Fortinet beendet den SSL-VPN Tunnel Mode. Welche FortiGate-Modelle betroffen sind, was sich mit FortiOS 7.6.3 ändert und welche Alternativen Unternehmen jetzt prüfen sollten.
Stand: September 2026
Wer heute mit FortiClient und SSL-VPN auf eine FortiGate zugreift, muss seine Remote-Access-Strategie überprüfen: Seit FortiOS 7.6.3 unterstützt Fortinet den SSL-VPN Tunnel Mode auf keiner FortiGate mehr. Bestehende Tunnel-Konfigurationen werden beim Upgrade nicht automatisch auf IPsec übertragen. Wer den Remote Access nach dem Upgrade weiter nutzen möchte, muss deshalb vor dem Upgrade migrieren.
Ganz verschwunden ist SSL-VPN damit allerdings nicht. Der bisherige SSL-VPN Web Mode wird seit FortiOS 7.6.3 als Agentless VPN bezeichnet. „Agentless“ bedeutet hier: Auf dem Endgerät ist kein zusätzlicher FortiClient erforderlich. Es handelt sich um eine Umbenennung; bestehende Web-Mode-Konfigurationen bleiben auf unterstützten Modellen gültig.
Die entscheidende Frage lautet deshalb nicht nur: „Womit ersetzen wir SSL-VPN?“ Sondern: Welche Benutzer benötigen tatsächlich vollständigen Netzwerkzugriff – und bei welchen Anwendungen lässt sich der Zugriff künftig gezielter gestalten?
Das Wichtigste auf einen Blick
- Ab FortiOS 7.6.3 entfällt der SSL-VPN Tunnel Mode auf allen FortiGate-Modellen.
- FortiGate-Modelle mit 2 GB RAM oder weniger verlieren ab FortiOS 7.4.4 wesentliche proxybasierte Funktionen, darunter den ZTNA Access Proxy. Bei bestimmten Entry-Level-Modellen wurde zusätzlich SSL-VPN bereits früher entfernt.
- IPsec-VPN ist Fortinets direkter Nachfolger für den klassischen Netzwerkzugriff des SSL-VPN Tunnel Mode. IPsec-VPN kann auch über TCP-Port 443 – den üblicherweise für HTTPS verwendeten Port – transportiert werden und damit auch in vielen restriktiven Fremdnetzen funktionieren.
- Der kostenlose FortiClient VPN-only unterstützt grundlegendes IPsec, ist gegenüber den kommerziellen Varianten aber deutlich eingeschränkt: IPsec über TCP, zentrale Verwaltung, ZTNA und VPN before Logon stehen nicht zur Verfügung; zudem bestehen Einschränkungen bei bestimmten Authentifizierungsszenarien.
- Für viele Unternehmen kann ein dauerhafter Mischbetrieb aus IPsec und ZTNA sinnvoller sein als eine reine Entweder-oder-Entscheidung.
- Für IPsec-VPN sind insbesondere zertifikatsbasierte Authentifizierung und SAML relevant. Je nach Infrastruktur können auch LDAP, RADIUS und klassische MFA-Verfahren eingesetzt werden. Beim clientbasierten ZTNA ergänzt FortiClient EMS die Benutzeranmeldung um eine zertifikatsbasierte Geräteidentität und Informationen zum Sicherheitszustand des Endgeräts.
- Für externe Administratoren sowie Wartungs- und OT-Dienstleister kann FortiPAM sinnvoll sein: Zugriffe lassen sich gezielt, zeitlich begrenzt und nach vorheriger Freigabe auf einzelne Systeme beschränken, ohne allgemeinen Netzwerkzugang zu gewähren.
Warum beendet Fortinet den SSL-VPN Tunnel Mode?
Die strategische Richtung war bereits vor FortiOS 7.6.3 erkennbar. Fortinet weist in seiner FortiClient-Dokumentation ausdrücklich darauf hin, dass SSL-VPN in der Praxis aktiv angegriffen wird, und priorisiert für Remote-Access-Szenarien verstärkt IPsec und ZTNA.
Das bedeutet allerdings nicht, dass IPsec unangreifbar wäre. Auch ein öffentlich erreichbarer IKE/IPsec-Endpunkt stellt eine Angriffsfläche dar und muss aktuell gehalten, sicher konfiguriert und überwacht werden.
Mit der Migration verschwindet die Angriffsfläche also nicht – sie verändert sich. Fortinet ersetzt den proprietären SSL-VPN-Tunnel durch standardbasiertes IPsec und entwickelt diese Remote-Access-Technologie gezielt weiter.
Die verkürzte Aussage „Fortinet schafft SSL-VPN wegen der vielen Schwachstellen (CVEs) ab“ wäre deshalb zu pauschal. Fortinet dokumentiert SSL-VPN zwar als aktiv angegriffenes Ziel, nennt einzelne Schwachstellen jedoch nicht als alleinigen Grund für die Abschaffung des Tunnel Mode.
Bei kleineren FortiGate-Modellen kommt ein weiterer Faktor hinzu: Fortinet nennt Performance- und Speicheroptimierung als Grund dafür, proxybasierte Funktionen auf Modellen mit 2 GB Arbeitsspeicher oder weniger nicht mehr anzubieten.
Welche FortiGate-Modelle sind betroffen?
Die Situation ist komplexer als nur „ab FortiOS 7.6.3“. Mehrere Einschränkungen greifen bereits früher.
|
FortiOS-Einschnitt |
Betroffene Modelle |
Auswirkung |
|
ab 7.2.12 |
90G-Serie und Varianten |
SSL-VPN Tunnel und Web Mode nicht verfügbar |
|
ab 7.4.4 |
40F, 50G, 60E, 60F, 80E, 90E und Varianten sowie FGR-60F mit 2 GB RAM |
proxybasierte Funktionen einschließlich ZTNA Access Proxy entfallen |
|
ab 7.4.8 |
50G-, 70G- und 90G-Serie samt Varianten |
SSL-VPN Tunnel und Web Mode nicht verfügbar |
|
7.6.0 / 7.6.1 |
insbesondere 40F, 60F/61F und FGR-60F; betroffene Varianten unterscheiden sich je Release |
SSL-VPN Tunnel und Web Mode bereits entfernt |
|
ab 7.6.3 |
alle FortiGate-Modelle |
SSL-VPN Tunnel Mode generell entfernt |
|
Agentless VPN ab 7.6.3 / 7.6.5 |
7.6.3: u. a. 40F, 60F/61F, FGR-60F 2 GB, 90G/91G; ab 7.6.5 zusätzlich 50G- und 70G-Serien und Varianten |
Agentless VPN nicht verfügbar |
Nicht aufgeführte FortiGate-Modelle unterstützen Agentless VPN weiterhin. Ob eine FortiGate zur 2-GB-Klasse gehört, lässt sich direkt per CLI mit diagnose hardware sysinfo conserve prüfen; Fortinet nennt einen angezeigten Gesamtspeicher unter 2000 MB als Kriterium.
Entscheidend sind damit das konkrete FortiGate-Modell, die eingesetzte FortiOS-Version und die gewünschte Zieltechnologie. Bei älteren oder kleinen Geräten kann aus der Remote-Access-Migration gleichzeitig ein Austausch der vorhandenen FortiGate werden.
Wie lange kann ich meine aktuelle FortiOS-Version noch nutzen?
Neben der technischen Unterstützung ist der Produktlebenszyklus (Lifecycle) entscheidend.
End of Engineering Support (EoES):
Mit diesem Datum endet die reguläre Engineering-Phase. Die Software wechselt anschließend in Fortinets sogenannte Urgent-Fix-Phase. Reguläre Funktionsverbesserungen und normale Fehlerkorrekturen sind dann nicht mehr vorgesehen; Maintenance Builds beschränken sich auf entsprechend schwerwiegende Probleme und Sicherheitslücken.
End of Support (EOS):
Mit diesem Datum endet der reguläre Support der Softwarelinie. Danach sollte die betreffende FortiOS-Version nicht mehr als langfristige Plattform für produktive Systeme eingeplant werden.
|
FortiOS |
End of Engineering Support |
End of Support |
|
7.2 |
31.03.2025 |
30.09.2026 |
|
7.4 |
11.05.2027 |
11.11.2028 |
|
7.6 |
25.07.2028 |
25.01.2030 |
Fortinet verlängerte die EoES- und EOS-Termine für FortiOS 7.4 und 7.6 im März 2026 jeweils um ein Jahr.
Für viele Unternehmen ergibt sich daraus eine klare Kausalkette:
SSL-VPN funktioniert heute noch → FortiOS nähert sich dem Supportende → ein Upgrade wird notwendig → die Zielversion unterstützt SSL-VPN Tunnel Mode nicht mehr → der Remote Access muss vorher migriert werden.
Was passiert beim Upgrade auf FortiOS 7.6.3?
Bestehende SSL-VPN-Tunnel-Konfigurationen und die damit verbundenen Firewall-Regeln werden nicht automatisch auf IPsec umgestellt beziehungsweise übernommen.
Der entscheidende Merksatz lautet:
Das FortiOS-Upgrade ist nicht der Beginn der Migration, sondern ihr Abschluss.
Solange die bisherige FortiOS-Version SSL-VPN noch unterstützt, kann der alte Zugang während der Pilotierung als kontrollierte Rückfallmöglichkeit bestehen bleiben. Nach dem Upgrade auf FortiOS 7.6.3 ist diese Option beendet.
Für den bisherigen Web Mode gilt dagegen: Die Konfiguration bleibt auf unterstützten Modellen erhalten und läuft unter dem neuen Namen Agentless VPN weiter.
Wann ist IPsec der richtige Ersatz?
Benötigt ein Benutzer weiterhin vollständigen Netzwerkzugriff – technisch einen Layer-3-Zugriff –, ist Dial-up IPsec mit IKEv2 der naheliegendste Ersatz für den bisherigen SSL-VPN Tunnel Mode.
Aus Sicht des Benutzers bleibt das Prinzip ähnlich: Der Client baut eine verschlüsselte Verbindung zur FortiGate auf und erhält Zugriff auf die dafür freigegebenen internen Netze.
Für neue IPsec-VPN-Verbindungen sollte IKEv2 verwendet werden. Es wird unter anderem für die SAML-basierte Benutzeranmeldung benötigt.
Wie funktioniert IPsec über TCP-Port 443?
Klassisches Dial-up IPsec arbeitet üblicherweise über UDP. Fortinet unterstützt zusätzlich TCP als Transportweg.
Dadurch kann TCP-Port 443 – der üblicherweise für HTTPS verwendete Port – für IPsec genutzt werden. Der VPN-Verkehr wird dadurch nicht zu HTTPS; er verwendet lediglich denselben TCP-Port.
Das kann insbesondere in Hotel-WLANs, Gastnetzen, fremden Unternehmensnetzen oder Mobilfunknetzen hilfreich sein, wenn klassischer IPsec-Verkehr über UDP blockiert wird.
Bei den Versionsvoraussetzungen ist eine Unterscheidung wichtig:
- TCP-Transport beziehungsweise UDP-zu-TCP-Fallback wird auf FortiGate-Seite ab FortiOS 7.4.2 unterstützt – je nach Konfigurationsvariante. Fortinet führte in 7.4.2 die Kapselung von ESP in TCP ein.
- FortiOS 7.4.6 dokumentiert darüber hinaus das Dial-up-Szenario mit frei konfigurierbarem TCP-Port.
- Auf Client-Seite wird FortiClient 7.4.1 oder höher für IPsec über TCP benötigt.
Seit FortiOS 7.6.5 kann Dial-up IPsec außerdem UDP-Port 443 für die IKE-Aushandlung verwenden. Das ist insbesondere für Migrationen interessant, bei denen SSL-VPN zuvor DTLS über UDP/443 verwendet hat.
Eine wesentliche Einschränkung bleibt:
Der kostenlose FortiClient VPN-only unterstützt IPsec über TCP nicht.
Wer TCP-Port 443 als notwendige Verbindungsoption benötigt, muss deshalb auch die zukünftige FortiClient-Strategie berücksichtigen.
Kann ich den kostenlosen FortiClient weiterverwenden?
Grundsätzlich ja – allerdings mit zunehmend relevanten Einschränkungen.
Der kostenlose FortiClient VPN-only verbleibt derzeit auf der Versionslinie 7.4.3. Fortinet hat für diese Versionslinie auch aktualisierte Builds beziehungsweise Installer mit Sicherheitskorrekturen veröffentlicht; eine neue kostenlose 7.4.x-Funktionsversion gibt es jedoch nicht. Der Funktionsumfang ist gegenüber den kommerziellen Varianten deutlich reduziert.
Beim kostenlosen FortiClient VPN-only sind außerdem funktionale Einschränkungen zu beachten. Insbesondere die Kombination aus direkter LDAP-/AD-Authentifizierung über EAP-TTLS und FortiToken MFA setzt einen neueren kommerziellen FortiClient voraus und funktioniert mit dem kostenlosen VPN-only Client 7.4.3 nicht.
|
Funktion |
Kostenloser VPN-only Client |
EMS-verwalteter FortiClient |
|
IKEv2-IPsec |
Ja |
Ja |
|
Zertifikatsauthentifizierung |
Ja |
Ja |
|
SAML |
Ja |
Ja |
|
FortiToken MFA grundsätzlich |
Ja |
Ja |
|
direktes LDAP über EAP-TTLS + FortiToken MFA |
Nein |
Ja |
|
IPsec über TCP |
Nein |
Ja |
|
VPN before Logon (Verbindungsaufbau vor der Windows-Anmeldung) |
Nein |
Ja |
|
zentrale Verwaltung |
Nein |
Ja |
|
ZTNA / Geräteprüfung |
Nein |
Ja |
Unter Linux unterstützt der kostenlose VPN-only Client kein IPsec-VPN. Lizenzierte FortiClient-Varianten müssen deshalb bei Linux-Endgeräten separat betrachtet werden.
Brauche ich für IPsec FortiClient EMS?
Technisch nicht zwingend.
Für kleinere Umgebungen, die vor allem einen aktuellen kommerziellen IPsec-Client benötigen, kann der FortiClient Standalone infrage kommen. Er arbeitet ohne EMS, nutzt FortiIdentity Cloud für Lizenzierung, Authentifizierung und Benutzerverwaltung und unterstützt IKEv2-IPsec unter Windows, macOS und Linux.
Für typische Unternehmensumgebungen empfehlen wir jedoch einen zentral über FortiClient EMS verwalteten FortiClient. Damit lassen sich VPN-Profile, Zertifikate und Clientkonfigurationen einheitlich verteilen und verwalten. Gleichzeitig schafft EMS die Grundlage für Geräteidentität, Prüfung des Endgerätezustands und clientbasiertes ZTNA.
Bei der klassischen endpointbasierten ZTNA-Lizenz dokumentiert Fortinet eine Mindestabnahme von 25 Endpunkten. Fortinet bietet daneben auch userbasierte Lizenzmodelle an; insbesondere bei kleinen Umgebungen sollte die konkrete Lizenzierung deshalb geprüft werden.
esko-systems bietet FortiClient EMS auch als Managed Service an. Damit können Unternehmen die zentrale FortiClient-Verwaltung nutzen, ohne die EMS-Plattform selbst betreiben zu müssen.
Was passiert mit dem bisherigen Webportal?
Der bisherige SSL-VPN Web Mode heißt seit FortiOS 7.6.3 Agentless VPN. Bestehende Web-Mode-Konfigurationen bleiben auf unterstützten Modellen gültig; auch die zugrunde liegende CLI-Konfiguration bleibt unverändert.
Agentless VPN stellt definierte interne Ressourcen über ein Webportal bereit, ohne dass auf dem Endgerät ein FortiClient installiert werden muss. Dazu gehören je nach Konfiguration beispielsweise HTTP/HTTPS, FTP, SFTP, SMB, RDP, VNC, SSH und Telnet.
Das eignet sich etwa für einzelne interne Anwendungen, administrative Einzelzugriffe oder externe Benutzer, bei denen kein Client installiert werden soll.
Agentless VPN ersetzt jedoch keinen vollständigen Netzwerk-Tunnel. Je nach Anwendung bestehen funktionale Grenzen; insbesondere komplexere Webanwendungen oder bestimmte RDP-/VNC-Szenarien sollten deshalb vorab getestet werden.
Wann ist ZTNA sinnvoller als ein VPN-Tunnel?
Zero Trust Network Access (ZTNA) verfolgt einen anderen Ansatz als ein klassisches VPN.
Statt einem Benutzer Zugang zu einem gesamten Netzwerk zu geben, wird der Zugriff möglichst auf eine definierte Anwendung oder ein konkretes Zielsystem begrenzt.
Clientbasiertes Fortinet-ZTNA kann neben der Benutzeridentität auch die Geräteidentität und den Sicherheitszustand des Endgeräts (Endpoint Posture) berücksichtigen.
Für klassische Infrastrukturkommunikation bleibt IPsec dagegen häufig einfacher und robuster – etwa für Domain Controller, DNS, Gruppenrichtlinien, komplexe AD-/Kerberos-/RPC-Abhängigkeiten oder Legacy-Anwendungen mit vielen dynamischen Verbindungen.
Bei in eine Windows-Domäne eingebundenen Notebooks kann zusätzlich eine VPN-Verbindung bereits vor der Windows-Anmeldung („VPN before Logon“) erforderlich sein, damit der Domain Controller schon vor der Benutzeranmeldung erreichbar ist.
Können IPsec und ZTNA dauerhaft gemeinsam eingesetzt werden?
Ja. Ein Mischbetrieb ist kein Provisorium.
Eine sinnvolle Kombination kann beispielsweise sein:
IPsec für notwendige Infrastruktur- und Legacy-Kommunikation – ZTNA für klar definierte Benutzeranwendungen.
Die Leitlinie lautet: So wenig klassischer Netzwerk-VPN-Zugriff wie notwendig – so viel anwendungsbezogener Zugriff wie sinnvoll.
Was setzt clientbasiertes ZTNA voraus?
Für das vollständige clientbasierte Fortinet-ZTNA wird ein EMS-verwalteter FortiClient eingesetzt. EMS stellt unter anderem Geräteidentität, Zertifikate und Informationen über den Sicherheitszustand des Endgeräts bereit.
Zusätzlich muss die FortiGate den ZTNA Access Proxy unterstützen. Physische FortiGate-Modelle mit 2 GB RAM oder weniger scheiden für diese proxybasierten ZTNA-Funktionen aus.
Unterstützt ZTNA auch UDP?
Ja. UDP ist bei aktuellen Fortinet-ZTNA-Versionen kein grundsätzliches Ausschlusskriterium mehr.
Das bedeutet aber nicht automatisch, dass jede komplexe Infrastrukturkommunikation ein sinnvoller ZTNA-Anwendungsfall wird. Entscheidend ist, ob die Anwendung dauerhaft sinnvoll als definierte Ressource verwaltet werden kann.
Was ist der Unterschied zwischen Agentless VPN und agentless ZTNA?
Neben Agentless VPN existiert seit FortiOS 7.6.1 agentless ZTNA (ZTNA Web Portal). Auch hier greifen Benutzer ohne FortiClient über einen Browser auf definierte Anwendungen zu. Das Portal übernimmt Authentifizierung und Autorisierung.
|
Merkmal |
Agentless VPN |
Agentless ZTNA |
|
Prinzip |
bisheriges SSL-VPN-Webportal |
anwendungsbezogener Zugriff über ZTNA Access Proxy |
|
Client / Geräteprüfung |
kein Client, keine vollständige Posture-Prüfung |
kein Client, keine vollständige Posture-Prüfung |
|
Anwendungen |
Web, RDP, SSH, SMB, SFTP, FTP, VNC, Telnet |
definierte Anwendungen und Bookmarks über das ZTNA-Portal |
|
Benutzeranmeldung |
u. a. LDAP/RADIUS, SAML, FortiToken |
ZTNA-Authentifizierung, z. B. LDAP oder SAML |
|
Hardware |
eigene Modell-Ausnahmeliste |
ZTNA Access Proxy erforderlich; 2-GB-Modelle scheiden aus |
|
Typischer Einsatz |
bestehende Portalzugänge |
neue clientlose, anwendungsbezogene Zugriffe |
SAML kann bei beiden Ansätzen genutzt werden, um die Anmeldung an einen zentralen Identity Provider zu delegieren.
Da bei beiden agentlosen Varianten die vollständige Geräteprüfung des clientbasierten ZTNA fehlt, sollten Zugriffe besonders restriktiv freigegeben und mit einer starken Benutzeridentität sowie möglichst starker Authentifizierung abgesichert werden.
Unsere Empfehlung lautet: Bestehendes Agentless VPN muss nicht ohne Grund ersetzt werden. Bei neuen clientlosen Anwendungsszenarien würden wir zunächst agentless ZTNA prüfen, sofern FortiGate und Anwendung dafür geeignet sind.
Der Grund ist nicht, dass Agentless VPN bereits abgekündigt wäre. Agentless ZTNA fügt sich bei neuen Projekten jedoch besser in ein anwendungsbezogenes Zugriffsmodell ein.
Wann ist FortiSASE sinnvoll?
FortiSASE ist nicht einfach ein weiterer VPN-Ersatz, sondern ein anderes Betriebsmodell für verteilte Benutzer und Standorte.
Fortinet unterscheidet insbesondere drei zentrale Anwendungsfälle:
- Secure Internet Access (SIA): zentral abgesicherter Internetzugriff für mobile oder standortbasierte Benutzer.
- Secure Private Access (SPA): abgesicherter Zugriff auf private Unternehmensanwendungen.
- Secure SaaS Access (SSA): Kontrolle und Absicherung von SaaS-Anwendungen.
Für viele Unternehmen ist insbesondere SIA interessant: Auch wenn Mitarbeiter im Homeoffice, Hotel oder unterwegs auf das Internet zugreifen, können zentrale Sicherheitsrichtlinien durchgesetzt werden. Dazu gehören unter anderem IPS, Application Control, Web- und DNS-Filter, Malware-Schutz, Sandboxing und Schutz vor Command-and-Control-Verbindungen.
FortiSASE sollte deshalb insbesondere geprüft werden, wenn viele Benutzer mobil arbeiten, mehrere Standorte bestehen, ein hoher Cloud-/SaaS-Anteil vorhanden ist oder Internetzugriff und Remote Access stärker über eine gemeinsame Cloud-Security-Architektur abgesichert werden sollen.
Für die Benutzeranmeldung kann FortiSASE in bestehende Identitätsdienste integriert werden, beispielsweise über Active Directory/LDAP, RADIUS oder SAML.
Für überwiegend lokal betriebene KMU-Umgebungen kann dagegen eine Kombination aus FortiGate, IPsec und EMS/ZTNA die einfachere Lösung bleiben.
Welche Authentifizierung ist für IPsec-VPN sinnvoll?
Für neue IPsec-VPN-Verbindungen sind insbesondere zertifikatsbasierte Authentifizierung und SAML relevant.
Zertifikate eignen sich besonders für zentral verwaltete Unternehmensgeräte und ermöglichen eine starke kryptografische Identität des Clients beziehungsweise Geräts. Über SAML kann die Benutzeranmeldung dagegen an einen zentralen Identity Provider wie Microsoft Entra ID oder FortiAuthenticator delegiert werden.
Gerade bei administrativen und anderen privilegierten Zugängen sollten dabei möglichst phishing-resistente Authentifizierungsverfahren eingesetzt werden. Dazu gehören beispielsweise:
- Passkeys auf FIDO2-Basis
- FIDO2-Hardware-Sicherheitsschlüssel, etwa per USB oder NFC
- Windows Hello for Business
- geeignete zertifikatsbasierte Benutzerauthentifizierung
Bei IPsec lässt sich FIDO2 beziehungsweise ein Passkey beispielsweise über SAML einbinden:
FortiClient → IKEv2/IPsec → SAML → Identity Provider → FIDO2/Passkey
FIDO2 ist damit kein direktes IKEv2-EAP-Verfahren. Die phishing-resistente Benutzeranmeldung findet am Identity Provider statt, während die FortiGate die erfolgreiche SAML-Anmeldung für den VPN-Zugang verwendet.
Klassische MFA-Verfahren bleiben weiterhin möglich. Dazu gehören beispielsweise FortiToken Mobile mit OTP oder Push sowie MFA über RADIUS. Sie erhöhen die Sicherheit gegenüber einer reinen Kennwortanmeldung deutlich, gelten jedoch nicht automatisch als phishing-resistent.
|
Verfahren |
Typischer Einsatz |
Besonderheit |
|
Zertifikat |
verwaltete Unternehmensgeräte |
starke Client-/Geräteidentität; zentral über eine PKI steuerbar |
|
SAML |
zentrale Benutzeranmeldung über einen Identity Provider |
ermöglicht moderne MFA sowie FIDO2/Passkeys |
|
LDAP + EAP-TTLS |
direkte AD-/LDAP-Benutzeranmeldung |
FortiToken MFA ist mit dem kostenlosen VPN-only Client 7.4.3 nicht möglich |
|
RADIUS |
bestehende zentrale Authentifizierungs- oder MFA-Infrastruktur |
flexibel und abhängig vom eingesetzten Authentifizierungs-Backend |
SAML allein macht eine Anmeldung nicht phishing-resistent. Entscheidend ist, mit welchem Verfahren der Identity Provider den Benutzer tatsächlich authentifiziert. Für privilegierte Zugänge sollten deshalb nach Möglichkeit phishing-resistente Verfahren bevorzugt werden.
Wann ist FortiPAM für externe Dienstleister sinnvoll?
Externe Administratoren, Maschinenbauer, Wartungsfirmen und OT-Techniker benötigen häufig keinen allgemeinen Zugang zum Unternehmensnetz.
Meist geht es darum, ein bestimmtes System zu administrieren, eine Maschine zu warten oder für einen begrenzten Zeitraum eine konkrete Tätigkeit durchzuführen.
Genau für solche Szenarien kann FortiPAM sinnvoller sein als ein klassischer VPN-Zugang.
FortiPAM ermöglicht unter anderem:
- Zugriff nur auf definierte Zielsysteme,
- rollenbasierte Berechtigungen,
- vorherige Freigabe- und Genehmigungsprozesse,
- zeitlich begrenzte Zugriffe,
- Schutz privilegierter Zugangsdaten,
- Überwachung, Auditierung und Aufzeichnung privilegierter Sitzungen.
Die zentrale Idee lautet:
Nicht dem Dienstleister Zugang zum Netzwerk geben, sondern ihm für einen definierten Zeitraum genau den Zugriff ermöglichen, den er für seine Aufgabe benötigt.
Wie greifen externe Dienstleister ohne FortiClient zu?
Für solche Anforderungen bietet sich beispielsweise folgende Architektur an:
externes Endgerät → Browser → agentless ZTNA Portal → JumpHost → FortiPAM → Zielsystem
Der JumpHost ist ein zentral verwaltetes und gehärtetes Zwischensystem, von dem aus die eigentliche administrative Verbindung aufgebaut wird.
Auf dem Endgerät des externen Dienstleisters ist kein FortiClient erforderlich. Über den JumpHost können dennoch native Werkzeuge wie RDP oder SSH genutzt werden, während FortiPAM Berechtigungen und privilegierte Zugangsdaten kontrolliert.
Zu berücksichtigen sind zusätzliche Infrastruktur und mehrere Anmeldestufen.
Welche Lösung passt zu welchem Anwendungsfall?
|
Anforderung |
Typischer Ansatz |
|
bisherigen SSL-VPN-Tunnel möglichst direkt ersetzen |
IPsec |
|
Windows-Domäne, Anmeldung vor Windows, Gruppenrichtlinien |
IPsec |
|
komplexe AD-/Kerberos-/RPC- oder Legacy-Abhängigkeiten |
IPsec |
|
definierte Anwendungen auf verwalteten Geräten |
ZTNA |
|
Zugriff abhängig vom Gerätezustand |
ZTNA + EMS |
|
Infrastruktur plus definierte Anwendungen |
IPsec + ZTNA |
|
bestehender browserbasierter Portalzugriff ohne Client |
Agentless VPN |
|
neuer anwendungsbezogener Zugriff ohne Client |
agentless ZTNA prüfen |
|
einheitliche Internet-Security für mobile Benutzer von überall |
FortiSASE / SIA |
|
private Anwendungen über eine SASE-Architektur |
FortiSASE / SPA |
|
zentral abgesicherter SaaS-Zugriff |
FortiSASE / SSA |
|
privilegierte externe Administratoren oder OT-Dienstleister |
FortiPAM |
|
externe Dienstleister ohne Client mit RDP-/SSH-Bedarf |
agentless ZTNA + JumpHost + FortiPAM |
Was sollten Unternehmen jetzt tun?
1. FortiGate und FortiOS erfassen.
Welches Modell, wie viel RAM und welche FortiOS-Version werden eingesetzt? Wie sehen Software- und Hardware-Lifecycle aus?
2. Tatsächliche SSL-VPN-Nutzung ermitteln.
Wer nutzt Tunnel Mode, wer das Webportal? Welche Benutzer benötigen wirklich vollständigen Netzwerkzugriff?
3. Clients und Authentifizierung erfassen.
Kostenloser VPN-only Client, FortiClient Standalone oder EMS-verwalteter Client? Werden Zertifikate, SAML, LDAP, RADIUS oder FortiToken eingesetzt?
4. Benutzergruppen unterscheiden.
Mitarbeiter, Administratoren sowie externe Wartungs- und Servicepartner haben unterschiedliche Anforderungen.
5. Anwendungen klassifizieren.
Welche Zugriffe benötigen wirklich einen Netzwerk-Tunnel? Welche lassen sich gezielt per ZTNA oder browserbasiert bereitstellen?
6. Authentifizierung modernisieren.
Für neue IPsec-VPN-Verbindungen insbesondere Zertifikats- und SAML-Konzepte prüfen. Bei privilegierten Zugängen phishing-resistente Verfahren bevorzugen.
7. Zielarchitektur und Hardwarefähigkeit festlegen.
IPsec, ZTNA, Hybridbetrieb, Agentless Access, FortiSASE oder FortiPAM anhand des tatsächlichen Bedarfs auswählen.
8. Neue Lösung parallel aufbauen und mit einer Pilotgruppe testen.
Zu prüfen sind insbesondere Anmeldung und MFA, Zertifikate, DNS und interne Namensauflösung, Routing, interne Anwendungen, RDP und Dateifreigaben, Split- und Full-Tunnel, Standby und Netzwerkwechsel sowie Mobilfunk-, Hotel- und Gast-WLAN.
9. Benutzer schrittweise migrieren und anschließend FortiOS aktualisieren.
Der SSL-VPN-Tunnel bleibt bis zur erfolgreichen Abnahme als Rückfallmöglichkeit bestehen. Erst danach wird er stillgelegt und FortiOS aktualisiert.
Wie unterstützt Sie esko-systems?
Wir prüfen mit Ihnen zunächst, wo tatsächlich Handlungsbedarf besteht: Welche FortiGate-Modelle und FortiOS-Versionen sind im Einsatz, welche Benutzer verwenden heute SSL-VPN und welche Zugriffe werden künftig benötigt?
Darauf aufbauend entwickeln wir gemeinsam mit Ihnen eine passende Zielarchitektur – vom Wechsel auf IKEv2-IPsec über eine Kombination aus IPsec und ZTNA bis hin zu agentlosen Zugriffsverfahren oder FortiPAM für externe Wartungs- und Administrationszugriffe.
Dabei betrachten wir nicht nur die Firewall, sondern auch FortiClient, Zertifikate, SAML, MFA, Clientverwaltung und Lizenzierung.
Für Unternehmensumgebungen empfehlen wir in der Regel eine zentrale FortiClient-Verwaltung über FortiClient EMS. esko-systems bietet FortiClient EMS auch als Managed Service an, sodass Sie die zentrale Verwaltung Ihrer FortiClients nutzen können, ohne die Plattform selbst betreiben zu müssen.
Ziel ist nicht, möglichst viele neue Komponenten einzuführen, sondern eine Remote-Access-Architektur zu schaffen, die zu Ihrer Umgebung, Ihren Sicherheitsanforderungen und Ihrem Betriebsaufwand passt.
Fazit
Fortinet beendet mit FortiOS 7.6.3 den klassischen SSL-VPN Tunnel Mode. Für bestehende Installationen bedeutet das jedoch nicht, dass Remote Access vollständig neu erfunden werden muss.
IPsec ist der naheliegende Ersatz, wenn weiterhin vollständiger Netzwerkzugriff benötigt wird. ZTNA ergänzt diesen Ansatz dort, wo Zugriffe auf konkrete Anwendungen begrenzt werden können. Agentless VPN kann bestehende browserbasierte Portalzugänge weiter abbilden, während agentless ZTNA bei neuen clientlosen Anwendungsszenarien geprüft werden sollte. FortiSASE ergänzt diese Ansätze insbesondere um zentral geschützten Internet-, SaaS- und Private-Application-Zugriff für verteilte Benutzer. FortiPAM eignet sich für gezielte, zeitlich begrenzte und nachvollziehbare privilegierte Zugriffe.
Gleichzeitig sollte die Migration genutzt werden, um FortiClient-Verwaltung und Authentifizierung zu modernisieren.
Erst die passende Remote-Access-Strategie festlegen und migrieren – dann FortiOS aktualisieren.
