KB5068861 breaks mirror networking with VPN

[jptrosclair]

Windows Version

Windows 1124H2

WSL Version

2.6.2.0

Are you using WSL 1 or WSL 2?

• [x] WSL 2
• [ ] WSL 1

Kernel Version

6.6.87.2-1

Distro Version

Ubuntu 24.04

Other Software

No response

Repro Steps

After the update is installed, no longer able to access network resources on VPN. Able to access to internet, only seems to affect VPN. Uninstalling the update restores accessibility to network resources on the other side of the VPN tunnel.

> type ~\.wslconfig
[experimental]
networkingMode=mirrored
dnsTunneling=true

Expected Behavior

Expecting to be able to access network resources on other side of VPN tunnel post-KB5068861.

Actual Behavior

Attempts to connect or even ping hosts on the other side of the VPN tunnel fail. These errors are logged in the kernel dmesg output:

[    7.468330] WSL (218) ERROR: CheckConnection: getaddrinfo() failed: -5
[    7.501055] WSL (218) ERROR: CheckConnection: getaddrinfo() failed: -5
[    7.537935] WSL (218) ERROR: CheckConnection: connect() failed: 101

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

[robertromore]

Also experiencing this. Putting the computer to sleep and re-waking it seems to fix it.

Edit: this seems to only work for about 10 minutes or so.

[jptrosclair]

This is a corporate PC and I'm unable to collect and upload logs due to restrictions outside of my control. I apologize.

I will add that I did update to the pre-release version of WSL with wsl --update --prerelease to see if that corrected the problem, and it did NOT. I was previously tracking the stable releases. I attempted multiple restarts of WSL with no luck. The only solution I found was to remove the update.

[simon376]

I'm facing the same issue, but uninstalling the update mentioned unfortunately did not solve the issue. Here are the WSL logs as requested, which may help you:

Networking Logs upload failed on GitHub and will be sent via email

WslLogs-2025-11-17_10-28-43.zip

[Ueland]

A colleague of me had this issue today where KB5068861 broke network connectivity. But in this case there was no .wslconfig file, so everything had default settings. Uninstalling the update brought network connectivity back. Unfortunately no debug logs. PS: We have tested this on multiple machines with the same hardware, no others have reported this issue. (I myself have this update and have no problems)

[ChamDK]

Same, recently updates have broken WSL when VPN is used.

I am unsure if it exactly this KB because i can't uninstall it.

14 days ago everything worked fine. After a larger windows update, it broke. Because of company policy i can't roll back.

but i see other similar posts regarding VPN and WSL that do not play well together.

[srbollin]

We’re seeing the same issue in our environment after installing KB5068861.

Environment (multiple dev workstations):

• Windows 11 (KB5068861 installed)

• WSL 2 WSL version: 2.6.1.0 Kernel version: 6.6.87.2-1 WSLg version: 1.0.66 MSRDC version: 1.2.6353 Direct3D version: 1.611.1-81528511 DXCore version: 10.0.26100.1-240331-1435.ge-release Windows version: 10.0.26100.6899

• Distro: Oracle Linux 9.5 (plus other distros)

• .wslconfig uses mirrored networking:

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

Symptom:

• From inside WSL, any connection that needs to go over our corporate VPN fails with No route to host.
• From the Windows host, the same destinations are reachable over VPN with no issue.
• Internet access (non-VPN) from WSL appears to work.
• We also noticed, systemd stopped working with latest patch.

Mitigation:

• Uninstalling KB5068861 with:

  wusa /uninstall /kb:5068861

  and rebooting immediately restores WSL networking, with no other config changes.

• Reinstalling KB5068861 reproduces the breakage 100% on affected machines.

Impact:

• A large portion of our team relies on WSL for day-to-day work, so this update is currently blocking normal workflows.

If there are specific logs that would help, we’re happy to collect, redact, and attach them.

[brianedwards00]

And I thought I was going crazy because I haven't changed anything. @srbollin 's solution worked for me!

[etyoma]

the same like above

• Windows 11
• wsl --version WSL version: 2.6.1.0 Kernel version: 6.6.87.2-1 WSLg version: 1.0.66 MSRDC version: 1.2.6353 Direct3D version: 1.611.1-81528511 DXCore version: 10.0.26100.1-240331-1435.ge-release Windows version: 10.0.26100.7171
• Guest OS Oracle Linux 9.5

uninstalling KB5068861 fully solves the issue but corp policy installs it back and immediately requires reboot

[randommen96]

Me and my coworkers have the same issue, uninstalling the KB makes it work again, however that is not preferred.

Tried multiple wsl versions, as well as distro's, but no luck.

Happy to provide logs.

[hovisms]

Same issue here. This impacts both mirrored and NAT modes. Unfortunately, my attempts to uninstall the KB result in an error state after reboot and windows reverting so that the KB remains installed.

[krutoileshii]

Same issue. unfortunately uninstalling the the KB is not an option either.

[randommen96]

In summary, a coworker found that the arp request is not answered for the ethernet interface of the VPN application.

Adding it manually makes it work with: sudo arp -s 1.2.3.4 11:22:33:44:55:66 -i ethX

I keep a ping open in a seperate tab to keep the arp alive.

So far this seems to work for me as a temporary workaround while keeping KB5068861 installed.

++ It looks like a ping in the background isn't needed to keep the arp entry, as it is added permanently with above command, at least for the time WSL is running.

[joesturge]

Im using vpnkit as a workaround for now: https://github.com/sakai135/wsl-vpnkit

I have created a gist to make setting this up trivial: https://gist.github.com/joesturge/6159ddf238ea8292ebc90a45ee2651b9

one liner:

 bash <(curl -sL https://gist.githubusercontent.com/joesturge/6159ddf238ea8292ebc90a45ee2651b9/raw/b2753d5acb323e0b071468cbc25def6915a0fb3f/enable-vpntoolkit.sh)

[keith-horton]

Thank you for reporting this. Can someone please share the network WSL logs with a full trace? https://github.com/microsoft/WSL/blob/master/diagnostics/collect-networking-logs.ps1

It's helpful to add the -RestartWslReproMode $true param to that PS script so that we can see everything being created and initialized.

Thanks!

[spencerdclayton]

Here are the logs from my machine. Running Cisco AnyConnect 5.1.8.112. I did previously attempt setting up the wsl-vpnkit. Can confirm hardcoding the arp entry associating the VPN interface's default gatway with its MAC address restores connectivity.

WslNetworkingLogs-2025-11-20_08-14-02.zip

For anyone stumbling upon this needing more guidance. Get the mac address of your vpn interface's default gateway using arp -a in Windows. Then confirm the interface in WSL with ip address (in most distros). Then use the arp command from net-tools to statically set the arp entry. sudo arp -s <192.168.100.1> <11:22:33:44:55:66> -i <ethX>

[sommella]

Here are the logs from my machine. Running Cisco AnyConnect 5.1.8.112. I did previously attempt setting up the wsl-vpnkit. Can confirm hardcoding the arp entry associating the VPN interface's default gatway with its MAC address restores connectivity.

WslNetworkingLogs-2025-11-20_08-14-02.zip

For anyone stumbling upon this needing more guidance. Get the mac address of your vpn interface's default gateway using arp -a in Windows. Then confirm the interface in WSL with ip address (in most distros). Then use the arp command from net-tools to statically set the arp entry. sudo arp -s <192.168.100.1> <11:22:33:44:55:66> -i <ethX>

I created this powershell script:

$ip = (Get-NetIPConfiguration -Detailed -InterfaceAlias "Cisco AnyConnect Secure Mobility Client Virtual Adapter").IPv4Address.IPAddress
$dg = (Get-NetIPConfiguration -Detailed -InterfaceAlias "Cisco AnyConnect Secure Mobility Client Virtual Adapter").ipv4defaultgateway.NextHop
$mac = ((arp -a) | Select-String -Pattern $dg).ToString().Split()[13].Replace("-",":")
$interface = ((wsl ip -br -4 a sh) | Select-String -Pattern $ip -Raw).ToString().Split()[0]
wsl sudo arp -s $dg $mac -i $interface
wsl sudo arp -a

Resulting in:

> Get-NetIPConfiguration -Detailed -InterfaceAlias "Cisco AnyConnect Secure Mobility Client Virtual Adapter"

InterfaceAlias                        : Cisco AnyConnect Secure Mobility Client Virtual Adapter
IPv4Address                           : 192.168.11.213
IPv4DefaultGateway                    : 192.168.0.1


> arp -a

Interface: 192.168.11.213 --- 0x7
  Internet Address      Physical Address      Type
  192.168.0.1           00-11-22-33-44-55     dynamic

$ sudo ip -br -4 a sh
eth5             UP             192.168.11.213/19

 sudo arp -a
192.168.0.1 at 00:11:22:33:44:55 [ether] PERM on eth5

But is still not working, am I getting the wrong values?

Thanks

[keith-horton]

Here are the logs from my machine. Running Cisco AnyConnect 5.1.8.112. I did previously attempt setting up the wsl-vpnkit. Can confirm hardcoding the arp entry associating the VPN interface's default gatway with its MAC address restores connectivity.

WslNetworkingLogs-2025-11-20_08-14-02.zip

For anyone stumbling upon this needing more guidance. Get the mac address of your vpn interface's default gateway using arp -a in Windows. Then confirm the interface in WSL with ip address (in most distros). Then use the arp command from net-tools to statically set the arp entry. sudo arp -s <192.168.100.1> <11:22:33:44:55:66> -i <ethX>

Thanks! We are investigating why this ARP reply is being dropped.

[Ueland]

Interesting that you mention Cisco Anyconnect. All cases I have handled now (3) are using Anyconnect. All have been solved by removing the KB.

[hkscfreak]

One liner to execute inside WSL after connecting to Cisco VPN:

sudo arp -s $(ip route | grep default | awk '{print $3}' | head -1) 00:11:22:33:44:55

Note: for me the gateway MAC was always the dummy address 00:11:22:33:44:55 YMMV. You can check/find the right MAC by:

1. Finding the right eth device a.run ifconfig inside WSL a. the correct device will have a lower MTU than the rest, for me it was 1390. a. note the inet(IP) address assigned to the adapter
2. Dumping the ARP cache in WIndows a. run arp.exe -a in windows terminal/powershell/WSL a. find the interface with the IP address from above a. the first ARP entry listed under that interface with type dynamic will be the physical address you need

[ChamDK]

One liner to execute inside WSL after connecting to Cisco VPN:

sudo arp -s $(ip route | grep default | awk '{print $3}' | head -1) 00:11:22:33:44:55

Note: for me the gateway MAC was always the dummy address 00:11:22:33:44:55 YMMV. You can check/find the right MAC by:

1. Finding the right `eth` device
   a.run `ifconfig` inside WSL
   a. the correct device will have a lower MTU than the rest, for me it was 1390.
   a. note the inet(IP) address assigned to the adapter

2. Dumping the ARP cache in WIndows
   a. run `arp.exe -a` in windows terminal/powershell/WSL
   a. find the interface with the IP address from above
   a. the first ARP entry listed under that interface with type `dynamic` will be the physical address you need

I can confirm that doing a static arp do not work for me, so i would think there is also other problems with WSL and VPN after the KB.

I see the ping packets in wireshark (windows-host) being sent out the interface, but i never receive any reply. if i do it on windows i see the same traffic being sent out, but now i get response.

I've attached a export from wireshark, difference between the 2, first one from wsl 2nd from windows. (mac and ip's have been changed for privacy)

diffrence.json

update: funfact, udp seems to work (dns)

[Acimaz]

I am fighting with this for a while now. For me it started with the earlier KB5067036 update. My workaround was to uninstall it daily (corporate workstation). Now with this new security update KB5068861, I can't uninstall the earlier one. I probably need to uninstall one after the other now.. Which takes quite some time.

Edit: I will try the workaround above as well and report back

[JoelB]

I had this same problem and am also using Cisco Secure Connect VPN client with a NixOS WSL2 VM with mirrored networking mode.

The solution @sommella provided did eventually work (thanks!) but had to be modified to account for the NextHop not being present for split tunnel configuration and the interface name being slightly different. Here's a more generic version which will hopefully work for more folks having this problem:

$adapter = Get-NetAdapter | Where-Object { $_.InterfaceDescription -like 'Cisco AnyConnect*' }
$ip = (Get-NetIpAddress -AddressFamily IPv4 -InterfaceIndex $interfaceIndex).IPAddress
$nexthop = (Get-NetRoute -InterfaceIndex $adapter.IfIndex | Where-Object { $_.NextHop -ne '0.0.0.0' } | Select-Object -First 1 -ExpandProperty NextHop)
$interface = ((wsl ip -br -4 a) | Select-String -Pattern "\b$ip\b").ToString().Split()[0]
$mac = ((arp -a) | Select-String -Pattern "${nexthop} ").ToString().Split()[13].Replace("-",":")

wsl sudo arp -s $nexthop $mac -i $interface

EDIT: Added missing $ip assignment and fixed the pattern matching for arp output for cases where the assigned IP starts with the same IP as the gateway.

[illegal]

@JoelB , thanks for the script! I had a few issues with it though. I think there is a missing command to find the IP address of the Cisco network adapter, and also the command that gets the MAC address relies on the number of whitespaces in the ARP table, which may vary between different environments, and hence may produce an empty string in the result.

I've tried to fix all these issues and got the following script in the end:

$interfaceIndex = (Get-NetAdapter | Where-Object { $_.InterfaceDescription -like 'Cisco AnyConnect*' }).IfIndex
$interfaceAddress = (Get-NetIpAddress -AddressFamily IPv4 -InterfaceIndex $interfaceIndex).IPAddress
$nextHop = (Get-NetRoute -InterfaceIndex $interfaceIndex | Where-Object { $_.NextHop -ne '0.0.0.0' } | Select-Object -First 1 -ExpandProperty NextHop)
$mac = ((arp -a) | Select-String -Pattern $nextHop).ToString().Split(" ", [System.StringSplitOptions]::RemoveEmptyEntries)[1].Replace("-",":")
$wslInterfaceName = ((wsl -d <your_distro_name> ip -br -4 a) | Select-String -Pattern "\b$interfaceAddress\b").ToString().Split()[0]

wsl -d <your_distro_name> sudo arp -s $nextHop $mac -i $wslInterfaceName

The part -d <your_distro_name> can be removed from the script, when applied to the default WSL distro.

[tovine]

@JoelB , thanks for the script! I had a few issues with it though. I think there is a missing command to find the IP address of the Cisco network adapter, and also the command that gets the MAC address relies on the number of whitespaces in the ARP table, which may vary between different environments, and hence may produce an empty string in the result.

I've tried to fix all these issues and got the following script in the end:

[code snippet removed because it broke the quote reply]

The part -d <your_distro_name> can be removed from the script, when applied to the default WSL distro.

Thanks a lot to both of you! The last line didn't work for me though (Debian Trixie) because I didn't have net-tools installed. Here's a version using ip neigh instead:

wsl -d <your_distro_name> sudo ip neigh add $nextHop lladdr $mac dev $wslInterfaceName nud permanent

(use ip neigh replace instead of ip neigh add in order to avoid RTNETLINK answers: File exists if conflicting routes already exist).

Disclaimer: Copilot helped me translate from arp to ip neigh, but it worked for me. 🤖

[kashyapmanu]

Thank you @JoelB @illegal. The script works flawlessly for me. Even after closing the VPN I do not need to delete anything from arp or restart the WSL. Thanks a ton.

[patryksliwinski]

@JoelB , thanks for the script! I had a few issues with it though. I think there is a missing command to find the IP address of the Cisco network adapter, and also the command that gets the MAC address relies on the number of whitespaces in the ARP table, which may vary between different environments, and hence may produce an empty string in the result.

I've tried to fix all these issues and got the following script in the end:

[code snippet removed because it broke the quote reply]

wsl -d <your_distro_name> sudo arp -s $nextHop $mac -i $wslInterfaceName The part -d <your_distro_name> can be removed from the script, when applied to the default WSL distro.

I tried this solution but for me it doesn't fix the issue.

[sommella]

Maybe the folks that identified the arp problem, can share how they identified the problem, so we can use same methodology to see what else is not working for us, even after the addiction of the workaround arp static entry.

[vetletm-tn]

I also tried the arp trick, but still no connectivity to corporate resources. I can see that packets traverse the vpn interface, but they are never received at the destination and get no replies. Works fine from Windows, even though networking is set to mirrored.

Cisco AnyConnect 5.1.12.146

Running Ubuntu 24.04.3 LTS in: WSL version: 2.6.1.0 Kernel version: 6.6.87.2-1 WSLg version: 1.0.66 MSRDC version: 1.2.6353 Direct3D version: 1.611.1-81528511 DXCore version: 10.0.26100.1-240331-1435.ge-release Windows version: 10.0.26100.7171

[ankavko]

For me, KB rollback works and static arp fix doesn't work. As i can see from WireShark, ARP response is quite slow, but it comes after some delay. After that i can see packets from WSL2 arriving at correct interface, but then no response. If we look to "Event Viewer" logs for "Cisco Secure Client - Core and VPN", there warning like this: [TID=22124 PID=27528] Function: CHostMgrCommonImpl::processPacket File: E:\dev\workspace\cure-client-windows_Raccoon_MR11@2\vpn\Agent\HostMgrCommonImpl.cpp Line: 1605 'PRM': Encountered invalid network bound packet

So, probably, something in this KB makes WSL2 ip packets invalid from Cisco vpnagent point of view.