How to configure Centos 7 firewallD to allow docker containers free access to the host’s network ports?

I have docker installed on CentOS 7 and I am running firewallD.

From inside my container, going to the host (default 172.17.42.1)

With firewall on

container# nc -v  172.17.42.1  4243
nc: connect to 172.17.42.1 port 4243 (tcp) failed: No route to host

with firewall shutdown

container# nc -v  172.17.42.1  4243
Connection to 172.17.42.1 4243 port [tcp/*] succeeded!

I’ve read the docs on firewalld and I don’t fully understand them. Is there a way to simply allow everything in a docker container (I guess on the docker0 adapter) unrestricted access to the host?

Answers:

Thank you for visiting the Q&A section on Magenaut. Please note that all the answers may not help you solve the issue immediately. So please treat them as advisements. If you found the post helpful (or not), leave a comment & I’ll get back to you as soon as possible.

Method 1

Maybe better than earlier answer;

firewall-cmd --permanent --zone=trusted --change-interface=docker0
firewall-cmd --permanent --zone=trusted --add-port=4243/tcp
firewall-cmd --reload

Method 2

Theses commands did the trick:

firewall-cmd --permanent --zone=trusted --add-interface=docker0
firewall-cmd --permanent --zone=trusted --add-port=4243/tcp

Method 3

One reason the accepted solution works for some people but not for others lies in a design issue of firewalld. Firewalld only processes the first matching zone for any connections. It also processes zones based on IP address before zones based on interfaces. As long as any of your zones happens to include the IP addresses docker is using, the ACCEPT rule in the trusted zone will never get processed.

To verify this, you can look at the generated iptables rules unless you are using the nbt backend:

iptables -vnL | less

The solution is to use a firewalld direct rule instead of the trusted zone. Direct rules are always processed first. For example, for port 3306 (i.e., mysqld on the local host), you’d need this rule:

/bin/firewall-cmd --direct --permanent --add-rule ipv4 filter INPUT 10 -p tcp --dport 3306 -i docker0 -j ACCEPT

If you repeat the same command without the –permanent switch, firewalld will make the change on the fly for you, and you should not need to restart docker.

A second reason is that, depending on the version of docker and the networking you configured, traffic may not actually flow across the docker0 interface, but through a separate bridge interface. You can see that interface with the command

ip address show

You will have to repeat the direct-rule statement above with this bridge interface.

You can also specify your own network in docker. This post describes the process: https://serverfault.com/questions/885470/how-to-configure-firewall-on-user-defined-docker-bridge

The short version is that you specify the networks section in a docker-file, like this:

version: '3'
  .
  .
  .
networks:
  mynetwork:
    driver_opts:
      com.docker.network.bridge.name: mynetwork_name

You can also do this on the command line.

Method 4

I had problems with this as well; this did the trick for me:

firewall-cmd --zone=public --add-masquerade --permanent

From:
https://serverfault.com/questions/987686/no-network-connectivity-to-from-docker-ce-container-on-centos-8

Method 5

Unfortunately, none of above solutions worked for me, one container was still not able to access another container.

Solution: disable firewalld

While I understand this is really bad, it actually works and the risks of disabled firewall can be mitigated my configuring iptables in the way you need.

sudo systemctl stop firewalld
sudo systemctl disable firewalld

Restarting docker is not needed, but just in case: sudo systemctl restart docker

Method 6

the following allowed docker to access the internet on CentOS 7 with firewalld

firewall-cmd --permanent --direct --add-rule ipv4 filter INPUT 4 -i docker0 -j ACCEPT
firewall-cmd --reload
systemctl restart docker

Method 7

I encountered the same issue, but putting docker0 in the Trusted Zone didn’t work since the traffic wasn’t coming from docker0. I actually had two docker related connections.

5: docker0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default 
    link/ether 02:42:f1:89:6d:6a brd ff:ff:ff:ff:ff:ff
    inet 172.17.0.1/16 brd 172.17.255.255 scope global docker0

6: br-2800c2ad17b6: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default 
    link/ether 02:42:8a:7d:85:d5 brd ff:ff:ff:ff:ff:ff
    inet 172.19.0.1/16 brd 172.19.255.255 scope global br-2800c2ad17b6

And inside the docker traffic was going over the bridge.

<a href="https://getridbug.com/cdn-cgi/l/email-protection" class="__cf_email__" data-cfemail="43312c2c37037677217572747a717a737470">[email protected]</a>:/# ip route show
default via 172.19.0.1 dev eth0 
172.19.0.0/16 dev eth0 proto kernel scope link src 172.19.0.27

Once I put br-2800c2ad17b6 in the trusted zone I was able to connect to the host.

All methods was sourced from stackoverflow.com or stackexchange.com, is licensed under cc by-sa 2.5, cc by-sa 3.0 and cc by-sa 4.0