TLS Authenticate/Decrypt packet error - but not on local LAN

[GuyPickering]

My VPN has been working fine in the past, but recently stopped working (in the last 3-4 weeks I think, I don't use it much). When I am on my local LAN I am able to establish a connection fine (I specify the DDNS name in the .ovpn file pointing to my external IP address), but as soon as I switch WiFi off on my phone and use cellular I get the following error in my server log file:

Code: Select all

Sat Feb 13 17:01:03 2021 107.126.50.12:6754 Authenticate/Decrypt packet error: bad packet ID (may be a replay): [ #1 / time = (1613253658) Sat Feb 13 17:00:58 2021 ] -- see the man page entry for --no-replay and --replay-window for more info or silence this warning with --mute-replay-warnings
Sat Feb 13 17:01:03 2021 107.126.50.12:6754 TLS Error: incoming packet authentication failed from [AF_INET]107.126.50.12:6754

When connecting while on the LAN I see the following log:

Code: Select all

Sat Feb 13 17:22:30 2021 192.168.1.1:64494 TLS: Initial packet from [AF_INET]192.168.1.1:64494, sid=a29996e7 a9ed8d0b
Sat Feb 13 17:22:30 2021 192.168.1.1:64494 VERIFY OK: depth=1, CN=ChangeMe
Sat Feb 13 17:22:30 2021 192.168.1.1:64494 VERIFY KU OK
Sat Feb 13 17:22:30 2021 192.168.1.1:64494 Validating certificate extended key usage
Sat Feb 13 17:22:30 2021 192.168.1.1:64494 ++ Certificate has EKU (str) TLS Web Client Authentication, expects TLS Web Client Authentication
Sat Feb 13 17:22:30 2021 192.168.1.1:64494 VERIFY EKU OK
Sat Feb 13 17:22:30 2021 192.168.1.1:64494 VERIFY OK: depth=0, CN=Guy_iPhone_Dev

DDNS and port forwarding appears to be working correctly (i.e. ping works OK and I see entries in the log when trying to connect from cellular).

I am running Client Version 3.2.2 (3507) on iOS 14.4.
Server version is the latest available on a Raspberry Pi is:
OpenVPN 2.4.7 arm-unknown-linux-gnueabihf [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] built on Feb 20 2019
library versions: OpenSSL 1.1.1d 10 Sep 2019, LZO 2.10

All devices are exhibiting the same behavior. I even have a second VPN Server at a relatives house and the same thing is happening with that one.

Any ideas would be welcome. Last time I had this type of issue it turned out to be a change in the supported settings by the iOS client, but that was a couple of years ago now.

View OriginalClient config

client
dev tun
proto udp
remote xxxxxxxxxx.dynu.com 61194
resolv-retry infinite
nobind
persist-key
persist-tun
key-direction 1
remote-cert-tls server
tls-version-min 1.2
verify-x509-name server_xxxxxxxxx name
cipher AES-256-CBC
auth SHA256
auth-nocache
verb 3
<ca>
-----BEGIN CERTIFICATE-----
-----END CERTIFICATE-----
</ca>
<cert>
-----BEGIN CERTIFICATE-----
-----END CERTIFICATE-----
</cert>
<key>
-----BEGIN PRIVATE KEY-----
-----END PRIVATE KEY-----
</key>
<tls-auth>
#
# 2048 bit OpenVPN static key
#
-----BEGIN OpenVPN Static key V1-----
-----END OpenVPN Static key V1-----
</tls-auth>

View OriginalServer config

dev tun
proto udp4
port 61194
ca /etc/openvpn/easy-rsa/pki/ca.crt
cert /etc/openvpn/easy-rsa/pki/issued/server_xxxxxxxxx.crt
key /etc/openvpn/easy-rsa/pki/private/server_xxxxxxxxx.key
dh /etc/openvpn/easy-rsa/pki/dh2048.pem
topology subnet
server 10.9.0.0 255.255.255.0
# Set your primary domain name server address for clients
push "dhcp-option DNS 8.8.8.8"
push "dhcp-option DNS 8.8.4.4"
# Prevent DNS leaks on Windows
push "block-outside-dns"
# Override the Client default gateway by using 0.0.0.0/1 and
# 128.0.0.0/1 rather than 0.0.0.0/0. This has the benefit of
# overriding but not wiping out the original default gateway.
push "redirect-gateway def1"
client-to-client
keepalive 1800 3600
remote-cert-tls client
tls-version-min 1.2
tls-auth /etc/openvpn/easy-rsa/pki/ta.key 0
cipher AES-256-CBC
auth SHA256
user nobody
group nogroup
persist-key
persist-tun
crl-verify /etc/openvpn/crl.pem
status /var/log/openvpn/openvpn-status.log
status-version 3
log-append /var/log/openvpn/openvpn.log
verb 3

[TinCanTech]

The first thing you can do is increase to --verb 4 in your server config. This will give you a little more info.

Second, replay-errors are generally not fatal, so you should be OK.

[GuyPickering]

Thanks for the response TinCanTech! I figured it out after upping the verb, trying TCP instead of UDP and finally running tcpdump on the server. It was nothing to do with the OpenVPN configuration. It was a route issue on the Raspberry Pi. I had connected the Pi to my new solar install device which had a bad DHCP setting that resulted in an incorrect second default route on the Pi. The responses from the server were getting sent over both eth0 and wlan0 resulting in lost packets sent to the solar controller. Not sure why local connections worked, but once I reconfigured the route table via /etc/dhcpcd.conf to have 'no gateway' the issue resolved.