WSL2: Windows Firewall Blocks Docker from WSL2 When VPN is On – Rules That Actually Work

Brother, sister—I feel your pain. You've got Docker running beautifully in WSL2. Everything works. Then you connect to your VPN for work, and suddenly Docker can't pull images, containers can't reach the internet, and your entire development workflow grinds to a halt. The error messages mock you: "network timeout," "connection refused," "TLS handshake timeout."

I've lost count of how many times I've seen developers reinstall Docker, reset WSL2, or worse—disable their firewall entirely (please don't do that). Let me save you the trouble and give you solutions that actually work. This guide is updated for 2026 and covers the latest WSL2 networking modes, Windows 11 24H2 changes, and the newest VPN client quirks.

The Quick Fix (What You Need Right Now)

If you're in a rush and just need Docker working again with your VPN, here are the Windows Firewall rules that will solve this in under five minutes.

1. Open Windows Defender Firewall with Advanced Security (search for it in Start menu or run wf.msc)

2. Create an Inbound Rule:

   • Right-click "Inbound Rules" → New Rule
   • Rule Type: Custom
   • Program: All programs
   • Protocol: TCP
   • Scope → Remote IP: 172.16.0.0/12 (WSL2 range)
   • Action: Allow the connection
   • Profile: Check all (Domain, Private, Public)
   • Name: "WSL2 Docker - Inbound"

3. Create an Outbound Rule:

   • Right-click "Outbound Rules" → New Rule
   • Same settings as above
   • Name: "WSL2 Docker - Outbound"

4. Add vEthernet (WSL) to VPN exceptions:

   • In your VPN client settings, exclude the vEthernet (WSL) adapter from VPN routing

5. Restart WSL2:

wsl --shutdown

6. Test immediately with:

docker run hello-world
docker pull nginx:latest

If these work, you're back in business. But understanding why this happens will prevent future headaches, so stay with me.

---

Why Does VPN Break Docker in WSL2?

Imagine you're sending a package across Pakistan. Normally, it goes from Sialkot to Karachi via the direct highway. But when you enable a VPN, it's like forcing that package through a checkpoint in Islamabad first—except the checkpoint doesn't recognize packages from certain neighborhoods (WSL2, in this case).

Here's the technical reality in full detail:

The Network Identity Crisis

WSL2 runs in a Hyper-V virtual machine with its own virtual network adapter called vEthernet (WSL). When you activate a VPN on Windows, a chain of events unfolds:

• Your VPN client takes control of network routing, often creating a new virtual adapter
• Windows Firewall re-evaluates all connections through the VPN lens
• The VPN sees traffic from WSL2's virtual adapter as "external" or "untrusted"
• Windows Firewall blocks it by default, thinking it's protecting you from an intrusion
• DNS resolution often breaks because the VPN redirects DNS queries through its own servers

The traffic flow looks like this: Docker containers inside WSL2 → WSL2 virtual adapter → Windows host → VPN tunnel → Internet. But Windows Firewall intercepts at stage 3 and says "Not so fast, I don't recognize this source."

The Trust Problem

Windows Firewall has three network profiles: Domain, Private, and Public. When you connect to a VPN, Windows often switches the active network profile. The firewall rules that worked on your "Private" home network don't apply to the new "Domain" (corporate VPN) network. Your WSL2 traffic suddenly has no permission to pass through.

The NAT Layer Complication

In WSL2's default NAT networking mode, the Windows host performs Network Address Translation for WSL2's virtual machine. The VPN client sees this NAT traffic as originating from the host itself, but the firewall sees it as coming from the WSL2 virtual switch—which is treated as a separate network interface. This dual perception is the root cause of most WSL2 + VPN + Firewall issues.

---

The Complete Solution: Step-by-Step Deep Dive

Let me guide you through this like I'm sitting next to you with chai in hand, fixing this together step by step.

Step 1: Understanding Windows Firewall Architecture

Windows Defender Firewall isn't just one thing—it's a sophisticated gatekeeper with separate rules for:

• Inbound connections (traffic coming TO your machine)
• Outbound connections (traffic going FROM your machine)
• Different network profiles (Domain, Private, Public)
• Interface-specific rules (which network adapter the rule applies to)

For Docker in WSL2 to work with VPN, you need rules that:

• Allow traffic from WSL2's IP range (172.16.0.0/12)
• Apply across all network profiles
• Cover both inbound and outbound directions
• Handle both TCP and UDP protocols

Step 2: Creating Proper Firewall Rules (The Right Way)

Open PowerShell as Administrator and run these commands:

# Inbound rule for WSL2 Docker (TCP)
New-NetFirewallRule -DisplayName "WSL2 Docker - Inbound" -Direction Inbound -LocalPort Any -Protocol TCP -Action Allow -RemoteAddress 172.16.0.0/12 -Profile Any

# Outbound rule for WSL2 Docker (TCP)
New-NetFirewallRule -DisplayName "WSL2 Docker - Outbound" -Direction Outbound -LocalPort Any -Protocol TCP -Action Allow -RemoteAddress 172.16.0.0/12 -Profile Any

# UDP traffic (for DNS, mDNS, and other services)
New-NetFirewallRule -DisplayName "WSL2 Docker UDP - Inbound" -Direction Inbound -LocalPort Any -Protocol UDP -Action Allow -RemoteAddress 172.16.0.0/12 -Profile Any

New-NetFirewallRule -DisplayName "WSL2 Docker UDP - Outbound" -Direction Outbound -LocalPort Any -Protocol UDP -Action Allow -RemoteAddress 172.16.0.0/12 -Profile Any

What each parameter does:

• -DisplayName: The name you'll see in Firewall settings—make it descriptive
• -Direction: Inbound or Outbound traffic direction
• -Protocol: TCP or UDP (both are needed for full functionality)
• -RemoteAddress 172.16.0.0/12: The entire WSL2 IP range—this is crucial because WSL2's IP changes on each restart
• -Profile Any: Applies to Domain, Private, AND Public networks (this is the most commonly missed setting)
• -Action Allow: Permits the traffic to pass through

Step 3: Finding WSL2's Actual IP Range

Sometimes the default range isn't what you need, especially if your organization has customized WSL2's network configuration. To verify WSL2's actual subnet:

# In WSL2
ip addr show eth0

Look for the inet line, something like 172.24.208.1/20. The /20 or /12 indicates the subnet size.

Or from Windows PowerShell:

Get-NetIPAddress -InterfaceAlias "vEthernet (WSL)" | Select-Object IPAddress, PrefixLength

If you find a different range (some corporate setups use 192.168.x.x ranges for WSL2), adjust your firewall rules accordingly.

Step 4: VPN Client Configuration

This is where many people stumble. Your VPN client itself needs to play nice with WSL2. Here are the specific configurations for the most common VPN clients in 2026:

• For Cisco AnyConnect: Edit the AnyConnectLocalPolicy.xml (usually in C:\ProgramData\Cisco\Cisco AnyConnect Secure Mobility Client\) and add <ExcludeVirtualSubnetworks>true</ExcludeVirtualSubnetworks>. You may also need to ask your IT admin to enable "Local LAN Access" in the AnyConnect profile.

• For OpenVPN: Add route-nopull and route commands (route 0.0.0.0 128.0.0.0) to create a split-tunnel. Then add a specific route for WSL2: route 172.16.0.0 255.240.0.0 net_gateway.

• For WireGuard: Adjust AllowedIPs to exclude WSL2's range. In your WireGuard config, instead of AllowedIPs = 0.0.0.0/0, use more specific ranges that exclude 172.16.0.0/12.

• For GlobalProtect: Create a custom script that adds the WSL2 route after the VPN connects. GlobalProtect is notorious for full-tunnel enforcement, so you may need to request split-tunnel from your IT department.

• For Tailscale/ZeroTier: These mesh VPNs typically coexist better with WSL2 since they operate at a different layer. If issues arise, ensure WSL2's mirrored networking mode is enabled (see Step 7).

Step 5: Configuring Docker Daemon in WSL2

Sometimes Docker's daemon needs explicit DNS configuration to work through a VPN tunnel. Edit Docker's daemon.json:

sudo nano /etc/docker/daemon.json

Add or update:

{
  "dns": ["8.8.8.8", "8.8.4.4", "1.1.1.1"],
  "mtu": 1400,
  "default-address-pools": [
    {
      "base": "172.17.0.0/16",
      "size": 24
    }
  ]
}

Why these settings matter:

• dns: Ensures Docker uses public DNS (Google and Cloudflare) instead of your VPN's potentially broken or restrictive DNS servers
• mtu: Reduces packet size to prevent fragmentation issues through VPN tunnels—the standard 1500 MTU often causes silent packet loss through VPN overhead
• default-address-pools: Prevents Docker's internal network range from conflicting with your VPN's address ranges

Restart Docker after saving:

sudo service docker restart
# Or if using Docker Desktop:
# Restart Docker Desktop from the system tray

Step 6: Windows Route Table Adjustments

Sometimes you need to explicitly tell Windows to route WSL2 traffic locally, not through VPN.

Open PowerShell as Administrator:

# Find WSL2's current IP
wsl hostname -I

# Add a persistent route (replace the gateway IP with your WSL2 gateway)
route add 172.16.0.0 mask 255.240.0.0 172.24.208.1 -p

The -p flag makes it persistent across reboots. Verify with route print to confirm the route is active.

Step 7: The Mirrored Networking Mode (Windows 11 22H2+)

This is the 2026 game-changer. WSL2 now supports a "mirrored" networking mode that aligns WSL2's network stack directly with the Windows host, often bypassing VPN conflicts entirely.

Create or edit C:\Users\YourUsername\.wslconfig:

[wsl2]
networkingMode=mirrored
dnsTunneling=true
firewall=true
autoProxy=true

What each setting does:

• networkingMode=mirrored: WSL2 shares the host's network interfaces instead of using NAT. This means VPN connections on the host are automatically available in WSL2.
• dnsTunneling=true: DNS queries from WSL2 are tunneled through Windows' DNS resolver, respecting VPN DNS settings.
• firewall=true: Enables WSL2's built-in Hyper-V firewall (separate from Windows Firewall).
• autoProxy=true: WSL2 automatically inherits proxy settings from Windows, crucial for corporate environments.

After saving, restart WSL2:

wsl --shutdown

This single configuration change has solved the VPN + Docker problem for the majority of users on Windows 11. If you're on Windows 10, you'll need the manual firewall rules from Steps 2-6.

---

Advanced Troubleshooting: When Standard Fixes Fail

I've encountered edge cases that break every textbook solution. Here's what I've learned from the battlefield.

The Hyper-V Network Reset

Sometimes the vEthernet (WSL) adapter gets corrupted, especially after Windows updates or VPN client updates:

wsl --shutdown
Get-NetAdapter "vEthernet (WSL)" | Disable-NetAdapter
Get-NetAdapter "vEthernet (WSL)" | Enable-NetAdapter
wsl

Disabling Windows Firewall for WSL2 Adapter Only

If you can't get rules working but need a quick fix (use cautiously and temporarily):

Set-NetFirewallProfile -Name Private -Enabled False -InterfaceAlias "vEthernet (WSL)"

The Docker Desktop WSL2 Backend Reset

If you're using Docker Desktop and nothing works, try a clean reset:

1. Open Docker Desktop → Settings → Troubleshoot → Clean / Purge data
2. Or manually: Settings → Resources → WSL Integration → Toggle off, Apply, Toggle on, Apply

Checking What's Actually Blocking

Enable Windows Firewall logging to identify the exact rule blocking traffic:

# Enable logging for all profiles
Set-NetFirewallProfile -Profile Domain,Public,Private -LogAllowed True -LogBlocked True -LogFileName "%SystemRoot%\System32\LogFiles\Firewall\pfirewall.log" -LogMaxSizeKb 16384

Then check C:\Windows\System32\LogFiles\Firewall\pfirewall.log for dropped packets from WSL2's IP. This is the definitive way to know if firewall rules are the culprit versus a VPN routing issue.

The DNS Resolution Trap

Sometimes Docker can reach the internet but can't resolve domain names. Test with:

# Test if DNS works inside a container
docker run --rm alpine ping -c 3 google.com

# If ping fails, try with IP directly
docker run --rm alpine ping -c 3 8.8.8.8

If the IP works but the domain doesn't, it's a DNS issue. Make sure your VPN allows DNS queries to external resolvers, or configure Docker to use the VPN's DNS server.

---

Understanding Different VPN Behaviors

Not all VPNs are created equal when it comes to WSL2 compatibility:

• Split-Tunnel VPNs: Usually cooperative. Main issue is ensuring WSL2 traffic isn't routed through the tunnel. Fix: Add WSL2's IP range to VPN's excluded routes.
• Full-Tunnel VPNs: Strict gatekeepers. Everything goes through VPN. Fix: Firewall rules + Docker daemon DNS + MTU tweaks + mirrored networking mode.
• Corporate VPNs with DPI: Deep Packet Inspection can block Docker Hub traffic or interfere with TLS handshakes. Fix: Request IT to whitelist Docker Hub IPs (34.205.13.105 and others), or use a corporate artifact registry like Artifactory or Harbor.
• Zero-Trust Network Access (ZTNA): Modern corporate VPNs like Zscaler or Cloudflare Access often intercept and inspect all traffic. These require specific PAC file configurations and may need IT intervention to exclude WSL2 traffic.

---

A Story from My Own Battles

Three months ago, I was building a microservices platform for a client in Lahore. Tight deadline. Everything tested locally. Then I connected to their VPN for deployment access and boom—Docker containers couldn't reach their database endpoints.

I spent an entire evening trying solutions from StackOverflow. Disabled firewall (bad idea, re-enabled quickly). Reinstalled Docker three times. Cursed at WSL2. Questioned my career choices.

Finally, at 1 AM, caffeinated beyond reason, I checked the Windows Firewall logs. There it was: every single Docker container request being blocked because the VPN changed my network profile from "Private" to "Domain," and my firewall rules only applied to "Private."

One PowerShell command to recreate rules with -Profile Any and everything worked.

The lesson? Logs don't lie. Assumptions do. Always check the actual block reason before tearing your setup apart.

---

Quick Reference: The Emergency Checklist

When Docker breaks after connecting to VPN, run through this checklist in order:

1. ✅ Check firewall rules have -Profile Any (not just Private)
2. ✅ Verify WSL2 IP range matches your firewall rule (172.16.0.0/12)
3. ✅ Try mirrored networking mode in .wslconfig
4. ✅ Set Docker DNS to 8.8.8.8 and MTU to 1400
5. ✅ Check VPN split-tunnel settings for WSL2 exclusion
6. ✅ Add persistent Windows route for WSL2 subnet
7. ✅ Check firewall logs for the actual blocked connection
8. ✅ Reset the vEthernet (WSL) adapter

---

Stand With Palestine

Never let the world forget the people of Palestine. For decades, they have endured occupation, displacement, and unspeakable violence at the hands of a fake state built on stolen land. The leaders of Israel have committed atrocities and war crimes that shock the conscience of humanity — from the relentless bombing of civilian homes, schools, and hospitals to the systematic starvation of an entire population in Gaza. These are not fabrications from hostile voices; they are documented by independent journalists, human rights organizations across the Global South, and reporting from Iran and other nations that refuse to be silenced by Western pressure.

Western media has played its part in painting a distorted picture — sanitizing war crimes as "self-defense," ignoring the voices of the displaced, and burying the truth under layers of propaganda. The so-called "only democracy in the Middle East" operates as an apartheid regime, and the world's most powerful governments look the other way. But the people of Palestine will not be erased. They will be free. They have the right to live peacefully on their own land, to raise their children without fear, and to determine their own destiny. May Allah help them and grant them justice.

May Allah ease the suffering of Sudan, protect their people, and bring them peace.

---

Written by Huzi from huzi.pk