Von der Alt-Firewall zu FortiGate: Migrationsplan Schritt für Schritt

Eine Firewall-Migration ist die geplante Übertragung von Regeln, NAT-Definitionen, VPN-Tunneln und Objekten von einer bestehenden Firewall auf eine neue FortiGate. Eine erfolgreiche Migration durchläuft acht Phasen: Inventur, Regelanalyse, Zieldesign, FortiConverter oder manuelle Konvertierung, Parallelbetrieb, Cutover-Fenster, Rollback-Plan und Validierung. Dieser Leitfaden beschreibt jede Phase mit Ergebnis und typischer Dauer.

Warum sollte eine Firewall-Migration als eigenes Projekt geplant werden?

Eine Firewall-Migration braucht einen eigenen Projektplan, weil die Firewall das einzige Tor zwischen dem Unternehmen und dem Internet, den Niederlassungen, den VPN-Nutzern und den Servern ist. Wer einfach das Kabel umsteckt und die Konfiguration einfügt, überträgt jahrelang angesammelte Regelfehler und undokumentierte Abhängigkeiten auf das neue Gerät – und der Ausfall zeigt sich während der Geschäftszeiten.

Nach unserer Projekterfahrung geraten die meisten Migrationen aus drei Gründen in Schwierigkeiten. Erstens enthält das alte Gerät Regeln, die niemand mehr erklären kann; sie werden unverändert übernommen, „damit nichts kaputtgeht“. Zweitens sind die Abhängigkeiten von Systemen wie ERP, Kassenintegration oder dem Videoaufzeichnungsserver von der Firewall nicht dokumentiert; in der Cutover-Nacht funktioniert alles, am nächsten Morgen kann die Buchhaltung nicht arbeiten. Drittens besteht der Rollback-Plan aus dem Satz „Wir stecken das alte Gerät wieder ein“, und niemand hat gemessen, wie lange das tatsächlich dauert.

Deshalb teilen wir die Migration in Phasen auf, die jeweils ein konkretes Ergebnis liefern. Die folgende Tabelle zeigt typische Dauern aus unseren Projekten für ein KMU mit einem Standort; bei mehreren Niederlassungen oder vielen veröffentlichten Diensten verlängern sich die Zeiten.

Inventur und Regelanalyse: Was muss wirklich migriert werden?

Die Inventur dokumentiert jedes Konfigurationselement der alten Firewall und jedes Geschäftssystem, das davon abhängt; die Regelanalyse filtert anschließend heraus, welche Regeln tatsächlich Verkehr sehen und welche verschattet oder doppelt sind. Auf die FortiGate wandert nicht die gesamte bestehende Konfiguration, sondern die bereinigte Teilmenge, die diese Analyse übersteht.

Ein Blick nur auf das Regelwerk reicht nicht. Unsere Inventur-Checkliste umfasst:

• Schnittstellen und VLANs: physische Ports, Subinterfaces, IP-Adressen, MTU und Einstellungen für den Verwaltungszugang.
• Routing: statische Routen, Standard-Gateway, mehrere WAN-Leitungen und richtlinienbasiertes Routing.
• NAT: Source-NAT, Destination-NAT / Portweiterleitung (in FortiOS: VIP) und den Verantwortlichen jedes veröffentlichten Dienstes.
• Objekte: Adressen, Adressgruppen, Dienste, Zeitpläne und FQDN-Objekte.
• VPN: Site-to-Site-IPsec-Tunnel, Remote-Access-Profile, Pre-Shared Keys und Zertifikate.
• Authentifizierung: LDAP/Active Directory, RADIUS, lokale Benutzer und Gruppen.
• Dienste: DHCP-Bereiche, DNS-Weiterleitung, NTP, SNMP und Syslog-Ziele.
• Sicherheitsprofile: IPS, Virenschutz, Webfilter und Anwendungskontrolle sowie die Regeln, an die sie gebunden sind.

Die Abhängigkeitskarte ist der am häufigsten übersprungene Teil der Inventur. Für jeden veröffentlichten Dienst und jeden VPN-Tunnel sollte schriftlich beantwortet werden: „Welche Abteilung kann nicht arbeiten, wenn das ausfällt?“ Diese Liste ist die Grundlage für die Testmatrix der Cutover-Nacht und für die Rollback-Auslöser.

Bei der Regelanalyse suchen wir drei Klassen von Problemen: ungenutzte Regeln ohne Trefferzähler, verschattete Regeln, die nie greifen, weil eine vorherige Regel ihren Verkehr abfängt, und doppelte Regeln, deren Entfernung nichts ändert. Hinzu kommen „Any-Any“-Freigaben und vorübergehend geöffnete, vergessene Testregeln. In seinen Best Practices für FortiOS 7.6 empfiehlt Fortinet, ungenutzte Objekte und Richtlinien vor der Migration zu entfernen und anhand des Verkehrsflusses zu prüfen, ob sich bestehende Richtlinien zusammenfassen lassen (Fortinet Document Library, Migration). Die Methode beschreiben wir ausführlich in unserem Beitrag zur Firewall-Regelbereinigung und Richtlinienprüfung; für die Regellogik auf FortiOS-Seite ist unser Leitfaden zur FortiGate-Richtlinienverwaltung ein guter Einstieg.

Die IT sollte Bereinigungsentscheidungen nicht allein treffen. Eine Regel mit Trefferzähler null kann zu einer Übertragung gehören, die nur einmal im Jahr zum Geschäftsjahresabschluss läuft. Die Löschliste wird daher mit den Fachbereichen abgestimmt; strittige Regeln werden als „deaktiviert“ auf das neue Gerät übernommen und beobachtet.

Zieldesign: Modell, Schnittstellenplan und Segmentierung

Das Zieldesign legt im Voraus fest, wie das bereinigte Regelwerk auf der neuen FortiGate aufgebaut wird: welches Modell, welcher physische Port welchem alten Port entspricht, welche VLANs zu welcher Sicherheitszone gehören und welche Sicherheitsprofile an welche Regeln gebunden werden. Ohne fertiges Design beginnt keine Konvertierung.

Die Modellauswahl richtet sich nach den Eigenschaften des Zielverkehrs, nicht nach der Größe des bisherigen Geräts. Werden IPS, SSL-Inspektion oder Webfilter, die auf dem alten Gerät deaktiviert waren, auf dem neuen eingeschaltet, zählen die mit aktiven Sicherheitsprofilen gemessenen Werte, nicht der Firewall-Durchsatz aus dem Datenblatt. Die Optionen für KMU vergleichen wir im Beitrag FortiGate 40F, 60F, 70G und 90G im Vergleich; den allgemeinen Entscheidungsrahmen finden Sie im Firewall-Auswahlleitfaden für KMU. Die gesamte Produktfamilie ist auf unserer FortiGate-Lösungsseite aufgeführt.

Der Schnittstellenplan ist ein einfaches, aber entscheidendes Dokument, das auch in Fortinets Migrations-Best-Practices betont wird: Port1 des alten Geräts kann Port2 des neuen entsprechen; neben WAN und LAN gehören auch Management-Port, HA-Verbindung und DMZ-Ports in die Tabelle.

Die Migration ist der beste Zeitpunkt, die Segmentierung zu überdenken. In flachen LAN-Umgebungen macht die Trennung von Benutzern, Servern, Gast-WLAN, Druckern und IoT-/Kameranetzen in eigene VLANs und Zonen das Regelwerk lesbarer und widerstandsfähiger gegen Ransomware. Wir empfehlen jedoch, Segmentierung und Firewall nicht in derselben Nacht zu ändern: Zuerst wird mit der bestehenden Segmentierung migriert, danach werden neue Zonen schrittweise eingeführt.

Im Design sollten außerdem festgehalten werden: ob Hochverfügbarkeit mit einem zweiten Gerät und einer FortiGate-HA-Konfiguration benötigt wird; die Methode für den Fernzugriff (ist das Zielrelease FortiOS 7.6, gehört der Wegfall von SSL-VPN und der Wechsel zu IPsec/ZTNA zum Design); das Log-Ziel (lokale Festplatte, Syslog oder FortiAnalyzer) sowie Einschränkungen des Verwaltungszugangs.

FortiConverter oder manuelle Konvertierung?

FortiConverter ist Fortinets Werkzeug, das Konfigurationen von Drittanbieter-Firewalls in das FortiOS-Format übersetzt; bei großem Regelwerk und unterstütztem Quellhersteller verkürzt es die Konvertierungszeit erheblich. Die manuelle Konvertierung liefert ein saubereres Ergebnis bei wenigen Regeln, nicht unterstützten Quellen oder einem komplett neuen Design. In beiden Fällen wird das Ergebnis Zeile für Zeile geprüft.

Laut Fortinets Produktseite unterstützt FortiConverter eine breite Liste von Quellen, darunter Cisco, Cisco Meraki, Check Point, Palo Alto Networks, Juniper, Forcepoint, SonicWall, Sophos, WatchGuard, Barracuda, Huawei und MikroTik, und überträgt Schnittstellenkonfiguration, Firewall-Richtlinien, NAT-Regeln, Adressobjekte und statische Routen nach FortiOS (Fortinet FortiConverter). Die Fortinet-Dokumentation weist zudem darauf hin, dass manche Konfigurationsteile wegen Abhängigkeiten oder nicht unterstützter Syntax nicht übersetzt werden und manuell konvertiert werden müssen. Unterstützte Zielversionen und das Lizenzmodell prüfen Sie bitte in der aktuellen Fortinet-Dokumentation.

In unseren Projekten bringt das Werkzeug den größten Nutzen bei Adress- und Dienstobjekten sowie langen Regelwerken; die meiste Handarbeit erfordern VPN-Tunnel, Authentifizierungsintegration, Sicherheitsprofile und herstellerspezifische Funktionen der Quellplattform.

Ist das Quellgerät bereits eine FortiGate (etwa ein Modell am Ende des Lebenszyklus, das durch eine neue 70G oder 90G ersetzt wird), empfiehlt Fortinet ebenfalls FortiConverter; ohne Lizenz beschreibt es, die Konfigurationsdatei anzupassen, auf das neue Gerät zu laden und nach dem Neustart das Fehlerprotokoll mit diagnose debug config-error-log read zu prüfen (Fortinet, Migrating a FortiGate configuration manually).

Unabhängig von der Methode laden wir das Konvertierungsergebnis zunächst auf das Gerät in der parallelen Testumgebung, nie direkt in die Produktion. Für die ersten Konfigurationsschritte ergänzt unser Leitfaden zur FortiGate-Installation und Erstkonfiguration diesen Beitrag.

Parallelbetrieb und Testmatrix

Im Parallelbetrieb wird die neue FortiGate neben der alten Firewall mit einem Teil des echten Verkehrs oder einer Kopie davon betrieben und so validiert. Ziel ist, die Zahl der Überraschungen, die erst in der Cutover-Nacht auftauchen, gegen null zu bringen. Die Testmatrix entsteht aus der Abhängigkeitskarte der Inventur, und jede Zeile wird mit der Freigabe eines Fachbereichs geschlossen.

In der Praxis nutzen wir drei Stufen des Parallelbetriebs. Erstens wird das neue Gerät in einem separaten Test-VLAN mit einer temporären WAN-Leitung aufgebaut, und eine Pilotgruppe geht darüber ins Internet. Zweitens werden veröffentlichte Dienste über eine temporäre zweite öffentliche IP-Adresse über das neue Gerät getestet. Drittens werden Site-to-Site-VPNs mit einer zweiten Tunneldefinition auf der Gegenseite vom neuen Gerät aus aufgebaut.

Die Testmatrix enthält mindestens folgende Punkte:

• Internetzugang, DNS-Auflösung und Webfilter-Verhalten aus jedem Benutzer-VLAN.
• Externer Zugriff auf jeden veröffentlichten Dienst (VIP / Portweiterleitung) und korrekte Einschränkungen der Quell-IP.
• Aufbau der Site-to-Site-VPN-Tunnel, passende Parameter für Phase 1 und Phase 2 und funktionierende Anwendungen in den Niederlassungen.
• Fernzugriff: Authentifizierung, gruppenbasierte Berechtigung und Split-Tunnel-Verhalten.
• Integration von LDAP/Active Directory und RADIUS; korrekte Zuordnung benutzerbasierter Regeln.
• DHCP, NTP, SNMP und Log-Weiterleitung; Eingang der Logs in FortiAnalyzer oder Syslog.
• Einschränkungen des Verwaltungszugangs und Multi-Faktor-Authentifizierung für Administratorkonten.
• Bei geplanter HA: Erhalt der Sitzungen bei einem Mitgliederwechsel.

Mit der Richtliniensuche (Policy Lookup) und dem Paketmitschnitt von FortiOS lässt sich die Frage „Auf welche Regel trifft dieses Paket?“ vor dem Cutover beantworten. Die Testergebnisse fließen in die Konfiguration zurück; übernommene Regeln, deren Trefferzähler noch immer null ist, werden in dieser Phase erneut hinterfragt.

Wie steuert man das Cutover-Fenster?

Das Cutover-Fenster ist das geplante Wartungsintervall, in dem der Produktionsverkehr von der alten Firewall auf die neue FortiGate umgestellt wird. Ein erfolgreiches Fenster wird mit einer schriftlichen Schritt-für-Schritt-Verfahrensanweisung (MOP), vorab erstellten und geprüften Backups, zeitlich festgelegten Go/No-Go-Kontrollpunkten und einem einzigen Entscheider gesteuert. Es wird zur Zeit mit der geringsten geschäftlichen Auswirkung geöffnet.

Vor dem Öffnen des Fensters müssen folgende Voraussetzungen erfüllt sein:

1. Vollständige Konfigurationsbackups von altem und neuem Gerät liegen vor, und eine Wiederherstellung aus dem Backup wurde einmal getestet.
2. Die Fachbereiche sind schriftlich über Zeitpunkt und Dauer der Unterbrechung informiert; für Niederlassungen und externe Lieferanten an VPN-Gegenstellen sind Ansprechpartner benannt.
3. Themen auf Providerseite sind geklärt: statische IPs, an MAC-Adressen gebundene Verträge und der ARP-Cache von Modems/Routern; ändert sich die öffentliche IP, wurden die DNS-TTL-Werte vorab gesenkt.
4. Die Verkabelung ist beschriftet, und der Schnittstellenplan liegt ausgedruckt auf dem Tisch.
5. Der Rollback-Plan ist schriftlich festgehalten, Auslöser und Entscheider sind bestimmt.

Das Verfahren selbst ist kurz und sequenziell: letztes Backup auf dem alten Gerät, WAN-Kabel auf das neue Gerät umstecken, LAN/VLAN-Uplinks umstecken, Schnittstellen- und Routingstatus auf dem neuen Gerät prüfen, veröffentlichte Dienste von außen testen, VPN-Tunnel aufbauen und die kritischen Zeilen der Testmatrix durchlaufen. Zu jedem Schritt sind erwartetes Ergebnis und geschätzte Dauer notiert.

Go/No-Go-Kontrollpunkte legen wir nach der Uhr fest: etwa Grundkonnektivität und NAT in Minute 30 des Fensters, VPN und Authentifizierung in Minute 60, Geschäftsanwendungen in Minute 90. Wird ein Kontrollpunkt nicht rechtzeitig erreicht, leitet der Entscheider den Rollback ein.

Rollback-Plan und Validierung nach der Migration

Ein Rollback-Plan ist das schriftliche Verfahren, um die Produktion bei einem gescheiterten Cutover innerhalb einer bekannten Zeit auf die alte Firewall zurückzuführen; Auslöser, Entscheider und Reihenfolge stehen vorab fest. Die Validierung nach der Migration belegt mit Checklisten für 24 Stunden, eine Woche und 30 Tage, dass die neue FortiGate alle Geschäftsprozesse vollständig trägt.

Rollback-Auslöser müssen konkret sein: „Kritische Anwendung X ist am Kontrollpunkt nicht erreichbar“, „das VPN der Niederlassung steht nicht innerhalb der vereinbarten Zeit“, „der veröffentlichte Dienst antwortet von außen nicht“. Tritt ein Auslöser ein, eröffnet der Entscheider keine Diskussion, sondern startet das Verfahren. Es ist in umgekehrter Reihenfolge geschrieben: neues Gerät abklemmen, altes Gerät einschalten, Schnittstellen und Routing prüfen, VPNs wieder aufbauen und kurz validieren. Wird diese Abfolge im Parallelbetrieb mindestens einmal geprobt, bleibt der Plan nicht nur auf dem Papier.

In unseren Projekten bleibt das alte Gerät zwei bis vier Wochen verkabelt, aber ausgeschaltet; es wird erst entfernt, wenn seltene Prozesse wie Monatsabschluss, Gehaltsabrechnung oder periodische Berichte dieses Fenster durchlaufen haben.

Die Validierung erfolgt in drei Wellen:

Nach abgeschlossener Validierung wird die Konfiguration als Baseline gesichert, für das Regelwerk gilt ein Änderungsverfahren, und ein regelmäßiger Prüfkalender wird eingerichtet. Für Organisationen, die diesen Betrieb nicht mit eigenem Team leisten können, erläutert unser Beitrag zu Managed-Firewall-Services Umfang und Entscheidungskriterien.

Häufig gestellte Fragen

Wie lange dauert eine Firewall-Migration?

Bei einem KMU mit einem Standort dauert das Projekt von der Inventur bis zum Ende der Validierung typischerweise vier bis acht Wochen; das Cutover-Fenster selbst umfasst meist zwei bis vier Stunden. Zahl der Niederlassungen, veröffentlichte Dienste und Größe des Regelwerks bestimmen die Dauer direkt.

Konvertiert FortiConverter jede Firewall-Marke?

Nein. Laut Fortinets Produktseite wird eine breite Liste unterstützt, darunter Cisco, Check Point, Palo Alto Networks, Juniper, SonicWall, Sophos, WatchGuard, Forcepoint, Barracuda, Huawei und MikroTik; Quellhersteller und Version prüfen Sie in der aktuellen Fortinet-Dokumentation. Nicht unterstützte Quellen werden manuell konvertiert.

Warum ist es riskant, alte Regeln unverändert zu übernehmen?

Ungenutzte, verschattete und doppelte Regeln sowie vergessene temporäre Freigaben landen unverändert auf dem neuen Gerät. Die Angriffsfläche schrumpft nicht, das Regelwerk bleibt unübersichtlich, und die neuen Sicherheitsprofile liegen auf alten, fehlerhaften Regeln. Die Migration ist der günstigste Moment zum Aufräumen.

Gibt es während der Migration einen Internetausfall?

Eine kurze Unterbrechung im Cutover-Fenster ist unvermeidlich; bei einer durch Parallelbetrieb vorbereiteten Migration beschränkt sie sich auf das Umstecken der Kabel und den Neuaufbau der Tunnel. Das Fenster liegt in der Zeit mit geringster geschäftlicher Auswirkung und wird vorab angekündigt.

Wann sollte die alte Firewall abgeschaltet werden?

Sie wird am Ende des Cutovers ausgeschaltet, aber nicht abgebaut. In unseren Projekten bleibt sie zwei bis vier Wochen verkabelt und rollback-bereit, bis seltene Prozesse wie der Monatsabschluss problemlos gelaufen sind; das Konfigurationsbackup wird unbefristet aufbewahrt.

Braucht man FortiConverter beim Wechsel von einer FortiGate auf eine neuere FortiGate?

Nicht zwingend. Fortinet empfiehlt auch hier FortiConverter; ohne Lizenz beschreibt es, die Konfigurationsdatei anzupassen, auf das neue Gerät zu laden und das Fehlerprotokoll zu prüfen. Portnamen und Versionsunterschiede sind die Hauptrisiken; Regelbereinigung und Validierung gelten weiterhin.

Fazit

Der Wechsel von einer Alt-Firewall zu FortiGate ist weniger ein Gerätetausch als ein Projekt, in dem Regelwerk und geschäftliche Abhängigkeiten neu betrachtet werden. Inventur und Regelanalyse entscheiden, was migriert wird, das Zieldesign, wohin, und FortiConverter oder die manuelle Konvertierung, wie. Der Parallelbetrieb deckt Überraschungen vor dem Cutover auf, ein schriftlicher Rollback-Plan nimmt den Entscheidungsdruck aus der Nacht, und 30 Tage Validierung belegen, dass die Arbeit wirklich abgeschlossen ist.

Als unabhängiger Lösungspartner bietet Sora Yazılım FortiGate-Beschaffung, Migrationsplanung, Installation und anschließende Managed Services. Wenn Sie Ihre bestehende Firewall gemeinsam mit uns erfassen und ein Angebot für den Migrationsplan erhalten möchten, können Sie ein kostenloses Erstgespräch anfragen.