Learn WireGuard - Production-Ready Deployment

#Introduction

Episode 12 covered key rotation and the security lifecycle, episode 14 hardened the firewall, and episode 19 brought high availability. Episode 21 weaves all of it together: how to put WireGuard into production properly, not just as a tunnel that works.

In this episode you will take away a production deployment checklist covering key rotation policy, firewall hardening, handshake and transfer monitoring, log aggregation, and backup strategies. The final section covers deployments on AWS, GCP, and Azure, including hybrid connectivity and SD-WAN.

The key is building habits: every configuration decision must be explainable, testable, and recoverable. Production is not about one feature; it is about how all the parts work together when facing failure.

#Production Deployment Checklist

#Key Rotation Policy

Production demands a documented key lifecycle. Set a key validity period, for example 90 days, a replacement mechanism that does not cut connections, and a rule against copying private keys off the server. Also record who is responsible for replacing keys and how the process is tested.

Rotation runs smoothly because WireGuard supports replacing keys live without restarting the interface. The following command replaces the private key safely:

wg set wg0 private-key /etc/wireguard/keys/wg0.new
wg syncconf wg0 <(wg-quick strip wg0)

Notice the wg syncconf command, which syncs the runtime configuration with the file without cutting the session. This is the standard practice for zero-downtime rotation, and it can be automated with cron or CI.

#Firewall Hardening

WireGuard itself only manages the tunnel; the firewall remains your responsibility. Every production interface should restrict the source of UDP traffic to the listen port, and reject packets that do not come from a known peer.

nft add rule inet filter input iifname "eth0" udp dport 51820 accept
nft add rule inet filter input ct state established,related accept
nft add rule inet filter input iifname "eth0" drop

The rules above only open port 51820 from the public interface, then drop other packets. Save the rules in the /etc/nftables.conf file and enable with systemctl enable --now nftables so they survive a reboot.

#Security Basics

A few small details that are often missed but have a big impact:

• AllowedIPs is set as small as possible, not 0.0.0.0/0 without reason.
• A non-standard ListenPort adds no security, but makes scanning harder.
• The private key is owned by root with 600 permissions.
• Kernel and WireGuard tools updates run automatically through the package manager.

#Monitoring and Logging

#Monitoring Handshake and Transfer

The two most important metrics are the age of the last handshake and the amount of transfer. Both are available via wg show and can serve as the basis for alerting.

if wg show wg0 latest-handshakes | grep -q "0$"; then
  echo "tidak ada handshake baru, restart wg0"
  systemctl restart wg-quick@wg0
else
  echo "handshake terakhir masih aktif"
fi

The script above checks whether the last handshake is zero, which indicates a dead session. At larger scale, send a warning to your monitoring system when the last handshake is older than a threshold, for example five minutes. Cumulative transfer via wg show wg0 transfer is useful for detecting peers that have stopped sending.

#Log Aggregation

wg-quick uses systemd, so interface logs are easy to access. For aggregation across many servers, point all logs at a single collector such as Promtail or Vector, then store them in Loki. Also include the relevant nftables firewall logs so the connection audit trail is complete and can be replayed during investigations.

#Backup Strategy

Backup is not just copying files. You must be able to recover a peer from scratch using only the stored artifacts.

wg-quick save wg0
tar czf /backup/wg-prod-$(date +%F).tar.gz \
  /etc/wireguard /etc/nftables.conf

wg-quick save writes the current runtime configuration to /etc/wireguard/wg0.conf, so the backup always represents the latest state. Store the archive somewhere separate from the server, such as object storage, and encrypt it if it contains private keys. Test recovery periodically, not only when a disaster happens.

#Deploying in the Cloud

#AWS, GCP, and Azure

The deployment concept on all three providers is nearly identical: create an instance with a public IP and UDP port 51820 open in the security group or VPC firewall, install WireGuard, and register the instance's public endpoint with all peers.

[Interface]
Address = 10.9.0.1/24
ListenPort = 51820
PrivateKey = <server-private-key>
 
[Peer]
PublicKey = <client-public-key>
AllowedIPs = 10.9.0.2/32

You only need to adjust the AWS security group, GCP network tags, or Azure NSG so UDP port 51820 is open from allowed source addresses, not from 0.0.0.0/0 without filtering.

#Hybrid Connectivity and SD-WAN

To connect on-premises with the cloud, combine WireGuard with a route in the VPC: point the route table for the on-premises prefix through the WireGuard instance. At larger scale, WireGuard becomes the foundation of SD-WAN, leveraging the multi-interface WAN and dynamic endpoints already covered in episodes 7 and 19.

#Closing

Episode 21 closed the operational side: the production checklist starts with key rotation and firewall hardening, continues with handshake and transfer monitoring, log aggregation, backup strategies, and ends with deployments on AWS, GCP, and Azure with hybrid connectivity.

Key takeaways:

• Key rotation can be done live with wg set and wg syncconf.
• The firewall restricts UDP port 51820 to known peers only.
• wg show wg0 latest-handshakes and transfer are the main monitoring metrics.
• Backups use wg-quick save and are stored separately from the server.
• Cloud security groups or firewalls only open the WireGuard port from trusted sources.
• WireGuard is suitable as the foundation of SD-WAN and hybrid connectivity.

In episode 22, the final episode, we compare WireGuard with OpenVPN, IPsec, Tailscale, Headscale, and ZeroTier, then recap the journey from episode 0 to 21 along with final best practices and the future direction of WireGuard.