OpenVPN quits on unstable client connection

[jsnl]

So I connect to OpenVPN from temporary remote sites, and once in a while the internet connections will be unstable (go up and down multiple times, high packet loss, jitter/latency issues, etc). When this happens, I notice I get to a point where I can't reconnect even after the connection stabilizes. At first it was some snort issues (triggering UDP portscan detection, etc), but I have all of those sorted and I'm still seeing it. Today I was finally able to narrow it down, and I'm curious if anyone else experiences this.

I am the only one connecting to this VPN. I keep maxclients at 2, mainly for quick reconnect purposes and also in case I need to VPN from both my phone and laptop at the same time. I think the issue is when maxclients is exceeded, the service stops (red X on the openvpn service status). An example from the log:

Dec 28 13:03:23 	openvpn 	41965 	(removed):57593 TLS Error: incoming packet authentication failed from [AF_INET](removed):57593
Dec 28 13:03:24 	openvpn 	41965 	(removed):57593 Authenticate/Decrypt packet error: bad packet ID (may be a replay): [ #2 / time = (1672250544) 2022-12-28 13:02:24 ] -- see the man page entry for --no-replay and --replay-window for more info or silence this warning with --mute-replay-warnings
Dec 28 13:03:24 	openvpn 	41965 	(removed):57593 TLS Error: incoming packet authentication failed from [AF_INET](removed):57593
Dec 28 13:03:25 	openvpn 	41965 	(removed):57593 Authenticate/Decrypt packet error: bad packet ID (may be a replay): [ #2 / time = (1672250544) 2022-12-28 13:02:24 ] -- see the man page entry for --no-replay and --replay-window for more info or silence this warning with --mute-replay-warnings
Dec 28 13:03:25 	openvpn 	41965 	(removed):57593 TLS Error: incoming packet authentication failed from [AF_INET](removed):57593
Dec 28 13:03:26 	openvpn 	41965 	(removed):57593 Authenticate/Decrypt packet error: bad packet ID (may be a replay): [ #2 / time = (1672250544) 2022-12-28 13:02:24 ] -- see the man page entry for --no-replay and --replay-window for more info or silence this warning with --mute-replay-warnings
Dec 28 13:03:26 	openvpn 	41965 	(removed):57593 TLS Error: incoming packet authentication failed from [AF_INET](removed):57593
Dec 28 13:03:27 	openvpn 	41965 	(removed):57593 Authenticate/Decrypt packet error: bad packet ID (may be a replay): [ #2 / time = (1672250544) 2022-12-28 13:02:24 ] -- see the man page entry for --no-replay and --replay-window for more info or silence this warning with --mute-replay-warnings
Dec 28 13:03:27 	openvpn 	41965 	(removed):57593 TLS Error: incoming packet authentication failed from [AF_INET](removed):57593
Dec 28 13:03:28 	openvpn 	41965 	(removed):64642 MULTI: new incoming connection would exceed maximum number of clients (2) 

There are lots of those packet errors, but the "exceed max clients" line is the last thing in the log when it dies.

Is this expected behavior - for the server to shut down if maxclients is exceeded? Or is this a bug? I can't find any indication to show if the software is crashing or just closing.

My temporary solution has been to put a watchdog on it, but I'm curious to know if this is something anyone else has ran into.

[Gertjan]

@jsnl

VPN needs good time.
When you see a packet coming in on "13:03:26" an the packet states it was send at "13:02:24" then the message (may be a replay) makes sens.
Check time on both sides.

Further more, clients can only logging when credentials are ok, what about accepting more then just 2 client ?
Or : temporary disable all other possible incoming VPN ''scanners' by limliting your OpenVPN WAN rule to the IP you are using to test.
If you still receive these "Authenticate/Decrypt packet error" you know it's coming from your device == the time not sync issue.

[jsnl]

The thing is, there should have only been one client connected at that time. So it means that because of the bad connection, a re-connect attempt happened, the software considered it a new connection, held the old connection open, the packets got confused, the connection timed out again, and the client tried to reconnect again which got counted as a THIRD connection, at which point the software closed or crashed (not sure which).

All connections were from my Windows OpenVPN client, and done in the background without input from me - up until the point the server died.

[jsnl]

Some other config settings for context...

Concurrent connections: 2
Ping Interval: 10
Ping Timeout: 60
Ping Method: Keepalive
Inactive: 300

I could look at lowering the ping timeout and inactive settings to clear up any stale connections. Is there any reason for inactive to be set at 5 minutes (I think this was the default)? In my mind I should be able to lower the ping timeout to 30 and inactive to 90 or 120. What is the difference between ping timeout and inactive? I assume a keepalive ping counts as activity? And with a timeout of 30 it would drop the connection after 3 consecutive missed pings (at an interval of 10), right?

But all of that still doesn't explain why the server closes.

[Gertjan]

@jsnl said in OpenVPN quits on unstable client connection:

Inactive: 300

I'm using the default settings :

Did you solved the huge clock time difference between the client and the server ?
1 minute is far to much.

@gertjan said in OpenVPN quits on unstable client connection:

When you see a packet coming in on "13:03:26" an the packet states it was send at "13:02:24" then the message (may be a replay) makes sense.