WSL2 networking: mirrored mode, localhost and LAN access

Verified 2026-10-282 min read

Choose between WSL2 NAT and mirrored networking, edit .wslconfig correctly, and test Windows-to-Linux and Linux-to-Windows connections.

Tested onPro (26H2) · Build 26300.9457 · x64

Build: 26300.9457
Edition: Pro (26H2)
Architecture: x64
Support: Documentation (E1)
Evidence: E1Official documentation
Verified: 2026-10-28
Page type: Task

The short answer

WSL2 defaults to NAT, which gives the distro a private address behind Windows. That is fine for outbound traffic, but inbound access from the LAN and some VPN setups are awkward.

Mirrored networking makes WSL share the Windows host’s network interfaces. It improves localhost, LAN and VPN compatibility, but it is not a magic bridge: Hyper-V firewall, port conflicts and IPv6 still matter.

NAT vs mirrored

	NAT (default)	Mirrored
WSL IP	Private, changes on restart	Shares host interfaces
Windows → WSL service	`localhost` may work with forwarding	`localhost` works more consistently
WSL → Windows service	Host IP/`localhost` varies	Host interfaces visible
LAN → WSL service	Needs port proxy/firewall	Can bind host interface, subject to firewall
VPN	Often breaks or needs routes	Better compatibility, not guaranteed
IPv6	Limited	Supported where host supports it
Configuration	None	`.wslconfig` + restart

Enable mirrored mode

Edit %UserProfile%\.wslconfig:

[wsl2]
networkingMode=mirrored

Then restart WSL:

wsl --shutdown
wsl --version

Check the distro:

ip addr
ip route

You should see interfaces that mirror the Windows host, not a single NAT eth0.

Test both directions

Windows → WSL

Start a listener inside WSL:

python3 -m http.server 8000

From Windows:

curl.exe http://localhost:8000/

WSL → Windows

Run a listener on Windows (PowerShell):

python -m http.server 8001

From WSL:

curl http://localhost:8001/

If localhost fails, try the Windows LAN IP. If both fail, check the Hyper-V firewall and Windows Defender Firewall.

Configuration matrix

Goal	Mode	Extra setting
Windows browser → WSL dev server	Mirrored	None; bind to `0.0.0.0` or `localhost`
LAN phone → WSL dev server	Mirrored	Allow the port in Hyper-V/Windows firewall
WSL → Windows service	Mirrored	Bind the Windows service to the LAN interface, not only `127.0.0.1`
Corporate VPN + WSL	Mirrored	Test with VPN on; some clients still need routes
Docker Desktop only	NAT (default)	Use Docker port publishing
Strict isolation from LAN	NAT	Do not add a port proxy

Firewall check (elevated PowerShell):

Get-NetFirewallHyperVVMSetting -Name '{40E0AC32-46A5-438A-A0B2-2B479E8F2E90}' |
  Select-Object Name, DefaultInboundAction, DefaultOutboundAction

The GUID is the WSL Hyper-V firewall profile. If inbound is blocked, add a narrow rule for the port; do not set the whole profile to allow.

Common blockers

Hyper-V firewall. Mirrored mode uses the Hyper-V firewall; a blocked inbound rule looks like “the service is not running”.
Port already in use. Windows and WSL can both try to bind :8000; pick a free port or stop the other listener.
VPN. Some VPN clients rewrite routes/DNS. Test with the VPN on and off; do not assume mirrored mode fixes every tunnel.
Docker Desktop. Its own port publishing and WSL integration can add another layer. Test the container directly before blaming WSL.
IPv6. A service bound only to 127.0.0.1 is not reachable over IPv6; bind explicitly.

When to stay on NAT

You only need outbound internet and a local dev server on Windows.
You use Docker Desktop’s port mapping and it already works.
Your VPN vendor documents NAT-specific behaviour.
You do not want WSL to share host interfaces.

Mirrored mode is a compatibility choice, not a speed setting.

Lab note

The lab has WSL 3.0.3 and Ubuntu 24.04, but this page was not re-tested with mirrored networking. It is E1. If you change .wslconfig on a working machine, keep a copy of the old file and be ready to wsl --shutdown and revert.