How WireGuard Handshakes Work: A Simple Explanation

WireGuard has a reputation for being cryptic: tiny codebase, terse docs, config files that look deceptively simple until something breaks. The WireGuard handshake is the part most worth understanding, because once you get it, half of all WireGuard troubleshooting becomes obvious. No math degree required: here's how the WireGuard handshake works, in plain language.

The 1-RTT Handshake, in Plain Language

When two WireGuard peers want to talk, they need to agree on encryption keys without anyone eavesdropping. The handshake does this in a single round trip (1-RTT): one message out, one message back, done. Compare that to older protocols that need several back-and-forth exchanges, and you start to see why WireGuard connects so fast.

In everyday terms, the exchange goes like this:

1. The initiator says hello, cryptographically. It sends a handshake initiation message containing its identity (derived from its public key), a timestamp, and some encrypted material. Everything is structured so that only the intended recipient can make sense of it; to anyone else it's noise.
2. The responder answers. It verifies the initiator, then replies with a handshake response containing its own cryptographic material. At this point both sides can compute the same shared session keys independently. Neither side ever transmitted the actual keys: that's the elegant part.
3. Both sides confirm with data. The first real data packets (often just keepalives) act as confirmation. After that, the session is live and data flows, encrypted with keys that get rotated periodically without another full handshake.

A few properties fall out of this design that matter for travelers:

• It's fast. One round trip means the tunnel is up in milliseconds on a decent connection. Walking out of a dead zone, your tunnel is back before you've noticed it was gone.
• It's quiet. After the handshake, an idle tunnel sends nothing. No chatter, no keepalive theater. A phone in your pocket with an idle WireGuard tunnel is silent on the radio, which is part of why the battery impact is so low.
• There's no "connection" to drop. WireGuard is stateless: there's no session object on either side that can time out. If packets stop arriving, nothing "disconnects." When packets resume, possibly from a new IP after you've switched networks, the receiver just updates its endpoint and carries on. Roaming isn't a feature bolted on; it's a consequence of the design.

Why Handshakes Repeat (and What PersistentKeepalive Changes)

If the design is stateless and quiet, why do handshakes happen more than once? A few reasons:

• Key rotation. Session keys expire after a couple of minutes of use and the peers silently negotiate fresh ones. This is normal, healthy, and invisible. Rekeying isn't a "reconnect"; it's maintenance.
• Silence timeout. If a peer hears nothing for a while (around three minutes by default), it considers the session stale and the next packet triggers a fresh handshake. Also normal.
• NAT sessions expiring. Here's the one that bites travelers. The NAT mapping on the hotel router or carrier gateway that lets return packets reach you has its own timeout, often much shorter than WireGuard's. When it expires, inbound packets stop arriving. Your side doesn't know; it just looks like silence. Then your next outbound packet triggers a handshake and everything resumes. From your perspective: a mysterious few-seconds stall every so often.
• Network changes. New IP from switching WiFi to cellular? The next packet re-establishes the path. Usually seamless.

PersistentKeepalive exists for the NAT problem. It's a setting (on the client, typically your travel router or phone) that says "send a tiny packet every N seconds even when idle." That chatter keeps the NAT mapping alive through quiet periods, so return packets keep flowing and the tunnel never goes stale. The standard value is 25 seconds: frequent enough for almost all NATs, cheap enough to be negligible in bandwidth and battery.

When to touch it: if your tunnel stalls after idle periods on specific networks (hotel WiFi is the classic), and 25 seconds doesn't fix it, try shorter intervals. If everything works, leave it alone. More keepalives than necessary just burn a little battery and bandwidth for no benefit.

What Failed Handshakes Tell You When Troubleshooting

Handshake failures are WireGuard's way of telling you exactly what's wrong, if you know how to read them. The symptom is always the same (no traffic flows), but the pattern of handshake attempts points at the cause:

• No handshake response ever arrives. Your initiation packets are leaving but nothing comes back. Suspects, in order: wrong endpoint address or port, server firewall blocking the UDP port, server not running, or your ISP/carrier blocking the traffic. Check the basics first: can you even reach the server's IP?
• Handshake starts but never completes. Initiation goes out, a response comes back, but data never flows. This smells like a key mismatch (wrong peer public key on one side), mismatched pre-shared keys if you use them, or clock skew: WireGuard rejects handshakes with timestamps too far off, so a device with a wildly wrong clock fails mysteriously. Check the time.
• Handshake succeeds, then traffic dies after a while. The tunnel establishes fine but stalls during idle periods. That's the NAT expiry pattern: add or shorten PersistentKeepalive. If it happens only on one network, that network's NAT timeout is aggressive.
• Handshake succeeds but only in one direction. You can reach the server, but return traffic never arrives (or vice versa). Look at AllowedIPs on both sides: the most common cause is a misconfigured AllowedIPs that doesn't include the addresses you're trying to reach. Second suspect: a firewall on the server dropping forwarded packets.
• Intermittent handshake failures that resolve themselves. Usually network-level: packet loss, brief outages, switching networks. WireGuard retries on its own; if it always recovers within seconds, that's the protocol working as designed, not a bug.

The meta-lesson: WireGuard's simplicity means the failure modes are few and legible. Endpoint wrong, keys wrong, clock wrong, NAT expired, firewall in the way. That list covers nearly everything you'll ever see. When something breaks, work it in that order instead of randomly changing settings, and you'll find it fast.

FAQ

Need Help Setting This Up?

Handshake failures are one of those problems that's a five-minute fix when you've seen it before and a lost afternoon when you haven't. If your tunnel isn't behaving and you'd like someone who's debugged hundreds of them to take a look, our VPN audit covers exactly this: https://homeipvpn.com.