Migrar de SSL-VPN a IPsec en FortiGate: guía paso a paso

Migrar de SSL-VPN a IPsec no es reescribir tu acceso remoto desde cero: es cambiar el protocolo de túnel sobre la misma arquitectura, con tu FortiGate en el mismo lugar de siempre. El orden importa más que la velocidad -el objetivo es que nadie note el cambio, no hacerlo rápido-.

Si todavía no tienes claro por qué esto es necesario, empieza por FortiOS 7.6 mató el SSL-VPN: qué hacer antes de actualizar. Esta guía asume que ya decidiste migrar y quieres el orden de pasos.

1. Audita antes de tocar nada

Antes de crear el primer túnel IPsec, documenta lo que ya tienes en SSL-VPN:

• Cuántos usuarios activos y cómo se agrupan (por departamento, por nivel de acceso).
• Qué método de autenticación usan: local, LDAP, RADIUS o SAML.
• Si hay perfiles distintos por grupo, con rutas o recursos diferentes.
• Si dependen de split-tunnel (solo el tráfico corporativo va por el túnel) o de full-tunnel (todo el tráfico sale por la VPN).

2. Elige IPsec con IKEv2 para acceso remoto de usuario

Para reemplazar SSL-VPN punto a usuario, la vía estándar es un túnel IPsec en modo cliente con IKEv2 y FortiClient como cliente de escritorio. A diferencia de un túnel site-to-site, aquí cada usuario negocia su propio túnel al conectarse, con la misma lógica de autenticación que ya tenías configurada para SSL-VPN.

3. Configura en paralelo, no en reemplazo directo

Crea la configuración de IPsec como algo adicional, sin apagar el SSL-VPN todavía. Esto te da una ventana real de prueba: un grupo piloto se conecta por IPsec mientras el resto del equipo sigue en SSL-VPN sin interrupción.

4. Ajusta las políticas de firewall

El túnel IPsec necesita sus propias políticas de firewall -origen, destino, servicios permitidos- reflejando lo mismo que tenías para el SSL-VPN. Es el paso donde más se cuelan errores: copiar la política de SSL-VPN sin ajustar la interfaz de origen deja al grupo piloto sin acceso a nada, aunque el túnel levante bien.

5. Prueba con un grupo piloto real, no solo contigo

Antes de mover a todo el equipo, valida con un grupo pequeño que use el acceso en condiciones reales: aplicaciones internas, impresión, recursos compartidos, lo que sea que su día a día requiera. Un túnel que levanta pero no da acceso a lo que la gente necesita no es una migración exitosa, aunque el diagnóstico se vea limpio.

¿Cómo sé si el problema es de fase 1 o de fase 2?

Si el túnel IPsec no levanta durante las pruebas, casi cualquier falla vive claramente en una de las dos fases de la negociación:

Cubrimos este diagnóstico a fondo, con los comandos exactos de debug de IKE, en VPN IPsec que no levanta: separa la fase 1 de la fase 2.

6. Corta, no apagues de golpe

Una vez validado, migra al resto del equipo por tandas, y retira las políticas y objetos de SSL-VPN al final, no al principio. Si algo falla durante la migración, quieres poder regresar al SSL-VPN mientras aún existe -antes de actualizar a una versión donde ya no es una opción-.

¿Cuánto tiempo toma una migración típica?

Depende del número de usuarios y de qué tan documentada esté tu configuración actual, pero el orden -auditar, configurar en paralelo, piloto, tandas, retiro- es el mismo sin importar el tamaño. Un equipo de 20 usuarios con perfiles simples puede completarse en una semana de ventanas controladas; un entorno con múltiples grupos y perfiles distintos toma más, principalmente por la validación de políticas de cada grupo, no por la configuración técnica en sí.

Si al final de este proceso te preguntas si valió la pena quedarte en VPN o si hubiera sido mejor saltar directo a ZTNA, esa es justo la pregunta que responde el siguiente artículo de esta serie, publicado más adelante.

Errores comunes que alargan una migración simple

¿Qué documentación dejar lista al terminar?

Una migración bien hecha no termina cuando el último usuario pasa a IPsec: termina cuando queda documentado qué cambió, para que el siguiente que toque esa configuración -tú mismo en seis meses, o quien te reemplace- no tenga que reconstruir la lógica desde cero. Como mínimo: el mapeo de grupos y perfiles, las políticas de firewall nuevas con su propósito, y la fecha en que se retiraron los objetos de SSL-VPN.