--net=host does not work

Docker Desktop
1

Expected behaviour

Running a container with --net=host should expose all the ports on localhost

Actual behaviour

The container is running isolated in fact, with nothing exposed

Information

Running Docker for Mac beta 1.12.0-rc2-beta 17 on OS X El Capitan 10.11.5

Steps to reproduce the behavior

  1. Run an nginx container with --net=host
  2. check localhost:80 to see if there is a server listening: nothing there
    lsof -n -iTCP | grep 80
2

Keep in mind that docker runs linux containers, thus, docker for mac starts light weighted VM.

When you run --net=host you run within linux, not directly on your mac host.

Your mac network interface differs from the linux network interface and thus you cannot see your processes locally.
https://docs.docker.com/docker-for-mac/networking/#/there-is-no-docker0-bridge-on-osx explains why you cannot do so

3

I noticed the missing docker0 interface on the host. The container does have a docker0 interface when run with --net=host and traffic does go from the container to the host just not the other way around. I am able to access services running on the host.

I need to run an nginx reverse proxy(which is probably a common scenario) that needs to access the host. If I run with --net=host the container has a docker0 interface that allows me to access the host. However if I throw in a -p 80:80 the port is not forwarded.

Can port forwarding and host networking be mixed to allow for the host to access some port on the container while the container uses the docker0 interface to access services no the host? Since the the two things run on different interfaces(eth0 and docker0) in the container maybe it would be possible?

Is there a workaround now for this scenario?

Thank you

4

Iā€™ve also noticed that --net=host were not forwarded
I donā€™t exactly get what you are trying to achieve. But I donā€™t get how a lsof -ni TCP on the mac could display services.

From what I know and what Iā€™ve seen, forwarding requests from your host to the container is done by the vpnkit:

Maybe there could be options to achieve what you want to do:

  • inspire from vpn implementations (tunnelblick, ā€¦) to provide a VPN to the docker host networks (implement both an ā€˜interfaceā€™ on the mac and an interface on the docker host and exchange traffic from them as VPNKit does)
  • inspire from VPNKit to provide a VPN server on localhost that forwards traffic to the docker host

Although there is a risk of ā€˜infinite loopā€™ networking as containers are connecting to the world using VPNKit (VPNKit using the native mac networking)

5

When using DockerMachine, solving this was considerably easier.

All you needed to do was add a host-only or bridged adapter (depending on whether you wanted the container to see your whole network or just your machine) in VirtualBox. Then the host could communicate with a container running with the --net=host argument via that adapter, and the container was also able to talk to anything on the docker0 network.

Judging by the number of threads that have been popping up with similar questions to this one, this seems like a fairly common use case for a variety of purposes.

Canā€™t something similar be done with this new VM? Is creating host-only or bridged adapters not possible with xhyve?

Iā€™m hoping a similarly simple solution will be found (or provided by the docker team if itā€™s just not possible right now).

There should be a straightforward way to connect to a container running --net=host.

6

It should be similar.
I just spun up an ubuntu 16.04 in an instance of xhyve and it makes a NAT based network which allows me to access both the host from the VM and the VM from the host(see http://www.pagetable.com/?p=831). I think that with some routing magic the traffic could be routed from the VM to the containers(from the virtual nat interface to the docker0 interface).

So while I get this is a beta limitation at the moment I think(based on my crude assessment of the situation, mind you) there should be no technical impediment to implement this.

7

Just did the following experiment:

  • Booted using xhyve an ubuntu 16.04 instance (see http://www.pagetable.com/?p=831)
  • installed docker inside the VM
  • started an nginx docker using --net=host inside the xhyve VM

Itā€™s accessible from the host using itā€™s IP address AND I can access the host OS X from the container inside the VM.
So, itā€™s 100% doable.

8

I wanted to slightly rephrase the original post to make sure Iā€™m experiencing the same thing. Running Docker for Mac Version 1.12.0-rc3-beta18 (build: 9996) on OS X El Capitan 10.11.5

This works:

docker run --rm -p 80:80 nginx

(curl localhost from my Mac returns the nginx page)

This doesnā€™t work:

docker run --rm -p 80:80 --net host nginx

(curl localhost shows ā€œFailed to connect to localhost port 80ā€). However, a second container can connect: docker run --rm --net host alpine nc -vz localhost 80 returns localhost (127.0.0.1:80) open

This blocks how we use Docker for development, since we rely on --net host to expose a bunch of services that weā€™d otherwise have to refactor to refer by container hostname. Can someone confirm that this isnā€™t intended? Or is this likely to not be fixed?

Explain networking known limitations, explain ā€œhostā€ seems relevant, but thereā€™s no response there either.

2 Likes
9

I did some experiments with xhyve and tap interfaces. The tap interface gives you gives you an ethernet interface pair through which you can access the vm without any nat in the way. In combination with libnetworks macvlan driver you can assign an ip address to containers which is directly reachable from os x. You can even access the container from remote machines with the correct routing in place.
Now I can just not find the right way to change the xhyve config from vmnet to vmnet tap. In earlier versions there was a -xhyve arguement pointing to xhyve.args file containing xhyve parameters. But this is not available in r18.