La VPN SSL de FortiGate se acaba y toca pasar a IPsec

En 2021 publiqué aquí cómo configurar la VPN SSL en un FortiGate, en modo túnel y en modo web (sí, la de las veinte capturas de pantalla). Pues resulta que sigue siendo de las entradas más leídas del blog, y eso ahora es un problemilla, porque media entrada ya no vale para nada.

Desde FortiOS 7.6.3 el modo túnel de la VPN SSL se acaba, Fortinet lo cambia por IPsec, que por lo menos es un estándar, y el marrón está en lo que no sale en el titular. Cuando actualizas, la configuración del túnel SSL no se convierte en nada, se borra sin más, y las políticas que colgaban de ella detrás. O sea, que si alguien le da a actualizar un viernes a última hora (siempre hay alguien) sin haber migrado antes, el lunes no entra nadie desde casa y el teléfono echa humo.

Qué se lleva por delante la 7.6.3 (y la 7.6.0)

Lo resumo rápido, que la lista oficial es bastante más larga.

• Si tu FortiGate tiene 2 GB de RAM o menos, la VPN SSL ya desapareció entera con la 7.6.0 y la configuración se borra al actualizar, así, sin anestesia.
• En el resto de modelos la 7.6.3 quita el modo túnel, y las políticas que usaban la interfaz ssl.root tampoco sobreviven a la actualización.
• El modo web sigue vivo pero con otro nombre, Agentless VPN, viene apagado por defecto y no está en todos los modelos (en los 40F y 60F, por ejemplo, ni eso).
• Y un FortiGate ya no puede hacer de cliente de la VPN SSL de otro, para eso también toca IPsec.

Fortinet tiene la lista completa de comandos que desaparecen en su guía de migración de la VPN SSL a IPsec, yo me la leería entera antes de planificar nada, tiene más miga de la que parece.

¿Por qué ahora?

Fortinet lo vende (¿lo vende?) como pasar de un túnel propietario a uno estándar, y es verdad, pero la VPN SSL de FortiOS arrastra un historial que tampoco ayuda. CVE-2022-42475, CVE-2023-27997, CVE-2024-21762… fallos críticos, explotados de verdad, en el servicio que atiende la VPN y sin necesidad de autenticarse. Tres en tres años, que se dice pronto.

IPsec no es invulnerable, ojo, nada lo es, pero es un protocolo abierto, revisado por medio mundo y que habla cualquier fabricante, que no es poco.

Antes de tocar nada

IPsec no tiene portales, así que esto no va de traducir la configuración vieja comando a comando. Hay que pararse a pensar unas cuantas cosas, cinco en mi cuenta, porque cada una cambia lo que vas a escribir después.

La primera, la versión de IKE. IKEv2, sin mucha discusión, la autenticación de usuario va por EAP en vez de XAUTH y además admite DNS dividido. IKEv1 lo dejaría para clientes viejos que no puedan con la 2.

La segunda, por dónde va el tráfico. IPsec tira por defecto de UDP 500 y 4500, y hay operadores, algún hotel y redes con CGNAT que lo bloquean o lo complican (el clásico «desde aquí no me conecta»). Desde FortiOS 7.4.2 y FortiClient 7.4.1 puede ir por TCP, por defecto en el 443, igual que iba la SSL, y hay hasta un modo automático que prueba UDP y si en 15 segundos no contesta nadie se pasa a TCP.

La tercera, cómo se autentica la gente. Con usuarios locales del FortiGate no hay sorpresas, pero si tiráis de LDAP, en IKEv2 necesitáis EAP-TTLS, y eso pide FortiClient 7.4.3 o superior. SAML también funciona, con su puerto y su configuración aparte (esto da para otra entrada).

La cuarta, túnel completo o dividido, y aquí hay una diferencia que pilla a más de uno. La VPN SSL deducía qué redes mandar por el túnel a partir de las políticas, IPsec no, así que para un túnel dividido se lo tienes que decir tú con un grupo de direcciones.

Y la quinta, los portales. Si teníais varios portales SSL para distintos grupos, en IPsec lo normal es un túnel por cada caso. Con IKEv2 varios túneles pueden compartir interfaz gracias al network ID, eso sí, ese valor solo se puede fijar en un FortiClient gestionado desde EMS, con el gratuito nada.

La configuración, que es lo de menos

Vamos con un ejemplo sencillito, usuarios locales, IKEv2, túnel dividido y transporte TCP. Los nombres y las redes me los he inventado, cambiadlos por los vuestros.

Primero el rango que se reparte a los clientes, las redes a las que tienen que llegar y el grupo de usuarios (ana y luis, por poner a alguien).

config firewall address
    edit "rango-vpn"
        set type iprange
        set start-ip 10.10.250.10
        set end-ip 10.10.250.100
    next
end

config firewall addrgrp
    edit "redes-internas"
        set member "lan-oficina" "lan-servidores"
    next
end

config user group
    edit "grupo-vpn"
        set member "ana" "luis"
    next
end

Luego la fase 1, que es donde está todo el meollo.

config vpn ipsec phase1-interface
    edit "vpn-remota"
        set type dynamic
        set interface "wan1"
        set ike-version 2
        set peertype any
        set net-device disable
        set mode-cfg enable
        set proposal aes256gcm-prfsha384 aes256-sha256
        set dhgrp 20 14
        set dpd on-idle
        set eap enable
        set eap-identity send-request
        set authusrgrp "grupo-vpn"
        set transport tcp
        set assign-ip-from name
        set ipv4-name "rango-vpn"
        set ipv4-split-include "redes-internas"
        set ipv4-dns-server1 10.10.1.10
        set save-password enable
        set client-keep-alive enable
        set psksecret <clave-precompartida-larga>
    next
end

La fase 2 es cortita.

config vpn ipsec phase2-interface
    edit "vpn-remota"
        set phase1name "vpn-remota"
        set proposal aes256gcm aes256-sha256
        set dhgrp 20 14
    next
end

El puerto de IKE por TCP se fija a nivel de sistema y por defecto es el 443.

config system settings
    set ike-tcp-port 443
end

Ojo aquí, si mientras dura la transición la VPN SSL sigue escuchando en ese puerto, o tenéis la administración web en el 443 de la WAN, poned otro puerto para IPsec y ya lo cambiaréis cuando apaguéis la SSL. Y bueno, la administración del firewall no debería estar abierta a internet, pero esa es otra guerra.

Y la política, que como el grupo ya va en la fase 1, aquí no se repite.

config firewall policy
    edit 0
        set name "VPN remota a LAN"
        set srcintf "vpn-remota"
        set dstintf "port1"
        set action accept
        set srcaddr "rango-vpn"
        set dstaddr "redes-internas"
        set schedule "always"
        set service "ALL"
    next
end

Lo del grupo da más guerra de la que parece. Si lo ponéis en la fase 1 y también en la política, el usuario se autentica bien y el tráfico no pasa, y te puedes tirar una mañana mirando logs sin entender nada. En uno de los dos sitios, nunca en los dos. Y en producción afinad destinos y servicios, dejar ALL en una política de VPN es muy de andar por casa.

El cliente, la parte que nadie quiere hacer

En FortiClient hay que crear una conexión IPsec nueva con la dirección del FortiGate, la clave precompartida, IKE versión 2 y que pida usuario y contraseña al conectar. Para usar TCP hace falta FortiClient 7.4.1 o posterior, no vale cualquiera.

Si tenéis EMS, lo cómodo es empujar el perfil desde ahí y dejar que convivan las dos VPN unos días. Sin EMS toca ir equipo a equipo (sí, a mano), así que preparad una guía cortita con capturas para los usuarios, os ahorraréis un montón de llamadas.

Y una cosa que a veces se pasa por alto, la clave precompartida es la misma para todos, lo que identifica a cada persona es su usuario. Si queréis subir el listón, la alternativa es autenticar con certificados, que obliga a montar una CA y a repartir un certificado a cada equipo (si os hace falta un repaso, tenéis la entrada de certificados X.509).

Migrar sin que suene el teléfono

El orden que seguiría yo, más o menos, es este.

1. Copia de la configuración. Parece de primero de carrera, ya, pero es justo lo que falta el día que hace falta.
2. Inventario de lo que hay, portales, grupos, rangos de IP, políticas con ssl.root, marcadores del modo web y un largo etcétera, y sobre todo quién usa cada cosa, que eso casi nunca está apuntado en ningún sitio.
3. Montar IPsec en paralelo con la versión que tengáis ahora, antes de actualizar. Fortinet tiene un asistente en la interfaz y el servicio FortiConverter para convertir la configuración.
4. Un piloto pequeño, con gente de confianza, probando desde casa, desde el móvil compartiendo datos y desde alguna red que bloquee UDP, que es donde salen los problemas más tontos.
5. El resto por tandas, comprobando que no quedan sesiones SSL activas.
6. Con todo el mundo en IPsec, apagar la VPN SSL y ahora sí, actualizar a la 7.6.3 o posterior. Si gestionáis los equipos con FortiManager, este tiene que ir a la 7.6.3 antes que los FortiGate.
7. Y volver a probarlo todo después de actualizar. Si usabais el modo web, mirad cómo ha quedado como Agentless VPN.

Cuatro bloques y mucho inventario

La VPN SSL era cómoda, eso hay que reconocérselo, funcionaba en casi cualquier red y se montaba en una tarde. IPsec por TCP en el 443 recupera buena parte de esa comodidad y encima deja el acceso remoto sobre un estándar, que a la larga se agradece.

La configuración son cuatro bloques. Lo que de verdad lleva tiempo es el inventario y las pruebas con usuarios reales, así que mejor hacerlo antes de que una actualización os obligue con prisas. Si vuestro FortiGate está en la 7.4 o en la 7.6.2 o anterior, todavía hay margen para hacerlo con calma, aprovechadlo.

La referencia completa está en la documentación de Fortinet y en su nota técnica sobre los cambios en la 7.6.3.