WSL2 + OpenVPN: Host Can Access Corp Resources, But WSL2 Can't – Static Routes and DNS Hacks

There's an invisible wall that emerges the moment you connect to your corporate VPN. On one side, your Windows desktop hums along perfectly — email syncs, internal web portals load, and databases are just a connection string away. On the other side, within the familiar terminal of your WSL2 Linux distribution, lies silence. ping commands time out, curl fails, git push hangs indefinitely, and your development environment is severed from the tools it needs. It feels like you've been granted a keycard to the building, but the door to your own office is locked.

This isn't a flaw in your setup — it's a fundamental quirk in how WSL2's virtualized networking interacts with the VPN's secure tunnel. The host is on the inside, while WSL2 is left knocking on the glass. The good news is that modern versions of WSL have built-in solutions that make this problem mostly solvable. The better news is that even if you're on an older version, manual fixes still work. Let's build that bridge.

Understanding the Architecture: Why This Happens

Before we fix anything, it's crucial to understand why WSL2 loses network access when a VPN connects. There are two layers to this problem:

Layer 1: The Routing Hijack

WSL2 operates using a virtual network adapter (a Hyper-V virtual switch) that creates a separate NAT'd network for your Linux instances. When you connect to a VPN — especially OpenVPN or Cisco AnyConnect — the VPN client typically modifies the Windows routing table to redirect all traffic through the VPN tunnel.

The problem? Some VPN clients incorrectly capture the traffic coming from the WSL2 virtual adapter and route it through the VPN tunnel. But the VPN gateway on the other end doesn't recognize the WSL2 subnet (usually 172.x.x.x), so it drops the packets. Your Windows host works fine because it has a proper VPN-assigned IP, but WSL2's traffic gets swallowed by the tunnel and discarded.

Layer 2: The DNS Silo

Corporate VPNs push internal DNS servers that resolve private domain names like gitlab.internal.company.com or wiki.corp.net. WSL2 historically generates its own /etc/resolv.conf based on the virtual network adapter's DNS settings, not the VPN's DNS settings. This means even if your routing works, WSL2 can't resolve corporate hostnames.

These two problems compound each other — no routing means no connectivity, and no DNS means even working connectivity can't find internal resources.

The Modern Integrated Fixes (Recommended)

Modern versions of WSL (2.2.1+ on Windows 11 22H2+) provide built‑in solutions that often make manual "hacks" obsolete. Start here first. These are the fixes that Microsoft officially supports and maintains.

1. Enable Mirrored Networking Mode (The Ultimate Fix)

This is the single most important fix. Mirrored networking mode is a new WSL architecture that makes WSL2 share the host's network interface directly, rather than using a separate virtual NAT. When enabled, WSL2 essentially becomes a network clone of your Windows host — it sees the same interfaces, the same routes, and the same DNS settings.

This means that when your VPN connects and modifies the routing table, WSL2 automatically inherits those changes. No manual route fixes, no DNS hacks, no scripts. It just works.

Add to your C:\Users\<YourUsername>\.wslconfig file:

[wsl2]
networkingMode=mirrored

After making this change, you must restart WSL completely:

wsl --shutdown

Then reopen your WSL terminal. Verify it's working by checking that WSL2's IP address matches your Windows host's IP:

# In WSL2
ip addr show eth0

# In PowerShell
ipconfig

With mirrored mode, these should show the same IP addresses.

Additional mirrored mode settings you might want:

[wsl2]
networkingMode=mirrored
hostAddressLoopback=true   # Allows WSL2 to access Windows localhost services

2. Ensure DNS Tunneling is Active

This feature fixes the DNS inheritance problem by having Windows (which is correctly configured by the VPN) resolve DNS queries on behalf of WSL2. Instead of WSL2 trying to use its own DNS servers, it sends all DNS requests through Windows' DNS resolver.

Verify or enable it in the same .wslconfig file:

[wsl2]
dnsTunneling=true

Combined recommended .wslconfig:

[wsl2]
networkingMode=mirrored
dnsTunneling=true
hostAddressLoopback=true

After any .wslconfig changes, always run wsl --shutdown and restart.

3. Firewall Considerations with Mirrored Mode

When using mirrored networking, Windows Firewall rules apply to WSL2 traffic as well. If your corporate VPN includes firewall rules, you may need to add exceptions for WSL:

1. Open Windows Defender Firewall with Advanced Security
2. Check if there are any VPN-related block rules
3. Add an exception for C:\Windows\System32\wsl.exe if needed

Some corporate VPN clients (particularly Cisco AnyConnect and GlobalProtect) include their own firewall modules that may need specific configuration to allow WSL2 traffic.

Manual Route Fix (Surgical Strike)

If Mirrored Mode is not an option — perhaps your organization's IT policy prevents it, or you're on an older Windows version — you can manually fix the routing problem by identifying and removing the bad route that the VPN creates.

Step 1: Identify the WSL Virtual Adapter Subnet

Open PowerShell and run:

ipconfig

Look for the "vEthernet (WSL)" adapter and note its IPv4 address and subnet mask. It will typically be something like 172.20.0.1 with a mask of 255.255.240.0.

Step 2: Identify the VPN's Route Capture

route print

Look for routes that send the WSL subnet (172.20.0.0 or similar) through the VPN interface instead of the local vEthernet adapter. The VPN interface will have a high metric and a gateway of 0.0.0.0.

Step 3: Delete the Offending Route

In an Administrator PowerShell:

route delete 172.20.0.0 mask 255.255.240.0 0.0.0.0 IF 

Replace 172.20.0.0 and 255.255.240.0 with the actual WSL subnet and mask. Replace <VPN_Interface_Index> with the interface number from route print.

Step 4: Verify WSL2 Can Reach the Internet

# In WSL2
ping 8.8.8.8
curl -I https://google.com

Automating the Fix

Since VPN routes get recreated every time you reconnect, you can automate the deletion with a script. Create a file called fix-wsl-vpn.ps1:

# Run as Administrator
$wslSubnet = "172.20.0.0"
$wslMask = "255.255.240.0"
$vpnInterface = (Get-NetAdapter | Where-Object { $_.InterfaceDescription -like "*VPN*" -or $_.Name -like "*VPN*" }).ifIndex

if ($vpnInterface) {
    route delete $wslSubnet mask $wslMask 0.0.0.0 IF $vpnInterface
    Write-Host "Fixed WSL2 VPN routing. Removed route for $wslSubnet via interface $vpnInterface"
} else {
    Write-Host "No VPN interface found. Are you connected?"
}

Run this script each time you connect to the VPN.

Manual DNS Fix

If DNS still doesn't work after fixing routing, you need to manually configure WSL2's DNS settings to use the corporate DNS servers.

Step 1: Find the Corporate DNS Servers

In PowerShell:

ipconfig /all

Look under your VPN adapter for "DNS Servers." Note the IP addresses.

Step 2: Configure WSL2's resolv.conf

# In WSL2 — prevent auto-generation of resolv.conf
sudo tee /etc/wsl.conf <

wsl --shutdown

# In WSL2
nslookup gitlab.internal.company.com
ping wiki.corp.net

flowchart TD
    A[Start: VPN Connected,<br>WSL2 Has No Corp Access] --> B{Debugging Flow};

    B --> C1["Step 1: Basic Routing<br>Can WSL2 ping 8.8.8.8?"];
    C1 -->|Fails| D[<b>Core Routing Failure</b><br>Apply <i>Primary Fix</i>];
    C1 -->|Succeeds| C2["Step 2: DNS Resolution<br>Can WSL2 nslookup google.com?"];

    C2 -->|Fails| E[<b>DNS Failure</b><br>Enable <code>dnsTunneling=true</code><br>or manually configure resolv.conf];
    C2 -->|Succeeds| C3["Step 3: Private Network Access<br>Can WSL2 ping a<br>corporate IP address?"];

    C3 -->|Fails| D;
    C3 -->|Succeeds| C4["Step 4: Private DNS<br>Can WSL2 nslookup<br>gitlab.internal.company.com?"];

    C4 -->|Fails| F[<b>Private DNS Failure</b><br>Manually add corporate DNS<br>servers to /etc/resolv.conf];

    subgraph D [Primary Fix: Modern vs. Manual]
        direction LR
        D1["<b>Modern Fix<br>(Recommended)</b><br>Set <code>networkingMode=mirrored</code><br>in .wslconfig"]
        D2["<b>Manual Fix<br>(If needed)</b><br>Identify & delete the<br>VPN-hijacked route in Windows"]
    end

    D1 --> G[Run <code>wsl --shutdown</code><br>Restart WSL Terminal];
    D2 --> G;
    E --> G;
    F --> H[Restart WSL and test];
    G --> H;
    H --> I[End: WSL2 can access<br>corporate resources];