What a VPN handshake is, and why the first second matters

A VPN handshake is the short exchange of messages at the start of a connection in which the phone and the server prove to each other who they are and agree on the keys that will encrypt everything after. It is the only part of a VPN session that is not yet encrypted with session keys, and it is where every connection either succeeds or fails. Because a failed handshake usually produces no reply at all, the first second or two after sending it tells an app almost everything it needs to know about the network it is on.

What a handshake has to achieve

Three things, and a protocol that skips one is not safe.

1. Authenticate the server. The phone must know it is talking to the real VPN server and not something on the local network pretending to be it. Otherwise the tunnel is encrypted to the wrong party.
2. Authenticate the client. The server must know which client this is, so it can decide whether to serve it and where its traffic belongs.
3. Agree fresh session keys. Both sides derive the same secret key from values exchanged in the open, using a key exchange such as Curve25519, in a way an observer cannot reproduce. The encryption explainer covers how that works.

WireGuard's handshake

WireGuard's is the simplest of the three common protocols. The phone sends a handshake initiation: a fixed 148-byte UDP packet containing a fresh temporary public key, its own long-term identity encrypted so only the server can read it, and a timestamp. The server checks the identity against the keys it knows, and if it matches, replies with a handshake response carrying its own temporary key. Both sides now derive identical session keys, and the very next packet can carry data. One round trip, about the time of a ping.

If the identity does not match, the server sends nothing. That is deliberate: a WireGuard server never reveals its existence to a sender it does not recognise. The WireGuard explainer covers why that silence is a feature.

OpenVPN's and IKEv2's handshakes

OpenVPN runs a full TLS handshake first, in which the server presents a certificate and the two sides negotiate a cipher, then performs its own key exchange over that channel. That is several round trips and a few kilobytes, which is why OpenVPN takes noticeably longer to connect than WireGuard and costs more on every reconnect.

IKEv2 uses two exchanges. IKE_SA_INIT carries the Diffie-Hellman values and negotiates the cryptography; IKE_AUTH carries each side's identity and, usually, a certificate and signature. Because certificates are large, IKE_AUTH often has to be split across several UDP packets, and if a network drops fragments the handshake fails partway in a way that is hard to tell from a dead server.

Why silence is the hard case

Three very different problems all produce the same thing from the phone's side: nothing comes back.

• The network is dropping the packet, because it filters that port or recognises the protocol.
• The server does not know the client's key, so it deliberately does not reply.
• The server is down or unreachable.

A phone cannot tell these apart by waiting longer. What it can do is decide in advance how long a handshake deserves, send it, and move on when the budget runs out. WireGuard's is small enough that a couple of seconds on a nearby server is generous; a certificate-based IKEv2 handshake needs more. An app that waits thirty seconds on a silent UDP port before trying anything else leaves you looking at "connecting" for half a minute on every hotel network, and an app that gives up after half a second abandons servers that were about to answer.

The handshake is not the connection

A completed handshake proves the two sides can agree on keys. It does not prove that traffic will flow afterwards. Some networks let the first packets through and then throttle or drop the rest; some tunnels come up with a route or DNS problem that leaves everything inside them stalled. This is why "connected" is a weak label. The honest check is to send a real request through the tunnel, for example asking the VPN's own server what address it saw, and wait for the answer. If it arrives, the tunnel carries traffic and the address it reports is your exit IP. If it does not, the handshake succeeded and the connection still failed, which the connected-but-no-internet post covers.

Handshakes you never see

The first handshake is not the last. WireGuard performs a fresh one roughly every two minutes to rotate the session keys, and again after the phone changes address. Each is one round trip on a tunnel that is already carrying traffic, so it is invisible unless the network has quietly started dropping the port, in which case the rekey fails and the tunnel goes stale. A good app watches for that too, rather than trusting the connection it made a few minutes ago. If your VPN will not connect at all, the Android troubleshooting checklist walks through the causes in order.

Culvert VPN gives each connection method a fixed budget, WireGuard over UDP on several ports first, then a TLS transport on TCP 443, then IKEv2, and only shows a connection as up once a request through the tunnel has come back from its own server; it is on Google Play.