You spend twenty minutes verifying keys, checking endpoints, and confirming the interface is up, yet the handshake never completes. It’s the classic silent failure. WireGuard is intentionally quiet about why it’s not talking, but nine times out of ten, it’s not a configuration error. It’s your firewall aggressively dropping UDP packets because it thinks they are stray junk from an unknown state.

Why the stateful firewall hates your tunnel

If you are running nftables or iptables with a default drop policy, you probably have a rule that allows established and related traffic. The problem is that WireGuard is connectionless by design. Your firewall doesn’t see a TCP handshake to track, so it just sees random UDP noise if the timing is slightly off or if your NAT gateway decides to remap your source port mid-session. This bit me in production during a carrier failover, and it was a nightmare to debug.

nft add rule inet filter input iifname wg0 accept
nft add rule inet filter input udp dport 51820 accept

• Always define the explicit UDP listen port before your generic stateful rules.
• Ensure your interface name is locked to the specific tunnel device to prevent leaking traffic.
• Check your MTU settings if the handshake completes but large payloads freeze the connection.

Most tutorials tell you to just open the port and move on, but they skip the part where your provider or a local middlebox resets your connection state. If you are seeing packets leave but nothing coming back, dump your trace logs. The kernel is likely being helpful by being silent, so you have to force it to show you the drop reason.

Take a look at your interface counters before you change a single rule. If you see the drop count climbing on your input chain, you know exactly where to point your focus. Stop guessing if the keys match; check if the packets are even hitting the WireGuard socket in the first place.