On 19/11/2024 09:25, נתי שטרן wrote:
have something to fix configuration?
I already answered that:
> Since you seem to run OpenVPN Access Server, just log into the web
> portal and download a new configuration profile.
Otherwise, read the fine manual we have for OpenVPN. You already have
the clues: --tls-crypt-v2 --tls-crypt --tls-auth
<https://build.openvpn.net/man/openvpn-2.6/openvpn.8.html>
Don't ask the community to spoon feed you. Since you seem interested in
security research, practice the research part first before seeking help.
--
kind regards,
David Sommerseth
OpenVPN Inc
בתאריך יום ג׳, 19 בנוב׳ 2024 ב-10:17 מאת David Sommerseth
<dazo+open...@eurephia.org <mailto:dazo%2bopen...@eurephia.org>>:
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
<http://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 <http://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>
<mailto: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>
> <mailto: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>
> <mailto:dazo%2bopen...@eurephia.org
<mailto:dazo%252bopen...@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>
<http://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>
<http://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>
<http://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>
<http://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>
<http://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>
<http://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>
<http://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>>
> <mailto: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>>
> > <mailto: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>> <mailto: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>>
> > <mailto: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>
<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>>
> >
<mailto: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://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>>>
>
>
>
>
>
> --
> <https://netanel.ml <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
