WireGuard is great because it stays out of your way. Unlike IPSec or OpenVPN, it doesn’t leave sockets sitting around waiting for handshake hell. But this simplicity is a trap when you’re managing complex routing tables. I’ve spent three hours on a Tuesday night chasing a packet that was getting dropped by a rule I wrote for eth0, completely forgetting that traffic from the tunnel interface needed its own policy.

Why your tunnel traffic hits the global policies

Most people assume WireGuard is just another interface and treat it like a static bridge. The problem is that once the tunnel is up, those packets often bypass the specific input chains you’ve carefully built for your public interfaces. If you aren’t explicitly matching the interface name in nftables, your restrictive default-drop policy might let the traffic through in ways you didn’t intend, or worse, block it silently while you stare at tcpdump trying to figure out why the handshake finishes but the data stream stalls.

nft add rule inet filter input iifname wg0 accept

• Use iifname instead of ip saddr to bind rules to the tunnel specifically
• Keep the tunnel traffic in a separate hook chain to keep your main input chain from bloating
• Remember that WireGuard doesn’t do state tracking like NAT-heavy VPNs so you have to allow return traffic explicitly

If you are running a mesh, managing these rules by hand is a recipe for disaster. I prefer scoping the tunnel traffic strictly to the internal IP range rather than just opening the whole interface. Don’t let your tunnel rules become a sprawling mess of IP addresses that nobody remembers updating three years from now.

Next time you add a peer, try applying the rules via a nftables set rather than individual lines. It keeps the policy readable and prevents the kernel from choking on a massive chain as your peer list grows.