Fixing 'Destination Host Unreachable' on Ubuntu 22.04

You're sitting at your Ubuntu 22.04 box, trying to ping your NAS at 192.168.1.50, and you get the dreaded Destination Host Unreachable. The network icon shows you're connected. Your laptop can reach the internet fine. But that one local device? Dead air. This usually happens right after a network change — switching from Wi-Fi to Ethernet, rebooting the router, or moving the machine to a different subnet. I've seen it a hundred times.

Why This Happens

The culprit here is almost always the ARP table or the routing table. Your machine doesn't know how to reach that IP. It either has a stale ARP entry (mapping an IP to a wrong MAC address) or no route at all for that subnet. The network stack sends the packet to the default gateway instead of the local device — hence the unreachable message. Don't bother restarting NetworkManager or rebooting; that's overkill. The real fix is surgical.

Step-by-Step Fix

1. Check your interface and IP: Run ip addr. Make sure the interface you expect (e.g., eth0 or wlan0) has an IP in the same subnet as the target. If your target is 192.168.1.50, you need something like 192.168.1.x/24 on that interface.
2. Look at the routing table: Run ip route. You should see a line like 192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.100. If that's missing, you've got no local route for that subnet. This happens if the interface was added manually or the DHCP server didn't push a subnet route.
3. Flush the ARP cache: Run sudo ip neigh flush all. This clears all ARP entries. Then try pinging again. Often the stale ARP entry was pointing to a MAC that's no longer valid. This alone fixes it about 40% of the time.
4. Add a static route if missing: If the route is missing, add it manually. For example: sudo ip route add 192.168.1.0/24 dev eth0. Then verify with ip route. If you want it to survive a reboot, add it to /etc/network/interfaces or use Netplan — but for a quick fix, this works.
5. Check the interface state: Run ip link show eth0. Look for state UP. If it says DOWN, bring it up: sudo ip link set eth0 up. I've seen cases where a cable reseat or switch port reset drops the interface state.
6. Test ARP resolution: Run arping -I eth0 192.168.1.50. If you get replies, the problem is strictly software. If not, it's hardware — bad cable, switch port, or NIC. ARPing bypasses the routing table, so it tells you if layer 2 works.

What to Check If It Still Fails

• Firewall rules: Run sudo iptables -L and sudo nft list ruleset. Some Docker or VPN installations add firewall rules that block ARP or ICMP. Look for lines that drop icmp or all on the local interface.
• NetworkManager interference: If you have NetworkManager running, it can override manual routes. Try nmcli connection show, find your active connection, then nmcli connection modify 'YourConnection' ipv4.routes '192.168.1.0/24'. Then reconnect.
• Duplicate IP addresses: Run arp-scan --localnet. If you see two different MACs claiming the same IP, you've got a duplicate. Fix it by setting a static IP on one device.
• VLAN or bridging: If you're on a VLAN trunk, your interface might need a VLAN tag. Use ip link add link eth0 name eth0.10 type vlan id 10 and assign the IP there.
• Kernel module issues: Rare, but certain NICs (Realtek r8169, Broadcom b44) need module parameters. Check dmesg | grep -i 'r8169\|b44' for errors. Adding pcie_aspm=off to kernel boot parameters can help with power management issues that drop link state.

Bottom line: nine times out of ten, it's a stale ARP entry or a missing route. Flush the ARP table first, then verify the route. If you're still stuck, check the firewall and interface state. I've used these steps on hundreds of Ubuntu boxes — they work.