You probably set up your WireGuard tunnel, saw the handshake succeed, and called it a day. But if the interface drops or the remote endpoint shifts, your system might decide to route traffic out via your default gateway. I once saw a box leak an entire database sync over public internet because the tunnel interface vanished. It happens in silence, and your logs won’t necessarily scream about it.

The killswitch reality

The issue is that WireGuard is a virtual interface, not a physical one. If it disappears or fails to route, the kernel just falls back to your main routing table. To stop this, you need to use nftables to ensure that traffic meant for the tunnel only leaves through the wireguard interface, and if that interface is unreachable, the packets get dropped at the prerouting or output chain. Don’t rely on userspace scripts to manage routes; the kernel is faster and harder to break.

nft add chain inet filter output { type filter hook output priority 0 ; }
nft add rule inet filter output oifname != "wg0" ip daddr 10.0.0.0/24 counter drop

• Binding your firewall rules to the interface name catches leaks the moment the interface drops.
• Restrict your outgoing traffic to only the known tunnel subnet to prevent accidental bypass.
• Verify your nftables rules after any interface restart since names can sometimes fluctuate during race conditions.

If you are worried about the interface name changing on reboot, stick to binding by hardware mac address or use a systemd-networkd match rule to ensure persistent naming. Most people ignore this until a packet hits their ISP’s logs. Test it by killing the wg-quick service while a ping is running and watch the traffic die immediately rather than finding a new path.