I initially thought it was not your server, because you told us that you do
not have server logs.

do you have at least any client packet that reaches server ?

(I know you may ask how to check that. I'd choose tcpdump. in case if you
wish to ask how to use tcpdump - sorry, no answer. Please use the tool of
your choice, whatever you are comfortable with)


if no packet reaches server, most probably you did not open firewall
(either on vm itself or in cloud level).

(if you are going to ask how to manage firewall on vm or cloud level,
sorry, no idea here, please consult cloud guides or contact cloud support).

‪пн, 18 нояб. 2024 г. в 12:43, ‫נתי שטרן‬‎ <nsh...@gmail.com>:‬

> How to solve this problem?
> because both the client and server are my  own
>
>
> ‫בתאריך יום ב׳, 18 בנוב׳ 2024 ב-12:04 מאת ‪David Sommerseth‬‏ <‪
> dazo+open...@eurephia.org‬‏>:‬
>
>>
>> Please stop now.
>>
>> A client which cannot reach a server because the client side has
>> connectivity issues towards the server is not a DoS, it is not a CVE and
>> will never be considered a security issue.
>>
>> First of all, a DoS attack is commonly related to a SERVER becoming
>> unresponsive due to traffic to the server causing it to stop responding.
>>   Or that one VPN clients misbehaviour (not due to misconfiguration,
>> though) results in no other clients being able to connect.
>>
>> What you have described so far is that you cannot reach the server.  And
>> OpenVPN tries to reconnect regularly.  This is the expected behaviour of
>> most VPN clients - they try to keep the tunnel running with as little
>> user interaction as possible.  The back-off timer is there to also
>> needlessly keep trying if there seems to be longer persisting
>> connectivity issues.
>>
>> And just to entertain you a bit more.  This is the logs when using
>> OpenVPN 3 Linux:
>>
>>
>> ----------------------------------------------------------------------------
>> Press CTRL-C to stop the connection
>>
>> 2024-11-18 09:59:19.854568 [STATUS] (StatusMajor.CONNECTION,
>> StatusMinor.CFG_OK)
>>
>> config_path=/net/openvpn/v3/configuration/4c2bba36x2151x4291xb7acx360000375d2a
>> 2024-11-18 09:59:19.854636 [LOG] Starting connection
>> 2024-11-18 09:59:19.854694 [LOG] Using DNS resolver scope: global
>> 2024-11-18 09:59:19.862369 [LOG] [Connect] DCO flag: disabled
>> 2024-11-18 09:59:19.862479 [STATUS] (StatusMajor.CONNECTION,
>> StatusMinor.CONN_CONNECTING)
>> 2024-11-18 09:59:19.862548 [LOG] [Core] OpenVPN core v3.10.1 linux
>> x86_64 64-bit OVPN-DCO
>> 2024-11-18 09:59:19.862596 [LOG] [Core] Frame=512/2112/512
>> mssfix-ctrl=1250
>> 2024-11-18 09:59:19.862636 [LOG] Resolving
>> 2024-11-18 09:59:19.866525 [LOG] [Core] Contacting 103.6.170.21:1194 via
>> UDP
>> 2024-11-18 09:59:19.866638 [LOG] Waiting for server response
>> 2024-11-18 09:59:19.878505 [LOG] [Core] Connecting to
>> [103.6.170.21]:1194 (103.6.170.21) via UDP
>> 2024-11-18 09:59:29.861733 [LOG] [Core] Server poll timeout, trying next
>> remote entry...
>> 2024-11-18 09:59:29.861875 [LOG] Resolving
>> 2024-11-18 09:59:29.865648 [LOG] [Core] Contacting 103.6.170.21:1194 via
>> UDP
>> 2024-11-18 09:59:29.865769 [LOG] Waiting for server response
>> 2024-11-18 09:59:29.876299 [LOG] [Core] Connecting to
>> [103.6.170.21]:1194 (103.6.170.21) via UDP
>> 2024-11-18 09:59:39.862254 [LOG] [Core] Server poll timeout, trying next
>> remote entry...
>> 2024-11-18 09:59:39.862347 [LOG] Resolving
>> 2024-11-18 09:59:39.866157 [LOG] [Core] Contacting 103.6.170.21:1194 via
>> UDP
>> 2024-11-18 09:59:39.866262 [LOG] Waiting for server response
>> 2024-11-18 09:59:39.877288 [LOG] [Core] Connecting to
>> [103.6.170.21]:1194 (103.6.170.21) via UDP
>> 2024-11-18 09:59:49.862757 [LOG] [Core] Server poll timeout, trying next
>> remote entry...
>> 2024-11-18 09:59:49.862852 [LOG] Resolving
>> 2024-11-18 09:59:49.866514 [LOG] [Core] Contacting 103.6.170.21:1194 via
>> UDP
>> 2024-11-18 09:59:49.866614 [LOG] Waiting for server response
>> 2024-11-18 09:59:49.875998 [LOG] [Core] Connecting to
>> [103.6.170.21]:1194 (103.6.170.21) via UDP
>> 2024-11-18 09:59:59.863047 [LOG] [Core] Server poll timeout, trying next
>> remote entry...
>> 2024-11-18 09:59:59.863179 [LOG] Resolving
>> 2024-11-18 09:59:59.866699 [LOG] [Core] Contacting 103.6.170.21:1194 via
>> UDP
>> 2024-11-18 09:59:59.866798 [LOG] Waiting for server response
>> 2024-11-18 09:59:59.876724 [LOG] [Core] Connecting to
>> [103.6.170.21]:1194 (103.6.170.21) via UDP
>> 2024-11-18 10:00:09.863146 [LOG] [Core] Server poll timeout, trying next
>> remote entry...
>> 2024-11-18 10:00:09.863242 [LOG] Resolving
>> 2024-11-18 10:00:09.867305 [LOG] [Core] Contacting 103.6.170.21:1194 via
>> UDP
>> 2024-11-18 10:00:09.867406 [LOG] Waiting for server response
>> 2024-11-18 10:00:09.879292 [LOG] [Core] Connecting to
>> [103.6.170.21]:1194 (103.6.170.21) via UDP
>> 2024-11-18 10:00:19.863499 [LOG] [Core] Server poll timeout, trying next
>> remote entry...
>> 2024-11-18 10:00:19.863623 [LOG] Resolving
>> 2024-11-18 10:00:19.867758 [LOG] [Core] Contacting 103.6.170.21:1194 via
>> UDP
>> 2024-11-18 10:00:19.867845 [LOG] Waiting for server response
>> 2024-11-18 10:00:19.879066 [LOG] [Core] Connecting to
>> [103.6.170.21]:1194 (103.6.170.21) via UDP
>> ^C
>> Disconnecting...
>> Connection statistics:
>>                      BYTES_OUT: 2814
>>                    PACKETS_OUT: 67
>>                    N_RECONNECT: 6
>>
>> ----------------------------------------------------------------------------
>>
>> This needs to stop.  This is not a CVE.  This is an OpenVPN server which
>> doesn't respond on port 1194/udp.
>>
>> If you want to keep some kind of credibility with any security teams,
>> you need to back down and spend time looking for real issues and
>> document it far better.  And you will need to provide the server side
>> perspective as well, not just the client side.
>>
>> Once again: Clients not being able to connect to the server because of
>> network connectivity issues is not a CVE.
>>
>>
>> This case is closed.
>>
>>
>> --
>> kind regards,
>>
>> David Sommerseth
>> OpenVPN Inc
>>
>>
>>
>> On 18/11/2024 08:37, נתי שטרן wrote:
>> > What can I do to assign a CVE?
>> >   I attached the CVE team of ISRAEL CERT  to conversation
>> >
>> > tnx
>> >
>> > ‫בתאריך יום ב׳, 18 בנוב׳ 2024 ב-9:29 מאת ‪Илья Шипицин‬‏
>> > <‪chipits...@gmail.com <mailto:chipits...@gmail.com>‬‏>:‬
>> >
>> >     As many details as possible. Configuration file usually helps.
>> >
>> >     Other than that also server side logs are nice to have. As well as
>> >     the detailed repro steps
>> >
>> >     On Mon, Nov 18, 2024, 08:27 נתי שטרן <nsh...@gmail.com
>> >     <mailto:nsh...@gmail.com>> wrote:
>> >
>> >         Do you want the configuration file?
>> >
>> >         ‫בתאריך יום ב׳, 18 בנוב׳ 2024 ב-9:14 מאת ‪Gert Doering‬‏
>> >         <‪g...@greenie.muc.de <mailto:g...@greenie.muc.de>‬‏>:‬
>> >
>> >             Hi,
>> >
>> >             On Mon, Nov 18, 2024 at 09:09:57AM +0200, ?????? ????????
>> wrote:
>> >              > I don't have access to server logs, I sent you the client
>> >             logs as well as
>> >              > the line pointing to the DoS:
>> >              > TLS Error: TLS key negotiation failed to occur within 5
>> >             seconds
>> >              > SIGUSR1[soft,tls-error] received, process restarting
>> >
>> >             What makes you think it's a DoS that can be fixed by a code
>> >             change?
>> >
>> >             If you break the network, programs will not be able to
>> >             connect - and there
>> >             is nothing "a patch to the software" will be able to fix.
>> >
>> >             gert
>> >             --
>> >             "If was one thing all people took for granted, was
>> >             conviction that if you
>> >               feed honest figures into a computer, honest figures come
>> >             out. Never doubted
>> >               it myself till I met a computer with a sense of humor."
>> >                                           Robert A. Heinlein, The Moon
>> >             is a Harsh Mistress
>> >
>> >             Gert Doering - Munich, Germany g...@greenie.muc.de
>> >             <mailto:g...@greenie.muc.de>
>> >
>> >
>> >
>> >         --
>> >         <https://netanel.ml>
>> >         _______________________________________________
>> >         Openvpn-devel mailing list
>> >         Openvpn-devel@lists.sourceforge.net
>> >         <mailto:Openvpn-devel@lists.sourceforge.net>
>> >         https://lists.sourceforge.net/lists/listinfo/openvpn-devel
>> >         <https://lists.sourceforge.net/lists/listinfo/openvpn-devel>
>> >
>> >
>> >
>> > --
>> > <https://netanel.ml>
>>
>>
>>
>>
>
> --
> <https://netanel.ml>
>
_______________________________________________
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Reply via email to