Tag Archives: Administration

Downgrade von Version 11.4.1 auf 11.3.2

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

Trade-Up / Migration von X Core e-series X550e, X750e, X1250e auf XTM 5

Viele Kunden steigen derzeit von einer WatchGuard X Core e-series X550e, X750e, X1250e auf ein entsprechendes Nachfolge-Modell XTM 505, XTM 510, XTM 520 und XTM 530 um (respektive von X Peak e-series auf XTM8). Fast immer taucht die Frage auf, ob die bestehende Konfiguration des “alten” Geräts auf das “neue” Gerät übertragen werden kann. Ja, sie kann. Es gilt aber ein paar kleine Hürden zu überwinden.

Zunächst muss natürlich die neue Box über die WatchGuard Website registriert und der neue Feature Key (Lizenzdatei) heruntergeladen werden. Auf dem Konfigurations-PC/Notebook haben Sie den aktuellen WSM 11.4.2 und die entsprechende Fireware XTM 11.4.2 für Ihre Geräte-Familie installiert, und auch das Adobe Flash Plugin für Ihren Browser ist vorhanden. Über https://10.0.1.1:8080 melden Sie sich mit dem User “admin” und dem Factory Default Kennwort “readwrite” an. Sie klicken den Setup Wizard mit den Default-Werten durch, importieren dabei auch den Feature Key und vergeben am Schluss Ihre eigenen Firewall-Kennwörter. Nach der erneuten Anmeldung mit Ihrem eigenen “admin”-Kennwort installieren Sie über System > Upgrade OS die neueste Fireware XTM 11.4.2 auf der Box, die daraufhin einmal durchbooten wird. Auf Ihrem Konfigurations-PC/Notebook starten Sie dann den WSM 11.4.2 und machen ein “Connect to Device” zu Ihrer neuen XTM-Box. Anschließend öffnen Sie den Policy Manager, der Ihnen die praktisch “leere” XML-Konfigurationsdatei der neuen XTM-Box anzeigt.

So weit, so gut. Erst jetzt wird es interessant:

Im Policy Manager laden Sie über File > Open > Configuration File die letzte XML-Konfigurationsdatei Ihrer “alten” WatchGuard. Auf die Frage “Do you want to save this new configuration to a file?” antworten Sie mit NEIN.

Sie sehen daraufhin die Konfigurationsdatei Ihrer “alten” WatchGuard. Falls Sie bisher eine X750e/X1250e im Einsatz hatten, bei der das Interface ganz rechts außen (eth7) im Einsatz war, sollten Sie sich die Network > Configuration Einstellungen für dieses Interface auf Papier notieren und prüfen, ob das Interface irgendwo namentlich in Firewall-Regel(n) auftaucht und auch diese entsprechend dokumentieren! Über Setup > System > Model wählen Sie Ihr neues Hardware-Modell aus. Es folgt eine Warnmeldung, die auf die veränderte Anzahl der Ethernet-Schnittstellen hinweist (eine XTM5 hat jetzt 7 Interfaces, eine alte X550e hatte 4, eine X750e/X1250e 8 Interfaces). Anschließend müssen Sie noch bei Setup > Feature Keys den Feature Key der alten Box removen und den Feature Key der neuen Box importieren. Beachten Sie bitte, dass im Policy Manager ganz unten rechts noch der Hinweis steht, dass es sich um eine Konfigurationsdatei des Typs “Fireware XTM v11.0-v11.3.x” handelt:

Auch bis hierhin alles planmäßig.

Anschließend starten Sie ein “Save to Firebox”. Die eventuelle Warnmeldung “The specified IP address does not match any of the interfaces specified in this config file. Are you sure you want to save to this Firebox?” (…ist klar, weil Ihre alte Konfigurationsdatei höchstwahrscheinlich eben nicht die 10.0.1.1 für eth1 enthält…) bestätigen Sie mit JA.

und erhalten dann eine zweite Warnmeldung: “The configuration file must be upgraded before it can be saved to the v11.4.2 device. Would you like to upgrade the configuration now?”. Auch die bestätigen Sie mit JA.

Anschließend folgt überraschend: “Error communicating with Firebox [IP]. INTERNAL_ERROR: The configuration is invalid, missing application action object”, die Sie nur mit OK bestätigen können.

=> Brechen Sie den Vorgang dann mit CANCEL ab und schließen Sie den Policy Manager.

Öffnen Sie den Policy Manager erneut, und öffnen Sie über File > Open > Configuration File die NEUESTE Version der Konfigurationsdatei, die im Zuge des vorigen “Save to Firebox” gespeichert wurde (ist nur wenige Minuten alt…). Bestätigen/ignorieren Sie die weiter oben bereits beschriebenen Warnmeldungen und starten Sie dann erneut den Vorgang “Save to Firebox”. Beachten Sie in diesem Zusammenhang, dass nun im Policy Manager ganz unten rechts für die Konfigurationsdatei der Typ “Fireware XTM v11.4.2” angezeigt wird:

=> Jetzt – beim zweiten Mal – sollte das Hochladen der Konfigurationsdatei funktionieren:


Danach sollten Sie die neue Box dann auch über die “alten” TCP/IP-Einstellungen auf den entsprechenden Interfaces ansprechen können! [Hinweis: die Firewall-Kennwörter sind nicht Bestandteil der Konfigurationsdatei, sondern hardwarespezifisch! D.h. die neue Firebox hat nicht automatisch die Kennwörter der alten Firebox, sondern die, die Sie ihr über den Setup Wizard verpasst haben!]

WSM und Fireware XTM 11.4.2

Im Software-Download-Bereich der WatchGuard Website stehen seit gestern die neuesten Verisonen WSM und Fireware XTM 11.4.2 für die Geräteserien XTM2, XTM5, XTM8 und XTM1050 bereit. WatchGuard hat den Download- und andere Customer-Care-Bereiche vor zwei Wochen ausgelagert, daher sieht die User-Anmeldeseite mittlerweile anders aus – und auch die dahinter liegenden Inhalte werden “anders präsentiert”, verstecken sich zum Teil oder sind (noch) gar nicht auffindbar… Das ändert/bessert sich hoffentlich in den nächsten Tagen/Wochen/xxx… 🙂

Die Liste der Resolved Issues der Version 11.4.2 liest sich so:

General

  • This release resolves an issue that caused the XTM device to lock up when configured with a combination of proxy policies, subscription services, and FireCluster. [61091]
  • A kernel memory leak and subsequent kernel crash that occured when the XTM device received many packets with MSS =0 has been resolved. [59953]
  • An issue that caused a kernel crash and complete XTM device lock up has been resolved. [59031]
  • This release resolves an issue that caused excessive logging from lighthttpd. [60508]
  • The “message” field from a WatchGuard log message now appears in a syslog message for the same traffic. [60045]
  • The ip_dst_cache cleanup timer has been improved to make sure that the ip_dst_cache table does not become full and cause packets to be dropped. [61558]
  • Dynamic DNS updates now work correctly when the XTM device is configured with a zero route branch office VPN tunnel. [56166]
  • A memory leak in the networkd process has been resolved. [61905]

Networking

  • Blocked sites that are added by IPS are now correctly removed from the Blocked Sites list when the expiration time configured to block them is reached. [60631]
  • An XTM device configured to use the server load balancing feature no longer allows connections to servers that are non-responsive. [60292]
  • Firewall policies are now applied to traffic that passs through two interfaces configured for the same VLAN (VLAN Bridge). [61352]
  • When you enable IPS on a policy configured for VLAN Bridged interfaces, it no longer causes traffic to fail though the policy. [61585]
  • This release resolves an issue that triggered MAC address flapping on Cisco switches when using an active/passive FireCluster. [60619]

Proxies

  • An issue that caused some web pages to not load correctly when using Internet Explorer v8.0 has been resolved. [58259]
  • Several issues that caused some downloads to fail through the HTTP proxy when using Gateway AV has been resolved. [61291] [60654]
  • The XTM device no longer fails to send quarantined emails to the Quarantine Server. [60940]
  • A Custom SOAP web application that required 255 or more requests through the HTTP proxy now works correctly. [58097]

FireCluster

  • This release resolves an issue that caused the master device in a FireCluster to become idle after a Force Failover command is issued. [60217]
  • The Backup Master can now send log messages to a WatchGuard Log Server that is not on the same subnet as the management IP addresses. [61109]
  • A rule to always allow management traffic between the FireCluster management interfaces is now added automatically when you configure FireCluster. This new rule makes sure that management functions to both devices in a cluster are not blocked by policy misconfiguration. [56062]
  • This release improves the performance of FSM when connected to an active/passive FireCluster. [61886]
  • The FSM Status Report tab now correctly displays data for the backup master device in a FireCluster. [60454]

Mobile VPN with SSL

  • This release adds support for multiple Mobile VPN with SSL policies for different users/groups from Policy Manager. [60741]
  • The Mobile VPN with SSL client for Windows now connects correctly to the IP address specified by the user in the connection settings instead of always using the IP address in the Mobile VPN with SSL configuration created by the XTM device. [60082]

Mobile VPN with IPSec

  • The Mobile VPN Shrew Soft client and the Mobile VPN with IPSec client now work with certificates generated by the WatchGuard Management Server. [61380, 61060]

Mobile VPN with PPTP

  • PPTP authentication no longer fails when there are a large number of previous PPTP connections that were not terminated correctly. [61117]

Branch Office VPN

  • You can now use Branch Office VPN with an External Wireless interface. [36232]
  • Ping traffic through a Branch Office VPN tunnel is no longer given low processing priority to improve latency for ping traffic through VPN tunnels. [60427]
  • We have increased the default buffer size for the xfrm_dst_cache on the XTM device to prevent a condition where Branch Office VPN traffic stops when there are many TCP connections through the tunnel. [58141]
  • Tunnels no longer fail with a “no proposal chosen” error when you use a dynamic external interface for the tunnel Gateway. This problem occurred when the gateway name for each gateway was not unique enough, which caused the wrong gateway to be selected for Phase 2. [60594]
  • This release resolved an issue that caused VoIP traffic with the ToS bit set to fail to pass through a Branch Office VPN tunnel. [59479]

Authentication

  • The Terminal Services Agent no longer uses 100% of the CPU when the first user starts an RDP session. [60111]
  • Terminal Server/Citrix users can now use the Interbase SQL client to get access to a remote server. [60847]
  • A Terminal Services Agent installation problem that occurred on some servers has been resolved. [60848]
  • Radius Authentication for PPTP users now works correctly on XTM 2 Series devices. [61164, 61151]
  • The deny message shown for authentication denies that occur because only one authentication is allowed for the same user account has been improved. [59214]
  • We have improved performance when many users authenticate to the XTM device using Firebox-DB authentication. [61760]

Management

  • Firewall policies can now be applied to intra-VLAN traffic. [61382]
  • The Management Server can now correctly apply updates to remote devices using dynamic external interfaces. [61141]
  • When you upgrade from Fireware XTM software v11.3 or earlier to v11.4.x, IPS is no longer disabled for policies that previously had IPS enabled. [61108]
  • Configuration saves now take effect without the need to reboot on XTM 5 Series appliances running v11.4 or v11.4.1. [60074]
  • This release resolves an issue that caused some Management Server backups created in v11.4 to fail to restore. [61075]

Certificates

  • A problem that caused custom web server certificates to not generate correctly has been resolved. [61421]
  • Management connections no longer fail because a web server certificate has many DNS names. [56441]

WatchGuard Log Server

  • LogViewer searches no longer fail to find a match after a new installation of the WatchGuard Log Server. [60411]
  • The WatchGuard Server Center no longer shows an abnormally high maximum database size immediately after a change is made to lower the database size. [61378]

Firebox System Manager (FSM)

  • FSM connections no longer fail if there are three or more FSM instances connected to the same XTM device. [61728]
  • Traffic Monitor no longer stops displaying log messages after a PPTP connection. [61227]

Verlust der Konfigurationsdatei beim Update von v10 auf v11.3.4

Mir ist es in den letzten Wochen selbst zweimal passiert, und auch ein Kunde hat übereinstimmend berichtet, dass beim Software-Update einer bestehenden X Core e-series (X550e, X750e, X1250e) von Softwareversion 10.2.x direkt auf Version 11.3.4 die Firebox anschließend eine “leere” Konfigurationsdatei hatte – genau so wie sie aus dem Setup Wizard mit durchbestätigten Default-Einstellungen heraus kommen würde.
Das Dumme dabei ist, dass sich auch die TCP/IP-Einstellungen der Interfaces auf Default zurückgesetzt haben: eth0=10.0.0.1/24, eth1=10.0.1.1/24 usw.!! Dadurch war die Firebox natürlich nicht mehr direkt “ansprechbar”, weder vom Trusted Network noch remote über das Internet!
Zum Glück war bisher in allen meinen Fällen kompetentes IT-Personal vor Ort zur Stelle, das nach telefonischer Anleitung den lokalen Zugriff und den Remote-Zugriff wieder herstellen konnte:

  • Auf eth1 lag 10.0.1.1/24, also musste zunächst irgendwie dafür gesorgt werden, dass ein PC/Notebook mit einer anderen fest konfigurierten IP-Adresse aus dem Subnetz 10.0.1.0/24 auf eth1 zugreifen kann.
  • Auf dem PC/Notebook muss bereits ein funktionsfähiges Adobe Flash Plugin vorhanden sein!
  • https://10.0.1.1:8080 ruft den WatchGuard Setup Wizard auf.
  • Die Passwörter waren jedoch NICHT die Factory Defaults readonly bzw. readwrite, sondern immer noch die bisherigen tatsächlichen Kennwörter der Firebox! (Auch der Feature Key war auf dem Gerät noch vorhanden und aktiv!)
  • Durchklicken des Setup Wizard, wobei jedoch die TCP/IP-Einstellungen für das TRUSTED Interface (und bei Remote Administration die Einstellungen für das EXTERNAL Interface) passend wiederhergestellt werden müssen!! Diese Angaben sollten also bei Durchführung eines Software-Updates grundsätzlich immer irgendwie “schwarz auf weiß” zugänglich sein… 🙂
  • Bei Remote Administration muss noch die “WatchGuard” Firewall Policy kurzfristig so erweitert werden, dass der Alias “Any-External” im From-Feld zu stehen kommt.
  • Nun kann die letzte existierende XML-Konfigurationsdatei wieder auf die Firebox hochgeladen werden – und alles sollte wie vorher sein, nur dass jetzt eben die 11-er Software darunter liegt…

Dieses Verhalten ist bei WatchGuard (noch) nicht als Problem bekannt, aber man weiß ja nie… Drei unabhängige Fälle lassen ja schon vermuten, dass da womöglich momentan ein Bug sein Unwesen treibt… Kleiner Tipp: eventuell hat das Problem ja auch etwas mit den berühmten Sonderzeichen zu tun. Sollten Sie also Firewall-Kennwörter verwenden, die nicht ausschliesslich aus A-Z, a-z und 0-9 bestehen, sollten Sie diese eventuell VOR dem Software-Update kurzfristig entsprechend ändern… 🙂

Fireware XTM: Reihenfolge der Anmelde-Domänen auf der Anmeldeseite

In Verbindung mit User Authentication wird meist die manuelle Anmeldeseite der WatchGuard Firewall Appliance verwendet:
https://[IP-der-Firebox]:4100.
Die Authentication kann entweder gegenüber der lokalen Benutzer-Datenbank der Firebox selbst erfolgen (Firebox-DB), alternativ gegenüber externen Benutzer-Datenbanken unter Verwendung von RADIUS, SecureID/VASCO, LDAP oder Active Directory. Selbst wenn in der Firebox-DB gar keine lokalen User vorhanden sind, weil z.B. generell mit Active Directory gearbeitet wird, sieht die Anmeldeseite BEIM ERSTEN AUFRUF erst einmal so aus, d.h. standardmäßig wird “Firebox-DB” als Anmelde-Domäne angezeigt:

Die User müssen also in diesem Fall nicht nur geschult werden, dort ihren Windows-Benutzernamen und ihr Windows-Kennwort einzugeben, sondern auch noch in dem Pulldown-Menü darunter MANUELL von “Firebox-DB” auf “Active Directory” umzustellen. Das gestaltet sich manchmal etwas schwierig……… Besser wäre es natürlich, wenn die Anmeldeseite auch schon beim ersten Aufruf standardmäßig “Active Directory” als Anmelde-Domäne zeigen würde:

Die Reihenfolge der Anmelde-Domänen in dem Pulldown-Menü lässt sich durch einen manuellen Eingriff in die XML-Konfigurationsdatei beinflussen.
Erzeugen Sie als Backup zunächst eine Kopie Ihrer aktuellen XML-Konfigurationsdatei. Öffnen Sie die XML-Datei dann mit einem entsprechenden Editor. WordPad reicht schon. Suchen Sie nach dem Tag “auth-domain-list”. Sie werden erkennen, dass dort die von Ihnen verwendeten Anmelde-Domänen als “auth-domain” aufgelistet sind. An erster Stelle werden Sie “Firebox-DB” finden. Sie können nun die Anzeige-Reihenfolge festlegen, indem sie die jeweils vollständigen “auth-domain”-Tags per Cut&Paste in der gewünschten Reihenfolge anordnen. Speichern Sie die geänderte XML-Datei, öffnen Sie diese über den Policy Manager und laden Sie sie per “Save to Firebox” auf die WatchGuard hoch.
ACHTUNG: Wie immer ist in einem solchen Fall natürlich sehr sorgfältiges Vorgehen angesagt!!!

Command Line Interface (CLI) auf Port 4118 tcp

WatchGuard Firebox e-series und XTM Systeme mit Software 10.x oder 11.x bieten auch die Möglichkeit der Administration und Programmierung im Kommandozeilenmodus (CLI). Ausnahme: X Edge e-series mit v10.x. Hierzu läuft auf der WatchGuard ein SSH-Daemon, der auf Port 4118 tcp hört. Dieser Port ist Bestandteil der standardmäßig im Regelwerk enthaltenen Firewall-Regel “WatchGuard”, die ebenfalls standardmäßig den Zugriff auf die “Firebox” von “Any-Trusted” und “Any-Optional” ermöglicht. Das From-Feld dieser Regel kann natürlich auch so erweitert werden, dass der Zugriff über das Internet oder für mobile User möglich wird (Sicherheitsüberlegungen berücksichtigen!).
Das CLI kennt wie das WebUI zwei User: status und admin. Zu status gehört immer das lesende Kennwort der Firebox (status passphrase). Zu admin gehört immer das schreibende Kennwort der Firebox (configuration passphrase).
Wenn Sie nun über einen SSH-Client (z.B. PuTTY) eine SSH-Verbindung zu Port 4118 öffnen und sich als admin an der Firebox anmelden, können Sie dort zunächst durch die Eingabe eines Fragezeichens (?) eine Übersicht der verfügbaren Befehle anzeigen lassen:

Hier findet sich unter anderem auch der Befehl “reboot”, über den die Firebox durchgebootet werden kann. Gerade bei Fireboxen mit v10.x ist dieser Einstieg manchmal “der letzte Rettungsanker”, wenn durch Memory Leak Effekte der Hauptspeicher auf der Firebox zugelaufen ist und die Firebox in Folge den Daemon abgeschaltet hat, über den sich der WSM mit der Firebox verbindet…
Ebenfalls sehr hilfreich ist der CLI-Befehl “ping”, der es ermöglicht, pings direkt von der Firebox aus zu verschicken.
Theoretisch kann über das CLI auch eine weitgehende Administration des Gesamtsystems erfolgen, also auch Konfigurationsänderungen etc., jedoch kommt dies in der Praxis eher selten vor. WatchGuard bietet hierfür unter http://www.watchguard.com/help/documentation/xtm.asp eine umfangreiche PDF: die Command Line Interface Reference.

Logging Datenbank unter 11.3 hat jetzt feste Größe

Nach einem Auslandsprojekt und etwas Urlaub nun neuer Input: Wer sich gewundert hat, warum im WatchGuard Server Center 11.3 unter “Logging Server” nicht mehr die bisher üblichen Angaben zu finden sind, nach wie vielen Tagen die alten Daten gelöscht werden sollen bzw. nach Erreichen von wieviel Prozent der maximalen Datenbank-Größe eine Notification E-Mail an den Administrator zu senden ist, sei beruhigt: in der Version 11.3 ist die Angabe “Database Size” tatsächlich die Maximalgröße der Datenbank. Bei Erreichen von 95% dieser Größe werden ältere Daten automatisch gelöscht. Es gibt keine Notifications mehr. Wenn also aufgrund von Unternehmensrichtlinien eine entsprechende Anzahl von vorzuhaltenden Tagen verbindlich ist, müsste dies im Rahmen der Datenbankgröße und des anzuwendenden Backup-Konzepts aufeinander abgeglichen werden. Hier bietet sich das freie Tool “pgadmin” an, mit dem u.a. auch zeitgesteuerte Datenbank-Dumps geplant werden können.

Keine Sonderzeichen in Firewall-Kennwörtern!

Kleine Erinnerung (obwohl schon des öfteren thematisiert): Verwenden Sie an allen Stellen der XML-Konfigurationsdatei sowie in VPN Pre-Shared Keys und vor allem in der Status und der Configuration Passphrase der Firewall selbst ausschließlich ASCII-Zeichen des Zeichensatzes US-ASCII 7bit! Keine deutschen Umlaute äöü/ß, keine speziellen Sonderzeichen!
Ich musste heute eine X750e mit Fireware 10.2.11 “retten”, bei der der Kunde in der Configuration Passphrase ein €-Zeichen (EUR) verwendet hat. Effekt war, dass nur noch die Anmeldung mit der Status Passphrase möglich war, jedoch eben keine Änderungen mehr an der Konfigurationsdatei usw. Problemlösung war nur über Factory Reset und Restore/Aufspielen der letzten Konfigdatei möglich…

Probleme mit self-signed Zertifikaten beim Update auf 11.2

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…

Version 11.1 Download und Update-Tipps

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.