WireGuard is a VPN protocol that’s so simple, it fits in under 4,000 lines of code, yet it achieves speeds that often embarrass older, more complex VPNs.
Let’s see it in action. Imagine you have a WireGuard server running on a Linode instance and a client on your laptop.
Server (wg0.conf):
[Interface]
PrivateKey = <server_private_key>
ListenPort = 51820
Address = 10.0.0.1/24
[Peer]
PublicKey = <client_public_key>
AllowedIPs = 10.0.0.2/32
Client (wg0.conf):
[Interface]
PrivateKey = <client_private_key>
Address = 10.0.0.2/24
[Peer]
PublicKey = <server_public_key>
Endpoint = <server_ip>:51820
AllowedIPs = 10.0.0.1/24
When the client wants to send traffic to the server (e.g., ping 10.0.0.1), it encrypts the packet using the server’s public key and sends it to the server’s IP and port. The server, using its private key, decrypts the packet. The AllowedIPs setting dictates which IP addresses are considered "internal" to the VPN and should be routed through the tunnel, and which source IP addresses are permitted from a given peer.
WireGuard achieves its speed primarily through its minimalist design and use of modern cryptographic primitives. Unlike OpenVPN, which often relies on OpenSSL and a host of configuration options, WireGuard bundles its cryptographic operations directly into the kernel (or a user-space equivalent). This means fewer context switches between user space and kernel space, a major bottleneck in traditional VPNs. It also uses performant algorithms like ChaCha20 for symmetric encryption and Poly1305 for authentication, which are significantly faster on modern CPUs than the AES-CBC/HMAC combinations often seen in older protocols. The fixed header size and streamlined handshake also contribute to lower latency and higher throughput.
The magic of AllowedIPs is that it’s not just about routing; it’s also about defining the "identity" of a peer. When a packet arrives at the server from a specific IP address, the server checks if that IP is listed in the AllowedIPs of any of its configured peers. If it is, and the packet’s source IP matches the IP configured for that peer in the server’s interface, it’s accepted and decrypted. This tight coupling of IP routing and peer authentication is key to WireGuard’s efficiency and security. You don’t have separate systems for "who is allowed to connect" and "where should traffic go"; it’s all managed by AllowedIPs.
Most people understand that WireGuard uses modern crypto for speed, but they often miss how the Endpoint and AllowedIPs on the client side work together to create a full tunnel or split tunnel. If you set AllowedIPs = 0.0.0.0/0, ::/0 on your client, all your internet traffic is routed through the WireGuard tunnel to the server, and then out to the internet from the server’s IP. This is a full tunnel. However, if you set AllowedIPs = 10.0.0.1/32 (the server’s VPN IP) and 192.168.1.0/24 (your home network), only traffic destined for the VPN server or your home network goes through the tunnel. All other internet traffic bypasses WireGuard, giving you the best of both worlds: secure access to internal resources and fast, direct internet browsing.
The next step is exploring how to manage multiple peers and dynamic IP addresses with WireGuard.