FortiGate-SSL-VPN zu NetBird migrieren: der Ablauf

Fernzugriff ablösen, ohne den Betrieb zu unterbrechen? WZ-IT plant und betreibt den Umstieg von VPN-Appliances auf identitätsbasierten Zugriff - NetBird, IdP-Anbindung, Standorte und Maschinen, aus einer Hand. Managed Secure Access ansehen

Mit FortiOS 7.6.3 hat Fortinet den SSL-VPN-Tunnelmodus auf allen FortiGate-Modellen entfernt. Damit wird aus einer Architekturdebatte ein Termin: Jede Remote-Access-Konfiguration muss angefasst werden. Dieser Leitfaden zeigt den Weg zu NetBird - nicht als Konzept, sondern als Ablauf: Bestandsaufnahme, Identitätsanbindung, Peers, Zugriffsrichtlinien, Standorte und Cutover. Stand Juli 2026.

Inhaltsverzeichnis

• Der Anlass und die zwei Wege
• Was sich architektonisch ändert
• Schritt 1: Bestandsaufnahme
• Schritt 2: Control Plane und Identität
• Schritt 3: Peers ausrollen
• Schritt 4: Gruppen und Zugriffsrichtlinien
• Schritt 5: Standorte und Maschinen ohne Client
• Schritt 6: Cutover und Rückweg
• Fallstricke aus der Praxis

Der Anlass und die zwei Wege

Ab FortiOS 7.6.3 ist der SSL-VPN-Tunnelmodus weder in der GUI noch in der CLI verfügbar, und zwar auf allen FortiGate-Modellen. Entscheidend sind zwei Details aus den Release Notes: Bestehende Konfigurationen inklusive der zugehörigen Firewall-Policies werden nicht übernommen, und die Umstellung muss vor dem Upgrade erfolgen, sonst bricht der Fernzugriff weg.

Damit stehen zwei Wege offen:

• IPsec - der von Fortinet benannte direkte Nachfolger, wahlweise über TCP 443. Kürzester Weg, bleibt im gewohnten Ökosystem, sinnvoll vor allem für feste Standort-zu-Standort-Tunnel.
• Identitätsbasiertes Overlay - der Fernzugriff wandert von der Appliance in ein Mesh, das Zugriff pro Identität und Ressource erlaubt. Mehr Umbau, dafür verschwindet der exponierte Listener.

Dieser Leitfaden beschreibt den zweiten Weg. Für die Einordnung, warum exponierte Appliances zum Risiko wurden, siehe FortiGate-SSL-VPN-Risiko 2026.

Was sich architektonisch ändert

Der Unterschied ist nicht das Protokoll, sondern die Reihenfolge von Zugriff und Prüfung:

Der praktische Gewinn: Nach der Migration gibt es keinen anonym erreichbaren Dienst mehr, den ein Scanner findet - und ein kompromittiertes Endgerät erreicht nur noch das, was seiner Gruppe zugewiesen ist.

Schritt 1: Bestandsaufnahme

Bevor irgendetwas aufgebaut wird, muss der Ist-Zustand auf dem Tisch liegen. Vier Fragen:

1. Wer greift heute zu? Mitarbeitende, externe Dienstleister, Maschinenhersteller - und über welche Konten? Lokale FortiGate-Nutzer sind hier der häufigste blinde Fleck, weil sie in keinem Verzeichnis auftauchen.
2. Worauf greifen sie zu? Konkrete Zielsysteme statt „das Netz". Genau diese Liste wird später zur Richtlinienmatrix.
3. Welche Zugänge sind nicht personengebunden? Sammelkonten, geteilte Zugangsdaten, Maschinenzugänge. Sie brauchen im Zielbild eine eigene Lösung.
4. Was ist internet-exponiert? Nicht nur das SSL-VPN, sondern alle offenen Verwaltungszugänge.

Das Ergebnis ist eine Tabelle „Wer greift auf was zu, mit welchem Konto, wofür". Ohne sie wird die Richtlinienarbeit später zum Raten.

Schritt 2: Control Plane und Identität

Zuerst entsteht die Steuerungsebene - self-hosted auf eigener Infrastruktur oder als betriebener Dienst in der EU. Sie verteilt Schlüssel, Routen und Regeln; der Datenverkehr läuft anschließend direkt zwischen den Peers.

Der wichtigere Teil ist die Identität. NetBird bindet OIDC-fähige Identity Provider an, darunter die selbst hostbaren Authentik und Keycloak. Hier entstehen Nutzer, Gruppen und die Mehrfaktorauthentifizierung - und genau hier liegt der Compliance-Hebel: Das seit dem 6. Dezember 2025 geltende NIS2-Umsetzungsgesetz nennt Multi-Faktor-Authentifizierung ausdrücklich als Risikomanagementmaßnahme (siehe NIS2-konformer Fernzugriff).

Praktischer Rat: Die Gruppenstruktur im IdP zuerst festlegen, nicht nebenbei. Sie bestimmt später jede Zugriffsregel, und nachträgliches Umbauen ist teurer als einmal sauber überlegen.

Schritt 3: Peers ausrollen

Ein Peer ist ein Gerät im Overlay. Für die Erstregistrierung gibt es zwei Wege: interaktive Anmeldung über den IdP - der Normalfall für Arbeitsplätze - oder Setup Keys für alles, was unbeaufsichtigt startet.

Zu den Setup Keys (NetBird-Dokumentation):

• One-off für einzelne Maschinen, reusable mit Nutzungslimit für Ausrollen in Serie.
• Auto-assign groups: Der Schlüssel weist neu registrierte Peers automatisch Gruppen zu - damit greifen die passenden Zugriffsregeln ab der ersten Sekunde.
• Ephemeral peers: Mit diesem Modus registrierte Peers werden automatisch entfernt, wenn sie länger als zehn Minuten offline sind - sinnvoll für Container und kurzlebige Instanzen.

Für Server und wiederkehrende Rollouts gehört der Schlüssel in die Automatisierung (Ansible, Terraform), nicht in eine Anleitung zum Abtippen.

Schritt 4: Gruppen und Zugriffsrichtlinien

Jetzt wird aus dem Netz ein kontrollierter Zugang. NetBird arbeitet mit Gruppen und Policies: Eine Richtlinie legt Quell- und Zielgruppe fest, dazu Protokoll, Ports und Richtung - bidirektional oder nur vom Quell-Peer initiiert (Dokumentation).

Der wichtigste Handgriff der ganzen Migration: Beim ersten Einrichten wird eine Default-Policy angelegt, die Verbindungen zwischen allen Peers erlaubt. Wer sie stehen lässt, hat das flache Netz der Appliance originalgetreu nachgebaut. Sie gehört ersetzt durch Regeln entlang der Tabelle aus Schritt 1 - je Gruppe nur die Ziele, Protokolle und Ports, die gebraucht werden.

Ergänzend prüfen Posture Checks Eigenschaften des Geräts, bevor eine Verbindung zustande kommt. Damit lässt sich etwa erzwingen, dass nur aktuelle Clients Zugriff bekommen.

Schritt 5: Standorte und Maschinen ohne Client

Nicht auf jedem System kann oder soll ein Agent laufen - Legacy-Server, Steuerungen, HMIs, Drucker. Dafür gibt es Routing Peers: ein NetBird-Peer im jeweiligen Netz, der Verkehr zwischen Overlay und lokalem Subnetz weiterleitet. So werden ganze Netze erreichbar, ohne irgendetwas auf den Zielsystemen zu installieren, und der Zugriff bleibt trotzdem richtlinienbasiert.

Ein Detail, das im Betrieb Zeit spart: NetBird führt das nötige ausgehende SNAT selbst nur auf Linux-Routing-Peers aus. Auf anderen Plattformen - OPNsense und pfSense sind die üblichen Beispiele - muss es manuell konfiguriert werden. Für Standortanbindungen ist ein Linux-Routing-Peer deshalb der ruhigere Weg.

Für Maschinen- und Anlagenzugriffe gelten zusätzlich die Segmentierungsregeln aus der OT-Welt; die Einordnung liefert OT/IT-Segmentierung und DMZ.

Schritt 6: Cutover und Rückweg

Die Umstellung läuft parallel, nie als Stichtag:

1. Eine unkritische Nutzergruppe und ein unkritisches Zielsystem zuerst - inklusive Prüfung, dass Protokollierung und Richtlinien greifen.
2. Nutzergruppen nacheinander umstellen; das SSL-VPN bleibt in dieser Phase als Rückweg aktiv.
3. Dienstleister- und Maschinenzugänge folgen, weil sie die meiste Abstimmung brauchen.
4. Erst wenn niemand mehr über den alten Weg arbeitet, wird der SSL-VPN-Listener deaktiviert. Damit verschwindet die exponierte Angriffsfläche - und erst danach ist das Upgrade auf 7.6.3 unkritisch.

Die FortiGate bleibt dabei in aller Regel als Firewall und für Site-to-Site-Tunnel im Einsatz. Abgelöst wird der Fernzugriff, nicht das Netzdesign.

Fallstricke aus der Praxis

• Default-Policy vergessen. Der häufigste Fehler, siehe Schritt 4. Ohne restriktive Regeln ist der Sicherheitsgewinn dahin.
• Lokale Appliance-Konten übersehen. Konten, die nur in der FortiGate existierten, tauchen in keinem IdP auf und fallen beim Cutover auf.
• Sammelkonten eins zu eins übernehmen. Geteilte Zugangsdaten lassen sich nicht sinnvoll mit MFA versehen und machen jede Protokollierung wertlos. Die Migration ist der richtige Moment, sie aufzulösen.
• SNAT auf Nicht-Linux-Routing-Peers. Führt zu Verbindungen, die scheinbar grundlos scheitern.
• Zu früh abschalten. Der alte Zugang ist der Rückweg. Er darf erst weg, wenn die letzte Gruppe migriert und in Betrieb bestätigt ist.

Wie die Zielarchitektur im Detail funktioniert, erklärt Was ist NetBird?; die Entscheidungsgrundlage zwischen den Overlay-Optionen liefert NetBird vs Tailscale vs WireGuard.