Fix WSL2 DNS Resolution Failures Behind Corporate VPNs

You connect to your company's GlobalProtect or Cisco AnyConnect VPN, and suddenly your WSL2 Ubuntu distribution loses all internet access. apt update hangs, git clone times out, and internal registry lookups fail completely because the Windows host VPN routing stomps on the virtualized WSL2 network adapter.

Quick TL;DR Fix

If you need a working connection immediately, run this command in your PowerShell terminal as Administrator to extract your corporate DNS servers and push them directly into WSL2:

Set-DnsClientServerAddress -InterfaceAlias "vEthernet (WSL)" -ServerAddresses ("10.0.0.1", "8.8.8.8")

(Replace 10.0.0.1 with your primary corporate DNS server and keep a public fallback like 8.8.8.8 if split-tunneling allows it.)

While this works for the current session, it reverts the moment you restart your machine or cycle your VPN connection. Let's fix this permanently by stopping WSL from overwriting your nameserver configuration and setting up a reliable static resolver.

Step 1: Disable WSL's Automatic resolv.conf Generation

By default, WSL2 generates the /etc/resolv.conf file inside your Linux distribution on every boot, pointing it at the internal Hyper-V virtual switch IP. When your corporate VPN kicks in, this IP fails to route internal DNS queries through the tunnel.

Open your WSL2 terminal and open the wsl.conf configuration file using nano:

sudo nano /etc/wsl.conf

Add the following lines to the file. This tells the WSL engine to stop touching your DNS settings:

[network]
generateResolvConf = false

Save the file by pressing Ctrl+O, hit Enter to confirm, and exit with Ctrl+X.

Next, you need to delete the existing symlinked configuration file so you can replace it with a static one:

sudo rm /etc/resolv.conf

Step 2: Configure Static Nameservers

Now create a new, static resolv.conf file that will reliably handle both internal corporate domains and public internet traffic.

Open the new file in your editor:

sudo nano /etc/resolv.conf

Paste the following configuration, substituting your company's actual internal DNS server IPs for the example addresses:

nameserver 10.100.0.2
nameserver 10.100.0.3
nameserver 8.8.8.8
nameserver 1.1.1.1

Save and close the file. To lock down the configuration so nothing accidentally overwrites it, make it immutable:

sudo chattr +i /etc/resolv.conf

Note: If you ever change your corporate network infrastructure and need to update these IP addresses, you will need to remove the immutable flag first by running sudo chattr -i /etc/resolv.conf.

Step 3: Configure Windows Hyper-V Firewall and Mirrored Mode (Alternative)

If disabling generateResolvConf doesn't fully resolve your routing issues—often the case with aggressive corporate VPN clients that block local subnet bridging—you can leverage Windows 11's newer networking mode.

Windows 11 (specifically build 22H2 and newer) supports a mirrored networking mode that shares the network stack of the host directly with WSL2. This completely bypasses the virtual switch translation layer that corporate VPNs hate.

Open your Windows PowerShell (Administrator) and edit your global WSL configuration file located at your Windows user profile root. If it doesn't exist, create it:

notepad "$env:USERPROFILE\.wslconfig"

Add the following configuration block:

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

Save the file, close Notepad, and restart your WSL instances completely from your PowerShell prompt:

wsl --shutdown

Open a new WSL terminal. Test your DNS resolution immediately:

nslookup internal.corp-domain.com
nslookup github.com

Expected output for a successful lookup behind a corporate VPN:

Server:         10.100.0.2
Address:        10.100.0.2#53

Name:   internal.corp-domain.com
Address: 10.200.45.12

If This Doesn't Work: 3 Common Failure Points

Even after locking down resolv.conf and enabling mirrored networking, strict corporate security software can still block traffic. Check these three common culprits if you are still timing out:

1. The VPN Client is Flushing Your Routes

Some enterprise VPN clients (such as older versions of Palo Alto GlobalProtect or Check Point) aggressively rewrite the Windows routing table upon connection, dropping local Hyper-V interface routes.

To check if your routes are disappearing, run this in PowerShell while connected to the VPN:

Get-NetRoute -InterfaceAlias "*WSL*"

If the route table is empty or missing your WSL gateway, you may need to add a persistent route or adjust your VPN client's "Split Tunnel" or "Local LAN Access" policy via your IT department.

2. Immutable File Permission Errors

If you attempt to update packages and receive an error stating /etc/resolv.conf: Permission denied, you likely forgot to remove the immutable attribute before editing the file, or another background service is trying to write to it. Verify the file attributes:

lsattr /etc/resolv.conf

If you see a ----i--------, remove it temporarily:

sudo chattr -i /etc/resolv.conf

3. DNS Cache Pollution on the Windows Host

Sometimes your Windows host holds onto stale DNS entries before the VPN connects. Flush the host DNS cache from an Administrator PowerShell prompt, then restart WSL:

Clear-DnsClientCache
wsl --shutdown

Preventing Future Regressions

Corporate VPN updates and Windows 11 cumulative patches frequently alter network adapter priorities. To prevent these DNS resolution failures from creeping back into your workflow during updates, keep a shell script in your home directory (~/fix-dns.sh) with the following contents:

#!/bin/bash
sudo chattr -i /etc/resolv.conf
sudo bash -c 'cat > /etc/resolv.conf <<EOF
nameserver 10.100.0.2
nameserver 8.8.8.8
EOF'
sudo chattr +i /etc/resolv.conf
echo "WSL2 DNS fixed for corporate VPN."

Make the script executable with chmod +x ~/fix-dns.sh, and you can instantly restore your development environment with a single command whenever your VPN drops your packets.