05 Module · Why WireGuard
Small enough to
read in full.
A VPN implemented in a few thousand lines of kernel code. A peer is a public key and an IP range, and there is no cipher negotiation because there is only one suite.
- In mainline Linux since
- 5.6 (2020)
- Core implementation
- A few thousand lines
- Cipher choice
- None, one fixed suite
- Licence
- GPL v2
In a VPN, whether anyone has read the code matters more for security than which ciphers it supports.
The previous generation of VPN software is enormous: hundreds of thousands of lines, decades of accumulated options, negotiation code for algorithms nobody should still be using, and so many settings that two competent engineers can disagree about what a config file does.
Each of those lines can hide a flaw, and the published history of that software includes a long list of flaws that went unnoticed for years.
WireGuard is small instead. It has one cipher suite, chosen by the authors, with no negotiation, so a downgrade attack has nothing to work on. Peers are identified by public key, as in SSH. It runs in the kernel and is short enough that reviewing all of it is realistic.
Argumenten · The case
Seven reasons,
in order of how often they matter.
Ranked by what your engineers and the rest of your staff notice, which are two different lists.
01 Roaming 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. For most staff this is the only thing they 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
There is one fixed, modern suite. Nobody can misconfigure it or leave a legacy algorithm enabled through an old default, and a downgrade attack has nothing to downgrade to.
04 Fast enough to forget about
Running in the kernel with a short code path, it saturates ordinary links with modest CPU. When the VPN is no longer the bottleneck, people stop turning it off, and that matters more for security than for performance.
05 Keys behave like SSH keys
You generate a key pair, distribute the public half and remove a line to revoke it. There is no certificate authority, no certificate expiring unexpectedly at three in the morning, and no second PKI to run alongside the one you already have.
06 It is silent to scanners
An interface with no valid key material for the sender does not reply. The port does not announce itself, which removes a category of background noise from your logs.
07 No appliance, no support contract
It is in mainline Linux and the NixOS module set, and it runs on every phone platform. There is no box to buy or renew, or to discover during an audit has reached end of life.
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 | Tunnel stays up |
| 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, which is the downside |
Nackdelar · The downsides
When WireGuard is not enough on its own.
WireGuard is a tunnel and nothing else. Several things you may expect from a VPN product are out of scope by design.
- There is no user management: no portal, no groups and no per-user policy, only peers. For a fleet of laptops you need something on top, and we build that with automation and your directory.
- Key distribution is your problem, so onboarding and offboarding must be a real process. That is less work than running a certificate authority, but still some work.
- There is no native multi-factor authentication; possession of the key is the credential. Where a second factor is required, put it on the services behind the tunnel rather than on the tunnel itself.
- Peer IPs are visible on the server, because the design keeps each peer's last known endpoint. That is fine for corporate use, but worth knowing if your threat model involves hiding from the operator.
- Hub-and-spoke needs designing. A full mesh works well at ten peers and is unmanageable at three hundred. Choosing the topology is most of what we are paid for here.
None of these is a reason to keep an IPsec appliance. They mean treating WireGuard as the transport and planning the operational layer around it properly.