Tag Archives: High Availability

Active/Passive Cluster in 11.2.3 verwendet wieder vrrp

1 Comment

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

Comment

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

Comment

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

Comment

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.

Probleme beim Update von Gateway Antivirus Signaturen im HA Cluster Betrieb

1 Comment

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

Comment

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 Client 11 läuft nicht in Verbindung mit Fireware 10.x

Comment

Es freut mich sehr, dass mein Blog eine ansehnliche Zahl von WatchGuard-Usern erreicht. Sinn und Zweck dieser Institution ist natürlich auch, meine eigene Expertise in diesem Umfeld darzustellen und auf diese Weise konstruktive Kundenkontakte anzubahnen – unbestritten! Umsonst ist der Tod, und der kostet bekanntlich das Leben! Es entsteht jedoch auch ein interessanter Dialog, wie sich an diesem Beitrag von Michael Schramm zeigt, der mich per E-Mail erreicht hat und den ich hier gerne wiedergeben möchte – ungeprüft, da ich genau die beschriebene Konstellation noch nicht “vor der Flinte” hatte :-). Michael Schramm schreibt:

“Der aktuelle WatchGuard SSLVPN-Client in der Version 11.1 funktioniert nicht mit einer 10er-Fireware. Dies ist leider in den Release Notes nirgends erwähnt – jedenfalls konnte ich keinen entsprechenden Hinweis finden. Öffnet man den Client direkt mit einem passenden Configfile (*.wgssl), erscheint beim Connecten eine irreführende Fehlermeldung: Die Softwareversion auf dem Gerät (1.x) ist kleiner als die Version des Clients (5.x), und man soll auf Yes klicken, um die neue Softwareversion herunterzuladen. Das klappt natürlich nicht und der Client springt dann nach einiger Zeit wieder zurück zur Login-Maske. Der automatische Download des Config-Files funktioniert ebenfalls nicht, da sich in der Fireware XTM 11.x offensichtlich der Pfad zu diesem File geändert hat. Der 11er-Client fragt bei der Firebox nach dem File

https://FIREBOX:4100/?action=sslvpn_download&fw_username=USERNAME&fw_password=PASSWORD&filename=client.wgssl

und bekommt daraufhin von der Firebox “401 unauthorized” zurück (im Logfile des Clients: FAILED, Access denied), während der alte 10er-Client nach diesem File fragt:

https://FIREBOX:4100/?action=sslvpn_download&username=USERNAME&password=PASSWORD&filename=client.wgssl

und dieses dann auch bekommt – man kann es sogar manuell mit einem Browser herunterladen. Das “fw_” vor Username und Password gab es also in der alten Version noch nicht.

Allen Benutzern, die also unter Windows 7 Probleme mit dem 10er-Client haben und deswegen den 11er-Client benutzen wollen, kann von dieser Idee nur abgeraten werden, solange auf der WatchGuard Firebox noch eine Fireware 10.x läuft.

Der 10er-Client funktioniert im übrigen bei mir unter Windows 7, nativ und ohne Kompatibilitätsmodus, einwandfrei! Falls es also mit dem 10er-Client unter Windows 7 zu Problemen kommt, liegt das schätzungsweise eher an etwas anderem. Ich hatte z.B. konkret das Problem, dass sich der Client immer nur sporadisch und völlig ohne erkennbares Muster connecten ließ. Des Rätsels Lösung war ein falsch konfigurierter Switchport für das entsprechende WAN-Interface auf der Secondary Firebox [Anm. BO: in einem Cluster!]. Die Ports auf beiden Fireboxen stehen auf 100FDx, der entsprechende Switchport stand auf Auto und hat sich dann immer auf 100HDx eingependelt. Deswegen konnte ich mich immer dann nicht verbinden, wenn gerade die Secondary Firebox die aktive war…”

Soweit Michael Schramm! Vielen Dank für diesen konstruktiven Beitrag. Ergänzend zum letzten Absatz von mir noch einmal der Hinweis auf einen meiner früheren Beiträge: http://de.watchguard-blog.com/2008/12/verbindungsprobleme-wegen-ethernet.html: Lassen Sie möglichst ALLE Interfaces der WatchGuard Firebox auf “Auto Sensing” – und sorgen Sie NUR bei offensichtlichen Kompatibilitätsproblemen zunächst dafür, dass das direkt an der WatchGuard Firebox angeschlossene Ethernet-Device (Switch/Router) auf einen festen Wert eingestellt wird…

Lizensierungsproblem bei FireCluster unter XTM v11.0 und 11.0.1

Comment

In den Versionen Fireware XTM 11.0 und 11.0.1 gibt es im Active/Passive Clusterbetrieb aktuell ein Lizensierungsproblem beim Einsatz der UTM Services. Grundsätzlich reicht es im Active/Passive Modus aus, dass die UTM Services nur auf der PRIMARY Box lizensiert sind. Für die SECONDARY Box reicht die “nackte” Live Security aus. Findet unter 11.0 und 11.0.1 jedoch ein Failover auf die Secondary Box statt, funktionieren die UTM Services WebBlocker, spamBlocker und Gateway Antivirus/IPS dann nicht, da ein Bug die UTM Lizenzen nicht korrekt auf die Secondary Box synchronisiert und die Services dann einfach nicht angewendet werden… Dieser Bug wird mit Version 11.0.2 behoben. Betroffene Kunden können sich in der Zwischenzeit von Customer Care eine temporäre Lizenz für die Secondary Box ausstellen lassen.

HA Cluster: “Peer Status is in-transition”

Comment

Beim Speichern einer neuen Konfiguration auf einen HA Cluster kommt es bisweilen zu dem Zustand Peer Status is in-transition anstelle des normalen “Peer Status is standby”. Zu diesem Verhalten kann es kommen, wenn während des Speicherns gerade mobile User über PPTP-VPN eingewählt sind.

[30.01.2009]: Laut Release Notes soll dies nun mit der Fireware 10.2.7 behoben sein.