Cisco VPN se cuelga tras Hyper-V: ¿desvincular o reconstruir?

El cliente gira en securing communications y nunca muestra un aviso de inicio de sesión, y lo único que cambió fue una instalación de emulador. Ese patrón apunta al adaptador virtual, no al perfil ni a la contraseña. La decisión es si el adaptador está vinculado a un conmutador Hyper-V en el que no debería estar, o si nunca se levantó.

Esos dos estados se parecen en el cliente y necesitan reparaciones distintas. Uno es una vinculación que puede deshacer; el otro es un problema de controlador que desvincular no tocará.

Qué espera la etapa securing communications

Antes de construir el túnel, el cliente necesita una ruta de red local operativa hacia la puerta de enlace. Instala su propio adaptador virtual y lo usa como parte de esa ruta. Si Hyper-V conecta ese adaptador a un conmutador creado para un emulador, el adaptador puede dejar de ofrecer una ruta utilizable.

El cliente no informa de qué adaptador está esperando. El registro suele terminar en la última etapa alcanzada, y el mismo fallo aparece para cada dirección de puerta de enlace. Por eso el historial de instalación importa más que el texto del error. El registro sigue valiendo la pena; le dice la etapa, no la causa.

Volver a introducir las credenciales o reinstalar el perfil no puede cambiar una vinculación de conmutador. Si esos son sus dos primeros movimientos, está reparando la capa equivocada.

Decisión uno: ¿está el adaptador VPN vinculado al conmutador equivocado?

Abra Hyper-V Manager, luego Virtual Switch Manager, y lea la lista de adaptadores de cada conmutador. El adaptador Cisco no debería aparecer como conexión de un conmutador de emulador. Si aparece, es culpa suya, y la reparación es quitarlo de ese conmutador.

Reinicie primero para que el cliente arranque limpio y no medio conectado. Quite la vinculación, aplíquela y deje los demás adaptadores en paz hasta que haya probado. El cambio es reversible y no desinstala nada, pero anote qué adaptadores desvinculó.

Inicie el cliente y pruebe la conexión. Si sigue atascado, desvincule los adaptadores virtuales restantes uno a la vez y pruebe después de cada uno, para saber cuál importaba.

Decisión dos: ¿está el adaptador activo pero sin dirección?

Ejecute ipconfig /all desde un símbolo del sistema elevado para que se incluyan los adaptadores ocultos, y compare la lista con lo que recuerde de antes de la instalación. Un adaptador sin dirección y con estado de medio desconectado suele significar que el controlador no se inició. Eso no se repara desvinculando. Anote el estado exacto antes de cambiar nada.

Un adaptador que está activo pero conectado al conmutador equivocado es el caso de la sección anterior. El estado de la dirección es cómo distingue los dos.

Restaure el emulador sin restaurar el fallo

Cuando el túnel funcione, vuelva a conectar el adaptador propio del emulador a su conmutador y confirme que la VM obtiene una dirección. No vuelva a conectar el adaptador VPN. Pruebe tanto el emulador como el cliente una vez más antes de darlo por terminado.

En una estación de trabajo gestionada, diga al administrador qué vinculación cambió. Una actualización de directivas posterior puede restaurar la conexión anterior, y el cuelgue volverá sin causa evidente.

Anote el nombre del adaptador, el conmutador al que estaba vinculado y el estado de ipconfig antes y después. Si el cuelgue vuelve tras una actualización, ese registro es la diferencia entre una comprobación de cinco minutos y empezar de cero.