OpenVPN connection fails (TLS handshake failed)

[andre2000]

Hi,

I have been using openVPN for a long time without any issues. However, since about two weeks, I cannot connect to openVPN anymore (using iOS 13 devices or the viscosity client on the Mac).

Today I took a look and am seeing the following error:

Jan 19 11:49:44   openvpn[18369]: 192.168.11.29:58298 TLS Error: TLS handshake failed
Jan 19 11:49:44   openvpn[18369]: 192.168.11.29:58298 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Jan 19 11:49:44   openvpn[18369]: 192.168.11.29:51732 TLS Error: incoming packet authentication failed from [AF_INET6]::ffff:192.168.11.29:51732
Jan 19 11:49:44   openvpn[18369]: 192.168.11.29:51732 Authenticate/Decrypt packet error: bad packet ID (may be a replay): [ #1 / time = (1579430974) Sun Jan 19 11:49:34 2020 ] -- see the man page entry for --no-replay and --replay-window for more info or silence this warning with --mute-replay-warnings

(I am aware that this is from an internal IP, it's the same from outside)

I did't make any changes to the system beside the regular updates.

Do you have an idea why this could happen? Would there be a reason to be paranoid about this? I will go ahead and reinstall OPNsense, but want to ensure I am not just cureing some symptoms away.

Please let me know if I shall provide further log files.

Thanks in advance!
Andre

[fabian]

Can you retry TCP to exclude network packet loss?

[andre2000]

thanks, I tried as suggested. I have changed the openVPN Server config to TCP, exported the connection again (made sure it points to the external dyndns address) and used a local vpn client to my VPN provider to make sure I am connecting from outside. Also, I checked the firewall to accept TCP for openVPN (it set to).
I verified the DNS entry at spdns is up to date - which it is - but I am not getting a response for ping.

Here is what the openVPN log shows after restarting the service:

Jan 19 13:01:07   openvpn[63208]: Initialization Sequence Completed
Jan 19 13:01:07   openvpn[63208]: TCPv4_SERVER link remote: [AF_UNSPEC]
Jan 19 13:01:07   openvpn[63208]: TCPv4_SERVER link local (bound): [AF_INET]192.168.11.1:1194
Jan 19 13:01:07   openvpn[63208]: Listening for incoming TCP connection on [AF_INET]192.168.11.1:1194
Jan 19 13:01:07   openvpn[63208]: Could not determine IPv4/IPv6 protocol. Using AF_INET
Jan 19 13:01:07   openvpn[63208]: /usr/local/etc/inc/plugins.inc.d/openvpn/ovpn-linkup ovpns1 1500 1623 10.0.8.1 10.0.8.2 init
Jan 19 13:01:07   openvpn[63208]: /sbin/ifconfig ovpns1 10.0.8.1 10.0.8.2 mtu 1500 netmask 255.255.255.255 up
Jan 19 13:01:07   openvpn[63208]: TUN/TAP device /dev/tun1 opened
Jan 19 13:01:07   openvpn[63208]: TUN/TAP device ovpns1 exists previously, keep at program end
Jan 19 13:01:07   openvpn[63208]: Initializing OpenSSL support for engine 'rdrand'
Jan 19 13:01:07   openvpn[63208]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Jan 19 13:01:07   openvpn[59636]: library versions: OpenSSL 1.0.2u 20 Dec 2019, LZO 2.10
Jan 19 13:01:07   openvpn[59636]: OpenVPN 2.4.8 amd64-portbld-freebsd11.2 [SSL (OpenSSL)] [LZO] [LZ4] [MH/RECVDA] [AEAD] built on Jan 7 2020
Jan 19 13:01:07   openvpn[22015]: SIGTERM[hard,] received, process exiting
Jan 19 13:01:05   openvpn[22015]: /usr/local/etc/inc/plugins.inc.d/openvpn/ovpn-linkdown ovpns1 1500 1623 10.0.8.1 10.0.8.2 init

My connection attempt does not show up.

Thank you for your help!

[andre2000]

so, I don't know why but the openVPN server was configured to listen on the LAN interface. By also pinning the connection to TCP4 instead of TCP i was able to connect. I will now revert to UDP and see what's happening.

[andre2000]

And there we go, it works again with UDP.

Now I also have a theory why this happened: I am running OPNsense in a proxmox KVM. Maybe the same time the issues started (guessing) I updated proxmox from v5 to v6, which caused the WAN interface (which is a physically attached NIC) to be removed from the OPNsense. Maybe that's why the interface was set to LAN, because the WAN adapter wasn't there.
But, this does not explain the initial issue about the failed TLS handshake - or does it?

At least I can use VPN again. Thanks for pointing me into the right direction.