Category Archives: Technischer Blog

Crash Report kann Antivirus-Pattern-Update verhindern

Kürzlich bei einer Box aufgetreten: Antivirus-Pattern-Update konnte das Signature-File nicht mehr herunterladen.  Im Firebox System Manager unter Subscription Services wurde beim manuellen Update folgende Fehlermeldung erzeugt:

The signature update failed: An error occured when downloading the signature file (9)

Im Traffic Monitor war folgende Fehlermeldung zu sehen:

sigd Manual GAV update started
sigd Manual GAV update for version (13101) failed (Failed to download signature file from server)

Die Lösung war, alle Crash Reports zu löschen. (Firebox System Manager => Status Report Tab => Support => Delete all crash reports).

Auszug aus dem WatchGuard Support Case:

unfortunately when crash report is listed, this create a condition to not download signature update.
Seems there is a problem to decompress some internal file in the kernel and this need the deletion of crash.
Once you delete them, Firewall is able to download and update itself.

Bei der betroffenen Box wurden die Crash Reports gelöscht und danach funktionierte das manuelle Update auf anhieb, ein Reboot der Box war nicht notwendig.

 

Update 2017-06-27: Siehe hierzu auch unseren Artikel GAV Update Probleme bei Update des Patterns auf XTM2-Series. 

 

LetsEncrypt Zertifikat als Proxy-Zertifikat auf Watchguard Firebox

Ziel

Setup eines kostenfreien SSL-Zertifikates zum Testen des TLS-Proxies auf einer Watchguard. Für den weiteren Artikel wird hier @mail.meinedomain.de@ als Hostname vorausgesetzt.

Voraussetzung

  • DNS konfiguration: mail.meinedomain.de muß im DNS als A-Record und PTR-Record auflösbar sein
  • WWW-Konfiguration: http://mail.meinedomain.de/ muß auf einen Webserver zeigen, auf den man Zugriff hat, um die Authorisierungs-Dateien zu hinterlegen

Weiterlesen »

IPSec VPN WatchGuard <=> Android (nativer Client)

Dieser Artikel beschreibt die Anbindung eines Android 6.0.1 Marshmallow mit dem Native Client per IPSec an eine WatchGuard Firebox/XTM.

Nativer Client

Die in der WatchGuard Help (Stand: 04.08.2016) angegebenen Hinweise auf die IPSec Proposals beziehen sich auf Android 4.x. Dort steht “do not use SHA2 in the Phase 1 and Phase 2 settings. SHA2 is not supported on the VPN clients on Android devices”. Mittlerweile wird jedoch SHA1 als nicht mehr ausreichend sicher eingestuft und soll eigentlich nicht mehr verwendet werden. SHA2 wird inzwischen von Android in Phase 1 und Phase 2 unterstützt. Theoretisch zumindest.
Leider funktioniert genau dieses SHA2 in Phase 2 nicht richtig. Es wird zwar eine Verbindung hergestellt, aber danach kann kein SA ausgehandelt werden, womit das Android-Device ohne Routing gar nicht mehr kommunizieren kann. Hier folgt eine genauere Betrachtung der Proposals und eine Anleitung mit funktionierenden Parametern.

Weiterlesen »

Watchguard SSLVPN 2-Factor mit Google-Authenticator Token

WatchGuard SSLVPN 2-Factor mit Google-Authenticator Token

Zwei-Faktor-Authentisierung ist derzeit stark im Kommen und dies ist eine gute Entwicklung. Eine Zwei-Faktor-Authentisierung baut auf zwei Dinge:

  • Something you know
  • Something you have

Es werden zum Login also zwei komplett unterschiedliche Dinge benötigt, einmal etwas, das man kennen muss (typischerweise das Passwort), und dann etwas, das man besitzen muss (typischerweise einen Token-Generator). Der Token-Generator erzeugt nun automatisiert zeitabhängige Token, also mehrstellige Ziffern-Folgen, die sich mit der Zeit ändern. Hierfür gibt es bei WatchGuard die Unterstützung von Secure-ID – aber diese Tokens sind umständlich, man muss sie nämlich dabei haben. Also “noch ein Ding rumschleppen”.

Seit einigen Jahren gibt es bei Google die Möglichkeit, mit Google-Authenticator eine Zwei-Faktor-Authentisierungzu aktivieren. Hierbei wird ebenfalls ein “Ding” als Tokengenerator verwendet, nur ist dieses Ding etwas, das man sowieso schon dabei hat: das Smartphone.

Die Idee ist nun, die Token-Erzeugung in eine App auf dem Smartphone auszulagern, somit muß jemand zum Login auf das Google-Konto nicht nur das Passwort kennen, sondern auch das Smartphone besitzen _und_ es freischalten können, um an das Token zu kommen.

Was liegt nun näher, als die WatchGuard mit Google-Authenticator zu vermählen?

Weiterlesen »

Installation Dimension auf Intel-NUC mit VMWare ESXi

Für kleine Netzwerkumgebungen ohne vorhandene ESXi-Umgebung gibt es häufig ein Problem, einen Watchguard Dimension Server (Logserver) zu betreiben, da dieser nur als Template für VMWARE oder HyperV angeboten wird. Ein Einsatz einer Dimension ist jedoch für die Überwachung der Firewall anzuraten.

Eine einfache, platzsparende Lösung ist das Setup einer VMWARE ESXi auf einem kleinen Intel NUC. Die Vorteil des Einsatzes eines NUC bestehen im geringen Platz- und Strombedarf des NUC. Weiterlesen »

HOWTO: Software-Update über das Web-Interface

Die regelmäßige Aktualisierung Ihrer WatchGuard Firebox ist wichtig, um die Leistungsfähigkeit, Sicherheit und Zuverlässigkeit Ihres Netzwerks zu gewährleisten. In diesem Blog-Artikel zeigen wir Ihnen Schritt für Schritt, wie Sie ein Fireware Software-Update über die Web-UI erfolgreich durchführen – unabhängig davon, ob sich Ihre Firebox bereits im Einsatz befindet oder ob Sie diese gerade erstmalig einrichten.

Unseren ausführlichen HOWTO-Artikel über alle drei verschiedenen Methoden, mit denen Sie das Firmware-Upgrade Ihrer Firebox sicher und effizient durchführen können finden Sie unter >> HOWTO: WatchGuard Firebox Firmware-Upgrade. Weiterlesen »

Dynamic NAT und Nicht-RFC-1918-Adressen

Eine Default WatchGuard Konfigurationsdatei, die per Setup Wizard erstellt wurde, geht davon aus, dass in einem LOKALEN Netzwerk (Trusted oder Optional) entweder RFC-konforme Private IP-Adressen nach RFC 1918 verwendet werden – 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 > Dynamic NAT.
Fügen Sie dort Ihren “verbogenen” lokalen IP-Bereich hinzu. Hierbei kann auch eine bestimmte Quell-IP festgelegt werden. Wird nichts definiert, wird die Primary IP des Interfaces verwendet, über das das Datenpaket gemäß Routing Table die WatchGuard verlässt:

WatchGuard Dynamic NAT 1   WatchGuard Dynamic NAT 2   WatchGuard Dynamic NAT 3

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 KORREKTE private IP-Adressen nach RFC 1918 verwendet werden…

Dieser Artikel wurde erstmals am 11.12.2008 im “Technischen WatchGuard-Blog von Bernd Och” veröffentlicht. Hierher verschoben und aktualisiert in 2016.