Dos usuarios con equipos distintos fallaban intermitentemente al conectar por SSL VPN y el FortiClient devolvía -7200. Se resolvió al corregir un desajuste raro de MTU/MSS en el camino provocado por un cambio reciente en el borde WAN, que hacía que el handshake TLS de SSLVPN quedara truncado solo para ciertos accesos.

Producto/Rol: FortiGate como concentrador SSL VPN (portal + túnel)
• Versión: FortiOS 7.4.x
• Servicio afectado: SSL VPN (FortiClient)
• Cambio reciente: Ajuste en el borde WAN (por ejemplo, nuevo enlace/PPPoE/SD-WAN o cambio de perfil/inspección) que alteró el MTU efectivo hacia Internet

Los dos clientes (hardware/firmware diferente) reportaban que la conexión SSL VPN quedaba en “connecting” y terminaba en error VPNSSL -7200. En el FortiGate no se veía una caída “limpia” tipo credenciales o política; parecía más un corte durante la negociación inicial (antes de levantar el túnel estable).

LA PISTA DECISIVA

El fallo ocurría solo desde ciertas redes/operadores (o solo cuando el usuario estaba fuera de oficina) y, lo más importante, repetía patrón por ruta, no por tipo de endpoint. Eso descartó “driver/OS del cliente” y apuntó a algo del camino (PMTUD/fragmentación) que afectaba a la negociación TLS.

DIAGNÓSTICO

Evidencia mínima que capturé: hora aproximada del intento fallido y desde qué ISP/red venía cada usuario
Qué verifiqué primero: que el servicio SSLVPN estaba arriba y no era un tema de licencia/CPU o caída general
• get system status
Qué patrón busqué en eventos/logs: eventos de sslvpn alrededor de una ventana corta (1–2 min) para ver si era “corte en handshake” vs. auth/policy
• execute log filter reset
• execute log filter category vpn
• execute log display
Prueba decisiva: habilité debug del proceso SSLVPN solo durante un intento fallido (30–60s) buscando signos de retransmisiones/negociación incompleta (sesión que se abre y se cierra antes de auth completa)
• diagnose debug console timestamp enable
• diagnose debug application sslvpn -1
(terminado el intento, apagué debug; ver cierre más abajo)
Qué resultado confirmó la hipótesis: en los intentos fallidos se veía la sesión iniciarse pero no completar la fase esperada antes de credenciales/establecimiento estable, consistente con paquetes que no llegan (truncado) y no con “bad password / no matching policy”
Si no confirmaba: habría comprobado MTU/MSS efectivo en la interfaz WAN/SD-WAN y la política de salida (sin profundizar en más causas)

(Debug apagado al terminar el intento)
• diagnose debug disable
• diagnose debug reset

LA CORRECCIÓN

Apliqué un fix mínimo y reversible: forzar MSS menor para el tráfico SSLVPN (o para el tráfico de salida correspondiente) de modo que el TLS handshake y el túnel no dependieran de PMTUD/ICMP en ese camino.

En la práctica, esto fue ajustar MSS clamp en el punto correcto (normalmente en la política de salida hacia Internet o en la interfaz WAN/SD-WAN según el diseño), dejando un margen seguro para encapsulaciones. No cambié cifrados ni reemití certificados: la corrección fue estrictamente de tamaño de segmento.

VALIDACIÓN FINAL

• Los dos usuarios conectaron en el primer intento desde las mismas redes que fallaban
• El tiempo de conexión volvió a ser consistente (sin “connecting…” prolongado)
• En logs ya no aparecieron cierres prematuros durante el handshake; el flujo llegó a estado estable y navegación por túnel OK

ROLLBACK

Si hubiera algún efecto colateral (poco común, pero posible en ciertos enlaces), revertir es simple: deshacer el ajuste de MSS/MTU aplicado (volver al valor anterior o quitar el clamp) y validar de nuevo con un intento controlado.

QUÉ ENVIAR AL TAC

• Código/mensaje exacto: “VPNSSL -7200” y hora aproximada de 2–3 intentos fallidos por usuario
• Capturas de FortiClient (sin datos sensibles) mostrando el momento del fallo
• Versión FortiOS (7.4.x) y modelo FortiGate
• Export/backup solo de la parte relacionada (config de vpn ssl settings, vpn ssl web portal, políticas implicadas y (si aplica) SD-WAN/WAN MTU/MSS)
• Extracto de logs de VPN alrededor de ±2 minutos de cada intento fallido
• Un paquete mínimo de comandos + debug breve (abajo), incluyendo apagado de debug

PAQUETE TAC: COMANDOS SUGERIDOS

• get system status
• execute log filter reset
• execute log filter category vpn
• execute log display
• diagnose debug console timestamp enable
• diagnose debug application sslvpn -1

Cierre obligatorio (después del intento):
• diagnose debug disable
• diagnose debug reset
• diagnose debug console timestamp disable