The 2:00 AM Connection Wall
It is the middle of the night. You are trying to push a critical hotfix to a production node, but your SSH terminal just stares back at you. Instead of a password prompt, you get a blunt rejection:
ssh: connect to host 192.168.1.100 port 22: No route to host
This error is frequently misunderstood. It differs from "Connection refused," which occurs when a server is reachable but no service is listening. "No route to host" indicates a harder break in the network stack. Somewhere between your keyboard and the server's disk, a device is actively reporting that the destination cannot be reached.
Isolate the Breakpoint
Avoid the temptation to reboot routers or flip IP addresses immediately. You need to find exactly where the packet dies. Is it your local machine, an intermediate router, or the target's internal security?
1. Test Basic Connectivity
Start with a simple ping. While security-hardened servers often ignore ICMP requests, a successful reply proves the physical and virtual wiring is intact.
ping -c 4 192.168.1.100
Pay attention to the specific response. If the terminal says Destination Host Unreachable, your local machine doesn't know which gateway to use. If it specifically says No route to host, you are likely receiving a "Communication Prohibited" packet from a firewall.
2. Inspect the Routing Table
Verify your local path using ip route show. You need to ensure your machine knows how to handle the 192.168.1.0/24 subnet.
ip route show
Look for your target's subnet. If traffic for 192.168.1.100 is defaulting to a public-facing interface (like eth0) instead of your management VPN (like tun0), the packet will never arrive.
The Usual Suspect: The Software Firewall
More often than not, this error stems from the target's firewall configuration. Linux firewalls usually handle traffic in two ways: DROP or REJECT. A DROP causes your connection to time out silently. A REJECT, however, sends back a small ICMP packet that tells your client the route is closed. This is what triggers the error message.
Fixing RHEL/CentOS/Fedora (Firewalld)
On Red Hat-based systems, firewalld often blocks everything by default except for specific services. To verify if this is the bottleneck, try stopping the service briefly on a secure network:
sudo systemctl stop firewalld
If SSH connects instantly, restart the firewall and explicitly permit port 22:
sudo systemctl start firewalld
sudo firewall-cmd --permanent --add-service=ssh
sudo firewall-cmd --reload
Fixing Ubuntu/Debian (UFW)
Ubuntu users should check the Uncomplicated Firewall status:
sudo ufw status
If the status is active but port 22 is missing from the list, run these commands to open the gates:
sudo ufw allow 22/tcp
sudo ufw reload
The Subnet Trap
Mismatched masks can lead to total silence. I once spent three hours debugging a server that had two network cards assigned to overlapping 10.0.0.0/24 subnets. The kernel got confused and tried to send return traffic out the wrong port, resulting in a "No route" error for anyone trying to connect.
Pro-Tip: Double-check your CIDR math before committing to a static IP. I use this Subnet Calculator to visualize host ranges and broadcast addresses. It’s a fast, browser-based tool that prevents simple typos from turning into network-wide outages.
Final Verification
Never assume the fix worked just because one command succeeded. Use nc (netcat) to check the port's health from a different machine or subnet:
nc -zv 192.168.1.100 22
A successful connection will return:
Connection to 192.168.1.100 22 port [tcp/ssh] succeeded!
Key Takeaways
- Reject vs. Drop: If you see "No route to host," look for an active
REJECTrule. If you see a timeout, look for aDROPrule. - Return Paths: Ensure your firewall allows
ESTABLISHED,RELATEDtraffic, or the server won't be able to talk back to you. - Log Hunting: Check
/var/log/syslogorjournalctl -u sshon the target. If the service isn't even running, the network path doesn't matter. - VLAN Mismatches: If you are connecting from a VPN, ensure the firewall allows the specific IP range of your VPN gateway, not just the local LAN.