Advisory: This site contains documentation for the v1.12 release candidate version of Docker Engine. For the Docker Engine v1.11 docs, see https://docs.docker.com/v1.11/. Docker for Mac and Docker for Windows are currently in Beta.
The information in this section explains container communication within the
Docker default bridge. This is a
bridge network named
automatically when you install Docker.
Note: The Docker networks feature allows you to create user-defined networks in addition to the default bridge network.
Whether a container can talk to the world is governed by two factors. The first
factor is whether the host machine is forwarding its IP packets. The second is
whether the host’s
iptables allow this particular connection.
IP packet forwarding is governed by the
ip_forward system parameter. Packets
can only pass between containers if this parameter is
1. Usually you will
simply leave the Docker server at its default setting
Docker will go set
1 for you when the server starts up. If you
--ip-forward=false and your system’s kernel has it enabled, the
--ip-forward=false option has no effect. To check the setting on your kernel
or to turn it on manually:
$ sysctl net.ipv4.conf.all.forwarding net.ipv4.conf.all.forwarding = 0 $ sysctl net.ipv4.conf.all.forwarding=1 $ sysctl net.ipv4.conf.all.forwarding net.ipv4.conf.all.forwarding = 1
Note: this setting does not affect containers that use the host network stack (
Many using Docker will want
ip_forward to be on, to at least make
communication possible between containers and the wider world. May also be
needed for inter-container communication if you are in a multiple bridge setup.
Docker will never make changes to your system
iptables rules if you set
--iptables=false when the daemon starts. Otherwise the Docker server will
append forwarding rules to the
DOCKER filter chain.
Docker will not delete or modify any pre-existing rules from the
chain. This allows the user to create in advance any rules required to further
restrict access to the containers.
Docker’s forward rules permit all external source IPs by default. To allow only
a specific IP or network to access the containers, insert a negated rule at the
top of the
DOCKER filter chain. For example, to restrict external access such
that only source IP 184.108.40.206 can access the containers, the following rule
could be added:
$ iptables -I DOCKER -i ext_if ! -s 220.127.116.11 -j DROP
where ext_if is the name of the interface providing external connectivity to the host.
Whether two containers can communicate is governed, at the operating system level, by two factors.
Does the network topology even connect the containers’ network interfaces? By default Docker will attach all containers to a single
docker0 bridge, providing a path for packets to travel between them. See the later sections of this document for other possible topologies.
iptables allow this particular connection? Docker will never make changes to your system
iptables rules if you set
--iptables=false when the daemon starts. Otherwise the Docker server will add a default rule to the
FORWARD chain with a blanket
ACCEPT policy if you retain the default
--icc=true, or else will set the policy to
It is a strategic question whether to leave
--icc=true or change it to
--icc=false so that
iptables will protect other containers -- and the main
host -- from having arbitrary ports probed or accessed by a container that gets
If you choose the most secure setting of
--icc=false, then how can containers
communicate in those cases where you want them to provide each other services?
The answer is the
--link=CONTAINER_NAME_or_ID:ALIAS option, which was
mentioned in the previous section because of its effect upon name services. If
the Docker daemon is running with both
then, when it sees
docker run invoked with the
--link= option, the Docker
server will insert a pair of
ACCEPT rules so that the new
container can connect to the ports exposed by the other container -- the ports
that it mentioned in the
EXPOSE lines of its
Note: The value
--link=must either be an auto-assigned Docker name like
stupefied_pareor else the name you assigned with
--name=when you ran
docker run. It cannot be a hostname, which Docker will not recognize in the context of the
You can run the
iptables command on your Docker host to see whether the
FORWARD chain has a default policy of
# When --icc=false, you should see a DROP rule: $ sudo iptables -L -n ... Chain FORWARD (policy ACCEPT) target prot opt source destination DOCKER all -- 0.0.0.0/0 0.0.0.0/0 DROP all -- 0.0.0.0/0 0.0.0.0/0 ... # When a --link= has been created under --icc=false, # you should see port-specific ACCEPT rules overriding # the subsequent DROP policy for all other packets: $ sudo iptables -L -n ... Chain FORWARD (policy ACCEPT) target prot opt source destination DOCKER all -- 0.0.0.0/0 0.0.0.0/0 DROP all -- 0.0.0.0/0 0.0.0.0/0 Chain DOCKER (1 references) target prot opt source destination ACCEPT tcp -- 172.17.0.2 172.17.0.3 tcp spt:80 ACCEPT tcp -- 172.17.0.3 172.17.0.2 tcp dpt:80
Note: Docker is careful that its host-wide
iptablesrules fully expose containers to each other’s raw IP addresses, so connections from one container to another should always appear to be originating from the first container’s own IP address.