Category Archives: Technischer Blog

Traffic Management funktioniert nicht richtig unter 11.4.1

Comment

In der Version 11.4.1 hat sich ein Bug in den Bereich Traffic Management eingeschlichen. Eine Traffic Management Action, die eine Bandbreitenbegrenzung für den Fall enthält, dass der Verbindungsaufbau zwar in ausgehende Richtung erfolgt – der eigentliche Traffic aber von außen nach innen fließt, greift derzeit nicht!
Dies betrifft leider auch den “typischen” Anwendungsfall, dass HTTP Downloads bzw. allgemein das “Websurfen” nur eine begrenzte Bandbreite verwenden dürfen… 🙁

Downgrade von Version 11.4.1 auf 11.3.2

Comment

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

Policy Based Routing

2 Comments

Die Voraussetzung für die Nutzung von Policy Based Routing ist die Fireware Pro bzw. XTM Pro Zusatzoption und die korrekte Konfiguration von mehr als einem externem Interface für den Multi-WAN-Betrieb (vgl. z.B. http://de.watchguard-blog.com/2011/08/multi-wan-und-policy-based-routing.html).
Anschließend erweitert sich das Erscheinungsbild jeder einzelnen Firewall-Policy – und über die dort erscheinenden, eigentlich selbsterklärenden erweiterten Einstellungen lässt sich das gewünschte Verhalten im Multi-WAN-Umfeld bestimmen:

Sinn macht an dieser Stelle natürlich – speziell für ausgehende HTTP und HTTPS Policies – hier das vom Multi-WAN-Default abweichende Interface auszuwählen (im Beispiel das Interface “VDSL50” anstelle der defaultmäßigen “STANDLEITUNG”). Das hat zur Folge, dass eben der durch ausgehende HTTP/HTTPS-Verbindungen (also auch Downloads!) verursachte Traffic über das “zweite” externe Interface geführt wird (VDSL50) – und somit die STANDLEITUNG von eben diesem Traffic entlastet wird, so dass die dortige Bandbreite für die unternehmenskritischeren Anwendungen wie VPN, E-Mail etc. genutzt werden kann.

Multi-WAN und Policy Based Routing

1 Comment

Wenn auf einer WatchGuard die Zusatz-Option “Fireware Pro” bzw. “XTM Pro” aktiviert ist, können bis zu vier Interfaces als External Interface konfiguriert werden. Hier können jeweils unterschiedliche Internet-Anschlüsse angebunden werden. Ein typisches Anwendungs-Szenario sieht so aus: Kunde x hat eine Standleitung mit x Mbit Bandbreite, die bisweilen überlastet ist, weil “zu viel” HTTP/HTTPS-Traffic (Eigennutzung, sprich Surfen und Downloads) die Leitung “dicht” macht und zu wenig Bandbreite für VPN-Anbindungen, E-Mail und andere unternehmenskritische Anwendungen übrig bleibt…
Statt einfach die Bandbreite der Standleitung für teuer Geld beim Provider hochsetzen zu lassen, kann auch darüber nachgedacht werden, einen – deutlich billigeren – ADSL, VDSL oder Kabel-TV-Anschluss als zweiten Internet-Anschluss an die gleiche WatchGuard anzubinden und über das Firewall-Regelwerk festzulegen, dass der typische HTTP und HTTPS Traffic über eben diese billigere DSL-Leitung geführt wird (Policy Based Routing, PBR). Damit wird die (teure) Standleitung von eben diesem Traffic ENTLASTET.

Die unternehmenskritischen Services können so evtl. auch auf längere Sicht auf dem bisherigen Stand zu deutlich geringeren laufenden Kosten versorgt werden.

Wenn nun mindestens ein zweites Interface der WatchGuard als “External” konfiguriert wird, sind zusätzliche Einstellungen erforderlich, ohne die das gewünschte Verhalten eventuell nicht zum Tragen kommt! Insbesondere muss im Policy Manager unter Network > Configuration die Registerkarte Multi-WAN beachtet werden, die bei Verwendung nur eines einzelnen externen Interfaces “ausgegraut” war.
Hier wähle ich in der Regel als Default-Verhalten im Multi-WAN-Betrieb anstelle des voreingestellten Verfahrens “Routing Table” das Verfahren “Failover” aus und aktiviere hinter dem Button “Configure” die am typischen Multi-WAN-Betrieb beteiligten externen Interfaces (die Zahlen in Klammern entsprechen der Interface-Nummer auf der WatchGuard: z.B. 0=eth0, 6=eth6):

Die angezeigte Reihenfolge der Interfaces entspricht auch dem tatsächlichen Verhalten der WatchGuard Firebox für ausgehende Verbindungen: sofern keine PBR-Regel ein anderes Verhalten vorschreibt, werden die Interfaces gemäß dieser Liste von oben nach unten bedient. Will heißen: Wenn das ganz oben aufgeführte Interface “ACTIVE” ist, dann wird auch genau dieses per Default bedient, ansonsten wird das nächste Interface in der Liste verwendet…

Wie erkennt nun die WatchGuard, ob ein Interface “ACTIVE” ist oder nicht? Auch dies wird über die Registerkarte Multi-WAN gesteuert:

Für jedes der am Multi-WAN Verhalten beteiligten Interfaces muss nun definiert werden, woran die WatchGuard die Verfügbarkeit des Interfaces festmachen soll. Das Default-Verhalten ist in der roten Markierung und den darunter aufgeführten Settings beschrieben. Demzufolge pingt die Firebox alle 15 Sekunden eine IP-Adresse an (standardmäßig das Default Gateway des jeweiligen Interfaces). Wenn die angepingte IP-Adresse (3+1) = 4 x 15 => 60 Sekunden) nicht antwortet, wird das Interface auf “INACTIVE” gesetzt. Kommen wieder drei aufeinanderfolgende Antworten im Abstand von 15 Sekunden, wird das Interface wieder auf “ACTIVE” gesetzt und nimmt am Multi-WAN-Verfahren teil.

Daraus ergeben sich zwei Problematiken:

  • Problem 1 (Szenario Standleitung) => “Wo befindet sich das Default Gateway einer Standleitung?” Antwort: “Das ist der Übergaberouter des ISP, der sich in der Regel beim Kunden vor Ort befindet und per Kabel direkt an der WatchGuard angeschlossen ist”. Wenn nun eben dieser Router auf “ping” antwortet: Ist das eine zuverlässige Aussage darüber, ob nun die eigentliche Internet-Anbindung durch diesen Router hindurch funktioniert? Antwort: “Nein”. Typischerweise sollte also hier eine EXPLIZITE IP-ADRESSE konfiguriert werden, die irgendwo tatsächlich im Internet liegt.

  • Problem 2 (Szenario PPPoE oder DHCP-Einwahl) => Das Default Gateway des Interfaces wird dem Interface vom Provider erst bei der Einwahl zugewiesen. In vielen Fällen (providerabhängig!) antwortet aber genau diese als Default Gateway zugewiesene IP-Adresse nicht auf ping. Was ist also das Resultat im Default-Zustand? Das Interface arbeitet zunächst (3+1) x 15 => 60 Sekunden ordnungsgemäß, wird dann jedoch von der WatchGuard als “INACTIVE” eingestuft und aus dem Multi-WAN-Verfahren herausgenommen… Insbesondere in diesem Fall sollte also UNBEDINGT eine tatsächliche IP-Adresse im Internet als ping-Ziel definiert werden…

Es ist nun also erkennbar, dass man sich im Multi-WAN-Umfeld von der Verfügbarkeit von externen Systemen abhängig macht, auf die man selbst keinen Einfluss hat! Ich verwende hier meist “bekannte” IP-Adressen, die in sich oft hochverfügbar ausgelegt sind: 8.8.8.8, 4.2.2.3, 141.1.1.1 oder die typischen DNS-Server der Telekom 194.25.0.60, 194.25.0.68, 194.25.0.52, 194.25.2.129 etc. Providerunabhängig lautet meine Empfehlung generell: Verwenden Sie hier nach Rücksprache mit Ihrem Leitungs-Provider eine IP-Adresse im Backbone Ihres Providers, die nachweislich hochverfügbar ausgelegt ist – und die sich nicht in absehbarer Zeit ändern wird!

(Mit der 141.1.1.1 hatte ich letzte Woche z.B. Probleme, weil die Betreiber wohl irgendwelche Wartungsarbeiten auf dem System durchgeführt haben, und die IP eine Zeitlang nicht erreichbar war – mit den Konsequenzen, die man sich sicher gemäß o.g. ausmalen kann… War zum Glück an einem Wochenende…)

Nachdem nun die Voraussetzungen für das korrekte Funktionieren von mehreren Interfaces im Multi-WAN-Umfeld gegeben sind, kann man an das Konfigurieren der tatsächlichen PBR (Policy Based Routing) Firewall-Regeln herangehen. Mehr dazu später heute Abend, wenn ich vom Strand zurück bin. Schließlich bin ich nun mal diese Woche im Urlaub… 🙂

WatchGuard und Telekom VDSL 25, VDSL 50

4 Comments

In der Vergangenheit stellte die Deutsche Telekom VDSL nur in Verbindung mit dem TV-Paket “Entertain” zur Verfügung. Das hat sich geändert: Mittlerweile kann VDSL auch als reiner Hochgeschwindigkeits-Anschluss gebucht werden, als Call & Surf Comfort VDSL in zwei Geschwindigkeits-Varianten: VDSL 25 mit 25/5 Mbit und VDSL 50 mit 50/10 Mbit, jedoch nur mit dynamischer IP-Zuweisung (und ggfs. DYNDNS). Daher wird es künftig auch häufiger vorkommen, dass eine WatchGuard Firebox an einem VDSL-Anschluss betrieben werden soll. Bisher war die korrekte Konfiguration des dazugehörigen “External” Interfaces der WatchGuard eher umständlich, da das Interface als VLAN-Interface mit einem Tagging für die VLAN ID 7 konfiguriert werden musste. Mit Verfügbarkeit des Telekom Speedport 221 VDSL2 Modems entfällt dieser Umweg. Das VDSL-Modem übernimmt das VLAN-Tagging, so dass in der WatchGuard “nur noch” die üblichen PPPoE-Zugangsdaten hinterlegt werden müssen.
Wenn der VDSL-Zugang im Rahmen von “Multi-WAN” als “zusätzlicher” Anschluss für schnelles Surfen verwendet werden soll, beachten Sie bitte auch den folgenden Blog-Beitrag:http://de.watchguard-blog.com/2011/08/multi-wan-und-policy-based-routing.html

RSA SecurID Appliance verweigert User Authentication wegen falscher Systemzeit

Comment

Vor ein paar Wochen hatte ich den Fall, dass ein Kunde eine RSA SecurID Appliance (v3.0) zur Two-Factor Authentication seiner WatchGuard Mobile User VPN Verbindungen nutzen wollte. Trotz vermeintlich korrekter Konfiguration sowohl der WatchGuard XTM 510 als auch der RSA Appliance wollte es partout nicht klappen. Die eigentliche Ursache kam erst fast zufällig in einem Support Call mit RSA ans Tageslicht: weil NTP (Network Time Protocol), also der automatische Zeitabgleich mit Zeitservern im Internet auf der RSA Appliance fehlerhaft konfiguriert war, hatte die RSA Appliance eine um etwa 12 Stunden falsche Systemzeit, was eben zur Ablehnung der Usereinwahlen geführt hat… Mit korrekter Systemzeit auf der RSA Appliance war dann “alles gut”…

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]

Verlust der Konfigurationsdatei beim Update von v10 auf v11.3.4

2 Comments

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

RMA Fälle der letzten Zeit

Comment

Ich hatte in den letzten Wochen drei Fälle, in denen WatchGuard die Hardware Appliance im Zuge eines Support Incidents ausgetauscht hat:

  • Defekte XTM 505: nachdem die Ersteinrichtung (incl. Aufspielen des Feature Key) einwandfrei geklappt hatte, blieb beim nächsten Boot-Vorgang das LCD-Display komplett leer (Hintergrundbeleuchtung an), die Box “kam nicht hoch” und auch die Lüfter liefen nach wie vor auf 100% (reduziert sich normalerweise nach ca. 20-30 Sekunden auf eine geringe Drehzahl).

  • Defekte X10e: trotz korrekter Ausführung eines “Factory Reset” (für mehr als 1 Minute gedrückter RESET-Buttons während Power On) startete die Box nicht in die Maintenance-Partition SYS-B (Safe Mode) – stattdessen war wieder die reguläre Partition SYS-A und die reguläre Konfigurationsdatei aktiv…

  • Defekte SSL100: Probleme mit User Authentication (Microsoft ActiveSync gegenüber Active Directory für den SSL-Zugriff von Apple iPhone auf Microsoft Exchange Server)