Isn't that expected behavior? Since you're not passing any network flag the container is using the default bridge mode. So you're seeing the container's IP address on the docker0 bridged interface.

No, I should see the remote ip (like in linux or docker toolbox) of the connected machine from inside the container, and not the container's gateway ip.

This is a pretty serious issue as NAT appears to be broken ... kind of a deal breaker.

I confirm that I can reproduce the issue. I will discuss the issue further with the team to see what we can do to fix it.

I also confirm that we can reproduce the issue on Linux, so the issue is not in Docker for Mac. /cc @thaJeztah is it a know issue on Linux?

I had second thoughts about whether I had really reproduced on native Linux.

I had done a docker run then a ⁠⁠⁠⁠curl localhost...⁠⁠⁠⁠ like the ticket says and saw an originating IP of 172.17.0.1, which is the IP of the ⁠⁠⁠⁠docker0⁠⁠⁠⁠ bridge, which thinking about it more is an IP of the originating host (even if one maybe wouldn't think about it as "the" IP of the host).

In the for-mac case the ⁠⁠⁠⁠172.17.0.1⁠⁠⁠⁠ is not going to be an address which the OSX host knows about, which is the crux of the issue here since something which ought to dial back to the mac will end up dailing back to the VM hosting the containers instead.

So I think I was too quick to tell @samoht I was seeing the same issue on native Linux, sorry. Reopening.

I think what would be needed here would be some mechanism to forward ports back out of the VM to the host (i.e. the inverse of what docker run -p NN:NN does). ISTR that being discussed in another context somewhere but the specifics are escaping me right now.

@samoht @ijc25 I know there's an issue in swarm mode (see moby/moby#25526)

I tried to replicate the issue and found out that the IP address like 172.17.0.1 only appears when the request is originated from the same host as the container.

This behavior is for standalone container. For swarm mode, it is another separate issue.

@PanJ in that case, I suspect it's because of the userland-proxy

@thaJeztah
I just noticed that this is docker for mac repo. Tried to reproduce again with docker for mac and the problem persists event the client and server is different machine. Both with machine in same network and doing NAT over the internet.

Thanks for the report and sorry the delay! I have forwarded the issue to our networking team, we will keep you updated when we start making progress on fixing that issue.

I think making this just work in Docker for Mac will be quite involved. We can't add an X-Forwarded-For header since this is a TCP proxy, not an HTTP one. I think we would have to teach the userland proxy how to do transparent proxying i.e. to spoof the client IP. From a quick glance at https://www.haproxy.com/blog/howto-transparent-proxying-and-binding-with-haproxy-and-aloha-load-balancer/ I think this involves some or all of:

• CONFIG_NETFILTER_{,XT_TARGET_}TPROXY kernel options
• net.ipv4.ip_nonlocal_bind
• some new iptables rules: would need to be careful here to avoid damaging the main docker/swarm ones
• some new routing
• update the tunnelling protocol to pass in the client IP and use it inside the VM

As a workaround in the meantime perhaps you could run an explicit HTTP proxy container yourself, and make it add the X-Forwarded-For header?

@djs55 for what it's worth, this also appears to happen with Docker Swarm mode ...

moby/moby#25526

This makes it impossible to test things like HAproxy load balancing via source method which checks the IP address of incoming requests when determining which container to send a connection to on Docker for Mac. All incoming requests will appear to originate from the same IP, the HyperKit VM's IP (not the macOS host IP or other LAN IP).

@samoht Just checking on the status of this. The issue is over a year old and doesn't sound like it's being actively reviewed in the last 9 months. Can we get a status update? Please.

this configuration worked for me

ports: - mode: host protocol: tcp published: 8082 target: 80

changing port bind mode to host

how ever you should force your fronted container to run on the specific host in swarm cluster only

i.e.
deploy: placement: constraints: [node.role == manager]

this works for me:

version: "3.2"
services:
   mycontainer:
     build:
       context: .
     ports:
        - "2221:2221"
        - "30000-30009:30000-30009"
     container_name: mycontainer
     network_mode: host

Note the addition of network_mode: host. I didn't need to use lines such as ports: - mode: host protocol: tcp published: 8082 target: 80.
And now my container sees the original IP address of incoming sockets.

As this is the docker for mac repository: https://docs.docker.com/network/network-tutorial-host/

The host networking driver only works on Linux hosts, and is not supported on Docker Desktop for Mac, Docker Desktop for Windows, or Docker EE for Windows Server.

I'm not sure if this helps, but I am experiencing this issue on CentOS 8 with DockerCE.
But when I run sudo firewall-cmd --permanent --zone=trusted --remove-masquerade I am able to read incoming IPs from within the container. If Mac supports iptables I would look into that.

Those solutions above only work on Linux.

The host networking driver only works on Linux hosts, and is not supported on Docker Desktop for Mac, Docker Desktop for Windows, or Docker EE for Windows Server.

I wanted to run Tomcat Docker on a Windows host, only to find out that I cannot access the management interface. By default, it is only accessible from localhost as a security measure. So my only option afaik is to reconfigure Tomcat and compromise my apps security.

Same here
Docker Desktop 2.2.0.5
Docker Engine 19.03.8

On Mac OSX 10.14.6
$ docker run -it --rm -p 80:80 --name whoami containous/whoami

On a remote machine
$ curl 192.168.25.87
Hostname: 07a90be6f0fa
IP: 127.0.0.1
IP: 172.17.0.2
RemoteAddr: 172.17.0.1:46448
GET / HTTP/1.1
Host: 192.168.25.87
User-Agent: curl/7.54.0
Accept: /

Expected to be the ip from remote client on 192.168.25.0 network

As a reply to my crosspost to boot2docker I‘ve got the hint to put this problem/wish on the roadmap at https://github.com/docker/roadmap
Apparently the issue is internally known, but that may get this more publicity...

So, we're in August, can't we have a solution from docker team? I just want to have the original ip forwarded to containers :/

Same for me. Can we have the original IP forwarded? 😁 🙏

this works for me:

version: "3.2"
services:
   mycontainer:
     build:
       context: .
     ports:
        - "2221:2221"
        - "30000-30009:30000-30009"
     container_name: mycontainer
     network_mode: host

Note the addition of network_mode: host. I didn't need to use lines such as ports: - mode: host protocol: tcp published: 8082 target: 80.
And now my container sees the original IP address of incoming sockets.

Thanks. Worked for me.

Yeah we know that. But host mode only circumvents the problem.
host mode is not usable in swarm / service environments where mutliple instances need to run on the same machine.
PS:
Happy 4th birthday for a issue that should be fixed like... 4 years ago.

Same for me...

Yep, same here on Linux aswell

Still an issue in Docker Desktop in Windows 10. This prevents setting up ACL in web based applications hosted inside a Docker container. This should be marked critical and have a proper fix.

This issue has prevented me from using my applications in production. Is this in the "Roadmap" anywhere?

This feature request has now moved to docker/roadmap#157, so I'm going to close this ticket.

I'm not sure if this helps, but I am experiencing this issue on CentOS 8 with DockerCE.
But when I run sudo firewall-cmd --permanent --zone=trusted --remove-masquerade I am able to read incoming IPs from within the container. If Mac supports iptables I would look into that.

It helps but the performance is going so bad from 19ms to 2-3seconds
On Linux

I'm not sure if this helps, but I am experiencing this issue on CentOS 8 with DockerCE.
But when I run sudo firewall-cmd --permanent --zone=trusted --remove-masquerade I am able to read incoming IPs from within the container. If Mac supports iptables I would look into that.

It helps but the performance is going so bad from 19ms to 2-3seconds
On Linux

This worked for me and performance wasn't degraded at all.

Closed issues are locked after 30 days of inactivity.
This helps our team focus on active issues.

If you have found a problem that seems similar to this, please open a new issue.

Send feedback to Docker Community Slack channels #docker-for-mac or #docker-for-windows.
/lifecycle locked