[WSL2] Checkpoint VPN breaks network connectivity

[rlipscombe]

(I've searched the open issues, and none that I could find were exactly the same)

Windows 10.0.18922.1000

I just installed Windows Insiders, and updated my Ubuntu distro to WSL2. It can no longer access the Internet.

From the Ubuntu bash prompt: ping github.com doesn't work (100% packet loss); ping 8.8.8.8 is the same.

/etc/resolv.conf gives nameserver 192.168.115.225. ping 192.168.115.225 doesn't work.

My Ubuntu distro has IP 192.168.115.230; I can ping that from Ubuntu.

The Windows IP address is 192.168.115.225, and I can ping it from PowerShell. Pinging the Ubuntu distro's IP (192.168.115.230) also works, from PowerShell.

Inside Ubuntu, route -n reports:

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         192.168.115.225 0.0.0.0         UG    0      0        0 eth0
192.168.115.0   0.0.0.0         255.255.255.0   U     0      0        0 eth0

I'm using a Surface Go, Windows 10 Pro, connected to the Internet over Wifi.

I might have some left-over detritus from when I attempted to get a Hyper-V VM connecting via Wifi. That was prior to upgrading to Windows Insiders. I don't know how much of that Hyper-V networking infrastructure is shared, and I don't know how to debug that.

[rlipscombe]

I attempted to convert the distro back to WSL 1, but it failed with The network connection was aborted by the local system.

[rlipscombe]

Oh, it might be worth noting that I've got Checkpoint VPN software (not active), Wireshark (i.e. npcap) and NordVPN (also not active) installed. I don't know whether any of those will break anything.

[rlipscombe]

Uninstalling NordVPN does not fix the problem.

The Checkpoint VPN software seems to be responsible for screwing it up. Uninstalling it fixes the problem.

Unfortunately (sigh), I have to have this software installed, so it looks like I'm going to have to uninstall Windows Insiders.

Any chance you could work with Check Point to get this resolved?

[rlipscombe]

So, interestingly enough, uninstalling and reinstalling the Checkpoint VPN software appears to fix the problem.

[rlipscombe]

(title updated to true cause of problem)

[BenHenning]

FWIW I've experienced what sounds like a similar issue, and I don't use Checkpoint VPN. I notice that when this happens, seemingly all socket-level operations seem to fail in Windows. Even my Android emulator becomes inaccessible to Android Studio, and all Chrome tabs indicate no internet connectivity. Closing all Ubuntu windows resolved the issue for me today, and this consistently happens when I leave a local server running in Ubuntu overnight and come back to my workstation 24 hours later.

[cmeiklejohn]

I'm using the Cisco AnyConnect VPN and as soon as I connect, I lose all access to the external network. Anything I can do to help debug this further?

[craigloewen-msft]

@cmeiklejohn please see issue #4277

If you'd like to help us debug it please send us networking logs, instructions on how to do that are here!

[neileadobe]

I also have this problem, using Cisco. Logs here: https://aka.ms/AA6fthe

[rlipscombe]

Data point: with Windows 10.0.19013.1, CheckPoint VPN E81.40. If I right-click on the notification icon and select "Disable Security Policy" (thus regaining control of my own firewall) then WSL Ubuntu can connect to the Internet correctly.

[jagjordi]

Same issus occurs with Cisco OpenConnect VPN. Here are the logs https://aka.ms/AA6jmg1

[timesnewmen]

Similar issue with Citrix VPN.
I can ping the server, but can not open tcp port 80 and curl is timeout.

[codeart1st]

Same issues also with Checkpoint VPN

[caal-15]

Same problem with Cisco AnyConnect

[elmorekevin]

I lose internet connectivity in WSL2 when using SonicWall VPN in full-tunnel mode. If I switch to partial-tunnel, then WSL2 internet connectivity is fine.

[wissamz]

I am seeing the same behavior using Cisco AnyConnect VPN. Any updates on this issue?

[iamoverit]

same issue using Cisco AnyConnect (connected)

[sphair]

So, interestingly enough, uninstalling and reinstalling the Checkpoint VPN software appears to fix the problem.

I have the same problem, but this did not seem to help in my case.

[hardik-id]

I installed/used Cisco AnyConnect from Windows Store
https://www.microsoft.com/store/productId/9WZDNCRDJ8LH and it started working.
Credit goes to #4277 (comment)

[andyneff]

I have the same problem as @elmorekevin I'm using the latest Sonicwall NetExtender (9.0.274), and can only use full tunnel mode. WSL1 works perfectly at the same time WSL2 does not.

[metawave]

I have a similar problem with Citrix Netscaler VPN at work, which only tunnels some networks. Internet access is fine with wsl2 but connecting to a host inside a VPN tunneled network, the name can be resolved to an IP but then timeouts (wireshark says tcp retransmission). Citrix Netscaler says, that it has tunneled that connection in the "tunneled application" window. Also disabled the firewall completely, but that didn't work either....

[andyneff]

At random, I tried to use WSL 2 when I was connected to VPN, and to my utter and total surprise, it started working! I have not been able to reproduce the result since. But I was able to access both my VPN network and the internet (via full tunnel mode).

I did make an observation though. When it worked, I had done nslookup and run server and noted the IP address of the dns proxy server was 172.x.x.x. However other times (when it doesn't work) it's 192.168.x.x. (Now my real IP both locally and via VPN is 10.x.x.x subnets)

Sometimes I see three IPs in WSL2 (ifconfig), sometimes only two. I have no idea what is going on here. For example, now I only see 172.25.x.x and 127.0.0.1 (local host is always there), and it's not working. In my current example, I am able to ping the 172.25.x.x IP on my host windows machine, that is in the same subnet, but none of my other IPs

Recently updated to Windows 10 Pro build 10.0.19041

[andyneff]

Attempted to delete the WSL NIC/switch from hyper v fails (in a extremely bad way) I was hoping I could "reset the NIC" once connected to VPN by deleting it, and then letting it regenerate like it did the first time you run WSL2. It half deletes, and won't finish, and will never repair itself. I had to uninstall and reinstall WSL itself (not the distros)

[andyneff]

Workaround steps to get Internet working on VPN

Since the one time I got internet working on WSL2 was after an Windows 10 update, I was guessing that maybe somehow the network was reset, it and was because I started WSL2 while on VPN...

This has worked twice now using Sonicwall VPN, so I hope this works for someone else:

WARNING: You should always backup registry keys before you delete them, in case this breaks things!

1. Remove the WSL Switch and NIC. Since neither WSL2 VM nor networks devices appear normally in Hyper-V Manager (which only hurts the users, so thanks), I cannot figured out how to use Hyper-V Manager to remove the Switch. It just errors out, and leave it broken. Now I found a Registry way to remove them
   1. Look in HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Control\Class\{4d36e972-e325-11ce-bfc1-08002be10318}\####\NetSetupProperties, where #### is a four digit number
      • Out of the four digit keys in there, two of them will mention WSL
        • "NETSETUPPKEY_Interface_IfAliasBase"="vSwitch (WSL)"
        • "NETSETUPPKEY_Interface_IfAliasBase"="vEthernet (WSL)"
      • The two number should be consecutive. Delete both keys.
   2. Look in HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\vmsmp\parameters\NicList
      • Delete the Key containing "FriendlyName"="WSL"
   3. Look in HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\vmsmp\parameters\SwitchList
      • Delete the Key containing "FriendlyName"="WSL"
2. Now reboot.
3. Once you reboot, running ipconfig should no longer show Ethernet adapter vEthernet (WSL):
4. VPN in (do not start WSL2 even once before doing this)
5. Once completly connected to VPN, now start WSL 2
   • Enjoy internet (Until you have to do this all over again...)

While still on VPN, shutting down WSL2 and restarting it, still worked. However...

1. wsl --shutdown
2. Disconnect from VPN
3. Reconnect from VPN
4. Run WSL2 again

Does not work.

---

This is not a great workaround, but it is a start... Shortcuts welcome!

[AmmarRahman]

The workaround I have at the moment is to work within a container. Even though Docker uses WSL2 as it's backend, they seem to have got a better network setup that would work through the VPN.

[metawave]

I can confirm the comment of @AmmarRahman. After installing Docker Desktop on my Windows machine and switch to the WSL2 backend, I noticed that this docker daemon is able to access resources in the vpn (downloads an image from a docker registry there). I can also confirm it by running a container accessing resources on the vpn docker run alpine sh -c 'wget -O- https://some-vpn-internal.resource.com'. Eventhough the communication to vpn resources don't work in wsl2, ex. by running the docker wsl2 "machine" (wsl.exe -d docker-desktop). So I think something is actively preventing this to work

[jcmendez-guerrero]

Do we have to run this after every reboot?

Actually you need to run every time you connect the VPN. I haven't been able to find a way to keep the values permanent or without the need of elevated rights

[andyneff]

Do we have to run this after every reboot?

Many VPN clients have the ability to run a post connection script, https://docs.paloaltonetworks.com/globalprotect/9-1/globalprotect-admin/globalprotect-apps/deploy-app-settings-transparently/customizable-app-settings/script-deployment-options.html, however I'm not sure if that will be able to run with the rights you need (I supposed that depends on how GlobalProtect works)

If your Admins are willing to setup this up for you, they can

1. As an admin, Create a task in "Task Scheduler" that will do what you need. Make sure it's configured to run with admin privileges. Usually this means "Run as SYSTEM user, and check the "Run with highest privileges", but they may have another user account designed for this purpose.
2. "Allow task to be run on demand" must be on
3. No trigger needs to be setup
4. Action would run a command (or script) to set your settings.
5. Have the admin give you permission to run the task (I think this is automatic, I don't remember)

Now this means you'll have permission to run an "elevated" task. This is the closest to a "windows sudo" list I know of.

There's a command. As a user, you can create a shortcut to run SCHTASKS.EXE /RUN /TN "task name", and now you can run that task that needs admin, as a non-admin any time you want.

---

I used to think this would help, but on second glance, it will not, it's kind of solves an opposite problem
https://docs.microsoft.com/en-us/powershell/module/vpnclient/add-vpnconnectiontriggerapplication?view=windowsserver2019-ps

[alxdrl]

Hi @wesleymusgrove,

In addition to using Cisco AnyConnect VPN on my Windows 10 host, all my traffic also goes through a Zscaler proxy running on Windows on http://localhost:9000. That means that while I'm connected to my VPN, in Windows I also have to specify HTTP_PROXY=http://localhost:9000 pretty much everywhere you can imagine so that things can access the internet. Inside of WSL, [...] . However I'm getting this error: curl: (56) Recv failure: Connection reset by peer and I don't know at what layer it's failing...

curl: (56) Recv failure: Connection reset by peer

I'm facing the same issue here (win10 20H2 + WSL2 + Zscaler client connector 3.1.0.96)

• added firewall rules to allow WSL access port 9001 on host
• added netsh interface portproxy to proxy on host address 10.90.161.68
• changed interface metrics
• set http_proxy/https_proxy in WSL guest

curl on host through proxy => OK
curl on WSL guest =>

$ curl  -v https://www.google.com/
* Uses proxy env variable https_proxy == '10.90.161.68:9001'
*   Trying 10.90.161.68:9001...
* Connected to 10.90.161.68 (10.90.161.68) port 9001 (#0)
* allocate connect buffer!
* Establish HTTP proxy tunnel to www.google.com:443
> CONNECT www.google.com:443 HTTP/1.1
> Host: www.google.com:443
> User-Agent: curl/7.78.0
> Proxy-Connection: Keep-Alive
> 
* Recv failure: Connection reset by peer
* Received HTTP code 0 from proxy after CONNECT
* CONNECT phase completed!
* Closing connection 0
curl: (56) Recv failure: Connection reset by peer

Were you able to solve it ?

[yalopov]

I have created a script to simplify the solution above for our corporate machines. I have adapted it to be more generic on

https://github.com/AmmarRahman/wsl-vpn

Please feedback if this work for you.

Works like a charm, thank you

[thcuvelier]

Using also Zscaler proxy running on Windows on http://localhost:9000. and having the same problem than @aderuelle
Any idea how to solve this

[nb510]

Has anyone found a solution in 2023 for Windows 11 and the latest version of Checkpoint?
In accordance with https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solutionid=sk177207 I need to add a new rule to the incoming firewall policy rules. Does anyone know how to do this?

[Pit-Storm]

You shouldn't change the Interface-Metric due to the than different routing. See the following blogpost for explanation: https://janovesk.com/wsl/2022/01/21/wsl2-and-vpn-routing.html
TLDR: If it works, it doesn't mean that it doesn't have side effects. And it's not only solving the thing that you was intended to fix.

The problem of not using the correct DNS-Server is properly explained and the suggested solution should be used from networking point of view.

For the IP-Range problem you have only the following two options:

1. Changing the routing table (see blogpost above)
2. Changing the subnet-range that WSL is using

How second could work, is shown in this Microsoft Q&A: https://learn.microsoft.com/en-us/answers/questions/1123820/set-wsl2-subnet

TLDR: Change SubNet of WSL NAT-Router to a different one which does not collide with your Company-VPN subnet. To do so got to regedit and edit the following entries:
Path: Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Lxss
Entries: NatGatewayIpAddress and NatNetwork
Values e.g.: 19.16.0.1 and 19.16.0.0/16

Again: Please don't change the InterfaceMetric!

[K2ouMais]

Guys don't mess around with your wsl and just use this to fix it for you.

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

This was the only solution I found to work.

[K2ouMais]

Guys don't mess around with your wsl and just use this to fix it for you.

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

This was the only solution I found to work.

[ganeshgk]

@aderuelle @thcuvelier @wesleymusgrove Did anyone got this working? I have a similar issues - my corporate laptop has zscalar running on 9000 port, access via specific networks go via zscalar when done via browser, but those same networks when accessed via wsl fails -> because it doesn't go via zscalar. :/

[craigloewen-msft]

Hi folks, we have put out a new update that aims to address networking issues in WSL. In your .wslconfig file you can set experimental.networkingMode=mirrored, as well as some other key settings that should improve your network compatibility! Please try them out and let us know what you think.

More info on this release and the changes can be found here in the blog post.

Please note: You need to be on a Windows Insiders version to use the new networking settings (Any channel of Windows Insiders will do, including release preview). If you see the "These are not supported" messages it means that your current Windows version doesn't have support, and you will need to upgrade. These features will eventually be coming to Windows 11 22H2.

[wissamz]

@craigloewen-msft Where would we see the "These are not supported" message? And is there a way to verify that the settings are taking effect?

[craigloewen-msft]

If you run wsl.exe you will see the not supported messages in your console output. You can verify you have mirrored mode running by checking to see if your IP address in WSL is the same as yours in Windows (See the video in the blog post for the demo on that).

[craigloewen-msft]

These new networking features are now available on the latest version of Win11 22H2!

Please make sure you're on the latest build to get these features, you can do that by clicking "Check for Updates" in Windows settings. You can check you have the right build by either ensuring you have KB5031354 installed, or run cmd.exe /c ver and ensure that your build number is 22621.2428 or higher (Including the minor build number which is after the . as this was a backport!)

[andyneff]

These new networking features are now available on the latest version of Win11 22H2!

Please make sure you're on the latest build to get these features, you can do that by clicking "Check for Updates" in Windows settings. You can check you have the right build by either ensuring you have KB5031354 installed, or run cmd.exe /c ver and ensure that your build number is 22621.2428 or higher (Including the minor build number which is after the . as this was a backport!)

@craigloewen-msft I can confirm that after installing these updates Azure VPN + Windows Defender for Endpoint and Sonicwall Mobile Connect + Windows Defender for Endpoint both work now. However SonicWall NetExtender + Windows Defender for Endpoint does not work still.

[kharlamov-itra]

Has anyone found a solution in 2023 for Windows 11 and the latest version of Checkpoint?

@out510 Have you found a solution?

[nb510]

Has anyone found a solution in 2023 for Windows 11 and the latest version of Checkpoint?

@out510 Have you found a solution?

I haven't

[OneBlue]

Hi ! Please try the latest networking features that we've added in WSL. Those should greatly improve VPN compatbility.

If the issue still remains, please reopen this issue.

[lkorpalski-pgs]

No combination of mirrored mode networking and dns tunnelling is fully helping. Mirrored mode makes the internet work when connected via checkpoint, but WSL2 can't access the vpn subnets. Dns tunneling doesn't seem to change anything.

[JOSEALM3IDA]

I have a slightly different experience: Check Point Mobile VPN turned on, DNS tunneling turned on (which is default) and NAT mode (not mirrored) I get correct hostname resolution (IP resolves fine) but 100% packet loss, as before.

Changing the networkingMode to mirrored completely kills DNS resolution ('Temporary failure in name resolution') and pinging IPs directly gives 'connect: Network is unreachable'

Turning off DNS tunneling, either with networkingMode on NAT or mirrored, doesn't change anything for me, just like @lkorpalski-pgs reported

With Check Point VPN turned off, and with default settings (nothing in .wslconf) the network connection works with no problems

[bedware]

This helped me make external (internet) and internal (corporate) resources work. Taken from here.
Prerequisites:

• WSL

wsl --version
WSL version: 2.2.4.0
Kernel version: 5.15.153.1-2
WSLg version: 1.0.61
MSRDC version: 1.2.5326
Direct3D version: 1.611.1-81528511
DXCore version: 10.0.26091.1-240325-1447.ge-release
Windows version: 10.0.22631.4169

• Check Point Endpoint Security Version VPN E87.20 Build 986104605

C:\Users\dmitr
> Get-NetFirewallHyperVVMSetting -PolicyStore ActiveStore -Name '{40E0AC32-46A5-438A-A0B2-2B479E8F2E90}'

Name                  : {40E0AC32-46A5-438A-A0B2-2B479E8F2E90}
Enabled               : True
DefaultInboundAction  : Block
DefaultOutboundAction : Allow
LoopbackEnabled       : True
AllowHostPolicyMerge  : True

C:\Users\dmitr
> Set-NetFirewallHyperVVMSetting -Name '{40E0AC32-46A5-438A-A0B2-2B479E8F2E90}' -DefaultInboundAction Allow
C:\Users\dmitr
> Get-NetFirewallHyperVVMSetting -PolicyStore ActiveStore -Name '{40E0AC32-46A5-438A-A0B2-2B479E8F2E90}'

Name                  : {40E0AC32-46A5-438A-A0B2-2B479E8F2E90}
Enabled               : True
DefaultInboundAction  : Allow
DefaultOutboundAction : Allow
LoopbackEnabled       : True
AllowHostPolicyMerge  : True

C:\Users\dmitr
> wsl --terminate Ubuntu-22.04
The operation completed successfully.
C:\Users\dmitr
> wsl --shutdown

[fourpastmidnight]

I know this is closed, but for others who end up here, I'll post my answer, because for me, it was a combination of things that got this working for me.

Like many of you, my company switched to Checkpoint VPN, and after that, my WSL connectivity was broken. Here's how I fixed it. Note that I did not need to shutdown WSL, uninstall/reinstall anything. I just needed to update a text file and a NIC configuration. That's all.

First, I edited the /etc/resolv.conf file. Now this is a symlink to a file that is automatically generated by WSL. Since I just got this to work, I have not yet turned off auto-generation of this file. (I'm waiting to see if this will be necessary before turning off auto-generation.) For now, I have now turned off auto-generation of this file because I found that upon restart of the underyling VM, the file is reset and the changes I made below are necessary for me to have internet access from Ubuntu on WSL. YMMV depending on your environment and how your networking staff have configured the VPN. I simply changed the file to have the following contents:

# This file was automatically generated by WSL. To stop automatic generation of this file, add the following entry to /etc/wsl.conf:
# [network]
# generateResolvConf = false
nameserver <VPN Nameserver 1>
nameserver <VPN Nameserver 2>
nameserver <Home Router Nameserver>

The first two lines I snagged from ipconfig /all for the adapter associated with the Checkpoint VPN connection. The last one is my home router's nameserver (or, your preferred nameserver, e.g. Mozilla, Google, Cloudflare, etc.). Originally, I put my home router nameserver first because I wanted to prioritize most requests through my ISP. BUT, apparently, WSL stops querying nameservers at the first "successful" response even if the result is "I couldn't find what you're looking for." So, I switched them around. Oddly enough, when I later did a nslookup for a company resource, the VPN nameservers failed to resolve the company resource, but my home router entry resolved the name 😕 Whatever, it worked.

OK, so at that point, I could ping the company resource I wanted access to—in this case, an Azure DevOps on-prem server. BUT, when attempting to git fetch origin, I received the following message: Recv failure: Connection reset by peer. Hmm, is this a firewall issue? It doesn't seem like it—that would usually be Connection forcefully reset by peer... Then I remembered the above references to the MTU size. So I did a ip link set eth0 mtu 1350, because that's what the Checkpoint VPN is configured to use as the MTU (by default?). Once that was done, I was able to access the Azure DevOps server and fetch my repository.

So, to summarize the required steps:

1. Update /etc/resolv.conf, potentially turning off auto-generation of the file
2. Set your WSL adapter's MTU (from within WSL) to the same MTU as your VPN ethernet adapter's MTU.
3. Profit.

Hope this helps somebody. At least this will help my future self. 😆

[bedware]

2. Set your WSL adapter's MTU (from within WSL) to the same MTU as your VPN ethernet adapter's MTU.

Affirmative, changing MTU helped me with the Check Point Endpoint Security Version VPN E87.20 Build 986104605.
Before that, I couldn't make "follow redirects" in curl. The connection just hung after the headers...

Thanks