You probably set up WireGuard because it is fast and simple, but the lack of a formal connection state in the protocol creates a nasty trap. If your tunnel loses the peer but keeps the route active, the kernel will happily route traffic into the void or back out your default gateway unencrypted. I have seen this happen during ISP flaps where the interface stays up but no packets move.

Why the kernel does not care about your dead tunnel

WireGuard is stealthy by design. It does not send KeepAlive packets unless you explicitly configure them, and it does not notify your routing table that the peer is unreachable. When the handshake fails, the interface just sits there, waiting for a response that might never come. If your routing table says traffic for 10.0.0.0/24 should go through wg0, your machine will keep trying to shove data into that black hole instead of failing closed.

Forcing a kill switch with nftables

Don’t rely on the VPN client to manage your firewall rules. If the process crashes or hangs, the rules remain. The right approach is to explicitly block egress traffic for your tunnel subnet on your primary interface using an output chain rule. This forces the packets to drop at the wire if they aren’t marked correctly, which is the only way to ensure zero leakage when the peer vanishes.

nft add rule inet filter output oifname eth0 ip daddr 10.0.0.0/24 drop

• Set PersistentKeepalive in your wg0.conf to at least 25 seconds to force re-handshakes
• Check your interface state with wg show dump to verify the latest handshake time
• Use a distinct routing table for the tunnel to prevent default gateway leakage on failure

The next time you are debugging a flaky connection, stop looking at the logs and check your outbound counters instead. If the packets are hitting your primary interface despite the tunnel supposedly being up, you’ve just found your leak. It’s a boring fix, but it’s the only one that holds up when the network goes sideways.