Skip to content
WSLDeep Dive Published Updated 5 min readViews unavailable

WSL2's Networking Modes: NAT and Mirrored, Explained

WSL2's original NAT networking isolates it from your LAN by default; mirrored mode, added later, takes a fundamentally different approach with real tradeoffs.

WSL2 runs inside a real, lightweight virtual machine — which means, unlike WSL1, it needs an actual virtual network interface, not just direct access to the host’s own networking stack. How that virtual network is configured has changed meaningfully since WSL2’s original design.

The original design: NAT networking

WSL2’s original and longtime-default networking mode puts the WSL2 VM behind NAT (Network Address Translation) — WSL2 gets its own private IP address on a virtual network Windows manages, translated through to the host’s actual network connection, conceptually similar to how a home router puts every device on your LAN behind one public IP address.

What NAT mode actually breaks

Because WSL2 sits behind its own private, translated network under NAT mode, other devices on your actual physical LAN can’t directly reach a service running inside WSL2 by the host machine’s own LAN IP address — a web server running inside WSL2, for instance, isn’t automatically reachable from another computer on the same network the way a service running directly on Windows would be, without additional port-forwarding configuration.

Mirrored networking mode’s different approach

Mirrored networking mode, added as a newer option, instead gives the WSL2 VM the same network interfaces and IP addressing as the Windows host itself — services running inside WSL2 become directly reachable on the LAN using the host’s own IP address, without needing NAT traversal or manual port-forwarding rules.

The tradeoffs mirrored mode actually introduces

Mirrored mode’s tighter network integration comes with its own considerations — VPN compatibility behaves differently than under NAT mode, and some networking edge cases behave differently than either a purely native Linux machine or the older NAT-based WSL2 default, since the underlying implementation is still bridging a virtualized Linux network stack with the physical host’s real interfaces.

How to actually choose between them

%UserProfile%\.wslconfig

[wsl2]
networkingMode=mirrored

Setting networkingMode=mirrored in the global .wslconfig file switches to mirrored networking; omitting it or setting it to nat keeps the original default behavior.

Why this choice actually matters for real workloads

Anyone running a WSL2-hosted service that needs to be reachable from other devices on their network — testing a web app from a phone on the same Wi-Fi, for instance — runs directly into NAT mode’s isolation, making mirrored mode a genuine practical improvement for that specific, common use case rather than just a networking implementation detail.

Why NAT was the reasonable original default anyway

NAT networking is a well-understood, broadly compatible pattern that isolates WSL2’s virtual network from directly participating in the host’s LAN — a reasonable, conservative default for a virtualized subsystem, even though it created real friction for the specific, common case of wanting to reach a WSL2-hosted service from elsewhere on the same network, which mirrored mode was introduced specifically to address.

The Hyper-V firewall’s role under mirrored mode

Mirrored mode’s tighter integration means a companion piece of infrastructure, the Hyper-V firewall, becomes directly relevant to what’s actually reachable — starting with Windows 11 version 22H2 and WSL 2.0.9 and higher, this firewall is active by default for WSL traffic specifically. Because a service being reachable from the Windows host doesn’t automatically mean it’s reachable from the wider LAN once this firewall layer is involved, confirming actual reachability from a genuinely separate machine on the network — not just from the Windows host itself — is a necessary verification step, not an assumption safe to skip.

Checking which mode is actually active

cat /etc/resolv.conf
ip addr

Comparing the IP address WSL reports for itself against the Windows host’s own IP address (via ipconfig on the Windows side) is a direct, concrete check: under mirrored mode, they match; under NAT mode, WSL’s address is a distinct, private address on its own separate virtual subnet. This is a more reliable confirmation of which mode is actually active than assuming based solely on what’s configured in .wslconfig, since a fallback to NAT can occur silently on systems that don’t meet mirrored mode’s requirements.

When mirrored mode silently isn’t available

Mirrored networking has real prerequisites — a sufficiently current Windows 11 build, a sufficiently current WSL version, and certain network adapter or virtualization configurations. On a system that doesn’t meet these, WSL can fall back to NAT networking automatically, which is worth checking for directly if mirrored mode was configured but LAN reachability still isn’t working as expected — the configuration may be correctly set, while the underlying platform silently isn’t honoring it due to an unmet prerequisite.

Choosing a mode isn’t strictly permanent

Switching between NAT and mirrored mode is a .wslconfig edit plus a wsl --shutdown and restart, not a one-way architectural commitment — testing mirrored mode for a specific project’s LAN-reachability needs, then reverting if it introduces an unrelated compatibility issue with a specific VPN client or network tool, is a reasonable, low-risk way to evaluate whether it’s actually the better fit for your specific setup rather than treating the choice as high-stakes.

Port forwarding as the older NAT-mode workaround

Before mirrored mode existed, the standard workaround for reaching a WSL2-hosted service from elsewhere on the LAN under NAT mode was manually configuring Windows port-forwarding rules (via netsh interface portproxy) to relay traffic from the host’s own LAN-facing address into WSL2’s private NAT address. This still works today for anyone specifically needing to stay on NAT mode for other compatibility reasons, but it’s manual, per-port configuration that mirrored mode makes unnecessary for the general case — worth knowing about specifically as the older, still-valid alternative for setups that have a specific reason to avoid mirrored mode’s own trade-offs.

Related:

Sources:

Comments