WSL2 has NO connectivity when Windows is connected to VPN

Question

Networking on my Windows PC has the following configuration:

Ethernet adapter Ethernet 2:

   Description . . . . . . . . . . . : Cisco AnyConnect Secure Mobility Client Virtual Miniport Adapter for Windows x64
   ...
   IPv4 Address. . . . . . . . . . . : 172.27.31.15(Preferred)
   Default Gateway . . . . . . . . . : ::
                                   172.27.0.1
   ...

Ethernet adapter vEthernet (Default Switch):
   ...
   IPv4 Address. . . . . . . . . . . : 172.22.128.1(Preferred)
   ...

Ethernet adapter vEthernet (WSL):
   ...
   IPv4 Address. . . . . . . . . . . : 172.28.48.1(Preferred)
   ...

Wireless LAN adapter Wi-Fi:
   ...
   IPv4 Address. . . . . . . . . . . : 192.168.2.13(Preferred)
   Default Gateway . . . . . . . . . : 192.168.2.1
   ...

My WSL:

# ip addr|grep 'inet '
inet 127.0.0.1/8 scope host lo
inet 172.28.50.28/20 brd 172.28.63.255 scope global eth0
# ip route
default via 172.28.48.1 dev eth0
172.28.48.0/20 dev eth0 proto kernel scope link src 172.28.50.28

When the Windows PC is connected to VPN, pinging the IPs from within WSL2 give the following result:

172.27.0.1 (Unreachable)
192.168.2.1  (Unreachable)
172.28.48.1  (Unreachable)
172.22.128.1  (Unreachable)

When the Windows PC is disconnected from VPN, pinging the IPs from within WSL2 give the following result:

192.168.2.1  (YES)
172.28.48.1  (YES)
172.22.128.1  (Unreachable)

basically, when the Windows PC is connected to VPN, WSL2 is totally isolated from any IPs other than itself. How to fix this?

Update:

the routing situation shown by "rounte print" on Windows PC is as follows (I ommitted majority of lines with Gateway=192.168.2.1, Interface=192.168.2.13):

IPv4 Route Table
=================
Active Routes:
Network Destination        Netmask          Gateway       Interface  Metric
          0.0.0.0          0.0.0.0      192.168.2.1     192.168.2.13     35
          0.0.0.0          0.0.0.0       172.27.0.1     172.27.31.15      2
        127.0.0.0        255.0.0.0         On-link         127.0.0.1    331
        127.0.0.1  255.255.255.255         On-link         127.0.0.1    331
  127.255.255.255  255.255.255.255         On-link         127.0.0.1    331
     172.22.128.0    255.255.240.0       172.27.0.1     172.27.31.15      2
     172.22.128.0    255.255.240.0         On-link      172.22.128.1    271
     172.22.128.1  255.255.255.255         On-link      172.22.128.1    271
   172.22.143.255  255.255.255.255         On-link      172.22.128.1    271
       172.27.0.0    255.255.192.0         On-link      172.27.31.15    257
     172.27.31.15  255.255.255.255         On-link      172.27.31.15    257
    172.27.63.255  255.255.255.255         On-link      172.27.31.15    257
      172.28.48.0    255.255.240.0         On-link       172.28.48.1    271
      172.28.48.0    255.255.240.0       172.27.0.1     172.27.31.15      2
      172.28.48.1  255.255.255.255         On-link       172.28.48.1    271
    172.28.63.255  255.255.255.255         On-link       172.28.48.1    271
    192.168.2.0    255.255.255.0       172.27.0.1     172.27.31.15      2
        224.0.0.0        240.0.0.0         On-link         127.0.0.1    331
        224.0.0.0        240.0.0.0         On-link      192.168.2.13    291
        224.0.0.0        240.0.0.0         On-link       172.28.48.1    271
        224.0.0.0        240.0.0.0         On-link      172.27.31.15    257
        224.0.0.0        240.0.0.0         On-link      172.22.128.1    271
  255.255.255.255  255.255.255.255         On-link         127.0.0.1    331
  255.255.255.255  255.255.255.255         On-link      192.168.2.13    291
  255.255.255.255  255.255.255.255         On-link       172.28.48.1    271
  255.255.255.255  255.255.255.255         On-link      172.27.31.15    257
  255.255.255.255  255.255.255.255         On-link      172.22.128.1    271

Answer 1

https://github.com/sakai135/wsl-vpnkit

This solved the issue for me from corporate system with work VPN.

Logging here in hopes of fixing search engine indexes (I kept hitting this thread every time I tried to search for a fix this specific issue)

Answer 2

In my case we are using Palo Alto VPN; however you could easily modify this to find any other VPN interface. This finds the problem route and removes it, traffic now flows from the WSL2 instance over the VPN. Run it manually from an elevated PS or trigger it from a scheduled task when the VPN connects. This solution is based on the excellent write-up https://janovesk.com/wsl/2022/01/21/wsl2-and-vpn-routing.html

clear
#find the VPN interface
$If_PANGP=Get-NetAdapter | Where-Object -Property InterfaceDescription -like PANGP*

#get the VPN interface index
$IDX_PANGP=$If_PANGP.ifIndex
write-host "PANGP interface index: $IDX_PANGP"

#get the interface used by WSL
$If_WSL=Get-NetAdapter | Where-Object -Property Name -like *WSL*  #there can be multiple Hyper-V interfaces - this find only the WSL one

#get the interface index for subsequent commands
$IDX_WSL=$If_WSL.ifIndex
write-host "WSL interface index: $IDX_WSL`n"

#get the subnet used by WSL
#The unique property for the subnet route is that it has a 20 bit subnet mask
#I don't know if this varies on other systems but this seems to work for mine
$RT_WSL=Get-NetRoute | Where-Object -Property ifIndex -eq $IDX_WSL | Where-Object -Property DestinationPrefix -like "*/20"

#Split the DestinationPrefix into it's components
$DP_WSL=$RT_WSL.DestinationPrefix.ToString() -split "/"  
$SN_WSL=$DP_WSL[0]   #WSL Subnet
$SM_WSL=$DP_WSL[1]   #WSL Mask

#find the WSL-subnet route bound to the PANGP interface
$RT_WSL_IFPAN=Get-NetRoute | Where-Object -Property ifIndex -eq $IDX_PANGP | Where-Object -Property DestinationPrefix -like "$SN_WSL*"

write-host "This is the route I will remove"
$RT_WSL_IFPAN


#this works but I have to call it several times at an elevated command prompt, it confirmed deletion 3 times before it was no longer found
write-host "`ncmd.exe equivalent:"
write-host "route delete $SN_WSL MASK $SM_WSL IF $IDX_PANGP"   #The mask here needs to be converted to octet form, but this output is just for posterity anyway


#Nuke it from orbit
#do until command fails - takes several tries, I don't know why
$A=1
while ($true)
{
    Write-Host "trying to remove route attempt $A"
    Remove-NetRoute -InputObject $RT_WSL_IFPAN -Confirm:$false -ErrorAction SilentlyContinue
    if (!$?)
    {
        Write-Host "route was removed on attempt $A"
        break
    }
    sleep 1
    $A+=1
}

#To restore the route - disable/enable the WSL ethernet adapter in network connections

Answer 3

This is a known limitation with corporate VPN's. WSL2 operates on a separate virtual network behind a Hyper-V switch. I would assume that you can't access any other devices on your local network either when connected to the VPN. The WSL2 network is a "separate device"/network from the perspective of Windows.

Two options:

• First, if your use-case supports it, use a WSL1 instance when you are connected to the VPN. Because it shares the network interface with Windows, it will still have access to the network (and resources on the VPN) when the VPN is attached in Windows.

• Second, if you are on Windows 11 (unlikely for a corporate device, I know), then there's a possible workaround. There are improvements in the WSL2 networking area that are in preview right now. Windows 11 users can install the WSL Preview available in the Microsoft Store and follow the instructions here to turn on bridged networking.

  When in this mode, my understanding (although I can't test it) is that the bridged device may be able to connect to the network while the VPN is enabled. If you need to connect to the VPN from within WSL2, you'll need to use a Linux client, though.

Answer 4

Thanks for the routing table. I think it lines up with John's assumption that Split Tunnel is not enabled on your VPN provider. That is, the VPN client, when establishing a connection to the VPN server, is configured to update the operating system's routing table and move all traffic through the VPN.

You mention the following hosts being unreachable:

1. 172.27.0.1 (Unreachable)
2. 192.168.2.1 (Unreachable)
3. 172.28.48.1 (Unreachable)
4. 172.22.128.1 (Unreachable)

172.27.0.1/18

This is IP is given as the default gateway for your Cisco AnyConnect interface:

Ethernet adapter Ethernet 2:

   Description . . . . . . . . . . . : Cisco AnyConnect Secure Mobility Client Virtual Miniport Adapter for Windows x64
   ...
   IPv4 Address. . . . . . . . . . . : 172.27.31.15(Preferred)
   Default Gateway . . . . . . . . . : ::
                                   172.27.0.1

That you cannot ping this particular IP address is likely just a firewall rule on the server side that prevents ICMP (ping) traffic. If it were truly unreachable then you would not have any connectivity at all according to state of the route table.

192.168.2.1/24

This is, I'm assuming, the default gateway for a wireless access point that your device is connecting to:

Wireless LAN adapter Wi-Fi:
   ...
   IPv4 Address. . . . . . . . . . . : 192.168.2.13(Preferred)
   Default Gateway . . . . . . . . . : 192.168.2.1
   ...

The relevant pieces from the routing table are:

IPv4 Route Table
=================
Active Routes:
Network Destination        Netmask          Gateway       Interface  Metric
    192.168.2.0    255.255.255.0       172.27.0.1     172.27.31.15      2

Here, traffic destined for the 192.168.2.0/24 subnet has only one option, to go through the 127.27.0.1 gateway. There is no other route saying to use the 192.168.2.1 Gateway on the 192.168.2.13 Interface.

As such, traffic destined for the 192.168.2.0/24 subnet hits the VPN gateway, and there is nothing on the other side. Hence, destination unreachable.

172.28.48.1/20

The relevant pieces from the routing table are:

IPv4 Route Table
=================
Active Routes:
Network Destination        Netmask          Gateway       Interface  Metric
      172.28.48.0    255.255.240.0         On-link       172.28.48.1    271
      172.28.48.0    255.255.240.0       172.27.0.1     172.27.31.15      2

Here, you have two different routes for the same network, 172.28.48.0/20. The On-link one is what you want the traffic to go through. However, its Metric is 271, which is higher than the Metric for the VPN gateway, which is 2. The lower metric wins, and so traffic to the 172.28.48.0/20 network goes to the VPN gateway, and there is nothing on the other side. Hence, destination unreachable.

172.22.128.1/20

The relevant pieces from the routing table are:

IPv4 Route Table
=================
Active Routes:
Network Destination        Netmask          Gateway       Interface  Metric
     172.22.128.0    255.255.240.0       172.27.0.1     172.27.31.15      2
     172.22.128.0    255.255.240.0         On-link      172.22.128.1    271

(This is a similar situation to the 172.28.48.0/20 network.)

For the 172.22.128.0/20 network, two routes are specified. You want the On-link one, but the metric for the VPN gateway is lower. So, traffic for 172.22.128.0/20 goes to the VPN gateway, and there is nothing on the other side. Hence, destination unreachable.

---

In order for you to reach the desired networks from your host machine, you will need to remove the routes that the Cisco AnyConnect VPN client has installed in the routing table. I do not know whether or not the VPN client will detect this and update them again though; typically, when administrators configure their VPNs this way, it is intentional, and manually trying to work around the VPN client configuration without permission might be viewed negatively.

I also don't think this is a WSL2 vs WSL1 issue, or a Windows 10 vs 11 issue, or a virtual bridge vs virtual NAT issue (but I readily admit I could be mistaken). So long as the routing table on the host is configured this way, any traffic from the host machine is going to go through the VPN rather than to the relevant interfaces on the host machine that would push the traffic to the local VM network.

Your VMs themselves should still have network connectivity; they'll just go through the VPN. If you're able to log into the VMs "locally" via a console log-in, you could confirm that.

Edit:

A note on your comment about the route table:

the table shows majority of routes go through my home router 192.168.2.1 and other routes (to office) go through officer router: 172.27.0.1

I don't think that's what the route table shows. Specifically, for non-specific networks --0.0.0.0-- there are two routes specified:

IPv4 Route Table
=================
Active Routes:
Network Destination        Netmask          Gateway       Interface  Metric
          0.0.0.0          0.0.0.0      192.168.2.1     192.168.2.13     35
          0.0.0.0          0.0.0.0       172.27.0.1     172.27.31.15      2

Here, again, the VPN gateway has the lower Metric and so all traffic that matches 0.0.0.0 rather than a more specific one will go to the VPN (and we have already demonstrated above that the more specific routes are also configured to go through the VPN).

Answer 5

Open file explorer and folder

C:\Users<your_username>\

you can just paste %USERPROFILE% in path line

Create new file

.wslconfig

with content:

[experimental]
dnsTunneling=true

Open PowerShell or CMD window and Reboot WSL :

wsl --shutdown