I have troubles accessing a host private interface (ip) from a docker container. I'm fairly certain that it's related to my Iptables rules (or perhaps routing). When I add the --net=host flag to docker run, everything works as expected. Similarly when I specify that the INPUT policy is following a liberal -P INPUT ACCEPT, things also work as I would expect. However these are undesirable and unsafe options i'd like to avoid.

Since it's not specific to my services (DNS) I've excluded that from the problem, since searching for that in combination with docker yields in a different (popular) problem area, adding noise to the search results.

Also linking of Docker containers is not a viable option, because certain containers need to be run with the --net=host option, preventing linking and I want to create a consistent situation where possible.

I have the following Iptables rules. A combination of CoreOS, Digital Ocean and Docker I assume.

-A INPUT -i lo -j ACCEPT
-A INPUT -i eth1 -j ACCEPT
-A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A INPUT -p tcp -m tcp --dport 22 -j ACCEPT
-A INPUT -p icmp -m icmp --icmp-type 0 -j ACCEPT
-A INPUT -p icmp -m icmp --icmp-type 3 -j ACCEPT
-A INPUT -p icmp -m icmp --icmp-type 11 -j ACCEPT
-A FORWARD -o docker0 -j DOCKER
-A FORWARD -o docker0 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -i docker0 ! -o docker0 -j ACCEPT
-A FORWARD -i docker0 -o docker0 -j ACCEPT

My (relevant) host interfaces:

3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    inet brd scope global eth1
       valid_lft forever preferred_lft forever
4: docker0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default
    inet scope global docker0
       valid_lft forever preferred_lft forever

And I run a docker container:

$ docker run --rm -it --dns= debian:jessie # Specifying the DNS is so that the public DNS servers aren't used.

At this point I want to be able to use a local service, bound on So that the following should yield a reply:

$ ping google.com
$ ping user.skydns.local

When I run the same command from my host:

$ ping photo.skydns.localPING photo.skydns.local ( 56(84) bytes of data.
64 bytes from icmp_seq=1 ttl=64 time=0.790 ms

My resolv.conf

$ cat /etc/resolv.conf

The point here is not to access public hosts, but rather internal ones, using the local DNS service available on the host (via another docker instance).

To illustrate it even further (My ascii art design skills surpass my iptables fu, so that should say enough at this point):

|  __________________________           Host   |
| |   Docker DNS container   |                 |
|  ``````````````````````|```                  |
|                        |                     |
|     ,----------,---( private n. interface )  |
|     |          |                             |
|     |          |   ( public  n. interface )---
|     |          |                             |
|     |          |   ( loopbck n. interface )  |
|     |          |                             |
|     |          |                             |
|     |        __|_______________________      |
|     |       | Docker service container |     |
|     |        ``````````````````````````      |
|     |                                        |
|     |                                        |
| [ Local host service using DNS. ]            |
|                                              |

  private (host) network interface: eth1 (
  Docker network interface: docker0 (

I've searched, read and applied different example Iptables configurations, but I know too little of the more "advanced" Iptables rules to understand whats going on and thus to get the desired result.

Output of iptables -t nat -nL:

target     prot opt source               destination
DOCKER     all  --              ADDRTYPE match dst-type LOCAL

Chain INPUT (policy ACCEPT)
target     prot opt source               destination

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination
DOCKER     all  --           !          ADDRTYPE match dst-type LOCAL

target     prot opt source               destination

Chain DOCKER (2 references)
target     prot opt source               destination

Output of cat /proc/sys/net/ipv4/ip_forward:

  • Can you post the output of iptables -t nat -nL? Did you do any packet analysis, say do a ping from the source container and use tcpdump to capture the packets on the host.
    – Daniel t.
    Jul 15, 2015 at 3:46
  • Certainly, thanks for helping so far: pastebin.com/TAaT73nk (Didn't fit the comment..) --edit--> Updated the link to a pastebin that doesn't expire.
    – Dynom
    Jul 27, 2015 at 7:36
  • Maybe I didn't understand correctly your problem, but I don't see any rule to allow DNS queries on host. Also, is ip_forward enabled? Jul 27, 2015 at 8:51
  • Hi @LaurentiuRoescu. $ cat /proc/sys/net/ipv4/ip_forward -> 1 and -A INPUT -i eth1 -j ACCEPT accepts all connections on the private interface. What rules are you missing?
    – Dynom
    Jul 27, 2015 at 8:54
  • 2
    I think packets from container come from docker0 interface, not eth1. try -A INPUT -i docker0 -j ACCEPT Jul 27, 2015 at 9:04

2 Answers 2


Container communicates with host using docker0 interface. To allow traffic from container add:

-A INPUT -i docker0 -j ACCEPT
  • 2
    Dynom, a lesson you might want to take away from this is that logging all your refusals is useful, with eg iptables -A INPUT -j LOG. The stamp IN=docker0 would have been very useful in working out what rule tweak was needed. Not to take away from Laurentiu's work, which was excellent - +1 from me!
    – MadHatter
    Jul 27, 2015 at 9:18
  • 7
    For people who use UFW, here is what I did to allow all communication from Docker containers to host: ufw allow in on docker0
    – Ali Ok
    Mar 5, 2016 at 19:42
  • This is wrong. This is allowing packets back TO the docker interface, such as ACK packets and such. The conntrack rule would be better suited here.
    – Otheus
    Oct 29, 2021 at 14:11
  • @Otheus It is the INPUT chain, not OUTPUT. Nov 3, 2021 at 9:55
  • 2
    I had to use the following rule instead for docker compose to work: -A INPUT ! -i eth0 -s -j ACCEPT
    – vbezhenar
    May 25, 2022 at 16:29

I've encountered very similar situation but adding -A INPUT -i docker0 -j ACCEPT will open all accesses over my eth0 interface of docker host to containers which is absolutely not what I intended.

And since I noticed that my container just had limited access(say only port 22) to host interface instead of totally shut down from host network, I reviewed my iptables rules and found a rule in chain IN_public_allow which should be responsible for this. The rule is -A IN_public_allow -p tcp -m tcp --dport 22 -m conntrack --ctstate NEW -j ACCEPT. So I added similar rules to allow my container to access other host ports desired, which I think could be a bit more precise way to open host network access to containers.

  • -i docker0 should ensure that this will not affect traffic which does not arrive via the docker0 network. Your grammar is unclear though. Perhaps you were saying that outgoing access from docker hosts via eth0 was enabled, which might be true. I agree that more targeted rules are possible opening only as much as you need.
    – mc0e
    Apr 11, 2019 at 8:42
  • @mc0e "-i docker0 should ensure that this will not affect traffic which does not arrive via the docker0 network" sounds incorrect, especially the word via. Instead, at the docker0 network is more precise.
    – Otheus
    Oct 29, 2021 at 14:13

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .