Category Archives: Technischer Blog

X Edge: versteckte Debug-Funktionen

Die Firebox X Edge hat eine nicht dokumentierte Seite, die zum Testen und für Debug-Zwecke sehr hilfreich ist:
https://IP-DER-FIREBOX/shakne.htm.
Im Abschnitt Property Management können mit den Funktionen “Get Property”, “Put Property” und “Delete Property” einzelne Parameter in der Konfigurationsdatei hinzugefügt, verändert und gelöscht werden, die über die GUI sonst nicht erreichbar wären. Ähnlich wie beim manuellen Eingriff in die Registry eines Windows-Rechners ist hier natürlich ein konkreter Anlass und äußerste Sorgfalt angesagt!
Die Funktion Ping setzt einen Ping direkt von der Firebox an die eingegebene Zieladresse ab. Das ist äußerst hilfreich, z.B. wenn man sich gerade einmal nicht auf anderes Testsystem an dem Standort aufschalten kann…

Weiter unten finden sich noch verschiedene Debug-Hilfen – unter anderem kann hier auch das Logging Level für die Application Proxies hochgesetzt werden (wirklich nur für Debug-Zwecke, denn natürlich erzeugt das erweiterte Logging Last auf der Firewall…)

Upper Port Problem bald gelöst

Freudige Nachricht des Tages: Aktuell wird bereits ein neuer Code getestet, der zwei Phänomene des bisweilen auftretenden Upper Port Problems beseitigen soll – genau die, die hauptsächlich hier in Europa auftreten: Das Booten der kompletten Box durch Kernel Crash und temporäre Traffic Unterbrechung an den oberen (rechten) vier Ports der aktuellen X Core e-series und X Peak e-series Hardware. Dieser Code soll u.a. Bestandteil der nächsten Version 10.2.7 sein.

Upgrade-Pfad für X Edge e-series

WatchGuard empfiehlt, beim Software-Update einer X Edge e-series (X10e, X20e, X55e und die Wireless-Versionen) auf die Einhaltung folgender Reihenfolge zu achten: Edge e-Series 8.0 > 8.0.1 > 8.0.3 > 8.6.2 > 10.2 > 10.2.6. Dazwischen liegende Software-Versionen sollten immer zunächst auf die nächst höhere Version in der Liste upgedated werden, bevor die weiteren Updates in der o.g. Reihenfolge aufgespielt werden.
Speziell der Zwischenschritt auf 10.2 soll dabei das Problem mit der fehlenden VPN-Any Policy vermeiden. Hier wird beschrieben, wie ein Software-Update auf einer X Edge durchgeführt wird.

Software-Updates auf einer X Edge

Im Software-Download-Bereich der WatchGuard Website finden sich für die X Edge jeweils zwei Versionen: eine EXE-Datei und eine ZIP-Datei. Die EXE kann unter Windows XP und 2000 verwendet werden – ich verwende im Regelfall aber die ZIP-Datei. Im Download steckt jeweils ein vollständiges Linux-Image, das bei einem Update auf die X Edge Appliance hochgeladen wird. Nach dem Entpacken der ZIP-Datei findet sich neben einer README und drei Language Files (Französisch, Chinesisch und Japanisch) die eigentlich wichtige Datei: yakfw.sysa-dl, die aktuell etwa 20 MB groß ist.

Prüfen Sie nach der Anmeldung am Webinterface der X Edge zunächst, ob die LiveSecurity noch aktuell oder bereits abgelaufen ist (Expired). Nur bei gültiger Live Security kann das Software-Update überhaupt durchgeführt werden. Die Verlängerung bzw. Reaktivierung der Live Security erfolgt über Ihren WatchGuard-Partner, gerne natürlich auch über uns. 🙂

Natürlich ist es eine gute Idee, vor dem Update zunächst ein Backup der Konfigurationsdatei zu erstellen: Administration > Backup Configuration. Hinweis: je nach verwendetem Browser müssen Sie ggfs. zwei Mal auf Backup klicken, bevor Sie die Backup-Datei namens edgecfg.wgbk tatsächlich zum Speichern angeboten bekommen.
Für das eigentliche Software-Update findet sich im Webinterface unterhalb der X Edge-Abbildung der Button Update. Ein Klick bringt Sie zu der Seite Administration > Update. Dort können Sie mit Durchsuchen den Pfad zu der neuen yakfw.sysa-dl auswählen und die Datei anschließend auf die X Edge hochladen. Abschließend will die X Edge einmal booten. Oben links im Webinterface sollte dann die neue Versionsnummer angezeigt werden: 10.2.6 December 08 2008 Build 202312. Die Konfigurationsdatei sollte erhalten geblieben sein, so dass die X Edge sofort wieder voll produktiv ist.

Sichere Fernwartung einer X Edge

Um eine entfernt stehende Firebox X Edge auch per HTTPS direkt über das Internet administrieren zu können, füge ich normalerweise bei Firewall > Incoming eine Custom Packet Filter Policy hinzu, die eingehenden HTTPS-Verkehr direkt auf das Webinterface der Firebox leitet (Static NAT). Damit nicht jeder beliebige Rechner aus dem Internet bis zur Anmeldeseite gelangt, lasse ich jedoch nur die bekannten festen IP-Adressen z.B. des Hauptstandorts des Kunden (und unsere eigenen) zu:

Hat die X Edge eine feste externe IP-Adresse, erfolgt der Zugriff über https://EXTERNE-IP. Bei einer dynamischen externen IP-Adresse nehme ich mir einen kostenfreien DYNDNS-Hostname zu Hilfe, der bei Network > Dynamic DNS eingetragen wird:

Befindet sich die X Edge in einer (VPN-)Außenstelle unseres Unternehmens, sorgt diese Einrichtung natürlich auch dafür, dass wir die X Edge über das Internet erreichen können, auch wenn der reguläre VPN-Tunnel dorthin gerade einmal nicht zur Verfügung steht 🙂 Wenn ich parallel dazu auch die SSL-VPN-Möglichkeit der X Edge nutzen möchte, um dort mobile User zu terminieren, lege ich den Port für Remote-HTTPS meist von 443 zum Beispiel auf 444 um: Administration > System Security:

Base Encryption statt Strong Encryption

In seltenen Fällen passiert beim Anlegen des Live Security User Accounts in der WatchGuard Datenbank ein Fehler. Nach der Anmeldung stehen Ihnen dann über Support > Software Downloads im Download-Bereich nur die Base Encryption Versionen (40 Bit) zur Verfügung, nicht aber die üblichen Strong Encryption Versionen (128 Bit). Wir können Ihnen bei der “Reparatur” helfen, wenn Sie uns den Namen Ihres Live Security Accounts mitteilen…

Neue Software-Versionen 10.2.6

Mit heutigem Datum (12.12.2008) wurden die Software-Versionen WatchGuard System Manager (WSM), Fireware und Edge 10.2.6 im Download-Bereich der WatchGuard-Website bereit gestellt. Dort steht auch eine neue Version 10.2.6 des WatchGuard SSL VPN Client bereit. Nach der Installation von 10.2.6 in unserem Produktiv-System waren keine negativen Auswirkungen erkennbar. Alle vorkonfigurierten BOVPN-Tunnel kamen erfolgreich wieder hoch, auch die Mobile User VPN Einwahl verlief erfolgreich…

WSM 10.2.4: Bandwidth Meter defekt

Das Bandwidth Meter im Firebox System Manager der Version WSM 10.2.4 hat wohl einen Bug. Die belegte Bandbreite wird – gefühlt – nur zu etwa einem Tausendstel angezeigt. Offenbar ist da im Hintergrund mal ein “Kilo” mit einem “Mega” durcheinander geraten…
[16.12.2008]: Wie mir heute aufgefallen ist, steckt der Bug nicht im WSM bzw. im Firebox System Manager, sondern in der Fireware 10.2.4: das Bandwidth Meter / WSM arbeitet korrekt, die Appliance liefert jedoch einen viel zu geringen Anzeigewert. Ein Update der Appliance auf Fireware 10.2.6 behebt das Problem!

X Edge: “VPN-Any” Problem nach Software Update

Kurzer Hinweis auf ein Problem bei der X Edge, das hoffentlich schon wieder der Vergangenheit angehört: mit Software-Version Edge 10.2.2 wurde eine neue (Default) Firewall-Regel namens VPN-Any ins Leben gerufen, die den Verkehr INNERHALB eines Branch Office VPN-Tunnels (BOVPN) zwischen dieser X Edge und einer VPN-Gegenstelle regelt (früher war dieser Traffic seitens der X Edge implizit immer zulässig…).
Es gibt Fälle, bei denen ein Software-Update auf einer X Edge mit einer älteren Software-Version (zum Beispiel 8.5.2) zu einem Fehler bei der automatischen Umschreibung der Konfigurationsdatei führt. Dann wird zwar das Software-Update durchgeführt (ohne Fehlermeldung!) – jedoch wird die Firewall-Regel “VPN-Any” nicht mit erzeugt. Das führt dazu, dass plötzlich kein Traffic mehr durch den VPN-Tunnel fließt… 🙁
So finden Sie heraus, ob Ihre X Edge nach einem Software-Update auf v10.x “gelitten” hat: Gehen Sie zu Firewall > Outgoing und prüfen Sie, ob im oberen Bereich die folgenden sieben (!) “Common Proxy Policies” angezeigt werden. Sehen Sie nur drei Proxy-Regeln (HTTP, FTP, Outgoing), haben Sie definitiv dieses Problem! Scrollen Sie weiter runter und prüfen Sie, ob bei den Common Packet Filter Policies die Regel VPN-Any (grün/Allow) angezeigt wird. Wenn nicht, haben Sie auch das hier beschriebene Problem…

Als Reparatur-Maßnahme schlägt WatchGuard vor, dass die X Edge Hardware auf Factory Default zurückgesetzt wird: Strom-Stecker ziehen, Reset-Knopf drücken, gedrückt halten, Strom-Stecker wieder einstecken, ca. 1 Minute warten, Knopf loslassen. Nach dem dann folgenden Setup Wizard (https://192.168.111.1) sollen die kundenspezifischen Einstellungen “from scratch” erneut vorgenommen werden… Der Weg über Administration > Backup Configuration und Restore Configuration behebt das Problem nach Aussage von WatchGuard-Support offenbar NICHT! Ich habe beim letzten Auftreten dieses Problems Papier-Ausdrucke der beschädigten Konfigurations-Dateien angefertigt und werde diese genauer analysieren, wenn ich Zeit dazu habe. Wenn ich einen einfacheren Weg zur Reparatur finde, werde ich hier berichten…
“Scratch” erzeugt man also zunächst am besten, indem man auf dem alten Stand auf Administration > View Configuration klickt, den Inhalt des Haupt-Frame per Cut&Paste in eine Textdatei wegspeichert und ausdruckt… Bis auf weiteres also viel Spaß beim Tippen…

Dynamic NAT und Nicht-RFC-1918-Adressen

Im Rahmen meiner heutigen WatchGuard-Schulung kam auch das Thema “Dynamic NAT” zur Sprache. Insofern kurzer Hinweis auf folgende Besonderheit: Per Default geht der WatchGuard Policy Manager davon aus, dass Sie in Ihren LOKALEN Netzwerken (Trusted oder Optional) entweder RFC-konforme Private IP-Adressen nach RFC 1918 verwenden – also ein beliebiges Subnet innerhalb der Bereiche 10.0.0.0/8, 172.16.0.0/12 oder 192.168.0.0/16 – oder korrekt geroutete öffentliche IP-Adressen! Nur dann funktioniert der “Internet-Zugriff” auf Anhieb!
Verwenden Sie jedoch – meist aus “historischen Gründen” – in Ihrem lokalen Netzwerk “verbogene” öffentliche IP-Adressen (also zum Beispiel: 192.1.1.0/24) – müssen Sie folgende Einstellung im Policy Manager bearbeiten, damit die reguläre Internet-Nutzung überhaupt erst möglich wird: Network > NAT.

Fügen Sie dort Ihren “verbogenen” lokalen IP-Bereich hinzu:

Technischer Hintergrund: Nur wenn die Quell-IP-Adresse in den Headern von ausgehenden IP-Paketen in den hier definierten Bereichen liegt, wendet die WatchGuard Firebox beim Durchfluss der Datenpakete Richtung Internet auch die erforderlichen NAT-Regeln an, ersetzt also die eigentliche Quell-IP-Adresse (des Client-PC) durch die korrekte öffentliche IP-Adresse der Firewall. Nur dann können die Daten aus dem Internet auch den korrekten Weg zu unserem lokalen Netzwerk zurück finden! – OHNE die NAT-Regel würde der angesprochene Server im Internet unsere Anfrage zwar erhalten – und sogar darauf antworten (!) – allerdings würden die Router im Internet die Antwort wegen ihrer Routing Tables sonstwohin schicken (Südamerika, Australien, Timbuktu…) – nur nicht zu uns, da die Router gar nicht wissen KÖNNEN, dass “wir” diese IP-Adressen “illegalerweise” in unserem lokalen Netzwerk in Hintertupfingen verwenden… 🙂
Fazit: o.g. NAT-Regel anpassen – oder dafür sorgen, dass in Ihrem lokalen Netzwerk endlich KORREKTE private IP-Adressen nach RFC 1918 verwendet werden…