OpenVPN says TLS key negotiation failed to occur within 60 seconds

That line is a timeout, not a cause. It means the TLS control channel did not complete inside the handshake window, so the client gave up before any tunnel existed. Read the lines above it. If the log shows a certificate being inspected, packets are flowing and the problem is keys or certificates. If it shows nothing, the packets are not arriving.

Is this the same as AUTH_FAILED

No. AUTH_FAILED means your credentials reached the server and were rejected, which requires a working control channel. A TLS handshake failure happens earlier, before credentials are ever sent. The two errors share almost no causes. Check which string your log actually contains before applying any fix, because the remedies do not overlap.

The difference between tls-crypt and tls-auth

tls-auth adds an HMAC signature to control-channel packets and drops anything unsigned. tls-crypt encrypts those packets as well as authenticating them, using a pre-shared key. Both hide the control channel from scanners. Both produce a silent drop when the key does not match, which is why a mismatch looks exactly like a firewall problem from the client side.

Does switching from UDP to TCP fix this

Only when the cause is a filtered path. TCP on port 443 passes through networks that drop UDP, so the switch helps on hotel, campus and corporate connections. It does nothing for a key mismatch, an expired certificate or a wrong clock. Try the other transport as a diagnostic first, and keep it only if it actually changes the result.

Can a wrong system clock break the tunnel

Yes, because certificates carry a validity window and your client checks the current time against it. A clock far enough outside that window makes a valid certificate look expired or not yet valid. This is common on devices that lost their battery or booted without a network. Whether it surfaces as this timeout or as a separate verification error depends on the client, so correct the clock first and then read the log again. For the wider symptom index, see connection troubleshooting. For where each profile lives on each client, see using your OpenVPN profile.

OpenVPN TLS handshake failed

An OpenVPN TLS handshake failed message means the control channel never completed. The client log usually ends with two lines in a row:

TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
TLS Error: TLS handshake failed

Nothing has been said about your username or password yet. The tunnel does not exist. Your client sent its first control packet and never got back an answer it could use. So there is only one useful question, and it is a question about geography rather than about credentials. Find out where the packets stop.

What the message means

OpenVPN builds a control channel before it builds a tunnel. The control channel is a TLS session, and it carries the key exchange for everything that follows. Until that session completes, no data channel exists and no traffic moves.

Treat the 60 seconds as a deadline rather than a diagnosis. It is the handshake window, set by hand-window. The OpenVPN manual defines that as the window in which the TLS key exchange must finalize after either peer starts the handshake. It gives the default as 60 seconds. When the deadline passes without a completed handshake, the client gives up and prints both lines above.

Note that this is not an authentication failure. A rejected username or password produces AUTH_FAILED instead, which is a different page and a different fix. Read the string in your own log before applying anything below.

Why the OpenVPN TLS handshake failed

Five things stop the control channel, and they sort neatly into two groups. Either your packets never reached the server, or they reached it and were discarded before OpenVPN would talk to you. Work through the groups in order, because the tests below separate them in about two minutes.

Wrong port or wrong protocol

OpenVPN listens on one transport at a time per instance. A server configured for UDP does not answer TCP on the same port, and the reverse is equally true. Check the proto and remote lines in your profile before anything else.

proto udp
remote vpn.example.com 1194

The number after the hostname is the port. Confirm both against what the server actually publishes. A profile that has been hand-edited, or copied from a different provider, is the most common source of this mismatch.

Note the asymmetry that makes this hard to spot. On UDP there is no connection to refuse, so a wrong port produces silence and then the 60-second timeout. On TCP a wrong port usually produces a connection refused or a connection timeout much earlier. Silence is therefore weak evidence, and a fast TCP error is strong evidence.

Something in the path is dropping the traffic

Corporate networks, hotel networks and some mobile carriers filter outbound UDP on anything other than DNS. Your packets leave your machine and are discarded at the first hop that cares. The client cannot tell the difference between a filtered path and a server that is switched off.

Test this by changing exactly one variable. Run the same profile from a phone hotspot. If the tunnel comes up there and nowhere else, the profile is fine and the network is the problem. See connecting from a restricted network for the wider version of that situation.

tls-crypt or tls-auth does not match

Both options put a pre-shared key on the control channel, and both cause exactly this symptom when they do not match.

Start with what each one does. tls-auth adds an HMAC signature to every control-channel packet, and a packet without a valid signature is dropped before OpenVPN spends any work on it. tls-crypt goes further and encrypts the control channel as well as authenticating it, using the same pre-shared key on both ends.

Take the consequence seriously, because nobody states it plainly. A key mismatch is indistinguishable from a firewall drop at the client end. The server receives your packet, fails the check, and discards it without replying, because replying would confirm to a scanner that something is listening. Your client waits 60 seconds and prints a timeout. That is the design working correctly.

Four things break the match:

The <tls-crypt> or <tls-auth> inline block is missing from your profile entirely.
The block is present but truncated, usually by a copy and paste that dropped the closing tag.
The profile uses tls-auth where the server expects tls-crypt, or the reverse.
The key-direction line is absent or wrong, which applies to tls-auth and not to tls-crypt.

Re-download the profile rather than editing it. See re-importing the profile for the procedure per client.

The certificate chain does not verify

The control channel is TLS, so the server presents a certificate and your client checks it against the CA in your profile. A failure here stops the handshake as surely as a dropped packet does.

Look for a certificate verification failure in the log above the timeout. Read your own log for the wording rather than matching a string from a guide, because it changes between client versions. Suspect an expired CA, a profile carrying the wrong CA for that server, or an inline <ca> block that was truncated on import.

Read the remote-cert-tls server line as well. The OpenVPN manual describes it as requiring that the peer certificate was signed with an explicit key usage and extended key usage, following RFC 3280 TLS rules. With the value server, the extended key usage it demands is TLS Web Server Authentication. That is what stops another client certificate from impersonating the server. Its presence is correct and its absence is worth asking about.

The system clock is too far out

Certificates carry a validity window. A client whose clock sits outside that window rejects a certificate that is perfectly valid everywhere else. This shows up on machines that lost their CMOS battery, on freshly imaged virtual machines, and on devices that booted without a network.

Check the clock before you rebuild anything. There is no fixed tolerance in minutes, because what matters is whether the current time falls inside the certificate's own validity window. Compare the machine against a known time source, correct it, and retry. That costs a minute and removes a cause no amount of profile editing will fix.

Finding where the packets stop

Run these in order. Each one removes a group of causes rather than confirming a single one, which is why the order matters more than the individual result.

Test	What a pass means	What a fail means
`ping vpn.example.com`	The name resolves and the host answers	ICMP may simply be filtered, so this proves nothing on its own
`nc -vz vpn.example.com 443` on a TCP profile	TCP reaches the port and something is listening	The port is closed, filtered, or your profile has the wrong one
Same profile on a phone hotspot	Your local network is filtering the traffic	The problem follows you, so look at the profile or the server
Same profile on the other transport	The blocked transport is the cause	Both transports fail, so look at keys and certificates
Compare the client clock to a known time source	The clock is not involved	Fix the clock and retry before changing anything else

Note two limits on that table. A UDP port cannot be probed reliably, because a silent server and a filtered path look identical from outside, so nc -vz -u is not a test you should trust. Substitute Test-NetConnection vpn.example.com -Port 443 on Windows, which does the same job as the nc row.

Reading the log lines that matter

Raise the log level before you read anything. Add verb 4 to the profile, or start the client from a terminal with --verb 4 appended. The default level hides the stage the handshake reached.

openvpn --config yourprofile.ovpn --verb 4

Read four lines in particular, because they carry most of the diagnostic value.

The link line. Near the top the client prints the address and port it is actually dialling. Find that line and compare it against the remote line in your profile. It is the fastest way to catch a profile that resolves to a stale address or a port you did not expect.

A control-channel authentication failure. A key mismatch is logged by whichever side rejects the packet, and on an outbound connection that side is the server. So the message you want sits in a log you cannot read. Your own log shows the timeout and nothing else, which is exactly why a key mismatch and a firewall drop look identical from here.

A verification error. Any VERIFY ERROR line rules out the network entirely. Packets are arriving in both directions if your client got far enough to inspect a certificate.

The timeout pair. TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity) followed by TLS Error: TLS handshake failed is the terminal state, not a cause. Everything useful is above it.

Keep a working log for comparison, because most people have never read one. Capture one at verb 4 while a tunnel is healthy, and save it somewhere you will find it again. A successful start moves through the same stages in the same order every time. It dials the remote, it reports the peer connection, it verifies the server certificate, and it applies the options the server pushed. The strings differ between versions, so your own healthy log is a better reference than any list.

Find the last stage your own log reached and you have located the failure without guessing. A log that stops at the link line never got a reply. A log that stops after certificate verification has a path and a key problem further in.

Keep the general rule in front of you. A log that reaches certificate inspection has a working path, and a log that reaches nothing but the timeout does not. That single split decides which half of this page applies to you. For the flag-level detail on the options named here, see OpenVPN transport and control-channel options.

If it only fails on one network

Some networks permit TCP 443 and almost nothing else. On those, a UDP profile fails every time and a TCP profile on 443 usually works, because the traffic is indistinguishable from ordinary HTTPS at the transport layer.

Switch transports rather than tuning timeouts. Raising hand-window on a filtered path buys you a longer wait and the same result. If your provider ships both a UDP and a TCP profile, import the TCP one and keep it for exactly this case. See using your OpenVPN profile for where each profile goes per client.

Mobile networks add their own version of the problem. Carrier-grade NAT sits between you and the server, and some carriers keep UDP state for a very short period. A tunnel that establishes and then fails on the next attempt often points there rather than at your profile.

Consider a failover list if you move between networks regularly. A profile may carry more than one remote line, and remote-random tells the client to shuffle them rather than always trying the first. That converts a single blocked endpoint from a hard failure into a retry. See OpenVPN transport and control-channel options for how those lines interact.

PulseVPN issues both .ovpn and WireGuard configuration files, so changing protocol is a file swap rather than a support ticket. Read the proto and remote lines of any profile you already hold to see which transport and port it uses. If you need a transport your current file does not offer, ask before hand-editing it. The server has to be listening on the other side for the edit to mean anything.

Quick answers

OpenVPN says TLS key negotiation failed to occur within 60 seconds: That line is a timeout, not a cause. It means the TLS control channel did not complete inside the handshake window, so the client gave up before any tunnel existed. Read the lines above it. If the log shows a certificate being inspected, packets are flowing and the problem is keys or certificates. If it shows nothing, the packets are not arriving.
Is this the same as AUTH_FAILED: No. AUTH_FAILED means your credentials reached the server and were rejected, which requires a working control channel. A TLS handshake failure happens earlier, before credentials are ever sent. The two errors share almost no causes. Check which string your log actually contains before applying any fix, because the remedies do not overlap.
The difference between tls-crypt and tls-auth: tls-auth adds an HMAC signature to control-channel packets and drops anything unsigned. tls-crypt encrypts those packets as well as authenticating them, using a pre-shared key. Both hide the control channel from scanners. Both produce a silent drop when the key does not match, which is why a mismatch looks exactly like a firewall problem from the client side.
Does switching from UDP to TCP fix this: Only when the cause is a filtered path. TCP on port 443 passes through networks that drop UDP, so the switch helps on hotel, campus and corporate connections. It does nothing for a key mismatch, an expired certificate or a wrong clock. Try the other transport as a diagnostic first, and keep it only if it actually changes the result.
Can a wrong system clock break the tunnel: Yes, because certificates carry a validity window and your client checks the current time against it. A clock far enough outside that window makes a valid certificate look expired or not yet valid. This is common on devices that lost their battery or booted without a network. Whether it surfaces as this timeout or as a separate verification error depends on the client, so correct the clock first and then read the log again. For the wider symptom index, see connection troubleshooting. For where each profile lives on each client, see using your OpenVPN profile.