The interesting lines are these:
2024-11-18T20:53:01+1100 [stdout#info] [OVPN 0]
OUT: '2024-11-18 09:53:01 152.32.247.23:55730
Non-OpenVPN client protocol detected'
These lines indicates the server seems to be configured with
--port-share. And those packets are forwarded to the service behind
OpenVPN. In this case OpenVPN behaves like a proxy.
2024-11-19T01:13:00+1100 [stdout#info] [OVPN 1]
OUT: '2024-11-18 14:13:00 TLS Error:
tls-crypt unwrapping failed from [AF_INET]195.28.180.102:36515
(via [AF_INET]103.6.170.21%eth0)'
2024-11-19T01:13:35+1100 [stdout#info] [OVPN 1]
OUT: '2024-11-18 14:13:35 tls-crypt unwrap error: packet too short'
That just means someone is trying to connect to the server not using
--tls-crypt or --tls-crypt-v2. In this case, your client configuration
uses --tls-auth, which will result in this kind of error and not being
able to connect.
I believe --mute will reduce the number of duplicated log lines in these
cases on the server side.
I am not able to see anything extraordinary in these log lines. This is
just plain misconfiguration.
Since you seem to run OpenVPN Access Server, just log into the web
portal and download a new configuration profile.
This has certainly nothing to do with any kind of security issues.
--
kind regards,
David Sommerseth
OpenVPN Inc
On 18/11/2024 15:17, נתי שטרן wrote:
*_
_*
*_server logs:_*
[...snip...]
בתאריך יום ב׳, 18 בנוב׳ 2024 ב-13:58 מאת Илья Шипицин
<chipits...@gmail.com <mailto:chipits...@gmail.com>>:
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
<mailto: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
<mailto:dazo%2bopen...@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 <http://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 <http://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 <http://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 <http://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 <http://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 <http://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 <http://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>
<mailto: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>
> <mailto: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> <mailto: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>
> <mailto:g...@greenie.muc.de
<mailto:g...@greenie.muc.de>>
>
>
>
> --
> <https://netanel.ml <https://netanel.ml>>
> _______________________________________________
> Openvpn-devel mailing list
> Openvpn-devel@lists.sourceforge.net
<mailto:Openvpn-devel@lists.sourceforge.net>
> <mailto: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://lists.sourceforge.net/lists/listinfo/openvpn-devel <https://lists.sourceforge.net/lists/listinfo/openvpn-devel>>
>
>
>
> --
> <https://netanel.ml <https://netanel.ml>>
--
<https://netanel.ml>
--
<https://netanel.ml>
_______________________________________________
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel
