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
