WireGuard is brilliant because it is simple, but that simplicity often hides a dangerous race condition. When the wg-quick service brings up an interface, it injects routes into your main table before your nftables ruleset is fully validated or applied. I have seen production nodes briefly leak DNS queries and cleartext traffic to the default gateway during a reboot or service restart because of this precise ordering issue.

Why the route table wins the race

The kernel prioritizes the routing table for packet steering. If your default route is up, the kernel is ready to push traffic out that interface. Even if your nftables filter chains are defined, there is a narrow window where the interface exists but the filter rules have not yet bound to it. Relying on the interface coming up last is a fool’s errand. Instead, you need to use table-specific routing to keep your tunnel traffic isolated from the get-go.

ip rule add from 10.0.0.0/24 table 200
ip route add default via 10.0.0.1 dev wg0 table 200

• Create a dedicated routing table specifically for your WireGuard traffic
• Use ip rule to force traffic based on the source IP rather than just interface state
• Ensure your firewall rules drop traffic from the tunnel interface if it attempts to egress via eth0

If you are managing this via wg-quick, use the PostUp and PreDown directives to toggle these rules. Don’t assume the tunnel is invisible just because the connection is encrypted. If you lose the tunnel, you don’t want the OS failing over to your ISP gateway. Always verify with tcpdump on your physical interface while the tunnel is down, just to see what kind of garbage is still trying to leak out.