When your WireGuard peers talk but your traffic just vanishes

Technical Briefing | 9/16/2026

You setup WireGuard, the handshake completes, and wg show confirms the peer is active. You ping the tunnel IP and it works. But the moment you try to route traffic through the peer for actual work, the packets fall into a black hole. It is not an MTU issue, and it is not a missing route. It is almost always a return path problem hidden by the stateful nature of your firewall.

Why connection tracking lies to you

Most of us rely on conntrack to keep our firewall rules simple. If you have an established-related rule, you assume that return traffic is magically handled. But WireGuard interfaces operate as routed point-to-point links. If your main firewall is doing NAT for your LAN and you forget to explicitly allow the traffic coming out of the wg0 interface, the kernel drops those return packets before they even reach the tunnel interface. It feels like the handshake worked, so why wouldn’t the traffic flow? Because the kernel treats the tunnel as an untrusted external zone, even if it is on the same machine.

nft add rule inet filter forward iifname wg0 oifname eth0 accept
nft add rule inet filter forward iifname eth0 oifname wg0 accept

• Check if you have an input policy that is implicitly dropping forward traffic without logging
• Verify if your WireGuard AllowedIPs configuration on the remote peer actually includes the traffic destination
• Ensure ip_forwarding is actually enabled in sysctl because it resets on reboot more often than you think
• Look for dropped packets in your dmesg buffer specifically originating from the tunnel interface

The trap of interface-based filtering

Stop writing rules based solely on IP addresses. When dealing with VPNs, you need to filter on the interface name. If you restrict traffic by the wg0 interface, you isolate your VPN policy from your physical ethernet policy. This prevents a configuration drift where an interface gets renamed and your firewall rules silently lose their binding to the traffic you intended to control. Just be careful that you do not accidentally rely on zone-based filtering tools that do not support dynamic interface naming in their rule sets.

If you are still hitting a wall, disable your nftables ruleset entirely for five minutes. If traffic suddenly flows, you know it is the firewall and not a routing table collision. Don’t waste another hour chasing routes when a single logging rule at the top of your chain would have shown you the interface mismatch instantly.