Tag Archives: WSM

WSMMGR Lizenznummer derzeit nur per Support Incident

Comment

Auch mehr als zwei Monate nach dem Umbau der WatchGuard-Webseite gibt es noch keine Möglichkeit, die Lizenznummer für den “WatchGuard System Manager” (bzw. besser gesagt: die “Management Server” Komponente, vgl. auch https://www.boc.de/watchguard-info-portal/watchguard-system-manager-vs-watchguard-management-server-2/) selbständig aus seinem LiveSecurity Account auzulesen wie das bis Anfang Juli möglich war.
Wer aktuell seine VPNMGR, WSMMGR und/oder WSMUPGRADE Lizenznummer(n) braucht und nicht bereits irgendwo dokumentiert hat, muss leider bei WatchGuard einen Support Incident aufmachen (per Web oder telefonisch) – und sich die entsprechenden Lizenznummer(n) von den WatchGuard-Kollegen händisch auslesen und übermitteln lassen…

WatchGuard System Manager vs. WatchGuard Management Server

Comment

Begriffsbestimmung “WatchGuard System Manager”: Dieser wird auch im internen WatchGuard-Sprachgebrauch etwas uneindeutig verwendet.

Zum einen taucht er auf bei den Software Downloads und steht dort für die Software-Komponenten, die für die Installation auf einem Windows-basierten “WatchGuard Management Computer” gedacht sind. Der Dateiname für die aktuelle Version 11.4.2 lautet z.B.: WSM11_4_2s.exe (s steht hierbei für Strong Encryption) oder WSM11_4_2b.exe (b für Base Encryption – wenn z.B. beim Anlegen Ihres WatchGuard Accounts etwas schief gelaufen ist und Sie versehentlich in einem Land angesiedelt wurden, das unter US-Export-Beschränkungen steht 😉 Einen solchen Fehler sollten Sie schleunigst über einen Support Incident bei WatchGuard beheben lassen…)

Zum anderen wird der Begriff WatchGuard System Manager auch etwas irreführend für den Server Service “WatchGuard Management Server” verwendet. Das ist der Nachfolger des früheren “VPN Manager”, also die Möglichkeit, mehrere WatchGuard Fireboxen zentral zu verwalten und Branch Office VPN Tunnel zwischen den angeschlossenen Standorten per Mausklick einzurichten… Der “WatchGuard Management Server” ist ein optionales Kaufprodukt, das in 5-er Schritten (auch 25, 50, 100) zusätzlich erworben werden kann (taucht in den Preislisten lustigerweise auch wieder als “WatchGuard System Manager” auf…). Wenn Sie mindestens eine X750e oder eine XTM 505 in Ihrem Account haben, hat WatchGuard Ihnen bereits kostenfrei eine Lizenz für 4 Standorte bereitgestellt. Diese finden Sie bei Ihren “Activated Products”: Die Lizenznummern beginnen mit WSMMGR-1-xxx, WSMMGR-4-xxx, WSMUPGRADE-5-xxx o.ä. Nun ja, zumindest fanden Sie dort die Lizenznummern, bevor WatchGuard am 02.07.2011 das Customer Portal umgestellt hat… 😉 Sie werden irgendwann dort auch einmal wieder erscheinen. Vorher hilft nur ein Support Call, mit der Bitte, die entsprechende(n) Lizenznummer(n) telefonisch oder per E-Mail oder im Support Incident bekannt zu geben…

Hinweis: es kann immer nur eine WSMMGR- (Basislizenz) verwendet werden. Die Anzahl der lizensierten Standorte lässt sich dann nur durch WSMUPGRADE- (Erweiterungslizenzen) erhöhen.

Den Installer WSM11_4_2s.exe können Sie auch ohne diese Lizenznummer(n) vollständig durchklicken und je nach Bedarf sowohl die Client Komponenten als auch die Server Services “Management Server”, “WebBlocker Server”, “Logging Server”, “Quarantine Server” und “Report Server” erfolgreich installieren.

Wenn Sie jedoch anschließend die Server Services über das WatchGuard Server Center konfigurieren (und bei der Installation den “Management Server” angeklickt haben), werden Sie zur Eingabe der Lizenznummer(n) aufgefordert. Dies können Sie zwar überspringen, jedoch wird der Management Server erst dann funktionstüchtig sein, wenn Sie die Lizenznummer(n) nachträglich über das WatchGuard Server Center eingetragen haben.

Hinweis: Wenn Sie überhaupt nur eine einzelne WatchGuard Firebox besitzen, bringt Ihnen der Management Server auch gar nichts. Sie sollten dann beim Durchklicken des WSM11_4_2s.exe Installers das Häkchen beim Management Server einfach weg lassen.

Verwirrt? Na ja, kommt wie gesagt auch in den besten Kreisen vor… 🙂

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:


Diagnostic Tasks / Extended Ping / TCP Dump

1 Comment

Eine relativ unbekannte Funktion des Firebox System Managers sind die Diagnostic Tasks, die im Traffic Monitor per Rechtsklick mit der Maus erreicht werden können:

Eine Funktion ist Extended Ping, mit dem z.B. pings von der Firewall selbst aus gestartet werden können – und zwar auch unter Angabe des tatsächlich zu verwendenden Interfaces! Das kann gerade im Multi-WAN Umfeld interessant sein, wenn geprüft werden muss, ob ein bestimmter Ziel-Host auch genau über das angegebene Interface erreichbar ist (Problematik vgl. http://de.watchguard-blog.com/2011/08/multi-wan-und-policy-based-routing.html). Ein weiterer Anwendungsfall kommt aus dem Umfeld Dynamic Routing, wenn geprüft werden muss, ob das Routing eben auch auf den alternativen Wegen/Interfaces möglich ist. Die Advanced Options werden erst angezeigt, wenn das entsprechende Häkchen gesetzt ist. Im u.g. Screenshot wird die Ziel-IP 10.10.10.200 direkt von der Quell-IP 192.168.1.1 (Firebox Interface) angepingt:

Mittels TCP Dump lässt sich z.B. rudimentär mit verfolgen, welche Datenpakete auf welchem Interface transportiert werden – auch ohne dass sie zwingend im Traffic Monitor angezeigt werden:

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

18 Comments

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

2 Comments

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]

Installations-Problem bei WSM 11.3.2

Comment

Mir ist mittlerweile in ein paar Update-Installationen des WatchGuard System Manager (WSM) 11.3.2 aufgefallen, dass der Installer mit einer Fehlermeldung an ein paar Stellen hängengeblieben ist, die etwas mit den Dateien C:ProgrammeGemeinsame DateienWatchGuardwsm11libnlsen_US logging_res.loc und C:ProgrammeWatchGuardwsm11postgresqllib pgevent.dll zu tun hatten. Wenn die Dateien im Hintergrund z.B. im Windows Explorer umbenannt oder gelöscht werden, kann der Installer anschließend fortgesetzt werden…

Fireware XTM: Öffentliches Zertifikat für Anmeldeseite (Port 4100 tcp) verwenden

2 Comments

Wenn auf der WatchGuard Firebox oder WatchGuard XTM mit User Authentication gearbeitet wird – also Firewall-Regeln verwendet werden, die auf User-Basis greifen und nicht auf Maschinen-Basis – kommt häufig die Anmeldeseite der Firewall ins Spiel, die über
https://[IP-der-Firebox]:4100
aufgerufen wird. Die Anmeldeseite verwendet SSL-Verschlüsselung. Hierfür wird standardmäßig ein von WatchGuard selbst generiertes Zertifikat verwendet, das aber nicht von einer öffentlichen Zertifizierungsstelle rückbestätigt ist, weswegen beim Aufruf die allseits bekannte Warnmeldung des Browsers erscheint. Folgende Zertifikate sind ab Werk auf einer WatchGuard Appliance unter Fireware XTM 11.3.x vorhanden:


Das SSL Zertifikat von WatchGuard kann durch ein offizielles, von einer allgemein bekannten Zertifizierungsstelle rückbestätigtes SSL Zertifikat ersetzt werden. Hier reicht schon ein einfaches Zertifikat z.B. von RapidSSL aus, das bereits für 10,95 USD pro Jahr erhältlich ist. Alternativ kann (mit den bekannten Einschränkungen) auch ein von einer firmeninternen, privaten Zertifizierungsstelle erstelltes Zertifikat verwendet werden. Es empfiehlt sich, das Zertifikat für einen griffigen Hostname ausstellen zu lassen (firewall.kundenname.de, watchguard.kundenname.de, fw.kundenname.de etc.) und diesen über DNS korrekt bekannt zu machen. Zur allgemeinen Vorgehensweise:
WatchGuard System Manager (WSM) > Connect to Firebox > Firebox System Manager > View > Certificates > Create Request.
Der abschließend erzeugte CSR (Certificate Signing Request) wird an die Zertifizierungsstelle geschickt, für die man sich entschieden hat. Wenn das von dort ausgestellte Zertifikat vorliegt, kann es über “Import Certificate / CRL” auf die Firebox importiert werden. Wenn das Root-Zertifikat der CA nicht in der Liste der defaultmäßig enthaltenen CA Certificates enthalten ist (http://www.watchguard.com/help/docs/wsm/11/en-US/Content/en-US/certificates/cert_auto_trusted_list_c.html), muss es VOR dem Import des eigentlichen Zertifikats auf die gleiche Weise importiert werden, da sonst ein Fehler generiert wird: “Error: Error occurred while performing ‘import certificate’: certificate add error msg=”Failed to import a certificate!! 6_982: certificate validation fail” add certificate”. Das Root-CA Zertifikat von RapidSSL findet sich übrigens hier: http://www.geotrust.com/resources/root_certificates/certificates/Equifax_Secure_Certificate_Authority.cer. Wählen Sie für den Import jeweils die Option “IPSec, Web Server, Other”. Der erfolgreiche Import wird angezeigt:

Nun ist/sind die offiziellen Zertifikat(e) zwar schon auf der Firebox vorhanden, müssen aber noch für den Einsatz auf der Authentication Webpage der Firebox ausgewählt werden:
Policy Manager > Setup > Authentication > Web Server Certificate… > Third Party Certificate auswählen > OK > Save to Firebox.
Abschließend muss die Firebox einmal durchgebootet werden, damit diese Änderung auch tatsächlich aktiv wird:


Command Line Interface (CLI) auf Port 4118 tcp

1 Comment

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.

X Core und Peak out-of-the-box auf 11.3.1 updaten

1 Comment

WatchGuard X Core und X Peak e-series Modelle werden auch heute noch ab Werk mit der Software-Version 10.2 ausgeliefert. Ich führe derzeit folgende Schritte aus, wenn ich die Produkte out-of-the-box auf die aktuelle Version Fireware XTM 11.3.1 updaten möchte (Voraussetzung: Dual-Install eines WSM 10.2.x und WSM 11.3.1 auf dem Installations-PC vorhanden, feste IP de PC z.B. 10.0.1.100/24, verbunden mit eth1 der Firebox):

  • Registrierung der Firebox im Live Security Account auf der WatchGuard Website (vorab).
  • Feature Key (Lizenzdatei) herunterladen und in einer Textdatei speichern (vorab).
  • Starten der Firebox in den Recovery Mode (Up-Arrow-Button gedrückt).
  • Ausführen des “Quick Setup Wizard” der WSM 10.2.x Installation und Befüllen mit Dummy-Werten (IP-Adresse des Trusted Interface jedoch nach wie vor auf 10.0.1.1/24 setzen, Feature Key importieren).
  • Nach dem Reboot der Firebox WSM 11.3.1 starten und “Connect to Device” (10.0.1.1).
  • Policy Manager der 11.3.1 starten
  • File > Upgrade; Configuration Passphrase eingeben und aktuelle utm_core_peak.sysa-dl auswählen (11.3.1); Meldungen durchbestätigen, kein Backup-Image speichern.

Ich habe festgestellt, dass ein direkter Update-Versuch einer Factory Default 10.2 Firebox über den “Quick Setup Wizard” des WSM 11.3.1 scheitert, weil der Installer nach ca. 2-3 Minuten an folgender Stelle hängenbleibt:

Danach geht es auch nach 10-15 Minuten nicht weiter und der Quick Setup Wizard 11.3.1 muss mit einer Fehlermeldung abgebrochen werden. Zum Erfolg führte dann in der Regel das weiter oben beschriebene Verfahren in einer Dual-Install-Umgebung.