Tag Archives: High Availability

Best Practices: Hochverfügbarkeit dank WatchGuard Firecluster

Comment

In diesem Webinar wird erklärt, wie Sie WatchGuard FireCluster einrichten und konfigurieren können. Darüber hinaus werden die Unterschiede zwischen einem Active/Active und Active/Passive Cluster erläutert.  Mit WatchGuard FireCluster wird die Hochverfügbarkeit (High Availability) ihrer Firewalls gewährleistet. Damit lassen sich kritische Ausfallzeiten und somit zusammenhängende finanzielle Verluste im Unternehmen vermeiden.

Das Webinar ist wie folgt gegliedert:
Weiterlesen »

Neue WatchGuard Firebox Appliance aktivieren

Comment

Um eine WatchGuard Firebox Appliance überhaupt sinnvoll nutzen zu können, muss diese über die WatchGuard Website aktiviert werden. Das bedeutet, dass die Seriennummer bei WatchGuard registriert werden muss, damit man anschließend den Feature Key (die Lizenzdatei) herunterladen kann. Der Feature Key wird dann bei der Inbetriebnahme über den Web Setup Wizard gebraucht.

Weiterlesen »

Wie Auto Negotiation auf HA Port abschalten?

Comment

In einem Hochverfügbarkeits-Projekt sollten zwei WatchGuard Firebox X5000 mit Fireware 10.2.11, die bislang “klassisch” per Crossover-Patchkabel miteinander verbunden waren, auf zwei mehrere Hundert Meter auseinander liegende, aber mit ausreichend LWL/Glasfasern verbundene Serverräume verteilt werden. Die Telekom stellte zudem eine Zweiwege-Zuführung bereit. Die beteiligten Router regeln die dynamische Umschaltung der IP-Adressen im Bedarfsfall selbst. Aus Sicht des Firebox-Clusters handelt es sich also um eine einfache, klassische “Static IP” Konfiguration.

Für alle im Einsatz befindlichen Interfaces (hier: External, Trusted und eine DMZ) wurde pro Serverraum jeweils ein dedizierter Cisco-Switch bereitgestellt, die per LWL direkt miteinander verbunden sind. Die HA-Ports der Fireboxen wurden jedoch NICHT über Switche, sondern DIREKT miteinander verbunden – mit zwei Medienkonvertern, die RJ45 auf LWL umsetzen. Bei Inbetriebnahme des Clusters stellte sich heraus, dass die Heartbeats zwischen den Fireboxen nicht korrekt liefen, die Synchronisation der Konfiguration nur teilweise funktionierte und häufig zufällige Failovers ausgelöst wurden.

Problemursache war das offenbar nicht korrekt funktionierende Auto-Sensing zwischen Firebox und Medienkonverter am HA-Interface. Die Konverter waren nicht managebar, also musste seitens der Firebox ein fester Wert für den Betrieb des HA-Interfaces eingestellt werden, z.B. 100 Mbit Full-Duplex. Die GUI des Policy Managers erlaubt dies aber nicht! Sobald HA auf einem Interface aktiviert wird, wird dort automatisch “Auto-Sensing” eingestellt – auch wenn das Interface vorher fest mit 100 Mbit Full-Duplex konfiguriert wurde…

Abhilfe schafft hier der manuelle Eingiff in die XML-Konfigurationsdatei. Nach Aktivierung von HA kann in der XML-Datei für das entsprechende Interface der Wert für < auto-sensing > von 1 auf 0 geändert und die gewünschten Parameter (100 Mbit, Full Duplex) eingetragen werden. Im vorliegenden Fall musste diese Einstellung anschließend auch noch für diezweite Firebox manuell in deren Konfigurationsdatei geändert werden, denn die Synchronisation der Konfigurationen lief auch nach Anpassung der ersten Firebox noch immer nicht korrekt. Danach funktionierte der HA Cluster jedoch korrekt.

Hinweis: Manuelle Eingriffe in die XML-Konfigurationsdatei werden von WatchGuard offiziell “nicht supported” und erfolgen auf “eigene Gefahr”.

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

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)…

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:


Downgrade von Version 11.4.1 auf 11.3.2

Comment

Beim Versuch, eine Firebox mit Fireware XTM 11.4.1 über den Menüpunkt File > Upgrade im Policy Manager auf eine ältere Softwareversion downzugraden, erscheint die Fehlermeldung:

“The WatchGuard device is currently running Fireware XTM v11.4.1 and cannot be downgraded to v11.3.2 in this manner. To downgrade, please restore a backup image of the device when it was running v11.3.2 or use the device’s Recovery Mode to install a clean version of Fireware XTM v11.3.2.”

Die unkomplizierteste Version ist allerdings die Verwendung des Webinterfaces https://[IP-der-Firebox]:8080 (nicht möglich im High Availability Clusterbetrieb). Über den dortigen Menüpunkt System > Upgrade OS kann auch der Downgrade auf ältere Versionen erfolgen. Hierbei muss die gewünschte Version der xtm_xxx.sysa-dl Datei über das Filesystem ausgewählt und hochgeladen werden. Die sysa-dl Dateien befinden sich typischerweise unter C:ProgrammeGemeinsame DateienWatchGuardresourcesFirewareXTM => Versionsnummer => Gerätetyp

Active/Passive HA Failover Problem

Comment

In einem Kundenprojekt (zwei XTM 505 in Active/Passive HA) wurde berichtet, dass nach einem Failover von der Primary auf die Secondary Firebox die Systeme in einer DMZ nicht mehr erreichbar wären. Die Systeme untereinander könnten kommunizieren, auch die Systeme im eigentlichen Trusted Network arbeiten korrekt.
Das Problem scheint sich auf einen bereits bekannten Bug zurückführen zu lassen, der dafür sorgt, dass sich nach einem Failover die neue MAC-Adresse des WatchGuard Clusters nicht in die ARP Table der angeschlossenen Client-PCs einträgt (BUG45223). Das Problem soll in einer der kommenden Software-Releases behoben sein.

Fireware XTM: HA Cluster Probleme mit MTU Size im BOVPN Tunnel

1 Comment

Ich habe aktuell einige offene Support-Fälle, die folgende Gemeinsamkeiten aufweisen: Active/Passive Cluster unter Fireware XTM v11.3.x, Branch Office IPSec VPN Tunnel zu festen Außenstellen, Kommunikationsprobleme innerhalb des/der BOVPN Tunnel.
In allen Fällen scheinen die Probleme mit fehlerhafter Fragmentierung von IPSec-Paketen zu tun zu haben. Ich konnte etwas ausführlicher debuggen und feststellen, dass bisweilen (also nur zeitweise!) IP-Pakete größer als 1394 Bytes im VPN-Tunnel nicht korrekt fragmentiert, sondern komplett verworfen werden. WatchGuard hat das Szenario im TestLab nachgestellt, konnte jedoch die Fehlerursache bis jetzt noch nicht weiter eingrenzen.
Zur schnellen Dokumentation des Problems verwende ich von einem PC in einer Außenstelle eine MSDOS-Eingabeaufforderung mit dem Befehl

ping [IP] -l 2000 -t

wobei [IP] eine IP-Adresse am anderen Ende eines BOVPN-Tunnels (in der Zentrale) ist. Der Befehl erzeugt Ping-Pakete mit einer Größe von 2000 Byte, die also beim Transport über das Internet zwingend fragmentiert werden müssen, da die maximale MTU Size auf Internet-Routern in der Regel 1500 Bytes beträgt. Erhalte ich korrekte ICMP-Antworten, weiss ich, dass die Fragmentierung korrekt funktioniert. Wenn nicht, liegt ein Problem vor. Durch Verkleinern der Paketlänge kann man sich iterativ an den kritischen Wert herantasten. Im vorliegenden Problemfall werden Pings mit 1394 Bytes korrekt übertragen, Pings mit 1395 Bytes und mehr jedoch NICHT:

Das Problem scheint zudem nur auf dem Rückweg von dem angepingten Host aufzutreten. Offenbar erreichen im Problemfall auch größere Datenpakete den Zielhost, der auch korrekt antwortet – jedoch scheint die WatchGuard Firebox ein Problem mit dem “Rücktransport” der Antwortpakete zu haben, wie sich am Vergleich der folgenden, im Abstand von ein paar Minuten aufgenommenen Screenshots erkennen lässt. Die mit grünen Streifen markierten Werte zählen im Laufe der Zeit korrekt hoch, während der eine rot markierte Wert (RCVD zurück auf dem ursprünglich sendenden System) sich nicht ändert…:

In allen meinen Support-Fällen konnte ich das Problem zunächst durch einen Workaround umgehen: auf dem Cluster Reduktion der MTU Size auf den Interfaces, die an BOVPN-Tunneln beteiligt sind, von 1500 auf 1380 Bytes:

WatchGuard muss jedoch das eigentliche Problem finden und beheben, denn durch den Workaround wird die Gesamtleistung der WatchGuard Firebox etwas ausgebremst.

Wie Auto Negotiation auf HA Port abschalten?

1 Comment

In einem Hochverfügbarkeits-Projekt sollten zwei WatchGuard Firebox X5000 mit Fireware 10.2.11, die bislang “klassisch” per Crossover-Patchkabel miteinander verbunden waren, auf zwei mehrere Hundert Meter auseinander liegende, aber mit ausreichend LWL/Glasfasern verbundene Serverräume verteilt werden. Die Telekom stellte zudem eine Zweiwege-Zuführung bereit. Die beteiligten Router regeln die dynamische Umschaltung der IP-Adressen im Bedarfsfall selbst. Aus Sicht des Firebox-Clusters handelt es sich also um eine einfache, klassische “Static IP” Konfiguration.

Für alle im Einsatz befindlichen Interfaces (hier: External, Trusted und eine DMZ) wurde pro Serverraum jeweils ein dedizierter Cisco-Switch bereitgestellt, die per LWL direkt miteinander verbunden sind. Die HA-Ports der Fireboxen wurden jedoch NICHT über Switche, sondern DIREKT miteinander verbunden – mit zwei Medienkonvertern, die RJ45 auf LWL umsetzen. Bei Inbetriebnahme des Clusters stellte sich heraus, dass die Heartbeats zwischen den Fireboxen nicht korrekt liefen, die Synchronisation der Konfiguration nur teilweise funktionierte und häufig zufällige Failovers ausgelöst wurden.

Problemursache war das offenbar nicht korrekt funktionierende Auto-Sensing zwischen Firebox und Medienkonverter am HA-Interface. Die Konverter waren nicht managebar, also musste seitens der Firebox ein fester Wert für den Betrieb des HA-Interfaces eingestellt werden, z.B. 100 Mbit Full-Duplex. Die GUI des Policy Managers erlaubt dies aber nicht! Sobald HA auf einem Interface aktiviert wird, wird dort automatisch “Auto-Sensing” eingestellt – auch wenn das Interface vorher fest mit 100 Mbit Full-Duplex konfiguriert wurde…

Abhilfe schafft hier der manuelle Eingiff in die XML-Konfigurationsdatei. Nach Aktivierung von HA kann in der XML-Datei für das entsprechende Interface der Wert für < auto-sensing > von 1 auf 0 geändert und die gewünschten Parameter (100 Mbit, Full Duplex) eingetragen werden. Im vorliegenden Fall musste diese Einstellung anschließend auch noch für die zweite Firebox manuell in deren Konfigurationsdatei geändert werden, denn die Synchronisation der Konfigurationen lief auch nach Anpassung der ersten Firebox noch immer nicht korrekt. Danach funktionierte der HA Cluster jedoch korrekt.

Hinweis: Manuelle Eingriffe in die XML-Konfigurationsdatei werden von WatchGuard offiziell “nicht supported” und erfolgen auf “eigene Gefahr”.