Stop your WireGuard handshake from getting stuck behind strict nftables ingress rules

Technical Briefing | 8/2/2026

You spend half an hour verifying your WireGuard keys and public IP, only to find the tunnel stays silent. It is not the config file. It is not the kernel module. It is your firewall eating packets before they even hit the interface. I have seen this drive juniors to the brink of insanity because nftables doesn’t always log dropped packets by default.

Why the standard accept rules aren’t enough

WireGuard is unique because it is stateless. Most firewalls are built to track connections using conntrack, but WireGuard is just UDP traffic. If you rely on stateful rules, you might be accidentally filtering the handshake packets before the tunnel can even establish its internal peer state. The problem usually crops up when you combine default-deny policies with loose interface bindings.

nft add rule inet filter input udp dport 51820 accept

• Force the rule to trigger early in the hook so you aren’t fighting global drop policies
• Avoid using ct state established for UDP traffic unless you have a helper that actually understands WireGuard
• Check if you have an input filter binding to the physical interface while the WireGuard interface is still coming up

If you are still seeing zero incoming traffic in wg show, dump the raw nftables ruleset to a file and look for a counter that increments every time you try to ping the remote endpoint. If the packet count hits a drop rule, you know exactly where the bottleneck is. Move your accept rule to the top of the chain, reload, and verify with a fresh handshake.

The next time you are debugging this, don’t trust the interface counters alone. WireGuard will keep retrying the handshake indefinitely, masking the fact that your firewall is discarding the packets at the ingress stage. Keep an eye on the kernel’s drop monitor if you really want to see the path of destruction.