Fortigate – Migration einer Multiple VDOM Konfig in Single VDOM Konfig

Fortigate – Migration Multiple VDOM Konfig in Single VDOM Konfig

Eine Herausforderung war eine Migration eines Fortigate 100D Clusters, bei welcher VDOMs aktiviert waren. Die aktivierten VDOMs waren Ergebnis einer Trial and Error Konfig eines alten Admins, der dann auch noch kommentarlos die Segel strich…

Normalerweise gibt es keine Möglichkeit, die aktivierte VDOM Konfig unterbrechungsfrei wieder zu deaktivieren, da eine VDOM Konfig etliche Parameter und Konfigurationseinstellungen beeinflusst. Insofern ist die offizielle Variante, alles komplett neu zu integrieren. Bei einer komplexen Integration, kann das Tage Arbeit und vor allem tagelanges Troubleshooting nach sich ziehen. Da es sich hier aber um ein Cluster handelte, kam mir die Idee eines der Systeme vorzubereiten und anschließend mit dem alten System das Cluster wiederherzustellen. Das ging natürlich nur, da für den Zeitraum der Umbauten und Änderungen (bei mir etwa 3 Tage) auf die HA Funktion verzichtet werden konnte (besser musste)!

Grundsätzlich der Plan:

Altes Cluster mit nur einem System weiterbetreiben
Abgehängtes System in den Werkszustand versetzen
Konfiguration von Multiple VDOM auf Single VDOM „umbauen“
Überarbeitete Single VDOM Konfig am „neuen“ System importieren
Umstellen des Netzwerks auf das neue Single VDOM System
Alles testen und ggfs. Fehler abstellen
Altes Cluster System in den Werkszustand versetzen
Altes Cluster System dem neuen Single VDOM System als Slave hinzufügen

Wir befanden dies für die beste Lösung, vor allem hinsichtlich der notwendigen Downtimes und Fehlerquellen und vorab, wir kamen so mit einer effektiven Downtime von ca. 30 Minuten aus.

Ok, die Steps im Detail:

Slave vom Cluster trennen, im Zweifel einfach herunterfahren und das Cluster nur mit dem Master betreiben. Es meckert zwar die ganze Zeit, aber ich wusste ja warum.
Achtung! Bitte unbedingt nach einem evtl. Failover die korrekte Funktion der Firewall testen! Ich habe erlebt, dass es HA Cluster gab, die nie wirklich HA konnten!

Den „alten“ Slave in den Werkszustand versetzen, dann Basiskonfig in aller Kürze:

config system virtual-switch
delete lan
end
config system dhcp-server
purge
end
config firewall policy
purge
end
config system interface
edit port1
set ip 10.1.1.1 255.255.255.0
set allowaccess ping http https ssh
end
end

config system virtual-switch

delete lan

end

config system dhcp-server

purge

end

config firewall policy

purge

end

config system interface

edit port1

set ip 10.1.1.1 255.255.255.0

set allowaccess ping http https ssh

end

Damit sollte der Zugriff auf Port1 via https://10.1.1.1 möglich sein.

Backup der Konfiguration des Clusters via GUI, unverschlüsselt, damit ich sie editieren kann. Ich habe die globale und separat noch einmal die entsprechende VDOM-Konfig exportiert (gesichert).
Vorbereitend die betreffenden Ports von der alten Konfig an der „neuen“ planen und die Interfaces neu zuordnen.
Meine Beispielkonfig:
- WAN1 (WAN Uplink Internet Provider)
- Port1 (Transit Interface zum Core Switch – IRF Stack)
- Lab-Netz (VLAN an Port1)
- DMZ
- DMZ3 (VLAN am DMZ Interface)
- Port2 (DMZ 2)
- BYOD WLAN (VLAN an Port3)
- Gast WLAN (VLAN an Port3)
- ha1 und ha2 lasse ich aktiv, aber völlig unkonfiguriert (für späteres Clustern)
Die gesicherte (Cluster) Konfig im Editor Deiner Wahl öffnen. Ich habe Notepad++ verwendet, da ich hier die Syntax für das Ersetzen diverser Zeichenketten und die Zeilenoperationen kenne.
Den kompletten Header entfernen, bis zum Teil config sytem interface.
Die „alten“ Interface-Namen durch die neuen „ersetzen“, falls erforderlich. Achtung hier immer „Alle ersetzen…“, denn natürlich werden die Namen der Interfaces in der gesamten Konfig „irgendwo“, wie bspw. bei IPSec Tunneln, in den SSL-VPN Einstellungen, bei Adressobjekten (wenn der Parameter Interface nicht auf ANY) steht und natürlich in allen Policies als Source bzw. Target Interface verwendet.
Jetzt muss man die entsprechenden IP’s, ebenfalls durch reines „Ersetzen“ auf den Interfaces anpassen, falls erforderlich.
Bei den Interfaces (Achtung, hier ggfs. auf das Global Backup zurückgreifen, da in der VDOM evtl. nicht alle Interfaces enthalten sind!) ist jetzt der Parameter set vdom zu entfernen. Mit Notepad++ habe ich hier beschrieben, wie das relativ fix geht. Beim Zurückspielen dieser Konfig als Script, ist der Parameter nicht erforderlich, denn das System setzt diesen Parameter by default auf root, wenn nichts anderes angegeben wird.
Jetzt gilt es sämtliche Konfigurationsparameter bezüglich HA zu entfernen, dazu einfach nach config system ha suchen und den ganzen Block entfernen,

denn die HA config machen wir später…
nachdem alle notwendigen Anpassungen gemacht sind, die „neue“ Konfig als *.conf File speichern.
Jetzt an der neu konfigurierten Firewall die aktuelle Konfiguration sichern. (für einen schnellen Rückweg, falls etwas schief geht)
Über den Script Import jetzt die neue Konfig laden