Occasional TLS handshake error

apeg

Hi,

I have been hosting my OpenVPN server for about 10 months now (via r7000 ddwrt). I have about 20 active connections at all times. For the most part everything runs like clockwork, but once in a blue moon a user will disconnect and dozens of “UNDEF” entries will appear. The logs report the following TLS handshake issue (server side) and just loops forever as i have recoonection attpems set to infiite:

daemon.err openvpn[6640]: 69.*.*.*:51353 TLS Error: TLS handshake failed
daemon.notice openvpn[6640]: 69.*.*.*:51353 SIGUSR1[soft,tls-error] received, client-instance restarting
daemon.notice openvpn[6640]: 69.*.*.*:58915 TLS: Initial packet from [AF_INET]69.*.*.*:58915, sid=231d2d1d a73ff4f7
daemon.err openvpn[6640]: 69.*.*.*:40704 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)

I have tried to fix the issue a bunch of times but I just don’t seem to have the skills to dive in deeper. Also, it’s not the end of the world as a simple reboot of the client machine 100% of the time solves the problem.

But as of today I think I have a hunch/clue to the “once in a blue moon” occurrence. If the client machine is active/connected (through a router) and the external IP of the client router changes the reconnection attempts made by the client device (behind the router) forever get stuck in this TLS handshake issue.

if i'm right (big if) it would seem the client device isn't aware of the external IP change until the device is rebooted? Would anyone be able to provide insight or ideas I can try?

Thanks,

Traffic

Please see the Forum rules (top of this page)

apeg

Here we go, client:

client
dev tun12
proto udp
remote * *
resolv-retry infinite
nobind
persist-key
persist-tun
ca ca.crt
tls-client
remote-cert-tls server
auth-user-pass *.*
cipher AES-128-CBC
reneg-sec 0
verb 0

Server:

server 10.*.*.0 255.255.255.0
proto udp
port ****
dev tun22
cipher AES-128-CBC
keepalive 15 60
verb 3
push "route 172.*.*.0 255.255.255.0"
client-config-dir ccd
client-to-client
plugin /lib/openvpn_plugin_auth_nvram.so vpn_server2_users_val
script-security 2
username-as-common-name
client-cert-not-required
ca ca.crt
dh dh.pem
cert server.crt
key server.key
status-version 2
status status

# Custom Configuration
--duplicate-cn

apeg

I am unable to provide client logs because when the issue is occurring i cant connect to the client machine and i am unable to reproduce the issue on my end.

The reason i may be unable to reproduce is because i have a static IP form my ISP? just a guess

Traffic

apeg wroteclient
<..>
persist-key
persist-tun

The persist options could be the problem ..

apeg

Thanks Traffic, I took both the persist parameters out and from my end i cant see any negative impacts.

To make myself a little more knowledgeable on what i just removed i'm trying to read up on what the persist options do. But the best descriptions I've found are a bit cryptic. Wondering if anyone can correct/fill in the gaps.

persist-key, removed the need for openVPN to recheck the key file on re-connection attempts? It goes on to say this is useful should root privilege be taken away from openVPN, i guess every setup is different but i cant see how root privileges would be taken away? if that's the only use for the command than i dont see a need to keep it, although i dont fully get why a cached key would cause my TLS handshake issues?

persist-tun, from what i can tell this keep the IP association alive with the client machine on disconnect. This i understand a little more and can see how that saved association could cause re-connection issues. am i close on this?

Anyhow if i remove the two parameters from all my connections will i see any other changes as a result?

Cheers,

Traffic

apeg wroteI am unable to provide client logs because when the issue is occurring i cant connect to the client

If you use --log-append on a client that regularly has a problem, you will be able to see the full log once a new session is established.