Tag Archives: Cluster

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

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?

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”.

Active/Passive Cluster in 11.2.3 verwendet wieder vrrp

Eine der Neuerungen der Softwareversion Fireware XTM 11.2.3 ist, dass Active/Passive Cluster nun wieder vrrp verwenden – wie bei Fireware 10. In der Version Fireware XTM 11.1 wurden Unicast IP-Adressen eingeführt, so dass die ARP Tabelle die IP 1.1.1.1 zusammen mit der MAC Adresse des Master Devices zeigte. Bei einem Failover auf den Backup Master sah man die IP 1.1.1.1, jetzt aber mit der MAC Adresse des Secondary Devices. Der Wechsel wurde durch ein GARP Paket angekündigt (Gratuitous ARP), was jedoch von vielen Switchen und Routern nicht verstanden wurde, wodurch die tatsächlichen Unterbrechungszeiten wesentlich länger waren als eigentlich nötig.

In der Version 11.2.3 wird nun wieder vrrp verwendet. Die IP 1.1.1.1 hat nun eine unveränderliche virtuelle MAC Adresse 00-5E-00-xx-xx-xx – egal welcher Cluster-Knoten gerade aktiv ist. Die Management IP-Adressen sind aber noch immer Unicast.
Bei einem Software-Update auf 11.2.3 kann es nun erforderlich sein, auch die Switch-Konfiguration anzupassen, weil ggfs. Spanning Tree und Port Security Restriktionen die ARP/MAC Tabellen auf ein einzelnes Interface begrenzen. Der zuständige Switch-Admin sollte also immer “mit im Boot sein”…

Generell gilt ja bei Clustern unter Version 11, dass immer alle aktiven Ethernet-Ports überwacht werden (“Link State”). Unter Version 10 konnte dies noch portweise abgeschaltet werden. Bei Version 11 ist also genau zu überlegen, ob/wann einmal ein Kabel eines aktiven Interfaces aus der Firebox gezogen werden soll, denn dadurch wird ein Failover ausgelöst. Nicht benötigte Interfaces sollten daher unter Network > Configuration immer auf “Disabled” gesetzt werden.

Any-Alias in Firewall-Regeln und BOVPN-Probleme

Im Rahmen eines weiteren PCI Compliance Projekts stand vor zwei Wochen auch die Migration einer WatchGuard X5500e von Fireware 10.2.9 nach Fireware XTM 11.2.3 an sowie die Erweiterung um eine zweite X5500e zu einem HA Active/Passive Cluster. Der Kunde hatte bereits vor einigen Monaten die Migration auf eine frühere 11-er Version versucht, war aber daran gescheitert, dass zwar alle über den WatchGuard Management Server verwalteten Branch Office VPN-Tunnel funktioniert haben – nicht jedoch die über “Manual IPSec” eingerichteten BOVPN-Tunnel zu seinem outgesourceten Rechenzentrum und zu ein paar anderen externen Partnern.
Ich konnte nun erkennen, dass das Problem nicht auf Seiten der VPN-Konfiguration lag, sondern in der Formulierung einiger FIREWALLREGELN. So lautete die Firewall-Regel für “ping” From:Any To:Any. Offenbar hat aber die Firewall nicht erkannt, dass auch Ziele hinter einem BOVPN-Tunnel zu dem Alias “Any” gehören… Insofern wurden pings trotz korrekt vorhandenem VPN-Tunnel als Unhandled Internal Packet eingestuft und verworfen. Abhilfe schuf hier die Aufsplittung dieser einen Firewall-Regel in mehrere einzelne Regeln, z.B. Ping.Out.Internet = From:Any-Trusted To:Any-External und Ping.Out.VPN = From:Any-Trusted To:Any-BOVPN sowie ein paar weitere erforderliche Kombinationen z.B. für die Gegenrichtung From:Any-BOVPN To:Any-Trusted. Diese grundsätzliche Splittung in separate Firewall-Regeln für klassischen gerouteten Firewall-Traffic und VPN-Traffic hat sich bewährt! Die Migration von 10 auf 11 auf Basis der geänderten Konfigurationsdatei war dann auf Anhieb erfolgreich.

Quick Setup Wizard 11.2.3 und XTM 830

Ich konnte nun bei der Erst-Inbetriebnahme von zwei WatchGuard XTM 830 sehen, dass der Quick Setup Wizard der Version 11.2.3 bei diesem Modell offenbar etwas Probleme hat festzustellen, dass die Installation eigentlich korrekt durchgelaufen ist. Trotz Fehlermeldungen seitens des Quick Setup Wizard waren beide Boxen korrekt installiert und konnten anschließend auch sauber als HA Active/Passive Cluster in Betrieb genommen werden.

1-to-1 NAT Probleme bei 11.2.3 HA Active/Passive Cluster

In der Softwareversion Fireware XTM 11.2.3 ist offenbar ein Bug zurück, der vor ein paar Sub-Releases bereits gefixt war. Im Rahmen eines PCI Compliance Projekts durfte ich letzte Woche einen WatchGuard XTM 1050 Active/Passive Cluster von 11.1 auf 11.2.3 updaten. Nach dem Update mussten wir bei Tests feststellen, dass sich nach einem Failover das EXTERNE Interface nicht sauber initialisieren konnte. Alle anderen Optional und Trusted Interfaces arbeiteten korrekt. Das Problem trat nicht auf, wenn nur EIN Cluster-Knoten eingeschaltet war (zweite Box aus).
Bei der folgenden Analyse stellte sich heraus, dass die in der Konfigurationsdatei hinterlegten 1-to-1 NAT Einträge zusammen mit der aktuellen Softwareversion 11.2.3 das Problem in einer Cluster-Konstellation hervorrufen. Dieses Verhalten wurde von WatchGuard als Bug klassifiziert (BUG44667: 11.2.3 FireCluster A/P connections failing for 1-1-NAT entries). Da dieser Fehler bereits einmal behoben war, rechne ich damit, dass ein Bugfix sehr kurzfristig zur Verfügung stehen wird. In diesem Kundenprojekt wurde jedoch entschieden, dass das NATting künftig bereits auf dem vorgelagerten Router stattfindet, so dass der XTM1050-Cluster nur noch sauber routen braucht.

(K)ein Problem von spamBlocker

Einen kuriosen Support-Fall durfte ich gestern lösen: seit dem Update auf WatchGuard Fireware XTM 11.2.3 lief der spamBlocker in einem X1250e Active/Passive HA Cluster nicht mehr. Alle Spams kamen ungefiltert durch, im Traffic Monitor stand jedes Mal ProxyAllow: SMTP Message classification is unknown because an error occurred while classifying.
Die Analyse brachte jedoch ein ganz anderes Problem ans Tageslicht: der Status Report des Firebox System Manager vermeldete, dass das externe Interface (eth0) des zweiten Cluster-Knotens keinen Ethernet-Link hatte. Nach Austausch des Patchkabels war der Link wieder da. Nach einem darauf folgenden Failover auf den zweiten Cluster-Knoten lief der spamBlocker wieder.Nach einem erneuten Failover/Failback auf den zuvor “alleine” aktiven Clusterknoten lief spamBlocker wieder nicht. Erst nach einem Reboot des ersten Clusterknoten arbeitete spamBlocker wieder korrekt auf beiden Cluster-Knoten.

Probleme beim Update von Gateway Antivirus Signaturen im HA Cluster Betrieb

Mir ist in zwei Cluster-Installationen ein merkwürdiges Verhalten bei den Updates der GAV Signaturen aufgefallen. Verbindet man sich über den Firebox System Manager mit der Cluster-IP, wird bei Subscription Services > Gateway Antivirus als Installed version eine kleinere Zahl angezeigt als bei Version available – es steht also eine aktuellere Version bereit. Wenn man über Klick auf Update ein manuelles Update auslöst, läuft dies auch erfolgreich durch und bei Installed version taucht KURZZEITIG die gleiche Zahl auf wie bei Version available. Nach einigen Sekunden bzw. nach dem nächsten Refresh steht dort jedoch wieder die ursprüngliche, niedrigere Zahl. Ein Klick auf History zeigt jedoch, dass das Update korrekt durchgelaufen ist.
Verbindet man sich nun mit der Management IP der aktiven Box (master), wird dort auch korrekt die höhere Versionsnummer angezeigt. Verbindet man sich mit der Management-IP der Standby-Box (backup master), wird die niedrigere Versionsnummer angezeigt. Offenbar scheitert also der automatische Abgleich zwischen den beiden Boxen, der eigentlich im Hintergrund stattfinden sollte.

Die Lizensierung der UTM-Services beim Active/Passive HA Betrieb erfordert ja, dass NUR auf der Primary Box die UTM Services lizensiert sind, für die Secondary Box reicht die normale Live Security aus. Im Praxisbetrieb gibt es aber offenbar derzeit Schwierigkeiten bei der Synchronisierung der Lizenzen, so dass es wohl vorkommt, dass die UTM-Services nicht korrekt laufen, wenn gerade einmal die Secondary Box die aktive Box (master) ist.
USA Support stellt in diesem Fall neue Feature Keys bereit, wenn im Rahmen eines Support Incidents die betroffenen Seriennummern der Cluster Member angegeben werden. Das Lizenzproblem soll im kommenden Software-Release behoben sein.

Management IP der passiven Box in einem 11.2.1 Active/Passive HA Cluster nicht erreichbar

In einem Active/Passive HA Cluster unter Fireware XTM v11.x haben beide Firewalls zusätzlich zu der gemeinsamen Traffic IP auch noch jeweils eine eigene Management IP-Adresse. Bei der Einrichtung des Clusters wird gefragt, über welches Interface der Management-Zugriff erfolgen soll. In vielen Fällen wird man das reguläre Trusted Interface wählen, wodurch die Management IP als Secondary IP (z.B. eth1:1) mit auf das Trusted Interface gebunden wird. Die Management IP hat u.a. den Vorteil, dass man nun auch die passive Box in einem Cluster “ansprechen” kann, was vorher nicht ging.

Wenn ein Netzwerk-Monitoring-System im Einsatz ist (z.B. Nagios), wird man daher auch die Management IP Adressen – auch die der passiven Box – überwachen (oder zumindest anpingen) wollen. In einem aktuellen Projekt hat das jedoch nicht funktioniert. Die nähere Untersuchung hat ein Verhalten aufgezeigt, das bei WatchGuard bereits als Bug bekannt ist:
Im passiven Zustand werden alle IP-Adressen von den Interfaces entfernt, bis auf die Management IP (und die Cluster IP auf dem dedizierten HA Interface). Die Subnetzmaske auf dem Interface der Management IP wird jedoch fest auf /24 (255.255.255.0) eingestellt:

– unabhängig davon, welche Subnetzmaske im aktiven Zustand auf diesem Interface eingestellt ist (!):

Zudem enthält die Routing Table der passiven Box kein Default Gateway:

Dies führt dazu, dass die Management IP der passiven Box dem Monitoring-System nicht antworten kann, es sei denn, dass die ersten drei Oktets der IP-Adresse zufälligerweise identisch sind und das Netz größer gleich /24 ist…

SSL VPN Probleme nach Update von 11.1 auf 11.2

In einem aktuellen Supportfall hatte der Kunde seine Firebox X550e von Fireware XTM v11.1 auf 11.2 upgedated. Anschließend konnten die mobilen User über den WatchGuard SSL VPN Client 11.1 keine Verbindung mehr herstellen. Fehlermeldung: “Could not download the configuration file…”.
Ich vermute einen Zusammenhang mit der fehlerhaften Migration der integrierten WatchGuard-eigenen SSL-Zertifikate. Neben den gültigen SSLVPN-Zertifikaten (“Signed”) befinden sich im Zertifikatsspeicher noch weitere Zertifikate im Status “Pending”, die offenbar die gültigen Zertifikate behindern.

Die “Pending” Zertifikate können wie folgt gelöscht werden: Per WSM mit der Firebox verbinden, den Firebox System Manager starten, dort View > Certificates, Pending-Zertifikate anklicken und “Delete”. Anschließend Reboot der Firebox. Handelt es sich um einen Cluster, müssen beide Boxen zur gleichen Zeit ausgeschaltet werden!