FortiClient se queda en el 98 %: desactiva IPv6 en ese adaptador

La barra llega al 98 %, el cliente se queda ahí y volver a escribir la contraseña no cambia nada. Esa es la pista útil: el cliente ya aceptó el certificado de la puerta de enlace, envió las credenciales y recibió una configuración de túnel. Lo que queda es levantar el adaptador virtual y confirmar que el túnel transporta tráfico. Cuando ese último paso nunca se completa, la falla es local, y ninguna cantidad de reintroducir credenciales llega a ella.

Cuatro pasos, y el primero es leer el registro en lugar de la barra.

Qué informa realmente el contador del 98 %

El porcentaje es el contador de etapas del propio cliente, no una medida de rendimiento. Un bloqueo en el mismo número en cada intento significa que el cliente llega a una etapa concreta y espera; por eso una conexión lenta y un cliente atascado se ven distintos en el registro. Un problema de credenciales imprimiría un error de credenciales en lugar de una pausa silenciosa.

Fortinet documentó este síntoma contra una causa del lado del cliente: IPv6 activado en el adaptador que usa el cliente. Eso convierte el ajuste del adaptador en lo primero que hay que probar, no en una explicación universal para cada SSL-VPN bloqueo.

Paso 1: lee el registro antes que la barra

Antes de cambiar nada, captura las líneas inmediatamente anteriores al bloqueo. Buscas si se creó el adaptador de túnel, si se asignó una dirección y si el cliente dejó de esperar una familia de direcciones. Un bloqueo en otro porcentaje es otra etapa con su propio diagnóstico, y una advertencia de certificado o una dirección de puerta de enlace incorrecta produce su propio mensaje en lugar de una espera silenciosa. Anota la marca de tiempo, porque el siguiente intento añade otro bloque al mismo archivo.

Si el registro muestra un inicio de sesión completado seguido de nada, estás en la configuración local y el adaptador es un sospechoso legítimo.

Paso 2: limita el cambio de IPv6 a un solo adaptador

El cambio corresponde al adaptador, no al equipo. En las propiedades del adaptador de Windows eso significa desmarcar Internet Protocol Version 6 (TCP/IPv6) en la interfaz concreta, y desde un shell es Disable-NetAdapterBinding -Name "Ethernet 2" -ComponentID ms_tcpip6. Confirma el estado con Get-NetAdapterBinding -ComponentID ms_tcpip6 antes de volver a conectarte. Luego reconéctate y observa si la barra pasa del 98 % en lugar de detenerse ahí.

Primero delimita el alcance, luego prueba. Desactivar IPv6 de forma global es un cambio mayor de lo que exige la cuestión y afecta a servicios que no pretendías tocar.

Paso 3: verifica qué ocultaba el bloqueo

Un túnel que conecta no es un túnel que funciona. Comprueba la dirección que asignó el cliente, las rutas que instaló el perfil y la resolución de nombres para un host interno: Resolve-DnsName files.corp.example. Un cliente que conecta y no resuelve nada tiene un problema de DNS, y eso se malinterpreta fácilmente como el regreso de la misma falla.

Prueba un recurso interno por nombre y un destino público, para que un túnel dividido roto no se confunda con un cliente arreglado.

Paso 4: haz que la corrección sea repetible

Si el ajuste tiene que llegar a una flota, ponlo en el paquete de despliegue o en la configuración del adaptador en lugar de en un paso manual repetido en cada portátil. Anota en el ticket que el bloqueo del 98 % estaba ligado a IPv6 en la interfaz de red, y señala qué más del host dependía de IPv6 antes de que alguien lo reactive para arreglar algo no relacionado.

Una corrección que solo existe en la memoria de un ingeniero es una corrección que vuelve el próximo trimestre.

Si la barra sigue deteniéndose en el 98 % con IPv6 desactivado, la nota del proveedor ya no lo explica y el registro es tu siguiente evidencia. Deja de tratar el síntoma y vuelve al contador de etapas.