WireGuard is a layer 3 VPN protocol that creates encrypted tunnels over UDP between peers identified by Curve25519 public keys. In network security, it is known for a deliberately small codebase, a single fixed cryptographic suite and configuration that fits on a few lines.
It runs in the Linux kernel since version 5.6 and as user-space or native implementations on Windows, macOS, BSD, Android and iOS. Unlike older VPN designs, it has no cipher negotiation: every peer speaks the same protocol version with the same algorithms.
How WireGuard builds a tunnel
WireGuard builds a tunnel by giving each host a virtual network interface, typically named wg0, with a private key, a listening UDP port and a list of peers. Each peer entry holds the peer’s public key, an optional endpoint address and a list of AllowedIPs.
The handshake follows the Noise_IK pattern from the Noise protocol framework. It takes one round trip, derives fresh session keys and is repeated about every two minutes, which provides perfect forward secrecy. An optional preshared key adds a symmetric layer intended as a hedge against future quantum attacks on the key exchange.
The fixed cryptographic suite is summarized below. Because these choices are not negotiable, a weakness in any one of them would require a new protocol version rather than a configuration change.
| Function | Algorithm | Role in the protocol |
|---|---|---|
| Key exchange | Curve25519 (X25519) | Elliptic-curve Diffie-Hellman between peers |
| Authenticated encryption | ChaCha20-Poly1305 | Encrypts and authenticates every data packet |
| Hashing | BLAKE2s | Hashing and keyed hashing in the handshake |
| Key derivation | HKDF | Derives session keys from handshake secrets |
| Hashtable keys | SipHash24 | Protects internal lookups against flooding |
Cryptokey routing and AllowedIPs
Cryptokey routing is the rule that ties every inner IP address to exactly one peer public key. On the outgoing side, AllowedIPs acts as a routing table: a packet for 10.8.0.5 is encrypted to the peer that lists 10.8.0.5/32. On the incoming side, it acts as an access control list: a decrypted packet is dropped if its source address is not in that peer’s AllowedIPs.
This design means that the authenticated identity of a packet is always its public key, never just its source address. Setting AllowedIPs to 0.0.0.0/0 on a client sends all traffic through the tunnel, which is the usual full-tunnel configuration.
WireGuard compared with IPsec and OpenVPN
WireGuard differs from IPsec and OpenVPN mainly in simplicity and agility. It trades flexibility for a small attack surface, while the older protocols support many ciphers, authentication methods and enterprise integrations.
| Aspect | WireGuard | IPsec with IKEv2 | OpenVPN |
|---|---|---|---|
| Transport | UDP only | ESP, UDP 500 and 4500 | UDP or TCP |
| Cipher choice | Fixed suite | Negotiated | Negotiated |
| Authentication | Public keys | Certificates, PSK, EAP | Certificates, user credentials |
| Code size | About 4,000 lines in the kernel | Large, spread over several components | Large user-space program |
| Roaming | Built in | Through MOBIKE | Reconnect required |
| Interoperability | WireGuard peers only | Broad vendor support | OpenVPN peers only |
In practice, IPsec remains common for site-to-site links between firewalls from different vendors, while WireGuard is popular for remote access, cloud overlays and links between Linux hosts where both ends are under one administrator.
Key configuration parameters
A working WireGuard setup needs only a few parameters per interface and per peer. The table lists the ones that most often matter and their typical values.
| Parameter | Scope | Typical value | Effect |
|---|---|---|---|
| ListenPort | Interface | 51820 by convention | UDP port for incoming handshakes |
| MTU | Interface | 1420 by default, 1280 to 1420 | Leaves room for the 60 to 80 byte overhead |
| Endpoint | Peer | Public IP and port | Where to send packets; updated on roaming |
| AllowedIPs | Peer | /32 per client or 0.0.0.0/0 | Routing and source filtering |
| PersistentKeepalive | Peer | 25 seconds behind NAT | Keeps NAT mappings open |
WireGuard is silent by design: it sends nothing unless there is data or a keepalive, and it does not answer unauthenticated packets. This makes the listening port hard to detect by scanning, but it also means a misconfigured peer produces no error message, only an absent handshake.
Limitations and common mistakes
WireGuard is a tunnel primitive, not a complete VPN product. Features that enterprise VPNs provide out of the box must be added by surrounding tooling.
- No dynamic address assignment: inner addresses are set statically or by a management layer.
- No user authentication: there are no passwords or certificates, so key distribution and revocation are manual unless automated.
- Static key storage: the server stores each peer’s public key and last endpoint in memory, which is a privacy concern some providers address with key rotation.
- UDP only: networks that block UDP need an extra wrapper, which adds latency.
- Overlapping AllowedIPs: assigning the same prefix to two peers silently moves the route to the last one configured.
Most failed deployments trace back to MTU problems or missing firewall and forwarding rules. A tunnel that handshakes but stalls on large transfers usually needs a lower MTU or MSS clamping on the router.
Stripped to the essentials
WireGuard is a way to build a private, locked corridor across the internet between two computers. Each side has a key pair, much like a lock and a matching key, and the two sides only talk to each other after proving they hold the right keys.
What makes it stand out is that it is small and uses one well-chosen set of locks instead of dozens of options. Fewer moving parts mean fewer things to misconfigure and a corridor that is quick to set up.
Where it is applied
A company with a web application in a public cloud needs its developers to reach internal databases that have no public address. The operations team runs a small Linux virtual machine as a WireGuard gateway listening on UDP 51820, with the tunnel subnet 10.8.0.0/24.
Each developer laptop receives one /32 address and the gateway public key; its AllowedIPs list only the internal subnets, so ordinary web traffic stays outside the tunnel. Developers working from hotel networks keep a PersistentKeepalive of 25 seconds to hold the NAT mapping open. When one employee left, revoking access took a single step: removing that public key from the gateway, after which the laptop could no longer complete a handshake.