WireGuard and Modern VPNs
WireGuard is a deliberately minimal VPN — roughly 4,000 lines of code against IPsec's hundreds of thousands — built on the premise that simplicity is itself a security property. It uses one fixed, modern cipher suite with no negotiation, runs entirely over UDP, and is keyed on public keys the way SSH is: each peer has a key pair, and you exchange public keys to connect. There is no IKE-style handshake to mismatch and no "connection" in the stateful sense, which means there is nothing to break when an endpoint's IP changes.
The result is a VPN you can configure correctly in a dozen lines and that runs in the kernel at near line rate. Its design has reshaped the whole category: self-hosted VPNs increasingly default to it, and an entire class of mesh-overlay products — Tailscale, Netbird, and others — is built directly on the WireGuard data plane, adding the coordination it deliberately leaves out.
The Minimal Design
WireGuard's smallness is the point. A tiny codebase is auditable in an afternoon, and it has had a fraction of the CVEs of the sprawling IPsec and OpenVPN stacks. There is no cipher negotiation at all: WireGuard ships one current suite — Curve25519, ChaCha20-Poly1305, BLAKE2s — and when those need replacing, you replace the protocol version rather than negotiate per-connection. That eliminates the entire class of downgrade attacks and mismatched-proposal failures that plague IKE.
It is also silent by default. WireGuard sends no packets until there is traffic to carry and never replies to an unauthenticated packet, so a port scan finds nothing — the interface is invisible to anyone without a valid key. That stealth, plus the fixed crypto, is most of why the configuration is so short.
Peers and Cryptokey Routing
A WireGuard interface is a list of peers, each identified by a public key, and the link between key and traffic is cryptokey routing. Each peer carries an AllowedIPs setting, and that one field does two jobs at once. Outbound, it is a routing table: a packet destined for an address inside a peer's AllowedIPs is encrypted and sent to that peer. Inbound, it is an access-control list: a decrypted packet is accepted only if its source address falls within the sending peer's AllowedIPs, and dropped otherwise.
That dual role is the single most important thing to get right. Setting a peer's AllowedIPs to 0.0.0.0/0 means "route all my traffic through this peer" and "accept any source address from it" — fine for a full-tunnel client, dangerous for a peer that should only reach one subnet. Scoping it tightly is how you bound what each peer can send you and where its traffic may go.
# a minimal peer: public key, where to reach it, and what it may carry [Interface] PrivateKey = aMy...local-private-key...= Address = 10.7.0.2/32 [Peer] PublicKey = xTm...peer-public-key...= Endpoint = 203.0.113.9:51820 AllowedIPs = 10.7.0.0/24 # routing AND ACL: only this subnet, both ways
Roaming and Statelessness
WireGuard has no session to renegotiate, which is what makes roaming invisible. Every data packet is authenticated on its own, so when a peer's source IP changes — a laptop moving from Wi-Fi to LTE — the receiver simply notes the new Endpoint from the authenticated packet and keeps going. There is no handshake to redo and no "VPN dropped, reconnecting" because there was never a connection in the stateful sense to drop.
The handshake that does exist is a lightweight rekey roughly every two minutes, not a per-connection setup. A PersistentKeepalive of 25 seconds is the one knob you add for a peer behind NAT, so the NAT mapping doesn't time out while the link is idle. Without it, a peer that initiates nothing becomes unreachable once its NAT entry expires.
Mesh Overlays Built on WireGuard
WireGuard gives you a fast encrypted data plane and nothing else — no way to discover peers, distribute keys, or punch through NAT at scale. That gap is exactly what the mesh-overlay products fill. Tailscale, Netbird, and similar systems add a coordination plane: a control service that holds every node's public key, hands out the AllowedIPs map, and brokers NAT traversal so two peers behind separate routers can form a direct tunnel.
The result feels like a flat private network spanning machines anywhere, but the encryption is still plain WireGuard between the endpoints — the coordination plane never sees the traffic, only the metadata needed to connect peers. This split is why a mesh can layer identity, device approval, and access policy on top while keeping the data path as lean as raw WireGuard.
WireGuard is lean and kernel-fast: ~4,000 lines, one fixed cipher suite, UDP-only, configured in a dozen lines. It has the least to misconfigure and the highest throughput, but it does only the data plane — peer discovery and user auth are yours to add. Choose it when you control both ends and want speed and simplicity.
IPsec is the configurable-but-heavy incumbent: many ciphers, broad vendor interop, and the layer-3 standard for site-to-site, at the cost of complex IKE negotiation and awkward NAT traversal. Choose it to interoperate with existing gear that already speaks it.
OpenVPN is TLS-based and runs in userspace, often on port 443 over TCP, so it slips through restrictive firewalls that block UDP. It is slower than WireGuard but maximally firewall-friendly. Choose it for clients on hostile networks where only 443 gets out.
- Setting AllowedIPs too broadly. Because it is both routing and ACL, a careless 0.0.0.0/0 on a peer that should reach one subnet lets that peer send you packets with any source address and routes far more traffic through it than intended.
- Reusing one key pair across multiple peers. WireGuard identifies peers by public key, so shared keys make devices indistinguishable and mean revoking one compromised device revokes them all.
- Assuming WireGuard authenticates users. It authenticates keys, not people; a stolen device's key still works. Layer an identity provider or a mesh coordination plane on top for real user auth.
- Forgetting it is UDP-only. In an environment that blocks outbound UDP and allows only TCP 443, WireGuard simply can't connect, and you need a TCP-based VPN like OpenVPN instead.
- Omitting PersistentKeepalive on a NAT'd peer. With nothing keeping the mapping alive, the NAT entry expires during idle periods and the peer becomes unreachable until it initiates traffic itself.
- Scope AllowedIPs to the narrowest range each peer legitimately needs, treating it as an access-control list, so a single peer can neither route nor spoof traffic outside its remit.
- Generate a unique key pair per device and never reuse one, so each peer is individually identifiable and a single compromised key revokes only that device.
- Set PersistentKeepalive to 25 on any peer behind NAT, so the mapping stays alive and the peer remains reachable even when it sends nothing.
- Layer identity on top with a mesh coordinator (Tailscale, Netbird) or your own IdP when you need per-user auth and device approval, rather than treating WireGuard keys as identities.
- Keep a TCP-443 fallback such as OpenVPN for clients on networks that block UDP, since WireGuard's UDP-only design has no answer where only 443 is permitted.
Knowledge Check
A peer's AllowedIPs is set to 0.0.0.0/0 when it should only reach one subnet. What's the risk?
- It routes all traffic through that peer and accepts any source address from it
- It downgrades that peer to a weaker negotiated cipher across the whole wide address range
- It forces a full handshake renegotiation on every packet
- It silently converts the tunnel from UDP to TCP
A WireGuard laptop moves from Wi-Fi to LTE and keeps working with no reconnect. Why?
- A stateful session is migrated intact to the new network
- Each packet is authenticated on its own, so the receiver updates the peer's endpoint
- A TCP keepalive holds the connection open across the change
- A central coordination server reroutes the existing session to the laptop's new IP address for it
What do mesh overlays like Tailscale add that plain WireGuard does not provide?
- A stronger encryption algorithm than WireGuard's default
- Faster packet throughput than the raw WireGuard data path
- A coordination plane for peer discovery, key distribution, and NAT traversal
- A central relay that decrypts and inspects all of the traffic on the way through
You got correct