WSL2: Advanced guide to network configuration and NAT and mirrored modes

Informatec Digital » Resources » WSL2: Advanced guide to network configuration and NAT and mirrored modes

WSL2 has completely changed the way Linux integrates with WindowsEspecially in everything related to the network: we now have a lightweight virtual machine with its own network stack, its own IP address, and separate access rules. This opens up a lot of possibilities for development, testing, containers, and self-hosting environments, but it also raises concerns when services become inaccessible, as happened with WSL1.

Understanding WSL2 network configuration, its NAT and mirrored modes, the use of .wslconfig and wsl.conf, and how they interact with firewalls, VPNs, Docker, or tools like Tailscale This is key to avoiding headaches. Let's see step by step how this whole setup works, how to expose services to Windows and the LAN, what commands to use to obtain the correct IPs, and what advanced configuration options you have to fine-tune your environment, making it stable and, above all, secure.

How the network actually works in WSL2

WSL2 no longer shares the host network stack like WSL1Instead, it runs each Linux distribution within a small virtual machine managed by Hyper-V. That VM has its own virtual adapter (usually eth0) and a private IP address assigned by an internal virtual switch.

In its default mode, WSL2 uses a NAT-based architecture (Network Address Translation). Windows acts as the router/host, and the Linux distribution resides on a private subnet, typically within the range. 172.16.0.0/12This subnet can change after reboots or WSL restarts, something that has driven more than one person crazy when configuring static firewall rules.

From a practical point of view, this means that your WSL2 distro's IP address is neither stable nor directly accessible from the LAN As with WSL1: by default, there is only connectivity between Windows and WSL2 through redirection rules and NAT, and exposure to the local network requires extra steps or the use of mirrored mode.

In addition to this base architecture, Windows 11 22H2 and later versions add new networking capabilities (mirrored mode, dnsTunneling, autoProxy, Hyper-V firewall, etc.) that are controlled from the global file .wslconfigwhile certain options within Linux are managed with /etc/wsl.conf.

Identify IP addresses in WSL2

Working with WSL2 involves clearly distinguishing between two IP scenarios: when you need the IP address of the Linux distribution and when you need the IP address of the Windows host viewed from Linux. Each is resolved with a different command.

Scenario 1: From Windows you want to know the IP address of the WSL2 distro To allow an application on the host (for example, a client, browser, or testing tool) to connect to a service running within Linux. To do this, you can run the following commands in Windows (using CMD or PowerShell):

wsl.exe --distribution <DistroName> hostname -i

If you want to use the default distro, you can omit the distribution parameter. and simply call wsl.exe hostname -iIn the background, this command launches in Linux hostname --ip-addresses and returns the instance's IP address. A typical result might look something like this:

172.30.98.229

Scenario 2: From the Linux distro you need to know the IP address of the Windows hostFor example, to connect a WSL2 application to a server running natively on Windows (Node.js, SQL Server, Caddy, etc.). Within the Linux shell, you can use:

ip route show | grep -i default | awk '{ print $3 }'

The output will be the default gateway of the WSL2 VM, which corresponds to the IP address of the Windows host as seen from Linux, something like:

172.30.96.1

That value (for example, 172.30.96.1) is the address to which your Linux clients should point when you want to access services running on the Windows host while in classic NAT mode.

NAT mode: default behavior of the WSL2 network

Out of the box, WSL2 works in NAT mode, and for many simple development environments, this is more than sufficient.The important thing is to understand what works "on its own" and what doesn't, so as not to waste time chasing ghosts.

Accessing Linux services from Windows using localhostIf you run a network application (for example, a Node.js server, a Flask server, a SQL Server on Linux) on your WSL2 distro, you can access it from Windows using localhost:puertoWindows automatically forwards incoming connections to the internal IP address of the WSL2 VM.

Accessing services running on Windows from LinuxHere's where things change. To reach a network application on the host (such as a Node.js server, SQL Server, or Caddy on Windows) from WSL2, you have to use the host's IP address as seen from Linux, obtained with the default route command:

ip route show | grep -i default | awk '{ print $3 }'

With that IP address you can connect from Linux to any service on the host, for example http://172.30.96.1:3000 if your Windows server listens on port 3000 on all interfaces.

When you connect using remote IPs (not localhost), applications see them as LAN connections.This means that many servers must be configured to listen on 0.0.0.0 instead of 127.0.0.1For example, with Flask you could launch:

app.run(host='0.0.0.0')

This change improves accessibility but requires a focus on security.because you are allowing connections from your local network, not just from the computer itself.

Accessing WSL2 from the local area network (LAN) using NAT

One of the most annoying changes when moving from WSL1 to WSL2 is that distributions are no longer directly accessible from the LANIn WSL1, if your Windows was visible on the network, the distro's services inherited that exposure almost effortlessly.

In WSL2, the VM has its own private IP address and is not automatically advertised on the LAN.To achieve something similar to the old behavior, in NAT mode you have to create a port proxy in Windows, as you would with any Hyper-V virtual machine.

Windows includes a classic tool for this: netsh interface portproxyA typical command to redirect a host port to the WSL2 IP/port would be:

netsh interface portproxy add v4tov4 listenport=<puertoHost> listenaddress=0.0.0.0 connectport=<puertoWSL> connectaddress=(wsl hostname -I)

In practice, you would replace the markers with specific values., For example:

netsh interface portproxy add v4tov4 listenport=4000 listenaddress=0.0.0.0 connectport=4000 connectaddress=192.168.101.100

Here listenaddress=0.0.0.0 This indicates that Windows will listen on all IPv4 addresses of the host.and will forward what comes in through port 4000 to 192.168.101.100:4000which would be the WSL2 IP address obtained with:

• wsl hostname -I It gives you the IP address of the Linux distro inside the WSL2 VM
• cat /etc/resolv.conf It reveals the IP address of the Windows Vista host from WSL2.

With this technique you can make a service running on WSL2 accessible from any computer on the LANprovided that the Windows firewall allows it and you are clear that you are exposing a service of a VM, not the host directly.

IPv6 and modern networking features

WSL2 can also work with IPv6, which is especially relevant in modern environments, VPNs, and corporate networks.To handle addresses, the basic commands in Linux are equivalent to those of IPv4:

• wsl hostname -i From Windows to view the IP address of the WSL2 distribution
• ip route show | grep -i default | awk '{ print $3 }' from Linux to obtain the IP address of the Windows host

Where the leap in quality in IPv6 and VPN support is truly noticeable is in mirrored network mode, available in Windows 11 22H2 and later versions, which we will see in detail later.

Mirrored network mode: mirroring Windows interfaces in Linux

On computers with Windows 11 22H2 or higher, you can enable "mirrored" network mode. In WSL2, the model changes completely: instead of classic NAT, Linux "sees" the Windows network interfaces reflected.

To enable it, you need to edit the file .wslconfig of your user, found in %UserProfile%\.wslconfigFrom PowerShell with administrator privileges, you can open it with:

notepad $env:USERPROFILE\.wslconfig

Inside, add (or modify) the [wsl2] section to activate mirrored mode:

[wsl2]
networkingMode=mirrored

Once the file is saved, you need to restart WSL2 for it to take effect.For example, with:

wsl --shutdown

When you restart it, WSL will use the new mirrored network architecture.which brings several very powerful advantages:

• Native IPv6 support and improved integration with corporate networks and VPNs
• Ability to connect to Windows services from Linux using 127.0.0.1 directly (although it is not allowed) ::1 (such as IPv6 loopback for this)
• Improved multicast support within the Windows-Linux integration
• Direct access to WSL from the LAN without needing netsh portproxyusing the IP address of the Windows machine itself

Enabling this mode resolves many of the classic WSL2 NAT problems and it is the recommended option in most modern development and self-hosting environments where you can use an updated version of Windows 11.

DNS tunneling and the use of proxies in WSL2

In Windows 11 22H2 and later versions, name resolution from WSL2 has also received a significant overhaul.The key lies in two functionalities defined in .wslconfig: dnsTunneling y autoProxy.

The option dnsTunneling It is enabled by default in the [wsl2] section. This allows Linux DNS requests to be handled through a virtualization feature, rather than being sent out as normal network packets. This greatly improves compatibility with VPNs and complex network configurations on the host.

For its part, autoProxy=true forces WSL to use the Windows HTTP proxy settingsIf the host is behind a corporate or security proxy, WSL2 automatically inherits it without you having to wrestle with environment variables manually.

You could have, for example, something like this in your .wslconfig:

[wsl2]
dnsTunneling=true
autoProxy=true

This ensures that the WSL2 network behaves consistently with the host configuration., especially useful in companies with strict network and filtering policies.

Hyper-V Firewall and Secure Service Exposure

In modern environments, the WSL2 network also passes through a dedicated firewall.Starting with WSL 2.0.9 on Windows 11 22H2, the Hyper-V firewall feature is enabled by default, adding an extra layer of filtering for VM traffic (including WSL2 traffic).

If you are working in mirrored mode and want to permanently expose WSL2 services to the LAN (for example, APIs, dashboards or self-hosting services), you need to make sure that the firewall rules allow it.

A reasonable approach from PowerShell with administrator privileges is to create a Hyper-V rule for private networks:

New-NetFirewallHyperVRule -DisplayName "WSLPrivateInboundRule" -Profiles Private -Direction Inbound -Action Allow -VMCreatorId ((Get-NetFirewallHyperVVMCreator).VMCreatorId)

If for any reason you want to disable that specific Hyper-V protection (something less recommended), you could use:

Set-NetFirewallHyperVVMSetting -Name ((Get-NetFirewallHyperVVMCreator).VMCreatorId) -Enabled False

The idea is to keep the firewall active whenever possible.limiting rules to private networks and only to the ports you really need, and reserving any mass deactivation as a last resort and always with a view to hardening the configuration again as soon as everything is working.

WSL2 network architecture, X11 and 172.16.0.0/12 ranges

A classic case that reveals details of the WSL2 network is the use of graphical applications via X11For example, launching Xming on Windows and sending Linux applications via DISPLAY.

When upgrading from WSL1 to WSL2, many users find that X stops working. because the network ceases to be "shared" and becomes a virtual NAT network with ranges such as 172.16.0.0/12which can also change after each Windows or WSL restart.

To get X working again with Xming from WSL2, the usual trick is to obtain the Windows IP address that Linux sees. using:

ens

DISPLAY=$(grep nameserver /etc/resolv.conf | cut -d' ' -f2):0

In parallel, it is necessary to adjust the Windows firewall to allow X11 traffic from that NAT subnetA typical approach is to edit the Xming rule by adding the range 172.16.0.0/12 in TCP+UDP 6000.

Many end up disabling Xming authentication with the option -acThis effectively "opens the door" to any client X arriving from that network. It works, but from a security standpoint it's quite questionable, so it's worth considering more limited solutions or using WSLg (integrated GUI applications) in Windows 11.

wsl.conf and .wslconfig: advanced WSL2 configuration

WSL offers two key configuration files that control both the behavior of the VM and that of each distribution.: /etc/wsl.conf (by distro) and %UserProfile%\.wslconfig (global for all WSL2 distros).

wsl.conf lives within the Linux distribution, in /etc/wsl.confIt is used to configure local options for that distro: auto-mounts, generation of hosts y resolv.confinteroperability with Windows, default user, systemd, etc.

.wslconfig It is saved outside of Linux, in the Windows user profile. (C:\Users\<Usuario>\.wslconfig) and controls global parameters of the VM that powers WSL2: memory, CPUs, kernel, network mode, firewall, DNS, virtual disk size, GUI support, etc.

One curious detail is the "8-second rule" when changing settingsWhen you modify any of these files, you must ensure that the WSL VM is completely shut down. Even if you close the distro window, it may remain in memory for a few seconds.

To force a subsystem restart you can use:

• wsl --list --running to check if there are any active distros
• wsl --shutdown to close all distributions at once
• wsl --terminate <distroName> to stop a specific distro

The configuration changes are only actually applied when WSL is shut down and restarted.Something that many overlook and think their adjustments "don't work".

Main wsl.conf options by section

The file wsl.conf It is inspired by the classic .ini format, with sections and keysThe main sections are [automount], [network], [interop], [user], [boot], [gpu] y [time].

En [automount] You control how Windows drives are mounted within Linux (typically low) /mnt):

• enabled (bool, default true)If true, C:/, D:/, etc. are automatically mounted in /mnt/c, /mnt/d...
• mountFsTab (bool): if it is true, it is processed /etc/fstab when starting the distro.
• root (chain): root directory where the drives will be mounted, for example /windir/ in order to have /windir/c.
• options (comma-separated list): DrvFs-specific parameters such as metadata, uid, gid, umask, fmask, dmask o case.

DrvFs is the file system that bridges Windows and Linux., designed to access NTFS from WSL with permission control, metadata and case sensitivity.

In the section [network] You adjust the automatic generation of network files:

• generateHostsIf true, WSL automatically generates /etc/hosts.
• generateResolvConfIf true, WSL creates /etc/resolv.conf with legacy DNS.
• hostname: hostname that the distribution will use.

The section [interop] controls interoperability with Windows:

• enabled: Enables or disables the ability to launch Windows processes from WSL.
• appendWindowsPath: decides whether to add Windows paths to $PATH Linux.

En [user] You can specify the user that will be used by default when starting the distro:

• default: username that will be started by default in WSL.

The section [boot] It is particularly useful in Windows 11 and Server 2022 to automatically launch services, such as Docker within WSL:

• command: command string to execute when starting WSL, for example service docker start.
• protectBinfmt: protects the generation of systemd units when systemd is enabled.

You also have sections like [gpu] (enable access to the Windows GPU from Linux), and [time] to synchronize the time zone with WindowsThis prevents problems when you change to summer time or travel.

.wslconfig: WSL2 virtual machine control

While wsl.conf fine-tunes the behavior of each distro, .wslconfig allows you to fine-tune the VM shared by all WSL2 distros.This file is only taken into account by distributions that run as WSL2, not WSL1.

Within .wslconfig the main section is [wsl2]where you define key parameters:

• kernel y kernelModules: absolute paths from Windows to a custom Linux kernel and its modules.
• memory: VM memory limit (default 50% of host RAM), for example 4GB.
• processors: number of logical processors assigned to the VM.
• localhostForwarding: allows open ports in WSL2 to be accessible from Windows using localhost.
• swap y swapFile: size and path of the swap file for the VM.
• guiApplications: enables or disables GUI application support (WSLg).
• dnsProxyWhen you are in NAT mode, it decides whether the Linux DNS server will be the host's NAT instance or a copy of the Windows DNS.
• networkingModeHere you choose between none, nat, bridged (obsolete), mirrored o virtioproxy.
• firewall, dnsTunneling y autoProxy: options we have discussed to better integrate the WSL network with Windows policies.
• defaultVhdSize: maximum size of the VHD where the distro's file system is stored (default 1 TB).

There is also a section [experimental] where features are activated in testing on the table:

• autoMemoryReclaim: automatic memory recovery settings (disabled, gradual, dropCache).
• sparseVhd: creation of sparse virtual disks to save space.
• bestEffortDnsParsing y dnsTunnelingIpAddress: fine-tuning for DNS tunneling.
• ignoredPorts: ports that Linux apps can use even if they are in use on Windows when you are in mirrored mode.
• hostAddressLoopback: allows host and container to connect using local IP addresses of the host in mirrored mode.

Properly configuring .wslconfig makes the difference between a resource-guzzling VM and an optimized environment that works well with your Windows system and network.especially if you work with heavy workloads, containers, or multiple simultaneous distros.

WSL2, Docker, and networking for self-hosting with Tailscale

A very practical example is using WSL2 on Windows servers (even Windows Server 2025) as a self-hosting platform, combining Ubuntu on WSL2, Docker Engine (without Docker Desktop), Tailscale and a reverse proxy like Caddy to expose services like n8n or Supabase.

The idea is to have a stable Docker environment within WSL2, avoiding the problems of Docker Desktop on serversWhen installing Docker Engine directly on Ubuntu (WSL2), the container network relies on the WSL2 network, which in turn depends on the NAT or mirrored mode defined in .wslconfig.

With Tailscale installed on WSL2, you can publish your services on a mesh VPN. without opening ports on the router, and using Caddy as a reverse proxy to centralize TLS certificates, routes, and lightweight load balancing between containers.

To maintain a clean, predictable, and secure network, it is advisable:

• Choose a single coherent network mode (NAT or mirrored) and document it
• Avoid port conflicts between Windows and WSL2, relying on ignoredPorts if you use mirrored
• Control service exposure only via Tailscale or Caddyinstead of opening ports "by default" in the firewall
• Automate the startup of Docker, Tailscale, and Caddy from [boot] in wsl.conf to have an environment closer to production

With this architecture, WSL2 ceases to be just a development tool and can become a fairly serious self-hosting platform.provided you accept its limitations (virtualization over Hyper-V, additional network layer, etc.) and configure it carefully.

Best practices for WSL2 networking for development and testing

Aside from the fine-tuning, there are a number of guidelines that help you work comfortably with the WSL2 network without constantly battling with IPs, ports, and firewalls.

For development services, use high ports (above 1024) and avoid privileged or heavily used ports; this minimizes conflicts and eliminates the need for extra privileges.

Ensure that the code and data reside within the Linux file system. (you ~/ or internal routes) instead of working directly on /mnt/cbecause accessing NTFS from WSL is slower and can penalize I/O-intensive services.

Automate network settings and redirection rules with scripts In PowerShell and Bash: for example, a script that configures WSL2 when it starts. netsh portproxy (if you continue with NAT) or check firewall rules when using mirroring.

Avoid relying on changing IPs generated by the internal virtual switch. Whenever possible, work with localhost, hostnames or entries in /etc/hosts for your services, so that an IP change doesn't break half your testing infrastructure.

In professional or semi-production environments, it's best not to blindly rely on WSL's automatic forwarding.Explicitly configure ports, proxies, and firewall rules to know exactly what is exposed and where.

When properly configured, WSL2 offers an isolated yet flexible network, perfect for advanced development, API testing, working with containers, and simulating distributed environments.The key is to master network modes (NAT vs mirrored), the wsl.conf and .wslconfig files, and the interaction with the firewall and the tools in your stack (Docker, Tailscale, reverse proxies), so that Windows and Linux can run on the same machine without overlapping ports or compromising security.