Sixty-Second TLS Timeout: Which End Actually Stopped?

The client gives up after sixty seconds with a message about key negotiation, and the laptop offers no opinion about why. That sentence describes the client's patience, not the server's behaviour. Three quite different situations produce it: the packet never reached the right service, the service discarded it before logging anything, or the service rejected it and said so somewhere the client cannot see. Correlating one attempt across both ends is what separates them.

Give one attempt an identity you can search for

Write down the start time with its time zone, the profile name, the destination the client actually resolved, the port, and whether the connection is UDP or TCP. If the profile carries several remote entries, note which one that attempt selected, because a retry may have moved to the next entry without changing the file you are reading.

Take the endpoint from the active log rather than from the download you remember. A profile pointing at a private address is perfectly valid and completely unusable from a network that cannot route to it, and that case looks identical to a server that is down.

Then ask the operator for the same window on the intended instance. Clock skew is common enough that an offset of a few minutes can make a matching event look absent, so record the offset rather than concluding there was no event.

Four observations, four different next steps

What the server records decides the branch. An absence of any attempt points at addressing, transport or the path to the service. Arriving packets that vanish before an ordinary exchange point at the control-channel requirements of the actual service. A named rejection points at the object it names. Replies that leave the server but never reach the client point at the return path.

An empty application log is weaker evidence than it looks. Logging starts at a certain point in the exchange, and packets discarded before that point leave no trace in the file you are reading. Where it is authorised to do so, the operator can use service and network observations to see whether anything arrived at all.

Keep the four outcomes separate in your notes. The temptation is to merge them into "server not responding", which is the phrase that sends people to change ciphers when the real problem is a firewall rule. A note that records only the word timeout has thrown away the distinction you just paid for.

Fix the stage the evidence names

A TCP connection that completes proves only that something accepted a socket. It does not prove the listener is the OpenVPN service you configured, and a web server on the same hostname answers a browser perfectly while being irrelevant to the tunnel.

If the server reports an expired revocation list, that is a far more specific fact than the client's eventual timeout, and the fix belongs to the certificate authority rather than to the network. If the two ends disagree about control-channel protection or shared material, resetting a password changes nothing, because the discard happens before any credential is examined.

Change one thing that the evidence actually supports, then repeat the same profile against the same endpoint. Preserve the first new event if the connection gets further, because that event is the next stage of the investigation rather than a new problem.

grep -nE 'TLS Error|VERIFY ERROR|CRL|handshake failed' /var/log/openvpn/server.log
date -u; timedatectl | head -3

What extending the window actually changes

Sixty seconds is the client's handshake window, and the community client reference documents the option that adjusts it. Raising it makes the client wait longer before giving up. It does not make an absent service appear and it does not make a rejected packet acceptable.

There is a legitimate use for a longer window on a slow link or a heavily loaded server, and it is worth trying once you have evidence that the exchange is progressing slowly rather than not happening. Trying it first simply delays the same diagnosis by another minute and makes the timeline harder to read. If the timeline shows an exchange that advances and then stalls, the window is a symptom of load rather than of reachability.