Durante años, SSL VPN de FortiGate ha sido una de las formas más utilizadas para dar acceso remoto a las redes empresariales. Miles de empresas se acostumbraron a un modelo sencillo: instalar FortiClient, autenticar al usuario y crear un túnel hacia el firewall de la empresa.

Pero Fortinet está cambiando de dirección.

A partir de FortiOS 7.6.3, SSL VPN en modo túnel deja de estar disponible en todos los modelos FortiGate. Fortinet recomienda migrar las configuraciones existentes a IPsec VPN antes de actualizar. En determinados modelos de entrada con 2 GB de memoria, la retirada de SSL VPN incluso comenzó antes.

La pregunta para muchas empresas y MSP es evidente: si tengo que migrar mi acceso remoto igualmente, ¿tiene sentido cambiar SSL VPN por otra VPN o es el momento de adoptar un modelo Zero Trust?

Ahí aparece una tercera opción: ConnectaSec.

¿Qué ha pasado exactamente con FortiGate SSL VPN?

Es importante ser precisos: Fortinet no ha abandonado el acceso remoto ni las VPN. Lo que ha eliminado es SSL VPN en modo túnel.

Desde FortiOS 7.6.3 esta funcionalidad ya no aparece en GUI ni CLI, y las configuraciones SSL VPN tunnel existentes no se conservan al actualizar. Fortinet dispone incluso de documentación específica para migrar de SSL VPN a IPsec VPN.

La estrategia propuesta por el fabricante es, por tanto:

SSL VPN → IPsec VPN

Es una migración perfectamente válida y especialmente lógica para organizaciones que quieren seguir utilizando el FortiGate como concentrador de acceso remoto. Pero también plantea otra cuestión: ¿queremos simplemente cambiar el protocolo VPN o queremos replantearnos cómo damos acceso a nuestra infraestructura?

SSL VPN e IPsec comparten la misma filosofía

SSL VPN e IPsec utilizan tecnologías distintas, pero conceptualmente comparten una característica importante: conectan un dispositivo remoto con una red.

El usuario establece un túnel hacia la infraestructura corporativa y, después, las reglas del firewall determinan qué tráfico puede circular. Este modelo puede securizarse muchísimo con MFA, certificados, políticas y segmentación.

El problema no es que IPsec sea inseguro. El problema es que seguimos partiendo de un modelo de acceso basado en conectividad de red.

Zero Trust le da la vuelta al concepto:

El usuario o dispositivo no necesita entrar en la red. Solo necesita acceder a los recursos estrictamente autorizados.

FortiGate IPsec vs ConnectaSec

ConnectaSec está diseñado siguiendo precisamente ese modelo: una plataforma de acceso remoto basada en Zero Trust Network Access (ZTNA) donde se definen de forma granular los recursos a los que puede acceder cada usuario o dispositivo.

Por ejemplo, un usuario de administración puede necesitar:

ERP: 192.168.10.20:443
SQL: 192.168.10.25:1433

Pero no tiene ninguna razón para acceder a controladores de dominio, impresoras, NAS, hipervisores, dispositivos IoT u otras estaciones de trabajo.

1. Acceso a la red vs acceso al recurso

Con FortiGate SSL VPN / IPsec, el dispositivo establece un túnel contra el firewall y después se usan políticas para delimitar hasta dónde puede llegar. Es un modelo potente y flexible, sobre todo cuando necesitamos conectividad completa entre redes.

Con ConnectaSec, por defecto no tienes acceso a nada. El administrador determina expresamente qué recursos deben ser accesibles. Eso reduce enormemente las posibilidades de movimiento lateral si un dispositivo acaba comprometido.

2. El firewall deja de ser el punto de entrada

Una VPN tradicional necesita un servicio accesible desde Internet: el FortiGate debe recibir las conexiones de los usuarios remotos.

En ConnectaSec la arquitectura es distinta: las conexiones se establecen hacia la infraestructura de ConnectaSec, por lo que no es necesario publicar directamente el servicio interno que queremos proteger. No necesitas abrir un puerto hacia el ERP, ni publicar RDP, ni exponer un servidor VPN propio para ese acceso.

Para muchas pymes esto supone una diferencia operativa enorme.

3. El firewall puede seguir siendo FortiGate

ConnectaSec no pretende sustituir al FortiGate como firewall. Un FortiGate sigue teniendo todo el sentido para firewall perimetral, IPS, filtrado, SD-WAN, seguridad entre VLAN, inspección de tráfico, conectividad site-to-site y protección de la LAN.

Lo que cambia es una función concreta: el acceso remoto de usuarios.

En lugar de:

Usuario → FortiClient → VPN → FortiGate → LAN

pasamos a:

Usuario → ConnectaSec → recurso autorizado

FortiGate protege la red. ConnectaSec controla quién accede a qué recurso remoto. Ambas tecnologías conviven perfectamente.

4. Microsegmentación desde el primer momento

Uno de los principales riesgos de cualquier acceso remoto es el movimiento lateral. Si un portátil remoto se ve comprometido, el atacante intentará descubrir servidores, SMB, RDP, SQL, Active Directory, NAS, hipervisores, impresoras o dispositivos de red.

Con un modelo Zero Trust, el objetivo es que el equipo comprometido ni siquiera tenga una ruta válida hacia los recursos que no necesita.

5. Seguridad del dispositivo antes de conectarlo

Zero Trust no debería limitarse a preguntar «¿está autorizado este dispositivo?», sino también «¿está en condiciones de seguridad adecuadas para conectarse?».

ConnectaSec puede incorporar controles de postura del endpoint para verificar aspectos como el estado de actualización de Windows, el estado del antivirus o EDR, el cumplimiento de políticas de seguridad o la identidad del dispositivo. Si el dispositivo deja de cumplir las condiciones definidas, su acceso puede limitarse o aislarse.

No basta con tener acceso: hay que seguir cumpliendo las condiciones de seguridad.

6. ¿Y si necesito realmente acceso completo a una red?

Aquí hay que ser claros: ZTNA no sustituye a todas las VPN. Hay escenarios donde IPsec sigue siendo una excelente solución:

conexión site-to-site entre dos oficinas;
comunicaciones permanentes entre dos redes;
determinados entornos industriales;
aplicaciones antiguas que requieren descubrimiento completo de red;
ciertos escenarios de routing.

Pero cuando hablamos de teletrabajadores, proveedores externos, técnicos, administradores, acceso a ERP, aplicaciones internas, RDP, SQL o servidores concretos, ZTNA ofrece un modelo mucho más granular.

Comparativa rápida

Característica	FortiGate SSL VPN	FortiGate IPsec	ConnectaSec ZTNA
Acceso remoto	Sí	Sí	Sí
Disponible en FortiOS 7.6.3+	No en modo túnel	Sí	Sí
Basado en túnel VPN	Sí	Sí	No como VPN tradicional
Acceso granular	Mediante políticas	Mediante políticas	Por recurso
Microsegmentación	Configurable	Configurable	Nativa al modelo
Requiere FortiGate	Sí	Sí	No
Servicio VPN publicado	Sí	Sí	No hace falta publicar el recurso interno
Posture check	Según arquitectura/licencias	Según arquitectura/licencias	Integrado en el modelo
Gestión centralizada	Fortinet	Fortinet	Panel ConnectaSec
Orientado a Zero Trust	Parcial	Parcial	Sí
Site-to-site	No es su foco	Excelente	No es su objetivo principal

No se trata de que IPsec sea peor

Sería un error interpretar la retirada de SSL VPN como «Fortinet reconoce que las VPN son inseguras». No es eso lo que está ocurriendo: IPsec es un protocolo extremadamente maduro y seguro cuando está bien configurado.

La reflexión es otra. Si una empresa tiene que dedicar tiempo a migrar cientos de usuarios porque su tecnología de acceso remoto cambia, quizá sea buen momento para preguntarse: ¿queremos migrar de SSL VPN a IPsec, o queremos evolucionar de VPN a Zero Trust? Son decisiones diferentes.

Especialmente interesante para MSP

Para un MSP el problema se multiplica. Gestionar acceso remoto para 30, 50 o 100 clientes puede significar mantener múltiples FortiGate, distintas versiones de firmware, configuraciones VPN, certificados, usuarios, políticas, MFA e incidencias de cliente VPN.

Una plataforma ZTNA centralizada permite administrar los accesos desde una única capa de gestión. ConnectaSec está diseñado con un modelo multiempresa: usuarios, dispositivos, gateways y permisos desde un solo panel. Puedes ampliar en ZTNA para MSPs.

Una oportunidad para replantear el acceso remoto

La decisión de Fortinet acelerará muchas migraciones en los próximos años. Algunas empresas migrarán directamente a IPsec, y será una decisión perfectamente válida. Otras aprovecharán el cambio para modernizar su arquitectura.

Porque quizá la pregunta ya no debería ser «¿qué VPN utilizamos?», sino «¿por qué necesita este usuario estar conectado a mi red?».

Si solo necesita el ERP, damos acceso al ERP. Si solo necesita RDP contra un servidor, damos acceso a ese servidor. Si solo necesita SQL, permitimos SQL. Nada más. Eso es aplicar Zero Trust al acceso remoto.

FortiGate + ConnectaSec: no son necesariamente competidores

Una de las arquitecturas que más sentido tiene es usar ambas tecnologías: FortiGate para proteger la red y ConnectaSec para controlar el acceso remoto. El firewall sigue haciendo aquello en lo que es excelente —proteger, segmentar e inspeccionar— mientras ConnectaSec aplica una capa Zero Trust sobre usuarios y dispositivos remotos.

No hay que sustituir el firewall. Hay que evitar convertirlo en la puerta universal de entrada para cualquier usuario remoto.

¿Tienes usuarios conectándose por FortiGate SSL VPN?

Antes de migrarlos automáticamente a IPsec, puede ser buen momento para revisar qué necesitan de verdad. En muchos casos, de 50 usuarios conectados por VPN:

20 solo necesitan el ERP;
10 necesitan escritorio remoto;
8 necesitan una aplicación SQL;
7 necesitan acceder a un NAS;
y solo 5 necesitan conectividad de red más amplia.

Esos primeros 45 usuarios probablemente no necesitan una VPN tradicional: necesitan acceso seguro a aplicaciones y recursos concretos.

Acceso remoto seguro. Zero Trust. Sin VPN tradicional. Sin exponer la red. Y únicamente a aquello que cada usuario necesita.

Más detalle en la landing alternativa a FortiGate SSL VPN, en la comparativa VPN vs ZTNA y en ConnectaSec vs FortiClient. Consulta los precios o solicita una demo.