FortiGate elimina la SSL VPN: migrar a IPsec o fer el salt a ZTNA?
Durant anys, la SSL VPN de FortiGate ha estat una de les maneres més utilitzades de donar accés remot a les xarxes empresarials. Milers d''empreses es van acostumar a un model senzill: instal·lar FortiClient, autenticar l''usuari i crear un túnel cap al tallafocs de l''empresa.
Però Fortinet està canviant de direcció.
A partir de FortiOS 7.6.3, la SSL VPN en mode túnel deixa d''estar disponible en tots els models FortiGate. Fortinet recomana migrar les configuracions existents a IPsec VPN abans d''actualitzar. En determinats models d''entrada amb 2 GB de memòria, la retirada de la SSL VPN fins i tot va començar abans.
La pregunta per a moltes empreses i MSP és evident: si he de migrar l''accés remot igualment, té sentit canviar la SSL VPN per una altra VPN o és el moment d''adoptar un model Zero Trust?
Aquí apareix una tercera opció: ConnectaSec.
Què ha passat exactament amb la SSL VPN de FortiGate?
Cal ser precisos: Fortinet no ha abandonat l''accés remot ni les VPN. El que ha eliminat és la SSL VPN en mode túnel.
Des de FortiOS 7.6.3 aquesta funcionalitat ja no apareix ni a la GUI ni a la CLI, i les configuracions SSL VPN tunnel existents no es conserven en actualitzar. Fortinet fins i tot disposa de documentació específica per migrar de SSL VPN a IPsec VPN.
L''estratègia proposada pel fabricant és, per tant:
SSL VPN → IPsec VPN
És una migració perfectament vàlida i especialment lògica per a organitzacions que volen continuar fent servir el FortiGate com a concentrador d''accés remot. Però també planteja una altra qüestió: volem simplement canviar de protocol VPN o volem replantejar com donem accés a la infraestructura?
SSL VPN i IPsec comparteixen la mateixa filosofia
La SSL VPN i IPsec fan servir tecnologies diferents, però conceptualment comparteixen una característica important: connecten un dispositiu remot amb una xarxa.
L''usuari estableix un túnel cap a la infraestructura corporativa i, després, les regles del tallafocs determinen quin trànsit pot circular. Aquest model es pot securitzar moltíssim amb MFA, certificats, polítiques i segmentació.
El problema no és que IPsec sigui insegur. El problema és que continuem partint d''un model d''accés basat en connectivitat de xarxa.
El Zero Trust gira el concepte:
L''usuari o dispositiu no necessita entrar a la xarxa. Només necessita accedir als recursos estrictament autoritzats.
FortiGate IPsec vs ConnectaSec
ConnectaSec està dissenyat seguint precisament aquest model: una plataforma d''accés remot basada en Zero Trust Network Access (ZTNA) on es defineixen de forma granular els recursos als quals pot accedir cada usuari o dispositiu.
Per exemple, un usuari d''administració pot necessitar:
- ERP:
192.168.10.20:443 - SQL:
192.168.10.25:1433
Però no té cap raó per accedir a controladors de domini, impressores, NAS, hipervisors, dispositius IoT o altres estacions de treball.
1. Accés a la xarxa vs accés al recurs
Amb FortiGate SSL VPN / IPsec, el dispositiu estableix un túnel contra el tallafocs i després s''usen polítiques per delimitar fins on pot arribar. És un model potent i flexible, sobretot quan cal connectivitat completa entre xarxes.
Amb ConnectaSec, per defecte no tens accés a res. L''administrador determina expressament quins recursos han de ser accessibles. Això redueix enormement les possibilitats de moviment lateral si un dispositiu acaba compromès.
2. El tallafocs deixa de ser el punt d''entrada
Una VPN tradicional necessita un servei accessible des d''Internet: el FortiGate ha de rebre les connexions dels usuaris remots.
A ConnectaSec l''arquitectura és diferent: les connexions s''estableixen cap a la infraestructura de ConnectaSec, de manera que no cal publicar directament el servei intern que volem protegir. No cal obrir un port cap a l''ERP, ni publicar RDP, ni exposar un servidor VPN propi per a aquest accés.
Per a moltes pimes això suposa una diferència operativa enorme.
3. El tallafocs pot continuar sent un FortiGate
ConnectaSec no pretén substituir el FortiGate com a tallafocs. Un FortiGate continua tenint tot el sentit per a tallafocs perimetral, IPS, filtratge, SD-WAN, seguretat entre VLAN, inspecció de trànsit, connectivitat site-to-site i protecció de la LAN.
El que canvia és una funció concreta: l''accés remot d''usuaris.
En lloc de:
Usuari → FortiClient → VPN → FortiGate → LAN
passem a:
Usuari → ConnectaSec → recurs autoritzat
El FortiGate protegeix la xarxa. ConnectaSec controla qui accedeix a quin recurs remot. Totes dues tecnologies conviuen perfectament.
4. Microsegmentació des del primer moment
Un dels riscos principals de qualsevol accés remot és el moviment lateral. Si un portàtil remot queda compromès, l''atacant intentarà descobrir servidors, SMB, RDP, SQL, Active Directory, NAS, hipervisors, impressores o dispositius de xarxa.
Amb un model Zero Trust, l''objectiu és que l''equip compromès ni tan sols tingui una ruta vàlida cap als recursos que no necessita.
5. Seguretat del dispositiu abans de connectar-lo
El Zero Trust no s''hauria de limitar a preguntar «aquest dispositiu està autoritzat?», sinó també «està en condicions de seguretat adequades per connectar-se?».
ConnectaSec pot incorporar controls de postura de l''endpoint per verificar aspectes com l''estat d''actualització de Windows, l''estat de l''antivirus o EDR, el compliment de polítiques de seguretat o la identitat del dispositiu. Si el dispositiu deixa de complir les condicions definides, l''accés es pot limitar o aïllar.
No n''hi ha prou amb tenir accés: cal continuar complint les condicions de seguretat.
6. I si realment necessito accés complet a una xarxa?
Aquí cal ser clars: el ZTNA no substitueix totes les VPN. Hi ha escenaris on IPsec continua sent una solució excel·lent:
- connexió site-to-site entre dues oficines;
- comunicacions permanents entre dues xarxes;
- determinats entorns industrials;
- aplicacions antigues que requereixen descobriment complet de xarxa;
- certs escenaris d''encaminament.
Però quan parlem de teletreballadors, proveïdors externs, tècnics, administradors, accés a l''ERP, aplicacions internes, RDP, SQL o servidors concrets, el ZTNA ofereix un model molt més granular.
Comparativa ràpida
| Característica | FortiGate SSL VPN | FortiGate IPsec | ConnectaSec ZTNA |
|---|---|---|---|
| Accés remot | Sí | Sí | Sí |
| Disponible a FortiOS 7.6.3+ | No en mode túnel | Sí | Sí |
| Basat en túnel VPN | Sí | Sí | No com una VPN tradicional |
| Accés granular | Mitjançant polítiques | Mitjançant polítiques | Per recurs |
| Microsegmentació | Configurable | Configurable | Nativa al model |
| Requereix FortiGate | Sí | Sí | No |
| Servei VPN publicat | Sí | Sí | No cal publicar el recurs intern |
| Posture check | Segons arquitectura/llicències | Segons arquitectura/llicències | Integrat al model |
| Gestió centralitzada | Fortinet | Fortinet | Panell ConnectaSec |
| Orientat a Zero Trust | Parcial | Parcial | Sí |
| Site-to-site | No és el seu focus | Excel·lent | No és el seu objectiu principal |
No es tracta que IPsec sigui pitjor
Seria un error interpretar la retirada de la SSL VPN com «Fortinet reconeix que les VPN són insegures». No és això el que passa: IPsec és un protocol extremadament madur i segur quan està ben configurat.
La reflexió és una altra. Si una empresa ha de dedicar temps a migrar centenars d''usuaris perquè la seva tecnologia d''accés remot canvia, potser és bon moment per preguntar-se: volem migrar de SSL VPN a IPsec, o volem evolucionar de VPN a Zero Trust? Són decisions diferents.
Especialment interessant per a MSP
Per a un MSP el problema es multiplica. Gestionar accés remot per a 30, 50 o 100 clients pot significar mantenir múltiples FortiGate, versions de firmware diferents, configuracions VPN, certificats, usuaris, polítiques, MFA i incidències del client VPN.
Una plataforma ZTNA centralitzada permet administrar els accessos des d''una única capa de gestió. ConnectaSec està dissenyat amb un model multiempresa: usuaris, dispositius, gateways i permisos des d''un sol panell. Pots ampliar-ho a ZTNA per a MSPs.
Una oportunitat per replantejar l''accés remot
La decisió de Fortinet accelerarà moltes migracions els propers anys. Algunes empreses migraran directament a IPsec, i serà una decisió perfectament vàlida. D''altres aprofitaran el canvi per modernitzar l''arquitectura.
Perquè potser la pregunta ja no hauria de ser «quina VPN fem servir?», sinó «per què necessita aquest usuari estar connectat a la meva xarxa?».
Si només necessita l''ERP, donem accés a l''ERP. Si només necessita RDP contra un servidor, donem accés a aquell servidor. Si només necessita SQL, permetem SQL. Res més. Això és aplicar Zero Trust a l''accés remot.
FortiGate + ConnectaSec: no són necessàriament competidors
Una de les arquitectures que més sentit té és fer servir totes dues tecnologies: FortiGate per protegir la xarxa i ConnectaSec per controlar l''accés remot. El tallafocs continua fent allò en què és excel·lent —protegir, segmentar i inspeccionar— mentre ConnectaSec aplica una capa Zero Trust sobre usuaris i dispositius remots.
No cal substituir el tallafocs. Cal evitar convertir-lo en la porta universal d''entrada per a qualsevol usuari remot.
Tens usuaris connectant-se per FortiGate SSL VPN?
Abans de migrar-los automàticament a IPsec, pot ser bon moment per revisar què necessiten de debò. En molts casos, de 50 usuaris connectats per VPN:
- 20 només necessiten l''ERP;
- 10 necessiten escriptori remot;
- 8 necessiten una aplicació SQL;
- 7 necessiten accedir a un NAS;
- i només 5 necessiten connectivitat de xarxa més àmplia.
Aquests primers 45 usuaris probablement no necessiten una VPN tradicional: necessiten accés segur a aplicacions i recursos concrets.
Accés remot segur. Zero Trust. Sense VPN tradicional. Sense exposar la xarxa. I només a allò que cada usuari necessita.
Més detall a la landing alternativa a FortiGate SSL VPN, a la comparativa VPN vs ZTNA i a ConnectaSec vs FortiClient. Consulta els preus o demana una demo.