Fix No Route to Host Errors

"No route to host" (EHOSTUNREACH) means the Linux kernel cannot find a network path to the destination. Unlike "connection refused" (server rejects) or "timed out" (no response), this error means the routing table has no matching entry. This guide covers diagnosing and fixing routing problems.

Understanding the Error

# The error occurs when:
# 1. No route exists in the routing table for the destination
# 2. A firewall is sending ICMP "host unreachable" messages
# 3. ARP resolution fails (can't find the MAC address)
# 4. The network interface is down

# Different from:
# "Network is unreachable" — no route to the network at all
# "No route to host" — network route exists but specific host unreachable

Step 1: Check Routing Table

# View routing table
ip route show
# or
route -n

# Check if there's a route for the destination
ip route get 10.0.0.50

# Expected output: "10.0.0.50 via 10.0.0.1 dev eth0 src 10.0.0.10"
# Bad output: "RTNETLINK answers: Network is unreachable"

# Check for default gateway
ip route | grep default
# Should show: default via X.X.X.X dev ethX

Step 2: Check Network Interface

# Is the interface up?
ip link show
ip addr show

# Check for carrier (physical link)
cat /sys/class/net/eth0/carrier  # 1=connected, 0=disconnected

# Bring interface up
sudo ip link set eth0 up

# Check for IP address assignment
ip addr show eth0 | grep inet
# If no IP, get one via DHCP
sudo dhclient eth0

Step 3: Check Firewall REJECT Rules

# iptables REJECT rules send ICMP "host unreachable"
# which causes "No route to host" on the client side
sudo iptables -L -n -v | grep REJECT
sudo iptables -L -n -v | grep icmp-host-unreachable

# nftables check
sudo nft list ruleset | grep reject

# Temporarily flush iptables to test
# WARNING: This removes all firewall rules
sudo iptables -P INPUT ACCEPT
sudo iptables -P FORWARD ACCEPT
sudo iptables -F

# If the connection works after flushing, the firewall was the issue

Step 4: Check ARP

# If the destination is on the same subnet, check ARP resolution
ip neigh show
# Look for the destination IP — status should be "REACHABLE" or "STALE"
# "FAILED" or missing = ARP is failing

# Manually add ARP entry (for testing)
sudo ip neigh add 10.0.0.50 lladdr aa:bb:cc:dd:ee:ff dev eth0

# Clear ARP cache
sudo ip neigh flush all

# Check for duplicate IP addresses
arping -D 10.0.0.50 -I eth0

Step 5: Trace the Path

# Trace where packets stop
traceroute -n 10.0.0.50
mtr -n 10.0.0.50

# Use TCP traceroute (if ICMP is blocked)
traceroute -T -p 80 10.0.0.50

# Check for asymmetric routing
# Packets might reach the destination but the reply takes a different path

Common Fixes

# Fix: Missing default gateway
sudo ip route add default via 10.0.0.1 dev eth0

# Fix: Missing route to specific network
sudo ip route add 192.168.1.0/24 via 10.0.0.1 dev eth0

# Fix: Interface down
sudo ip link set eth0 up
sudo dhclient eth0

# Fix: Firewall REJECT rule
sudo iptables -D INPUT -s 10.0.0.0/24 -j REJECT  # Remove the REJECT rule
sudo iptables -A INPUT -s 10.0.0.0/24 -j ACCEPT   # Replace with ACCEPT

# Fix: Make route persistent
# Debian/Ubuntu (/etc/netplan/01-config.yaml)
network:
  ethernets:
    eth0:
      routes:
        - to: 192.168.1.0/24
          via: 10.0.0.1

# RHEL/Rocky (/etc/sysconfig/network-scripts/route-eth0)
192.168.1.0/24 via 10.0.0.1

Best Practices

• Check routing table first: ip route get DESTINATION immediately shows if a route exists
• Distinguish REJECT from DROP: REJECT causes "no route to host"; DROP causes "timed out"
• Check interface status: A downed interface causes "no route to host" for its entire subnet
• Verify ARP: On local networks, ARP failures cause this error
• Make routes persistent: Routes added with ip route add are lost on reboot