Docker - No route to host

Question

When i try and connect to a port from within my container to another container, i am unsuccessful and get,

root@ac1590a59fe5:/opt/f5massupgrade# curl -v https://172.17.0.1:6379
* Rebuilt URL to: https://172.17.0.1:6379/
* Hostname was NOT found in DNS cache
*   Trying 172.17.0.1...
* connect to 172.17.0.1 port 6379 failed: No route to host
* Failed to connect to 172.17.0.1 port 6379: No route to host
* Closing connection 0

From the docker host I am successful,

[root@docker-host ~]# curl -v https://172.17.0.1:6379/0
* About to connect() to 172.17.0.1 port 6379 (#0)
*   Trying 172.17.0.1...
* Connected to 172.17.0.1 (172.17.0.1) port 6379 (#0)
* Initializing NSS with certpath: sql:/etc/pki/nssdb
*   CAfile: /etc/pki/tls/certs/ca-bundle.crt
  CApath: none

If i check the iptables I can see the issue,

[root@docker-host ~]#  iptables -S INPUT
-P INPUT ACCEPT
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -p icmp -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -i docker0 -j ACCEPT
-A INPUT -p tcp -m state --state NEW -m tcp --dport 22 -j ACCEPT
-A INPUT -j REJECT --reject-with icmp-host-prohibited

So I add the following and it all works well,

iptables -I INPUT 4 -i docker0 -j ACCEPT

Am i missing something here?

[root@docker-host ~]# docker version
Client:
 Version:         1.9.1
 API version:     1.21
 Package version: docker-common-1.9.1-40.el7.centos.x86_64
 Go version:      go1.4.2
 Git commit:      ab77bde/1.9.1
 Built:
 OS/Arch:         linux/amd64

Server:
 Version:         1.9.1
 API version:     1.21
 Package version: docker-common-1.9.1-40.el7.centos.x86_64
 Go version:      go1.4.2
 Git commit:      ab77bde/1.9.1
 Built:
 OS/Arch:         linux/amd64

Thanks,

Answer 1

We hit this issue on a RHEL box which was running firewalld. The firewall was preventing container to host access (other than icmp traffic).

We needed to configure the firewall to allow traffic from the docker containers through to the host. In our case, the containers were in a bridge network on subnet 172.27.0.0/16 (determined via docker network ls and docker inspect <network-name>). Firewall rules for firewalld can be updated via:

firewall-cmd --permanent --zone=public --add-rich-rule='rule family=ipv4 source address=172.27.0.0/16 accept'
firewall-cmd --reload

This was a useful reference in resolving the issue.

Answer 2

If anyone is still stuck with this problem on CentOS 8 or any system using firewalld

try the following settings for firewalld

# Allows container to container communication, the solution to the problem
firewall-cmd --zone=public --add-masquerade --permanent

# standard http & https stuff
firewall-cmd --zone=public --add-port=80/tcp --permanent
firewall-cmd --zone=public --add-port=443/tcp --permanent
# + any other port you may need

# reload the firewall
firewall-cmd --reload

you may also need to restart the docker service if it does not work immediately, there's no need to add the docker0 interface onto the trusted zone as many of the guides I've gone through stated

I was struggling with setting up a Traefik reverse proxy for my docker containers, I only got 502 responses with a no route error to my container from Traefik logs. At first I thought it was my Traefik setup but it turned out it was the firewall restrictions as @al. mentioned. It pointed me in the right direction and I got my answer from https://serverfault.com/questions/987686/no-network-connectivity-to-from-docker-ce-container-on-centos-8

Answer 3

These worked for me on Fedora 32

$ sudo firewall-cmd --zone=public --add-masquerade --permanent
$ sudo firewall-cmd --reload
$ sudo systemctl restart docker

Answer 4

Try running the container with the flag --net set to host.

docker run --net host image 

Answer 5

Customizing of Kernel tunables below is solving issue "no route to host" between docker containers:

sysctl net.bridge.bridge-nf-call-iptables=0
sysctl net.bridge.bridge-nf-call-arptables=0
sysctl net.bridge.bridge-nf-call-ip6tables=0

These control whether or not packets traversing the bridge are sent to iptables for processing.

Note if you'll add it to sysctl.conf it may not automatically apply during reboot as known bug depending on your linux distribution.

Answer 6

For me the problem was conflicting MAC addresses... don't know how this could happen...

Answer 7

Removing non default docker bridge networks helps.

Use command docker network ls to see all docker networks.

Use command docker network rm <NETWORK_ID>

NOTE: networks named bridge, host and none are default ones.

Answer 8

Since docker will create a couple of networks, I would prefer to open all the related IPs.

# open all IPs starts with "172" so that all the containers may communicate each other
sudo firewall-cmd --permanent --zone=public --add-rich-rule='rule family=ipv4 source address=172.0.0.0/8 accept'
# make our container able to visit the network outside
sudo firewall-cmd --permanent --zone=public --add-masquerade
# apply the change
sudo firewall-cmd --reload

You may visit /etc/firewalld/zones/public.xml for your final result.

Here is my example:

<?xml version="1.0" encoding="utf-8"?>
<zone>
  <short>Public</short>
  <description>For use in public areas. You do not trust the other computers on networks to not harm your computer. Only selected incoming connections are accepted.</description>
  <service name="ssh"/>
  <service name="dhcpv6-client"/>
  <masquerade/>
  <rule family="ipv4">
    <source address="172.0.0.0/8"/>
    <accept/>
  </rule>
</zone>

And here is a detail description for the file. Edit this file and reload firewall may also works.

Hoping it helps.

Answer 9

In know this is an old question but I just had this issue an was able to resolve it with the help of this thread.

Thanks to Samuel, I checked whether any of my containers in my network had conflicting MAC addresses. That was the case and the cause of the issue.

Now the reason for the conflict was the usage of multiple networks in my compose file. I used the default network that gets created by every docker-compose as well joined an existing network.

The way docker chooses a MAC address is by starting at 02:42:ac:12:00:00 and just using the next address for each subsequent container. Apparently, this is done for every network individually. Docker choose the MAC address of my container based on the default network that was created with the compose. The resulting MAC was unique on the compose network, but already in use in the existing network it joined.

This issue has been described here and got resolved recently by introducing network priority.