senn-techWireGuard: VPN for Everyday Use
VPN is no longer a niche topic. Remote workstation, site interconnection, access to internal services — every organization needs this. WireGuard makes it simpler than VPN has ever been.
Why WireGuard?
WireGuard is 4,000 lines of code — against IPsec's hundreds of thousands. It runs in the kernel, requires no certificate infrastructure, no IKE handshake theater. A key pair, a config file, done.
# Generate key pair
wg genkey | tee privatekey | wg pubkey > publickey
# /etc/wireguard/wg0.conf
[Interface]
PrivateKey = <...>
Address = 10.10.0.1/24
ListenPort = 51820
[Peer]
PublicKey = <...>
AllowedIPs = 10.10.0.2/32, 192.168.181.0/24
This is the entire site-to-site configuration between Kufstein and the Hetzner root server. No connection setup, no negotiation — the tunnels are there as soon as the interfaces are up.
Site-to-Site: Sites Like a Network
Two sites, one VPN tunnel, and both sides can reach each other as if they were on the same VLAN. We use this:
- Kufstein → Hetzner: Proxmox backup traffic runs over WireGuard, encrypted, without an additional authentication layer
- Kufstein → Customer site: Access to their monitoring, logging, helpdesk — without port forwarding on their firewall
Road-Warrior: A Mobile Client, One Entry
Laptop, phone, tablet — WireGuard clients exist for everything. One peer entry per device, and the employee is on the internal network, no matter where.
# Client-side
[Interface]
PrivateKey = <...>
Address = 10.10.0.10/32
[Peer]
PublicKey = <server-key>
Endpoint = vpn.senn-tech.com:51820
AllowedIPs = 192.168.181.0/24
PersistentKeepalive = 25
PersistentKeepalive = 25 is not a detail but a necessity for clients behind NAT (practically every laptop on hotel Wi-Fi): Without regular keepalive packets, the NAT router closes the UDP mapping, and the return path to the client is dead. In tunnel-in-tunnel scenarios, it’s also worth checking the MTU (often 1420), otherwise large packets founder on fragmentation.
Many Clients? A Management Layer
One peer entry per device is charming with five employees, tedious with fifty. Tools like wg-easy, wg-portal, or Firezone add a management layer over WireGuard — peers, QR codes for phones, and expiration dates included, without giving up the kernel advantage.
WireGuard vs. OpenVPN vs. IPsec
| Criterion | WireGuard | OpenVPN | IPsec |
|---|---|---|---|
| Complexity | Minimal | Medium | High |
| Performance | Kernel, very fast | Userspace, good | Kernel, fast |
| Roaming | Transparent | Cumbersome | Rare |
| Auditability | Excellent (small codebase) | Good | Difficult |
Security: The Simplicity Principle
WireGuard has no options for insecure ciphers. There is no "wrong algorithm" to choose, because there is no choice. Curve25519, ChaCha20, Poly1305 — these are the only primitives, and that is sufficient.
Conclusion
WireGuard replaces IPsec and OpenVPN for all SME VPN purposes. No configuration orgies, no certificate problems, no connection roulette. A key pair, a config — then the tunnel is there.
Is WireGuard secure enough without selectable ciphers and certificates?+
Precisely because there's no choice. WireGuard offers no options for insecure ciphers — Curve25519, ChaCha20, and Poly1305 are the only primitives, and that's sufficient. There's no "wrong algorithm" to pick. On top of that, it's only about 4,000 lines of code against IPsec's hundreds of thousands, which greatly improves auditability.
Doesn't management get tedious with many employees?+
One peer entry per device is charming with five employees, tedious with fifty. That's what management layers like wg-easy, wg-portal, or Firezone are for: you create peers, generate QR codes for phones, and set expiration dates — without giving up WireGuard's kernel advantage.
Why does the connection drop from hotel Wi-Fi?+
Clients behind NAT — practically every laptop on hotel Wi-Fi — need PersistentKeepalive = 25. Without regular keepalive packets, the NAT router closes the UDP mapping and the return path to the client is dead. In tunnel-in-tunnel scenarios, also check the MTU (often 1420), otherwise large packets founder on fragmentation.