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 and

Ubuntu 18.04 WSL 1:

$ ifconfig wifi0
wifi0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet  netmask  broadcast
$ ifconfig eth0
eth0: flags=64<RUNNING>  mtu 1500
        inet  netmask
$ ping www.google.com # No VPN
PING forcesafesearch.google.com ( 56(84) bytes of data.
64 bytes from any-in-2678.1e100.net ( icmp_seq=1 ttl=119 time=19.8 ms
64 bytes from any-in-2678.1e100.net ( icmp_seq=2 ttl=119 time=22.0 ms
$ ping www.google.com # VPN active
PING forcesafesearch.google.com ( 56(84) bytes of data.
64 bytes from any-in-2678.1e100.net ( icmp_seq=1 ttl=119 time=19.8 ms
64 bytes from any-in-2678.1e100.net ( 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  netmask  broadcast
$ ping www.google.com # No VPN
PING www.google.com ( 56(84) bytes of data.
64 bytes from lax31s12-in-f4.1e100.net ( icmp_seq=1 ttl=118 time=27.7 ms
64 bytes from lax31s12-in-f4.1e100.net ( 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

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

Ethernet adapter vEthernet (WSL):

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

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

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 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 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:
vim no like enter image description here

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.

  • What are your other network interfaces? With Cisco AnyConnect the VPN has it's own network adaptor is this the same for you? Also what are the contents of resolv.conf and your adaptor DNS settings on Windows? Oct 27, 2020 at 12:26
  • What happens if you try to ping the IP address directly instead of using a FQDN? I can't even ping valid IP addresses on my network with VPN enabled... Apr 26, 2021 at 17:57
  • @MikeLowery - same with me: unable to ping valid IP addresses on my network with VPN enabled.
    – StoneThrow
    Jun 23, 2021 at 23:48
  • @StuartBrock - sorry for not actively responding/trying your solution sooner to when you posted, but I've answered your question, and described my result with your answer, in the "Update" section to my post. Didn't work for me - but thank you: it looked promising, and looked like it ought to have worked.
    – StoneThrow
    Jun 23, 2021 at 23:51
  • had the same issue, did a workaround guide here: stackoverflow.com/a/68573952/11473934
    – Kraego
    Jul 29, 2021 at 12:34

6 Answers 6


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.

   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.

  • Not just WSL2.. this happened with WSL (1) also. Oct 26, 2020 at 18:52
  • @SeñorCMasMas that wasn't the case for me with WSL1. There is an issue with Cisco AnyConnect, if it's configured to, it'll remove access to your Local LAN and only allow VPN connections. You should still be able to connect to servers on the VPN though if the DNS is configured correctly (or fixed in WSL2 as above). Oct 26, 2020 at 20:19
  • 2
    It WAS the case for me with WSL1 ;) We are all going to be resolv.conf gods before this is all over. Oct 26, 2020 at 22:37
  • 1
    Seems that latest ubuntu20/wsl2 ignores generateResolvConf = false parameter and always re-create resolv.conf :( Mar 12, 2021 at 10:28
  • This worked with Ubuntu-20.10 groovy and WSL-2. I did notice the /etc/resolv.conf does keep changing even after revising wsl.conf, but if you manually edit /etc/resolv.conf and change the nameserver lines to the ones that matchthe Ethernet adapter for the VPN from the WIndows shell output "ipconfig /all" then this works again. Whew! Hope a restart does not break the whole thing. Have not been able to run apt-get update for a couple of weeks.
    – pauljohn32
    Mar 29, 2021 at 20:53

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 : and

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

    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

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

  • The first two PowerShell (run as admin) commands both returned no output. ipconfig /all returned some IPV6 addresses. I documented my experience -- which was still unsuccessful -- trying to use those values in the update to my post.
    – StoneThrow
    Jun 24, 2021 at 0:08
  • Hi! This solution works, however the host and the WSL can't access the websites that require the VPN. Jul 19 at 11:42

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
# connect VPN again
  • 2
    I upvoted this because it solved my issue. But it would be nice not to need to do this :-) Oct 28, 2021 at 9:11
  • Might be worth noting this is doing the WSL equivalent of rebooting your machine! Make sure anything open is saved. Otherwise, good thing to try. Nov 20 at 21:25

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

  • This saved my day. What's the magic behind wsl-vpnkit? Apr 1 at 9:46

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

  • While this link may answer the question, it is better to include the essential parts of the answer here and provide the link for reference. Link-only answers can become invalid if the linked page changes. Jul 21, 2021 at 8:17
  • I'm leaving it as a link because this is a temporary mcafee solution, if the link no longer works, then the issue should no longer be a problem.
    – A H
    Jul 21, 2021 at 13:12

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.