4

Debugging a software problem, I detected a state where the attempt to make a TCP connection resulted in a "No route to host" error message. This was especially confusing as ping had no such problem:

# netcat -v 172.20.2.24 5565 netcat: connect to 172.20.2.24 port 5565 (tcp) failed: No route to host # ping 172.20.2.24 PING 172.20.2.24 (172.20.2.24) 56(84) bytes of data. 64 bytes from 172.20.2.24: icmp_seq=1 ttl=63 time=0.466 ms 64 bytes from 172.20.2.24: icmp_seq=2 ttl=63 time=0.470 ms ^C --- 172.20.2.24 ping statistics --- 2 packets transmitted, 2 received, 0% packet loss, time 1020ms rtt min/avg/max/mdev = 0.466/0.468/0.470/0.002 ms

In the end it turned out that the firewalld on the target host blocked the port (i.e.: did not allow it).

However from my memory I thought that blocked traffic would either

  • vanish in a "black hole", eventually causing connection timeouts, or
  • trigger an error like "connection refused" or "Connection reset"

but not "no route to host".

So I wonder: Was there a recent change, or is it simply a bug somewhere (incorrect error message being created)?

The system in question is SLES15 SP6 on x86_64, running Linux kernel 6.4.0-150600.23.25-default and firewalld-2.0.1-150600.3.2.1.noarch. Also between initiator and target there is one gateway host (just in case that might change the error code).

Further Thoughts

From the answers so far the source of the error code seems to be ICMP (Internet Control Message Protocol) as defined in RFC 792. For "type=3" (Destination Unreachable) there are four different "codes" related to this issue:

  1. 0: "net unreachable"
  2. 1: "host unreachable"
  3. 2: "protocol unreachable"
  4. 3: "port unreachable"

So I'd suggest that "code=3" would be the correct one, but "No route to host" seems to suggest that "code=1" is being used. See also "Destination unreachable" in "Internet Control Message Protocol" (Wikipedia).

Improve this question

2 Answers 2

Reset to default
3

It is not a bug, but the effect of the configuration of the firewall. The "no route to host" message is due to the firewall denying access via a ICMP message (target: REJECT) rather than just dropping the packet (target: DROP).

Since a ping command reaches correctly the remote host, the "no route to host" is not due to a missing route.

See also: No route to host with nc but can ping

Improve this answer
3

As this Superuser answer indicates, the firewalld in question was configured to not merely drop the packets destined for port 5565, but to return a REJECT response, which took the form of an ICMP error message. The ICMP messages are fairly generic, so the description of the error wasn't "Firewalld is blocking your traffic", but rather, "No route to host".

Firewalls are often configured to not bother trying to return a rejection reply. It's more common to silently drop the traffic. That's what you described as "vanish in a 'black hole'".

When firewalls and other network devices allow the traffic to reach the destination host but there's no service listening on the TCP port, the TCP stack at the destination usually returns a TCP error reply. That TCP error has the description "Connection refused".

Improve this answer
1
  • There is an ICMP message for "Firewall is blocking your traffic", but Linux still translates it to the "No route" system error code upon receipt for IPv4 (though it uses "Permission denied" for IPv6). Rarely anyone uses it. Commented Nov 22, 2024 at 5:21

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.