Stop WireGuard from leaking traffic when your tunnel goes down
By Saket Jain Published Linux/Unix
Stop WireGuard from leaking traffic when your tunnel goes down
Technical Briefing | 9/11/2026
You spend all afternoon crafting the perfect WireGuard config, bring the interface up, and everything looks great. But if your peer drops off or the handshake fails, the Linux kernel doesn’t just hold that traffic for you; it sends it right out the default gateway in the clear. This bit me in prod back when we were using tunnels for cross-region database replication. One network blip later, and our unencrypted sync traffic was dancing across the public internet for ten minutes before I realized what was happening.
The kernel doesnt know the tunnel is toast
WireGuard is designed to be invisible when it is not actively passing packets. It does not maintain a constant state that the routing table checks against. If you have a static route pointing to your wg0 interface, the kernel assumes that interface is valid as long as the device is up. To prevent this, you need to tie the tunnel state to your firewall rules. The right approach is to use a specific mark on the packets and drop anything that shouldn’t be leaving the wire.
nft add table inet fw_wg
nft add chain inet fw_wg output { type filter hook output priority filter; }
nft add rule inet fw_wg output oifname != "wg0" meta mark 0xca6e drop
- Use the fwmark setting in your WireGuard config to tag traffic bound for the tunnel
- Set an egress rule to reject everything without that mark if the interface is not wg0
- Keep your routing table clean by avoiding catch-all default routes that ignore the tunnel state
When things go wrong anyway
If you are strictly using nftables, keep an eye on your chain priorities. It is easy to accidentally let a filter rule execute before the connection tracking engine tags the packet, leading to silent drops that are a nightmare to debug with tcpdump. Before you commit these rules to production, dump your current set and verify the order. It is worth the two minutes to be sure your packets are actually hitting the chain you think they are.
Next time you deploy a tunnel, try forcing a dummy route and watching your traffic graphs to ensure nothing bleeds into your primary interface. It might save you from a messy security incident that you really do not want to explain to your boss.
