WSL2 fails to make HTTPS connection if Windows is using VPN

emrahkaya commented 4 years ago

Your Windows build number: Microsoft Windows [Version 10.0.19013.1122]
What you're doing and what's happening:
1. Open WSL 2 terminal (Ubuntu) and type: wget --timeout=30 http://packages.microsoft.com/ubuntu/18.04/prod, which succeeds.
2. In WSL 2, type: wget --timeout=30 https://packages.microsoft.com/ubuntu/18.04/prod, which also succeeds.
3. Connect through a VPN on Windows using the built-in VPN client.
4. In WSL 2, type: wget --timeout=30 http://packages.microsoft.com/ubuntu/18.04/prod, which still succeeds.
5. In WSL 2, type: wget --timeout=30 https://packages.microsoft.com/ubuntu/18.04/prod, which fails with message "Unable to establish SSL connection".
6. (control) In Powershell, type wget -TimeoutSec 30 https://packages.microsoft.com/ubuntu/18.04/prod, which still succeeds.
What's wrong / what should be happening instead: The 5th step should also have been succeeded.
Notes:
To be sure that it's not a firewall issue, I've included all network connections, including the VPN connection to the Private group
The date command in WSL shows correct date-time.
I've also tried with --no-hsts and --no-check-certificate options, but result is the same
I've also tested from firefox (in WSL) and it also waited for "Performing a TSL handshake to packages.microsoft.com", couldn't finish connection and gave "The connection has timed out" error after a while.
To be sure that it's not an network adapter issue, I've tested it by using both Wireless and Ethernet connections, which also connects to different ISPs.

NiklasBr commented 4 years ago

have you tied reaching your internal companies website after applying all 3 fixes? I found ping for external websites but a curl URL (HTTP?) is working. , so may be something with your companies private network

Hadn't tried, but I tested reaching our DNS serverns: 100% packet loss, Gateway: 100% loss, my desk PC: 100% loss. If I try a domain name I get the error ping: Temporary failure in name resolution

Good news is that at least loopback works 😄

niklas@Fractal:~$ ping 127.0.0.1
PING 127.0.0.1 (127.0.0.1) 56(84) bytes of data.
64 bytes from 127.0.0.1: icmp_seq=1 ttl=64 time=0.012 ms
64 bytes from 127.0.0.1: icmp_seq=2 ttl=64 time=0.014 ms
64 bytes from 127.0.0.1: icmp_seq=3 ttl=64 time=0.013 ms
64 bytes from 127.0.0.1: icmp_seq=4 ttl=64 time=0.015 ms
64 bytes from 127.0.0.1: icmp_seq=5 ttl=64 time=0.014 ms
^C
--- 127.0.0.1 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4121ms
rtt min/avg/max/mdev = 0.012/0.013/0.015/0.004 ms

Cordius commented 4 years ago

In my situation, I can ping google but can't curl/wget on WSL2. Change MTU doesn't work for me.

cordius@L-81390457-0939:~$ ping www.baidu.com
PING www.a.shifen.com (180.101.49.11) 56(84) bytes of data.
64 bytes from 180.101.49.11 (180.101.49.11): icmp_seq=1 ttl=45 time=18.3 ms
64 bytes from 180.101.49.11 (180.101.49.11): icmp_seq=2 ttl=45 time=18.7 ms
64 bytes from 180.101.49.11 (180.101.49.11): icmp_seq=3 ttl=45 time=17.9 ms
^C
--- www.a.shifen.com ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2004ms
rtt min/avg/max/mdev = 17.952/18.359/18.753/0.345 ms

cordius@L-81390457-0939:~$ curl -vvv www.baidu.com
* Rebuilt URL to: www.baidu.com/
*   Trying 180.101.49.12...
* TCP_NODELAY set
* connect to 180.101.49.12 port 80 failed: Connection timed out
*   Trying 180.101.49.11...
* TCP_NODELAY set
^C

applejag commented 4 years ago

Changing the MTU did it for me. My tip was to doublecheck the MTU my network adapter is actually using with netsh interface ipv4 show subinterface

# powershell on Windows
PS > netsh interface ipv4 show subinterface

   MTU  MediaSenseState   Bytes In  Bytes Out  Interface
------  ---------------  ---------  ---------  -------------
4294967295                1          0     747508  Loopback Pseudo-Interface 1
  1500                1  2244351051  1452619074  Wi-Fi
  1500                5          0          0  Cellular
  1500                5          0          0  Bluetooth Network Connection
  1500                5          0          0  Ethernet
  1500                5          0          0  Ethernet 3
  1392                5          0          0  Ethernet 4
  1500                5          0          0  Local Area Connection* 1
  1500                5          0          0  Local Area Connection* 2
# ↓↓↓↓ here's my actual VPN MTU config
  1200                1  1845392493  1251827749  My VPN setup
# ↑↑↑↑
  1500                5          0          0  Ethernet 2
  1500                1          0    7931843  vEthernet (Default Switch)
  1500                1   38626057   38625717  vEthernet (Ethernet 3)
  1500                1    3007499  116996182  vEthernet (WSL)
  1500                1   38626627   38626517  vEthernet (Ethernet)
  1500                1    7944342    7923059  vEthernet (Ethernet 4)
  1500                1    7938322    7919906  vEthernet (Ethernet 2)
  1500                1   18285484   18286252  vEthernet (Cellular)
  1500                1    7924600    7909471  vEthernet (Wi-Fi)
  1500                1    7875089    7865975  vEthernet (My VPN setup)

Then I could follow the tip by @neseih (but with the ip command instead)

# bash inside my WSL 2
$ sudo ip link set eth0 mtu 1200

That solved it for me. Did not succeed in having it apply after a reboot though, but I just inserted the snippet into a script and I run it manually on each morning when I start working via the VPN.

Sorry if I missed a statement of it in the discussion, but is this planned to be fixed? Like that WSL 2 applies MTU changes automatically when switching to VPN. Or will this config always be have to be done manually on a per-user basis?

trondhe commented 4 years ago

Changing the MTU did it for me. My tip was to doublecheck the MTU my network adapter is actually using with netsh interface ipv4 show subinterface
# powershell on Windows
PS > netsh interface ipv4 show subinterface

   MTU  MediaSenseState   Bytes In  Bytes Out  Interface
------  ---------------  ---------  ---------  -------------
4294967295                1          0     747508  Loopback Pseudo-Interface 1
  1500                5          0          0  Local Area Connection* 2
# ↓↓↓↓ here's my actual VPN MTU config
  1200                1  1845392493  1251827749  My VPN setup
# ↑↑↑↑
  1500                5          0          0  Ethernet 2
  1500                1          0    7931843  vEthernet (Default Switch)
That solved it for me. Did not succeed in having it apply after a reboot though, but I just inserted the snippet into a script and I run it manually on each morning when I start working via the VPN.

Wsl2 with ubuntu 18.04 and pulse vpn, this was the final step to fix (currently) all my networking issues.

/etc/resolv.conf

search my.dns.suffixes
nameserver a.b.x.z

where I found the dns suffixes by ipconfig /all and looking under the DNS Suffix Search List from the Windows IP Configuration section and DNS ips from the Local adapter that is created. This fixes base http connections and you can check with ping or just apt-get update.

Checking this Local Adapter with netsh interface ipv4 show subinterface showed 1320 MTU. Setting the base connection in wsl with sudo ifconfig eth0 mtu 1320 fixed https/ssh conections as well.

aj0413 commented 4 years ago

Just wanted to add to this for others:

I got the Mullvad client working (both OpenVPN and Wireguard) by adding the DNS server of the Mullvad adapter, created on Windows via the client, as a nameserver to the resolv.conf file for WSL2 Ubuntu instance.

MTU didn't effect this and it was simply a DNS resolution issue.

NiklasBr commented 4 years ago

it was simply a DNS resolution issue.

It's not a DNS issue for me (Cisco), can't reach anything by IP either:

bild

smerrill commented 4 years ago

In my case it was an MTU issue and sudo ifconfig eth0 mtu 1400 fixed outbound traffic for me.

erikhakansson commented 4 years ago

sudo ip link set eth0 mtu 1400 works for me.

But, how do I set that permanently?

viral32111 commented 4 years ago

I would add it to my ~/.bashrc or ~/.profile, etc so it runs everytime WSL initalises, but I suppose that isn't truly permanent, more so just "apply it every time the user logs (so when WSL loads)".

Since everyone else is posting their case: I got it working for me by setting different DNS nameserver IPs in /etc/resolvconf, not by adjusting the interface MTU.

JorgenSmith commented 4 years ago

+1 for me. I experienced the issue when doing a Clojure Clava REPL Jack In when on VPN with WSL2 - a few dependencies would get pulled down then after a few seconds, nothing.

Setting mtu to 1400 resolves it temporarily; netsh interface ipv4 show subinterface showed my VPN as having an MTU of 1400. Using Ubuntu, will look at making this a permanent config fix so that I won't have to type the SU pwd every time for the .bashrc workaround.

jsteenri commented 4 years ago

Check these other GH issues: 1) https://github.com/microsoft/WSL/issues/4277 -- Contains a workaround that (automatically) adjusts InterfaceMetrics in the routing table 2) https://github.com/microsoft/WSL/issues/1350 -- Contains a workaround for updating /etc/resolv.conf post-VPN to restore DNS

HTH

LeslieK commented 4 years ago

My openconnect vpn client was working perfectly until today. what happened to wls2 (ubuntu 18.04) over the past 24 hours?

justin-caldicott commented 4 years ago

I hit this too when using the Cisco AnyConnect app. Installing AnyConnect via the Windows Store and using that to connect seems to have sorted things for me, as per here.

NiklasBr commented 4 years ago

The Windows Store version looks like it is AnyConnect 4.7, our company supplies the newer version 4.8 with a pre-configured profile installed, so it is not a solution for all unfortunately.

rofrol commented 4 years ago

Works form me with 2FA and Cisco AnyConnect. Instructions here https://github.com/microsoft/WSL/issues/5068#issuecomment-683917384

grtrout commented 4 years ago

This has been a very helpful thread - thanks to everyone who contributed. After a ton of trial and error, I finally resolved my own connectivity issues by updating the /etc/resolv.conf file and updating the MTU setting on WSL2's eth0 to match my VPN's. In my case, this meant changing it from 1500 to 1396.

I do have one question, though. I understand that this setting gets reset and, as such, I've updated my .bashrc. This works great. However, I expected that I would need to change it back to 1500 when I am not using VPN. So far, I have not had to do that. I've tested this by downloading large files, cloning git repos, connecting to remote servers using SSH, etc. It seems to work perfectly fine when it's always set to 1396.

Is it possible that this mismatch will cause issues at some point? I'm fine with changing the setting as needed, but it would be great if I can just leave it as-is and not have to change it when I sign on/off VPN.

rofrol commented 4 years ago

maybe tinyproxy https://github.com/microsoft/WSL/issues/416#issuecomment-687904479 ?

NiklasBr commented 4 years ago

Is it possible that this mismatch will cause issues at some point?

I see no reason why it would interfere, at least not in a major way. It defines the Maximum Transmission Unit (maximum byte size per network transaction without fragmentation), if you are depending on super low network overhead, a high MTU is very desirable as I understand it because more data can fit into each transaction. Certain things could be a bit slower, but nothing should break.

maybe tinyproxy #416 (comment) ?

Unfortunately no help for Cisco AnyConnect users who are running VPN in Windows.

adonese commented 4 years ago

it got even worse with the latest two builds (20206 and previous) as my wsl internet got dropped after laptop sleeps or just randomly. Wrote this here since i believe they might be relevant.

Hebilicious commented 4 years ago

I am not sure I was experienced the same problem as everyone here, but I finally managed to get openvpn VPN working with WSL2 in a satisfying way. I'm connecting to the VPN with the openvpn GUI client from my Windows host (build 20211)

Connecting to the vpn immediately "breaks" the WSL network stack :

Restart it manually using an admin powershell :

# Open Powershell as Admin
PS C:\Users\Me> Restart-Service "Host Network Service"
PS C:\Users\Me> Restart-Service "LxssManager"

The DNS resolution is working out of the box :

I can ping the servers behind the vpn and google.com just fine. Docker desktop WSL2 backend is also working. Previously I had to connect from the openvpn cli tool from WSL2 itself, and change wsl.conf and resolv.conf to get the dns resolution working. Now everything works as intended 🎉

r-l-x commented 4 years ago

I also ran into this problem. This is a classic Path MTU discovery black hole case, where for some reason the Windows/VPN side doesn't send a "Fragmentation Needed" ICMP packet to the linux side. Rather than hardcoding a smaller MTU on the linux interface, a cleaner workaround is (I think) to enable MTU black hole detection on the linux side: # echo 1 > /proc/sys/net/ipv4/tcp_mtu_probing

For the reference, here is the documentation for this kernel setting (source)

tcp_mtu_probing - INTEGER
    Controls TCP Packetization-Layer Path MTU Discovery.  Takes three
    values:
      0 - Disabled
      1 - Disabled by default, enabled when an ICMP black hole detected
      2 - Always enabled, use initial MSS of tcp_base_mss.

Note that the fact that there is no convenient way at the moment in WSL2 to keep a persistent sysctl setting (see #4232) is quite annoying, and this setting must be applied every time WSL2 restarts for the moment.

To be honest I don't understand why common linux distributions don't enable MTU black hole detection by default. This is a very helpful feature. Microsoft has enabled this by default in Windows since Vista (source). For the reference, here are some discussions I have seen on this subject in Ubuntu: https://lists.ubuntu.com/archives/ubuntu-devel-discuss/2012-February/013195.html and in OpenSUSE: https://bugzilla.opensuse.org/show_bug.cgi?id=971797.

nezorflame commented 4 years ago

There might be a way to make it stick due to some work on systemd being done in https://github.com/microsoft/WSL/issues/994#issuecomment-698927438

rsegeda commented 4 years ago

Hi guys,

I understand it does not help everyone, but I have been able to solve it this way:

Check Challenge Handshake Authentication Protocol CHAP under adapter -> properties -> security

grtrout commented 4 years ago

@r-l-x That is very useful information. While the MTU setting/hack works fine for me, I'm striving for a cleaner solution. I plan to test this out soon.

@rsegeda FWIW, that setting (CHAP) was already enabled for my VPN connection and the problem persists.

rsegeda commented 4 years ago

@r-l-x That is very useful information. While the MTU setting/hack works fine for me, I'm striving for a cleaner solution. I plan to test this out soon.

@rsegeda FWIW, that setting (CHAP) was already enabled for my VPN connection and the problem persists.

You are right, I can see it is not stable. However, It did work for a while and it happens again now.

anagata commented 4 years ago

I also ran into this problem. This is a classic Path MTU discovery black hole case, where for some reason the Windows/VPN side doesn't send a "Fragmentation Needed" ICMP packet to the linux side. Rather than hardcoding a smaller MTU on the linux interface, a cleaner workaround is (I think) to enable MTU black hole detection on the linux side: # echo 1 > /proc/sys/net/ipv4/tcp_mtu_probing

For the reference, here is the documentation for this kernel setting (source)
tcp_mtu_probing - INTEGER
  Controls TCP Packetization-Layer Path MTU Discovery.  Takes three
  values:
    0 - Disabled
    1 - Disabled by default, enabled when an ICMP black hole detected
    2 - Always enabled, use initial MSS of tcp_base_mss.
Note that the fact that there is no convenient way at the moment in WSL2 to keep a persistent sysctl setting (see #4232) is quite annoying, and this setting must be applied every time WSL2 restarts for the moment.

To be honest I don't understand why common linux distributions don't enable MTU black hole detection by default. This is a very helpful feature. Microsoft has enabled this by default in Windows since Vista (source). For the reference, here are some discussions I have seen on this subject in Ubuntu: https://lists.ubuntu.com/archives/ubuntu-devel-discuss/2012-February/013195.html and in OpenSUSE: https://bugzilla.opensuse.org/show_bug.cgi?id=971797.

This solves the same problem I had, however the command to enable MTU black hole detection doesn't work for me. I had to use

$ sudo sysctl -w net.ipv4.tcp_mtu_probing=1

For reference see: https://lists.ubuntu.com/archives/ubuntu-devel-discuss/2012-February/013198.html

rsegeda commented 4 years ago

I ended up setting the MTU in .profile just like suggested above. + this fix for autogenerated wsl2 resolv.conf

Seems to be working for now.

earljon commented 4 years ago

Hi @rsegeda , what exactly worked on your end? For me, I have followed these instructions but Im still unable to connect inside WSL2

Private IP EKS
Private IP MySQL RDS

To resolve this for now, I created a new WSL v1 that doesn't have these issues but I really wanted to work with WSL2 because of the Docker + WSL2 integration.

rsegeda commented 4 years ago

@earljon As I've already said:

Set MTU in ~/.profile by adding a line sudo ifconfig eth0 mtu 1400 ~~2. Check your Windows host IP address and do it like it is described here~~

The second step is problematic if you're using GUI. I'm using Xwinrc, which requires me to put the DISPLAY env variable with an IP address of the host. Unfortunately, the IP changes on every Windows restart, which means I have to do it manually after starting the wsl2 session every day (for the first time after the windows boot). I have to automate it ofc.

EDIT: I have just switched to this fantastic tool which fixes the manual part of updating DISPLAY -> https://github.com/rsegeda/x11-over-vsock

As I said, I have access to both the VPN and the external network. However, changing the VPN connection during my wsl2 session (e.g., when I'm using the IntelliJ or Chrome via XWinrc) immediately shut down WSL2, which is very irritating btw. So I feel that I'm still missing something here (or simply, I don't understand it).

Bryce-huang commented 4 years ago

has same issue ,my pc using vpn and wsl2 switch to connect the vpn.

my kubectl client can't connect kubernetes of docker desktop

when i use the commands to unset proxy,it works:

 unset http_proxy
    unset HTTP_PROXY
    unset https_proxy
    unset HTTPS_PROXY
    unset ALL_PROXY
    unset all_proxy

earljon commented 4 years ago

I have no issues working with local Kubernetes with my Docker Desktop and doesn't need to unset anything inside the linux box.

Perhaps my issues is related to VPN but I can't pinpoint what exactly is wrong. I am using Endpoint Security VPN. My problem is that when I am connected to VPN (which is a must to be able to access AWS resources via their private IPs), I can't seem to connect any AWS services like EKS, MySQL RDS inside the WSL2 Ubuntu box. These AWS services are configured to only visible and accessible via Private Endpoints.

No issues when I am using (1) Windows Host machine and (2) WSL version 1.

earljon commented 4 years ago

Just an update on my WSL2 Issue with Check Point Endpoint VPN. I think I have solved it following solution found here - https://github.com/microsoft/WSL/issues/4246

Basically, what I only did is to set the MTU to the correct value. I've been trying to set my MTU to 1400 but based on the link above, for Checkpoint VPN to work with WSL2, a value of MTU 1350 is all it needs.

No modification of /etc/resolv.conf needed. No restart needed.

jakebrinkmann commented 3 years ago

thank you @earljon .

This is my solution for:

Pulse Secure VPN

PowerShell: netsh interface ipv4 show subinterface
WSL2: ip link list
WSL2: sudo ip link set dev eth0 mtu 1400

Notes

I ran this after successfully connected to the VPN. I noticed an extra Local Area Connection* with an MTU value ~100 less than the other "Local Area Connection" entries. That's the value I wanted.
Inside WSL2, check what your eth0 mtu value is set to. It was not the MTU value discovered in Step 1.
Inside WSL2, set the MTU value of the interface eth0 to the value discovered in Step 1.
HTTPS IS NOW WORKING :tada:

sbmaruf commented 3 years ago

Note for Pulse Secure: Could not resolve the problem in anyway. Changing MTU doesn't work. Finally downloaded the pulse secure from "Windows Store" and Reinstall IP, IPV6, PPTP from the device manager. And now it works.

lyng-dev commented 3 years ago

When connected using NordVPN, I get very slow or no internet connectivity when using WSL2.0

Resolution for NordVPN

Add to ~/.bashrc or ~/.zshrc or ~/.profile sudo ip link set dev eth0 mtu 1400
Restart Terminal

Andy9822 commented 3 years ago

I've been struggling with extremely low download speed for almost a year as described in #5638 In my case it happened only when I turn on my VPN and only within WSL, from Windows was everything fine.

The sudo ip link set dev eth0 mtu 1400 solution worked like a charm, it now works perfectly. I can't believe it but finally there we go :)

cdonnellytx commented 3 years ago

I hit this problem with apt update with the Microsoft server, with this only-tangentially-related error:

The repository 'https://packages.microsoft.com/ubuntu/20.04/prod focal Release' does not have a Release file.

I only noticed this after I installed the AWS Client VPN, although I have Pulse Secure 9.1.9 installed (and had Cisco AnyConnect 4.5.02036 installed). Basically everything works except https://packages.microsoft.com, which appears to fall into the MTU black hole described above.

I have since uninstalled the Cisco client as my company no longer uses it, as well as the AWS client, to no avail. I also don't know if the problem has been happening longer than that, though it definitely wasn't an issue 3-6 months ago.

I even uninstalled and reinstalled WSL (and the Ubuntu VM) to no avail. I encountered this on all three Ubuntu "apps" in the MIcrosoft Store (default, LTS 20.04, LTS 18.04).

The only thing that worked was dropping the MTU of eth0 to 1404:

Changing tcp_mtu_probing to 1 or 2 -- both methods -- had no effect:

# ran all the following sudo'd as root
sysctl -w net.ipv4.tcp_mtu_probing=1        # did not work for me
echo 1 > /proc/sys/net/ipv4/tcp_mtu_probing # did not work for me
ip link set dev eth0 mtu 1404               # worked for me.  Highest value that worked

Note I have not tried the solution on 18.04, only 20.04.

It took me way too long to figure this out based on the initial error -- hoping by adding it here it helps others.

EDIT: indicating how I ran the commands

logeekal commented 3 years ago

A simple fix for me was to set MTU to 1350 (same as VPN interface): sudo ifconfig eth0 mtu 1350

Even SSH connections are more stable now.

This solved my issues as well. I am using checkpoint VPN.

to get the MTU value of your VPN run below command for checkpoint, for example :

Get-NetAdapter | Where-Object {$_.InterfaceDescription -Match "Check"}

Name                      InterfaceDescription                    ifIndex Status                   LinkSpeed
----                      --------------------                    ------- ------                  ---------
Ethernet 3                Check Point Virtual Network Adapter Fo…       8 Up                   1 Gbps

Note the index of the connection, then run below statement. Match the index found above in below result and note the mtu.

netsh.exe interface ipv4 show interfaces

Idx     Met         MTU          State                Name
---  ----------  ----------  ------------  ---------------------------
  1          75  4294967295  connected     Loopback Pseudo-Interface 1
 24          35        1500  connected     Wi-Fi
 16          25        1500  disconnected  Local Area Connection* 1
 10           5        1500  disconnected  Ethernet 2
  5          25        1500  disconnected  Local Area Connection* 2
 17          65        1500  disconnected  Bluetooth Network Connection
 38          15        1500  connected     vEthernet (Default Switch)
 59          15        1500  connected     vEthernet (WSL)
  8           0        1350  connected     Ethernet 3

Not you have the mtu value.. Login into your wsl and run below statement(1350 is the mtu found above): sudo ifconfig eth0 mtu 1350

You can also run this script when you wsl2 is starting. below is the script if you have debian based wsl

sudo ip link set dev eth0 mtu 1350

dalewest commented 3 years ago

Excellent. The change of MTU also fixed my strange problems with the PulseSecure VPN. Most SSL things worked fine but couple command cli tools like cf and fly would not work from the WSL2 side of the machine.

wirdehall commented 3 years ago

Just an update on my WSL2 Issue with Check Point Endpoint VPN. I think I have solved it following solution found here - #4246

Basically, what I only did is to set the MTU to the correct value. I've been trying to set my MTU to 1400 but based on the link above, for Checkpoint VPN to work with WSL2, a value of MTU 1350 is all it needs.

No modification of /etc/resolv.conf needed. No restart needed.

THANK YOU! I have been trying to fix this for the better part of the day!

mjsztainbok commented 3 years ago

The MTU actually can need to be lower than the value from the interface. My Cisco VPN connection is reporting a MTU of 1390 but if I set WSL to that then SSL still doesn't work. I worked down the MTU by values of 10 and SSL didn't work until I set it to 1350.

cprivitere commented 3 years ago

Going to post this in a few of the longer running threads. Long story short, the AnyConnect fix for this issue is available. The fix requires two pieces, an update to the client of version 4.10.01075 or later and a new custom attribute in the ASDM. Links to info below:

Release Notes Admin Document Troubleshooting Section that describes the custom attribute that needs to be set up by the VPN adminstrator.

Glen-Moonpig commented 3 years ago

Going to post this in a few of the longer running threads. Long story short, the AnyConnect fix for this issue is available. The fix requires two pieces, an update to the client of version 4.10.01075 or later and a new custom attribute in the ASDM. Links to info below:

Release Notes Admin Document Troubleshooting Section that describes the custom attribute that needs to be set up by the VPN adminstrator.

I now have AnyConnect working with WSL2 using version 4.10.01075.

I think you need to make sure you have the 'Allow local LAN access' option checked:

vjaro commented 3 years ago

This is my solution for:

Pulse Secure VPN

PowerShell: netsh interface ipv4 show subinterface

WSL2: ip link list

WSL2: sudo ip link set dev eth0 mtu 1400

Notes

I ran this after successfully connected to the VPN. I noticed an extra Local Area Connection* with an MTU value ~100 less than the other "Local Area Connection" entries. That's the value I wanted.

Inside WSL2, check what your eth0 mtu value is set to. It was not the MTU value discovered in Step 1.

Inside WSL2, set the MTU value of the interface eth0 to the value discovered in Step 1.

HTTPS IS NOW WORKING 🎉

Thank you! This worked for me.

kishooore commented 3 years ago

Nothing works for me. Please help to fix the issue.

p-sherratt commented 3 years ago

@r-l-x describes the issue I'm seeing too and suggests the best workaround IMO.

However this also depends on the remote side of the VPN not having broken path MTU discovery, too - because it is still possible to negotiate a higher TCP MSS that the server will try to use when sending its response. The second workaround below of reducing interface MTU in the guest will cause a lower TCP MSS to be negotiated and works around this potential issue at the far-end of the VPN.

So if this first workaround does not work for you, then move on to the second.

I also ran into this problem. This is a classic Path MTU discovery black hole case, where for some reason the Windows/VPN side doesn't send a "Fragmentation Needed" ICMP packet to the linux side. Rather than hardcoding a smaller MTU on the linux interface, a cleaner workaround is (I think) to enable MTU black hole detection on the linux side: # echo 1 > /proc/sys/net/ipv4/tcp_mtu_probing

For the reference, here is the documentation for this kernel setting (source)
tcp_mtu_probing - INTEGER
  Controls TCP Packetization-Layer Path MTU Discovery.  Takes three
  values:
    0 - Disabled
    1 - Disabled by default, enabled when an ICMP black hole detected
    2 - Always enabled, use initial MSS of tcp_base_mss.
Note that the fact that there is no convenient way at the moment in WSL2 to keep a persistent sysctl setting (see #4232) is quite annoying, and this setting must be applied every time WSL2 restarts for the moment. ...

@jakebrinkmann also suggests a valid workaround, although this will reduce MTU for all traffic out of the WSL2 guest, rather than just traffic over the VPN.

PowerShell: netsh interface ipv4 show subinterface # find MTU of VPN interface (e.g. 1400) WSL2: ip link list WSL2: sudo ip link set dev eth0 mtu 1400

Just to re-iterate and expand on what @r-l-x has already described:

In the issue report, it is described that an HTTP request works, but a following HTTPS request to the same server times out. With the assumption there are no firewall/server issues with transport of HTTPS to/from the server, this is a classic symptom of an MTU blackhole.
In my case, I could not see any ICMP "fragmentation needed" messages arriving at the guest. So the issue is due to broken path MTU discovery, leading to an MTU blackhole where any packets larger than the VPN MTU are silently discarded.
The normal behaviour is for an ICMP "fragmentation needed" message to be generated from the egress interface (the VPN) back to the sender, so that it can learn of the constrained MTU and shrink future packets to the destination to the size of this reported MTU.

But this is either not happening at all (bug in windows VPN interface), or this message is being discarded/not forwarded to the WSL2 guest (possibly a bug in Hyper-V virtual switch/nic interface).
Similarly for IPv6 there is an ICMPv6 "packet too big" message, but I don't know if that also suffers from this issue/bug.

This needs to be identified as a bug so that a proper fix may be implemented.

For anyone else experiencing issues - if you find that you are not able to even ping a destination over your VPN from your WSL2 guest, then it is likely you are experiencing a different issue than what is described here.

Bloodcasterjavier commented 3 years ago

sudo ifconfig eth0 mtu 1350

This actually solved the issue for me. I don't even use a VPN and it started happening to me since about a week ago.

Teslenk0 commented 3 years ago

sudo ifconfig eth0 mtu 1350

This actually solved the issue for me. I don't even use a VPN and it started happening to me since about a week ago.

Also fixed the problem for me 🚀

weeezes commented 3 years ago

sudo ip link set dev eth0 mtu 1420 fixes it for me when running with WireGuard on WSL2 Ubuntu, thanks for the tip.

mo-xiaoming commented 3 years ago

This is my solution for:

Pulse Secure VPN

PowerShell: netsh interface ipv4 show subinterface

WSL2: ip link list

WSL2: sudo ip link set dev eth0 mtu 1400

Notes

I ran this after successfully connected to the VPN. I noticed an extra Local Area Connection* with an MTU value ~100 less than the other "Local Area Connection" entries. That's the value I wanted.

Inside WSL2, check what your eth0 mtu value is set to. It was not the MTU value discovered in Step 1.

Inside WSL2, set the MTU value of the interface eth0 to the value discovered in Step 1.

HTTPS IS NOW WORKING 🎉

Thank you! This worked for me.

Unbelievable, finally, a solution works for me

microsoft / WSL