Ich habe jahrelang auf FortiClient mit SSLVPN gesetzt. Kein Browser, kein Web-Portal — Client starten, Verbindung steht, 2FA per FortiToken Push fest eingebaut. Ausgereift, stabil, genau das, was es sollte. Dass Fortinet damit jetzt Schluss macht, ist ein Einschnitt, den viele noch nicht realisiert haben.

Was passiert ist

Mit FortiOS 7.6.3 hat Fortinet den SSLVPN-Tunnel-Mode entfernt — auf allen Modellen, nicht nur auf den kleinen mit 2 GB RAM, wo er schon vorher rausflog. Kein GUI, kein CLI, kein Upgrade-Pfad: Bestehende Konfigurationen werden beim Update nicht übernommen. Wer auf 7.6.3 aktualisiert, ohne vorher zu migrieren, hat schlicht keinen SSLVPN-Tunnel mehr.

Ein Detail, das gern untergeht: Der Web-Mode bleibt — allerdings umbenannt in „Agentless VPN" und auf einen reinen HTTPS-Reverse-Proxy zu internen Web-Anwendungen reduziert. Kein Client-Tunnel, keine gemappten Laufwerke. Als Ersatz für den vollwertigen Tunnel taugt das nicht; Fortinet selbst verweist dafür auf IPsec. Die Abschaltung kam übrigens in Etappen: erst die 2-GB-RAM-Modelle (ab 7.6.0), dann die G-Serie (ab 7.4.8), schließlich flächendeckend mit 7.6.3.

Der Ersatz: IPsec IKEv2

Nachfolger ist IPsec IKEv2, das inzwischen auch über TCP-Port 443 laufen kann — praktisch dort, wo restriktive Netze nur TCP-443 nach draußen lassen. Und der Wechsel ist nicht nur ein notwendiges Übel: IPsec arbeitet auf Layer 3 nah am Kernel und lässt sich auf FortiGates in Hardware beschleunigen, während SSLVPN den Verkehr im User-Space über TLS abwickelt. Ergebnis: tendenziell höherer Durchsatz und niedrigere Latenz — genau dieser Ressourcenhunger war ein Grund, warum SSLVPN auf schwacher Hardware zuerst wich.

Und die 2FA? Kein Problem mehr: Mit aktuellen FortiClient- und FortiOS-Versionen funktioniert IPsec IKEv2 mit einem vorgeschalteten SAML-Identity-Provider gut — in meinem Fall der FortiAuthenticator, mit FortiToken Mobile per Push. Der Client bleibt derselbe wie vorher, nur das Protokoll dahinter ändert sich.

Warum Fortinet das tut

Zwei Gründe greifen ineinander. Erstens Sicherheit: SSLVPN war jahrelang ein bevorzugtes Angriffsziel — pre-auth RCE im SSLVPN-Parser gleich in mehreren Jahren (CVE-2023-27997, CVE-2024-21762, CVE-2022-42475), dazu ein 2FA-Bypass (CVE-2020-12812), der Ende 2025 erneut aktiv ausgenutzt wurde. Ein öffentlich erreichbarer Dienst, der untrusted Traffic terminiert und Nutzer ins Netz lässt, ist eine große Angriffsfläche; irgendwann ist das Entfernen billiger als das Verteidigen. Zweitens das Geschäftsmodell: Fortinet will die Kunden in die SASE-Welt schieben. FortiSASE ist ein Abo pro User und Monat — wiederkehrende Einnahmen statt einmaliger Hardware-Verkäufe. Beides ist real; wer nur eines sieht, macht es sich zu einfach.

Die verpasste Chance: WireGuard

Was mich ärgert: Als Ersatz greift Fortinet ausgerechnet zu IPsec, einem Protokoll aus den späten Neunzigern — bewährt und schnell, aber komplex. Daneben steht seit Jahren WireGuard: schlank, moderne Codebasis im niedrigen vierstelligen Zeilenbereich (weniger Angriffsfläche), minimaler Handshake, hervorragendes Roaming, beim Durchsatz mindestens auf Augenhöhe. Fortinet implementiert es trotzdem nicht als Remote-Access-Protokoll. Das ist kein Zufall: Ein schlankes, offenes, leicht selbst zu betreibendes Protokoll passt schlecht in eine Strategie, deren Ziel das verwaltete Cloud-Abo ist.

Und das ist keine reine Fortinet-Kritik. Das Muster zieht sich durch die Branche: Neukunden werden mit attraktiven Konditionen an den Cloud-Futtertrog gelockt, und sind sie erst drin — Infrastruktur beim Hersteller, eigenes Know-how verkümmert, Wechsel teuer —, ziehen die Preise Schritt für Schritt an. Dasselbe Spiel bei Palo Alto (Prisma Access), Cisco und Zscaler. Nicht der einmalige Verkauf, sondern die dauerhafte Abhängigkeit ist das Produkt.

Wer draufzahlt — und wie man gegenhält

Am härtesten trifft es die, denen die Expertise fehlt, solche Lösungen selbst zu betreiben. Der bequemste Weg ist dann der in die Cloud: SASE kaufen, konfigurieren lassen, monatlich zahlen. Komfortabel, aber abhängig. Wer dagegen versteht, wie ein IPsec-Tunnel aufgebaut wird und was ein Identity Provider leistet, ist nicht erpressbar — der kann entscheiden, ob ein SASE-Abo Vorteile bringt oder ob er es bleiben lässt, weil er es selbst kann.

Der Weg ohne Abo ist aufwändiger als SSLVPN, aber einmaliger Aufwand:

  1. FortiAuthenticator als SAML Identity Provider konfigurieren
  2. FortiGate als Service Provider für IPsec IKEv2 mit SAML-Auth einrichten
  3. FortiClient EMS aufsetzen und die VPN-Konfiguration als Provisioning-Profil hinterlegen
  4. Massenausrollung über EMS — Windows, macOS, iOS, Android bekommen die fertige Konfiguration inklusive Zertifikat und SAML-Endpunkt

Einmal im EMS definiert, muss man an keinem Client mehr herumfummeln: Der Nutzer klickt auf „Installieren", und der Tunnel steht.

Bleibt ein fader Beigeschmack

Dass ein Feature, das jahrelang einwandfrei lief, einfach verschwindet, ist ein harter Schnitt — auch wenn die Sicherheitsargumente stichhaltig sind. Die Message ist unüberhörbar: Du sollst in die Cloud. Ich halte dagegen: Wer sein eigenes IPsec mit SAML aufsetzt, behält die Kontrolle. Kein Abo, keine Cloud-Abhängigkeit, kein Vendor-Lock-in über das nötige Maß hinaus. Und das Wissen, das man dabei aufbaut, nimmt einem keiner mehr.

Bei mir läuft jetzt IPsec mit SAML — und es funktioniert. Vermissen werde ich den SSLVPN trotzdem. Vor allem die Einfachheit, die er bot.