Fix Destination Host Unreachable on Linux

Tested on RHEL 10.2 (Coughlan) — vm1.lab.example (192.168.56.116) on host-only 192.168.56.0/24; peer 192.168.56.220 for working LAN checks
Package iproute 6.17.0-2.el10
NetworkManager 1.56.0-1.el10
bind-utils 9.18.33-15.el10_2.2
Applies to Ubuntu, Debian, Kali Linux, Linux Mint, Pop!_OS, Raspberry Pi OS, elementary OS, Zorin OS, Parrot OS, MX Linux, RHEL, Rocky Linux, AlmaLinux, Oracle Linux, CentOS Stream, Fedora, Arch Linux
Privilege Normal user for read-only checks; sudo or root to change routes, interfaces, and neighbor cache
Scope Diagnose destination host unreachable from ping, ssh, and TCP clients by reading ICMP sources, checking interfaces, ip route get, ip neigh, and gateway reachability. Contrasts with network is unreachable, no route to host, and connection refused.
Related guides Network is unreachable
No route to host
Connection refused
ip route command
traceroute command

ping 192.168.56.250 prints From 192.168.56.116 Destination Host Unreachable while ping 192.168.56.220 on the same subnet still works. A route to 192.168.56.0/24 exists — the failure is delivery on that segment, usually because nothing answered ARP for .250 or the configured gateway cannot be reached.

Read who sent the ICMP error, then walk interface state, routing, neighbors, and the gateway before you retest.

What destination host unreachable means

ping shows this message when an ICMP Destination Host Unreachable (type 3, code 1) comes back. Unlike network is unreachable, the kernel already picked a route — it could not complete forwarding to the next hop or final host.

Tool Typical message
ping From <ip> icmp_seq=N Destination Host Unreachable
ssh connect to host …: No route to host (same failure, different wording)
bash /dev/tcp/… connect: No route to host
tracepath !H on the hop that reported host unreachable

Common causes on a Linux client:

  • No ARP reply for a target on the same subnet (wrong IP, host powered off, VLAN mismatch)
  • Default gateway IP configured but the gateway does not answer ARP
  • Upstream router returns ICMP host unreachable for a remote network
IMPORTANT
Destination host unreachable is not DNS and not connection refused. If ip route get prints Network is unreachable with no dev line, fix local routes first — see network is unreachable. If TCP reaches the host but nothing listens, see connection refused.

Identify which host returned the error

The From field in ping output names the system that generated the ICMP error.

Ping an address that fails while a neighbor on the same subnet still works:

bash
ping -c2 -W3 192.168.56.250
output
PING 192.168.56.250 (192.168.56.250) 56(84) bytes of data.
From 192.168.56.116 icmp_seq=1 Destination Host Unreachable
From 192.168.56.116 icmp_seq=2 Destination Host Unreachable

--- 192.168.56.250 ping statistics ---
2 packets transmitted, 0 received, +2 errors, 100% packet loss, time 1020ms

From 192.168.56.116 is this host's own address — the local kernel gave up after ARP failed on enp0s8, not a remote router.

Compare with a working peer on the same LAN:

bash
ping -c1 -W2 192.168.56.220
output
PING 192.168.56.220 (192.168.56.220) 56(84) bytes of data.
64 bytes from 192.168.56.220: icmp_seq=1 ttl=64 time=0.634 ms

--- 192.168.56.220 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms

When From shows your gateway IP instead of your own address, the router is reporting that it cannot reach the next hop — fix gateway reachability or ask whoever manages that router.

TCP clients phrase the same failure differently:

bash
ssh -o ConnectTimeout=5 -o BatchMode=yes root@192.168.56.250 exit 2>&1
output
ssh: connect to host 192.168.56.250 port 22: No route to host

ping and ssh are describing the same delivery problem — use ping and ip neigh for the ICMP-level detail, then fix the layer that failed.

Check interface and IP configuration

Destination host unreachable on a directly connected subnet requires a working interface and an address on that segment.

List link state:

bash
ip -br link show enp0s8
output
enp0s8           UP             08:00:27:c4:4f:20 <BROADCAST,MULTICAST,UP,LOWER_UP>

UP and LOWER_UP mean the NIC is enabled and sees link carrier. DOWN without carrier explains why even valid IPs on that subnet fail — bring the interface up before you chase ARP.

Confirm the IPv4 address and prefix on the LAN interface:

bash
ip -4 addr show enp0s8
output
3: enp0s8: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    altname enx080027c44f20
    inet 192.168.56.116/24 brd 192.168.56.255 scope global dynamic noprefixroute enp0s8
       valid_lft 585sec preferred_lft 585sec

The target must sit in 192.168.56.0/24 when your source is 192.168.56.116/24. A typo in the last octet or a /24 host trying to reach a /24 peer without a router both produce unreachable errors — verify the peer's real address with whoever owns that system or your hypervisor console.

Check the route

Ask the kernel which path it would use for the failing address:

bash
ip route get 192.168.56.250
output
192.168.56.250 dev enp0s8 src 192.168.56.116 uid 0
    cache

dev enp0s8 confirms a direct LAN route — the next check is ARP, not a missing default gateway.

For traffic that leaves through a gateway, inspect the chosen next hop:

bash
ip route get 8.8.8.8
output
8.8.8.8 via 10.0.2.2 dev enp0s3 src 10.0.2.15 uid 0
    cache

When a wrong gateway is configured on the LAN interface, ip route get shows the bad via address:

bash
ip route get 8.8.8.8
output
8.8.8.8 via 192.168.56.99 dev enp0s8 src 192.168.56.116 uid 0
    cache

If 192.168.56.99 is not a live router, every remote ping returns destination host unreachable from your own IP. Remove or correct that default route — see gateway checks below.

When ip route get itself answers RTNETLINK answers: Network is unreachable, you have no matching route — that is network is unreachable, not this guide.

List connected subnets and default routes together:

bash
ip route show

Look for 192.168.56.0/24 dev enp0s8 for local LAN traffic and default via … for everything else. Duplicate or conflicting default entries with lower metrics can send traffic through a dead gateway.

Check ARP and neighbor resolution

On the same broadcast domain, the kernel must resolve the destination MAC before ICMP or TCP can flow. Inspect the neighbor cache for the failing IP:

bash
ip neigh show 192.168.56.250
output
192.168.56.250 dev enp0s8 FAILED

FAILED after ping attempts means no ARP reply — the host is off, the IP is unused, or L2 separation (VLAN, wrong port group) blocks discovery. REACHABLE or STALE with a lladdr line means L2 worked recently.

tracepath marks the hop that reported host unreachable with !H:

bash
tracepath -n 192.168.56.250
output
1?: [LOCALHOST]                      pmtu 1500
 1:  192.168.56.116                                      3053.043ms !H
     Resume: pmtu 1500

The !H on your own address matches the From 192.168.56.116 line from ping — local ARP failure, not a remote router.

Clear a stale FAILED entry only when you suspect a wrong MAC was cached, then retry:

bash
sudo ip neigh del 192.168.56.250 dev enp0s8

The next packet triggers a fresh ARP request. If the target truly does not exist, the entry fails again — that is expected.

Check gateway connectivity

When ip route get names a via gateway, that next hop must answer ARP or routing stops.

Ping the working default gateway on the internet-facing interface:

bash
ping -c2 -W2 10.0.2.2
output
PING 10.0.2.2 (10.0.2.2) 56(84) bytes of data.
64 bytes from 10.0.2.2: icmp_seq=1 ttl=64 time=0.488 ms
64 bytes from 10.0.2.2: icmp_seq=2 ttl=64 time=0.625 ms

--- 10.0.2.2 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1057ms

Replies confirm the NAT gateway on enp0s3 is reachable.

For a bad LAN gateway, neighbor state mirrors the ARP failure:

bash
ip neigh show 192.168.56.99
output
192.168.56.99 dev enp0s8 FAILED

With that gateway in the routing table, remote pings fail from the local host:

bash
ping -c2 -W3 8.8.8.8
output
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
From 192.168.56.116 icmp_seq=1 Destination Host Unreachable
From 192.168.56.116 icmp_seq=2 Destination Host Unreachable

--- 8.8.8.8 ping statistics ---
2 packets transmitted, 0 received, +2 errors, 100% packet loss, time 1016ms

Remove the dead default route and restore the working one:

bash
sudo ip route del default via 192.168.56.99 dev enp0s8

On DHCP-managed interfaces, let NetworkManager reinstall the correct gateway instead of hard-coding a wrong via address. For persistent DHCP profiles, nmcli connection modify <name> ipv4.never-default yes on secondary NICs can stop a LAN-only interface from stealing the default route.

Verify connectivity

After fixing the neighbor, gateway, or target IP, rerun the same probes that failed.

LAN peer that previously had no ARP entry — use a real address you confirmed is up:

bash
ping -c2 -W2 192.168.56.220
output
PING 192.168.56.220 (192.168.56.220) 56(84) bytes of data.
64 bytes from 192.168.56.220: icmp_seq=1 ttl=64 time=0.968 ms
64 bytes from 192.168.56.220: icmp_seq=2 ttl=64 time=2.94 ms

--- 192.168.56.220 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1001ms

Confirm the neighbor cache shows a MAC for the peer:

bash
ip neigh show 192.168.56.220
output
192.168.56.220 dev enp0s8 lladdr 08:00:27:7b:9e:bd REACHABLE

REACHABLE with a lladdr line means L2 resolution succeeded — TCP services on that host are worth testing next.

Re-check routing after gateway changes:

bash
ip route show default
output
default via 10.0.2.2 dev enp0s3 proto dhcp metric 116

For multi-hop paths, traceroute or tracepath helps confirm which hop first returns !H or stops replying — useful when the error comes from an upstream router rather than your own ARP cache.

Message Route in ip route get Typical From in ping Fix layer
Destination host unreachable Shows dev or via Own IP (ARP/gateway) or gateway IP Neighbor, gateway, target host
Network is unreachable Fails with RTNETLINK (ping may not get far) Add route or default gateway
No route to host (TCP) Often shows dev / via Same underlying failure as above Same as destination host unreachable
Connection refused Shows dev / via N/A — TCP RST instead Start service / fix bind address
Connection timed out May show route No ICMP — silent DROP Firewall or dead path mid-network

ping to an unused LAN address and ssh to the same address illustrate the wording split:

bash
ping -c2 -W3 192.168.56.250 2>&1 | tail -3
output
--- 192.168.56.250 ping statistics ---
2 packets transmitted, 0 received, +2 errors, 100% packet loss, time 1053ms

The same address over SSH shows the TCP-layer wording:

bash
ssh -o ConnectTimeout=5 root@192.168.56.250 exit 2>&1
output
ssh: connect to host 192.168.56.250 port 22: No route to host

Fix delivery — not DNS, not open ports — then retest with the application you care about.

Troubleshooting

Symptom Likely cause Fix
From own IP; ip neigh shows FAILED No ARP reply — wrong IP, host down, VLAN Verify target IP; check switch/VLAN; power on peer
From own IP; gateway FAILED in ip neigh Wrong or offline default gateway Correct via in routes; ping gateway IP; fix DHCP/router
From gateway IP Upstream router cannot reach next hop Trace with tracepath; fix routing on router or use different path
LAN works; remote fails after route change Bad default via on wrong interface ip route show; remove stray default; set metric on secondary NICs
ip route get → Network is unreachable No route at all Network is unreachable
TCP no route to host; ping destination host unreachable Same ARP/gateway issue Fix neighbors first — not firewall REJECT on a single port
Intermittent STALE then FAILED Roaming VM MAC, Wi-Fi roam, bond failover ip neigh del; stabilize L2; check duplicate IP
Interface DOWN / no LOWER_UP Cable, NIC disabled, parent bridge down ip link set dev up; fix hypervisor vSwitch

References

Summary

Destination host unreachable means a route was selected but the packet could not be delivered — the kernel or a gateway sent ICMP host unreachable back. ping exposes it in the From line; ssh and bash /dev/tcp often say no route to host for the same underlying failure.

Start by reading who returned the error. Your own address in From usually points to ARP failure on a directly connected subnet or an unreachable gateway in ip route get. Check ip -br link and the address on the outbound interface, then ip neigh show for FAILED entries on the target or gateway IP.

Restore a reachable default route, clear stale neighbors when MACs change, and verify with ping and ip neigh showing REACHABLE before you debug application ports. When ip route get itself fails, switch to network is unreachable. When TCP connects but fails with connection refused, the path works — see connection refused for listeners and services.

Frequently Asked Questions

1. What does destination host unreachable mean on Linux?

An ICMP host-unreachable message came back on the path. ping prints From Destination Host Unreachable. A route existed, but the next hop or final host could not be reached — often ARP failure on the LAN or an unreachable gateway.

2. How do I know whether my host or the gateway returned the error?

Read the From field in ping output. From your own IP means the local kernel gave up — usually ARP failed or the configured gateway does not answer. From the gateway IP means the router reported that the remote host or next hop is down.

3. How is destination host unreachable different from network is unreachable?

Network is unreachable means the kernel has no route for the destination. Destination host unreachable means a route was chosen but delivery failed at layer 2 or 3 — neighbor resolution, wrong gateway, or an upstream ICMP unreachable.

4. Why does ping say destination host unreachable but ssh says no route to host?

Both stem from the same underlying delivery failure. ping surfaces the ICMP wording. ssh and bash /dev/tcp map the errno to no route to host. Fix ARP, the gateway, or the target host — not DNS.

5. Will flushing ARP fix destination host unreachable?

Flushing a stale FAILED neighbor entry can help when the MAC changed or a VM moved. It does not fix a powered-off host, wrong IP, or dead gateway — verify ip neigh and ping the gateway first.
Deepak Prasad

R&D Engineer

Founder of GoLinuxCloud with more than 15 years of expertise in Linux, Python, Go, Laravel, DevOps, Kubernetes, Git, Shell scripting, OpenShift, AWS, Networking, and Security. With extensive experience, he excels across development, DevOps, networking, and security, delivering robust and efficient solutions for diverse projects.

Expertise
  • Go (programming language)
  • Python (programming language)
  • DevOps
  • Computer Security
  • Cloud Computing
  • Kubernetes
  • Linux
  • Ansible (software)

Related Articles

linux

Troubleshoot Default Routes in Linux

Troubleshoot Linux default route problems by reading ip route show default and ip route get, understanding …

9 min readlinux

Fix Network Is Unreachable on Linux

Fix network is unreachable on Linux by checking link state and IP addresses, reading ip route get, restoring a …

9 min readlinux

Fix NetworkManager Device Unmanaged on Linux

Fix NetworkManager device unmanaged on Linux by reading nmcli device state and reason codes, checking …

8 min read