Windows Subsystem for Linux (WSL 2) provides a high-performance environment for running Linux distributions directly inside Windows 11. However, since its inception, WSL 2 relied on a virtual Network Address Translation (NAT) architecture. Under standard NAT, the Linux virtual machine receives an independent IP subnet isolated from the host Windows machine. This frequently complicated web development workflows: accessing Windows services from Linux required resolving virtual gateway IPs, corporate VPNs disrupted connectivity, and binding network servers across localhost required port-forwarding gymnastics. To resolve these friction points, Microsoft introduced Mirrored Networking Mode to WSL 2 in Windows 11.
What Is Mirrored Networking Mode?
Mirrored networking mode replaces the isolated NAT adapter with a direct network mirror. Under mirrored mode:
- Shared Network Identity: WSL 2 mirrors the exact network interfaces, IP addresses, and routing tables of your Windows host.
- Bi-Directional Localhost Binding: A web server running on port
3000inside Ubuntu is immediately reachable athttp://localhost:3000in Windows Edge, and vice versa. - Full IPv6 Support: WSL 2 inherits native IPv6 connectivity from your host network adapter.
- VPN Compatibility: Enterprise VPN clients (such as Cisco AnyConnect, GlobalProtect, and OpenVPN) route traffic seamlessly through WSL without custom routing scripts.
- LAN Accessibility: Local area network devices can communicate with Linux server daemons directly using your PC’s physical IP address.
System Requirements
To enable mirrored networking, ensure your computer satisfies these requirements:
- Operating System: Windows 11 version 23H2 or Windows 11 22H2 (Build 22621.2361 or higher).
- WSL Version: WSL 2.0.0 or higher (distributed via Microsoft Store or GitHub, not the legacy Windows optional feature).
To verify your WSL engine version, open Windows Terminal (PowerShell) and execute:
wsl --version
If WSL reports version 1.x or fails to recognise the --version switch, update via:
wsl --update
Step-by-Step Configuration
WSL 2 global runtime configurations are managed through a configuration file named .wslconfig located in your Windows user profile folder.
Step 1: Create or Edit the .wslconfig File
Open Windows Terminal and create or edit the configuration file using Notepad:
notepad "$env:USERPROFILE\.wslconfig"
If Windows prompts that the file does not exist, click Yes to create it.
Step 2: Add Mirrored Networking Parameters
Paste the following configuration blocks into the editor:
[wsl2]
networkingMode=mirrored
dnsTunneling=true
firewall=true
autoProxy=true
Here is what each parameter provides:
networkingMode=mirrored: Activates the mirrored network stack.dnsTunneling=true: Routes Linux DNS lookups through Windows virtualization agents, solving corporate proxy and VPN DNS resolution failures.firewall=true: Applies Windows Defender Firewall rules directly to Linux network sockets for security compliance.autoProxy=true: Automatically forwards Windows HTTP/HTTPS proxy settings into your Linux environment.
Save the file (Ctrl + S) and close Notepad.
Step 3: Restart the WSL Subsystem
For changes to take effect, cleanly shut down the WSL virtual machine container:
wsl --shutdown
Wait approximately five seconds, then launch your Linux distribution:
wsl
Verifying Mirrored Connectivity
Once inside your Linux shell, run network diagnostic commands to confirm the mirrored stack is active:
1. Inspecting IP Addresses
ip addr show
Instead of displaying an internal 172.x.x.x virtual subnet, the Linux interface now reflects your physical Wi-Fi or Ethernet adapter IP (e.g. 192.168.1.150).
2. Testing Localhost Binding
Spin up a quick Python HTTP server inside your WSL terminal:
python3 -m http.server 8080
Open your browser in Windows 11 and navigate to http://localhost:8080. The directory index appears instantly without requiring firewall rules or IP translation.
Troubleshooting Port Conflicts
Because Windows and WSL share the same network identity under mirrored mode, two services cannot bind to the exact same TCP port simultaneously. If you run a local PostgreSQL instance on Windows (port 5432), a Docker or native PostgreSQL daemon inside WSL attempting to bind to 5432 will report Address already in use. Ensure conflicting background services on Windows are stopped or configured to distinct ports.