Missing DockerNAT after upgrading to Docker Desktop 2.2.0 on Windows

[LeonSebastianCoimbra]

After updating my local Docker Desktop from 2.1.0.5 to 2.2.0 i was unable to use the IP 10.0.75.1.

After some investigations, i found that the entire definition of "DockerNAT" disappeared.

I searched google for possible solutions but i didn't find anything useful.

I tried to delete and reinstall the 2.2.0 version but without success.

Through the page https://docs.docker.com/docker-for-windows/release-notes/ i was able to retrieve a functional version of the latest 2.1.0.5; once installed all started to work as before. The output of the ipconfig command is:

`

Ethernet card vEthernet (DockerNAT):
Connection specific DNS suffix:
IPv4 Address. . . . . . . . . . . . : 10.0.75.1
Subnet mask . . . . . . . . . . . . . : 255.255.255.240
Default gateway . . . . . . . . . :
`
This is the part that was missing with the new installation.

[straga]

Yep. They did that. I am already updated and lose DockerNAT too.

[mikeparker]

We deliberately removed the DockerNAT in the latest version because it's no longer necessary due to our new filesharing implementation.

There are existing, much more suitable methods for doing everything around this network adapter, can you perhaps describe why you want to use this IP and I can point you to a good solution?

[LeonSebastianCoimbra]

Thanks for the fast replay.

At the moment i am using the 10.0.75.1 IP address as convenient way to address my machine both by the browser (running in the host) and the internal services (running inside the docker network).

I modified the "hosts" file to be able to use a DNS-like name and since i am still in development phase it is more than sufficient.

I can say that in the final production environment this problem will not arise (i will re-organize my services in a convenient way), but in development, where i have limited resources, it is very convenient to do so.

[ChristopherMillon]

@mikeparker what are those solutions? The missing DockerNAT is an issue for us as well

[mikeparker]

@LeonSebastianCoimbra
Generally implementing something which allows you to access the host from a container AND use the same mechanism for container-to-container communication is not a best practice, because at scale the system often needs multiple hosts across a cluster, and so the hostname (and IP) will change. Generally for container to container communication we have DNS names provided by docker compose for example.

However, if you're looking for a solution that is 'developer only' (this won't necessarily work in production) and you are trying to standardise a mechanism for talking to containers either from a different container or on the host, you need to use a DNS name (not an IP address) as the DNS name will resolve to different IP addresses inside containers and on the host - we no longer have an IP address accessible by both the host and the container.

We technically provide a DNS name you can use for this purpose: kubernetes.docker.internal this is currently used by, as you can guess, kubernetes, allowing us to share the kube context on the host and inside containers. There is also host.docker.internal which may work depending on what you're trying to do exactly.

If this is something that is required maybe we need to look again at the feature and make it more of a standard feature - any more information on your use case would be useful.

@ChristopherMillon let me know what your use case is and whether it's the same as the above.

[straga]

Yes. I use it in dev on laptop, make route for bridge docker. Startup dns-proxy-server(http://mageddo.github.io/dns-proxy-server/latest/en/1-getting-started/running-it/) in container. After that DNS record update automaticly form start-up containers. And I can access to any conteiners by DNSname.

[bondas83]

I have solution https://www.bountysource.com/issues/39154772-how-to-access-containers-by-internal-ips-172-x-x-x whih disapear after 2.2 update. To access internal container IP's. What is a solution now?

[straga]

Linux native installation provides access to docker network, why windows should not provide it? But we use route for that and it works. In setting we have:
Hyper-V subnet
10.0.75.0/28
default: 10.0.75.0/28

But fact script what start Hyper-V virtual machine not use it after update.

[ChristopherMillon]

@mikeparker it's basically the same, we docker inspect ... get the IP Address of the container and then communicate with it from the host for dev/testings purposes.

You recommend using DNS? How would this work exactly? Do we have to set explicit hostnames for our containers and prefix them by host.docker.internal or kubernetes.docker.internal?

[mikeparker]

@ChristopherMillon that doesn't sound the same. Leon is talking about accessing the host machine. You're talking about accessing a container.

If you want to go host -> container simply expose the port and use localhost.

[mikeparker]

@straga @bondas83 I don't understand what you're saying.