DevOps
WireGuard VPN for Private Cloud Networking: Simple, Fast, Secure
January 202611 min read
DevOps
WireGuard achieves TCP throughput of 210 Mbps versus OpenVPN's 110 Mbps in comparable cloud environments — nearly 2x the throughput with significantly lower CPU usage and packet loss. More importantly, WireGuard's codebase is approximately 4,000 lines — roughly 1% the size of OpenVPN or IPsec stacks — making it dramatically easier to audit and maintain. At Commsult Indonesia, I replaced an OpenVPN setup between our DigitalOcean Droplets with WireGuard and saw connection establishment time drop from several seconds to milliseconds.
WireGuard is a modern VPN protocol that runs in the Linux kernel (kernel 5.6+ includes it natively). It provides encrypted tunnels between hosts using Curve25519 for key exchange, ChaCha20-Poly1305 for encryption, and BLAKE2s for hashing. It is not a full VPN service solution — there is no user management, no web UI, no certificate authority. WireGuard is a lean cryptographic tunnel: you configure public and private key pairs and peer lists, and it creates encrypted routes between hosts. Tools like wg-easy (Docker-based), Tailscale, and Headscale add the management layer on top.
WireGuard excels at: site-to-site networking between cloud servers (private database access without exposing ports publicly), remote access for developers to staging/production environments (SSH through WireGuard instead of exposing SSH to the internet), connecting DigitalOcean Droplets in different regions over a private overlay, and creating a hub-and-spoke network where development machines connect to a central VPS that has access to private cloud resources. I use a Singapore DigitalOcean Droplet as the WireGuard hub, with Commsult office machines and GCP instances as spokes.
In VMware environments, WireGuard demonstrated 210 Mbps TCP throughput versus OpenVPN's 110 Mbps — a 91% improvement. Packet loss was 12% for WireGuard versus 47% for OpenVPN under identical simulated network conditions. On gigabit networks, WireGuard achieves near-wire speed (7.88 Gbits/sec). WireGuard uses UDP exclusively, enabling kernel-level batching and offloads (GRO/GSO) that OpenVPN's TCP mode cannot leverage.
┌─────────────────────────────────────────────────────┐
│ WIREGUARD HUB-AND-SPOKE TOPOLOGY │
└─────────────────────────────────────────────────────┘
Dev Laptop ──────────────────────────────┐
(10.8.0.2) │
▼
Office IP ───────────────────► WireGuard HUB VPS
(10.8.0.3) (10.8.0.1, Singapore)
UDP :51820 public
GCP DB Server ◄──────────────────────────┤
(10.8.0.10) private overlay │
│
DO App Server ◄──────────────────────────┘
(10.8.0.11)
Public internet: only Nginx 80/443 + WireGuard UDP 51820
Private: PostgreSQL 5432, Redis 6379, NestJS 3000From my experience running WireGuard between DigitalOcean Singapore and GCP Asia-Southeast1 for Commsult Indonesia, use PersistentKeepalive = 25 for any peer behind NAT — most office connections and development machines. Without it, the WireGuard tunnel silently goes idle after 3 minutes of no traffic and takes 1-2 seconds to re-establish on the next packet, causing dropped database connections and WebSocket disconnects. PersistentKeepalive sends a UDP keepalive every 25 seconds to keep NAT mappings alive.
The most useful WireGuard topology for a small team is hub-and-spoke: one VPS acts as the hub with a static public IP, and all clients (office machines, laptops, CI/CD runners) are spokes. Each spoke has a WireGuard interface with routes for the private subnet going through the hub. The hub has IP forwarding enabled and a WireGuard interface listening on UDP port 51820. Clients connect to the hub's public IP and reach private resources (databases, internal APIs) through the encrypted tunnel.
On DigitalOcean, configure the Cloud Firewall to allow UDP 51820 from any IP (WireGuard clients may have dynamic IPs). Once peers are connected through WireGuard, restrict all other sensitive ports (PostgreSQL 5432, Redis 6379, NestJS 3000) to the WireGuard private subnet only — never exposing them to the internet. This is the correct production posture: only WireGuard and Nginx (80/443) are accessible from the internet, everything else is internal.
# Install WireGuard (Ubuntu 22.04+)
apt install wireguard -y
# Generate key pair on hub
wg genkey | tee /etc/wireguard/private.key | wg pubkey > /etc/wireguard/public.key
chmod 600 /etc/wireguard/private.key
# /etc/wireguard/wg0.conf (HUB)
[Interface]
Address = 10.8.0.1/24
ListenPort = 51820
PrivateKey = <HUB_PRIVATE_KEY>
PostUp = iptables -A FORWARD -i wg0 -j ACCEPT; iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
PostDown = iptables -D FORWARD -i wg0 -j ACCEPT; iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE
[Peer]
# Dev Laptop
PublicKey = <DEV_PUBLIC_KEY>
AllowedIPs = 10.8.0.2/32
PersistentKeepalive = 25
# Enable and check status
systemctl enable --now wg-quick@wg0
wg show # shows peers, last handshake, bytesWireGuard provides minimal built-in diagnostics, which is both a strength (simplicity) and a weakness (troubleshooting). Check peer status with wg show — it displays each peer's public key, endpoint, allowed IPs, last handshake time, and bytes transferred. A last handshake time older than 3 minutes indicates the peer is not connected. For connectivity issues: check that UDP 51820 is allowed in the firewall on both sides, verify the peer's public key is correct, and ensure AllowedIPs includes the private subnet you are trying to reach.
WireGuard has no central authority or password recovery. If you lose the private key for a peer, that peer cannot reconnect — you must generate a new key pair, update the hub's configuration with the new public key, and reconnect. I keep WireGuard configurations in an encrypted 1Password vault and in our private GitLab repository (with private keys stored only in the vault, never in git). Document your WireGuard setup thoroughly — debugging a mis-configured WireGuard tunnel from a locked-out state is painful.
For teams that need a UI for peer management, wg-easy is a Docker-based WireGuard management interface. Run it as a Docker container on your hub VPS: it manages WireGuard configuration, generates QR codes for mobile clients, provides a web UI for adding/removing peers, and shows connection status. wg-easy is significantly simpler than Tailscale (which requires an account and uses a proprietary coordination server) and gives you full control of your VPN infrastructure.
My current WireGuard setup: DigitalOcean Singapore Droplet (2 vCPU / 2GB) as the hub running wg-easy in Docker, with WireGuard subnet 10.8.0.0/24. Connected peers: 2 GCP Asia-Southeast1 instances (PostgreSQL and Redis, private IPs only), 3 DigitalOcean Droplets (NestJS app servers), Commsult Indonesia office static IP, and my development laptop. All inter-server communication goes through the WireGuard tunnel. Only Nginx on port 80/443 and WireGuard on UDP 51820 are publicly accessible. This setup has been running reliably for over a year with zero maintenance.