openVPN TLS Error: TLS handshake failed but was previously working

Question

I have an openvpn configured on my raspberrypi, I followed this guide: https://juncotic.com/openvpn-easyrsa-3-montando-la-vpn/ and everything was working fine for weeks. Suddenly a cupple days ago the vpn stopped working and is throwing the TLS error. I checked that the port forwarding was still up, it was, I also checked that everything was up to date on both the server and my machine, everything was, also checked if the openvpn was running correctly, nothing on the logs point that it shouldn't work, also tried changing the port of the vpn to a higher one, that didn't work. I don't know what else to look for. I'll attatch some info, if anyone needs something else let me know.

These are my config files:

server.conf:

port 1194
proto udp
server 192.168.10.0 255.255.255.0 
client-to-client
persist-key
persist-tun
ca /etc/openvpn/keys/ca.crt
cert /etc/openvpn/keys/cloudAtlas.crt
dh /etc/openvpn/keys/dh.pem
key /etc/openvpn/keys/cloudAtlas.key
tls-auth /etc/openvpn/keys/ta.key 0
crl-verify /etc/openvpn/keys/crl.pem
comp-lzo adaptive
dev tun
ifconfig-pool-persist server-ipp.txt 0
keepalive 10 120
cipher AES-256-CBC
auth SHA512
tls-version-min 1.2
tls-cipher TLS-DHE-RSA-WITH-AES-256-GCM-SHA384
log /var/log/openvpn/server.log
verb 3

client2.conf:

client
dev tun
proto udp
port 1194
remote 21e800.duckdns.org 1194
remote-cert-tls server
resolv-retry infinite
nobind
persist-key
persist-tun
comp-lzo
verb 3
cipher AES-256-CBC
auth SHA512
tls-version-min 1.2
tls-cipher TLS-DHE-RSA-WITH-AES-256-GCM-SHA384
ca /etc/openvpn/keys/ca.crt
key /etc/openvpn/keys/cliente1.key
cert /etc/openvpn/keys/cliente1.crt
key-direction 1
tls-auth /etc/openvpn/keys/ta.key 1

The openvpn logs output when starting:

Thu Aug 19 22:10:30 2021 OpenVPN 2.4.7 arm-unknown-linux-gnueabihf [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] built on Apr 28 2021
Thu Aug 19 22:10:30 2021 library versions: OpenSSL 1.1.1d  10 Sep 2019, LZO 2.10
Thu Aug 19 22:10:30 2021 NOTE: your local LAN uses the extremely common subnet address 192.168.0.x or 192.168.1.x.  Be aware that this might create routing conflicts if you connect to the VPN server from public locations such as internet cafes that use the same subnet.
Thu Aug 19 22:10:30 2021 Note: cannot open server-ipp.txt for READ
Thu Aug 19 22:10:30 2021 Diffie-Hellman initialized with 2048 bit key
Thu Aug 19 22:10:30 2021 Outgoing Control Channel Authentication: Using 512 bit message hash 'SHA512' for HMAC authentication
Thu Aug 19 22:10:30 2021 Incoming Control Channel Authentication: Using 512 bit message hash 'SHA512' for HMAC authentication
Thu Aug 19 22:10:30 2021 ROUTE_GATEWAY 192.168.1.1/255.255.255.0 IFACE=eth0 HWADDR=e4:5f:01:38:49:2b
Thu Aug 19 22:10:30 2021 TUN/TAP device tun0 opened
Thu Aug 19 22:10:30 2021 TUN/TAP TX queue length set to 100
Thu Aug 19 22:10:30 2021 /sbin/ip link set dev tun0 up mtu 1500
Thu Aug 19 22:10:30 2021 /sbin/ip addr add dev tun0 local 192.168.10.1 peer 192.168.10.2
Thu Aug 19 22:10:30 2021 /sbin/ip route add 192.168.10.0/24 via 192.168.10.2
Thu Aug 19 22:10:30 2021 Could not determine IPv4/IPv6 protocol. Using AF_INET
Thu Aug 19 22:10:30 2021 Socket Buffers: R=[180224->180224] S=[180224->180224]
Thu Aug 19 22:10:30 2021 UDPv4 link local (bound): [AF_INET][undef]:1194
Thu Aug 19 22:10:30 2021 UDPv4 link remote: [AF_UNSPEC]
Thu Aug 19 22:10:30 2021 MULTI: multi_init called, r=256 v=256
Thu Aug 19 22:10:30 2021 IFCONFIG POOL: base=192.168.10.4 size=62, ipv6=0
Thu Aug 19 22:10:30 2021 IFCONFIG POOL LIST
Thu Aug 19 22:10:30 2021 Initialization Sequence Completed

The message of the client when trying to connect:

Thu Aug 19 22:12:03 2021 OpenVPN 2.4.7 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] built on Jul 19 2021
Thu Aug 19 22:12:03 2021 library versions: OpenSSL 1.1.1f  31 Mar 2020, LZO 2.10
Thu Aug 19 22:12:03 2021 Outgoing Control Channel Authentication: Using 512 bit message hash 'SHA512' for HMAC authentication
Thu Aug 19 22:12:03 2021 Incoming Control Channel Authentication: Using 512 bit message hash 'SHA512' for HMAC authentication
Thu Aug 19 22:12:03 2021 TCP/UDP: Preserving recently used remote address: [AF_INET]83.51.211.151:1194
Thu Aug 19 22:12:03 2021 Socket Buffers: R=[212992->212992] S=[212992->212992]
Thu Aug 19 22:12:03 2021 UDP link local: (not bound)
Thu Aug 19 22:12:03 2021 UDP link remote: [AF_INET]83.51.211.151:1194
Thu Aug 19 22:13:03 2021 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Thu Aug 19 22:13:03 2021 TLS Error: TLS handshake failed
Thu Aug 19 22:13:03 2021 SIGUSR1[soft,tls-error] received, process restarting
Thu Aug 19 22:13:03 2021 Restart pause, 5 second(s)
Thu Aug 19 22:13:08 2021 TCP/UDP: Preserving recently used remote address: [AF_INET]83.51.211.151:1194
Thu Aug 19 22:13:08 2021 Socket Buffers: R=[212992->212992] S=[212992->212992]
Thu Aug 19 22:13:08 2021 UDP link local: (not bound)
Thu Aug 19 22:13:08 2021 UDP link remote: [AF_INET]83.51.211.151:1194
Thu Aug 19 22:14:08 2021 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Thu Aug 19 22:14:08 2021 TLS Error: TLS handshake failed
Thu Aug 19 22:14:08 2021 SIGUSR1[soft,tls-error] received, process restarting
Thu Aug 19 22:14:08 2021 Restart pause, 5 second(s)
Thu Aug 19 22:14:13 2021 TCP/UDP: Preserving recently used remote address: [AF_INET]83.51.211.151:1194
Thu Aug 19 22:14:13 2021 Socket Buffers: R=[212992->212992] S=[212992->212992]
Thu Aug 19 22:14:13 2021 UDP link local: (not bound)
Thu Aug 19 22:14:13 2021 UDP link remote: [AF_INET]83.51.211.151:1194
Thu Aug 19 22:15:13 2021 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Thu Aug 19 22:15:13 2021 TLS Error: TLS handshake failed
Thu Aug 19 22:15:13 2021 SIGUSR1[soft,tls-error] received, process restarting
Thu Aug 19 22:15:13 2021 Restart pause, 5 second(s)
Thu Aug 19 22:15:18 2021 TCP/UDP: Preserving recently used remote address: [AF_INET]83.51.211.151:1194

My port forwarding configuration (router):

enter image description here

Answers:

This is what i get when I ping to my router with the specified port:

pah@xiaomi:~$ nmap -Pn -p 1194 21e800.duckdns.org
Starting Nmap 7.80 ( https://nmap.org ) at 2021-08-19 22:58 CEST
Nmap scan report for 21e800.duckdns.org (83.51.211.151)
Host is up.
rDNS record for 83.51.211.151: 151.red-83-51-211.dynamicip.rima-tde.net

PORT     STATE    SERVICE
1194/tcp filtered openvpn

Nmap done: 1 IP address (1 host up) scanned in 2.34 seconds

And the certificates are valid until 2024. Just in case I was missing something I've reedone all the certificates and still not working.

Also I tried to check if I was receiving packets with:

sudo tcpdump -i any -c5 -nn port 1194

Nothing came out so I suspect that the problem is network-related but my knowledge there is ... scarce, so I don't know how to further debbug it or where the problem could be besides the port forwarding which I think is working because of the response of the ping (?).

Any ways, if someone has any ideas let me know please.

Answer: I FOUND THE PROBLEM! It was the DNS service, don't know why but it wasn't updating correctly my IP, and since it's dynamic everything just stoped working. I should have checked that one of the first things, shame on me.

Is it "a few weeks" as in .. right around or just beyond 30 days since you started this up ?? I'm asking because the tutorial you followed uses the easy-rsa method. I suspect though I'm not certain, that your CRL validity is outdated and needs to be refreshed. You can set crl time validity, but I believe in easy-rsa it defaults to 30 days. Also, I would recommend removing comp-lzo from your configuration. You have to remove on client and server should you decide to do so; It's deprecated and causes a couple problems: https://community.openvpn.net/openvpn/wiki/DeprecatedOptions — Enoch Root, Aug 19 '21 at 21:58
What's the result of a crl check on server? Example: openssl crl -in fileLocation.crl -noout -text — Enoch Root, Aug 21 '21 at 03:20
It's just a quick check but it's worth it to do so. Just to rule it out as a possible — Enoch Root, Aug 21 '21 at 03:22

score 0 · Answer 1 · answered Aug 19 '21 at 21:02

Check if you can actually make a connection from the internet to that ip and port:

maybe you have the server getting the internal IP via DHCP and it's internal IP have changed.
maybe your external IP changed double check.

Check that your server and client certificates are not expired, it could be the case as you said it was working fine before for a time.

openVPN TLS Error: TLS handshake failed but was previously working

1 Answers1