Unable to access any private IP (Cisco Anyconnect VPN) from WSL2 only

[firas-aschkar]

Windows Version

10.0.26100.7171

WSL Version

2.6.1.0

Are you using WSL 1 or WSL 2?

• [x] WSL 2
• [ ] WSL 1

Kernel Version

6.6.87.2-1

Distro Version

Ubuntu 20.04

Other Software

No response

Repro Steps

1. start Cisco Anyconnect VPN on Windows
2. launch WSL2 ( networking mode set to mirrored in .wslconfig file)
3. From WSL2, ping any private IP address of the VPN, It does not work:

dev@pc1:~$ ping -c 4 192.168.222.75
PING 192.168.222.75 (192.168.222.75) 56(84) bytes of data.
From 192.168.119.224 icmp_seq=1 Destination Host Unreachable
From 192.168.119.224 icmp_seq=2 Destination Host Unreachable
From 192.168.119.224 icmp_seq=3 Destination Host Unreachable
From 192.168.119.224 icmp_seq=4 Destination Host Unreachable
--- 192.168.222.75 ping statistics ---
4 packets transmitted, 0 received, +4 errors, 100% packet loss, time 3129ms
pipe 3
dev@pc1:~$ 

4. pinging same private IP from windows terminal works!

PS C:\Users> ping 192.168.222.75
Pinging 192.168.222.75 with 32 bytes of data:
Reply from 192.168.222.75: bytes=32 time=21ms TTL=63
Reply from 192.168.222.75: bytes=32 time=16ms TTL=63
Reply from 192.168.222.75: bytes=32 time=21ms TTL=63
Reply from 192.168.222.75: bytes=32 time=14ms TTL=63

Expected Behavior

pinging private VPN IP should have worked on WSL2. Note: There was no issue before, i.e. it used to work before the latest Windows11 Update

Actual Behavior

pinging private VPN IP not working on WSL2 only

Diagnostic Logs

No response

[github-actions[bot]]

Logs are required for review from WSL team

If this a feature request, please reply with '/feature'. If this is a question, reply with '/question'. Otherwise, please attach logs by following the instructions below, your issue will not be reviewed unless they are added. These logs will help us understand what is going on in your machine.

How to collect WSL logs

Download and execute collect-wsl-logs.ps1 in an administrative powershell prompt:

Invoke-WebRequest -UseBasicParsing "https://raw.githubusercontent.com/microsoft/WSL/master/diagnostics/collect-wsl-logs.ps1" -OutFile collect-wsl-logs.ps1
Set-ExecutionPolicy Bypass -Scope Process -Force
.\collect-wsl-logs.ps1

The script will output the path of the log file once done.

If this is a networking issue, please use collect-networking-logs.ps1, following the instructions in Collect WSL logs for networking issues

Once completed please upload the output files to this GitHub issue.

See Collect WSL logs (recommended method).

If you choose to email these logs instead of attaching them to the bug, please send them to [email protected] with the GitHub issue number in the subject, and include a link to your GitHub issue comment in the message body, and reply with '/emailed-logs'.

[patryksliwinski]

Same issue since friday. it always worked for me i'm using wsl with following settings

[wsl2]
dnsTunneling=true
autoProxy=true
networkingMode=mirrored

[firas-aschkar]

WslLogs-2025-11-24_08-37-24.zip

[github-actions[bot]]

Diagnostic information

.wslconfig found
	Custom kernel found: 'C:\bzImage'
Detected appx version: 2.6.1.0

[jarockja]

I have a similar behaviour since a few days with the same kernel version and Ubuntu 24.04. The difference to the initial problem description is, that my system always switches between "Destination Host Unreachable" and a successful ping:

ping 10.49.139.237
PING 10.49.139.237 (10.49.139.237) 56(84) bytes of data.
64 bytes from 10.49.139.237: icmp_seq=1 ttl=63 time=23.8 ms
64 bytes from 10.49.139.237: icmp_seq=2 ttl=63 time=26.5 ms
64 bytes from 10.49.139.237: icmp_seq=3 ttl=63 time=25.8 ms
64 bytes from 10.49.139.237: icmp_seq=4 ttl=63 time=25.6 ms
64 bytes from 10.49.139.237: icmp_seq=5 ttl=63 time=26.1 ms
From 10.49.143.95 icmp_seq=6 Destination Host Unreachable
From 10.49.143.95 icmp_seq=7 Destination Host Unreachable
From 10.49.143.95 icmp_seq=8 Destination Host Unreachable
From 10.49.143.95 icmp_seq=9 Destination Host Unreachable
From 10.49.143.95 icmp_seq=10 Destination Host Unreachable
From 10.49.143.95 icmp_seq=11 Destination Host Unreachable
From 10.49.143.95 icmp_seq=12 Destination Host Unreachable
From 10.49.143.95 icmp_seq=13 Destination Host Unreachable
From 10.49.143.95 icmp_seq=14 Destination Host Unreachable
From 10.49.143.95 icmp_seq=15 Destination Host Unreachable
From 10.49.143.95 icmp_seq=16 Destination Host Unreachable
...
From 10.49.143.95 icmp_seq=120 Destination Host Unreachable
From 10.49.143.95 icmp_seq=121 Destination Host Unreachable
From 10.49.143.95 icmp_seq=122 Destination Host Unreachable
64 bytes from 10.49.139.237: icmp_seq=124 ttl=63 time=460 ms
64 bytes from 10.49.139.237: icmp_seq=123 ttl=63 time=1484 ms
64 bytes from 10.49.139.237: icmp_seq=125 ttl=63 time=24.3 ms
64 bytes from 10.49.139.237: icmp_seq=126 ttl=63 time=25.1 ms
64 bytes from 10.49.139.237: icmp_seq=127 ttl=63 time=25.4 ms
64 bytes from 10.49.139.237: icmp_seq=128 ttl=63 time=26.0 ms
64 bytes from 10.49.139.237: icmp_seq=129 ttl=63 time=24.9 ms
64 bytes from 10.49.139.237: icmp_seq=130 ttl=63 time=25.4 ms
64 bytes from 10.49.139.237: icmp_seq=131 ttl=63 time=25.5 ms
64 bytes from 10.49.139.237: icmp_seq=132 ttl=63 time=27.0 ms
64 bytes from 10.49.139.237: icmp_seq=133 ttl=63 time=28.9 ms
64 bytes from 10.49.139.237: icmp_seq=134 ttl=63 time=25.5 ms
64 bytes from 10.49.139.237: icmp_seq=135 ttl=63 time=27.0 ms
64 bytes from 10.49.139.237: icmp_seq=136 ttl=63 time=23.2 ms
64 bytes from 10.49.139.237: icmp_seq=137 ttl=63 time=24.0 ms
64 bytes from 10.49.139.237: icmp_seq=138 ttl=63 time=24.5 ms
64 bytes from 10.49.139.237: icmp_seq=139 ttl=63 time=24.7 ms
64 bytes from 10.49.139.237: icmp_seq=140 ttl=63 time=25.7 ms
64 bytes from 10.49.139.237: icmp_seq=141 ttl=63 time=24.2 ms
64 bytes from 10.49.139.237: icmp_seq=142 ttl=63 time=24.6 ms
64 bytes from 10.49.139.237: icmp_seq=143 ttl=63 time=25.4 ms
64 bytes from 10.49.139.237: icmp_seq=144 ttl=63 time=25.6 ms
64 bytes from 10.49.139.237: icmp_seq=145 ttl=63 time=26.5 ms
64 bytes from 10.49.139.237: icmp_seq=146 ttl=63 time=24.5 ms
64 bytes from 10.49.139.237: icmp_seq=147 ttl=63 time=25.4 ms
64 bytes from 10.49.139.237: icmp_seq=148 ttl=63 time=23.7 ms
64 bytes from 10.49.139.237: icmp_seq=149 ttl=63 time=24.8 ms
64 bytes from 10.49.139.237: icmp_seq=150 ttl=63 time=25.8 ms
64 bytes from 10.49.139.237: icmp_seq=151 ttl=63 time=26.9 ms
From 10.49.143.95 icmp_seq=152 Destination Host Unreachable
From 10.49.143.95 icmp_seq=153 Destination Host Unreachable
From 10.49.143.95 icmp_seq=154 Destination Host Unreachable
From 10.49.143.95 icmp_seq=155 Destination Host Unreachable
...

[illegal]

This might be related to #13724

[firas-aschkar]

@illegal tried adding static arp entries but that did not help!

dev@pc1:~$ sudo arp -s 192.168.222.75 11:22:33:44:55:66 -i eth0

[yongzhang]

same issue, didn't change anything but network is broken recently

[Deividhp13]

Same issue here, just remove the update and it's working again, but I'm forced to update because it's a corporate laptop...

[sudo-tee]

Same issue since the last windows update 26100.7171

I cannot rollback the windows update as it's a corporate laptop

[dsolanki-aeris]

Same issue started last week. It was always working even without mirroring the host network but not now and can't revert the update due to corporate system.

[Turgaud88]

similar problem, I was sure that this was just my problem, but as I see it, no.

[llaros]

Same here I believe 24H2 update (KB5068861) (26100.7171) caused the issue. I've been using default (nat) networkMode for 4 years, however since its not working anymore I also tried mirrored but with no success (probably due to some corpo policy). I cannot connect on ICMP or TCP/telnet level using raw ip address (it's not a DNSissue) from wsl container (from windows it works).

I've tried so many different settings in .wslconfig, and other workarounds like interface metrics, restarting different services (hns, WSLService), winsock reset, enabling forwarding for interfaces, reinstalling wsl feature.

Once it worked when I've connected via hotspot from my phone but I cannot replicate that any more.

[omarmciver]

I’m seeing a reproducible variant of this problem that appears to be caused by WSL2 failing to update its ARP/neighbor table after Cisco Secure Client reconnects. Windows itself routes correctly through the VPN, but WSL2 loses the ability to reach the VPN gateway until a manual ARP repair is performed inside WSL.

Symptoms

• Windows can reach VPN internal hosts normally.
• WSL2 cannot reach any private IP or even the VPN gateway after a reconnect or policy update.
• ip neigh show <gateway> inside WSL reports INCOMPLETE.
• Pings/timeouts suggest L2 resolution failure, not firewall or DNS.
• All of this immediately resolves if a static ARP entry is injected into WSL’s ip neigh table.

Root cause (likely)

It looks like WSL2 is not learning (or re-learning) the ARP entry for the VPN gateway when Cisco Secure Client reconnects. Meanwhile Windows has the correct neighbor entry and routing table.

Minimal reproducible sequence

1. Connect to Cisco Secure Client (AnyConnect / Secure Client 5.x).
2. Confirm Windows can reach internal hosts.
3. WSL2: ping <gateway> → fails
4. ip neigh show <gateway> → INCOMPLETE
5. Run the workaround below → connectivity instantly restored.

Workaround

I wrote a small PowerShell script that:

1. Identifies the active Cisco VPN adapter.
2. Reads the VPN gateway from the Windows routing table.
3. Extracts the correct MAC address from Windows via Get-NetNeighbor.
4. Pushes that entry into WSL using ip neigh replace ... nud permanent.

After that, WSL2 networking works perfectly until the next VPN reconnect (at which point WSL loses ARP again).

Why this matters

This strongly suggests:

• Windows updates ARP correctly after the VPN reconnect
• WSL2’s virtual NIC does not
• The issue is not DNS, split tunnel, metrics, firewall, or routing
• It’s specifically the neighbor discovery layer inside WSL2 not tracking changes made on the host

This aligns with recent reports (#13776 and several older VPN-related networking bugs), but this case isolates the failure cleanly to ARP.

Gist with workaround

I’ve posted my updated script here:
https://gist.github.com/omarmciver/ec586c0a7de290730f4e7181920cc338

The script discovers the gateway via the active Cisco route and inserts the static ARP entry. This may help others confirm the issue or provide additional debugging data.

Request

It would be extremely helpful if WSL2 could:

• Re-synchronize its neighbor table when Windows updates the ARP entry
• Or provide an API/event to notify WSL of interface changes after VPN reconnects
• Or expose an official hook for L2 propagation from the host

Please let me know if you want packet captures, logs, or traces — I can reproduce this 100% of the time.

Thanks!

[firas-aschkar]

@omarmciver the script aborted with an error message !

Windows PowerShell
Copyright (C) Microsoft Corporation. All rights reserved.

Install the latest PowerShell for new features and improvements! https://aka.ms/PSWindows

PS C:\WINDOWS\system32> cd C:\Users\dev\Downloads\
PS C:\Users\dev\Downloads> .\wsl-vpn-arp-fix.ps1

=== Fix WSL VPN (Adapter-based ARP Sync) ===
VPN Adapter: Ethernet 2 (Cisco AnyConnect Virtual Miniport Adapter for Windows x64)
ERROR: No default route found on Cisco adapter.
PS C:\Users\dev\Downloads>

[omarmciver]

What is the name of your VPN adapter in Windows. The script tried to find it by name.

Sorry, I read it properly this time... The script assumes there is a default route. You could hard code that if it's static in your environment. Look at your route table in Windows. Seems strange there is no default route for the VPN adapter. Is it connected?

[firas-aschkar]

What is the name of your VPN adapter in Windows. The script tried to find it by name.

Sorry, I read it properly this time... The script assumes there is a default route. You could hard code that if it's static in your environment. Look at your route table in Windows. Seems strange there is no default route for the VPN adapter. Is it connected?

yes it is connected

PS C:\Users\dev\Downloads> ping 192.168.222.75

Pinging 192.168.222.75 with 32 bytes of data:
Reply from 192.168.222.75: bytes=32 time=17ms TTL=63
Reply from 192.168.222.75: bytes=32 time=17ms TTL=63
Reply from 192.168.222.75: bytes=32 time=25ms TTL=63
Reply from 192.168.222.75: bytes=32 time=35ms TTL=63

Ping statistics for 192.168.222.75:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 17ms, Maximum = 35ms, Average = 23ms
PS C:\Users\dev\Downloads>

not sure why there is no default route for Cisco VPN adapter !

[llaros]

@omarmciver Thank you for the script. Unfortunatelly it doesn't work. This line is causing a problem: "ip route show default | grep '$gatewayIP' | awk '{print \$5}'"`

I removed the backslash and a special character but this returns an empty line as my setup is running WSL with networkMode=nat (default). I have different NAT gateway vs gateway for cisco interface.

Since I have systemd enabled in my WSL I see a problem with sudo service systemd-networkd status:

systemd-networkd[88]: rtnl: received neighbor for link '7' we don't know about, ignoring. So generally your post is related to my setup.

[llaros]

I confirm that reverting this 24H2 update (KB5068861) (26100.7171) made WSL network working again. (networkMode=nat)

[omarmciver]

@llaros Thanks for confirming. I apologize if I skewed the conversation with my revelation. I switched to Mirrored specifically because with NAT I couldn't get any connectivity at all due the to VPN adapter blocking and having no control over split networking.

I found in Mirrored mode it would work, but only for a time - then DNS would be fine (I guess cached/local) but no packets could route to anywhere. Very unstable. That's when I discovered that on reconnect (the obvious one), silent reconnect (temporary background connection drop) and policy updates - WSL would still have all the correct routing to work with the VPN adapter but the ARP table was missing the entry for that adapter and it's gateway.

Happy you've got a temporary rollback solution. Unsure if there is a common cause at the bottom of NAT and Mirrored, so this is either helpful or another log on the fire.

[llaros]

@omarmciver I would use mirrored provided it would work, unfortunatelly I've got no network inside WSL with msg "Network Host Unreachable", but maybe this will be resolved by your script. I'll check it immediatelly when I loose my networking again.

Could you elaborate what message you've got when

WSL2: ping → fails

[omarmciver]

It's likely the same thing. I get Destination Unreachable. So normally that would mean you have an IP address that is not routable. When you check the ip route table, you will see a pathway to follow, however if you check the ARP table, you'll find that route broken (can't recall if it was invalid MAC or missing). The script I have uses Windows to lookup the correct Gateway IP and MAC from the VPN and then sets it as a static ARP entry in WSL, restoring the route.

[llaros]

My windows was updated to 26100.7171 again and unfortunatelly I've lost network in WSL with default networkMode=nat. I'm trying mirrored but it does not work due to policy of HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip6\Parameters\DisabledComponents set to FF My WSL does not get any eth* interface with network mode mirrored...

I see that netsh dump showed much more entries for the workstation where it works.

Is there any workaround or fix for this?

[LakhveerChahal]

Was using mirroredMode for so long and it broke today by itself :(.

ping google.com gives: ping: google.com: Temporary failure in name resolution ping 8.8.8.8 gives: ping: connect: Network is unreachable

I can't change anything on Windows side which requires administrative privileges due to policies. By looking at the above conversation, it looks like it has do something with the Windows update.

OS Build: 22631.6199 (23H2) (seems quite old compared to other users)

Could be that wsl.exe updated itself silently, but not sure.

[llaros]

I compared netsh interface ipv4 dump with working version and after windows update where WSL is not working: I've noticed two differences

1. On Ethernet # interface not working: set interface interface="Ethernet 3" forwarding=enabled advertise=disabled metric=6000 siteprefixlength=0 nud=disabled routerdiscovery=disabled managedaddress=disabled otherstateful=disabled weakhostsend=disabled weakhostreceive=disabled ignoredefaultroutes=disabled advertisedrouterlifetime=0 advertisedefaultroute=disabled currenthoplimit=0 forcearpndwolpattern=disabled enabledirectedmacwolpattern=disabled ecncapability=ecndisabled rabaseddnsconfig=disabled dhcpstaticipcoexistence=disabled

working: set interface interface="Ethernet 3" forwarding=enabled advertise=disabled metric=6000 nud=enabled routerdiscovery=disabled managedaddress=enabled otherstateful=disabled weakhostsend=disabled weakhostreceive=disabled ignoredefaultroutes=disabled advertisedefaultroute=disabled currenthoplimit=0 forcearpndwolpattern=disabled enabledirectedmacwolpattern=disabled ecncapability=ecndisabled

I tried to enable nud but it didn't help. I did't manage to set managedaddress to enabled - got the error.

2. On "vEthernet (WSL (Hyper-V firewall))" on working I have metric=1

[michaelprooney]

I am also facing this issue where when connected to the vpn, I can not reach my desired server but am able to ssh from powershell.