SSL-VPN in FortiOS 7.6 entfernt: Migrationsplan zu IPsec und ZTNA

Die Entfernung des FortiGate-SSL-VPN erfolgte in zwei Schritten: FortiOS 7.6.0 entfernte Web- und Tunnelmodus auf Einstiegsmodellen mit höchstens 2 GB RAM, und FortiOS 7.6.3 vom April 2025 ersetzte den SSL-VPN-Tunnelmodus auf allen FortiGate-Modellen durch IPsec VPN. Bestehende Einstellungen werden beim Upgrade nicht übernommen; der Fernzugriff muss vor dem Firmware-Upgrade auf IPsec IKEv2 oder ZTNA umgestellt werden.

Was hat sich beim SSL-VPN in FortiOS 7.6 geändert?

Die SSL-VPN-Änderung in FortiOS 7.6 verteilt sich auf drei Release Notes: 7.6.0 entfernte Web- und Tunnelmodus auf Einstiegsmodellen, 7.6.1 präzisierte die Liste der betroffenen Modelle, und 7.6.3 ersetzte den Tunnelmodus auf allen Modellen durch IPsec VPN und benannte den Webmodus in „Agentless VPN" um. In keinem Schritt werden alte Einstellungen in die neue Firmware übernommen.

Es handelt sich um eine Entfernung, nicht um eine Abkündigungswarnung. Der Sonderhinweis in Fortinets Release Notes zu FortiOS 7.6.3 stellt fest, dass der SSL-VPN-Tunnelmodus in GUI und CLI nicht mehr verfügbar ist, dass Einstellungen aus früheren Versionen nicht aktualisiert werden und dass dies für alle FortiGate-Modelle gilt. Derselbe Hinweis fordert Kunden auf, ihre SSL-VPN-Tunnelkonfiguration vor dem Upgrade auf 7.6.3 zu IPsec VPN zu migrieren, um den Fernzugriff unterbrechungsfrei zu halten.

In unserer Projektpraxis beginnt der häufigste Vorfall mit dem Anruf nach dem Upgrade: „Das VPN-Portal ist verschwunden." Tunnel-Einstellungen, zugehörige Firewall-Richtlinien und Portal-Zuordnungen werden beim Upgrade verworfen; der einzige Weg zurück führt über die vorherige Firmware und ein Konfigurations-Backup. Die Änderung Release für Release zu lesen, ist die Voraussetzung für das richtige Timing.

Dieselben Release Notes ergänzen, dass Modelle mit 2 GB RAM im 7.6-Zweig auch proxybasierte Funktionen, Security Rating und die Security-Fabric-Topologie verlieren. Auf diesen Geräten geht es also nicht nur um VPN, sondern um eine Lebenszyklusentscheidung für den gesamten 7.6-Zweig. Ab 7.6.4 (einschließlich FortiOS 8.0.0) lautet der Hinweis allgemein „einige FortiGate-Modelle"; prüfen Sie daher Modellliste und Termine stets am aktuellen Text in der Fortinet Document Library.

Welche FortiGate-Modelle und Unternehmen sind betroffen?

Betroffene FortiGate-Modelle lassen sich in zwei Gruppen teilen: Auf 40F, 60F/61F und FGR-60F mit 2 GB RAM sowie auf 90G/91G bleibt weder Tunnelmodus noch Agentless VPN; auf allen anderen Modellen entfällt der Tunnelmodus mit 7.6.3, Agentless VPN bleibt. Praktisch ist jeder FortiGate-Betreiber betroffen, der Fernzugriff über SSL-VPN bereitstellt.

Die Speicherklasse Ihres Geräts prüfen Sie in der CLI mit diagnose hardware sysinfo conserve; liegt der Gesamt-RAM unter 2000 MB, fällt das Gerät unter Fortinets Definition der „2-GB-Klasse". Das ist besonders bei Modellen wie der FGR-60F relevant, die in mehreren Speichervarianten ausgeliefert wurde. Einen Kapazitätsvergleich der Familien finden Sie in unserem Vergleich FortiGate 40F, 60F, 70G und 90G; beachten Sie, dass 90G/91G auf der Agentless-VPN-Ausschlussliste stehen, die 70G in den Release Notes dort jedoch nicht genannt wird.

Nach Unternehmensprofil sind drei Gruppen betroffen:

• KMU mit SSL-VPN-Tunnelmodus und FortiClient: Homeoffice-Mitarbeiter, Zugriff auf Buchhaltung und ERP, Außendiensttechniker. Das ist die größte Gruppe, und sie ist in 7.6.3 ausnahmslos betroffen.
• Unternehmen mit Webportal (Lesezeichen-Zugriff): Betriebe, die Dienstleistern oder nicht verwalteten Geräten RDP-/SSH-/HTTP-Lesezeichen anbieten. Mittlere und größere Modelle können mit Agentless VPN weiterarbeiten; Einstiegsmodelle müssen zu IPsec oder ZTNA wechseln.
• Managed-Service-Provider: Teams, die den Firmware-Stand über Dutzende Kundengeräte hinweg auf einmal anheben. Ein Massen-Upgrade ohne VPN-Inventar pro Kunde ist das riskanteste Szenario.

Der FortiOS-7.4-Zweig führt SSL-VPN weiterhin, und Fortinet hat auch für 7.4 einen eigenen Migrationsleitfaden veröffentlicht. Der Support für 7.4 ist befristet; prüfen Sie die Support-Enddaten auf Fortinets Produktlebenszyklus-Seite. Auf 7.4 zu bleiben, verschafft Zeit, ist aber keine Lösung: Wer für jeden Sicherheitspatch am 7.4-Zweig hängt, verzichtet mittelfristig auf neue Funktionen und Hardware-Support. Festzulegen, welches Gerät Ihres bestehenden FortiGate-Bestands zu welchem Zweig passt, sollte das erste Ergebnis des Migrationsplans sein.

Welche Alternativen gibt es zum SSL-VPN?

Alternativen zum SSL-VPN gibt es in vier Ausprägungen: IKEv2-basiertes Dial-up-IPsec-VPN auf der vorhandenen FortiGate, Agentless VPN für Browserzugriff auf unterstützten Modellen, FortiGate-ZTNA mit FortiClient EMS für anwendungsbezogenen Zugriff sowie das cloudbasierte FortiSASE. Die meisten Unternehmen wechseln zuerst zu IPsec und verlagern anschließend kritische Anwendungen auf ZTNA.

Die Entscheidung folgt Ihrem Zugriffsmodell, nicht der Frage, was am neuesten ist. Thick-Client-Anwendungen, die einen Tunnel auf Netzwerkebene benötigen (Alt-ERP, Dateifreigaben, Druckserver), sind mit IPsec am schnellsten und risikoärmsten versorgt. Wenn Sie nur Web-, RDP- oder SSH-Anwendungen abhängig vom Gerätezustand freigeben möchten, gewährt ZTNA anwendungsbezogenen Zugriff, ohne einen Tunnel zu öffnen. Wenn Sie Filial- und Remote-Verkehr lieber in der Cloud prüfen, als ihn zu einem zentralen Konzentrator zurückzuführen, kommt FortiSASE ins Spiel.

Wie ZTNA funktioniert und worin es sich vom VPN unterscheidet, erläutern wir in Was ist ZTNA? Zero-Trust-Zugriff als VPN-Ersatz; für das Filial- und Remote-Szenario ist Was ist SASE? Der FortiSASE-Ansatz für Filialen die Ergänzung. Produktseitig vereint FortiClient VPN, ZTNA und Endpunktschutz in einem Agenten, während FortiSASE dieselben Zugriffsrichtlinien aus der Cloud durchsetzt.

Wie gelingt die Migration zu IPsec IKEv2 Schritt für Schritt?

Die Migration von SSL-VPN zu IPsec IKEv2 folgt dem zweiteiligen Ansatz aus Fortinets Migrationsleitfaden: Zuerst werden die genutzten Authentifizierungsmethoden und Benutzergruppen dokumentiert, dann wird der IPsec-Dial-up-Tunnel parallel zum SSL-VPN aufgebaut, in das FortiClient-EMS-Profil aufgenommen, mit einer Pilotgruppe validiert, und die übrigen Benutzer ziehen in Wellen um.

Fortinets Leitfaden zur Migration von SSL-VPN zu IPsec VPN betont, dass weder Topologie noch Portnummer geändert werden müssen: Benutzer verbinden sich weiterhin mit TCP 443 auf der WAN-Schnittstelle der FortiGate; der Unterschied ist IKEv2/ESP in TCP gekapselt statt eines TLS-Tunnels. Die IPsec-Grundlagen aus unserem bestehenden Leitfaden zur FortiGate-VPN-Konfiguration bilden das Fundament dieser Schritte.

1. Inventar erstellen. SSL-VPN-Portale, Benutzergruppen und Portal-Zuordnungen, Authentifizierungsquelle (Local, LDAP, RADIUS, SAML), Zwei-Faktor-Nutzung, Split-Tunnel- und DNS-Suffix-Einstellungen, Adresspools und alle an die SSL-VPN-Schnittstelle gebundenen Firewall-Richtlinien auflisten.
2. IKE-Version festlegen. IKEv2 wird empfohlen: TCP-443-Transport funktioniert nur mit IKEv2, SAML-Authentifizierung wird nur auf IKEv2 unterstützt, und FortiClient ab 7.4.4 enthält kein IKEv1 mehr.
3. Authentifizierung zuordnen. Die Tabelle unten zeigt das IPsec-Äquivalent jeder aktuellen Methode. In IPsec ist ein Pre-Shared Key (PSK) oder ein Zertifikat ein Pflichtfeld; die Benutzerauthentifizierung wird über EAP darübergelegt.
4. Tunnel auf der FortiGate aufbauen. Die Remote-Access-Vorlage des VPN-Assistenten erzeugt Dial-up-Tunnel, Adresszuweisung (mode-cfg), Gruppenzuordnung und Richtlinien. Anschließend den Transport auf TCP umstellen.
5. Konflikt mit dem Admin-Port beheben. Wird TCP 443 für IKE genutzt, kann der Verwaltungszugriff über 443 auf derselben Schnittstelle beeinträchtigt werden; ändern Sie entweder den IKE-Port oder den Admin-Port.
6. FortiClient-EMS-Profil aktualisieren. Den IPsec-Tunnel zum Remote-Access-Profil hinzufügen; IKE-Version, Modus und TCP-Transport müssen exakt zur FortiGate passen. Clients benötigen 7.4.1 oder neuer für TCP-Kapselung und 7.4.6 oder neuer, wenn IPv6 erforderlich ist.
7. Pilot und Parallelbetrieb. IPsec für eine kleine Gruppe freigeben, ohne SSL-VPN abzuschalten; MFA, Split Tunneling, DNS-Auflösung und Anwendungszugriff prüfen. Danach die Gruppen umziehen, SSL-VPN-Richtlinien deaktivieren und das Firmware-Upgrade zuletzt durchführen.

Die CLI-Änderung für den TCP-Transport ist kurz; passen Sie den vom Assistenten erzeugten Tunnelnamen an Ihre Umgebung an:

config vpn ipsec phase1-interface
    edit "Fernzugriff-IKEv2"
        set ike-version 2
        set transport tcp
    next
end

config system settings
    set ike-tcp-port 443
end

Authentifizierungszuordnung und Richtlinienbereinigung brauchen immer den Blick eines Ingenieurs. In unseren Projekten bringt das Entfernen jahrelang ungenutzter, an SSL-VPN gebundener Richtlinien oft mehr Sicherheitsgewinn als die Migration selbst.

Wann ist der direkte Wechsel zu ZTNA sinnvoll?

Der Wechsel zu ZTNA ist sinnvoll für Unternehmen, die Fernzugriff pro Anwendung und abhängig vom Gerätezustand statt über einen Netzwerktunnel gewähren möchten. FortiGate arbeitet seit FortiOS 7.0 als ZTNA-Application-Gateway; FortiClient EMS, das Identität und Gerätezustand hält, ist jedoch Pflicht. Für die meisten KMU ist IPsec kurzfristig und ZTNA mittelfristig die ausgewogenste Reihenfolge.

Fortinets ZTNA-Architektur besteht aus drei Teilen: dem FortiClient-ZTNA-Agenten auf dem Endpunkt, FortiClient EMS mit Identität und Gerätezustand (Tags wie Patchstand des Betriebssystems, Antivirus-Status oder Festplattenverschlüsselung) und der FortiGate, die die Zugriffsentscheidung durchsetzt. Fordert ein Benutzer eine Anwendung an, prüft die FortiGate zuerst die EMS-Tags des Geräts und öffnet bei erfüllten Bedingungen ausschließlich den Zugriff auf diese Anwendung. Da kein Netzwerktunnel entsteht, schrumpft der Raum für laterale Bewegung, ein Unterschied, der in Ransomware-Szenarien entscheidend wird.

ZTNA hat in diesen Situationen die Nase vorn:

• Die meisten genutzten Anwendungen sind Web, RDP oder SSH: Kein Tunnel nötig; der ZTNA-Access-Proxy reicht aus.
• Dienstleister, Lieferanten oder BYOD-Geräte sind beteiligt: Einen Netzwerktunnel ohne Zustandsbedingung zu öffnen, ist ein Risiko, das uns in Audit-Befunden immer wieder begegnet.
• FortiClient EMS ist bereits im Einsatz: Existiert EMS für das Endpunktmanagement, lassen sich ZTNA-Tags und -Richtlinien mit überschaubarem Zusatzaufwand aktivieren.

Umgekehrt bleiben alte Thick-Client-Anwendungen, Druck- und Dateiserverzugriff oder Site-to-Site-ähnliche Anforderungen bei IPsec. Deshalb empfehlen wir am häufigsten ein hybrides Modell: Benutzergruppen mit Tunnelbedarf wechseln zu IPsec IKEv2, webbasierte Anwendungen zu ZTNA. Möchten Sie Filial- und Remote-Verkehr in der Cloud statt an einer zentralen FortiGate prüfen, setzt FortiSASE dieselben ZTNA-Richtlinien aus Cloud-PoPs durch; dieses Szenario behandeln wir in unserem FortiSASE-Beitrag. Den konzeptionellen Rahmen von ZTNA finden Sie in unserem ZTNA-Leitfaden.

Migrationsplan und Checkliste vor dem Upgrade

Die Checkliste vor dem Upgrade auf FortiOS 7.6.3 beruht auf einem Grundsatz: Keine FortiGate mit SSL-VPN-Tunnelmodus wird auf 7.6.3 oder neuer angehoben, bevor der IPsec- oder ZTNA-Zugriff in der Produktion validiert ist. Auch Fortinets Release Notes verlangen ausdrücklich, die Migration vor dem Upgrade abzuschließen.

Fortinets Leitfaden überlässt die Entscheidung, ob vor oder nach einem Upgrade migriert wird, den Unternehmensrichtlinien und der Ausfalltoleranz; steht ein kritischer Sicherheitspatch an, kann zuerst das Upgrade sinnvoll sein. Da der Tunnelmodus auf 7.6.3 und neuer aber gar nicht mehr existiert, entfällt die Option „erst upgraden, dann migrieren" an dieser Schwelle faktisch. Die folgende Liste fasst die Reihenfolge zusammen, die wir in unseren Projekten anwenden.

Diese Schritte sind zugleich Teil einer umfassenderen Firewall-Migration; für Unternehmen, die von einem anderen Hersteller zu FortiGate wechseln, wendet unser Schritt-für-Schritt-Migrationsplan dieselbe Disziplin an. Wenn Sie Wartungsfenster, Monitoring und Patch-Verfolgung nicht mit dem eigenen Team tragen möchten, lassen sich VPN-Migration und Firmware-Management gemeinsam im Rahmen eines Managed-Firewall-Service betreiben.

Häufig gestellte Fragen

Ich habe auf FortiOS 7.6.3 aktualisiert und meine SSL-VPN-Benutzer können sich nicht verbinden; kommen die Einstellungen zurück?

Nein. Laut Release Notes werden Tunnelmodus-Einstellungen aus früheren Versionen nicht übernommen und lassen sich in GUI oder CLI nicht neu anlegen. Die Optionen sind die Rückkehr zur vorherigen Firmware aus dem Backup oder der Aufbau des IPsec-IKEv2-Dial-up-Tunnels mit aktualisierten FortiClient-Profilen. Backup und Rollback-Plan sollten vor dem Upgrade bereitliegen, um den Ausfall kurz zu halten.

Sind Agentless VPN und der SSL-VPN-Webmodus dasselbe?

Ja; die Release Notes zu FortiOS 7.6.3 bezeichnen den SSL-VPN-Webmodus als „Agentless VPN". Der Lesezeichen-Zugriff über den Browser bleibt bestehen, doch auf 40F, 60F/61F, FGR-60F (2 GB) und 90G/91G wurde die Funktion aus GUI und CLI entfernt. Auf anderen Modellen ist sie weiterhin verfügbar; prüfen Sie die aktuelle Liste in den Fortinet Release Notes.

Welche FortiClient-Version ist für die IPsec-Migration nötig?

Laut Fortinets Migrationsleitfaden erfordert IPsec über TCP 443 FortiClient 7.4.1 oder neuer; ab FortiClient 7.4.4 wird IKEv1 nicht unterstützt, daher muss IKEv2 verwendet werden. FortiClient 7.4.4 unterstützt kein IPv6; wird IPv6 benötigt, nutzen Sie 7.4.6 oder neuer. Für SAML-Authentifizierung genügt 7.2.4 oder neuer.

Kann ich IPsec VPN ebenfalls auf TCP-Port 443 betreiben?

Ja. Der Transport des IKEv2-Tunnels wird auf TCP gestellt; die FortiGate kapselt IKE- und ESP-Verkehr standardmäßig über TCP 443, der Port lässt sich bei Bedarf ändern. So bleiben Verbindungen in Hotel- und Providernetzen bestehen, in denen UDP 500/4500 blockiert ist. Nutzt der Verwaltungszugriff auf derselben Schnittstelle ebenfalls 443, ändern Sie einen der beiden Ports.

Funktionieren SAML und MFA über IPsec?

Ja. Fortinets Leitfaden stellt fest, dass alle SSL-VPN-Authentifizierungsmethoden zu IPsec migriert werden können: SAML wird nur auf IKEv2 unterstützt, LDAP nutzt auf IKEv2 EAP-TTLS, und FortiToken-Zwei-Faktor lässt sich mit Local, LDAP, RADIUS und SAML kombinieren. Bestehende Benutzer und Gruppen können in der neuen IPsec-Konfiguration weiterverwendet werden.

Kann ich auf FortiOS 7.4 bleiben und SSL-VPN weiter nutzen?

Vorerst ja; der 7.4-Zweig führt SSL-VPN, und Fortinet hat auch für 7.4 einen Migrationsleitfaden veröffentlicht. Laut Fortinets Lebenszyklus-Bulletin läuft der 7.4-Support jedoch nur noch für einen begrenzten Zeitraum; prüfen Sie die aktuellen Termine im Supportportal. Auf 7.4 zu bleiben, verschafft Planungszeit, beseitigt die Migrationsnotwendigkeit aber nicht.

Braucht ZTNA neue Hardware?

Auf FortiGate-Seite in der Regel nicht; FortiOS 7.0 und neuer enthalten die Funktion des ZTNA-Application-Gateways. Ein FortiClient-EMS-Server ist für Posture-Tags jedoch Pflicht; prüfen Sie die Dimensionierung in der aktuellen EMS-Dokumentation. Für Unternehmen ohne Filial-Hardware setzt FortiSASE dieselben Richtlinien aus der Cloud durch.

Fazit

FortiOS 7.6.3 hat den SSL-VPN-Tunnelmodus auf allen FortiGate-Modellen entfernt; die 2-GB-Einstiegsmodelle haben zusätzlich Agentless VPN verloren. Weil Einstellungen beim Upgrade nicht übernommen werden, ist die richtige Reihenfolge klar: Inventar, den IKEv2-IPsec-Dial-up-Tunnel auf TCP 443 parallel aufbauen, FortiClient-EMS-Profile aktualisieren, Pilot und stufenweiser Umzug, Firmware-Upgrade zuletzt. ZTNA für Webanwendungen und Dienstleisterzugriff sowie FortiSASE für verteilte Filialen sind der nächste Schritt.

Als Sora Yazılım erarbeiten wir mit Ihnen die Auswirkungsanalyse Ihres FortiGate-Bestands, den IPsec- oder ZTNA-Migrationsplan und den Upgrade-Kalender. Um Ihre aktuelle Umgebung gemeinsam zu prüfen, vereinbaren Sie ein kostenloses Erstgespräch oder fordern Sie ein Angebot für das Migrationsprojekt an.