AnyConnect stuck on "Connecting" in Windows 11: the real causes

When Cisco AnyConnect is stuck on “Connecting” in Windows 11 and eventually times out, the client is almost never the thing that is broken. The usual cause is that something is blocking its virtual adapter from being created — and most of the advice you will find online tells you to restart your PC, which fixes the symptom roughly one time in five.

This page separates the causes you can fix yourself from the ones that need whoever runs your VPN server. Work down in order — they are arranged by how often we actually see them.

First: is it hanging, or is it failing?

These look identical in the UI but have completely different causes:

• Hangs on “Connecting” then times out — the client cannot bring up its virtual network adapter. Local problem. Everything below applies.
• Fails immediately with “Connection attempt has failed” — the client reached the gateway and was rejected. Different problem; see connection attempt has failed.
• Connects, but nothing loads — the tunnel is up and routing or DNS is wrong. Usually server-side split-tunnel configuration.

Get this distinction right before you change anything. Applying adapter fixes to an authentication failure wastes an afternoon.

Cause 1 — Memory Integrity blocks the network filter driver

This is the single most common Windows 11 cause and it is almost absent from the top search results. Windows 11 ships with Core Isolation → Memory Integrity enabled by default on clean installs. It refuses to load kernel drivers it considers incompatible, and older AnyConnect network filter drivers fall into that category.

The tell: the client hangs on “Connecting”, and Get-Service vpnagent shows the service running. Nothing looks broken — the driver simply never loaded.

To check:

1. Open Windows Security → Device security → Core isolation details.
2. Note whether Memory integrity is On.

The correct fix is not to switch Memory Integrity off. It is a meaningful exploit mitigation, and turning it off to run a VPN trades a real security control for a convenience. Upgrade the client instead:

• Cisco Secure Client 5.x — signed drivers compatible with Memory Integrity. This is the fix.
• AnyConnect 4.10+ — the minimum Cisco supports on Windows 11.
• AnyConnect 4.9 and older — will install, will appear to work, and will hang here.

If your organisation has not yet moved to Secure Client, this is the reason to raise it. See Secure Client vs AnyConnect for what actually changed.

Cause 2 — Hyper-V and the virtual switch

Hyper-V's virtual switch binds to the physical adapter and can prevent AnyConnect's adapter from initialising. You may have Hyper-V enabled without knowing: WSL2, Docker Desktop, Windows Sandbox, and the Windows Subsystem for Android all turn it on.

Check whether it is running:

systeminfo | findstr /i "hyper-v"

Rather than disabling Hyper-V wholesale — which breaks WSL2 and Docker — try this order:

1. Stop Docker Desktop and any running VMs, then reconnect. If it works, it is a virtual switch conflict.
2. In Hyper-V Manager → Virtual Switch Manager, check for an External switch bound to your active NIC. Switching it to Internal usually resolves the conflict while keeping your containers working.
3. Only as a last resort, and temporarily: bcdedit /set hypervisorlaunchtype off, reboot. Re-enable with auto afterwards. This will break WSL2 until you do.

Cause 3 — Stale virtual adapters from a previous client

Uninstalling a VPN client rarely removes its virtual adapters. Accumulated adapters from OpenVPN, a previous AnyConnect version, or a consumer VPN leave orphaned entries that AnyConnect trips over.

In Device Manager, tick View → Show hidden devices, expand Network adapters, and look for greyed-out entries. Remove ones belonging to VPN software you no longer use — leave the WAN Miniport entries alone unless you are certain, as Windows uses them for its own dial-up and L2TP stack.

Then reset the network stack:

netsh winsock reset
netsh int ip reset
ipconfig /flushdns

Reboot before testing. Winsock changes do not fully apply until you do.

Cause 4 — The VPN agent service is wedged

The classic restart, done properly. In an elevated PowerShell:

Restart-Service vpnagent -Force
Get-Service vpnagent

On Secure Client 5.x the service is csc_vpnagent instead. If the service will not start at all, the driver failed to load — go back to Cause 1.

What is not your fault

These need whoever administers the VPN gateway. No amount of client-side work will fix them:

• Licence exhaustion. The ASA has a fixed concurrent-session count. When it is reached, new clients hang rather than being told the reason. Very common at 9am and after outages.
• Expired gateway certificate. Presents as a hang on some Windows builds and a certificate error on others — see certificate validation failure.
• DTLS blocked upstream. AnyConnect prefers DTLS on UDP 443 and falls back to TLS. Some hotel, airport, and mobile networks drop UDP 443 silently, so the client waits for the timeout before falling back.
• Group policy mismatch. If your account was moved between tunnel groups, the client can authenticate then stall on policy download.

Get the evidence: run DART before you call

Every AnyConnect install ships with DART (Diagnostic and Reporting Tool). It bundles every relevant log into one zip, and sending it with your ticket typically saves a full day of back-and-forth.

1. Start menu → Cisco AnyConnect Diagnostics and Reporting Tool (or Cisco Secure Client - DART).
2. Choose Default and let it finish.
3. Attach the resulting zip from your Desktop to your ticket.

If you want to look yourself first, the useful file inside is Cisco AnyConnect Secure Mobility Client.txt. Search it for Function: CTransportWinHttp — the message immediately after it is the actual failure, not the generic one the UI shows you.

The order we work through it

1. Confirm it is hanging, not failing (30 seconds — decides everything else).
2. Check the client version. Below 4.10 on Windows 11, stop and upgrade.
3. Check Memory Integrity. On, with an old client, is your answer.
4. Stop Docker/VMs and retry — rules Hyper-V in or out in a minute.
5. Clear hidden adapters, reset Winsock, reboot.
6. Restart vpnagent.
7. Run DART and escalate — the remaining causes are server-side.