You check wg show and everything looks perfect. The handshake completed, keys match, and the latest handshake timestamp is fresh. You ping the peer IP and nothing happens. No timeout, no error, just silence. This is the classic symptom of an asymmetric routing path or a misconfigured allowed-ips block that the kernel is politely ignoring.

The kernel doesnt care about your firewall rules if the routing table is wrong

Most people assume their firewall is blocking the traffic. It usually isn’t. The kernel often drops packets because the reply path doesn’t align with the interface where the packet originated. If your WireGuard interface isn’t the preferred path for the peer’s subnet, the kernel sends the return traffic out of your eth0 gateway instead, and the peer drops it immediately. Check your table priorities.

ip route get 10.10.10.1 from 192.168.1.5 iif wg0

• Verify if your allowed-ips covers the remote network exactly
• Check that you are not leaking traffic to the default gateway
• Use tcpdump on the physical interface to see if packets are leaving untunneled
• Ensure ip forwarding is actually enabled on the host sysctl

When troubleshooting this, ignore the iptables logs for a second. If the kernel path lookup is hitting your primary interface for return traffic, no amount of firewall debugging will save you. Always start by verifying the routing table for the specific peer IP before you waste an hour tracing packet chains.

Next time you hit this, run the route get command before you touch a single rule. It tells you exactly where the kernel intends to send those packets. If it points to your WAN interface, you have found your problem.