🔐 Hardening WireGuard for a Zero-Trust Mesh, Not a Flat Network

The first WireGuard mesh I inherited looked clean on paper: a dozen nodes, one wg0 interface each, everyone able to reach everyone. It was also a security disaster. A single compromised CI runner could ssh to the database, the bastion, and three production app servers because every peer’s config said AllowedIPs = 10.0.0.0/24. That is not a mesh. That is a flat network wearing an encryption costume. WireGuard gives you a beautifully simple, fast, modern tunnel, but simplicity is not the same as zero trust. You have to build the trust boundaries yourself, and most of them live in places people skim past during setup.

This is a defensive walkthrough. Everything below is about reducing blast radius on infrastructure you own. I lean on AI heavily here, but only as a fast junior engineer that reviews configs and proposes nftables rules. The human verifies before anything is applied, and you never paste a real private key or preshared key into a model.

AllowedIPs Is the Firewall, Treat It Like One

The single most misunderstood line in WireGuard is AllowedIPs. People read it as “routes” and then write 0.0.0.0/0 or a fat /24 to make things “just work.” But on the inbound path, AllowedIPs is a cryptokey routing ACL: a packet decrypted from a peer is only accepted if its source IP falls inside that peer’s AllowedIPs. It is the closest thing WireGuard has to a per-peer firewall, and it is enforced in-kernel before anything else sees the packet.

So scope it to exactly the addresses a peer is allowed to be. A laptop peer should be a /32, never a subnet:

# /etc/wireguard/wg0.conf on a hub — laptop gets exactly one address
[Peer]
PublicKey = pK7...laptop...=
PresharedKey = /etc/wireguard/psk/laptop.psk
AllowedIPs = 10.10.0.7/32
PersistentKeepalive = 25

If that laptop is later compromised and tries to spoof 10.10.0.2 (the database), the hub drops the packet on decryption. No nftables rule fired, no application saw it. That is least privilege baked into the crypto layer.

Pro Tip: wg show wg0 allowed-ips prints the live ACL for every peer in one screen. Diff it against your intended policy on a schedule — drift here is silent and dangerous, because a too-wide AllowedIPs never throws an error, it just quietly grants access.

Per-Peer Least Privilege and the Hub-and-Spoke Trap

A true mesh where every node peers with every other node is hard to reason about and easy to over-permission. For zero trust, prefer a hub-routed topology where spokes only carry AllowedIPs for the specific services they need, and the hub enforces policy. A spoke that only talks to a metrics endpoint should not have a route to the database at all:

# spoke config — this node only needs the metrics collector
[Peer]
PublicKey = hUb...=
Endpoint = hub.example.net:51820
PresharedKey = /etc/wireguard/psk/hub.psk
AllowedIPs = 10.10.0.30/32   # metrics collector only, nothing else
PersistentKeepalive = 25

The instinct to write AllowedIPs = 10.10.0.0/24 “so I don’t have to edit it later” is exactly the flat-network trap. Editing it later is the point. Each address you add is a deliberate access grant you can audit.

Key Management Without Footguns

Private keys never leave the host they belong to. Generate on the box, set tight permissions, and only ever move the public key:

umask 077
wg genkey | tee /etc/wireguard/private.key | wg pubkey > /etc/wireguard/public.key
chmod 600 /etc/wireguard/private.key

Reference the key by file in newer wg-quick setups rather than pasting it inline, and keep the directory locked down:

chmod 700 /etc/wireguard
chown root:root /etc/wireguard

The public key is your peer identity, so treat the public-key-to-host mapping as security-relevant config and keep it in version control where changes are reviewed. When you want a second set of eyes on a config diff before it merges, an AI reviewer is a great fast first pass — paste the public config, ask it to flag any AllowedIPs wider than a /32 or any peer missing a preshared key, then verify its findings yourself. Our code review dashboard and the prompts in the security-hardening category are built around exactly this audit-then-verify loop.

Preshared Keys as a Post-Quantum Hedge

WireGuard’s handshake is solid today, but a stored-now-decrypt-later adversary is a real threat model for long-lived infrastructure. The cheap defense is a symmetric preshared key mixed into each peer’s handshake, which adds a layer that is not broken by a future break of the elliptic-curve exchange:

wg genpsk > /etc/wireguard/psk/laptop.psk
chmod 600 /etc/wireguard/psk/laptop.psk

It is per-peer-pair and goes in both ends’ [Peer] blocks (you saw PresharedKey above). It costs nothing at runtime and buys you a genuine post-quantum hedge. There is no reason a hardened mesh shouldn’t use them everywhere.

Combine With nftables — Defense in Depth

AllowedIPs controls which source addresses a peer may use, but it does not control which destination ports they may reach. For that you need a host firewall, and the two together are defense in depth. Run nftables on the hub and the sensitive spokes so that even an in-policy peer can only reach the ports it is supposed to:

table inet wg_policy {
    chain forward {
        type filter hook forward priority 0; policy drop;

        iifname "wg0" oifname "wg0" ct state established,related accept

        # laptop -> app server, https only
        ip saddr 10.10.0.7  ip daddr 10.10.0.20 tcp dport 443 accept
        # metrics spoke -> collector, scrape port only
        ip saddr 10.10.0.31 ip daddr 10.10.0.30 tcp dport 9090 accept

        log prefix "wg-drop: " drop
    }
}

Now compromise of the laptop peer gets an attacker tcp/443 to one app server and nothing else — not SSH, not the database, not lateral movement to other spokes. If you want help translating an access matrix into rules like these, the prompt packs include firewall-policy templates, and a model like Claude is good at drafting the ruleset from a plain-English table — but treat its output as a proposal and lint it with nft -c -f before loading.

Kill-Switch and Restricting Routing

For client peers, a kill-switch prevents traffic from leaking onto the open network if the tunnel drops. wg-quick can wire this with PostUp/PostDown fwmark rules, but the simplest robust version blocks all egress except through wg0:

[Interface]
PostUp = nft add table inet ks; nft add chain inet ks out '{ type filter hook output priority 0; policy drop; }'; nft add rule inet ks out oifname "wg0" accept; nft add rule inet ks out oifname "lo" accept; nft add rule inet ks out udp dport 51820 accept
PostDown = nft delete table inet ks

On the routing side, do not blindly enable net.ipv4.ip_forward on hosts that have no business routing. A spoke that only originates traffic should keep forwarding off entirely, so it can never become an accidental pivot. Only the hub forwards, and even there the nftables forward chain defaults to drop.

Rotating Keys and Monitoring Handshakes

Keys are not set-and-forget. Rotate on a cadence and immediately on suspected compromise. Rotation is a two-step swap: add the new peer entry, confirm the handshake, then remove the old one with wg set wg0 peer <oldpub> remove. Script it so the window where both keys are valid is short.

Monitoring is your detection layer. WireGuard exposes the last handshake time per peer, and a peer that should be chatty but shows a stale handshake is either down or being tampered with:

wg show wg0 latest-handshakes
# pubkey   1718539200   <- epoch seconds, alert if now - this > a few minutes

Feed those timestamps into your alerting. Pro Tip: pipe wg show all dump into a small exporter and alert on now - latest_handshake > 180 for any peer marked “should be up.” A silent peer is the first symptom of a dropped tunnel, a rotated-but-not-updated key, or someone pulling cable in your rack. If you want to turn that raw signal into runbook-ready alerts, our monitoring alerts dashboard helps draft the thresholds and the on-call narrative.

PersistentKeepalive = 25 is worth setting on any peer behind NAT — it keeps the UDP mapping alive so the handshake stays fresh and your monitoring stays meaningful, rather than going stale simply because a firewall forgot the flow.

Conclusion

WireGuard hands you a fast, minimal tunnel and then steps back. The zero-trust part is yours to build: /32 AllowedIPs as the real per-peer firewall, nftables for port-level control, preshared keys as a post-quantum hedge, a kill-switch, disciplined rotation, and handshake monitoring so you notice when something breaks. None of it is exotic, but all of it is easy to skip in the rush to “just connect the boxes.” Use AI to audit the configs, draft the rules, and catch the too-wide subnet you’d have missed — then verify every suggestion and apply it yourself, with real keys never leaving the host. Build the mesh like the network is already hostile, because the day a peer is compromised, that assumption is the only thing standing between one bad host and all of them.