Tag Archives: Cluster

HOWTO: Best-Practice-Konfiguration eines WatchGuard Firebox Clusters Active / Passive

Comment

In einer zunehmend digitalisierten Welt ist Hochverfügbarkeit kein Luxus mehr, sondern eine geschäftskritische Notwendigkeit. Schon wenige Stunden Ausfall können erhebliche Kosten verursachen – ganz zu schweigen von den Folgen, wenn Unternehmen ein bis zwei Tage komplett vom Internet oder den internen Netzwerken abgeschnitten sind.

Um sich vor solchen Szenarien zu schützen, stehen verschiedene Optionen zur Verfügung: Zum einen können Sie durch die Einrichtung eines zweiten Geräts einen hochverfügbaren „Cluster“ aufbauen. Zum anderen besteht die Möglichkeit, über den “4-Stunden-Premium-Austauschservice” die Auslieferung eines kostenfreien Ersatzgeräts deutlich zu beschleunigen.

Im Zuge neuer gesetzlicher Richtlinien wie bspw. NIS2 oder Cyber Resilience Act (CRA) rückt auch die betriebliche Resilienz gegenüber kleineren Ausfällen in den Vordergrund. IT-Verantwortliche müssen sicherzustellen, dass selbst kleinere Defekte – etwa ein defektes Netzteil – nicht zum Stillstand des gesamten Betriebs führen. Zu all diesen Themen beraten wir Sie selbstverständlich gerne.

Dieser Artikel führt Sie durch die Best Practices Einrichtung eines WatchGuard Firebox Active / Passive Clusters. Der für die Umsetzung benötigte Zeitaufwand liegt i.d.R. zwischen 30 und 60 Minuten.

  1. Einführung
  2. Cluster-Konfiguration
  3. Fazit
  4. Häufige Fehler und Lösungen

Weiterlesen »

HOWTO: WatchGuard Firebox Migration bei FireCluster

3 Comments

In diesem Artikel geht es um die Migration eines alten WatchGuard FireClusters auf ein neues WatchGuard FireCluster (bspw. nach einem Trade-Up). Weitere Informationen zu der WatchGuard Trade-Up Promotion mit den je nach Modell empfohlenen Trade-Ups finden Sie unter >> WatchGuard Trade-Up Promotion.

Die Migration einer einzelnen Firebox haben wir in dem Artikel >> HOWTO: WatchGuard Firebox Migration nach Trade-Up beschrieben.
Die Vorgehensweise bei einem Trade-Up mit WatchGuard AuthPoint haben wir in dem Artikel >> HOWTO: Trade-Up mit WatchGuard AuthPoint beschrieben.
Weiterlesen »

WatchGuard Cluster in Verbindung mit Dynamic Arp Inspection (DAI)

Comment

WatchGuard verwendet im Cluster-Betrieb virtuelle Mac-Adressen. Bei einem Cluster-Failover wird dann ein Gratious Arp Paket gesendet, damit alle beteiligten Switches ihre ARP-Table bzw. ihre Mac-Adress-Port-Table anpassen können. Dies kann bei leistungsfähigen Switches mit aktueller Firmware möglicherweise zu Problemen führen, wenn man die Konfiguration nicht entsprechend anpasst.

Weiterlesen »

Multi-WAN Konflikt mit zwei redundanten Cisco HSRP Router-Paaren

Comment

Das Debugging einer problembehafteten HA Umgebung aus zwei X750e mit Fireware XTM 11.3.2 (ich betrachte diese Version derzeit für Cluster aus X Core / Peak e-series am stabilsten) hat heute einen netten Sonderfall aufgezeigt, der für die Störungen sicher mitverantwortlich war:
Der Kunde betreibt schon seit vielen Jahren ein WatchGuard VPN mit ca. 40 Außenstellen. Wie so oft hat in der Vergangenheit dafür eine einzelneCompany Connect Anbindung der Telekom mit 2 Mbit/s gereicht. Diese Leitung war mit redundanten Cisco-Routern und zudem einerZweiwegeführung ausgestattet. Der Kunde hatte nun bei der Telekom eine weitere Company Connect Anbindung beauftragt, mit 34 Mbit/s und ebenfalls redundanten Cisco-Routern und Zweiwegeführung. Auf der WatchGuard waren diese beiden Anbindungen als Multi-WAN konfiguriert – im Failover-Modus.
Bei einem Routine-Check des “Status Report” im Firebox System Manager ist mir in der ARP Table der WatchGuard aufgefallen, dass dort beide vorgelagerten Router-Paare (2 Mbit an eth0 und 34 Mbit an eth1) mit der gleichen Hardware MAC Adresse 00:00:0C:07:AC:01 aufgeführt waren.

Recherche hat ergeben, dass dies eine virtuelle MAC-Adresse ist, die vonredundanten Cisco-Routern im HSRP Modus verwendet wird – und zwar dann, wenn auf den Routern die HSRP Group ID = 1 eingestellt ist. Offenbar hat der ISP also beide Router-Paare (da verschiedene Einzelaufträge) per Default mit der gleichen HSRP Group versehen… Das wird auch erst dann zum Problem, wenn beide Leitungen wie im vorliegenden Fall an das gleiche System angeschlossen werden. Die Auswirkungen kann man sich ausmalen.
Ein Support Call bei der Telekom hat dazu geführt, dass ein Router-Paar auf dieHSRP Group ID = 2 eingestellt wurde, wodurch sich die virtuelle MAC-Adresse auf 00:00:0C:07:AC:02 geändert hat und nunmehr aus Sicht der WatchGuard die Interfaces sauber konfiguriert sind:

NIC Einstellungen auf dem Cluster Interface per Hand ändern

Comment

Im Normalbetrieb kann man ja für jedes Firewall-Interface die Ethernet Geschwindigkeit (10/100/1000 Mbit) und Full Duplex bzw. Half Duplex über Network > Configuration manuell einstellen, wobei aber in der Regel die Einstellung “Auto Negotiate” beibehalten werden sollte, solange keine Ethernet Errors und Collisions offensichtlich sind. Im HA Cluster-Betrieb können die NIC Einstellungen auf dem/den “Cluster-Interface(s)”, mit denen die Boxen direkt miteinander verbunden sind, jedoch NICHT manuell beeinflusst werden! Im Regelfall befinden sich beide Cluster Member direkt beieinander und sind mit einem normalen Patchkabel (1:1 oder Cross-Over) verbunden. In manchen Installationen befinden sich die beiden Cluster-Boxen aber in verschiedenen Räumen/Rechenzentren und sind teilweise mehrere Hundert Meter weit voneinander entfernt. Bei diesen Entfernungen kommen dann Querverbindungen zum Einsatz, die auf LWL/Glasfaser-Technik basieren. Je nachdem wie die Netzwerk-Infrastruktur an beiden Lokationen aussieht und wie viele freie LWL-Fasern zur Verfügung stehen, werden die Interfaces der beiden Fireboxen dann entweder direkt miteinander verbunden (über LWL-Medienkonverter) – oder über VLANs, die auf entsprechenden Switchen an beiden Lokationen konfiguriert sind. In beiden Fällen hatte ich nun in der Praxis bereits Fälle, dass speziell die HA-Verbindung (Cluster Interface) zwischen den beiden Boxen Probleme bereitet hat und Ethernet Errors und Collisions auftraten. Teilweise konnten die beteiligten externen Netzwerk-Komponenten (=Medien-Konverter) nicht auf einen festen Wert eingestellt werden oder es gab nach wie vor Probleme, egal auf welche Werte das Interface auf dem beteiligten VLAN-Switch (z.B. HP) eingestellt war. Hier kann dann nur über die WatchGuard versucht werden, das Problem abzustellen. Aber wie gesagt, für das Cluster Interface lassen sich keine festen Werte über die GUI einstellen. Also muss hier mal wieder ein Texteditor und ein manueller Eingriff in die XML-Konfigurationsdatei ran… 😉

Weiterlesen »

NIC Einstellungen auf dem Cluster Interface per Hand ändern

1 Comment

Im Normalbetrieb kann man ja für jedes Firewall-Interface die Ethernet Geschwindigkeit (10/100/1000 Mbit) und Full Duplex bzw. Half Duplex über Network > Configuration manuell einstellen, wobei aber in der Regel die Einstellung “Auto Negotiate” beibehalten werden sollte, solange keine Ethernet Errors und Collisions offensichtlich sind. Im HA Cluster-Betrieb können die NIC Einstellungen auf dem/den “Cluster-Interface(s)“, mit denen die Boxen direkt miteinander verbunden sind, jedoch NICHT manuell beeinflusst werden! Im Regelfall befinden sich beide Cluster Member direkt beieinander und sind mit einem normalen Patchkabel (1:1 oder Cross-Over) verbunden. In manchen Installationen befinden sich die beiden Cluster-Boxen aber in verschiedenen Räumen/Rechenzentren und sind teilweise mehrere Hundert Meter weit voneinander entfernt. Bei diesen Entfernungen kommen dann Querverbindungen zum Einsatz, die auf LWL/Glasfaser-Technik basieren. Je nachdem wie die Netzwerk-Infrastruktur an beiden Lokationen aussieht und wie viele freie LWL-Fasern zur Verfügung stehen, werden die Interfaces der beiden Fireboxen dann entweder direkt miteinander verbunden (über LWL-Medienkonverter) – oder über VLANs, die auf entsprechenden Switchen an beiden Lokationen konfiguriert sind. In beiden Fällen hatte ich nun in der Praxis bereits Fälle, dass speziell die HA-Verbindung (Cluster Interface) zwischen den beiden Boxen Probleme bereitet hat und Ethernet Errors und Collisions auftraten. Teilweise konnten die beteiligten externen Netzwerk-Komponenten (=Medien-Konverter) nicht auf einen festen Wert eingestellt werden oder es gab nach wie vor Probleme, egal auf welche Werte das Interface auf dem beteiligten VLAN-Switch (z.B. HP) eingestellt war. Hier kann dann nur über die WatchGuard versucht werden, das Problem abzustellen. Aber wie gesagt, für das Cluster Interface lassen sich keine festen Werte über die GUI einstellen. Also muss hier mal wieder ein Texteditor und ein manueller Eingriff in die XML-Konfigurationsdatei ran… 😉

Je nachdem, wie bzw. wie oft das betreffende Interface vorher schon mal konfiguriert war, findet sich in der Konfig-Datei dann folgende Stelle:

[Schnipp] (für die Ansicht hier “<" und ">” durch “{” und “}” ersetzt)

{interface}
   {name}Optional-5{/name}
   {description /}
   {property}0{/property}
   {if-item-list}
    {item}
     {item-type}1{/item-type}
     {physical-if}
      {if-num}6{/if-num}
      {enabled}1{/enabled}
      {if-property}4{/if-property}
      {ip}0.0.0.0{/ip}
      {netmask}255.255.255.255{/netmask}
      {mtu}1500{/mtu}
      {auto-negotiation}1{/auto-negotiation}
      {link-speed}100{/link-speed}
      {mac-address-enable}0{/mac-address-enable}
      {mac-address /}
      {full-duplex}1{/full-duplex}

[Schnapp]

Die fett markierten Stellen sprechen für sich und müssen eben entsprechend händisch angepasst werden, also Auto Negotiation ausschalten (=0) und die entsprechenden Werte für Link Speed und Full Duplex an (=1) bzw. aus (=0) einstellen. Anschließend kann die XML-Datei gespeichert und auf die Firebox hochgeladen werden. Im Policy Manager unter Network > Configuration wird dann auch die Änderung des “NIC Speed” angezeigt (also z.B. 100 Mbit Full Duplex)…

Korruptes Zertifikat entfernen

1 Comment

Vor ein paar Tagen hatte ich mit einer X750e (Softwareversion Fireware XTM 11.3.4) zu tun, die im Basic Managed Mode als Außenstelle an einem WatchGuard Management Server lief (Softwareversion WSM 11.5.3). Die BOVPN-Tunnel waren als Managed VPN Tunnels über den Management Server eingerichtet. Die BOVPN-Tunnel kamen nicht mehr hoch und die X750e ließ über WSM / Policy Manager auch keine Änderungen an der Konfiguration zu – auch dann nicht, wenn man mit einem lokalen WSM direkt mit der Box verbunden war. Fehlermeldung beim Schreiben einer Konfiguration: “An error occured while retrieving all certificates from the Firebox [IP]). Unable to send request to module”. Ein Neustart der Box brachte keine Änderung.

Die Fehlersuche zeigte Probleme mit den Zertifikaten auf der X750e. “View… Certificates” aus dem Firebox System Manager konnte die Zertifikate nicht anzeigen (leeres Feld und darüber eine leere Fehlermeldung).

Auch im CLI Modus brachte der Befehl “show certificates” nur eine Fehlermeldung. Der certd daemon lief auch nicht. Ich hatte einen ähnlichen Fall bereits vor ein paar Monaten. Damals waren auch Zertifikate kaputt, die Box ließ sich jedoch noch über WSM / Policy Manager administrieren. Damals konnte ich das Problem durch ein Software-Update auf eine neuere Fireware XTM Version beheben. Vermutlich hätte auch das Aufspielen der gleichen Version geholfen. Da jetzt aber WSM / Policy Manager nicht mehr funktionierten, habe ich dieses Mal über das Web-Interface gearbeitet (System > Upgrade OS) und auf diesem Weg die 11.3.4er sysa-dl Datei erneut hochgeladen. Nach dem Reboot war certd wieder da und die Zertifikate waren wieder sichtbar. Anschließend konnte die Box auch wieder an den zentralen Management Server angebunden werden, jedoch kamen die Managed VPN Tunnel immer noch nicht hoch. Als nächstes habe ich den zentralen WSM / Management Server näher untersucht. Beim Versuch, die Managed VPN Tunnel neu anzulegen, stürzte der WSM jedes Mal mit einer Fehlermeldung der AppMngr.exe ab. Ein Neustart des Dienstes half nicht, auch nicht der Reboot der kompletten Windows Server 2008 Maschine.

Als temporären Workaround wollte ich nun den BOVPN Tunnel zwischen der Außenstelle und dem zentralen System (ein XTM 810 Active/Passive Cluster mit Fireware XTM 11.5.3) manuell anlegen, damit die User zumindest erst einmal wieder arbeiten konnten. In der XML Konfigurationsdatei des zentralen XTM810 Clusters ist mir dann aufgefallen, dass dort noch die DVCP-basierte Gateway- und Tunnel-Definition der alten “Managed VPN” Verbindung angezeigt wurde, obwohl diese eigentlich gar nicht mehr vorhanden sein sollte. Durch ein Cluster Failover verschwanden diese Fragmente dann aus der zentralen Firewall-Konfiguration, woraufhin auch der WSM / Management Server nicht mehr abschmierte und schlussendlich der BOVPN Tunnel doch wieder regulär als “Managed VPN” Tunnel erfolgreich eingerichtet werden konnte…

XTM 330 soll HA (Cluster) fähig werden

Comment

Die Watchguard XTM 330 wird ab Werk bereits mit dem XTM Pro Upgrade und den damit verbundenen Funktionserweiterungen wie Multi-WAN, Policy Based Routing, Dynamic Routing, QoS und der Maximalzahl der vorgesehenen 55 SSLVPN-User ausgeliefert. Bei den größeren Modellen ab XTM 5 aufwärts ist bei XTM Pro auch die Cluster-Fähigkeit (HA) in den Versionen Active/Active und Active/Passive enthalten.
Derzeit wird jedoch bei der XTM 330 kein HA (Cluster) unterstützt!
In einer der künftigen Softwareversionen soll jedoch die Clusterfähigkeit auch für die XTM 330 freigeschaltet werden!

Multi-WAN Konflikt mit zwei redundanten Cisco HSRP Router-Paaren

Comment

Das Debugging einer problembehafteten HA Umgebung aus zwei X750e mit Fireware XTM 11.3.2 (ich betrachte diese Version derzeit für Cluster aus X Core / Peak e-series am stabilsten) hat heute einen netten Sonderfall aufgezeigt, der für die Störungen sicher mitverantwortlich war:

Der Kunde betreibt schon seit vielen Jahren ein WatchGuard VPN mit ca. 40 Außenstellen. Wie so oft hat in der Vergangenheit dafür eine einzelne Company Connect Anbindung der Telekom mit 2 Mbit/s gereicht. Diese Leitung war mit redundanten Cisco-Routern und zudem einer Zweiwegeführung ausgestattet. Der Kunde hatte nun bei der Telekom eine weitere Company Connect Anbindung beauftragt, mit 34 Mbit/s und ebenfalls redundanten Cisco-Routern und Zweiwegeführung. Auf der WatchGuard waren diese beiden Anbindungen als Multi-WAN konfiguriert – im Failover-Modus.

Bei einem Routine-Check des “Status Report” im Firebox System Manager ist mir in der ARP Table der WatchGuard aufgefallen, dass dort beide vorgelagerten Router-Paare (2 Mbit an eth0 und 34 Mbit an eth1) mit der gleichen Hardware MAC Adresse 00:00:0C:07:AC:01 aufgeführt waren.

Recherche hat ergeben, dass dies eine virtuelle MAC-Adresse ist, die von redundanten Cisco-Routern im HSRP Modus verwendet wird – und zwar dann, wenn auf den Routern die HSRP Group ID = 1 eingestellt ist. Offenbar hat der ISP also beide Router-Paare (da verschiedene Einzelaufträge) per Default mit der gleichen HSRP Group versehen… Das wird auch erst dann zum Problem, wenn beide Leitungen wie im vorliegenden Fall an das gleiche System angeschlossen werden. Die Auswirkungen kann man sich ausmalen.

Ein Support Call bei der Telekom hat dazu geführt, dass ein Router-Paar auf die HSRP Group ID = 2 eingestellt wurde, wodurch sich die virtuelle MAC-Adresse auf 00:00:0C:07:AC:02 geändert hat und nunmehr aus Sicht der WatchGuard die Interfaces sauber konfiguriert sind: