Why is there no network connectivity in Ubuntu using WSL 2 behind VPN?

Question

Premise: I'm trying to run Ubuntu as a Windows 10 app using WSL.

TL;DR problem: When Ubuntu uses WSL 2, network connectivity "disappears" when using company VPN.

Trying to get Ubuntu 18.04 (downloaded from the Microsoft Store) running on a Windows 10 work laptop (IT doesn't support Linux - I'm on my own) using WSL 2. When the corporate VPN is turned off, I seem to have network connectivity; when I'm connected to the VPN, suddenly I can't connect (ping, etc.) to anything.

There's probably a cascade of problems to deal with, so I'll try to limit the scope of this question: why does Ubuntu report a wifi0 NIC when it's using WSL 1 but not when using WSL 2 (and does that matter)?

Why can't I connect to anywhere only when using WSL 2 and VPN is enabled? Is the fix just a matter of adding the right nameserver to /etc/resolv.conf? If so, what's a valid value? I've already tried 8.8.8.8 and 8.8.4.4.

---

Ubuntu 18.04 WSL 1:

$ ifconfig wifi0
wifi0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 10.0.0.96  netmask 255.255.255.0  broadcast 10.0.0.255
$ ifconfig eth0
eth0: flags=64<RUNNING>  mtu 1500
        inet 169.254.91.163  netmask 255.255.0.0

$ ping www.google.com # No VPN
PING forcesafesearch.google.com (216.239.38.120) 56(84) bytes of data.
64 bytes from any-in-2678.1e100.net (216.239.38.120): icmp_seq=1 ttl=119 time=19.8 ms
64 bytes from any-in-2678.1e100.net (216.239.38.120): icmp_seq=2 ttl=119 time=22.0 ms

$ ping www.google.com # VPN active
PING forcesafesearch.google.com (216.239.38.120) 56(84) bytes of data.
64 bytes from any-in-2678.1e100.net (216.239.38.120): icmp_seq=1 ttl=119 time=19.8 ms
64 bytes from any-in-2678.1e100.net (216.239.38.120): icmp_seq=2 ttl=119 time=22.0 ms

---

Ubuntu 18.04 WSL 2:

$ ifconfig wifi0
wifi0: error fetching interface information: Device not found
$ ifconfig eth0
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.34.56  netmask 255.255.255.240  broadcast 192.168.34.63

$ ping www.google.com # No VPN
PING www.google.com (142.250.68.100) 56(84) bytes of data.
64 bytes from lax31s12-in-f4.1e100.net (142.250.68.100): icmp_seq=1 ttl=118 time=27.7 ms
64 bytes from lax31s12-in-f4.1e100.net (142.250.68.100): icmp_seq=2 ttl=118 time=19.6 ms

$ ping www.google.com # VPN active -- Both the generated and hand-edited /etc/resolv.conf failed
^C

---

Update:
I tried @StuartBrock's promising answer, but unfortunately it didn't work.

In Windows, ipconfig /all yielded the following, that I think are the DNS values for the VPN adapter:

Ethernet adapter vEthernet (Default Switch):

   Connection-specific DNS Suffix  . :
   Description . . . . . . . . . . . : Hyper-V Virtual Ethernet Adapter
...
   DNS Servers . . . . . . . . . . . : fec0:0:0:ffff::1%1
                                       fec0:0:0:ffff::2%1
                                       fec0:0:0:ffff::3%1

Ethernet adapter vEthernet (WSL):

   Connection-specific DNS Suffix  . :
   Description . . . . . . . . . . . : Hyper-V Virtual Ethernet Adapter #2
...
   DNS Servers . . . . . . . . . . . : fec0:0:0:ffff::1%1
                                       fec0:0:0:ffff::2%1
                                       fec0:0:0:ffff::3%1

The following lines already exist in /etc/wsl.conf:

[network]
generateResolvConf = false

...and I've verified that as a result, edited content of /etc/resolve.conf persists across "reboots" (stop/restart of the Ubuntu 18.04 LTS Windows app).

I'm not sure what the fec prefix and %1 suffix are, but the values otherwise look like a IPV6 address. So I went ahead and updated my /etc/resolve.conf accordingly:

user@LOC-USER-LT:~$ cat /etc/resolv.conf
nameserver 10.0.0.1
nameserver 10.100.98.237
nameserver 10.100.98.21
nameserver fec0:0:0:ffff::1%1
nameserver fec0:0:0:ffff::2%1
nameserver fec0:0:0:ffff::3%1

...followed by the same test, i.e. ping www.google.com, and the behavior is unchanged from that originally-described.

The problem is still unchanged after a stop/restart of the Ubuntu 18.04 LTS Windows app.

The problem is also unchanged if I update the /etc/resolve.conf content to remove the fec prefix and %1 suffix, both before and after restarting the Ubuntu 18.04 LTS Windows app:

nameserver 10.0.0.1
nameserver 10.100.98.237
nameserver 10.100.98.21
nameserver 0:0:0:ffff::1
nameserver 0:0:0:ffff::2
nameserver 0:0:0:ffff::3

I'm not sure how intelligent vim is about the content of /etc/resolve.conf, but I found it interesting that it chose to red-highlight these new IPV6 values, as though it thought they were invalid:

---

Update 2:
I wondered whether the order of /etc/resolve.conf content mattered, so I tried placing the new IPV6 values at the top of the file. Interestingly, this did change behavior: instead of hanging for several seconds then failing with stderr ping: www.google.com: Temporary failure in name resolution, instead it immediately returns with the same stderr message.

Answer 1

I had similar issues with Cisco AnyConnect. I think WSL1 does it's networking through Windows (via Hyper-V?) and WSL2 is effectively a Linux Kernel running virtualised alongside Windows.

My fix was

1. In Windows ipconfig /all get the DNS values for the VPN adaptor
2. In WSL sudo vi /etc/resolv.conf and add the DNS values as lines nameserver <DNS IP>

You can optionally add the block below to /etc/wsl.conf to stop resolv.conf being "refreshed" (wiped) on restart. But you need to remember it's not being automatically updated in future.

   [network]  
   generateResolvConf = false   

As for why you had no network connection when VPN was connected, I think it was trying to connect to the "off VPN" DNS which your VPN was blocking. There seem to be some GitHub issues around WSL2 and VPNs so I'd expect a fix to come out at some point.

Answer 2

I used ubuntu_20 and WSL2 and I did the following steps to fix the issue:

• Run Powershell as administrator

  Get-NetAdapter | Where-Object {$_.InterfaceDescription -Match "Cisco AnyConnect"} | Set-NetIPInterface -InterfaceMetric 4000  
  Get-NetIPInterface -InterfaceAlias "vEthernet (WSL)" | Set-NetIPInterface -InterfaceMetric 1
  

• Find nameservers (command at windows powershell)

  ipconfig /all
  

  in my case I found values : 10.150.54.19 and 10.158.55.13

• Make permanent changes to dns by edditing /etc/wsl.conf (inside WSL instance)

  [network]
  generateResolvConf = false
  

• shutdown WSL2 (command at PowerShell)

  wsl --shutdown
  

  afterwards open new terminal window with wsl

• delete and create new /etc/resolv.conf file

  sudo rm /etc/resolv.conf
  sudo nano /etc/resolv.conf
  

• add the following at the resolv.conf

  nameserver 8.8.8.8
  nameserver 10.150.54.19
  nameserver 10.158.55.13 
  

• the first step (two powershell commands) need to be executed every time we are connected to the vpn

Answer 3

There's an easy workaround that worked for me on Windows 10 with WSL2+Ubuntu 20.04 and Cisco AnyConnect.:

Launch WSL before connecting to the VPN:

wsl --shutdown
# disconnect VPN
wsl
# connect VPN again

Answer 4

I did the following to provide network connectivity to the WSL 2 VM while connected to VPNs on the Windows host.

1. Download the distro wsl-vpnkit.tar.gz and copy it to C:\Users\<username>

2. Open a PowerShell in C:\Users\<username> and run these commands

wsl.exe --import wsl-vpnkit $env:USERPROFILE\wsl-vpnkit wsl-vpnkit.tar.gz

wsl.exe -d wsl-vpnkit

wsl.exe -d wsl-vpnkit service wsl-vpnkit start

3. To prevent having to re-run any commands, open a WSL 2 session window and run

sudo nano ~/.bashrc

Append this command below and save

wsl.exe -d wsl-vpnkit service wsl-vpnkit start >/dev/null 2>&1

.bashrc runs on every interactive shell launch.

4. Close and re-open a new WSL 2 session. To confirm network access, run a ping command

ping google.com

Answer 5

In case you're using Mcafee, see this article - https://kc.mcafee.com/corporate/index?page=content&id=KB94601

Answer 6

I had setup WSL2(Ubuntu) in Windows10. When connecting to GlobalProtect VPN I was able to get internet both in Windows10 and WSL2 but certain VPN sites were not accessible (company kubernetes api server hosted thru AWS load balancer). On internet I found this page https://janovesk.com/wsl/2022/01/21/wsl2-and-vpn-routing.html and got my solution by adding routes for sites that were not reachable over VPN from WSL2. I created a powershell script to be executed every time I connect to VPN. This can be automated by creating event triggered task as mentioned in https://github.com/microsoft/WSL/issues/5068#issuecomment-1263904885

If one wants then one can execute this powershell from inside WSL2(Ubuntu) bash also powershell.exe Start-Process -Verb runas -FilePath powershell.exe "C:\Users\Sushil.Sah\Desktop\route_edit.ps1"

My powershell script:

#this script needs to be run as administrator to be able to add routes

$adapter = Get-NetAdapter | Where-Object {$_.InterfaceDescription -Match "PANGP"}
Write-Output "VPN interface index = $($adapter.ifIndex) "

$adapter_ip = Get-NetIPAddress -InterfaceIndex $adapter.ifIndex
Write-Output "VPN IP = $($adapter_ip.IPAddress) "

function add_routes_after_resolving
{
  param(
    [string]$website_name = $(Throw 'website name is required')
  )

  $IPs = Resolve-DnsName $website_name
  Write-Output "DNS Resolved IPs for $($website_name) are below "

  ForEach($IP in $IPs.IPAddress)
  {
    Write-Output "$($IP)"
    route ADD $IP MASK 255.255.255.255 $adapter_ip.IPAddress METRIC 1 IF $adapter.ifIndex
  }
}

Write-Output "Routes before adding"
route print

add_routes_after_resolving google.com #replace with whatever website_name we want to add route for

#if following routes are not added by VPN client then to add it manually
#one can change IP and subnet mask according to their company IPs that needs to be connected over VPN
route ADD 10.0.0.0 MASK 255.0.0.0 $adapter_ip.IPAddress METRIC 1 IF $adapter.ifIndex
route ADD 172.16.0.0 MASK 255.240.0.0 $adapter_ip.IPAddress METRIC 1 IF $adapter.ifIndex
route ADD 192.168.0.0 MASK 255.255.255.0 $adapter_ip.IPAddress METRIC 1 IF $adapter.ifIndex

Write-Output "Routes after adding"
route print

Answer 7

An easier and faster solution is to turn off windows firewall. I know its an extremely bad idea but at this point, this is the solution that works for me.