Iptables rule-set so that a docker container can access a service on a host IP

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:


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

-A INPUT -i docker0 -j ACCEPT

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 think packets from container come from docker0 interface, not eth1. try -A INPUT -i docker0 -j ACCEPT

Certainly, thanks for helping so far: Chain PREROUTING (policy ACCEPT)target prot opt source desti - Pastebin.com (Didn’t fit the comment…) --[edit]–> Updated the link to a pastebin that doesn’t expire.

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?

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?

I think you nailed it @LaurentiuRoescu. When I add your line it seems to work. I never figured it was something that trivial… Could you please add it as an answer to my question? I’d like to reward your answer.

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.