search

microsoft / WSL

Issues found on WSL
https://docs.microsoft.com/windows/wsl
MIT License
17.46k stars 822 forks source link

WSL2 fails to make HTTPS connection if Windows is using VPN #4698

Closed emrahkaya closed 6 months ago

emrahkaya commented 4 years ago
libre-x commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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:

emrahkaya commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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: explorer_2020-01-20_01-12-26

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 :) ): image

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 commented 4 years ago

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 commented 4 years ago

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

gradinarot commented 4 years ago

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

pipplo commented 4 years ago

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

blaine commented 4 years ago

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 commented 4 years ago

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

emrahkaya commented 4 years ago

@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? image Thank you.

ukhwaja commented 4 years ago

@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 commented 4 years ago

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

jondavidschober commented 4 years ago

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 commented 4 years ago

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

emrahkaya commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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.

image

I am on Windows 10 Pro slow ring build 19041.208.

smerrill commented 4 years ago

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 commented 4 years ago

@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 commented 4 years ago

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 commented 4 years ago

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

emrahkaya commented 4 years ago

@smerrill , if you could find this issue via Google, maybe some devs from WSL or Hyper-V would also notice this issue, too. šŸ˜„

jondavidschober commented 4 years ago

I was not able to reproduce TLS1.3 vs TLS1.2 behavior. www.google.com is often a domain that I have this issue with and it supports TLS1.3

DJAlPee commented 4 years ago

Not sure, if it's a TLS1.3 issue...

I'm using a Cisco Meraki VPN (L2TP), And have no problems with apple.com, www.apple.com, and icanhazip.com. Only problem is with packages.microsoft.com, www.google.com and sometimes (!) with raw.githubusercontent.com.

neseih commented 4 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.

emrahkaya commented 4 years ago

@neseih , thank you alot, great solution. With a bit of trial and error I found my setting can be set to 1440 at max. BUT, I really wonder why and how this works?

blaine commented 4 years ago

Sadly, changing the mtu doesn't fix networking when using PulseSecure.

$ sudo ifconfig eth0 mtu 1350
$ ping 172.217.11.46
PING 172.217.11.46 (172.217.11.46) 56(84) bytes of data.
^C
--- 172.217.11.46 ping statistics ---
18 packets transmitted, 0 received, 100% packet loss, time 17701ms
NiklasBr commented 4 years ago

Glad it works for some, but I was unable to get this to work with the same MTU as Cisco AnyConnect was configured to use.

emrahkaya commented 4 years ago

@blaine , in fact the problem was about HTTPS handshaking. In your case, the problem seems different, because you cannot even ping the server. In my case, the IP of the server was the same, only difference was the https. Thus, pinging was never a problem. @NiklasBr , did you try smaller mtu values?

NiklasBr commented 4 years ago

@emrahkaya Lowering it to 1280 didn't work either

PS C:\WINDOWS\system32> .\netsh.exe interface ipv4 show interfaces

Idx     Met         MTU          State                Name
---  ----------  ----------  ------------  ---------------------------
 17          25        1500  connected     Ethernet
 23          25        1500  disconnected  Local Area Connection* 1
 20          25        1500  disconnected  Local Area Connection* 10
 22           1        1406  connected     Ethernet 2
 48          15        1500  connected     vEthernet (Default Switch)
 60          15        1500  connected     vEthernet (WSL)

And in WSL:

$ ifconfig eth0
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1280
        inet 172.-.-.-  netmask 255.255.240.0  broadcast 172.-.-.-
        inet6 fe80::215:5dff:feec:f70e  prefixlen 64  scopeid 0x20<link>
        ether 00:15:5d:ec:f7:0e  txqueuelen 1000  (Ethernet)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 10  bytes 788 (788.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
emrahkaya commented 4 years ago

@NiklasBr , look like none of ours setups are the same :) In my case, the output of netsh.exe interface ipv4 show interfaces is different than your on Windows. The MTU of Ethernet connection that goes to my router is 1500 and the MTU of vEthernet (WSL) is 65536. I've never specially configured them. Maybe you can try to increase the MTU of those connections on the Windows side.

jondavidschober commented 4 years ago

MTU solution worked perfectly for me. My MTU for my VPN connection is 1400, while my other connections are 1500. I set the linux MTU to 1400 to match my VPN and it works

LeslieK commented 4 years ago

@NiklasBr I'm also using Cisco AnyConnect for connecting windows to vpn. If you find a solution, please post here. Thank you.

NiklasBr commented 4 years ago

@LeslieK I'm sorry I have not been able to get any further, I have experimenting with a lot of MTU values but nothing has gone through.

LeslieK commented 4 years ago

@NiklasBr change your vpn client to openconnect-gui for windows. It works perfectly. install on windows. connect to your vpn. windows in connected. linux is connected. no dns issues on linux. no speed degradation that I can notice. omg. this is great. root cause of issue: wsl2 doesn't work with cisco anyconnect client. https://openconnect.github.io/openconnect-gui/

smerrill commented 4 years ago

Unfortunately, I can't convince our IT department to switch VPNs since we've invested heavily in Meraki products, and I bet a lot of folks here can't either.

roniburd commented 4 years ago

There seems to be 3 issues as far as I can tell, all of them different depending on the VPN client. The 3 issues are: 1) WSL not using the VPN interface. A solution that might work is doing this in PS: Get-NetAdapter | Where-Object {$_.InterfaceDescription -Match "Cisco AnyConnect"} | Set-NetIPInterface -InterfaceMetric 6000 . You can check if this works by going to your linux account and trying to ping an IP directly. 2) DNS resolution. If #1 solved the issue, you still might find that DNS resolution is not changed. Fro that, you need to modify /etc/resolv.conf and add nameserver 3) If both of the above dont work, you still need to fix MTU size mismatch. This is changed by using sudo ifconfig eth0 mtu 1350 , wheer 1350 is a similar value to what you see by running .\netsh.exe interface ipv4 show interfaces

NiklasBr commented 4 years ago

@LeslieK

change your vpn client to

Our IT department mandates Cisco, and a specific version at that. I have no choice but to use it.

nadddy commented 4 years ago

I was able to get ssh working with following fix (3) provided by @roniburd . I did not have to make any other changes. Thanks @roniburd

There seems to be 3 issues as far as I can tell, all of them different depending on the VPN client. The 3 issues are:

1. WSL not using the VPN interface. A solution that might work is doing this in PS: Get-NetAdapter | Where-Object {$_.InterfaceDescription -Match "Cisco AnyConnect"} | Set-NetIPInterface -InterfaceMetric 6000 . You can check if this works by going to your linux account and trying to ping an IP directly.

2. DNS resolution. If #1 solved the issue, you still might find that DNS resolution is not changed. Fro that, you need to modify  /etc/resolv.conf and add nameserver

3. If both of the above dont work, you still need to fix MTU size mismatch. This is changed by using sudo ifconfig eth0 mtu 1350 , wheer 1350 is a similar value to what you see by running .\netsh.exe interface ipv4 show interfaces
nezorflame commented 4 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.

Thanks @neseih! My connection in WSL2 is now alive using Mullvad with MTU of 1350 (in Wireguard mode).

NiklasBr commented 4 years ago

I'm unable to use the fix from @roniburd with Cisco Anyconnect:

image

Also:

PS C:\WINDOWS\system32> Get-NetAdapter | Where-Object {$_.InterfaceDescription -Match "Cisco AnyConnect"}

Name                      InterfaceDescription                    ifIndex Status       MacAddress             LinkSpeed
----                      --------------------                    ------- ------       ----------             ---------
Ethernet 2                Cisco AnyConnect Secure Mobility Cli...      25 Up           ..-..-..-..-..-00       995 Mbps
roniburd commented 4 years ago

I'm unable to use the fix from @roniburd with Cisco Anyconnect:

image

Also:

PS C:\WINDOWS\system32> Get-NetAdapter | Where-Object {$_.InterfaceDescription -Match "Cisco AnyConnect"}

Name                      InterfaceDescription                    ifIndex Status       MacAddress             LinkSpeed
----                      --------------------                    ------- ------       ----------             ---------
Ethernet 2                Cisco AnyConnect Secure Mobility Cli...      25 Up           ..-..-..-..-..-00       995 Mbps

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