05 Module · Why WireGuard
Small enough to have
actually been read.
A VPN whose entire implementation fits in a few thousand lines of kernel code, where a peer is a public key and an IP range, and where there is no cipher negotiation because there is nothing to negotiate.
- In mainline Linux since
- 5.6 (2020)
- Core implementation
- A few thousand lines
- Cipher choice
- None — one suite
- Licence
- GPL v2
The security property that matters most in a VPN is not which ciphers it supports. It is whether anyone has read it.
The previous generation of VPN software is enormous. Hundreds of thousands of lines, decades of accumulated options, negotiation machinery for algorithms nobody should still be using, and a configuration surface large enough that two competent engineers can disagree about what a config file does.
Every one of those lines is a place for a flaw to hide, and the published history of that software is a long list of flaws that hid successfully for years.
WireGuard's answer is to be small. One cipher suite, chosen by the authors, with no negotiation — so downgrade attacks have nothing to grip. Peers are identified by public key, the way SSH does it. The whole thing runs in the kernel, and it is short enough that reviewing it is a realistic exercise rather than a figure of speech.
Argumenten · The case
Seven reasons,
in order of how often they matter.
Ranked by what your engineers and your staff actually notice, which are two different lists.
01 Roaming just works
A laptop moving from office wifi to a train to a hotel keeps its tunnel without reconnecting, because the protocol is connectionless and identifies peers by key rather than by address. This is the single thing staff notice.
02 The config fits on a postcard
An interface, a private key, and a list of peers with their public keys and allowed IP ranges. A new engineer understands the whole topology in one sitting, which is not true of the alternatives.
03 No cipher negotiation
One modern suite, fixed. Nothing to misconfigure, no legacy algorithm left enabled by an old default, and no downgrade attack — because there is nothing to downgrade to.
04 It is fast enough to forget
Running in the kernel with a short code path, it saturates ordinary links with modest CPU. When the VPN stops being the bottleneck, people stop turning it off — which is a security outcome, not a performance one.
05 Keys behave like SSH keys
Generate, distribute the public half, remove a line to revoke. No certificate authority, no expiry surprises at three in the morning, no PKI to run alongside the PKI you already run.
06 It is silent to scanners
An interface with no valid key material for the sender simply does not reply. The port does not announce itself, which removes a whole category of background noise from your logs.
07 No appliance, no support contract
It is in mainline Linux, it is in the NixOS module set, and it is on every phone platform. There is no box to buy, renew, or discover has reached end of life during an audit.
Jämförelse · Side by side
Against the incumbents
Compared with the IPsec appliance or OpenVPN install we usually find in place.
| Concern | IPsec / OpenVPN | WireGuard |
|---|---|---|
| Code to audit | Hundreds of thousands of lines | A few thousand |
| Cipher configuration | Negotiated, with legacy options | One fixed suite |
| Identity | Certificates and a CA to run | A public key, like SSH |
| Config file | Pages, and easy to get subtly wrong | A dozen lines |
| Roaming between networks | Reconnect, often visibly | Seamless |
| Throughput | Frequently the bottleneck | Rarely the bottleneck |
| Where it runs | Userspace daemon or appliance | Mainline kernel |
| Revoking a device | CRL, and hope it propagates | Delete a peer stanza |
| Built-in user management | Yes, in commercial products | None — the honest gap |
Ärligt talat · Honestly
When WireGuard is not enough on its own.
WireGuard is deliberately a tunnel and nothing else. Several things you may expect from a VPN product are simply out of scope, by design.
- There is no user management. No portal, no groups, no per-user policy — just peers. For a fleet of laptops you need something on top, and we build that with automation and your directory rather than pretending the gap is not there.
- Key distribution is your problem. Onboarding and offboarding must be a real process. It is a smaller problem than running a certificate authority, but it is not nothing.
- No native multi-factor authentication. Possession of the key is the credential. Where a second factor is required, it belongs at the services behind the tunnel, not at the tunnel.
- Peer IPs are visible on the server. The design keeps a peer's last known endpoint. Fine for corporate use, worth knowing if your threat model is about hiding from the operator.
- Hub-and-spoke needs designing. A full mesh is elegant at ten peers and unmanageable at three hundred. That is a topology decision, and it is most of what we are actually paid for here.
None of these are reasons to keep an IPsec appliance. They are reasons to treat WireGuard as the transport and to build the operational layer around it deliberately.