ARP resolves but ping doesn't — the asymmetric-routing trap, and a one-line fix

I had two machines plugged into the same switch and couldn't get from one to the other. No ping, no SSH, nothing — yet the cable was fine and the other box was very much alive. The symptom that cracked it is worth knowing, because it points straight at the cause.

The tell

Ping timed out, but the ARP entry resolved perfectly:

arp -n | grep 192.168.50.2
192.168.50.2   ether   04:d4:c4:xx:xx:xx   C   enx...

ARP is layer 2. If the MAC resolves, the wire and the switch are doing their job — the other machine has answered an ARP broadcast at some point. So a resolving ARP entry alongside dead ICMP/TCP tells you the problem is layer 3, and specifically the return path.

Proving it with tcpdump

Capture on the interface while pinging:

sudo tcpdump -i enx... -n host 192.168.50.2

What I saw, each time I pinged: my echo request arrived, and the other box immediately fired off an ARP request for its default gateway — and got no reply. It had received my packet and was trying to route the response back, but my source address (on a different subnet, via a /16 that happened to cover the target) wasn't on its local segment, so it needed a gateway. That gateway was dead. The reply never left the building.

This is asymmetric routing: the outbound packet gets there, the reply can't find its way home. ARP keeps working throughout because ARP is broadcast on the local segment and doesn't care about gateways — which is exactly why you get the confusing "MAC resolves but nothing else works" picture.

The one-line fix

Give your machine a second address on the target's own subnet. Now your packets are sourced from an address the target can reach directly over ARP — no gateway required for the reply.

sudo ip addr add 192.168.50.50/24 dev enx...
ping -c3 -I 192.168.50.50 192.168.50.2
ssh -b 192.168.50.50 root@192.168.50.2

-I (ping) and -b (ssh) force the new source address so the reply path stays local. Remove it again with sudo ip addr del 192.168.50.50/24 dev enx... when you're done.

One aside that cost me a few minutes: even after this, ICMP stayed firewalled on the target while TCP worked fine. So don't let a still-failing ping convince you it hasn't worked — try the actual port you care about. The real fix for the target, of course, is to give it a working default gateway; the source-address trick is the get-in-now workaround.

I hope this saves you the tcpdump session. Enjoy!