WSL Mirrored Mode Networking in Docker Desktop 4.26: Improved Communication and Development Workflow

Docker Desktop 4.26.0 added support for WSL mirrored mode networking! This is a significant improvement for developers who use WSL (Windows Subsystem for Linux) alongside Docker Desktop, as it allows them to share network resources between their WSL distribution and their Docker containers. This can be helpful for multiple purposes, such as developing and testing web applications that need to communicate with both Linux and Windows systems.

Here are some additional details about WSL mirrored mode networking in Docker Desktop 4.26.0:

• It requires WSL version 2.0.4 or later.
• WSL can be enabled in the Docker Desktop settings.

• Once you enable networkingMode=mirrored in the .wslconfig file, Docker will automatically create a virtual network that is shared between your WSL distribution and your Docker containers.

WSL mirrored mode networking is a welcome addition to Docker Desktop 4.26.0 and should make it easier for developers to work with both WSL and Docker containers.

What is WSL Mirrored Mode Networking?

WSL mirrored mode networking is a new networking architecture introduced in WSL 2. It essentially bridges the gap between your Windows host and your WSL distribution by “mirroring” the network interfaces available on your Windows machine into the Linux environment. This creates a shared network space where both WSL applications and Docker containers can reside and communicate freely.

Why is it useful?

In the traditional NAT-based network setup, WSL applications and Docker containers are isolated from each other in separate virtual networks from the Windows host. This made communication between them a bit convoluted, requiring complex port forwarding configurations. For instance, to access a Docker container from a WSL application, you’d need to create a port forwarding rule between a port on the WSL application and a port on the Docker container.

With mirrored networking mode, both WSL applications and Docker containers directly connect to the physical network of the Windows host. This allows them to communicate directly with each other, eliminating the need for complex port forwarding configurations.

Here are some specific benefits of using WSL mirrored mode networking:

• Improved compatibility: This mode resolves various compatibility issues faced with VPNs, multicast applications, and IPv6 support in the older NAT-based networking.
• Simplified communication: Both WSL applications and Docker containers can directly access each other and other network resources on the host machine, eliminating the need for complex port forwarding configurations.
• Enhanced development workflow: Developers can easily test and debug web applications or microservices that span across both Linux and Windows environments.
• Direct LAN access: WSL applications can now directly connect to other devices on your local network, opening up new possibilities for network-aware applications.

How to enable it?

To enable WSL mirrored mode networking, you need to:

• Ensure you have WSL 2 version 2.0.4 or later: Check your WSL version by running wsl -l in a PowerShell terminal. Edit the .wslconfig file: This file contains configuration settings for your WSL distribution. You can find it in the %AppData%\Microsoft\Windows\WSL directory. Open the file with a text editor and add the following line under the [wsl2] section:

networkingMode=mirrored

• Restart your WSL distribution: Run wsl –shutdown in a PowerShell terminal to gracefully shut down your WSL distribution. Then, simply restart it using the usual methods.

A Quick Test

Assuming that you have a fresh Windows 11 system with Docker Desktop installed.

wsl -l
Windows Subsystem for Linux Distributions:
docker-desktop-data (Default)
docker-desktop

Install Ubuntu Distro

wsl --install -d ubuntu
Installing: Ubuntu
Ubuntu has been installed.
Launching Ubuntu...
Installing, this may take a few minutes...
\\\



Please create a default UNIX user account. The username does not need to match your Windows username.
For more information visit: https://aka.ms/wslusers
Enter new UNIX username: ajeetraina
New password:
Retype new password:
passwd: password updated successfully
The operation completed successfully.
Installation successful!
To run a command as administrator (user "root"), use "sudo <command>".
See "man sudo_root" for details.



Welcome to Ubuntu 22.04.3 LTS (GNU/Linux 5.15.133.1-microsoft-standard-WSL2 x86_64)

 * Documentation:  https://help.ubuntu.com
 * Management:     https://landscape.canonical.com
 * Support:        https://ubuntu.com/advantage


This message is shown once a day. To disable it please create the
/home/ajeetraina/.hushlogin file.

Don’t forget to click “Refetch Distro” to integrate Docker Desktop with this new WSL2 distro.

Setting up Firewall(optional)

Microsoft recommends setting up the following firewall rules

Set-NetFirewallHyperVVMSetting -Name '{40E0AC32-46A5-438A-A0B2-2B479E8F2E90}' -DefaultInboundAction Allow

New-NetFirewallHyperVRule -Name MyWebServer -DisplayName "My Web Server" -Direction Inbound -VMCreatorId "{40E0AC32-46A5-438A-A0B2-2B479E8F2E90}" -Protocol TCP -LocalPorts 80

The first command uses the Set-NetFirewallHyperVVMSetting cmdlet in Windows PowerShell to configure the default inbound action for Hyper-V virtual machines. The second command utilizes the New-NetFirewallHyperVRule cmdlet to create a new inbound firewall rule for a Hyper-V virtual machine.

Running Nginx container on the 1st Distro

ajeetraina@ajeetsraina:~$ sudo docker version
Client: Docker Engine - Community
 Version:           26.0.0
 API version:       1.45
 Go version:        go1.21.8
 Git commit:        2ae903e
 Built:             Wed Mar 20 15:17:48 2024
 OS/Arch:           linux/amd64
 Context:           default

Server: Docker Engine - Community
 Engine:
  Version:          26.0.0
  API version:      1.45 (minimum version 1.24)
  Go version:       go1.21.8
  Git commit:       8b79278
  Built:            Wed Mar 20 15:17:48 2024
  OS/Arch:          linux/amd64
  Experimental:     false
 containerd:
  Version:          1.6.28
  GitCommit:        ae07eda36dd25f8a1b98dfbf587313b99c0190bb
 runc:
  Version:          1.1.12
  GitCommit:        v1.1.12-0-g51d5e94
 docker-init:
  Version:          0.19.0
  GitCommit:        de40ad0

ajeetraina@ajeetsraina:~$ curl localhost:8081
<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>
<style>
html { color-scheme: light dark; }
body { width: 35em; margin: 0 auto;
font-family: Tahoma, Verdana, Arial, sans-serif; }
</style>
</head>
<body>
<h1>Welcome to nginx!</h1>
<p>If you see this page, the nginx web server is successfully installed and
working. Further configuration is required.</p>

<p>For online documentation and support please refer to
<a href="http://nginx.org/">nginx.org</a>.<br/>
Commercial support is available at
<a href="http://nginx.com/">nginx.com</a>.</p>

<p><em>Thank you for using nginx.</em></p>
</body>
</html>
ajeetraina@ajeetsraina:~$ sudo docker run -d -p 8082:80 nginx:alpine
4831c487bb332e0ef122ec835202dec73245a88b3ee55abbc639d9297c6b1375
ajeetraina@ajeetsraina:~$

Try accessing it via Windows web browser.

Listing the WSL2 Distro

 wsl -l -v
  NAME                   STATE           VERSION
* docker-desktop-data    Running         2
  docker-desktop         Running         2
  Ubuntu                 Running         2

Adding a New Node

 wsl --install -d debian

Refetch the 2nd WSL 2 Distro

Click “Refetch Distro” to integrate Docker Desktop with this new WSL2 distro.

If you try accessing the Nginx server running on the 1st container, you should be able to access it via 2nd node.

Key Benefits:

• No port conflicts: Eliminates the need to manage port mappings, reducing configuration complexity.
• Isolated networks for containers: Each container has its own – IP address within the shared network, promoting better isolation and security.
• Direct communication: Containers can communicate directly using hostnames or IP addresses, simplifying service discovery and interaction.
• Easier multi-container testing: Simplifies testing and debugging of complex systems with multiple containers, reducing setup overhead.

Please Note:

• WSL mirrored mode networking is still under development, and you might encounter some bugs or limitations.This mode can potentially expose your WSL applications to a wider network surface, so be mindful of security considerations.
• Some applications might require additional configuration to work properly with the shared network space.

WSL mirrored mode networking is a promising advancement that simplifies development workflows and unlocks new possibilities for working with WSL and Docker containers. If you’re a developer who frequently juggles between Linux and Windows environments, it’s definitely worth exploring!

Reference

• https://github.com/microsoft/WSL/issues/10494

Keep Reading