Cisco VPN hangs after Hyper-V: unbind or rebuild?

The client spins at securing communications and never shows a login prompt, and the only thing that changed was an emulator install. That pattern points at the virtual adapter, not the profile or the password. The decision is whether the adapter is bound to a Hyper-V switch it should not be on, or whether it never came up at all.

Those two states look similar in the client and need different repairs. One is a binding you can undo; the other is a driver problem that unbinding will not touch.

What the securing-communications stage is waiting for

Before the tunnel is built, the client needs a working local network path to the gateway. It installs its own virtual adapter and uses it as part of that path. If Hyper-V attaches that adapter to a switch created for an emulator, the adapter can stop presenting a usable route.

The client does not report which adapter it is waiting on. The log typically ends at the last stage it reached, and the same failure appears for every gateway address. That is why the install history matters more than the error text. The log is still worth keeping; it tells you the stage, not the cause.

Re-entering credentials or reinstalling the profile cannot change a switch binding. If those are your first two moves, you are repairing the wrong layer.

Decision one: is the VPN adapter bound to the wrong switch?

Open Hyper-V Manager, then Virtual Switch Manager, and read the adapter list for each switch. The Cisco adapter should not appear as an attachment of an emulator switch. If it does, that is your fault, and the repair is to remove it from that switch.

Reboot first so the client starts clean rather than half-connected. Remove the binding, apply it, and leave the other adapters alone until you have tested. The change is reversible and uninstalls nothing, but write down which adapters you unbound.

Start the client and try the connection. If it still stalls, unbind the remaining virtual adapters one at a time and test after each, so you know which one mattered.

Decision two: is the adapter up but unaddressed?

Run ipconfig /all from an elevated prompt so hidden adapters are included, and compare the list with what you remember from before the install. An adapter with no address and a media-disconnected state usually means the driver did not start. That is not repaired by unbinding. Note the exact state before you change anything.

An adapter that is up but attached to the wrong switch is the case from the previous section. The address state is how you tell the two apart.

Restore the emulator without restoring the fault

When the tunnel works, reattach the emulator's own adapter to its switch and confirm the VM gets an address. Do not reattach the VPN adapter. Test both the emulator and the client once more before you call it done.

On a managed workstation, tell the administrator which binding you changed. A later policy refresh can restore the old attachment, and the hang will return with no obvious cause.

Record the adapter name, the switch it was bound to, and the ipconfig state before and after. If the hang comes back after an update, that record is the difference between a five-minute check and starting over.