WSL2 Networking Problems: DNS, Ports, and Firewall Rules

14 Aug 2026

Windows Subsystem for Linux 2 gives developers a genuine Linux environment inside Windows 11 without requiring a traditional dual-boot setup or a separately managed virtual machine.

When its networking works, a development server started in Ubuntu can be opened from a Windows browser at localhost. Linux tools can download packages, connect to databases and use company resources through the Windows network connection.

When it stops working, the symptoms can be confusing:

Linux can ping an IP address but cannot resolve domain names.
apt update reports temporary DNS failures.
A website works in Windows but not inside WSL.
A development server runs in Linux but will not open in the Windows browser.
localhost works on the PC but not from another device.
WSL loses internet access when a VPN connects.
A port appears to be listening but Windows Firewall blocks it.
WSL networking fails after a Windows, VPN or security-policy change.
A service inside WSL cannot reach a service running on Windows.
Docker, Kubernetes or another tool reports that a port is already in use.

These problems are usually caused by one of three areas:

DNS: WSL has network connectivity but cannot translate names into IP addresses.
Ports: The application is listening on the wrong address or traffic is not being forwarded correctly.
Firewall and VPN rules: Windows, Hyper-V, endpoint security or the corporate network is blocking or redirecting traffic.

The safest approach is to identify which layer has failed before changing DNS files, opening firewall ports or resetting the whole WSL installation.

First: Understand How WSL2 Networking Works

WSL2 runs Linux inside a lightweight virtualised environment. Traditionally, it has used a Network Address Translation architecture that gives Linux its own virtual IP address behind the Windows host.

Microsoft now recommends trying mirrored networking mode for newer Windows 11 systems because it improves VPN compatibility, IPv6 support, multicast support, local-area-network access and communication between Windows and Linux. (learn.microsoft.com⁠)

Default NAT Mode

In the traditional NAT arrangement:

WSL receives its own private virtual IP address.
Windows can normally access services running in WSL through localhost.
Linux normally reaches Windows-hosted services through the Windows host’s virtual-network address.
Direct connections from another computer on the LAN may need port forwarding.
The WSL virtual IP can change when the WSL virtual machine restarts.

Microsoft documents NAT as WSL’s default networking architecture and provides separate commands for finding the Linux address and the Windows host address. (learn.microsoft.com⁠)

Mirrored Networking Mode

Mirrored mode reflects the Windows network interfaces into the WSL environment.

Its benefits include:

Better compatibility with several VPN configurations
IPv6 support
Multicast support
Bidirectional Windows-to-Linux communication through 127.0.0.1
More straightforward access from the local network
Less reliance on changing virtual IP addresses

Mirrored mode is available on Windows 11 version 22H2 and later. (learn.microsoft.com⁠)

It can be enabled through:

%UserProfile%\.wslconfig

using:

[wsl2]

networkingMode=mirrored

Configuration changes do not apply to an already running WSL virtual machine until it has been restarted. Microsoft recommends using wsl --shutdown after editing .wslconfig. (learn.microsoft.com⁠)

Establish the Current WSL Configuration

Before troubleshooting the network, open PowerShell and run:

wsl --version

wsl --status

wsl --list --verbose

These commands reveal:

The installed WSL version
Kernel and component versions
The default distribution
Whether each distribution uses WSL1 or WSL2
Whether the distribution is running or stopped

Microsoft recommends using wsl --list --verbose to identify whether a distribution is using WSL1 or WSL2. (learn.microsoft.com⁠)

Update WSL before spending time investigating a problem that may already have been corrected:

wsl --update

Then restart the WSL environment:

wsl --shutdown

Open the Linux distribution again and retest the connection.

wsl --shutdown stops all distributions and the WSL2 lightweight virtual machine. It is the correct restart method after changing global WSL settings. (learn.microsoft.com⁠)

Use a Simple Network Test Sequence

Do not start by deleting resolv.conf or switching off the firewall.

Inside WSL, test each networking layer in order.

Check the Interface and Route

Run:

ip address

ip route

You should normally see an active network interface and a default route.

In NAT mode, the default route also reveals the address WSL normally uses to reach the Windows host:

ip route show | grep -i default

To output only the host address:

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

Microsoft documents this command as the normal way to find the Windows host address from a WSL2 distribution using NAT networking. (learn.microsoft.com⁠)

Test Connectivity Without DNS

Try reaching a known IP address:

ping -c 4 1.1.1

Some networks and services block ping, so a failed ping alone is not conclusive. You can also test an HTTPS connection by IP where appropriate or use routing and connection tools.

The important distinction is:

If IP connectivity works but names do not, investigate DNS.
If neither IPs nor names work, investigate routing, VPNs, the firewall or WSL’s virtual network.

Test Name Resolution

Run:

getent hosts microsoft.com

You can also use:

nslookup microsoft.com

or:

dig microsoft.com

The last two commands may require a DNS utility package inside the distribution.

Then test a complete HTTPS request:

curl -I https://www.microsoft.com

This distinguishes a basic DNS lookup from a wider web, certificate, proxy or firewall problem.

Problem One: WSL Has Internet Access but DNS Does Not Work

A common symptom is that this works:

ping -c 4 1.1.1

but this does not:

getent hosts microsoft.com

Applications may display errors such as:

Temporary failure in name resolution

or:

Could not resolve host

This means the problem is probably DNS rather than the complete network connection.

Check the Current Resolver

Inside Linux, run:

cat /etc/resolv.conf

This file tells Linux which DNS resolver to use.

In a normal WSL-managed configuration, the file may be generated automatically. Avoid replacing it permanently until you have checked whether modern WSL DNS tunnelling can solve the problem.

Use DNS Tunnelling First

On supported Windows 11 systems, WSL DNS tunnelling sends DNS requests through a virtualisation communication channel to Windows rather than relying on an ordinary DNS network packet from the Linux virtual machine.

Microsoft designed this feature to improve compatibility with VPNs, advanced firewall configurations and other complex network environments. DNS tunnelling is enabled by default on current supported Windows 11 22H2-and-later configurations. (learn.microsoft.com⁠)

Create or edit:

%UserProfile%\.wslconfig

and use:

[wsl2]

dnsTunneling=true

A practical modern configuration may be:

[wsl2]

networkingMode=mirrored

dnsTunneling=true

autoProxy=true

firewall=true

In current WSL configuration, firewall=true allows Windows Firewall and Hyper-V-specific rules to filter WSL traffic, while autoProxy=true passes supported Windows HTTP proxy information into WSL. (learn.microsoft.com⁠)

After saving the file, run:

wsl --shutdown

Then reopen the Linux distribution and test:

getent hosts microsoft.com

curl -I https://www.microsoft.com

Do Not Add Public DNS Servers Automatically on Business Devices

You may find advice recommending that you replace the DNS server with:

8.8.8.8

or:

1.1.1.1

That may resolve public websites while breaking access to internal business services.

A company VPN or office network may use private DNS servers to resolve names such as:

fileserver.company.local

database.internal

intranet.companyname

Public DNS providers will not normally know those internal records.

Check the DNS servers supplied by Windows with:

Get-DnsClientServerAddress

or:

ipconfig /all

Company DNS changes should be reviewed by the organisation’s IT provider.

The Manual

resolv.conf

Workaround

Microsoft still documents a manual DNS override as a workaround for particular VPN and WSL networking failures.

This approach disables automatic generation of /etc/resolv.conf and supplies a DNS server manually. (learn.microsoft.com⁠)

First, back up the current file:

sudo cp /etc/resolv.conf /etc/resolv.conf.backup

Edit:

sudo nano /etc/wsl.conf

Add:

[network]

generateResolvConf=false

Stop WSL from PowerShell:

wsl --shutdown

Reopen the distribution, remove the automatically generated resolver file and create your own:

sudo rm -f /etc/resolv.conf

sudo nano /etc/resolv.conf

Add the correct DNS server, for example:

nameserver 10.20.30.40

Use the actual DNS server required by your network or VPN.

This workaround has an important disadvantage: the DNS configuration will not automatically adapt when you move between the office, home, public Wi-Fi and different VPNs.

For that reason, DNS tunnelling and mirrored networking should normally be tested before applying a permanent manual resolver.

DNS Works Until the VPN Connects

VPN software can change:

DNS servers
Routing tables
Interface priorities
Proxy settings
Firewall policies
Access to local subnets
Split-tunnel behaviour

A WSL distribution may therefore work normally before the VPN connects and lose either DNS or complete connectivity afterwards.

Test the sequence deliberately:

Disconnect the VPN.
Run wsl --shutdown.
Reopen WSL.
Test DNS and internet access.
Connect the VPN.
Retest the same commands.

When the problem occurs only while connected to the VPN, investigate the VPN and network policy rather than repeatedly reinstalling Linux.

Microsoft states that mirrored networking and DNS tunnelling are designed to improve compatibility with VPN and complex networking configurations. It also documents particular VPN products and configurations that may still require workarounds. (learn.microsoft.com⁠)

A useful .wslconfig starting point is:

[wsl2]

networkingMode=mirrored

dnsTunneling=true

autoProxy=true

firewall=true

Then run:

wsl --shutdown

If the company manages the VPN, firewall or endpoint-security platform, contact IT before attempting to bypass it.

Proxy Problems Inside WSL

A Windows browser may reach the internet through a corporate proxy while Linux tools attempt to connect directly.

This can create a situation where:

Edge works.
Windows Update works.
apt update fails.
git clone fails.
curl times out.

Current WSL supports autoProxy=true, which reads supported Windows HTTP and HTTPS proxy information and sets corresponding Linux environment variables. (learn.microsoft.com⁠)

Check the proxy variables inside Linux:

env | grep -i proxy

You may see:

HTTP_PROXY=

HTTPS_PROXY=

NO_PROXY=

A Proxy Auto-Configuration file is more complicated. Microsoft notes that WSL exposes a PAC URL through WSL_PAC_URL, but Linux applications do not automatically understand PAC files without additional tooling. (learn.microsoft.com⁠)

Do not copy passwords into plain-text proxy variables or shell-startup files. Ask IT for the supported authentication method.

Problem Two: A WSL Service Will Not Open from Windows

Suppose you start a development server in WSL:

python3 -m http.server 8000

You expect to reach it from Windows at:

http://localhost:8000

WSL2 normally forwards Linux ports to Windows localhost, allowing a service running inside WSL to be opened from a Windows browser. (learn.microsoft.com⁠)

If it does not work, check the service before changing Windows Firewall.

Confirm the Process Is Running

Inside Linux:

ss -lntp

Look for the required port:

:8000

You can also run:

curl http://127.0.0.1:8000

If the request fails inside Linux, Windows is not the problem. The application is not running, has crashed or is using a different port.

Check the Bind Address

An application can listen on:

127.0.0.1

which accepts local connections only, or:

0.0.0.0

which listens on all available IPv4 interfaces.

For local Windows-to-WSL development, normal localhost forwarding is often sufficient. For connections involving remote addresses, port forwarding or other devices, the application may need to bind to 0.0.0.0.

For example:

python3 -m http.server 8000 --bind 0.0.0.0

Microsoft notes that applications accepting remote connections may need to listen on 0.0.0.0 rather than 127.0.0.1. It also warns that doing so makes the service reachable from additional network locations when firewall rules allow it. (learn.microsoft.com⁠)

Test the Port from Windows

In Windows PowerShell:

Test-NetConnection localhost -Port 8000

You can also use:

curl.exe http://localhost:8000

If the Linux-side curl works but the Windows test fails, restart WSL:

wsl --shutdown

Then reopen the distribution and restart the application.

Also check whether another Windows or WSL application already owns the same port:

Get-NetTCPConnection -LocalPort 8000 -ErrorAction SilentlyContinue

Inside Linux:

ss -lntp | grep ':8000'

Connecting from WSL to a Service Running on Windows

In NAT mode, Linux normally reaches Windows by using the Windows host address shown by the default route:

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

Store it in a shell variable:

WINDOWS_HOST=$(ip route show | awk '/default/ {print $3}')

Then connect to a Windows service:

curl "http://$WINDOWS_HOST:5000"

Microsoft documents this host-address method for WSL2’s default NAT architecture. (learn.microsoft.com⁠)

The Windows application must also listen on an address that accepts the connection. If it is bound only to Windows 127.0.0.1, it may reject traffic arriving through the virtual-network address.

In mirrored mode, Linux can normally connect to a Windows IPv4 service through:

127.0.0.1

Microsoft notes that IPv4 localhost is supported bidirectionally in mirrored mode, while IPv6 ::1 does not provide the same WSL host-connection behaviour. (learn.microsoft.com⁠)

Accessing a WSL Service from Another Computer

Being able to open:

http://localhost:8000

on the Windows PC does not automatically mean another laptop can open:

http://WINDOWS-PC:8000

The service must:

Listen on an appropriate interface
Be exposed through the WSL networking architecture
Be allowed by Windows or Hyper-V firewall rules
Be permitted by the network profile
Be reachable through the router or LAN

Do not expose a development server to the local network unless that access is genuinely required.

LAN Access in NAT Mode

Under NAT, WSL has a separate virtual IP.

Find it from Windows:

wsl hostname -I

Use an uppercase I. Microsoft warns that lowercase -i can return a loopback-style diagnostic address rather than the WSL address required for connections. (learn.microsoft.com⁠)

You can use Windows portproxy to forward traffic from a Windows port to the WSL virtual IP.

From an Administrator PowerShell window:

$wslAddress = (wsl hostname -I).Trim().Split(' ')[0]

netsh interface portproxy add v4tov4 `

listenaddress=0.0.0.0 `

listenport=8000 `

connectaddress=$wslAddress `

connectport=8000

Microsoft documents netsh interface portproxy as a method for forwarding a Windows host port to the WSL2 virtual address. (learn.microsoft.com⁠)

Create a matching Windows Firewall rule:

New-NetFirewallRule `

-DisplayName "WSL Web Server 8000" `

-Direction Inbound `

-Protocol TCP `

-LocalPort 8000 `

-Action Allow `

-Profile Private

Restrict the rule further where possible, for example by limiting the approved remote subnet or addresses.

The WSL NAT address can change after WSL or Windows restarts. A static portproxy entry may therefore continue pointing to an old address. Check it with:

netsh interface portproxy show all

Remove an obsolete entry with:

netsh interface portproxy delete v4tov4 `

listenaddress=0.0.0.0 `

listenport=8000

Then recreate it using the current WSL address.

LAN Access in Mirrored Mode

Mirrored networking is intended to make direct local-network access to WSL services more straightforward. However, inbound traffic may still be governed by Hyper-V firewall rules.

The WSL Hyper-V firewall creator ID is:

{40E0AC32-46A5-438A-A0B2-2B479E8F2E90}

Microsoft documents that ID as the WSL VM creator identifier. (learn.microsoft.com⁠)

To inspect the active WSL firewall settings, run Administrator PowerShell:

Get-NetFirewallHyperVVMSetting `

-PolicyStore ActiveStore `

-Name '{40E0AC32-46A5-438A-A0B2-2B479E8F2E90}'

To view existing WSL-specific Hyper-V rules:

Get-NetFirewallHyperVRule `

-VMCreatorId '{40E0AC32-46A5-438A-A0B2-2B479E8F2E90}'

To allow a specific inbound TCP port, use a narrow rule:

New-NetFirewallHyperVRule `

-Name "WSL-Web-8000" `

-DisplayName "WSL Web Server 8000" `

-Direction Inbound `

-VMCreatorId '{40E0AC32-46A5-438A-A0B2-2B479E8F2E90}' `

-Protocol TCP `

-LocalPorts 8000

Microsoft provides the same model for creating WSL-specific inbound Hyper-V firewall rules. (learn.microsoft.com⁠)

You may also see advice to allow all inbound WSL traffic:

Set-NetFirewallHyperVVMSetting `

-Name '{40E0AC32-46A5-438A-A0B2-2B479E8F2E90}' `

-DefaultInboundAction Allow

Although Microsoft documents this command, a specific port rule is normally safer than changing the default action for every inbound WSL connection. (learn.microsoft.com⁠)

Windows Firewall and WSL

On Windows 11 version 22H2 with WSL 2.0.9 or later, Windows Firewall rules apply to WSL traffic by default. Hyper-V firewall rules can provide additional filtering for traffic associated with WSL’s virtualised environment. (learn.microsoft.com⁠)

This means a connection can fail even when:

The Linux application is running.
The correct port is listening.
The Linux distribution can reach the internet.
localhost works in one direction.

Do not solve the problem by switching Windows Firewall off permanently.

Instead, identify:

The direction of the connection
The protocol
The source device
The destination address
The required port
The active Windows network profile
Whether ordinary Windows Firewall or Hyper-V firewall is enforcing the block

Create the smallest necessary rule.

For example, a development service required only on the same PC should not need a rule allowing every device on every network profile.

Enterprise Firewall Policies Can Block WSL Completely

On a managed device, local Windows Firewall rules may be prevented from merging with centrally deployed policy.

Microsoft states that when local rule merging is disabled, WSL networking can be blocked unless the administrator deploys an appropriate rule centrally. (learn.microsoft.com⁠)

Possible signs include:

WSL works on a personal PC but not on a company laptop.
An Administrator PowerShell rule appears to save but has no effect.
The firewall setting says it is managed by the organisation.
WSL loses connectivity after a security-baseline update.
Other Hyper-V virtual machines have similar network restrictions.

Do not attempt to bypass company policy with scripts, alternate adapters or by disabling endpoint security.

Hamilton Group can review the applied Intune, Group Policy, Windows Firewall and endpoint-security settings to determine whether WSL access should be permitted and how to allow it safely.

Port Conflicts in Mirrored Mode

Because mirrored mode makes Windows and WSL networking more closely integrated, Windows and Linux applications may both attempt to use the same port.

Check Windows:

Get-NetTCPConnection -LocalPort 5432 -ErrorAction SilentlyContinue

Check Linux:

ss -lntp | grep ':5432'

Where practical, configure the applications to use different ports.

Current WSL also includes an ignoredPorts experimental setting for mirrored mode. This can let a Linux application bind to a port already used by Windows when the Linux traffic is intended to remain internal to Linux. Microsoft gives port 53 for Docker Desktop as an example. (learn.microsoft.com⁠)

Example:

[wsl2]

networkingMode=mirrored

[experimental]

ignoredPorts=53,3000

Do not use this setting merely to hide an unexplained conflict. Establish which application owns each port and whether external access is required.

.local

Hostnames Do Not Resolve

Names ending in .local commonly use multicast DNS rather than conventional unicast DNS.

Under NAT networking, .local resolution is not supported when DNS tunnelling is enabled. Microsoft recommends either disabling DNS tunnelling for that requirement or using mirrored networking mode. (learn.microsoft.com⁠)

Mirrored mode supports multicast, but Linux may still need an mDNS Name Service Switch plug-in.

On Ubuntu or Debian:

sudo apt update

sudo apt install libnss-mdns

Then test:

getent hosts device-name.local

Do not disable DNS tunnelling for one local device without considering whether doing so will break VPN or corporate DNS compatibility.

Resetting Network Components Safely

When the problem began after a Windows networking change, VPN update or failed WSL update, use the least destructive reset first.

Restart WSL

wsl --shutdown

Restart the Distribution Only

wsl --terminate Ubuntu

Replace Ubuntu with the exact distribution name shown by:

wsl --list --verbose

Update WSL

wsl --update

Restart Windows

A full Windows restart can reload:

Hyper-V networking
VPN filter drivers
Firewall policy
WSL services
Virtual adapters
DNS and proxy configuration

Do not use:

wsl --unregister Ubuntu

as a networking repair.

Unregistering a distribution permanently deletes its installed packages, files and configuration. Microsoft explicitly warns that the associated distribution data will be lost. (learn.microsoft.com⁠)

Avoid These Common WSL Networking Mistakes

Editing

resolv.conf

Before Testing DNS Tunnelling

A static resolver can fix one network while breaking another.

Binding Every Development Server to

0.0.0.0

This can expose services beyond the local machine when firewall rules allow the traffic.

Opening the Port on Every Firewall Profile

A server required at home or in the office may not need to be accessible on a public Wi-Fi network.

Turning the Firewall Off

This hides the cause and weakens the complete Windows device.

Using Public DNS on a Corporate VPN

Public lookups may work while internal company resources stop resolving.

Forgetting That NAT Addresses Change

A portproxy rule may point to yesterday’s WSL address.

Assuming

localhost

Works Identically in Every Mode

Windows-to-Linux and Linux-to-Windows behaviour differs between NAT and mirrored networking.

Reinstalling the Linux Distribution

Most WSL network problems are outside the Linux filesystem. Reinstallation can destroy valuable development environments without correcting the VPN, firewall or Windows networking issue.

Running Unknown Network Reset Scripts

Scripts copied from forums may remove firewall rules, disable IPv6, alter routes or reset adapters used by business applications.

Microsoft warns that disabling IPv6 through certain Windows Registry settings can cause WSL network connectivity to fail. (learn.microsoft.com⁠)

A Practical Troubleshooting Checklist

When WSL2 networking stops working:

Run wsl --version, wsl --status and wsl --list --verbose.
Update WSL with wsl --update.
Restart it with wsl --shutdown.
Test the Linux interface with ip address.
Check the default route with ip route.
Test connectivity to an IP address.
Test DNS with getent hosts.
Inspect /etc/resolv.conf.
Test DNS tunnelling.
Try mirrored networking on a supported Windows 11 computer.
Compare connectivity with the VPN connected and disconnected.
Check Windows proxy settings and Linux proxy variables.
Confirm that the application is actually running.
Inspect listening ports with ss -lntp.
Test the application from inside Linux.
Test localhost from Windows.
Confirm the application’s bind address.
Check for port conflicts in Windows and Linux.
Use portproxy only when NAT-mode LAN forwarding is required.
Check the current WSL IP after every WSL restart.
Review Windows Firewall and Hyper-V firewall rules.
Restrict inbound rules to the necessary port, profile and source.
Contact IT when local rule merging or security policy blocks WSL.
Avoid unregistering the distribution as a network fix.

How Hamilton Group Can Help

WSL2 networking can cross several technical layers at once:

Linux network configuration
Windows virtual networking
DNS and internal name resolution
VPN routes
Proxy services
Windows Firewall
Hyper-V firewall
Endpoint security
Intune and Group Policy
Development servers and containers

A change in any one of those layers can make WSL appear broken.

Hamilton Group’s experienced IT team can help with:

DNS and VPN Troubleshooting

We can determine whether failures originate in WSL, Windows DNS, the VPN client, split tunnelling or the organisation’s internal resolvers.

Port and Development-Server Configuration

We can configure application bind addresses, localhost access, LAN exposure and secure port-forwarding rules.

Windows and Hyper-V Firewall Rules

We can create targeted WSL firewall rules without weakening the rest of the Windows device.

Mirrored Networking Deployment

We can assess whether mirrored mode is appropriate and configure DNS tunnelling, proxy integration and firewall behaviour correctly.

Business WSL Management

For managed computers, we can review Intune, Group Policy, Microsoft Defender and firewall settings so developers can use WSL without bypassing security controls.

Container and Developer-Tool Support

We can investigate port and DNS problems involving:

Docker
Kubernetes
Visual Studio Code
Git
Node.js
Python
PHP
PostgreSQL
MySQL
Development proxies
Local APIs

Hamilton Group aims to make first contact on IT support requests within 15 minutes, helping developers and businesses get timely assistance when a WSL networking issue interrupts important work.

Get WSL2 Networking Working Properly

Most WSL2 network problems can be solved without reinstalling Linux or disabling Windows security.

The key is to determine whether the fault is DNS, routing, port binding, forwarding, proxy configuration or firewall policy—and then change only the layer responsible.

Call 0330 043 0069, book a meeting with one of our experts or visit hgmssp.com for experienced help with WSL2, Windows 11 and business development environments.