WSL2 fails to make HTTPS connection if Windows is using VPN

[emrahkaya]

• 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.

[libre-x]

Unable to reproduce on 19025.1 with OpenVPN GUI. (am aware it was explicitly mentioned using the built-in VPN client, but just providing this for reference)

[emrahkaya]

Unable to reproduce on 19025.1 with OpenVPN GUI. (am aware it was explicitly mentioned using the built-in VPN client, but just providing this for reference)

Thank you for your attention. However, the VPN server I'm using do not support OpenVPN. It supports IPSec IKEv2 (which built-in VPN uses) and Wireguard. I've also tested the issue with Wireguard (running on Windows, not WSL) but unfortunately the result was the same.

[Einlanzerous]

For what it's worth- I'm having a similar issue with VPN functionality and current insider builds. I'm using Viscosity (1.8.2) and once I connect the VPN, my vEthernet connection for WSL somehow becomes 'unplugged' until I reboot the machine. Shutting down the VM doesn't resolve the issue. My current insider build is 19028.vb_release.191115-1325

[chiefjester]

I'm having a similar issue using Pritunl client. Even if I don't activate it, if my computer sleeps, any connectivity is lost in WSL2. like @Einlanzerous, shutting down the VM doesn't help, logging out doesn't help. I have to restart it. 🤷🏻‍♂️

After uninstalling the Pritunl client, it seems I don't get the intermittent any connection on WSL2.

[ukhwaja]

Same. Using Windows10's built-in VPN with type L2TP/IPsec.
WSL 2 unable to connect to the internet.

Example: apt update fails with:

Temporary failure resolving 'deb.debian.org'

What works:

• Turning off VPN
• Switching back to WSL 1

[emrahkaya]

Thank you for the support.
It still fails with the newest Windows build (19041.1). I did some tests using Wireshark and it looks like, the TLS Handshake fails in the beginning. The ClientHello packet looks intact, while the ClientServer packet looks broken.

[dmerand]

I'm having this same issue using Wireguard / Firefox Private Network, both of which use Mullvad over the Wireguard protocol.

I'm using Windows insider build 19041.1.

I'm not sure if this is relevant, but it looks like Wireguard is changing the route table in WSL. It looks like Wireguard replaces all routes that point to the IP address in /etc/resolv.conf with the Wireguard address:

# no Wireguard:
cat /etc/resolv.conf
# 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 172.22.0.1


netstat.exe -rn

...
IPv4 Route Table
===========================================================================
Active Routes:
Network Destination        Netmask          Gateway       Interface  Metric
          0.0.0.0          0.0.0.0      192.168.0.1      192.168.0.3     35
        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.0.0    255.255.240.0         On-link        172.22.0.1   5256
       172.22.0.1  255.255.255.255         On-link        172.22.0.1   5256
    172.22.15.255  255.255.255.255         On-link        172.22.0.1   5256
     172.27.192.0    255.255.240.0         On-link      172.27.192.1   5256
     172.27.192.1  255.255.255.255         On-link      172.27.192.1   5256
...

# with wireguard (10.99.72.157)
IPv4 Route Table
===========================================================================
Active Routes:
Network Destination        Netmask          Gateway       Interface  Metric
          0.0.0.0          0.0.0.0      192.168.0.1      192.168.0.3     35
          0.0.0.0        128.0.0.0         On-link      10.99.72.157      5
     10.99.72.157 255.255.255.255         On-link      10.99.72.157    261
        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
  127.255.255.255  255.255.255.255         On-link      10.99.72.157    261

[dsmaher]

I also have issue that when Pritunl is connected, I have no connectivity from WSL2. It's important to note that if the VPN profile only forwards private traffic, WSL2 is blocked only for private IPs, but if the profile is forwarding everything, WSL2 can't reach anything.

I have the same issue that as @thisguychris mentioned that WSL2 completely loses connectivity after my laptop sleeps.

[emrahkaya]

Today, (coincidentally) I've tested to install an Ubuntu Server VM using the Hyper-V. Then, I thought that might be the Hyper-V and it's networking that's causing trouble. I made it use the Default Hyper-V switch to make it more distinctive (WSL uses it's own Hyper-V switch).
It turned out that when the VPN is up, the https connections from the VM also ceased. So, that's most likely about how Windows' networking works and it's the one that's causing problem. When I look at the Network adapters page, the VPN is setup as a WAN Miniport, and the Hyper-V adapters are setup as virtual ethernet adapters:

When I look at the properties page of the VPN, one thing I've noticed is that the Security is maintained by using machine certificates, which might be a case, because the VM doesn't have those certificates (Just thinking :) ):

I'll investigate further, but I'll be grateful if some of you can also check both the VPN configuration (if it's similar to mine) and the connectivity from a VM.
Thanks.

[NiklasBr]

I can reproduce the VPN issue with Cisco AnyConnect 4.5.04029, impossible to ping or get data from any domain or IP when active, but works again the moment the VPN connection is disabled.

[sunlin7]

same issue, and the workaround is switch back to WSL1.

[gradinarot]

I would be cool is we don't have to switch back to wsl 1

[pipplo]

I am having the same issue with Cisco AnyConnect and windows build 19564

[blaine]

Any updates to this? I've found WSL1's filesystem increasingly unstable, so am trying to switch to WSL2, but the network does not work with Pulse Secure, either. Same behaviour as described here and elsewhere - the network completely fails to connect, and after activating the VPN, a full shutdown and restart of WSL is required to restore network access.

[ukhwaja]

This issue was finally fixed for me a week ago. Not sure what did it but my combination of usage was as follows:

• Windows inside slow ring (now off) after 19041.xxx
• WSL 2 using Pengwin (Wlinux)
• Windows terminal
• Cyberghost VPN

[emrahkaya]

@blaine, unfortunately, no updates on the problem. But I'm getting the impression that the problem might be about the VPN protocol (i.e. IKEv2) and the authentication method (machine certificates).
@numbfall, I think your problem is solved, because Cyberghost is using a different VPN protocol. It says Cyberghost is supporting "OpenVPN, L2TP-IPsec and PPTP protocols" on their webpage. @numbfall, can you check your VPN settings and tell which type of protocol (OpenVPN, PPTP, etc.) and authentication method (username/password or machine certificate) is used?

Thank you.

[ukhwaja]

@blaine @emrahkaya It's set to use OpenVPN. I have never been able to get IKEv2 to work with my Windows, using the windows built-in VPN settings or Cyberghost client.

However, note that I had the issue described in the title with same VPN protocols (OpenVPN) since WSL 2 came out last year on the slow ring. I had to turn off VPN every time I needed to run apt update or yarn upgrade etc. This was only solved a week ago.

This could very well be a solution from the distro side, maybe... I skimmed the release notes of Pengwin but didn't see anything relevant. So I really don't have a clue what really solved the issue.

[huyen-streamotion]

@emrahkaya I'm using Pulse Secure. Type of VPN is SSTP. In the Authentication section, PAP, CHAP, and MS-CHAPv2 are ticked.

[jondavidschober]

Also having this problem with a Cisco Meraki VPN (L2TP with PAP). Its weird because "most" of the network traffic works fine (SSHing for example), but accessing https://google.com does NOT work, while https://duckduckgo.com DOES work.

I just ran a test.. if the TLS connection is made from inside WSL2 before making it on the host, it does work. But if the host then hits the same site, the connection doesnt work.

Example, in WSL I can hit https://xkcd.com, until I go to https://xkcd.com in a windows browser. Then WSL fails to hit xkcd.com

[NiklasBr]

I just found #416 and tried a few of the suggestions, but was unable to fix this issue.

[emrahkaya]

#416 is more related with the DNS issues. Currently it's easier to fix DNS issues (if any) by just changing the /etc/resolv.conf file and adding
[network]
generateResolvConf = false
to the /etc/wsl.conf file.

However, this issue is more related with a failing TSL handshake issue when using VPN on the host (i.e. Windows). If it was a DNS issue, I wouldn't be able to hit even the http port of packages.microsoft.com (or any other host).

[blaine]

I don't know if a different issue needs to be created, but when I use a windows-side VPN (PulseSecure), all networking in WSL2 fails. I'm unable to reach any hosts, resolve DNS, or make HTTP requests, SSL or not. My workaround is literally to use my Mac.

[adonese]

I'm on insiders fast ring build 19624. The problem is still here. When i'm using wireguard in my windows host, wsl2 can no longer access the internet.

[smerrill]

I have the same issue with the current slow ring build. HTTPS connections while my host machine is on a Cisco Meraki VPN that sends all traffic over it basically time out forever.

[smerrill]

To add some debugging info, I am having this problem with a full-tunnel L2TP/IPSec VPN using a pre-shared key and PAP authentication.

I am on Windows 10 Pro slow ring build 19041.208.

[smerrill]

This really is the weirdest thing, because some HTTPS handshakes work from WSL2 while I'm on the VPN, like so:

$ curl -vvv -sIXGET https://www.apple.com/                                                                                                                                                                                                                                
*   Trying 23.63.229.217:443...                                                                                                                                                                                                                                              
* TCP_NODELAY set                                                                                                                                                                                                                                                            
* Connected to www.apple.com (23.63.229.217) port 443 (#0)                                                                                                                                                                                                                   
* ALPN, offering h2                                                                                                                                                                                                                                                          
* ALPN, offering http/1.1                                                                                                                                                                                                                                                    
* successfully set certificate verify locations:                                                                                                                                                                                                                             
*   CAfile: /etc/ssl/certs/ca-certificates.crt                                                                                                                                                                                                                                 
CApath: /etc/ssl/certs                                                                                                                                                                                                                                                     
* TLSv1.3 (OUT), TLS handshake, Client hello (1):                                                                                                                                                                                                                            
* TLSv1.3 (IN), TLS handshake, Server hello (2):                                                                                                                                                                                                                             
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):                                                                                                                                                                                                                     
* TLSv1.3 (IN), TLS handshake, Certificate (11):                                                                                                                                                                                                                             
* TLSv1.3 (IN), TLS handshake, CERT verify (15):                                                                                                                                                                                                                             
* TLSv1.3 (IN), TLS handshake, Finished (20):                                                                                                                                                                                                                                
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):                                                                                                                                                                                                                  
* TLSv1.3 (OUT), TLS handshake, Finished (20):                                                                                                                                                                                                                               
* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384                                                                                                                                                                                                                      
* ALPN, server accepted to use h2                                                                                                                                                                                                                                            
* Server certificate:                                                                                                                                                                                                                                                        
*  subject: businessCategory=Private Organization; jurisdictionC=US; jurisdictionST=California; serialNumber=C0806592; C=US; ST=California; L=Cupertino; O=Apple Inc.; OU=Internet Services for Akamai; CN=www.apple.com                                                      
*  start date: Oct 24 00:00:00 2019 GMT                                                                                                                                                                                                                                      
*  expire date: Oct 23 12:00:00 2020 GMT                                                                                                                                                                                                                                     
*  subjectAltName: host "www.apple.com" matched cert's "www.apple.com"                                                                                                                                                                                                       
*  issuer: C=US; O=DigiCert Inc; OU=www.digicert.com; CN=DigiCert SHA2 Extended Validation Server CA                                                                                                                                                                         
*  SSL certificate verify ok.                                                                                                                                                                                                                                                
* Using HTTP2, server supports multi-use                                                                                                                                                                                                                                     
* Connection state changed (HTTP/2 confirmed)                                                                                                                                                                                                                                
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0                                                                                                                                                                                             
* Using Stream ID: 1 (easy handle 0x55cfbe9437c0)                                                                                                                                                                                                                            
> GET / HTTP/2                                                                                                                                                                                                                                                               
> Host: www.apple.com                                                                                                                                                                                                                                                        
> user-agent: curl/7.68.0                                                                                                                                                                                                                                                    
> accept: */*                                                                                                                                                                                                                                                                
>                                                                                                                                                                                                                                                                            
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):                                                                                                                                                                                                                        
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):                                                                                                                                                                                                                        
* old SSL session ID is stale, removing                                                                                                                                                                                                                                      
* Connection state changed (MAX_CONCURRENT_STREAMS == 100)!                                                                                                                                                                                                                  
< HTTP/2 200                                                                                                                                                                                                                                                                  

and

$ curl -vvv -sIXGET https://icanhazip.com/
*   Trying 116.202.244.153:443...
* TCP_NODELAY set
* Connected to icanhazip.com (116.202.244.153) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*   CAfile: /etc/ssl/certs/ca-certificates.crt
  CApath: /etc/ssl/certs
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-AES256-GCM-SHA384
* ALPN, server accepted to use h2
* Server certificate:
*  subject: CN=icanhazip.com
*  start date: Apr 27 12:23:46 2020 GMT
*  expire date: Jul 26 12:23:46 2020 GMT
*  subjectAltName: host "icanhazip.com" matched cert's "icanhazip.com"
*  issuer: C=US; O=Let's Encrypt; CN=Let's Encrypt Authority X3
*  SSL certificate verify ok.
* Using HTTP2, server supports multi-use
* Connection state changed (HTTP/2 confirmed)
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
* Using Stream ID: 1 (easy handle 0x564d363bf7c0)
> GET / HTTP/2
> Host: icanhazip.com
> user-agent: curl/7.68.0
> accept: */*
>
* Connection state changed (MAX_CONCURRENT_STREAMS == 128)!
< HTTP/2 200

But others, like the Microsoft sample related above do not:

$ curl -vvv -sIXGET https://packages.microsoft.com/ubuntu/18.04/prod
*   Trying 40.117.131.251:443...
* TCP_NODELAY set
* Connected to packages.microsoft.com (40.117.131.251) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*   CAfile: /etc/ssl/certs/ca-certificates.crt
  CApath: /etc/ssl/certs
* TLSv1.3 (OUT), TLS handshake, Client hello (1):

* OpenSSL SSL_connect: Connection reset by peer in connection to packages.microsoft.com:443
* Closing connection 0

But HTTPS connections to all three of these work from the Windows host when on the VPN.

[emrahkaya]

@smerrill That was a great catch.

After seeing the TLSv1.3 to TLSv1.2 change in your icanhazip.com log, I started thinking that it can related with TLS version.
And tried several other servers to confirm that. The result is if the server supports TLS v1.3, then the handshake is successful, otherwise it doesn't work.
You can check other servers' TLS support from https://www.cdn77.com/tls-test, and try to connect from WSL.
For my case, packages.microsoft.com doesn't support TLS v1.3, so handshake doesn't work.
Interestingly, apple.com doesn't support TLS v1.3 and doesn't work; but www.apple.com supports v1.3 and works.
Btw, for me icanhazip.com didn't work either, because it doesn't support v1.3.

I also tried to force curl to use v1.2 by setting --tlsv1.2 and --tls-max 1.2 parameters, but it didn't work:

curl --tlsv1.2 --tls-max 1.2 -vvv -sIXGET https://packages.microsoft.com/ubuntu/18.04/prod
*   Trying 13.79.133.120...
* TCP_NODELAY set
* Connected to packages.microsoft.com (13.79.133.120) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*   CAfile: /etc/ssl/certs/ca-certificates.crt
  CApath: /etc/ssl/certs
* TLSv1.2 (OUT), TLS handshake, Client hello (1):

# .... waits forever ...

So, I think the problem is now a bit more focused, but I still don't know why it behaves this way.

[smerrill]

Yeah - agreed. It's interesting that the way I initially found this was that I tried to run code . in my WSL2 VM, and the VSCode server component simply wouldn't download, leading me to Google for this.

[RichiCoder1]

Adding on to the pile, I can confirm that Cisco AnyConnect VPN 4.8 appears to break most connectivity within WSL 2.

[vvaltchev]

I believe I have a very similar problem.
WSL2 on Windows 11 and GlobalProtect as VPN.

After sleep or hibernation, the SSH connection is completely stuck and none of the suggestions here worked in my case. Changing the MTU has no effect at all. The ssh client is stuck on a select() syscall and the only way to exit from there is being killed manually with kill <PID>.

The correct behavior should be the connection to be just dropped (e.g. the select() call should just return with an error). For some reason, probably related with the fact that WSL tries to re-establish the connections now, that doesn't happen.

[aradalvand]

No updates on this one yet?! I've been beating my head against the wall for a number of hours, not being able to find out exactly why a simple cURL request wasn't working, I randomly stumbled into this issue after giving up on trying to solve the problem, turns out it was the freaking VPN.

It's been a year and a half since this issue was created, would've been nice if we could get some updates from the maintainers.

[samhrncir]

My Usecase:
I am using WSL2 on Windows 11. Wireguard is the VPN that I am using.
I am using WSL2 with the tool DDev for running a local Drupal environment that is entirely open source.

1st problem encountered:
curl https://packages.drupal.org/8/packages.json
curl: (6) Could not resolve host: packages.drupal.org

Solution:
(Within WSL)

1. cd /etc/
2. sudo chattr -i resolv.conf
3. rm -r resolv.conf
4. sudo echo 'nameserver 1.1.1.1' >resolv.conf
5. sudo chattr +i resolv.conf
6. sudo echo -e '[network] \ngenerateResolvConf = false' >> /etc/wsl.conf

2nd problem encountered:
I then was experiencing the same behavior as below... Though instead of https://packages.microsoft.com/ubuntu/18.04/prod, https://packages.drupal.org/8/packages.json was timing out at the same spot.

This really is the weirdest thing, because some HTTPS handshakes work from WSL2 while I'm on the VPN, like so:

$ curl -vvv -sIXGET https://www.apple.com/                                                                                                                                                                                                                                
*   Trying 23.63.229.217:443...                                                                                                                                                                                                                                              
* TCP_NODELAY set                                                                                                                                                                                                                                                            
* Connected to www.apple.com (23.63.229.217) port 443 (#0)                                                                                                                                                                                                                   
* ALPN, offering h2                                                                                                                                                                                                                                                          
* ALPN, offering http/1.1                                                                                                                                                                                                                                                    
* successfully set certificate verify locations:                                                                                                                                                                                                                             
*   CAfile: /etc/ssl/certs/ca-certificates.crt                                                                                                                                                                                                                                 
CApath: /etc/ssl/certs                                                                                                                                                                                                                                                     
* TLSv1.3 (OUT), TLS handshake, Client hello (1):                                                                                                                                                                                                                            
* TLSv1.3 (IN), TLS handshake, Server hello (2):                                                                                                                                                                                                                             
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):                                                                                                                                                                                                                     
* TLSv1.3 (IN), TLS handshake, Certificate (11):                                                                                                                                                                                                                             
* TLSv1.3 (IN), TLS handshake, CERT verify (15):                                                                                                                                                                                                                             
* TLSv1.3 (IN), TLS handshake, Finished (20):                                                                                                                                                                                                                                
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):                                                                                                                                                                                                                  
* TLSv1.3 (OUT), TLS handshake, Finished (20):                                                                                                                                                                                                                               
* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384                                                                                                                                                                                                                      
* ALPN, server accepted to use h2                                                                                                                                                                                                                                            
* Server certificate:                                                                                                                                                                                                                                                        
*  subject: businessCategory=Private Organization; jurisdictionC=US; jurisdictionST=California; serialNumber=C0806592; C=US; ST=California; L=Cupertino; O=Apple Inc.; OU=Internet Services for Akamai; CN=www.apple.com                                                      
*  start date: Oct 24 00:00:00 2019 GMT                                                                                                                                                                                                                                      
*  expire date: Oct 23 12:00:00 2020 GMT                                                                                                                                                                                                                                     
*  subjectAltName: host "www.apple.com" matched cert's "www.apple.com"                                                                                                                                                                                                       
*  issuer: C=US; O=DigiCert Inc; OU=www.digicert.com; CN=DigiCert SHA2 Extended Validation Server CA                                                                                                                                                                         
*  SSL certificate verify ok.                                                                                                                                                                                                                                                
* Using HTTP2, server supports multi-use                                                                                                                                                                                                                                     
* Connection state changed (HTTP/2 confirmed)                                                                                                                                                                                                                                
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0                                                                                                                                                                                             
* Using Stream ID: 1 (easy handle 0x55cfbe9437c0)                                                                                                                                                                                                                            
> GET / HTTP/2                                                                                                                                                                                                                                                               
> Host: www.apple.com                                                                                                                                                                                                                                                        
> user-agent: curl/7.68.0                                                                                                                                                                                                                                                    
> accept: */*                                                                                                                                                                                                                                                                
>                                                                                                                                                                                                                                                                            
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):                                                                                                                                                                                                                        
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):                                                                                                                                                                                                                        
* old SSL session ID is stale, removing                                                                                                                                                                                                                                      
* Connection state changed (MAX_CONCURRENT_STREAMS == 100)!                                                                                                                                                                                                                  
< HTTP/2 200                                                                                                                                                                                                                                                                  

and

$ curl -vvv -sIXGET https://icanhazip.com/
*   Trying 116.202.244.153:443...
* TCP_NODELAY set
* Connected to icanhazip.com (116.202.244.153) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*   CAfile: /etc/ssl/certs/ca-certificates.crt
  CApath: /etc/ssl/certs
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-AES256-GCM-SHA384
* ALPN, server accepted to use h2
* Server certificate:
*  subject: CN=icanhazip.com
*  start date: Apr 27 12:23:46 2020 GMT
*  expire date: Jul 26 12:23:46 2020 GMT
*  subjectAltName: host "icanhazip.com" matched cert's "icanhazip.com"
*  issuer: C=US; O=Let's Encrypt; CN=Let's Encrypt Authority X3
*  SSL certificate verify ok.
* Using HTTP2, server supports multi-use
* Connection state changed (HTTP/2 confirmed)
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
* Using Stream ID: 1 (easy handle 0x564d363bf7c0)
> GET / HTTP/2
> Host: icanhazip.com
> user-agent: curl/7.68.0
> accept: */*
>
* Connection state changed (MAX_CONCURRENT_STREAMS == 128)!
< HTTP/2 200

But others, like the Microsoft sample related above do not:

$ curl -vvv -sIXGET https://packages.microsoft.com/ubuntu/18.04/prod
*   Trying 40.117.131.251:443...
* TCP_NODELAY set
* Connected to packages.microsoft.com (40.117.131.251) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*   CAfile: /etc/ssl/certs/ca-certificates.crt
  CApath: /etc/ssl/certs
* TLSv1.3 (OUT), TLS handshake, Client hello (1):

* OpenSSL SSL_connect: Connection reset by peer in connection to packages.microsoft.com:443
* Closing connection 0

But HTTPS connections to all three of these work from the Windows host when on the VPN.

Like many others before, my issue now was that the MTU value of WSL did not match the MTU value of my VPN interface.

Solution:

1. Figure out the MTU of your VPN.
   C:\WINDOWS\system32>netsh interface ipv4 show subinterface
   Mine was 1420. Everything else was set to 1500.

2. In WSL, See your network interfaces with ifconfig.
   set the eth0 interface to match the VPN's MTU value.
   sudo ifconfig eth0 mtu 1420

[evakili]

I'm not using VPNs for connecting to the Internet (although I have some installed), and I face the same problem in some of my WSL distros (Debian and Ubuntu), and not in others (CentOS).

The problem did not been solved by changing MTU. My NIC drivers are seemed to be updated.

[akhfa]

For me, only pritunl wireguard that make the ubuntu WSL cannot connect from VPN. Pritunl openvpn still can connect as usual

[SkeletonMan2k21]

sudo ip link set dev eth0 mtu 1400
This solved it for me.

[ishworg]

Are there any words from the wsl2 folks? if not, would love to see a mitigation. thanks.

[gc250274]

Open windows firewall and add wsl application and check all the boxes and restart the computer.
This solved my connection issue.

[Zk2u]

Note for anyone using Tailscale on Windows & in wsl having this issue (run in wsl):

sudo ip link set dev eth0 mtu 1280
# and the below if still not working...
sudo ip link set dev tailscale0 mtu 1280

This is working for me when running Tailscale in both WSL and Windows, using an exit node on Windows

[speller]

The MTU workaround for the eth0 interface has fixed the issue in my case. I had to set it to 1230.

[speller]

To everyone looking for a proper MTU value in your case. You may use the ping command:

ping -s 1500 google.com

Start from 1500 and decrease by 10 until pings will pass. The value in the -s parameter will be your MTU value for the sudo ip link set dev eth0 mtu <value> command.

The method from #4698 (comment) didn't work in my case. The VPN's MTU was 1400 but the maximum working MTU value in WSL was 1230.

[speller]

WSL's eth0 MTU is changed to some non-working value every time you connect to the VPN. So you need to fix MTU after every connection.

[speller]

Does anyone know how to execute a script when a VPN connection is created? Or how can we customize the MTU value that Windows sets on eth0 when VPN is connected?

[speller]

I've solved this issue with a scheduler task that updates the MTU value. I'm using the standard Windows VPN client.

Here are the config values for it:

Begin the task: On an event
Log: Application
Source: RasClient
Event ID: 20225
Action: Start a program
Program: wsl
Add arguments: -u root ip link set dev eth0 mtu 1230

Here are the task screenshots:

Adjust the MTU value for your case.

[dgreenwald-ccs]

Have you tried https://github.com/sakai135/wsl-vpnkit

[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.

[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!)

[Qtax]

@craigloewen-msft do you know if networkingMode=mirrored will be available on Windows 10?

[vbdavisas]

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!)

right on, thanks craig.

[OneBlue]

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

If the issue still remains, please reopen this issue.

[Petros626]

I did the following, which worked for me (Windows 10 & WSL2):

1. sudo nano /etc/ssh/ssh_config
2. Under section Host* add ServerAliveInterval 5 (I guess any value is okay?)
3. sudo nano /etc/ssh/sshd_config
4. Near the end of the file search for: ClientAliveInterval 60; TCPKeepAlive yes; ClientAliveCountMax 10000
5. service ssh restart
6. ssh [email protected]