Address Pools and Interfaces for Docker and WSL and Windows

Docker Desktop and WSL2 integration on Windows 10/11 "just works" in many situations but feels like magic. I needed a map of the networks and names to understand why I needed proxies, port forwarders, and projected ports. May this be useful to you also :-)

The Windows 10/11 machine in this diagram is known as Z820. This diagram is an outside-looking-in topology. There are multiple networks and different name resolutions for the same names depending on where you are in the network. In some places, the same hostname is resolved to different IPs if you use DNS vs the host table, /etc/hosts
Click to Enlarge

This diagram is a simplified version of the previous one with the WSL network and associated Linux installations removed.
Click to Enlarge


The Six Networks in this diagram

The network IP ranges in the diagram above are those of the default Docker / WSL installations and can be adjusted via various mechanisms.  This is sometimes required in corporate environments where they have standard ranges for things like remote laptops and VPN adapters.
  1. Hyper-V Ethernet (WSL): The Linux WSL distributions communicate with the host over this network and through this Hyper-V switch. Note that in this picture the two WSL distributions have the same IP address as reported by the network tools in a shill on those machines
  2. Home Network ( The windows Ethernet and Wi-Fi adapters are on this network.  This is the network IP that external devices use to connect to the Windows host. The network that all the devices in the office / house use and that is connected to the internet via a FIOS router.
  3. Docker Desktop Network: A network managed by Docker Desktop that acts as a bridge network between the Docker Nodes and the Windows host.  There is a virtual IP on this network that is essentially attached to the Windows host
  4. Docker Node Pool Network: This is a 2nd network managed by Docker that all of the deployed docker containers is attached too.  Every docker container has a unique IP on this network
  5. Localhost ( The local loopback address on each device.  Port forwarded containers show up on this interface.  Each container must be forwarded to a different port as they all appear on the same network adapter
  6. Debian ties this address to the host name in the /etc/hosts file.  DNS resolution will point at the ethernet address.

Other Networks

Some networks were not included in order to not clutter the diagram.  
  1. Hyper-V Ethernet (default): This switch and associated network routes were not included because they didn't show up in any of the traceroute output.
  2. Kubernetes Pods (10.1.x.x): Kubernetes manages networks for services and node pools.  It allocates those networks in the range by default. This page does not talk bout Kubernetes networking so that is also not included.

Host Names, DNS, and Name Resolution

Windows and Linux instances use a combination of host files and DNS resolution. There are a few situations where those two actually resolve to different IP addresses.  You can see this for the name Z820 in the diagrams above.  That is the hostname for the Windows machine that all this runs upon.

WSL Linux Network Adapters

WSL Instances communicate with the Windows host over a private internal network that is attached to the Hyper-V Ethernet (WSL) vSwitch. External network devices cannot see the WSL instances unless additional networks or routes or port forwarding are in place.

Names, DNS, and Resolution

Docker ensures that host.docker.internal and gatweay.docker.internal resolve to the Windows hosts.  The WSL instances are not on the Docker Desktop network so those names resolve to the physical ethernet adapter, in the picture above.

The two Linux WSL distributions eth0 adapters have the same IP address.  I'm not sure which one you get when you ping that address from the host.

Kali WSL distribution
└─$ ip address
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether 00:15:5d:b3:93:cc brd ff:ff:ff:ff:ff:ff
    inet brd scope global eth0
       valid_lft forever preferred_lft forever
    inet6 fe80::215:5dff:feb3:93cc/64 scope link
       valid_lft forever preferred_lft forever

└─$ lsb_release -a
No LSB modules are available.
Distributor ID: Kali
Description:    Kali GNU/Linux Rolling
Release:        2023.2
Codename:       kali-rolling

Ubuntu WSL distribution
joe@z820:~$ ifconfig
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet  netmask  broadcast
        inet6 fe80::215:5dff:feb3:93cc  prefixlen 64  scopeid 0x20<link>
        ether 00:15:5d:b3:93:cc  txqueuelen 1000  (Ethernet)
        RX packets 18788  bytes 38889167 (38.8 MB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 4419  bytes 347920 (347.9 KB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet  netmask
        inet6 ::1  prefixlen 128  scopeid 0x10<host>
        loop  txqueuelen 1000  (Local Loopback)
        RX packets 1239  bytes 472324 (472.3 KB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 1239  bytes 472324 (472.3 KB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

joe@z820:~$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 20.04.6 LTS
Release:        20.04
Codename:       focal

Docker Desktop Network

This network is managed by Docker Desktop and acts as a bridge between the Docker Nodepools, Windows 11 Ethernet/Wi-Fi, and potentially any VPNs. The network in the diagrams above is the default network range for this and can be moved via the Docker Desktop management tool.

This network acts as a gateway for traffic coming into and out of the Node Pool networks. Communication between Docker containers and Windows or the internet transit through this network.  The diagram shows that DNS is manipulated on the docker pods so that traffic through the host goes through that IP on this network.  Traffic can be forced to the Ethernet adapter's public IP by explicitly requiring that address

I don't know what to call the address in this diagram.  It may actually be one of the K8s control nodes as I have Kubernetes running in this Docker Desktop environment using the provided integration.

Names, DNS and Resolution

Docker ensures that host.docker.internal and gateway.docker.internal always resolve to the Windows host.  They point at the Virtual IP on the Docker network.  

Docker Address Pool for Deployed Containers

Docker allocates a separate CIDR for the deployed docker containers. This isolates the containers from the other networks.  Traffic out of the containers routes through node pool gateway to the Docker Desktop Network and then to the host or the internet.  External devices and Windows are not directly attached to this node pool network.  This is one of the reasons you have to add a localhost port exposure declaration when deploying Docker ContainersA proxy has to be set up to transit the Docker network to the node pool network.

Names, DNS and Resolution

The node pool network uses the Docker Desktop DNS node for name resolution for anything outside the node pool. It maintains host.docker.internal and gateway.docker.internal to communicate with the Windows host. Traffic destined for the internet or other devices not on the Windows Host goes from the node pool network through the docker desktop network.



Revision History

Created 2023 06


Popular posts from this blog

Understanding your WSL2 RAM and swap - Changing the default 50%-25%

DNS for Azure Point to Site (P2S) VPN - getting the internal IPs

Installing the RNDIS driver on Windows 11 to use USB Raspberry Pi as network attached