Tag Archives: Policy Manager

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

Kein automatischer Reboot nach Migration

Comment

In einem früheren Posting hatte ich beschrieben wie man eine Firebox regelmäßig und automatisch zu einem bestimmten Zeitpunkt booten lassen kann. Ich habe nun Fälle gesehen, dass dies mit Softwareversionen kleiner 11.2.3 überhaupt nicht gegriffen hat – oder nach Migration auf 11.2.3 nicht mehr greift. Ich konnte Abhilfe schaffen, in dem das Häkchen bei Automatic Reboot (Policy Manager: Setup > Global Settings) entfernt wurde, die Konfig auf die Firebox gespeichert wurde, anschließend das Häkchen wieder gesetzt und die Konfig erneut auf die Firebox gespeichert wurde. Der 1:1 Vergleich der XML-Dateien zeigt keinen Unterschied, insofern muss das Setting wohl auf der Firebox selbst hinterlegt gewesen sein.

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.

Dual Install von WSM 10.2.x und WSM 11.2.x

Comment

Wenn Sie – zum Beispiel für Migrationszwecke – auf der gleichen Windows-Maschine sowohl die Client-Komponenten des WSM 10.2.x als auch WSM 11.2.x benötigen, ist die Reihenfolge wichtig, in der die Installer ausgeführt werden:
Installieren Sie immer zuerst den WSM 10.2.x – und erst danach den WSM 11.2.x!

Wird der WSM 10 nämlich nach dem WSM 11 installiert, zerschießt der nachträglich ausgeführte WSM 10-Installer wichtige Teile der WSM 11-Komponenten. So kommt es dann bei der Migration von Fireboxen zu Problemen. Der Policy Manager von WSM 11 meldet beispielsweise beim Zugriff auf eine 10-er Box java.lang.IllegalArgumentException: Cannot support TLS_RSA_WITH_AES_256_CBC_SHA with currently installed providers. Oder sowohl “Quick Setup Wizard” als auch “Web Quick Setup Wizard” von WSM 10 laufen zwar durch, enden aber mit einer Fehlermeldung. Die Firebox selbst hängt, im LCD Display steht XModemRcv 115200 Start Remote Send…. Die Box lässt sich in diesem Zustand nur noch wieder in den Safe Mode booten (Down-Button), aber das hilft nicht weiter…

Bereinigen Sie die Installation auf Ihrer Windows-Maschine wie folgt:

  • WSM 10.x und 11.x deinstallieren
  • Restliche Fragmente der Java Runtime Engine in “Common FilesWatchGuardjava” löschen (“Gemeinsame Dateien”…)
  • Neuinstallation WSM 10.2.x
  • Neuinstallation WSM 11.2.x
  • Quick Setup Wizard der 10.2.x durchführen
  • Box sollte dann wieder „normal“ booten
  • Über den WSM 11.2.x mit der Box verbinden
  • Über den Policy Manager von 11.2.x die Box updaten…

Natürlich haben Sie sichergestellt, dass Sie Zugriff auf die letzte funktionierende XML-Konfigdatei und eigene Zertifikate/CA haben… 🙂

Unable to load proxy bei 11.2.3

Comment

Wegen ein paar größerer Projekte in den letzten Wochen hatte ich für den Blog leider keine Zeit. Nächste Woche schreibe ich wieder mal ein paar Artikel, denn es gibt doch einiges zu berichten. Hier in aller Schnelle schon mal eine Problembeschreibung, für die es aber schon eine Lösung gibt:

Die Version 11.2.3 hat teilweise Probleme mit Proxy-Regeln. Das äußert sich so, dass Traffic durch Paketfilter einwandfrei abgearbeitet wird (ping, Filtered-DNS usw.), Traffic durch Application Proxies (z.B. HTTP-Proxy, FTP-Proxy, POP3-Proxy, SMTP-Proxy) jedoch nicht. Auf Deutsch: Kunde kann pingen, Namensauflösung funktioniert, er kann aber trotzdem nicht auf Webseiten zugreifen. Im Traffic Monitor tauchen Meldungen auf wie “http-proxy unable to load” oder “proxy failed”.

WatchGuard stellt in diesen Fällen im Rahmen eines Support Incident einen Patch (11.2.3CSP2, appliance build 270901) zur Verfügung, der das Problem behebt (BUG44474: Proxies fail after configuration save).

Fireware XTM v11 und Windows 2000 Active Directory User Authentication

3 Comments

Die Release Notes von WSM und Fireware XTM v11 enthalten den lapidaren Satz “We no longer support Microsoft Windows 2000”. Eine damit zusammenhängende Erscheinung hat mir die Tage etwas Kopfzerbrechen beschert: User Authentication gegenüber einer nativen Windows 2000 Domäne. Nach dem Upgrade von WSM/Fireware 10.2.7 auf 11.2.1 funktionierte sowohl die Web Authentication über Port 4100 nicht mehr (“user name or password invalid”) als auch die MUVPN-Einwahl über den IPSec-Client (“admd ADM auth Firewall user [xxxxx@Active Directory] Error, Reason – Generic error id=”1100-0012” bzw. “wgcgi Firewall user xxxxx@Active Directory from [IP] rejected – all other error”).
Das liegt daran, dass eine Firebox mit Fireware XTM v11 “anders” in das Active Directory abfragt als die bisherige Fireware 10. Zum Auslesen von Gruppenmitgliedschaften werden jetzt tokenGroups_get Abfragen ins AD gestellt. Damit kann ein natives Windows 2000 Active Directory aber noch nichts anfangen. Erst ein Windows 2003 Domänencontroller kommt damit zurecht. Natürlich sollte heutzutage die AD-Migration kein Problem mehr sein, will aber natürlich trotzdem gut vorbereitet sein. Für die Übergangszeit kann daher mit einem Trick gearbeitet werden, der zwar nicht offiziell supported wird, aber trotzdem funktioniert: anstelle der direkten Active Directory Authentication auf LDAP umstellen – mit ansonsten identischen Einstellungen:

In der Pulldown-Liste von Login Attribute findet sich bei LDAP jedoch nicht das klassische Windows-Attribut sAMAccountName. Dies kann dort aber händisch über die Tastatur eingegeben werden… Natürlich müssen dann ggfs. noch die in Firewallregeln verwendeten Gruppennamen unter Setup > Authentication > Authorized Users and Groups nachgezogen werden. Und unter VPN > Mobile VPN muss auch an den entsprechenden Stellen von Active Directory auf LDAP umgestellt werden.

Probleme mit self-signed Zertifikaten beim Update auf 11.2

Comment

Mir ist es heute zum zweiten Mal passiert, dass nach dem Update einer Firebox X Core bzw. X Peak von Fireware (Pro) 10.2.x auf Fireware XTM v11.2 zwar die Firewall/VPN-Funktionalität da war, die Box jedoch über den WatchGuard System Manager (WSM) nicht mehr ansprechbar war.

In beiden Fällen führe ich das Problem auf das Vorhandensein bzw. die Nutzung eines selbst generierten 3rd Party Zertifikats für die SSL-geschützte Web Authentication Page (Port 4100) zurück. Die Zertifikate waren jeweils von einer eigenen Active Directory-integrierten Zertifizierungsstelle erzeugt worden, damit beim Laden der Firewall-Anmeldeseite auf den Domänen-Mitglieds-PCs die Warnmeldung des Browsers nicht angezeigt wird. Unter Fireware (Pro) 10.2.x hatte dies auch die ganze Zeit problemlos funktioniert.

Beim ersten Fall vor ca. 2 Wochen stand ich sehr unter Zeitdruck (Downtime…) und habe zur schnellen Problemlösung die Brachialmethode gewählt: Factory Default Reset über das Command Line Interface (CLI) [PuTTY/SSH auf Port 4118 der Firebox, Anmeldung als User “admin” mit der Configuration Passphrase (dem “schreibenden Kennwort”)] und Eingabe des Kommandozeilen-Befehls “restore factory-default”. Hierdurch werden u.a. die Firewall-Kennwörter auf die Fireware XTM v11.x Defaults “readwrite” (für den User “admin” bzw. die Configuration Passphrase) und “readonly” (für den User “status” bzw. die Status Passphrase) zurückgesetzt… Anschließend dann das übliche Spiel: Durchklicken des Quick Setup Wizard, Verbinden per WSM, Öffnen des Policy Managers, Laden der letzten funktionierenden Konfigurationsdatei, Ändern der Einstellungen für das Web Server Certificate und “Save to Firebox”…

Heute konnte ich ein paar Minuten Zeit mehr investieren und habe dabei herausgefunden, dass es offenbar auch ausreicht, auf Kommandozeilenebene die Befehle “configure” und “web-server-cert default” auszuführen – also anstelle des 3rd Party Zertifikats das eingebaute Original-WatchGuard-Zertifikat auszuwählen. Anschließend konnte ich auch sofort wieder per WSM auf die Box zugreifen… Interessanterweise konnte ich anschließend im Policy Manager sogar wieder das 3rd Party Zertifikat auswählen und problemlos wieder aktivieren… Das Problem tritt also offenbar nur genau im Moment des Software Upgrades von 10.2.x auf 11.2 auf. Ich werde mir also angewöhnen, bei Migrationen künftig vorsorglich über Setup > Authentication > Web Server Certificate zunächst das Original-WatchGuard-Zertifikat auszuwählen und erst nach der Migration wieder das 3rd Party Zertifikat zu aktivieren…

Menü unvollständig im Policy Manager

Comment

Ein Kunde berichtete heute, dass nach der Einrichtung von WSM 11.2 auf einer frischen virtuellen Maschine im Policy Manager einige (Unter-)Menüs unvollständig angezeigt werden. So würden zum Beispiel unter Setup > Authentication > Authentication Settings die Felder für SSO (Single Sign On) überhaupt nicht angezeigt…

…die auf seinem alten System aber da gewesen wären:

Des Rätsels Lösung ist ein einfaches Grafikproblem: Die Bildschirmauflösung der virtuellen Maschine war auf 1024×768 eingestellt – und bei dieser “geringen” Auflösung werden umfangreiche Menüs eben unvollständig dargestellt. Abhilfe schafft hier entweder das Verbreitern des Pop-Up-Fensters, so dass durch geänderten Zeilenumbruch (weniger Zeilen) mehr “Platz” in der Vertikalen entsteht – oder aber einfach das Hochsetzen der Bildschirmauflösung auf 1280×1024 oder darüber…

Zeitgesteuerter PPPoE Reconnect oder Reboot bei 11.2

2 Comments

Die Fireware XTM v11.2 stellt für alle Plattformen ein neues Feature bereit, das speziell für den deutschen Markt mit seiner berühmten 24 Stunden DSL-Zwangstrennung interessant ist. Wenn ein External Interface auf PPPoE eingestellt ist, kann über Network > Configuration > [External] > Configure > Advanced Properties (Button ganz unten) ein täglicher PPPoE Reconnect zu einer bestimmten Uhrzeit ausgelöst werden.

Legt man diesen Zeitpunkt in eine betriebsarme Zeit (Nacht), kann man bei sonst stabiler DSL-Verbindung dadurch verhindern, dass durch eine eventuell sonst tagsüber erfolgende DSL-Zwangstrennung eine kurzzeitige Betriebsunterbrechung erfolgt.
In diesem Zusammenhang: auch bei dem Tarif T-DSL Business mit fester IP-Adresse erfolgt alle 24 Stunden eine Zwangstrennung. Bei der sofort danach erfolgenden Wieder-Einwahl wird lediglich nur wieder die gleiche IP-Adresse zugewiesen!

Alternativ dazu gibt es auch die Möglichkeit, einen zeitgesteuerten Reboot der gesamten Firewall durchzuführen – zum Beispiel einmal pro Woche. Dies ist interessant, weil dadurch regelmäßig wieder ein sauberer Ausgangszustand hergestellt wird und eventuelle Memory Leaks nicht dazu führen, dass die Firebox nach sehr langen Laufzeiten ggfs. instabil wird. Dieses Feature befindet sich unter Setup > Global Settings:

Version 11.1 Download und Update-Tipps

3 Comments

Am 13.11.2009 wurde die Version 11.1 freigeschaltet. Die Release Notes weisen auf die breite Unterstützung von Windows 7 für die Komponenten des WatchGuard System Manager (WSM) und der VPN-Clients für mobile User hin. Neu ist jetzt auch die Unterstützung von 64-Bit-Betriebssystemen für den Betrieb von Server Services. Hier ein Screenshot der aktuellen Unterstützungstabelle (aus den Release Notes, betrifft Windows XP 32-bit, Windows XP 64-bit, Vista 32-bit, Vista 64-bit, Windows 7 32-bit, Windows 7 64-bit, Mac OS X v10.5 (Leopard) und Microsoft Windows Server 2003. Hier fehlt leider eine konkrete Aussage über die 64-bit Version. Windows Server 2008 wird in der Tabelle leider überhaupt nicht erwähnt):

Bevor Sie das Update durchführen, lesen Sie bitte aufmerksam die Release Notes. Es kommt wirklich darauf an, welche Softwareversion aktuell auf Ihrer WatchGuard Firebox läuft. Unter Umständen muss ein bestimmter Upgrade-Pfad eingehalten werden. Beispiele:

Firebox X Edge

  • Wenn Sie aktuell 11.0 oder 11.0.1 auf Ihrer Firebox X Edge verwenden, müssen Sie die X Edge zunächst auf 11.0.2 updaten, bevor Sie auf 11.1 gehen. Dies gilt nicht für die X Core oder X Peak Geräteserien.

  • Wenn Sie aktuell 10.2.8 oder niedriger auf Ihrer Firebox X Edge verwenden, müssen Sie zunächst auf 10.2.9 (oder höher) updaten, bevor Sie dann direkt auf 11.1 upgraden können.

  • Wenn sich Ihre Firebox X Edge mit 10.x unter “centralized management” eines WatchGuard Management Servers befindet, können Sie das Update auf 11.1 nicht über die Funktion “Scheduled Firmware Updates” des Management Servers vornehmen, sondern müssen diesen Schritt “standalone” durchführen!

  • Nach dem Update auf 11.1 müssen Sie ggfs. die Konfiguration der Mobile User erneut aktivieren. Dies betrifft Mobile VPN mit IPSec, SSL-VPN und PPTP.

  • Unter 10.x gab es nur ein “Web-Kennwort” für den Administrator. Unter 11.x gibt es für die Administration standardmäßig zwei User: admin (Default-Kennwort “readwrite”) und status (Default-Kennwort “readonly”). Wenn unter 11.x Änderungen an der Konfiguration vorgenommen werden sollen, muss die Anmeldung mit dem User “admin” erfolgen.

  • Wenn Sie sich über einen Browser auf das neue Web-Interface verbinden wollen (https://[IP-der-Firebox]:8080) (Port 8080), muss der Browser “Flash” unterstützen. Wenn nicht, müssen Sie Flash installieren. Hierzu brauchen Sie auf dem PC ggfs. Administrator-Rechte.

  • Wenn Sie das Software-Update auf 11.x durchführen, indem Sie die Datei “utm_edge.sysa-dl” über das Webinterface hochladen, wird Ihre X Edge im Zuge des Updates auf Factory Default zurückgesetzt. Erzeugen Sie VORHER über Administration > Backup ein Backup Ihrer Konfigurationsdatei. Ich empfehle außerdem über Administration > View Configuration den im Hauptfenster angezeigten Text mit Cut&Paste in eine Textdatei wegzuspeichern!

  • Ich rate davon ab, ein Update direkt über das Internet vorzunehmen. Ich empfehle, eine Möglichkeit zu schaffen, sich remote auf einen PC im entfernten Netzwerk hinter der X Edge aufschalten zu können (incoming RDP, Teamviewer, PCvisit) – und das eigentliche Update quasi “lokal” von diesem PC aus durchzuführen.

Firebox X Core, X Peak, XTM1050

  • Um eine Firebox X Core oder X Peak auf 11.1 upzudaten, muss sich diese zunächst auf einer Version 10.2.x befinden.