Don’t let WireGuard handshake failures destroy your routing table

Networking & Firewalls (Nftables/Iptables/WireGuard)

Don’t let WireGuard handshake failures destroy your routing table

Technical Briefing | 11/6/2026

We have all been there. You deploy a new mesh network using WireGuard, everything pings perfectly for a week, and then one interface silently drops its connection. You check the kernel logs, see a few failed handshakes, and wonder why the rest of your traffic is still trying to route through a dead interface. The issue is that WireGuard is just a tunnel device, and it does not inherently know when the underlying path to the peer has become a black hole.

The kernel is not doing your heavy lifting

WireGuard relies on the kernel’s routing table to decide where encrypted packets go. If the interface stays ‘up’ but the peer stops responding, the kernel keeps pushing packets into that interface. If you don’t have explicit routing metrics or a watchdog to pull the interface down, you end up with a state where traffic vanishes into a void without triggering an ICMP error back to your application. This bit me in prod when a dynamic ISP IP change left a tunnel hanging in a half-connected state for hours.

ip route add 10.100.0.0/24 dev wg0 metric 100 onlink

  • Set persistent Keepalives to force the peer to acknowledge the tunnel state
  • Use a script to monitor /sys/class/net/wg0/statistics/tx_dropped to detect path issues
  • Avoid using static routes with high priority that ignore interface status

Validation beyond the handshake

If you are managing this with nftables, verify that your interface state is actually tracking the connection marks. If your firewall is allowing packets based on the tunnel interface but the tunnel is not passing traffic, your logs will lie to you by showing accepted packets that never arrive. Before you spend an hour debugging your firewall rules, check the output of wg show and make sure the latest handshake timestamp is actually recent. If it is older than a few minutes, stop looking at the firewall and go hunt down the routing logic.

Next time the link drops, check the routing metrics before you flush your nftables rules. Sometimes the simplest answer is that your OS is routing around the hole you didn’t know you had.

Linux Admin Automation  |  © www.ngelinux.com  |  11/6/2026

0 0 votes
Article Rating
Subscribe
Notify of
guest

0 Comments
Newest
Oldest Most Voted