What WireGuard is, and why it connects instantly

Strip away the branding and a WireGuard tunnel is a network interface on your device, in the same family as Wi-Fi or Ethernet. Programs do not talk to it, negotiate with it, or know it exists. They send packets to an address; the operating system decides those packets belong to the tunnel interface; the interface encrypts each one, wraps it inside a UDP packet addressed to the far end, and sends it out over whatever ordinary network you happen to be sitting on.

The interface keeps a short list of peers, and that list is where WireGuard's most distinctive idea lives. Each peer is a public key, and each public key is paired with the range of addresses it is permitted to use. The pairing does two jobs at once: it decides where an outgoing packet should go, and it decides whether an incoming packet is allowed to claim the source address written on it. The project calls this cryptokey routing.

Older tunnelling software typically ran as a user-space daemon: an ordinary program that the kernel handed packets to, which performed the cryptography and handed the result back. Every packet therefore crossed the boundary between kernel and program twice, and that boundary is not free. It costs a context switch and a copy in each direction, paid again for every packet, in both directions, forever.

WireGuard was written as kernel code, so on a Linux host the packet never makes that trip. Encryption happens on the path the packet is already travelling, with no copy out to a separate program and no copy back. What that buys is CPU time per packet rather than a headline speed figure, and spending less of it is the unglamorous reason the protocol tends to feel light rather than merely quick.

The caveat deserves stating plainly, because it is usually glossed over. Apple does not let an app install kernel code, so on iPhone, iPad and Mac the tunnel runs inside a Network Extension, a separate system-provided process, and the packets do cross a process boundary after all. Android goes through VpnService, using the in-kernel implementation where the device's kernel has one and a userspace implementation where it does not. The architectural saving is therefore largest on a Linux machine with the module available and smaller everywhere else. The protocol, the handshake and the key handling are identical in every case, which is why a phone and a server interoperate without either one knowing which implementation the other is running.

The security argument usually made for WireGuard is not that its mathematics is exotic. The primitives it uses are well known and widely deployed elsewhere. The argument is about volume: the project puts its core implementation at a few thousand lines, against the hundreds of thousands reached by older tunnelling stacks once their options, legacy modes and configuration machinery are counted. Those are the project's own figures and the exact count depends on what you agree to include, but the order of magnitude is not seriously disputed.

That gap is not an aesthetic preference. Bugs hide in code nobody has read, and nobody reads a hundred thousand lines carefully. A few thousand lines is a weekend for an experienced reviewer, which means the code can be examined by people outside the project rather than trusted on reputation. Reviewability is the property being claimed, and it is worth stating precisely, because it is a more modest claim than it sounds: code that is easier to check is not the same as code proven correct.

It is also worth knowing where the smallness comes from. It is not cleverness, it is subtraction. Every option the protocol declines to offer is code that does not exist, and code that does not exist cannot be wrong, misconfigured or exploited.

Bringing a tunnel up means two machines agreeing on keys. WireGuard does it in a single round trip, using a fixed handshake pattern borrowed from the Noise framework: your device sends a 148-byte initiation message, the far end answers with 92 bytes, and your side can send real traffic the moment that answer lands, because the answer is itself the proof that the handshake worked. There is no separate phase for agreeing on algorithms and no certificate chain to validate, which is the direct reason connecting feels instantaneous rather than like something you wait for.

One detail the short version leaves out: the far end is not allowed to send data first. It has to wait until it has received an authenticated data packet from the side that started the handshake, which is what confirms the new keys are genuinely in use rather than replayed from an older conversation. In practice your device always has something to send, so the wait is invisible. It is, however, the reason a server cannot nudge a device that has gone silent and moved: until the device speaks, the far end has nowhere to speak to.

After that, the tunnel is not a connection in the way a phone call is a connection. There is no session held open and nothing to tear down. Each side holds current keys for the other and sends UDP packets when it has something to send; when nothing is being sent, nothing travels. Keys are then replaced on a timer rather than on request: after roughly two minutes of use a fresh handshake runs in the background while the existing keys are still valid, keys older than about three minutes are refused outright, and an initiation that gets no answer is simply retried every few seconds. Rotation is invisible, and a stale key cannot be used indefinitely.

Silence has one practical cost. Because an idle tunnel really does send nothing, a home router or mobile carrier can forget the address mapping it was holding for you, and an incoming packet then has nowhere to land. The protocol's answer is an optional keepalive: a peer can be told to send one small authenticated packet every 25 seconds, which costs almost nothing and holds the path open. It is a configuration setting rather than part of the handshake, and it is the only case in which a WireGuard tunnel sends traffic nobody asked it for.

Roaming falls out of all this rather than being bolted on, which is why a phone that moves from Wi-Fi to cellular resumes instead of reconnecting. When the network changes your public address and port change, but your key does not. The first authenticated packet arriving at the far end from the new address is enough: the recorded endpoint for that key is updated and the tunnel carries on where it left off, with nothing renegotiated, because there was never a negotiation to repeat. Two qualifications keep that honest. Your device has to send that first packet, so the far end learns the new address from you rather than noticing by itself, and if the phone slept long enough for the keys to age out, a fresh handshake runs — still one exchange, not a reconnection sequence.

A related consequence is how an endpoint treats traffic it cannot verify: it ignores it. Every handshake message carries an authentication code computed with the recipient's public key, and anything failing that check is dropped with no reply at all, so a listener does not answer a scan that does not already know what it is looking for. Under enough load to care, it still declines to trust the sender's return address: instead of doing the expensive cryptography it replies with a cookie the sender must echo back, which proves the address is really theirs before any real work is spent on them.

The generation of tunnelling protocols that came before WireGuard were built to accommodate. They were standardised by committee, had to work between equipment from vendors who disagreed with each other, and had to keep working as cryptography advanced over decades. The sensible answer in that world is negotiation: both ends arrive with a list of ciphers, authentication methods and modes they support, and they talk until they find something in common.

Negotiation solves a genuine problem and creates its own. A protocol that can agree on anything must be able to agree on something weak, and an attacker able to influence that conversation may be able to steer it toward the feeblest option both ends will still accept, a class of problem known as downgrade. The negotiation itself also has to be specified, implemented, configured and understood, which means more code, more decisions handed to whoever deploys it, and more ways for a tunnel to be technically up while being set up badly.

WireGuard takes the opposite position: there is no negotiation, because there is nothing to negotiate. Curve25519 for key agreement, ChaCha20 with Poly1305 for encryption and authentication, BLAKE2s for hashing, fixed for everybody. Downgrade is not defended against so much as absent, since the protocol contains no weaker alternative to be steered toward and no cipher choice for an administrator to get wrong.

The cost is real and the project is open about it. If one of those primitives ever needs replacing, you do not renegotiate, you ship a new version of the protocol and both ends move to it. Flexibility is pushed out of the handshake and into versioning, which is slower and more disruptive when that day comes. The bet is that one well-chosen way of working, replaced wholesale when it must be, goes wrong less often than a protocol that can be talked into a bad state on an ordinary Tuesday.

A design this decided has edges, and knowing where they are saves an afternoon when something behaves oddly. The first is transport. WireGuard is UDP, and only UDP: there is no TCP mode in the protocol, partly because carrying a reliable stream inside another reliable stream makes both of them worse under loss. A network that forwards only TCP therefore cannot carry the handshake at all, and the failure is quiet from your side — the initiation goes out, nothing comes back, and there is no error to read, because an error would have to come from the far end that never heard you.

The second is packet size. Wrapping a packet costs 60 bytes of header and authentication tag on an IPv4 path and 80 on IPv6, so the tunnel interface has to advertise a smaller maximum packet size than the network underneath it, and 1420 bytes is the common default. Where the real path is smaller still, which happens on some mobile networks and on anything adding another layer of encapsulation, you get a recognisable signature: short requests succeed, pages load halfway, and large transfers stall rather than fail. Lowering the tunnel's MTU is the fix, and nothing else looks wrong while it is happening.

The third is that the private key on a device is the entirety of that device's identity. There is no password to rotate and no second factor inside the protocol; whoever holds the key is that peer, for as long as the far end keeps listing it. That is why the key pair should be generated on the device and the private half should never leave it, and why revoking access is work for the service around the protocol — removing a peer from the far end's list — rather than anything the protocol does by itself.

WireGuard is deliberately incomplete. It authenticates and moves packets between keys it has already been told about, and it stops there. Everything needed to turn that into something a person can actually use is someone else's job, and those jobs are worth naming, because they are where one provider differs from another in ways the protocol cannot.

One boundary is worth stating precisely, because WireGuard is often credited with more than it claims. It secures the hop between your device and the peer at the far end, and that is the whole of its promise: on the network you are sitting on, the contents and destinations of your packets are unreadable, and nothing can be injected into the tunnel without the key. That is a real guarantee and it is the one most people actually want on a shared network.

What happens to a packet after it leaves that far end and continues to the open internet is not a protocol question at all. The cryptography has finished by then. Whether traffic is recorded, what is kept, for how long and under what circumstances are properties of whoever runs the server, and no amount of reading the specification will tell you. The protocol is a floor you can verify rather than an answer to that question.

The useful way to read this is as a division of labour. Judge the protocol on what it is: a small, fixed, reviewable design with no negotiation to go wrong. Judge the app on whether it generates keys on the device, keeps the private half there, reconnects reliably and gets out of the way. Judge the service on how it is run and what it commits to in writing. WireGuard settles the first of those three and is silent on the other two, and a page that tells you otherwise is selling a protocol as if it were a provider.