OpenVPN TLS handshake failed: which branch are you on?

The line that says TLS handshake failed is the end of a story, not the start of one. What matters is the event immediately before it, because that event names which of four very different faults you have. A timeout, a control-channel mismatch, a certificate rejection and a failure after negotiation all produce the same headline. Choose the branch from the evidence, and the fix stops being a guess.

Read the last event before the failure

Scroll up rather than reading the final line. The event before the disconnect usually names the stage: no reply at all, an error while exchanging control packets, a verification result, or a successful negotiation followed by an authentication outcome. Each of those belongs to a different owner. That single line decides which section below applies.

Save the error text with the client version, the endpoint and the transport. Keep keys, passwords and unredacted profiles out of anything you paste publicly.

A precise first error is worth more than a long log excerpt. It names the stage, and the stage names the owner.

Branch one: nothing came back

If the client sent its first packet and received nothing usable, the problem is on the path or at the listener. Confirm the profile matches an option the operator actually offers: address, port, and UDP or TCP. Then check whether the endpoint is reachable at all from this network. Note which of those two checks failed before moving on.

A browser loading a page at the same hostname proves only that a web service answered. Even an accepted TCP connection says nothing about whether OpenVPN negotiation completed.

If the profile works on another trusted network, keep that comparison. It localises the restriction to a path or an intermediary.

Branch two: control channel does not match

When the exchange starts and then stalls, the control-channel settings are the first suspect. tls-auth and tls-crypt must match the deployment, and material from another server will not produce a useful exchange. This failure happens before any account login. A profile copied from an older server is the usual source.

A password reset does not replace those settings, and borrowing a key from another service is not a compatibility fix. Obtain the profile through the operator's verified channel and note the client version it expects.

Record the specific negotiation error rather than enabling a pile of older algorithms to see what sticks. A captured error text is what lets the operator check their side.

Branch three: a certificate was rejected

An explicit verification failure names the certificate it dislikes. Check the device clock first, then read which object failed: the server certificate, the client certificate, or an issuer in the chain. Expiry, an untrusted issuer and an unexpected identity are three different messages.

Keep verification enabled while you obtain corrected material. Accepting an unrelated certificate removes the error without proving you reached the intended server.

Note whether the failure follows the network or the profile. A certificate error that appears everywhere is not a path problem.

Branch four: negotiation finished and something else failed

Once the identity exchange succeeds, the remaining failure belongs to authentication or to routing. An explicit account rejection is an authentication question, and a connected tunnel with unreachable sites is a routing or DNS question. Continuing to replace TLS options at that point damages a stage that already worked.

When you report the problem, say whether every network fails, whether another profile works, and whether the server recorded the attempt. Silence on the server side and a rejection from it sit at different boundaries.