Tag Archives: WebUI

Korruptes Zertifikat entfernen

Vor ein paar Tagen hatte ich mit einer X750e (Softwareversion Fireware XTM 11.3.4) zu tun, die im Basic Managed Mode als Außenstelle an einem WatchGuard Management Server lief (Softwareversion WSM 11.5.3). Die BOVPN-Tunnel waren als Managed VPN Tunnels über den Management Server eingerichtet. Die BOVPN-Tunnel kamen nicht mehr hoch und die X750e ließ über WSM / Policy Manager auch keine Änderungen an der Konfiguration zu – auch dann nicht, wenn man mit einem lokalen WSM direkt mit der Box verbunden war. Fehlermeldung beim Schreiben einer Konfiguration: “An error occured while retrieving all certificates from the Firebox [IP]). Unable to send request to module”. Ein Neustart der Box brachte keine Änderung.

Die Fehlersuche zeigte Probleme mit den Zertifikaten auf der X750e. “View… Certificates” aus dem Firebox System Manager konnte die Zertifikate nicht anzeigen (leeres Feld und darüber eine leere Fehlermeldung).

Auch im CLI Modus brachte der Befehl “show certificates” nur eine Fehlermeldung. Der certd daemon lief auch nicht. Ich hatte einen ähnlichen Fall bereits vor ein paar Monaten. Damals waren auch Zertifikate kaputt, die Box ließ sich jedoch noch über WSM / Policy Manager administrieren. Damals konnte ich das Problem durch ein Software-Update auf eine neuere Fireware XTM Version beheben. Vermutlich hätte auch das Aufspielen der gleichen Version geholfen. Da jetzt aber WSM / Policy Manager nicht mehr funktionierten, habe ich dieses Mal über das Web-Interface gearbeitet (System > Upgrade OS) und auf diesem Weg die 11.3.4er sysa-dl Datei erneut hochgeladen. Nach dem Reboot war certd wieder da und die Zertifikate waren wieder sichtbar. Anschließend konnte die Box auch wieder an den zentralen Management Server angebunden werden, jedoch kamen die Managed VPN Tunnel immer noch nicht hoch. Als nächstes habe ich den zentralen WSM / Management Server näher untersucht. Beim Versuch, die Managed VPN Tunnel neu anzulegen, stürzte der WSM jedes Mal mit einer Fehlermeldung der AppMngr.exe ab. Ein Neustart des Dienstes half nicht, auch nicht der Reboot der kompletten Windows Server 2008 Maschine.

Als temporären Workaround wollte ich nun den BOVPN Tunnel zwischen der Außenstelle und dem zentralen System (ein XTM 810 Active/Passive Cluster mit Fireware XTM 11.5.3) manuell anlegen, damit die User zumindest erst einmal wieder arbeiten konnten. In der XML Konfigurationsdatei des zentralen XTM810 Clusters ist mir dann aufgefallen, dass dort noch die DVCP-basierte Gateway- und Tunnel-Definition der alten “Managed VPN” Verbindung angezeigt wurde, obwohl diese eigentlich gar nicht mehr vorhanden sein sollte. Durch ein Cluster Failover verschwanden diese Fragmente dann aus der zentralen Firewall-Konfiguration, woraufhin auch der WSM / Management Server nicht mehr abschmierte und schlussendlich der BOVPN Tunnel doch wieder regulär als “Managed VPN” Tunnel erfolgreich eingerichtet werden konnte…

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

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… 🙂

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.

Vorsicht bei “Deny” Firewall Rules auf der X Edge!

Durch die Migration einer Firebox X Edge von der Version 10 auf die neue Fireware XTM v11.x ändert sich unter anderem auch die Reihenfolge, in der die Firewallregeln ausgeführt werden. Unter Version 10 war es kein Problem, bei Firewall > Outgoing die nicht benötigten Services auf “Deny” (roter Hintergrund) zu setzen, solange z.B. die “Outgoing”-Regel selbst auf “Allow” (grüner Hintergrund) stand.

Bei Fireware XTM v11.x ist es anders. Dies zeigt dieser Supportfall: Kunde führt ein Update einer X Edge mit 10-er Software auf Fireware XTM v11.x durch. Das Update läuft erfolgreich durch. Anschließend ist plötzlich kein HTTP-Zugriff mehr auf das Internet möglich. Beim Versuch, auf das Webinterface der X Edge (neu, Port 8080) zuzugreifen, erscheint die Meldung, dass hierfür zunächst der Adobe Flash Player heruntergeladen und installiert werden müsse. Dumm gelaufen, HTTP funktioniert ja gerade eben nicht… Gut, wenn noch ein weiterer PC lokal vorhanden ist, auf dem schon Flash installiert ist und man von diesem PC aus auf das Webinterface der X Edge zugreifen kann – oder wenn vor der Migration eine Remote Access Regel für Port 8080 (Firewall > Incoming) angelegt wurde, die einem externen Supporter Zugang zu dem Gerät ermöglicht… 😉 Dieser konnte so die “Deny”-Regel für HTTP aus dem Regelwerk löschen, die nun “weiter oben” saß und dadurch den kompletten HTTP-Verkehr verhinderte.

Meine Empfehlung: Prüfen Sie vor der Migration einer X Edge von Version 10 auf Fireware XTM v11.x, ob es Firewallregeln gibt, die auf “Deny” stehen (roter Hintergrund). Wenn es hierfür keinen dringenden Grund gibt, sollten Sie diese Regeln auf “No Rule” setzen (grauer Hintergrund). Nach der Migration wird das Regelwerk wesentlich anschaulicher dargestellt und Sonderregelungen können hier viel einfacher eingebaut werden.

Fehler -10 bei Update mit edge_11_1.exe

Um eine WatchGuard Firebox X Edge mit 10-er Software auf die aktuelle Fireware XTM 11.1 upzudaten und dabei die bisherige Konfiguration beizubehalten, muss die X Edge zunächst auf 10.2.9 oder höher upgedatet werden. Anschließend wird der Install Wizard edge_11_1.exe ausgeführt, am besten von einem PC aus, der am Trusted oder Optional Interface angeschlossen ist (also “lokal”). Der Wizard fragt zunächst nach der IP-Adresse der X Edge und den bisherigen Zugangsdaten (Username/Password). Außerdem wird nach den “neuen” Firewall-Kennwörtern gefragt, die Sie vergeben wollen – die Status Passphrase (das “lesende Kennwort”) und die Configuration Passphrase (das “schreibende Kennwort”), so wie sie auch von den größeren Gerätefamilien X Core und X Peak in Verbindung mit dem WatchGuard System Manager (WSM) bekannt sind. Danach läuft der Wizard los. Wenn alles gut geht, bootet die X Edge nach ca. 5 Minuten und am Bildschirm erscheint eine Erfolgsmeldung.

In einer Installation bekam ich aber vorher eine Fehlermeldung angezeigt und das Update wurde abgebrochen. Auch ein erneuter Aufruf der edge_11_1.exe scheiterte mit der gleichen Fehlermeldung: “Error installing utm_edge.sysa-dl (error = -10)”.

Abhilfe schaffte hier ein Reboot der X Edge. Anschließend lief edge_11_1.exe erfolgreich durch. Offenbar braucht der Update Wizard auf der X Edge “Platz” zum Arbeiten, der eventuell im längerfristigen Dauerbetrieb von temporären Dateien o.ä. belegt wird. Ich empfehle also nun immer ein Reboot der X Edge, bevor der Update Wizard gestartet wird!

Bitte denken Sie daran, dass nach dem Update auf die 11-er Version das Webinterface jetzt auf Port 8080 liegt und nicht mehr auf Port 443. Sie müssen daher gerade bei Remote Administration auch diesen Port ggfs. von außen berücksichtigen – am besten BEVOR Sie das Update durchführen 🙂 Generell empfehle ich Besitzern einer X Edge jedoch, sich mit den neuen Möglichkeiten der Administration durch den WatchGuard System Manager (WSM) vertraut zu machen. Erst hiermit blüht Ihre X Edge zur vollen Leistungsfähigkeit auf!

Bugfixes in WatchGuard WSM und Fireware XTM 11.1

Die Versionen Fireware XTM v11.1 und WSM v11.1 beheben eine Reihe von Bugs und Known Issues früherer Versionen. Diese Aufstellung wurde den aktuellen Release Notes der Version 11.1 entnommen. Obwohl man aufgrund der Vielzahl eventuell auf den Gedanken kommen könnte, dass das Produkt sehr fehlerlastig ist (bzw. war), sehe ich diese offene Kommunikation hingegen sehr positiv. Die meisten anderen Hersteller geben kaum vergleichbare Informationen heraus, sondern werkeln eher im Hintergrund. Zudem zeigt sich, dass das Produkt “lebt” und intensiv weiterentwickelt wird. Auch schon in den Versionen 11.0.1 und 11.0.2 war das Produkt ausreichend stabil, auch wenn ich meinen Kunden anfangs eher zur Zurückhaltung geraten habe!

General

  • The WSM Quick Setup Wizard now allows you to enter a feature key that contains a model upgrade for Edge e-Series. [40405]
  • Fireware XTM v11.1 resolves a cross site scripting vulnerability found in the web server used with the authentication applet. [40332]
  • Fireware XTM v11.1 resolves a cross site scripting vulnerability found in the WatchGuard servers’ Apache HTTP server implementation. [40581]
  • The lighttpd version used by Fireware XTM has been upgraded to v1.4.22 to resolve several reported vulnerabilities. [38808]
  • The ISC DHCP server version has been upgraded to v4.1.0p1 to resolve several reported vulnerabilities. [40032]
  • HostWatch now shows VLAN traffic. [40401]
  • You can now right-click in Firebox System Manager > Traffic Monitor to add an IP address to the blocked sites list. [40488]
  • ServiceWatch now correctly displays bandwidth for auto-generated BOVPN policies created by the WatchGuard Management Server. [40364]

Authentication

  • The Authentication redirect feature now works when you use a wireless guest network on the Firebox X Edge e-Series. [40029]
  • This release resolves an issue that causes Active Directory authentication to fail with the following log message: user=”test1″ domain=TESTQAWIN2K30. [40786]

Proxies

  • You can now enable notification for Application Blocker. [40422]
  • Application Blocker has been enhanced to add support for Winny, a popular peer to peer application used in Japan. [35027]
  • You can now unlock a file with an “&” in the file name with the unlock.exe utility. [40718]
  • This release resolves several reported issues in which certain web applications did not work through the HTTP Proxy. [40293] [38121] [40392]
  • This release resolves an issue that caused FTP proxy traffic to stop after a multi-WAN failover. [37965]

Subscription Services

  • Subscription services now update when you use an internal HTTP proxy server. [40517]
  • WebBlocker override now works on Firebox X e-Series devices configured in Bridge Mode. [39283]
  • The Quarantine Server client now accepts firstname.lastname@domain.com email format. [39743]

Networking

  • You can now use either Policy Manager or the Web UI to add multicast addresses in a policy. [39947, 39948]
  • If you enable a network interface and change the Interface Name (Alias) at the same time you enable the interface, the interface now becomes active without the need for a reboot.[39815]
  • When you use multi-WAN, DNS servers with static IP addresses on WAN 1 are now used even when other external interfaces use DNS servers from an ISP through PPPoE or DHCP. [40322]
  • DHCP relay through a branch office VPN tunnel now works. [40844]
  • You can now change the MTU of an external interface configured with PPPoE. [40705]
  • The DHCP server now works when there are multiple VLANs in the configuration. [40556]
  • Server Load Balancing now works when the internal server IP addresses are on different subnets. [41041]
  • We have made enhancements to the Server Load Balancing server status detection mechanism. [40300] [40519]
  • The Server Load Balancing Stickiness function has been improved to maintain a sticky connection state until the idle timeout is reached. [40297]
  • Static MAC address binding now works when your device is configured in Bridge Mode. [40665]
  • This release resolves an issue that prevented some Windows computers from getting an IP address via DHCP when your device is configured in Drop-In Mode. [40184]
  • The Blocked Ports and Blocked Sites features now apply only to traffic on an external interface. [39918]

Multi-WAN

  • Several multi-WAN issues related to PPPoE and branch office and Mobile VPN have been resolved. [40007]
  • Multi-WAN now works when the source IP address for incoming traffic is on the same network subnet as one of the external interfaces of the Firebox. [41026]
  • This release resolves an issue that caused the external interfaces to become inactive when you used multi-WAN configured in Round-robin mode. [40357]

FireCluster

  • Firebox devices with a model upgrade in the feature key can now join a FireCluster. [39370]

Branch Office VPN

  • The choice of Any has been removed from the Tunnel Route Settings Local and Remote drop-down menu. The Web UI now shows “any (0.0.0.0/0)”. [40409]
  • This release resolves an issue that caused the IKED process to crash and all IPSec tunnels to fail. [40442]

Mobile VPN

  • The Windows SSL VPN client has been updated to support Windows 7 and Windows 64-bit operating systems. [39841]
  • This release resolves an issue that caused SSL VPN to fail to connect after an upgrade from v10.2.x to v11.0.x. When this problem occurred, the SSL VPN client logs showed: sslvpn State: initialization of prerequisites Debug. [40408]
  • This release resolves several reported vulnerabilities in the SSL VPN client for Mac. [40292]
  • Mobile VPN with PPTP and SSL now continue to work when the LiveSecurity subscription is expired in your Firebox feature key. [41045]
  • When you disconnect the Mobile VPN with SSL client from one Firebox and then connect to a different Firebox, the SSL VPN profile is now updated to show the new connection. [41052]
  • The Mobile VPN with IPSec v11.1 client supports Windows 7 (32-bit and 64-bit) and contains additional bug fixes.

Web UI

  • You can now export your device configuration with the Web UI. [35234]
  • The Web UI now prevents the use of custom SSL VPN ports that conflict with ports used by the Firebox. [39382]

Policy Manager

  • The Firebox no longer becomes unresponsive if you use more than 28 characters in a proxy policy name. [40679]
  • The alias “Firebox” is now treated the same as other aliases the Firebox determines policy precedence. [38891]

Management Server

  • When a Firebox is in Full Management Mode and you clear the Enable TCP Syn Checking check box, TCP Syn Checking is now correctly disabled. [40853]
  • When a Firebox is under centralized management, an update from the WatchGuard Management Server no longer overwrites any blocked sites configured manually on the Firebox. [40312]
  • You can now right-click on a device and add that device to a folder. [36077]
  • The ability to schedule a reboot time is now available from the Management Server. [38230]
  • You can now perform a mass update of managed devices to force all selected appliances to check for a configuration update. [36958]
  • The Management Server now sorts the IPSec-action-list and abs-ipsec-action-list for tunnels created by the Management Server. The IPSec actions for Manual BOVPN tunnels are left in the order sorted by the user. Manual tunnels are always placed at the top of the list, followed by the sorted list of the tunnels created by the Management Server.
  • For each firewall policy template in use, there is now a single firewall policy created in the appliance configuration. As an example, if you have three tunnels (to different endpoints) that all use the same firewall policy template, there is a single firewall policy with the attributes set in the template. If there are two firewall policy templates in use, then two firewall policies are created. [38877]

Report Server

  • If you use an IIS server to serve published reports, you no longer get an error about missing files. [39319]

Log Server

  • The performance of the LogViewer Search function has been improved in v11.1. To facilitate the performance improvements, a log database migration will occur when you upgrade from v11.0.x to v11.1. During the migration, all log messages generated for a particular device are not visible until the migration is finished. [38833]

Certificates

  • You can now import a CRL in DER format into Firebox System Manager. [36643]
  • This release resolves a memory leak that occurred when you used 3rd-party certificates on the Firebox and kept WatchGuard System Manager or Firebox System Manager connected. [41008]
  • WatchGuard System Manager and Firebox System Manager no longer display the certificates status as valid even if a certificate is invalid. [40378]

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.

Webinterface nun auch bei X Core und X Peak

Eine der wesentlichen Neuerungen bei der Fireware XTM (Version 11) ist, dass sich nun auch die größeren Modelle der X Core und X Peak Geräteserien über ein Webinterface (auch “WebUI” genannt)administrieren lassen. Von “innen” ist das Webinterface erreichbar über https://IP-der-Firebox:8080. Die Anmeldeseite kennt zwei vordefinierte Usernamen: status und admin. Zu dem User “status” gehört die Status Passphrase (das lesende Kennwort), zu dem User “admin” die Configuration Passphrase (das schreibende Kennwort). Wenn Sie vorhaben, Änderungen am Regelwerk vorzunehmen, müssen Sie sich als User “admin” anmelden! Die Fireware XTM lässt aber zu einem Zeitpunkt nur genau EINE admin-Sitzung zu! Wenn Sie die Firebox über das Internet, sprich von “außen” administrieren wollen, müssen Sie die entsprechende automatisch hinzugekommene Regel für Port 8080 auch für externe IP-Adressen öffnen – hierbei sollte allerdings eher nicht einfach “Any-External” mit in das From-Feld aufgenommen werden, sondern besser nur einzelne, feste IP-Adressen, von denen aus die Administration gestattet werden soll.
Das Webinterface (WebUI) der Fireware XTM unterstützt jedoch nicht alle Funktionen, die über den Policy Manager des WSM nutzbar sind. WatchGuard hat hierzu eine Liste der nicht unterstützten Funktionen in den Release Notes der Fireware XTM (Version 11) bereitgestellt:

The Fireware XTM Web UI does not support the configuration of some features. These features include:

  • FireCluster
  • Full proxy configuration options
  • The editing of static NAT rules
  • Manual policy precedence
  • Certificate export
  • You cannot enable diagnostic logging or change diagnostic log levels
  • You cannot turn on or off notification of BOVPN events
  • You cannot add or remove static ARP entries to the device ARP table
  • You cannot save a device configuration file to your local computer
  • You cannot get the encrypted Mobile VPN with IPSec end-user configuration profile, known as the .wgx file. The Web UI generates only a plain-text version of the end-user configuration profile, with file extension .ini.
  • You cannot edit the name of a policy, use a custom address in a policy, or use Host Name (DNS lookup) to add an IP address to a policy.
  • You cannot use the Web UI to configure a DNS server for the DHCP settings of a wireless guest account. You must use Policy Manager or the CLI to add the DNS server. [39980]
  • If you configure a policy in the Web UI with a status of Disabled, then open Policy Manager and make a change to the same policy, the action assigned to the policy when it denies packets is changed to Send TCP RST. [34118]
  • If you use the Web UI to edit an existing proxy policy that has alarm settings enabled, the alarm settings may be disabled when you save your configuration. [38585]
  • You cannot create read-only Mobile VPN with IPSec configuration files with the Web UI. [39176]