Why WireGuard, and the lab
Run a WireGuard server on Debian for several users, an office LAN and a branch: keys, wg-quick and systemd, AllowedIPs as routing and access control, split and full tunnels, roaming and keepalives, adding and removing users live, and the silent failures.
By the end you will be able to:
- Generate WireGuard keys and run a server as wg-quick@wg0 on Debian, with forwarding and an nftables firewall
- Explain cryptokey routing: AllowedIPs as both the routing table and the source-address check
- Route VPN users to an office LAN and a branch LAN, and control user-to-user traffic with the firewall
- Set up split and full tunnels from the client side, and explain wg-quick's policy routing
- Add and remove users without a restart, and diagnose a missing handshake, a lost private key and MTU problems
Prerequisites: Linux Network Connectivity
WireGuard is a VPN built into the Linux kernel: small, fast, and configured with little more than a list of public keys, which is why it has become the default choice for new VPNs. This lesson builds a remote-access WireGuard server on Debian for several users, a branch office and an office LAN, using the same lab and the same tasks as the OpenVPN on Debian lesson, so you can compare the two directly. Every output is from a real run.
How it differs from OpenVPN
| WireGuard | OpenVPN | |
|---|---|---|
| Identity | One key pair per device; you list public keys | Certificates from your own CA |
| Removing a user | Delete their public key: instant | Revoke, publish a CRL, restart |
| Per-user settings | One [Peer] block each, on the server | A file per user in ccd/ |
| Who gets which routes | The client's config decides | The server pushes them |
| User-to-user traffic | Always through the kernel and the firewall | Optionally inside OpenVPN (client-to-client) |
| Changing networks | Roams seamlessly | Reconnects |
| Speed and code size | In the kernel, very fast, a few thousand lines | User space, slower, much larger |
The trade-off: WireGuard has no certificates, no pushed configuration and very little logging. It's a fast, minimal tunnel, and the management around it (handing out keys and addresses, removing people) is up to you. For connecting two sites between routers, see Site-to-site VPN with WireGuard on VyOS.
The lab
Exactly the OpenVPN lab: the VPN server between the internet (203.0.113.10) and the office LAN, where the office router lanrtr is everyone's gateway; users alice, bob and carol on the internet; a branch router with its own LAN; and a web server that logs each visitor's address. The VPN's own subnet is 10.9.0.0/24, on UDP port 51820.
- Peers over the internet. alice, bob and the branch router send encrypted UDP to the VPN server's public address, 203.0.113.10, port 51820. The first packet triggers a handshake; there's no separate connect step.
- Into the office. The server decrypts alice's packet, checks its source (10.9.0.10) is in her AllowedIPs, and forwards it to the office host.
- …and the way back. The office host replies to its default gateway, lanrtr. lanrtr needs return routes for 10.9.0.0/24 and 10.20.0.0/24 via the VPN server.
- A LAN behind a peer. The branch peer's AllowedIPs on the server includes 10.20.0.0/24. That single line routes the branch LAN to its key, and accepts packets from the branch PCs.
- Full tunnel for one user. alice's own AllowedIPs is 0.0.0.0/0, so her internet traffic goes through the tunnel and leaves the VPN server NATed to 203.0.113.10. bob's still goes direct.