Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

How to access containers by internal IPs 172.x.x.x #221

Closed
wclr opened this issue Nov 11, 2016 · 154 comments
Closed

How to access containers by internal IPs 172.x.x.x #221

wclr opened this issue Nov 11, 2016 · 154 comments

Comments

@wclr
Copy link

@wclr wclr commented Nov 11, 2016

How to access containers by internal IP 172.x.x.x from dev machine (with docker for windows installed)? So by default you can not connect to containers.

I found out that it can be achived by adding route manually (you actually need to add routes for each sub-netwrok, I usually do for 17-25):

route /P add 172.17.0.0 MASK 255.255.0.0 10.0.75
route /P add 172.18.0.0 MASK 255.255.0.0 10.0.75
route /P add 172.19.0.0 MASK 255.255.0.0 10.0.75
...

Is is a valid method? Shouldn't it be made possible by default?

@rn
Copy link
Contributor

@rn rn commented Nov 11, 2016

you should be able to access the containers via localhost. Does that not work?

@wclr
Copy link
Author

@wclr wclr commented Nov 11, 2016

you should be able to access the containers via localhost.

What do you mean by that? You mean port mapping or what?

I want to reach their IPs, in my case then I use dnsdock to have DNS discovery for containers and access them by pretty dns names (without need of port mapping)

@kallie-b
Copy link

@kallie-b kallie-b commented Nov 11, 2016

So you should be able to access containers from your container host using the container IP. You can use docker inspect <container ID> to get your container's IP address.

Does that answer your question?

@wclr
Copy link
Author

@wclr wclr commented Nov 11, 2016

@kallie-b ok what should I do after I got IP? I want to ping it by IP. But it won't work from dev machine. I'm asking how to do this.

@kallie-b
Copy link

@kallie-b kallie-b commented Nov 11, 2016

Right, okay--yes, I'm happy to help.

So, can you provide the results that you get when you run docker inspect <container ID>? And let me know which IP address you're trying to use to ping the container--I want to confirm you're using the container's internal IP.

Also, I'm assuming your dev machine is the container host--is that correct? You're not running a VM on your dev machine as the container host, or anything like that?

Could you describe the steps you are taking more specifically (including where each step is executed--in the container, on the container host, or on another, external, host)? Wherever possible, also include any error messages.

@wclr
Copy link
Author

@wclr wclr commented Nov 11, 2016

I'm assuming your dev machine is the container host

My machine is not a container host, it is a windows 10 dev machine with installed docker for windows, it has only 10.0.75.x interface related to docker, no 172.x.x.x interface to be able to communicate with 172.x.x.x addresses directly. Host machine is linux that runs on Hyper-V, called MobyLinuxVM.

As I've mentioned, this will solve the issue:

route /P add 172.0.0.0 MASK 255.0.0.0 10.0.75.2

If I was using linux (I never used with docker), but I asume my dev machine would be also a docker host, I could access docker internal network 172.x.x.x. directly without any specific manually added routes to route table.

What I want is a comment about this issue from docker team, and if they are going to make integration between windows 10 dev machine and docker internal networks deeper.

@JMesser81
Copy link

@JMesser81 JMesser81 commented Nov 11, 2016

ping @friism

@wclr
Copy link
Author

@wclr wclr commented Nov 14, 2016

There seem to be a problem with docker network when such route:

route /P add 172.0.0.0 MASK 255.0.0.0 10.0.75.2

is added

Log is full of events, and growing very fast (log.txt - up to 1GB for a few hours):

15:48:00.469][VpnKit         ][Debug  ] com.docker.slirp.exe: Socket.Datagram.input udp:10.0.75.1:54882-172.26.234.194:51029: creating UDP NAT rule
[15:48:00.471][VpnKit         ][Debug  ] com.docker.slirp.exe: Socket.Datagram.input udp:10.0.75.1:54883-172.26.234.194:51029: creating UDP NAT rule
[15:48:00.473][VpnKit         ][Debug  ] com.docker.slirp.exe: Socket.Datagram.input udp:10.0.75.1:54884-172.26.234.194:51029: creating UDP NAT rule
[15:48:00.475][VpnKit         ][Debug  ] com.docker.slirp.exe: Socket.Datagram.input udp:10.0.75.1:54885-172.26.234.194:51029: creating UDP NAT rule
[15:48:00.476][VpnKit         ][Debug  ] com.docker.slirp.exe: Socket.Datagram.input udp:10.0.75.1:54886-172.26.234.194:51029: creating UDP NAT rule

Here is a log with this case:
https://gist.github.com/whitecolor/4940a8566f2b0211f6864cc11adb69be

Which also effects on the host, CPU usage is going up to 100% some time later
image

Can you comment on this as well? What is causing those events in the log?

@dgageot
Copy link

@dgageot dgageot commented Dec 3, 2016

@whitecolor I'm not sure I understand what you are trying to achieve. Is it a Windows container or a Linux container you are trying to connect to?

@wclr
Copy link
Author

@wclr wclr commented Dec 4, 2016

@dgageot
I need to connect to running containers from Windows dev machine where docker is installed.
This can be currently done by adding appropriate routes to routing table via 10.0.75.2 (this IP of docker linux host running on HyperV I believe).

@wclr
Copy link
Author

@wclr wclr commented Dec 7, 2016

Did I still failed to explain my request in OP?

  1. I'm running docker-for-windows on windows machine.
  2. Containers that are run on this platform has internal IPs like 172.18.x.x
  3. I want to reach (be able to ping) running containers directly from Windows machine (not using port mapping, I want to reach container's IP)

By default one can not just ping 172.18.x.x, but I found out the solution, add a route in route table:

route /P add 172.18.0.0 MASK 255.255.0.0 10.0.75.2

And now ping 172.18.x.x worked.

But after I installed the lastest beta (build 9123) where network was changed a lot this method using routing table doesn't work anymore.

So can you elaborate on this. How one can reach (ping) 172.x... containers from windows dev machine? Why the method with routing tabled stopped to worked, and how it can be fixed?

@Hronom
Copy link

@Hronom Hronom commented Dec 7, 2016

@whitecolor Thanks for workaround!
Also faced with this problem under windows, under linux I don't have such a problem...

I need to have access to the containers directly by IP address of container, for example by 172.18.0.3

@wclr
Copy link
Author

@wclr wclr commented Dec 8, 2016

@Hronom I wonder how does it work on linux by default, which gateway routes 172. address to containers?

@Hronom
Copy link

@Hronom Hronom commented Dec 8, 2016

@whitecolor On linux if I type in console ifconfig, I get next network interfaces:

br-bc76575bc879 Link encap:Ethernet  HWaddr *:*:*:*:*:*  
          inet addr:172.19.0.1  Bcast:0.0.0.0  Mask:255.255.0.0
          UP BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

br-fccc8ee02778 Link encap:Ethernet  HWaddr *:*:*:*:*:*  
          inet addr:172.18.0.1  Bcast:0.0.0.0  Mask:255.255.0.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:343481 errors:0 dropped:0 overruns:0 frame:0
          TX packets:448723 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:93440945 (93.4 MB)  TX bytes:169198433 (169.1 MB)

docker0   Link encap:Ethernet  HWaddr *:*:*:*:*:*  
          inet addr:172.17.0.1  Bcast:0.0.0.0  Mask:255.255.0.0
          UP BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:66359 errors:0 dropped:0 overruns:0 frame:0
          TX packets:77517 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:3569440 (3.5 MB)  TX bytes:203222893 (203.2 MB)

So there is a network interface br-fccc8ee02778 with IP 172.18.0.1 and mask 255.255.0.0

@wclr
Copy link
Author

@wclr wclr commented Dec 8, 2016

So probably on windows host there too such of interface with proper address should be added. But should there be interfaces for each 172.x... ?

@JMesser81
Copy link

@JMesser81 JMesser81 commented Dec 9, 2016

If your Windows containers are connecting to the default nat network on the container host, there should be a host vNIC named (e.g., vEthernet (nat)) with the NAT network's default gateway IP address assigned to this interface. Could you please verify this by running ipconfig /all

If that's true, then both the internal NAT network prefix and the external network prefix should be "on-link" from the container host's perspective and routing should happen automatically without creating static routes.

I've also created a PR (MicrosoftDocs/Virtualization-Documentation#513) to help aid in container networking diagnostics as well as a clean-up script.

@wclr
Copy link
Author

@wclr wclr commented Dec 12, 2016

@dgageot can you please comment on this I believe it is quite important and basic networking issue.

@wclr
Copy link
Author

@wclr wclr commented Dec 15, 2016

@Hronom
Can you confirm that the latest beta version doesn't work too? (without routes added to routing table)
I just remember now that when I installed the latest I might not check it with clean routing table. (Just don't want to install and then rollback again.)

@Hronom
Copy link

@Hronom Hronom commented Dec 19, 2016

@whitecolor sorry I'm don't have a chance to test this under beta version...

@pachkovsky
Copy link

@pachkovsky pachkovsky commented Dec 22, 2016

I can confirm that route add method is not working with latest beta (1.13.0-rc4-beta34 (9562)). 172.17.0.1 is reachable, but none of the containers are.

I can also confirm that the method is working with 1.12.3 (8488) and 1.12.5 (9503).

@wclr
Copy link
Author

@wclr wclr commented Dec 22, 2016

@pachkovsky so and without route (out of the box) it too doesn't work I believe in the latest beta?

@rneugeba @dgageot
Not sure why there is no reaction from the team?

@pachkovsky
Copy link

@pachkovsky pachkovsky commented Dec 22, 2016

@whitecolor without the route it's not working neither in 1.2.x nor in 1.3

@rn
Copy link
Contributor

@rn rn commented Dec 28, 2016

@whitecolor could you please provide exact steps on how to reproduce on what you try to achieve, including the command line you use to start dnsdock.
thanks

@wclr
Copy link
Author

@wclr wclr commented Dec 28, 2016

@rneugeba
Well dnsdock actually has nothing to do with this issue. The problem with accessing containers by IP from windows machine.

  • You just start any container (but container should be able to respond to pings).

  • Then you need to get its IP. Suppose it is default bridge network, so: docker network inspect bridge (usually something like 172.17.0.2)

  • Try to ping this IP from windows machine ping 172.17.0.2.

  • If you where on linux ping would work out of the box.

  • On docker for windows it doesn't work out of the box.

  • I'm using currenlty 1.12.3-beta30 (8568) and possible workaround works: route /P add 172.0.0.0 MASK 255.0.0.0 10.0.75.2

  • But on later (the latest) beta even this workaround with route doesn't work

  • Probably it should work out of the box as it is does on linux. what do you think?

@vision57
Copy link

@vision57 vision57 commented Mar 11, 2020

For those who use toolbox, if still can't access container ip directly from host after add route, but container gateway like 172.x.0.1 is accessable. Try login VM and check iptables, make sure FORWARD chain is ACCEPT.

Full instructions reference:

# add route if absent, doing this only if VM is running
# 172.x.0.0/16 is subnet of your container bridge network
# $(docker-machine ip default) retrieve ip of VM in one of host network
# command syntax varies with host OS
sudo route -n add -net 172.x.0.0/16  $(docker-machine ip default)


# login VM, the real linux running docker engine
docker-machine ssh default

sudo iptables -L

# add ACCEPT if absent, default rules may vary with releases of docker
# may lose after VM reboot
sudo iptables -I DOCKER-USER  -j ACCEPT

See Docker and iptables for more.

@nibtime
Copy link

@nibtime nibtime commented May 7, 2020

I am on Win10 and had to access a host service from within a container recently, so I tried to connecting to the container with its IP, which did not work and so I landed here. The idea of system modifications with Windows + Docker networking for that purpose made me uncomfortable. For my situation, I found a little trick to avoid this entirely, and maybe it turns out to be useful for someone else too. It goes like that:

  1. Start an SSH server inside the container that needs the host service
  2. Forward the container port of the SSH server to your Windows host system (localhost)
  3. Use PuTTY to connect to the SSH server with a tunnel from 127.0.0.1:<port of host service> to a target port in the Container. The host system can access the container SSH server locally from its point of view since the port has been forwarded by the container earlier

After that, you can consume the host service locally from the container's point of view. My concrete scenario was Chrome Co-Debugging with VS Code Remote Containers. I described it with more detailed instructions over here.

@datdinhquoc
Copy link

@datdinhquoc datdinhquoc commented May 29, 2020

@kallie-b ok what should I do after I got IP? I want to ping it by IP. But it won't work from dev machine. I'm asking how to do this.

for me, the ips 172.17.0.x work with Docker on linux, but not on windows.
any ideas why?

@vinchauhan
Copy link

@vinchauhan vinchauhan commented May 29, 2020

@datdinhquoc it won't work with the latest version of docker for windows as they changed networking and now there is no DockerNAT and there is no option to make it work other than installing and older version. I rolled back to 19.x and it works again with the persistent route workaround

@datdinhquoc
Copy link

@datdinhquoc datdinhquoc commented May 29, 2020

@datdinhquoc it won't work with the latest version of docker for windows as they changed networking and now there is no DockerNAT and there is no option to make it work other than installing and older version. I rolled back to 19.x and it works again with the persistent route workaround

yes, i see it now, even on official docker website: can't ping linux containers from windows
https://docs.docker.com/docker-for-windows/networking/#i-cannot-ping-my-containers

@benlumia007
Copy link

@benlumia007 benlumia007 commented May 29, 2020

all u gotta do is use wls2 and docker, that solves every thing.

@felipecrs
Copy link

@felipecrs felipecrs commented Jun 9, 2020

all u gotta do is use wls2 and docker, that solves every thing.

Do you mean installing docker daemon in the WSL distro instead of Docker Desktop? Because for me, this doesn't work even using Docker Desktop with WSL2 as backend.

@datdinhquoc
Copy link

@datdinhquoc datdinhquoc commented Jun 9, 2020

all u gotta do is use wls2 and docker, that solves every thing.

docker container inside wsl2, ok, should work, tks

@datdinhquoc
Copy link

@datdinhquoc datdinhquoc commented Jun 9, 2020

all u gotta do is use wls2 and docker, that solves every thing.

Do you mean installing docker daemon in the WSL distro instead of Docker Desktop? Because for me, this doesn't work even using Docker Desktop with WSL2 as backend.

yes, docker inside wsl2, not docker desktop (windows)

@benlumia007
Copy link

@benlumia007 benlumia007 commented Jun 10, 2020

Let's say that you cannot use WSL2 on Windows 10 Pro. WSL2 is only for those who are using Windows 10 Home. The new Docker for Windows has built-in support for WSL2 for those who are using Windows 10 Home. The software detect if you are using home or pro.

@felipecrs
Copy link

@felipecrs felipecrs commented Jun 10, 2020

Let's say that you cannot use WSL2 on Windows 10 Pro. WSL2 is only for those who are using Windows 10 Home. The new Docker for Windows has built-in support for WSL2 for those who are using Windows 10 Home. The software detect if you are using home or pro.

How does this help? The problem still happens in Docker Desktop, no matter what backend.

@benlumia007
Copy link

@benlumia007 benlumia007 commented Jun 10, 2020

So if you are using WSL2 with Ubuntu and you have docker for Windows. you don't even need to install docker on WSL2, the docker for WIndows have an option as see below.
image

@benlumia007
Copy link

@benlumia007 benlumia007 commented Jun 10, 2020

honestly, I'm not sure how you guys are setting up your environment. my simple setup is just to use the localhost at 127.0.0.1 and it just does whatever it needs to do. maybe I'm not doing complicated things, as long as I get my setup environment the way I need it. then improve it.

@benlumia007
Copy link

@benlumia007 benlumia007 commented Jun 10, 2020

I feel there is no need to grab the external IP address or the network that comes with the HyperV or WSL2 network because it changes every time you restart. WSL2 allows you to ping the 172.0.0.1 automatically without doing route IP or whatever. WSL2 is integrated into Windows so why not use the localhost for everything. If you're a web dev u can always update the hosts automatically with some bash script

macOS uses their own apple hypervisor you can't even access the dockerNAT. that's why using the localhost makes sense. I just build project that works for all different types of OS using HyperV, wsl2, macOS, and Linux because I use the localhost for everything.

127.0.0.1 dev.environtment.test
127.0.0.1 dev2.enviornment.test
@felipecrs
Copy link

@felipecrs felipecrs commented Jun 10, 2020

The point of this Issue isn't to discuss if using localhost is good or not. We are talking about being able to ping a container. Are you able to do that with your environment? Mine looks just like yours, and I'm not able to.

docker run -d --name alpine alpine sleep infinity
container_ip=$(docker inspect -f '{{range .NetworkSettings.Networks}}{{.IPAddress}}{{end}}' alpine)
ping $container_ip
docker rm -f alpine
@felipecrs
Copy link

@felipecrs felipecrs commented Jun 10, 2020

Maybe this works if you install the docker daemon in WSL2, without Docker Desktop, but didn't test it.

@benlumia007
Copy link

@benlumia007 benlumia007 commented Jun 10, 2020

u don't insall the daemon in wsl2, the docker desktop for windows enables that for u when u select wsl integration. i don't need to install docker on my wsl2 machine. the wsl integration in docker desktop does thatt for u.

@felipecrs
Copy link

@felipecrs felipecrs commented Jun 10, 2020

u don't insall the daemon in wsl2, the docker desktop for windows enables that for u when u select wsl integration. i don't need to install docker on my wsl2 machine. the wsl integration in docker desktop does thatt for u.

I know. And does the ping work for you? As I said my environment is just like what you described, and it does not work.

docker run -d --name alpine alpine sleep infinity
container_ip=$(docker inspect -f '{{range .NetworkSettings.Networks}}{{.IPAddress}}{{end}}' alpine)
ping $container_ip
docker rm -f alpine
@benlumia007
Copy link

@benlumia007 benlumia007 commented Jun 10, 2020

is not going to work. u can just use dnsmasq to give container access. See this answer for your to use the docker internal DNS and you can just use service names directly

https://stackoverflow.com/a/52242360

@felipecrs
Copy link

@felipecrs felipecrs commented Jun 10, 2020

is not going to work. u can just use dnsmasq to give container access. See this answer for your to use the docker internal DNS and you can just use service names directly

https://stackoverflow.com/a/52242360

Thanks for the suggestion. However, I believe this is a different matter. The fact is that the Issue reported here still persists even using Docker Desktop with WSL2.

@benlumia007
Copy link

@benlumia007 benlumia007 commented Jun 10, 2020

is not gonna work as we hope in Windows and the fact that windows, like to change major updates every twice a year, seems stupid. . I have seen it work before that you have to do more setup than you realized. using dnsmaq and resolver may help. its just an suggestion. i've done it before but i realize its just too much an hassle.

well i hope you and the rest of people here can find a solution. but i think this is not gonna solve on its own.

@vinchauhan
Copy link

@vinchauhan vinchauhan commented Jun 10, 2020

ting up your environment. my simple setup is just to use the localhost at 127.0.0.1 and it just does whatever it needs to do. maybe I'm not doing complicated things, as long as I get my setup environment the way I need it. then improve it.

I don't think every setup/project/requirement is drop dead simple like a webapp running of localhost. There is a challenge where you would need to ping or connect to the container ip 172.X, which is why people are asking for help

@benlumia007
Copy link

@benlumia007 benlumia007 commented Jun 10, 2020

yah I understand, but then you know how windows like there UAC and security. you wouldn't have this issue if you were to use Linux because docker runs truly 100% natively so you can ping, create a network, and all that neat stuff. The majority I think Docker is made for Linux.

plus, there are solutions probably that no one has found a better one I guess.

@vinchauhan
Copy link

@vinchauhan vinchauhan commented Jun 10, 2020

@felipecassiors - You can install older version of Docker desktop for windows - I am running on

~$ docker --version
Docker version 19.03.1, build 74b1e89

You should be good after creating persistence route approach.

@benlumia007
Copy link

@benlumia007 benlumia007 commented Jun 10, 2020

plus, i think if you know a version that works well for u and it solves that problem, i guess stick with it.. updating to the latest version seems not logical sometimes

@felipecrs
Copy link

@felipecrs felipecrs commented Jun 10, 2020

That's right, thanks. I'm not looking for a workaround actually, I'm just reporting the issue in the newest version of Docker Desktop.

@docker-desktop-robot
Copy link
Collaborator

@docker-desktop-robot docker-desktop-robot commented Jul 10, 2020

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

@docker docker locked and limited conversation to collaborators Jul 10, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet