Linux is more often than not a hassle-free operating system to use. However, no OS on the planet is immune to networking issues, and the same stands true for Linux.
In this article, we’re looking at the “no route to host” error in Linux, its causes and how you can fix the problem.
What causes the ‘no route to host’ issue?
The error is primarily triggered when the network, server or host you’re trying to connect to you is not responding. It could indicate an inactive internet connection, incorrectly set up router profiles or any number of settings that can restrict your access to the particular server you’re trying to reach.
Also read: How to change file permissions recursively using Chmod in Linux?
How to fix the ‘no route to host’ issue?
Here are six solutions to try out and fix the no route to host issue.
Check your internet connection
Minecraft requires an active internet connection to work. If you have an unstable internet connection, chances are you’re going to miss out on notifications. Suppose you’re on WiFi check to see if you’ve got internet access and strong signals. If you’re on mobile data, check to see if data is enabled and that you’ve got good network coverage.
Incorrect network or host configuration files
Linux uses a bunch of configuration files to define several rules, which it then uses to connect to either the internet or a dedicated host over the internet or even your local network. Check to see if these files are in order and allow outgoing connections. Be sure to check the following three files at least:
/etc /hosts /etc /hosts.allow /etc /hosts.deny
Check your services
The most obvious thing can be whether the service you’re trying to connect to you is running or not. If you’re trying to connect to an external server, check its status to see if it’s running or not.
If you’re operating a server yourself, use the systemctl command to see if the service is running.
sudo systemctl status [service name]
Also read: How to rename a directory in Linux?
Check the port
If the service is online, the next point of failure is most likely the port you’re connecting to. Most services change their default port as a security measure to avoid attackers from snooping in and causing damage. Check to see if you’re using the right port number.
If you’re using your server, try using NMAP to determine which port your service is running using the following command.
sudo nmap -sS [your server's IP]
Check IPTables
Another possible reason for the error could be IPTables blocking connections on the port the service is trying to communicate through. Check to see if the service is allowed to get through IPTables.
sudo iptables -S
DNS issues
If you can ping your server’s IP address but can’t resolve the domain name, you’re most likely facing a DNS issue. In most cases, your PC will fetch DNS information automatically using DHCP, but things can be different if you’re using static IP assignments.
Here’s how you can set up your DNS manually.
Step 1: Navigate to the following directory and open the resolved.conf file.
/etc/systemd/
Step 2: Uncomment the DNS= line and add your router’s default IP.
If you’re using OpenRC or any other systemd alternative, your DNS files will be in /etc/resolve.conf. Once you’ve updated the rules, try restarting your router and PC.
Also read: How to access command line history on Linux?
Someone who writes/edits/shoots/hosts all things tech and when he’s not, streams himself racing virtual cars.
You can contact him here: [email protected]
When you’re trying to connect to a service on Linux, “No route to host” is one of the last things you want to hear. It’s a broad message that means your computer can’t reach the target server, whether a local server daemon running on your system or a remote server that you can’t access for whatever reason. Here we show you how to fix the “no route to host” connection error in Linux.
Why Am I Getting the “No Route to Host” error?
There are many reasons why you could be getting that error. Networking in Linux is a somewhat complicated stack that’s pretty intricate, and as a result, it’s tough to determine exactly where the issue is.
Host Is Offline/Service Isn’t Running
It may seem painfully obvious, but you should first check that the server that you’re trying to connect to is even online. It might have been taken down for maintenance or be experiencing issues.
The service itself might not have been started. If it’s your server, you can check to see if the service has been started and is running properly. To do that with Systemd, run the following command.
sudo systemctl status SERVICENAME
Wrong Port
You may be trying to connect on the incorrect port. Many system administrators choose to run commonly targeted services like SSH on different ports to help thwart would-be attackers.
If the server isn’t your own, check the available documentation or contact their support services.
For your own server, you can try using NMAP to figure out where you started your service.
sudo nmap -sS your.server.ip
If you think you used a really obscure port, you can use the -p- flag to scan them all. It will take a while though.
Iptables Is Blocking the Connection
You may have accidentally configured iptables to block connections on that port. You would receive the same message whether you configured iptables on the server or your desktop, so it’s worth checking both. To see your iptables rules, run the following command.
Your DNS Is Improperly Configured
If all else fails, you should try to ping the IP address that you’re looking to connect to. It could be that your computer isn’t connecting to a DNS server properly.
If the ping works but connecting a domain name doesn’t, you’re looking at a DNS issue.
Systemd users can run systemd-resolve --status to check the DNS servers that your system is using. It’s broken down by interface, so make sure to check the one that you’re actually trying to connect through.
In most cases your computer will discover the relevant DNS information over DHCP. If you’re using a static IP or something on your network is configured differently, you may have to set your DNS manually.
Open “/etc/systemd/resolved.conf.” In that file, uncomment the DNS line and add either the IP of your router or another known DNS server. The default fallback DNS for Systemd is Google’s DNS servers listed under FallbackDNS.
If you’re using OpenRC or another Systemd alternative, you can find your DNS information in “/etc/resolv.conf.”
If there’s nothing there, enter the IP address of your router or any other known DNS server that you’d prefer to use.
After, either restart networking or your entire computer.
The GUI Way
If you’re using a graphical desktop with Network Manager, you can edit your connection information that way. Open the applet or go through your system settings. Select your connection and find the “IPv4” tab. Switch the connection to “Manual” and manually enter in the IP address of your computer and the IP of your router as the gateway. Then, in the DNS field below, enter your router’s IP or the IP of another DNS server.
Incorrect Network or Host Configuration
There are several other configuration options that may be incorrect. Any of them would make it impossible for your computer to connect to the server.
First, make sure that your computer’s network configuration is correct. Double-check the configuration files themselves and, of course, see if you can connect to the Internet another way.
If you’re using a specific hostname to connect or you’ve set up specific hosts on either the server or the client, you need to make sure both machines can connect to each other. Check the configurations of “/etc/hosts,” “/etc/hosts.allow,” and “/etc/hosts.deny.”
Finally, check your server configuration. Something may be improperly configured on the server, preventing clients from connecting properly.
Hopefully, using these tips has allowed you to fix whatever issues were happening that caused the “No Route to Host” error. Meanwhile, you can learn how to control your Wi-Fi network in Linux or check if your firewall is blocking any incoming and outgoing connection.
John Perkins
John is a young technical professional with a passion for educating users on the best ways to use their technology. He holds technical certifications covering topics ranging from computer hardware to cybersecurity to Linux system administration.
Subscribe to our newsletter!
Our latest tutorials delivered straight to your inbox
Overview
This issue happens when a network request is attempted to a remote host, and an error is thrown containing the phrase No route to host, or the error code EHOSTUNREACH.
Check RunBook Match
This runbook is limited to Linux hosts, although some steps may help trigger productive investigations on other OSes.
Initial Steps Overview
-
Gather information
-
Is host up?
-
Is the port open?
-
Check IPTables / NetFilter
-
Check routing tables
-
Check intervening firewalls
Detailed Steps
1) Gather information
1.1) Determine the host
Determine the host (or IP) you are trying to reach.
From here, this host will be referred to as [HOST|IP].
1.2) Determine the IP
Once you have the hostname, then you can determine the IP address by running:
which outputs, eg:
[HOST] has address 151.101.0.81
[HOST] has address 151.101.128.81
[HOST] has address 151.101.64.81
[HOST] has address 151.101.192.81
[...]
You can take the first address returned as the IP to use, eg for the above output, 151.101.0.81 would be the IP.
If you can find out the ‘correct’ IP that you are trying to reach by some means independent from your machine, do so. This might involve contacting another user, or figuring out the IP address by introspecting on the host.
1.3) Determine the port
Determine the port you are trying to reach.
If this is a ‘standard’ web request, then the port is either 80 (for http requests) or 443 (for https requests).
If the web request hits a non-standard port, then you will see :[NUMBER] in the URL, eg:
https://example.com:8443/path/to/site
would mean you are trying to contact port 8443.
This will be referred to subsequently as [PORT].
1.4) Determine the frequency of the problem
Try and work out if the problem happens every time, or is intermittent.
If it’s intermittent, consider whether there are multiple hosts that could be ultimately reached by the request (eg behind a load balancer), and whether one of these hosts is faulty.
2) Is host up?
Check whether the host you are trying to reach is up.
2.1) Use nmap
Run:
If you see output that begins like this:
Starting Nmap 7.80 ( https://nmap.org ) at 2020-06-19 10:11 BST
then you have nmap installed. If you don’t then you will need to install it. Wait for the command to return.
If you see a message in output like:
Failed to resolve "[HOST|IP]".
then this is a DNS lookup failure. See the DNS Lookup Failure runbook.
If you see output that mentions Host is up, like this:
Nmap scan report for [HOST] ([IP])
Host is up (0.016s latency).
Other addresses for [HOST] (not scanned): [IP2] [IP3]
Not shown: 998 filtered ports
PORT STATE SERVICE
80/tcp open http
443/tcp open https
Nmap done: 1 IP address (1 host up) scanned in 11.20 seconds
then the host you are trying to contact is up.
2.2) Use ping
If you can not install nmap, then you can try to ping the host:
2.3) Use nmap on the IP
If you are certain of the IP you are trying to connect to, you can try using nmap to access that host directly as per step 2.1. If the output differs from that of step 2.1, then you may have an issue with DNS lookup for the host not returning the correct IP address.
If you do, then this is likely due to a DNS server local to your network being misconfigured. Correcting this is outside the scope of this runbook, and will likely require you to contact the person responsible for that DNS server.
3) Is the port open?
There are two ways of determining this — from the client host and from the remote host.
3.1) From client
Run this command, and check the output:
If the command hangs with output like:
Trying 151.101.64.81...
then you can only say that the connection is not being explicitly rejected by the remote host. Where the connection is being stopped/dropped is impossible to say. It could be:
-
by a local firewall
-
by an intervening host/firewall
-
by the remote host’s firewall
If the request returns with a message like:
telnet: Unable to connect to remote host: Connection refused
then the request reached a remote host, and was explicitly refused.
If you connect, with a response like this:
Trying 151.101.0.81...
Connected to [HOST]
Escape character is '^]'.
Then the issue appears to be resolved. If your application is still having the same problem, then check the IP address it is trying to reach matches the IP address above.
3.2) From remote host
There are several ways to determine whether a given port is open on your host.
netstat
netstat -ln | grep -w tcp | grep -w [PORT]
If the output looks like this:
tcp 0 0 0.0.0.0:[PORT] 0.0.0.0:* LISTEN
then the port is open on all network interfaces (that’s what 0.0.0.0 means). If you see another set of numbers in place of the 0.0.0.0:[PORT], then .
Similarly, if you see something else in place of the 0.0.0.0:* (the ‘Foreign Address’), then the port may not be accessible only to clients from specific IP addresses. For example, if you see 127.0.0.1:* then it is only accessible from the localhost (using any port).
ss
ss -ln | grep -w tcp | grep -w [PORT]
Which produces similar output:
tcp LISTEN 0 128 0.0.0.0:22 0.0.0.0:*
- telnet
You can try connecting direct to the port using telnet, as per step 3.1. However be aware that this just proves that you can connect from the same host (see notes on interfaces in this section above).
3.3) Conclusions
If:
-
the port appears to be open from the point of view of the remote host
-
the port appears to be closed from the point of view of the client
this suggests that there is an intervening firewall that is blocking requests from reaching the server.
The firewall may be on the remote host.
4) Check IPTables / NetFilter
First, if you want to (optionally) know whether you are using IPTables or NetFilter, go here.
To determine your IPTables/NetFilter rules and whether they affect your port or host, run as root:
iptables -S | grep -w [PORT]
iptables -S | grep -w [IP]
iptables -S | grep -w [HOST]
If any lines match, then IPTables may be blocking or redirecting your attempts to connect to the remote server.
Understanding IPTables more deeply to fully debug this is outside the scope of this article. There are many resources on the web that attempt to explain it for various levels of experience.
5) Check routing tables
At this point, you may want to consider whether your routing tables are misconfigured.
This command gives a list of your machine’s routes:
If the ip command is unavailable, try route:
Determining whether the routing tables are correctly configured requires more network knowledge than can be reasonably placed here, and likely some knowledge of the local network topology.
There are many good resources on the internet for this, see Further Information below for links.
6) Check intervening firewalls
At this point you’ve checked connectivity at your client machine and the server. Now it is worth considering whether there is an intervening firewall between client and server blocking the connection.
- Local firewall (ie on way out)
We have already considered IPTables/NetFilter, but it is possible that there is some other kind of firewall running on your host that is preventing egress.
- If you are using AWS, or any other cloud provider…
then consider whether there are network rules set up to prevent egress. On AWS these come in the form of ‘Security Groups’ and ‘Network ACLs’.
- External/3rd party firewall
Any number of firewalls/hosts may be relaying your request to the destination host. Any of these may be blocking the request from going further.
Using traceroute might be considered at this point to determine which (and how many) hosts are being hit may help you debug further. See here for more background on this tool.
Check Resolution
If the application no longer reports this error, then this issue is resolved.
Further Steps
None.
Further Information
This error originates from the Linux kernel, eg in:
net/9p/error.c:114: {"No route to host", EHOSTUNREACH},
It can be thrown within the kernel for a number of different reasons, which makes interpreting the error tricky.
Routing tables
Owner
Ian Miell
There are three machines in this scenario:
- Desktop A : user@1.23.x.x
- Laptop A : user@1.23.y.y
- Machine B : user@192.168.z.z
All the machines have Ubuntu 11.04 (Desktop A is a 64bit one) and have both openssh-server and openssh-client.
Now when I try to connect Desktop A to Laptop A or vice-versa by ssh user@1.23.y.y I get an error as
port 22: No route to host
in both the cases.
I own both the machines, now if I try same commands from my friend’s machine, i.e. via Desktop B, I can access both my Laptop and Desktop. But if I try to access Desktop B from my Laptop or by Desktop I get
port 22: Connection timed out
I even tried changing ssh port no. in ssh_config file but no success.
Note: that ‘Laptop A’ uses WiFi connection while ‘Machine A’ uses Ethernet Connection and ‘Machine B’ is on an entirely different network.
@Lekensteyn Here it is ->
Laptop A && Desktop A -> Router/Nano_Rcvr provided to me by ISP. So to one Router two Machines are connected and can be accessed at the same time.
here is my ifconfig output for both the machines :-
Laptop
wlan0
Link encap:Ethernet HWaddr X:X:X:X:00:bc
inet addr:1.23.73.111 Bcast:1.23.95.255 Mask:255.255.224.0
inet6 addr: fe80::219:e3ff:fe04:bc/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:108409 errors:0 dropped:0 overruns:0 frame:0
TX packets:82523 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:44974080 (44.9 MB) TX bytes:22973031 (22.9 MB)
Desktop
eth0
Link encap:Ethernet HWaddr X:X:X:X:c5:78
inet addr:1.23.68.209 Bcast:1.23.95.255 Mask:255.255.224.0
inet6 addr: fe80::227:eff:fe04:c578/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:10380 errors:0 dropped:0 overruns:0 frame:0
TX packets:4509 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:1790366 (1.7 MB) TX bytes:852877 (852.8 KB)
Interrupt:43 Base address:0x2000
Output of ip route show
1.23.64.0/19 dev wlan0 proto kernel scope link src 1.23.73.111 metric 2
169.254.0.0/16 dev wlan0 scope link metric 1000
Output of traceroute -n 1.23.73.111
traceroute to 1.23.73.111 (1.23.73.111), 30 hops max, 60 byte packets
1 1.23.68.209 3008.787 ms !H 3008.786 ms !H 3008.784 ms !H
It must be annoying when you try to connect to a server in Linux and see an error message on your screen ‘no route to host.’ There is no need to worry, as you can fix the issue yourself. However, you need to find out and identify the actual cause. Usually, no route to host in Linux occurs when there is a problem with the network, or the setup is incorrect. Hence, before you try to identify the cause of the error message, check whether you have the proper network settings and whether there is the correct configuration of the DNS.
The “No Route to Host” error is usually caused by a routing issue. This can be caused by the network connection between your computer and the internet or an issue with your DNS settings. It can also happen if the user has not set up their network properly and is not connected to a network.
Steps to Resolve “No Route to Host Error Message in Linux”
Configure the DNS:
- The first step to resolving the DNS is by running the command, system-resolve-status
- If you find any problem, you must return to your network configuration and redo it. The DNS will configure automatically if you use a standard network with a dynamic IP.
- To manually update the DNS, you must go to Network Manage and enter the IP address in the IPv4 tab.
- After the process, you must restart the computer to get the correct settings.
Check the Host Connection:
Sometimes due to server issues, the host connection may not function properly. Therefore, before trying to resolve the error message, check whether the internet service is running or not. It is one of the most frequent causes that can happen due to some maintenance or other issues. Hence, if you want to check the status of the host connection, the following are the steps:
- Run the command ‘sudo systemctl status servicename.
- If you find the service is running, you need to identify other causes of the error message.
Check the Ports:
If you find that the service is running smoothly, then the next step is to check the cables. It is most likely that the port you are using is not apt. Most of the services change their default port for security reasons, a measure to avoid hackers causing damage to the network. However, you must install a security tool if you are trying to connect from your server. NMAP helps you to see the standard ports. Once you install NMAP, you need to check the standard ports through the command Sudo Nmap -sS target server-IP. If it does not work, you need to contact the host.
Check the hostname:
You may get a host-to-connect error if your computer and server that you are combining have a different hostname. To resolve the issue, you need to configure both to one another. You must also check the host denies and host allows files as it sometimes blocks the connection. Hence, when connecting to a new server, check whether you have the correct hostname.
Iptables – Check if it is blocking the connection:
Iptables are pretty helpful for the configuration of the Linux kernel firewall tables. The tables control the ins efficiently and out of traffic to your computer. However, if there is a configuration error, it can block the connection and give rise to the error message, ‘no route to host.
- Check a list of the iptables by typing sudo iptables -L and pressing Enter
- Run the command sudo iptables-S. It will let you know whether the iptables are blocking your network or not.
- You can also clear the firewall by typing the command sudo iptables –F
How Can You Fix Port 22: No Route to Host?
One of the most common errors you encounter while using SSH is ‘connect to host port 22, no route to host. One of the prime reasons for connection errors can be the server being down. You can do so by running the ping command. If the ping command results run smoothly, you need to check for other reasons for the error message. The other reason for the ‘host connect error’ statement can be the firewall blocking your system.
How to Resolve the Error Message ‘telnet No Route to Host?
When you get an error message ‘telnet unable to connect to remote host: No route to host,’ it may be due to the presence of a firewall. The internal firewall of your machine may be enabled, causing the network connection blockage. To resolve the issue, you need to follow the given below steps:
- Update the /etc/sysconfig/iptables to restart the iptables service.
- Check the policies by typing the command iptables -L
- You need to check ports 111 and 2049 to enable the telnet ports
- Quit the application.
How to Fix Ftp: Connect: No Route to Host?
While setting up the FTP server on Linux, you may get an error message, “no route to host”. It is a common issue, and you can easily resolve it once you identify it. The primary cause of the error may be the ip_conntrack_ftp kernel module missing. Following are the steps to resolve the error message:
- Add the command line ‘IPTABLES_MODULES=”ip_conntrack_ftp”
- Save it and restart your computer.
You will see that the connection has been resolved and running smoothly. However, time and again, you need to check the FTP connections and iptables as sometimes they block the link to your network.
When Do You Get the Message ‘Curl No Route to Host?
When you get a curl error, it means there is a block in the permission of your network connection. It may be due to many reasons. However, the most common issue of a curl error message may be due to the presence of a firewall. You may face the problem whenever the curl request is not at par with the standard ports. You may encounter an error message if you curl to a URL on port 1234. However, if you curl to port 80, you may get a positive result. It can resolve if you are issued the error message ‘curl no route to host.’
How to Fix Failed to Load Board Configuration Connection Error?
When you try to load any thread from the main site, you may find it broken and get the message ‘failed to load board configuration connection error .’To resolve the issue, you can first check the connection to see if it is running smoothly. Sometimes, you can get error messages when there is a glitch in the network.
Once you are sure about the connection, the next step is temporarily disabling all the extensions and user scripts. Here, you will understand the actual cause of the error message. You can also uninstall your previous Firefox and install the new version.
Conclusion
‘No route to host error message is the last thing you want to see popping on your computer screen, and it stalls all the urgent work. However, it would be best if you were conversant with the typical error message so that it is easy for you to resolve it. The first thing you must keep in mind is to check the configuration of your system. You must follow the various steps above if everything is in the right spot. You will get a positive result and resolve the issue of the error message, ‘ssh no route to host.’
На чтение 2 мин Опубликовано 27.06.2019
SSH является наиболее безопасным средством удаленного подключения к серверам Linux.
И одной из распространенных ошибок, возникающих при использовании SSH, является «ssh: connect to host port 22: No route to host».
В этой короткой статье мы покажем, как устранить неполадки и исправить эту ошибку.
Вот скриншот ошибки, о которой мы говорим.
Обратите внимание, что порт не обязательно может быть портом 22, в зависимости от ваших настроек на удаленном хосте.
В качестве меры безопасности системные администраторы могут настроить доступ к SSH через другой порт:
Как изменить номер порта для ssh
Существуют разные причины возникновения этой ошибки.
Первый, как правило, заключается в том, что удаленный сервер может быть отключен, поэтому вам нужно проверить, работает ли он, используя команду ping.
# ping 192.168.56.100
Исходя из результатов команды ping, сервер запущен и работает, поэтому он принимает эхо-запросы.
В этом случае причина ошибки кроется в другом.
Если на удаленном сервере запущена служба брандмауэра, возможно, брандмауэр блокирует доступ через порт 22.
Поэтому вам необходим физический доступ к консоли сервера или, если это VPS, вы можете использовать любые другие средства, такие как VNC (если он уже настроен) или другие пользовательские приложения для удаленного доступа к серверу, предоставляемые вашим поставщиком услуг VPS.
Войдите в систему и получите доступ к командной строке.
Затем используйте firewall-cmd (RHEL / CentOS / Fedora) или UFW (Debian / Ubuntu), чтобы открыть порт 22 (или порт, настроенный для использования для SSH) в брандмауэре следующим образом.
# firewall-cmd --permanent --add-port=22/tcp # firewall-cmd --reload или $ sudo ufw allow 22/tcp $ sudo ufw reload
Теперь попробуйте снова подключиться к удаленному серверу через SSH.
Вот и все!
Вы также найдете полезными следующие руководства по SSH:
- ? Как подключить удаленные каталоги в Linux с помощью SSHFS
- Как создать туннелирование SSH или перенаправление портов в Linux
- ? Как создать алиас SSH в Linux
- ? Как проверить, открыт ли порт на нескольких удаленных системах Linux с помощью скрипта оболочки с помощью команды nc?
- Настройка SSH для упрощения вашей жизни
- Как ограничить максимальное количество соединений ssh в CentOS / RHEL
- Как защитить ssh в CentOS / RHEL / Fedora
Пожалуйста, не спамьте и никого не оскорбляйте.
Это поле для комментариев, а не спамбокс.
Рекламные ссылки не индексируются!