Looking to resolve NTP drift in Pritunls servers/clients

Pritunl Pritunl VPN
,
1

Hello again. We are experiencing OpenVPN issues of the following quite often AEAD Decrypt error: bad packet ID (may be a replay). We have correlated this to our devices where they are on cellular data and disconnect then reconnect maybe around ~13 hours to 2 days at times. (The default Pritunl sets for authentication is 12 hours.) When the device comes back online, the NTP server does not sync on the public web and is not synced to our Pritunl servers. As for solutions I have found several which I am researching to see if Pritunl can add this feature, if not I can see if it’s possible on my side:

  1. Is it possible to modify the ovpn profile via Pritunl’s side? Was hoping in adding the following as a safeguard:
script-security 2
pre-up /usr/local/bin/sync-time-before-vpn.sh

The script I have in mind:

#!/bin/bash

chronyd -q  'server time.cloudflare.com iburst' >/dev/null 2>&1

if [ $? -ne 0 ]; then
  HTTP_TIME=$(curl -sI --max-time 5 https://1.1.1.1 | grep -i '^date:' | cut -d' ' -f2-)
  if [ -n "$HTTP_TIME" ]; then
    date -s "$HTTP_TIME"
  fi
fi

exit 0
  1. Setup chrony servers on the Pritunl servers and have the devices communicate to the servers of the correct time?

Wondering if any of these approaches would be the right choice?

2

The client doesn’t allow adding scripts, it would create a privilege escalation vulnerability. A device losing internet access shouldn’t cause the time to become inaccurate and that error message doesn’t indicate a time issue. Try switching the server protocol to TCP.

If the server loses time sync a lot more issues will occur, a lot of the internal state and failover code uses timestamps. The server must always maintain an accurate time within 5 seconds of all other servers to avoid issues.

I have added a new setting sudo pritunl set vpn.replay_window 128 to the codebase, it will be included in the next release to adjust this option. But it’s unlikely increasing it will fix the issue. On current releases the value can be modified in /usr/lib/pritunl/usr/lib/python3.12/site-packages/pritunl/server/instance.py or
/usr/lib/pritunl/usr/lib/python3.9/site-packages/pritunl/server/instance.py on the line server_conf += 'replay-window 128\n'. After updating this file run sudo systemctl restart pritunl.

3

Thank you for this @zach. We have a provider, Telnyx for SIM cards for cellular data, on our devices running pritunl-client. As a company we are trying to find ways when disconnects occur to rebound with a connection and not continue with constant errors. This is what I’ve found using Claude:

Server side logs:

// epoch 1791511468 = 02:04:28 UTC — matches "Authorization successful" exactly
{"timestamp": 1791511468, "event": "user_connect_success", "remote_address": "64.16.243.233", "user_name": "2ccf67ab8018"}
{"timestamp": 1791511468, "event": "user_ovpn_success", "remote_address": "64.16.243.233", "user_name": "2ccf67ab8018"}

// epoch 1791511472 = 02:04:32 UTC — matches "Stopping system profile due to authentication errors" exactly
{"timestamp": 1791511472, "event": "user_ovpn_failure", "remote_address": "64.16.243.233", "event_long": "Expired auth timestamp"}
{"timestamp": 1791511472, "event": "user_ovpn_failure", "remote_address": "64.16.243.233", "event_long": "Expired auth timestamp"}
{"timestamp": 1791511472, "event": "user_ovpn_failure", "remote_address": "64.16.243.233", "event_long": "Expired auth timestamp"}

Is there a way to have the server logs more verbose? If so, what additional logs would be appended to the already existing logs?

Client side logs:

[22:04:28][INFO] connection: Authorization successful
[22:04:32][INFO] connection: Stopping reconnect
[22:04:32][INFO] connection: Stopping system profile due to authentication errors

I’m thinking this correlates to Telnyx’s SIM cards but would the idea be to widen the auth_time_window and --replay-window on the server side and communicate to Telnyx what’s up?

Also, should I enable OpenVPN Authentication Cache? Wondering if that can be setup to help with these re-authentication issues.

4

That error shouldn’t be occurring, it’s not related to OpenVPN. It is from the HTTPS pre-connection authorization request. You can significantly increase sudo pritunl set app.auth_time_window 43200 which is set in seconds to correct the error. There are multiple layers of authentication including a one time nonce so the value can be safely increased to several days. The default is already 12 hours so the client likely has either an incorrect timezone or a significantly skewed clock.

1 Like