WSL2 Networking Problems: Fixing DNS, Ports and Firewall Rules
Windows Subsystem for Linux 2 normally makes Linux networking feel almost invisible.
You install Ubuntu, start a development server and open:
http://localhost:3000
from Windows.
Then something changes.
Suddenly:
apt update cannot resolve domains
WSL works until the VPN connects
Linux can reach IP addresses but not websites
a server works inside Linux but not from Windows
localhost fails
another computer cannot connect to the WSL service
Windows Firewall appears to block a port
Docker or PostgreSQL says a port is already in use
These problems often get treated as one generic:
“WSL networking is broken.”
They are not.
The fastest way to fix them is to determine whether the problem is:
routing → DNS → application listening → port exposure → firewall/VPN
before changing anything.
First: Understand the Two WSL2 Networking Models
WSL2 traditionally uses a NAT networking architecture.
In NAT mode:
Linux gets its own virtual IP address
Windows can normally access Linux services through localhost
Linux normally reaches Windows through the virtual gateway address
direct LAN access may need port forwarding
the WSL virtual IP can change after restart
Microsoft still documents NAT as the default architecture.
But on Windows 11 22H2 and later, Microsoft also provides:
mirrored networking
and currently recommends trying it for the latest networking improvements.
Mirrored mode provides useful benefits including:
better VPN compatibility
IPv6
multicast
simpler LAN access
Windows-to-WSL and WSL-to-Windows communication through IPv4 localhost
For many modern Windows 11 development systems, this is now the better starting point.
Check Which WSL You Are Actually Running
Open PowerShell and run:
wsl --version
wsl --status
wsl --list --verbose
Make sure the distribution is actually using:
WSL 2
rather than WSL 1.
Then update WSL:
wsl --update
and restart the WSL virtual environment:
wsl --shutdown
Do this before spending an hour diagnosing a problem already fixed in a newer WSL release.
Use a Simple Network Test Sequence
Inside WSL, start with:
ip address
ip route
You should normally have:
an active interface
an IP address
a default route
Then test name resolution:
getent hosts microsoft.com
and a complete HTTPS connection:
curl -I https://www.microsoft.com
The important distinction is:
Network works, names fail
Investigate:
DNS
Neither networking nor DNS works
Investigate:
route
VPN
firewall
WSL networking
Linux networking works but Windows cannot access your application
Investigate:
application
bind address
port
firewall
That decision tree eliminates a lot of unnecessary repair work.
Problem 1: WSL Has Internet Access but DNS Fails
A classic symptom is:
IP connectivity works
but:
getent hosts microsoft.com
returns nothing or reports:
Temporary failure in name resolution
First inspect:
cat /etc/resolv.conf
But do not immediately replace it with:
nameserver 8.8.8.8
That old workaround can create more problems on modern Windows 11 machines.
Use DNS Tunnelling First
Current WSL supports DNS tunnelling, which sends DNS requests through the Windows host using a virtualisation channel rather than ordinary network packets from the Linux VM.
Microsoft designed it specifically to improve compatibility with:
VPNs
complex networks
firewall configurations.
On supported Windows 11 systems it is enabled by default.
A useful .wslconfig configuration is:
[wsl2]
networkingMode=mirrored
dnsTunneling=true
autoProxy=true
firewall=true
Save this as:
%UserProfile%\.wslconfig
Then run:
wsl --shutdown
and retest.
Do not assume every setting needs to be explicitly added if your current defaults already work; this is primarily useful when troubleshooting or standardising a known configuration.
Be Careful With Public DNS on Business Devices
Changing WSL to:
8.8.8.8
or:
1.1.1.1
may make public websites resolve.
It may simultaneously break:
corporate domains
internal servers
private cloud resources
VPN-only services
A company network may intentionally use internal DNS records such as:
fileserver.company.local
database.internal
Public DNS services do not know those names.
If DNS fails only on a corporate VPN, fix the VPN/DNS integration rather than bypassing the company DNS infrastructure.
Manual resolv.conf Should Be a Last Resort
Microsoft still documents manual DNS configuration for certain edge cases, but it is less attractive now that DNS tunnelling exists.
If you disable automatic resolver generation:
[network]
generateResolvConf=false
and manually create /etc/resolv.conf, that configuration stays fixed.
It may work:
in the office
and then fail:
at home
or:
on another VPN
because the DNS environment changed.
Use static resolver settings only when you understand why dynamic Windows-provided DNS cannot be used.
Problem 2: WSL Breaks When the VPN Connects
This is very common.
A VPN can change:
routes
DNS
proxy settings
firewall rules
network-interface priorities
access to local networks
Test deliberately.
First:
wsl --shutdown
Start WSL with the VPN disconnected.
Test:
getent hosts microsoft.com
curl -I https://www.microsoft.com
Then connect the VPN and repeat.
If the problem appears only after the VPN connects, stop reinstalling Ubuntu.
The evidence points towards:
VPN + Windows + WSL networking interaction.
Microsoft specifically identifies mirrored networking and DNS tunnelling as features intended to improve VPN compatibility.
Corporate Proxies Can Cause Similar Problems
Windows may successfully browse the web because Edge knows about the corporate proxy.
Linux tools such as:
apt
curl
git
may try to connect directly.
Current WSL supports:
autoProxy=true
which can pass supported Windows proxy information into Linux.
Check inside WSL:
env | grep -i proxy
Do not put proxy usernames and passwords into plain-text shell configuration unless that is genuinely the approved authentication method.
Problem 3: A WSL Web Server Does Not Open From Windows
Suppose you start:
python3 -m http.server 8000
but:
http://localhost:8000
does not work from Windows.
Before touching the firewall, check Linux.
Run:
ss -lntp
and:
curl http://127.0.0.1:8000
Linux cannot access it
Windows Firewall is not your problem.
The application is:
not running
listening on another port
failing
Linux can access it
Now test from Windows PowerShell:
Test-NetConnection localhost -Port 8000
or:
curl.exe http://localhost:8000
By default, WSL2 forwards services running inside Linux to Windows localhost in normal supported configurations.
Check the Application's Bind Address
A service listening on:
127.0.0.1
accepts only local connections.
A service listening on:
0.0.0.0
accepts connections on all IPv4 interfaces available to it.
For example:
python3 -m http.server 8000 --bind 0.0.0.0
But do not blindly bind every development server to 0.0.0.0.
That can make the service reachable from other devices if the firewall permits it.
For development needed only on the same PC, localhost is generally safer.
WSL to Windows Works Differently in NAT and Mirrored Mode
In traditional NAT mode, find the Windows host address from Linux with:
ip route show | grep -i default | awk '{ print $3}'
You can then use that address when connecting from WSL to a Windows-hosted service.
With mirrored networking, things are easier.
Linux can normally connect to a Windows IPv4 service using:
127.0.0.1
Microsoft currently documents this bidirectional localhost behaviour for mirrored mode.
That is one of the best reasons to consider mirrored networking for modern development environments.
Problem 4: Another Computer Cannot Access Your WSL Server
Being able to open:
localhost:8000
on your Windows PC does not mean another computer can automatically open the same service.
For LAN access, several things must be true:
application listens on an appropriate interface
WSL networking exposes it
firewall allows it
network permits the connection
In NAT mode, this historically required port forwarding to the WSL virtual address.
In mirrored mode, LAN access is much simpler—but the Hyper-V firewall still matters.
WSL Has Hyper-V Firewall Rules
On current Windows 11 systems with modern WSL versions, Hyper-V firewall integration applies to WSL traffic by default.
For a specific inbound service, Microsoft supports narrowly scoped WSL-specific rules.
For example:
New-NetFirewallHyperVRule `
-Name "WSL-Web-8000" `
-DisplayName "WSL Web Server 8000" `
-Direction Inbound `
-VMCreatorId '{40E0AC32-46A5-438A-A0B2-2B479E8F2E90}' `
-Protocol TCP `
-LocalPorts 8000
Microsoft documents the WSL VM creator ID and this Hyper-V firewall model.
Prefer:
allow the required port
over:
allow everything inbound to WSL.
Do Not Turn Windows Firewall Off
If disabling Windows Firewall makes the application work, you have proved that a firewall rule is involved.
You have not proved that the correct fix is leaving the firewall disabled.
Instead establish:
source
destination
protocol
port
network profile
whether normal Windows Firewall or Hyper-V firewall is blocking it
Then create the smallest rule required.
Managed Business Devices May Block Local Firewall Changes
This is particularly relevant on company laptops.
Intune, Group Policy or endpoint-security policy may prevent locally created rules from being merged with central firewall policy.
That can create symptoms such as:
rule saves but changes nothing
WSL works on a personal PC but not a company PC
firewall says settings are organisation-managed
Do not try to bypass corporate security with scripts or by disabling the security agent.
The correct fix is a centrally approved rule.
Port Conflicts Are More Important in Mirrored Mode
Because Windows and WSL networking are more closely integrated in mirrored mode, both environments may want the same port.
Check Windows:
Get-NetTCPConnection -LocalPort 5432 -ErrorAction SilentlyContinue
and Linux:
ss -lntp | grep ':5432'
If PostgreSQL is already listening on Windows port 5432, another PostgreSQL instance inside WSL may conflict depending on the configuration.
WSL does have an ignoredPorts setting for particular mirrored-mode scenarios, but Microsoft describes it for specific cases such as Linux-internal services.
Do not use it simply to hide an unexplained conflict.
Find out which process should own the port.
Do Not Reinstall WSL as a Networking Fix
Most WSL2 networking problems are not caused by damaged Ubuntu files.
They are caused by:
Windows networking
VPN
firewall
DNS
proxy
WSL virtualisation
Start with:
wsl --shutdown
Then:
wsl --update
and, if necessary, restart Windows.
Do not use:
wsl --unregister Ubuntu
as troubleshooting.
Unregistering a distribution deletes that distribution and its data.
That is an extremely destructive way to discover the network problem was in the Windows firewall all along.
The Fast WSL2 Networking Checklist
When WSL networking stops working:
1. Run wsl --version and wsl --list --verbose.
2. Update WSL.
3. Run wsl --shutdown.
4. Check ip address and ip route.
5. Test name resolution with getent hosts.
6. Test HTTPS using curl.
7. If only DNS fails, investigate DNS tunnelling.
8. Try mirrored networking on supported Windows 11 systems.
9. Compare behaviour with VPN connected and disconnected.
10. Check proxy configuration.
11. If a service is unreachable, confirm it works inside Linux first.
12. Check its bind address and listening port.
13. Test the port from Windows.
14. For LAN access, review Hyper-V/Windows firewall rules.
15. Open only the ports actually required.
16. Do not reinstall the distribution unless you have evidence that the Linux environment itself is damaged.
The key principle is:
Find which network layer failed before changing the layer above it.
How Hamilton Group Can Help
Hamilton Group can help businesses and developers troubleshoot:
WSL2
Windows 11
Linux networking
DNS
VPNs
Windows Firewall
Hyper-V firewall
proxies
development ports
Docker and WSL
corporate endpoint policies
On managed business devices, we can also determine whether WSL networking is being affected by Intune, Group Policy, VPN or endpoint-security configuration rather than asking developers to weaken the machine's security controls.
Visit hgmssp.com or call 0330 043 0069 to discuss Windows, Linux and business IT support.