Sie sind hier

Fortigate Firewall HA Cluster mit FGCP

 

In diesem Dokument beschreibe ich die Funktionsweise und Konfiguration eines Cluster mit Fortigate Firewalls mit Forti OS 6.0.2. Das dafür verwendete Protokoll ist das Fortigate Clustering Protocol (FGCP), welches folgende Funktionen vereint:

  • Ausfallsicherheit: durch permanente Hearbeat-Pakete kann selbst bei Ausfall einer Firewall eine Ausfallzeit von weniger als einer Sekunde realisiert werden. Der Einsatz von virtuellen MAC Adressen dient dazu, dass Clients bei einem Failover keine neuen Adressen lernen müssen.
  • Session Failover: Im Normalzustand werden permanent die Zustände von TCP, SIP und IPSec Sessions auf alle Cluster-Mitglieder verteilt, so dass im Fehlerfall auch diese Protokolle ohne erneuten Verbindungsaufbau weiterlaufen können.
  • Lastverteilung: Mit Hilfe eines Active-Active Clusters kann die Last auf alle Cluster-Mitglieder verteilt werden, so dass ressourcenintensive Sicherheitsfeatures (z.B. Virusscan) auf mehrere Systeme verteilt werden können.
  • Virtuelles Clustering:  Als Erweiterung des FGCP lässt sich das Clustering auch auf virtualisierte Firewalls mit mehreren VDOMS erweitern.
  • Full-Mesh HA: Vor- und nachgelagerte Switches können vollvermascht an den Cluster mit Hilfe von LACP angeschlossen werden, so dass auch die angeschlossende Layer-2 Umgebung voll redundant aufgebaut werden kann.

Jedes Mitglied einer Clustergruppe ist eine sog. Einheit (Unit). Eine Einheit wird als primäre Firewall ausgewählt, die die Konfiguration an alle weiteren Einheiten verteilt. Ebenso können Statusinformation über aktive Sessions synchronisiert werden, so dass z.B. TCP Sessions bei einem Ausfall ohne TCP Verbindungsaufbau weiterlaufen. Die Synchronisierung der Einheiten läuft über dedizierte Heartbeat Interfaces.

 

Bevor ein Cluster in Betrieb genommen werden kann müssen folgende Voraussetzungen erfüllt sein:

  • Der gesamte Cluster muss aus einem Fortigate Modell bestehen
  • Alle Interfaces müssen mit statischen Adressen versehen sein. DHCP oder PPPoE kann erst aktiviert werden, wenn der Cluster formiert wurde
  • Firmware Version muss auf allen Einheiten identisch sein
  • Alle Einheiten müssen den gleichen Lizensierungsstand aufweisen. Wenn es Unterschiede gibt, dann wird der Cluster nur die Lizenzen aktivieren, die auf allen Einheiten identisch sind. Ausnahme bildet die FortiToken Lizenz

 

Zur Veranschaulichung der Konfiguration dient unser folgender Testaufbau bestehend aus zwei Fortigate 90D und vor- und nachgelagerten Aruba 2930F Switches, die unser LAN und WAN simulieren.

 

 

Im produktiven Umfeld würde man die Switches mit geeigneten Virtualisierungstechniken (vPC, VSF, IRF, VSS oder änlichen) ebenfalls redundant auslegen.

Wenn die beiden Firewalls räumlich getrennt sind, wäre auch der Transport der Heartbeat-Pakete über ein seperates VLAN möglich. 

 

 

Die Konfiguration erfolgt in folgenden Schritten:

#1 Hostnamen vergeben

Da die Hostnamen nicht synchronisert werden, müssen diese eindeutig vergeben werden. In unserem Fall heißen die Einheiten FG1 und FG2.

#2 Auf beiden Systemen die Lizenzen aktivieren

#3 HA Konfiguration auf FG1 durchführen. Hier müssen folgende Parameter konfiguriert werden:

Mode: Active-Active oder Active-Passive. Wir wählen Active-Passive, so dass ein System keine aktiven Verbindungen hat, sondern nur im Fehlerfall einspringt. Für kleinere Systeme ist das der empfohlene Einstellung. Auf größeren Plattformen kann zur Performancesteigerung auch eine Active-Active Konfiguration erstellt werden.
Device Priority: Ein numerischer Prioritätenwert, bei dem die höhste Priorität dazu für, dass dieses System die Rolle des Masters annimmt. Wir wählen den Wert 128
Group Name: Alphanumerischer Gruppenname, der im Cluster identisch sein muss
Password: Password zu Authentifizierung der Firewalls
Session Pickup: Die Möglichkeit TCP, IPSsec und VPN Sessions auf die anderen Firewalls zu synchronisieren, so dass die Sessions im Fehlerfall ohne Neuaufbau weiterlaufen
Monitor Interfaces: Hier können ein oder mehrere Interfaces ausgewählt werden, die bei Ausfall einen Failover auslösen.
Hearbeat Interface: Mindestens ein, empfohlen zwei physikalische Interfaces um die Heartbeat-Pakete zu übertragen und die Firewalls zu synchronisieren. Hier nehmen wir die beiden letzten Interfaces 13 und 14.
Heartbeat Priority: Hier können für jedes Interface eine Priorität angegeben werden.
Management Interface Reservation: Hier können physikalische Interfaces definiert werden, die von der HA Konfiguration ausgenommen sind, um jedes singuläre System über definierte Managementprotokolle (HTTPS, SSH, SNMP usw) anzusprechen.

Auf Firewall FG1 sieht die Konfiguration dann so aus:

 

 

Auf Firewall FG2 sieht die Konfiguration dann identisch aus mit Ausnahme der Device Priorität. Hier wählen wir einen kleineren Wert, damit dieses System in den Standby Modus versetzt wird:

 

 

Sobald die beiden Interfaces über die Heartbeat Interfaces verbunden werden, wird der Cluster formiert. FG1 läuft als Master und FG2 als Slave. Statt der Konfigurationsseite wird nun der Status des Clusters angezeigt:

 

Management Interface Reservation kann optional noch konfiguriert werden, um die beiden Systeme in vorhandene Management- und Monitoring System einzubinden. Wir gehen dazu mit "Edit" in die Konfiguration des Cluster: 

 

 

Mit dieser Einstellung lassen sich nun verschiedene IP Adressen auf den beiden Systemen konfigurieren. Die Konfiguration erfolgt über die CLI:
FG1 # config system interface
FG1 (interface) # edit internal2
FG1 (internal2) # set ip 192.168.12.254/24
FG1 (internal2) # set allowaccess https ping ssh snmp
FG1 (internal2) # end
FG1 # execute ha manage
<id>    please input peer box index.
<0>     Subsidary unit FGT90D3Z15xxxx18
FG1 # execute ha manage 0
FG2 login: admin
Password:
Welcome !
FG2 $ config system interface
FG2 (interface) $ edit internal2
FG2 (internal2) $ set ip 192.168.12.253/24
FG2 (internal2) $  set allowaccess https ping ssh snmp
FG2 (internal2) $ end

Die Management Interfaces werden nun in pink angezeigt und die IP Adresse wird in der Übersicht ebenfalls angezeigt: 

 

Weitere Details können wir im CLI abrufen:


FG1 # get system ha status
HA Health Status: OK
Model: FortiGate-90D
Mode: HA A-P
Group: 0
Debug: 0
Cluster Uptime: 0 days 1:25:59
Cluster state change time: 2018-08-25 21:41:06
Master selected using:
    <2018/08/25 21:41:06> FGT90D3Z15xxxx78 is selected as the master because it has the largest value of override priority.
    <2018/08/25 21:37:35> FGT90D3Z15xxxx78 is selected as the master because it's the only member in the cluster.
    <2018/08/25 21:37:29> FGT90D3Z15xxxx78 is selected as the master because the peer member FGT90D3Z15xxxx18 has SET_AS_SLAVE flag set.
    <2018/08/25 21:36:28> FGT90D3Z15xxxx18 is selected as the master because it has the largest value of uptime.
ses_pickup: disable
override: disable
Configuration Status:
    FGT90D3Z15xxxx78(updated 1 seconds ago): in-sync
    FGT90D3Z15xxxx18(updated 3 seconds ago): in-sync
System Usage stats:
FGT90D3Z15xxxx78(updated 1 seconds ago):
sessions=7, average-cpu-user/nice/system/idle=0%/0%/0%/100%, memory=23%
FGT90D3Z15xxxx18(updated 3 seconds ago):
sessions=1, average-cpu-user/nice/system/idle=0%/0%/0%/100%, memory=22%
HBDEV stats:
FGT90D3Z15xxxx78(updated 1 seconds ago):
      internal13: physical/1000auto, up, rx-bytes/packets/dropped/errors=1324344/4296/0/0, tx=1662721/4499/0/0
     internal14: physical/1000auto, up, rx-bytes/packets/dropped/errors=1096006/2913/0/0, tx=1307676/3466/0/0
     FGT90D3Z1xxxx318(updated 3 seconds ago):
     internal13: physical/1000auto, up, rx-bytes/packets/dropped/errors=1271082/3317/0/0, tx=948655/3181/0/0
      internal14: physical/1000auto, up, rx-bytes/packets/dropped/errors=971838/2571/0/0, tx=771936/2064/0/0
Master: FG1             , FGT90D3Z15xxxx78, cluster index = 1
Slave : FG2             , FGT90D3Z15xxxx18, cluster index = 0
number of vcluster: 1
vcluster 1: work 169.254.0.2
Master: FGT90D3Z15xxxx78, operating cluster index = 0
Slave : FGT90D3Z15xxxx18, operating cluster index = 1

 

Auf den Chassis sollte nun auch die HA LED auf beiden Systemen grün sein:

 

Failover-Test

Bei einem Ausfall einer Firewall kommt es zu einer kurzen Unterbrechung und die aktiven Sessions werden von der zweiten Einheit übernommen. Um ein Gefühl für die Ausfallzeit zu bekommen lassen wir ein Ping durch die beiden System laufen und schalten die aktive Firewall aus:

 

 

Im HA Event Log sehen wir folgende Meldungen:

 

 

Der Status fehlerhafte HA Status wird auch direkt am Chassis in Form einer roten HA LED angezeigt:

 

 

Weitere Dokumentation zu diesem Thema findet sich im FortiOS Handbook – High Availability unter https://docs.fortinet.com

Nutzungsbedinungen

Die Nutzung, Vervielfältigung und Verbreitung dieser Publikation und von verbundenen Grafiken wird hiermit unter der Bedingung gestattet, dass der Urheberrechtshinweis auf allen Kopien erscheint und dass sowohl der Urheberrechtshinweis als auch dieser Zustimmungshinweis erscheinen. Alle sonstigen Rechte bleiben vorbehalten. Der Name der Ingentive Networks GmbH darf im Zusammenhang mit der Verbreitung dieser Publikation durch Werbung oder sonstige Veröffentlichung, nur mit ausdrücklicher vorheriger schriftlicher Zustimmung verwendet werden. Ingentive Networks GmbH übernimmt keine Gewähr für die Verwendbarkeit dieser Information zu irgendwelchen Zwecken. Diese Publikation wird so wie hier bestehend zugänglich gemacht, ohne jegliche Gewähr oder sonstige Verpflichtung. Jegliche Gewährleistung im Zusammenhang mit dieser Information und deren Verwendung, ausdrücklich oder stillschweigend, gesetzlich oder aus sonstigem Rechtsgrund (einschließlich der Gewährleistung für bestimmte Eigenschaften oder der Verwendbarkeit für einen bestimmten Zweck) ist ausgeschlossen. Ingentive Networks GmbH haftet nicht für Bearbeitungsfehler oder Nutzungsausfall, entgangenen Gewinn oder erwartete ersparte Aufwendungen, Verlust des Firmenwerts (goodwill) oder Verlust von Daten oder Verträgen sowie für jegliche Art von indirekten Vermögens- oder Folgeschäden (einschließlich Schäden aufgrund von Ansprüchen Dritter), welche im Zusammenhang mit der Verwendung dieser Publikation entstehen. Die Nutzung dieser Publikation ist unter den Bedingungen erlaubt, dass (1) der unten angeführte CopyrightVermerk auf allen Kopien erscheint, und dass der Copyright-Vermerk und dieser Genehmigungsvermerk erscheinen, (2) die Dokumente dieser Web-Site nur zu informatorischen, nichtkommerziellen oder privaten Zwecken genutzt und nicht über Computernetze oder sonstigen Medien veröffentlicht werden, und (3) die Dokumente nicht verändert werden. Die Nutzung zu anderen Zwecken erfordert eine explizite Genehmigung seitens Ingentive Networks GmbH Diese Publikation kann technische Ungenauigkeiten oder typographische Fehler enthalten. Die darin enthaltenen Informationen werden regelmäßig verändert oder ergänzt. Die Ingentive Networks GmbH behält sich vor, jederzeit Änderungen und/oder Verbesserungen an einem oder mehreren der darin beschriebenen Produkte und/oder einem oder mehreren der Programme vorzunehmen. "Aruba",„HPE“, „Fortigate“, "Cisco Systems" und „Ingentive Networks“ sind eingetragene Warenzeichen.