"TLS handshake failed": the OpenVPN error explained

The full line is usually TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity), and the parenthetical advice is right about a third of the time. OpenVPN establishes a TLS control channel before it carries any traffic; this message means that control channel never completed.

Read the lines above the error

The message itself says almost nothing. The lines before it say everything.

• UDPv4 link remote: and then silence → packets are leaving and nothing is coming back. Network path problem.
• VERIFY ERROR: depth=0 → certificate verification failed. Trust problem.
• Authenticate/Decrypt packet error: packet HMAC authentication failed → the TLS auth key does not match. Configuration problem.
• Connection reset, restarting immediately → something is actively rejecting the connection rather than dropping it.

Cause one: the port is blocked or filtered

OpenVPN defaults to UDP 1194, and plenty of networks block it. The classic workaround is TCP on port 443, which is indistinguishable from HTTPS to anything short of deep packet inspection.

proto tcp
remote vpn.example.net 443

TCP over TCP is worse for throughput — two congestion control loops fighting each other — but it works where nothing else does. If your provider offers a 443/TCP endpoint and your usual one times out, try it before changing anything else.

Cause two: TLS auth or crypt key mismatch

OpenVPN can wrap the control channel in an extra HMAC layer, configured with tls-auth or tls-crypt. Both ends must use the same key file, and tls-auth additionally needs opposite key direction values: key-direction 1 on the client against 0 on the server.

Get either wrong and the server discards your packets without replying, which looks exactly like the port being blocked. The distinguishing log line is the HMAC authentication failure, which only appears at higher verbosity — add verb 4 while debugging.

tls-crypt is the newer of the two and has no direction to get wrong, which is one reason current configurations prefer it.

Cause three: certificates

Three variants, all producing a VERIFY ERROR:

• Expired. Client certificates are usually issued with a fixed lifetime. An old profile simply stops working one day with no other change.
• Wrong CA. The ca block in your config must be the authority that signed the server's certificate.
• Missing remote-cert-tls server. Without it a client can be tricked into accepting another client's certificate as a server. Its presence is correct; its absence is a real weakness rather than a convenience.

Check the dates:

openssl x509 -in client.crt -noout -dates

Cause four: the clock

TLS validates certificate validity windows against the local clock. A device set to the wrong year will reject a perfectly good certificate as not yet valid or long expired. This is common on devices that lose time when unplugged — routers, single-board computers, anything without a battery-backed clock.

Turn on automatic time and retest before changing any configuration.

Cause five: protocol or cipher mismatch

OpenVPN 2.5 and later negotiate ciphers via data-ciphers. An old client insisting on cipher AES-256-CBC against a server offering only AES-256-GCM, or vice versa, fails during negotiation.

If the client and server are different major versions, this is worth checking early. The fix is normally to update the client rather than to weaken the server.

Cause six: connecting through a proxy

On a network that requires an HTTP proxy, OpenVPN needs to be told:

http-proxy proxy.example.net 8080

Without it, the connection attempt goes nowhere and times out identically to a blocked port.

A working order

1. Raise verbosity to verb 4 and read the lines above the error.
2. Try the provider's TCP 443 endpoint.
3. Check the system clock.
4. Check certificate dates.
5. Confirm tls-auth key direction, or move to tls-crypt.
6. Try the same profile on a different network — mobile data is the fastest control.

If it connects on mobile data and not on the network you are on, the profile is correct and the network is filtering. That is a different problem with a different answer, and no amount of configuration will make a blocked port open.

Why WireGuard fails differently

WireGuard has no TLS, no certificates and no negotiation, so none of the causes above except the blocked-port one can occur. What it has instead is a silent handshake failure, which is less informative when it goes wrong. Neither is strictly better to debug; they simply fail in different places.