Category Archives: Technischer Blog

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

1 Comment

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

Comment

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…

X Edge und Avaya VoIP Telefone

2 Comments

Bislang gab es ein Problem mit der Kompatibilität zwischen einer X Edge mit Software v10.x und VoIP-Telefonen des Herstellers Avaya. Das Problem ließ die X Edge bisweilen unkontrolliert neu booten. Die bisherige Empfehlung lautete: Downgrade der X Edge auf Software v8.6.2 – hier tauchte das Problem nicht auf. Nun ist eine Lösung in Sicht: mit Edge 10.2.6 (offenbar noch vor Weihnachten) soll das Problem behoben sein.

XML-Konfigurationsdatei auf anderes Modell portieren

Comment

Nach etwas Urlaub nun wieder etwas Arbeit… 🙂 Eine urspünglich für ein bestimmtes Modell erstellte XML-Konfigurationsdatei kann auch für alle anderen X Core und X Peak Modelle mit Fireware angepasst und verwendet werden. Hierzu wird die Datei mit dem Policy Manager geöffnet und bei Setup > System > Firebox Model wird das neue Modell ausgewählt. Ändert sich dadurch die Anzahl der an der Hardware vorhandenen Netzwerk-Interfaces, erscheint eine Warnmeldung:

Nach dem Klick auf Ja kommt folgende Bestätigung und die Konfiguration kann dann entsprechend weiter angepasst werden:

Ein kleines Problem tritt auf, wenn die Modellnummer des neuen Geräts NIEDRIGER ist als die in der Konfigurationsdatei (X550e ist zum Beispiel niedriger als X700, X5000 ist niedriger als X5500e)! Dann verweigert der Policy Manager nämlich zunächst den Modellwechsel (“The model number must not be lower than the base model:Xxxx”):

Der Trick besteht nun darin, vorher die XML-Konfigurationsdatei mit einem Texteditor zu öffnen (der Default Pfad zu den Konfig-Dateien ist Eigene DateienMy WatchGuardconfigs). Relativ weit oben in der XML-Datei (etwa um die achte Zeile herum) befindet sich der Tag

< base-model > X5500e < / base-model > .

Diese Zeile muss komplett GELÖSCHT werden. Anschließend die XML-Datei speichern und mit dem Policy Manager öffnen. Dann sollte die Modelländerung problemlos vonstatten gehen… Eine Modelländerung ist ja auch immer mit einem Wechsel der Hardware/Seriennummer verbunden. Natürlich muss daher auch immer der Feature Key ausgetauscht werden: Setup > Feature Keys. Alten Feature Key removen, neuen Feature Key importieren.

WatchGuard 3G Extend Solution

1 Comment

Ab sofort ist das Produkt WatchGuard 3G Extend Solution bestellbar. Es handelt sich um eine Bridge, die vor einer WatchGuard Firebox Edge, Core oder Peak platziert wird. In diese Bridge wird eine PCMCIA- bzw. PC-Express-Karte eingeschoben, die die Verbindung zu einem Mobilfunknetz herstellt (z.B. UMTS, HSDPA/GPRS, EDGE). Somit können kleine Arbeitsgruppen, die an ständig wechselnden Orten arbeiten müssen (zum Beispiel in Baustellen-Containern) sicher an das Internet und über VPN an das Firmennetzwerk angebunden werden. Gleiches gilt auch für Fahrzeuge, bewegliche Maschinen (LKWs, Baumaschinen) oder fest installierte Automaten, die an Orten ohne eigenen Telefon- oder DSL-Anschluss aufgestellt sind.

Auch Failover- bzw. Backup-Szenarien lassen sich hiermit aufbauen: in Verbindung mit Edge Pro bzw. Fireware Pro kann so ein zweiter externer Anschluss bereitgestellt werden. Fällt die reguläre Internet-Leitung aus, weicht die Firebox auf die Mobilfunk-Anbindung aus. Zur Kostenbegrenzung sollte ein Tarif mit einer Daten-Flatrate gewählt werden, die derzeit schon für unter 40 Euro im Monat zu bekommen sind. Alternativ kann beim Mobilfunk-Anbieter eine Volumen-/Kostenbeschränkung beantragt werden, damit nicht im Extremfall unkontrolliert Kosten auflaufen. Der 3G Extender kostet unter 300 Euro (incl. MwSt.).


WebBlocker: Automatische Updates

Comment

Updates der WebBlocker-Datenbank können auch automatisiert werden. Im Unterverzeichnis C:ProgrammeWatchGuardwsm10.2bin befindet sich eine Batch-Datei names updatedb.bat, die mit Hilfe des Windows Task Scheduler auch unbeaufsichtigt ausgeführt werden kann (Windows / Start / Alle Programme / Zubehör / Systemprogramme / Geplante Tasks). Die Batch-Datei beendet zunächst den WebBlocker-Dienst, schaut dann nach Updates und startet den Dienst erneut.
Zu beachten ist, dass der HTTP-Proxy standardmäßig keinen Webzugriff zulässt, wenn der WebBlocker-Dienst nicht läuft. Dieses Verhalten kann im Policy Manager über Tasks / WebBlocker… / Configure… und nochmals Configure… auf der Registerkarte Advanced geändert werden. Ich wähle hier üblicherweise die Einstellung “If your Firebox cannot connect to the WebBlocker server in 5 seconds then Allow the user to view the website”. Außerdem muss sichergestellt sein, dass der WebBlocker-Server direkten, gerouteten http-Zugriff auf das Internet über Port 80 hat.

Zertifikat für Web Authentication

3 Comments

Bei Nutzung von User Authentication melden sich die User an der von der WatchGuard Firebox selbst zur Verfügung gestellten Anmeldeseite https://ip-der-firewall:4100 an. Für die SSL-Verschlüsselung wird standardmäßig ein von WatchGuard selbst erzeugtes SSL-Zertifikat verwendet, das aber nicht gegenüber einer “offiziellen” Zertifizierungsstelle rückbestätigt ist. Daher bekommen die User zunächst die übliche Warnmeldung des Browsers gezeigt, die sie entsprechend übergehen müssen.
Der beste Ansatz, dieses Verhalten zu umgehen, ist der Einsatz eines offiziellen Webserver SSL-Zertifikats, das aber kostenpflichtig ist und im Regelfall pro Jahr ebenfalls kostenpflichtig erneuert werden muss. Die entsprechende Zertifikatskette kann dann über den Firebox System Manager im Menüpunkt View / Certificates… importiert werden. Anschließend steht das Zertifikat im Policy Manager unter Setup / Authentication / Web Server Certificate als Third Party Certificate zur Auswahl bereit. Alternativ dazu kann bei Vorhandensein einer (Windows) Active Directory Umgebung dort auch eine eigene (Windows-)Zertifizierungsstelle aufgesetzt und darüber ein eigenes Webserver-Zertifikat generiert werden. Computer, die Mitglied der Domäne sind, lernen dieses Zertifikat dann automatisch.
Wichtig: Der Import von Zertifikaten ist ein Feature der Zusatzoption Fireware Pro, die bei X Peak Geräten standardmäßig dabei ist, auf X Core Geräten jedoch separat lizensiert werden muss!

WebBlocker: Download und Update langsam

1 Comment

Ein Get Full Database oder Get Incremental Update der WebBlocker-Datenbank ist in manchen Installationen derzeit extrem langsam. Hierbei handelt es sich um ein DNS-Problem. Die DNS-Server der Deutschen Telekom zum Beispiel liefern für den (im Hintergrund fest hinterlegten Hostname listsrv.surfcontrol.com derzeit die IP 204.15.69.70 zurück. Die Performance dieses Servers lässt aber sehr zu wünschen übrig. Wesentlich (!!!) schneller ist der 204.15.67.70, der z.B. von amerikanischen DNS-Servern aufgelöst wird.
Man könnte nun entweder dafür sorgen, dass für die DNS-Auflösung ein anderer Forwarder verwendet wird (zum Beispiel 4.2.2.2) – oder auf dem WebBlocker-Server einen Eintrag in die lokale HOSTS-Tabelle schreiben. Diese liegt auf Windows-Systemen unter C:windowssystem32driversetc und heisst einfach nur “hosts“. Die Datei kann mit einem Texteditor bearbeitet werden:

Anschließend noch den DNS-Cache leeren: ipconfig /flushdns und den Download/Update erneut starten. Dies ist natürlich nur eine Übergangslösung. Man sollte im Auge behalten, wann sich die DNS-Auflösung auf dem standardmäßigen DNS-Server wieder entsprechend ändert – und dann den Eintrag in der HOSTS-Tabelle wieder rückgängig machen, um nicht bei einem möglicherweise in der Zukunft stattfindenen Wechsel der IP-Adresse plötzlich im Regen zu stehen…

Zwei Versionen der Fireware 10.2.3

Comment

Die ursprüngliche Veröffentlichung der Fireware 10.2.3 vom 07.10.08 ist offenbar fehlerhaft. Der Installer fireware10_2_3.exe, der am 07.10.08 zum Download bereitgestellt wurde, wurde am 14.10.08 durch eine neuere Version – allerdings mit gleichem Dateinamen (!) ersetzt. Die Versionen erkennen Sie nur an der so genannten Build-Nummer: Gehen Sie auf Ihrer WatchGuard Management-Station in das Verzeichnis C:ProgrammeGemeinsame DateienWatchGuardresourcesFireware10.2. Überprüfen Sie dort den Dateinamen der *.wgf und *.wgu Dateien. Finden Sie dort fbx_ta-10.2-b192439.wgf bzw. FW1020B192439.wgu (entspricht Build 192439), dann haben Sie die ALTE Version der Fireware 10.2.3. Bei fbx_ta-10.2-b193535.wgf bzw. FW1020B193535.wgu (entspricht Build 193535) haben Sie die NEUE Version!
Ich empfehle dringend, auf die NEUE Version umzusteigen. In einem Kundenprojekt hat sich z.B. gezeigt, dass bei der alter Version jedesmal die BOVPN-Tunnel unterbrochen werden, wenn eine simple Konfigurationsänderung gespeichert wurde. Dieses Fehlverhalten war dann mit der neuen Version wieder verschwunden. Der Installer des WSM hingegen hat sich nicht geändert.

Report Server und deutsches Windows

2 Comments

Um die im WatchGuard System Manager v10.x integrierten Server-Dienste Logging Server und Report Server auf einer deutschen Windows-Plattform nutzen zu können, muss an einigen Stellen manuell nachgearbeitet werden, da sonst z.B. das Reporting überhaupt nicht funktioniert – oder dauerhaft 100% CPU-Last hervorruft…
Bereits bei der Konfiguration der Dienste (rechte Maustaste und Configure auf dem Icon in der Symbolleiste WatchGuard) fällt an einigen Stellen auf, dass per Default hart codierte Pfade à la C:Documents and Settings… hinterlegt sind. Ich ändere diese Pfadangaben auf deutschen Betriebssystemen immer auf das entsprechende C:Dokumente und Einstellungen… ab und lösche anschließend im Filesystem die zuvor erzeugten leeren Unterverzeichnisse mit englischem Namen. Casus knacksus und Auslöser für die 100% CPU-Last durch den Report Server ist jedoch, dass dieser eine Datei mit Hilfetexten sucht und nicht findet. Man muss im Filesystem das Unterverzeichnis
C:ProgrammeWatchGuardwsm10.2helpmapsen-US umbenennen in de-DE. Anschließend einmal booten und der Spuk sollte nach ein paar Minuten “legitimer Rödelei” vorbei sein.