VPN Handshake Steps: What Happens Before Traffic Flows

Pressing Connect starts four separate jobs that succeed or fail independently. The client has to reach a listener, agree on who the peer is, derive keys, and then hand a working tunnel to the rest of the system. Most failed connections are diagnosed in the wrong job. That is why the first error matters more than the third retry.

Reach the Listener First

Before any identity is exchanged, the client resolves a name, chooses a route and opens a transport to a port. A captive portal that answers everything, a closed port and a wrong hostname all fail here, and none of them is an authentication problem. Changing a password cannot fix any of the three. Read the first line of the error before touching credentials.

A timeout, a certificate rejection and a rejected account are three different faults with three different checks. Sorting them first is what keeps a network problem from being debugged as a credential problem.

Prove the Peer, Then Derive Keys

Every protocol needs a way to recognise the intended server, whether through a configured public key or a certificate chain. A user login is additional to that check, not a replacement for it. A server that accepts your password has proved nothing about its own identity. That is why a shared secret typed into a client is not a substitute for verifying what answered.

The exchange then derives traffic keys from the protocol's own inputs, and the login password is generally not the key stamped onto each packet. Long-term identity material and short-lived session keys have different lifetimes and different jobs. That separation is what forward secrecy is about.

Keep verification enabled while troubleshooting, because a tunnel that connects after you disable a check has demonstrated nothing except that the check was doing something. Note what you changed, and put it back before the next test.

Three Protocols, Three Conversations

In a TLS-based OpenVPN deployment the control channel negotiates security parameters while the data channel carries tunnel traffic, so a data-channel option and a certificate problem live in different places. IKEv2 authenticates both participants and then establishes IPsec security associations with their own lifetimes. WireGuard derives keys through its Noise-based exchange and keeps the state machine deliberately small. Knowing which of the three you run decides which log is worth reading.

Similar-looking clients do not imply interchangeable messages underneath, and a configuration field that exists in one product may have no counterpart in another. Copying a profile between them is a guess rather than a migration.

What the Handshake Does Not Do

Routes, name resolution and destination policy all remain afterwards. An internal site can stay unreachable because its subnet route is missing, even though the peer was authenticated correctly and the tunnel is up. Treating that as weak encryption sends you looking in the wrong layer, and it usually ends with a cipher change that fixes nothing.

Key refresh and reconnection also look alike in most status displays, and neither tells you whether ordinary traffic was blocked during the outage. Only the client's failure policy answers that question, so read the policy rather than the icon.

Work the stages in the order above and stop at the first one that produces an error. Every later stage inherits the state of the earlier ones, so a failure at the third stage says nothing about the fourth.

ip -brief address show tun0
ip route get 10.60.7.15
resolvectl query intranet.corp.internal