Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Support hairpin NAT #6810
This re-applies commit b39d02b with additional iptables rules to solve the issue with containers routing back into themselves.
The previous issue with this attempt was that the DNAT rule would send traffic back into the container it came from. When this happens you have 2 issues:
The solution to this is to masquerade the traffic when it gets routed back into the origin container. However for this to work you need to enable hairpin mode on the bridge port, otherwise the kernel will just drop the traffic.
The libcontainer change is docker/libcontainer#62
Also, since part of this change is in libcontainer, I wasn't sure how to handle that. Such as whether the files in
Note, with this change, it is almost possible to remove the docker proxy. The only thing left that the proxy handles is connecting to a port mapping via localhost from the docker server (the TestAllocateTCPPortLocalhost test).
I ran the integration test suite with the proxy disabled, and the only tests that failed were those localhost tests.
Haven't tested it, but that's basically the change that I need indeed. We also never use
It would be great of course in the long run if the proxy could be removed completely, but the changes for that look more complex (and should be looked at by people with more network knowledge than I have).
I'll build this branch tomorrow, give it a spin and report back.
The big problem with the proxy is that you lose client information. The server no longer knows the IP/port of the client.
Addendum: I'm all for making it an option, but the default behavior should be the same everywhere.
if/when docker gets ported to other OSs, iptables will have to be ported anyway as there are numerous other things using iptables besides potential localhost traffic. Plus I think implementing the iptables equivalent in the target OS will be trivial compared to everything else.
And yes, it does require setting a single sysctl param on the bridge interface,
referenced this pull request
Jul 16, 2014
@LK4D4 sorry, missed your message.
I successfully routed localhost by performing the following: