Issue with Transparent Network in Docker on a Windows VM Hosted on VMware

I’m facing a networking issue with Docker running on a Windows virtual machine hosted on VMware. My goal is to establish direct network communication between Docker containers and a SQL Server Database (DB) for using Distributed Transaction Coordinator (DTC) via NetBIOS names and ports, within the same network segment

Here’s a summary of my setup and the problem:

  1. Environment Setup:

    • The Docker host (Windows VM) and the SQL Server are both located within the same network segment
    • The Windows VM Docker host has an additional network interface.
    • Docker containers need to communicate directly with the SQL Server using DTC, which requires them to be in the same network and be accessible by NetBIOS names and ports.
  2. Issue Description:

    • I attempted to use Docker’s transparent networking to allow containers to obtain IP addresses from the subnet directly and communicate with the SQL Server.
    • Despite the containers seemingly receiving IP addresses from the desired subnet, DHCP requests don’t seem to reach the DHCP server.
    • Containers appear to obtain IP addresses automatically but are not accessible from any physical host within the network, suggesting a lack of direct network visibility or incorrect IP address allocation.
    • Network monitoring tools on the Docker host have shown packets being routed from the host to the DB server during container DB access attempts, indicating that the containers might not have direct network access to the network as intended.
  3. Attempts and Observations:

    • Firewall configurations have been checked and are not blocking the communication. (Firewall is off on both DB and Docker)
    • Direct usage of host networking, as commonly applied in Linux environments, doesn’t apply here due to the Windows-based setup.
    • There seems to be a “hidden” layer of routing or network address translation happening that prevents the containers from participating in the network as independent hosts with direct visibility.

Has anyone encountered a similar issue with Docker on Windows, particularly with transparent networking not working as expected?
Any insights into ensuring direct network visibility for Docker containers in the same subnet as the SQL Server, or how to properly configure Docker networking on Windows to support DTC over NetBIOS, would be greatly appreciated.

I moved the topic to the DockerEngine category, because you mention you run a Windows virtual machine on VMWare, but I might have made a mistake as I’m not sure you are not trying to run Docker Desktop in that Windows virtual machine. So how exactly did you installed Docker in that VM? And do you really run Windows containers or Linux containers on Windows?

Hi, Ákos


I ran docker desktop on a Windows virtual machine.

My problem is that - I cannot get direct access from the container to
the existing physical network.

When creating a network in docker with the transparent driver, packets
from inside the container are routed through the docker network. And
this is not a transparent network mode.
Maybe there are additional settings that I don’t know about

Did you follow the instructions in the docs when you created the container network using the transparent driver?

Those instructions are for the Docker Engine on Windows Server, so they may or may not work with Docker Desktop.

Hi, Metin!

Thanks for the link!
I didn’t find it before.
I am using docker on windows 2022
I followed the recommendation in your link, but I didn’t quite get what
I wanted.

The DHCP server lease the container address. ICMP packets began to flow.
This is already a success!

But… From the physical network, the container is still not available
by the received address.

I made a trace from inside the container. Packages do not go directly to
the network, but through the docker interface.

I use Network Monitor on docker host. ICMP traffic goes through docker
interface 172.###.###.### to the DB server.

@vrapolinario: can you pitch in?

1 Like

I have to add that Docker Desktop is not supported on Windows server and never was.

@vrapolinario once shared a link to run Linux containers in WSL2 on Windows server 2022

But you wrote you wanted to run Linux containers. I can’t say that what you want wont work with Docker dEsktop and Windows containers (maybe vrapolinario knows the answer), but at least it is not officially supported.

1 Like

My fail!

I forgot to add the details of the problem.
I am creating a windows container. I need to containerize a Windows
application with ActiveX components.

And i need same network with ms sql server to work with MSDTC.

Thanks for adding me @meyay.

@barsuk4 To confirm: you have installed Docker from the official link provided above (which installs Moby), correct? Did you create a network before you created the containers? Which network type? and when you created the containers, did you add them to that network? Here’s the docs for networking: Windows container network drivers | Microsoft Learn

1 Like

Creating an account to jump on this post because apparently we are one of the only people trying this same thing and the posts fell off…

Windows docker container (web applications) - NOT Docker Desktop - on a Windows Server 2019 VM host (with postgres sql) on VMware hypervisor (maybe not relevant).

We cannot find a reliable way to connect from the container to the host.

Supposedly host.docker.internal does not work in production containers (and didn’t work for us).
Supposedly is the old deprecated version (and didn’t work for us).

My coworker got something working where the container app uses the “vEthernet (nat)” NIC of the host to connect to postgres, but it didn’t work for my new deployment. ALSO, after a reboot, this nat NIC changes its IP address, so we have to change our appsettings and redeploy every time - which is terrible.
(nat network link; Docker Host network alternatives for Windows containers - Microsoft Community Hub)

I haven’t tried out this transparent network, but this post doesn’t give me high hopes.

Anyone have any other recommendations on what to use in a windows container to connect to windows host - like a production version of host.docker.internal?

@vrapolinario Can you provide some insights?

How are you assigning IPs to the containers? If you aren’t and instead you are using whatever is the default, then I can tell you that you’re using NAT. Please note as in the blog post, NAT means you have an internal network on which the containers and the host have IPs from. You then map a port from the host to the container when you run docker run. Something like:

docker run -d -p 8080:80 containerimage:tag

If you wan to ping from the container to the host, you can ping using the IP of the host from the container. Remember to open for ICMP traffic on the host.

Also, when you create a new container it will get a new IP address. You can assign a specific IP to the container if you want - also when you run docker run.

1 Like

Our containers’ IP and port mapping is all working fine.

Our main issue is container-to-host communication (for postgres on the host) via that NAT NIC on the host VM. Every time the host reboots, the NIC loses its configuration and generates a new random NAT IP / network - so our containers’ applications’ connection strings pointing to the host no longer work.

How can we assign a static NAT IP to the host that doesn’t reset itself?
or - Is there a way to use the non-NAT IP on the host to communicate instead? ie. maybe putting the containers on the physical network? Is that what the transparent network does?

Yes. That’s what I described on the blog post. Now, keep in mind the containers will by default try to get an IP address from your DHCP server. Containers were created to be ephemeral and not necessarily long-last runners, so in theory you should not be assigning an IP address to it. With that said, you still can, by providing an IP address to it when you run the docker run command. Use the --network parameter to specify to which network to connect and --ip to specify an IP address to the container.