Das Debug Log Level für die Konsole (System Manager => Traffic Monitor)
kann im Policy Manager unter
Setup => Logging => Klick auf [Diagnostic Log Level]
eingestellt werden. Hier stellt man den Bereich VPN > IKE auf “Debug”
und speichert die Konfiguration auf die WatchGuard.
Nicht vergessen: nach Gebrauch das Log Level wieder zurückstellen 🙂
Dieser Artikel beschreibt die Anbindung eines Android 6.0.1 Marshmallow mit dem Native Client per IPSec an eine WatchGuard Firebox/XTM.
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.
Zwei-Faktor-Authentisierung ist derzeit stark im Kommen und dies ist eine gute Entwicklung. Eine Zwei-Faktor-Authentisierung baut auf zwei Dinge:
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?
Wie kommt man schmerzfrei von (V)DSL + ISDN + Telefonanlage zu ALL-IP? Dieser Artikel liefert die nötigen Hintergrundinfos sowie eine mögliche und inzwischen mehrfach erfolgreich praktizierte Lösung.
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
Dieser Artikel berschreibt die Einrichtung mehrerer WLANs mit unterschiedlicher SSID und getrennten VLANs, um sie auf der Watchguard mit entsprechenden Policies sehr sauber getrennt managen zu können.
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
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:
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.
In einigen Supportfällen der Vergangenheit wurde zum Beispiel über Download langsam (oder fehlschlagend) bzw. VPN-Verbindung instabil geklagt. Als Ursache konnte jeweils eine Inkompatibilität auf Ethernet-Ebene zwischen der WatchGuard Firebox und – entweder dem vorgelagerten Übergabe-Router des Internet-Providers (im Regelfall an eth0) – oder dem internen Netzwerk-Switch (im Regelfall an eth1) lokalisiert werden, wodurch jeweils Ethernet Errors bzw. Ethernet Collisions auftraten.
Öffnen Sie den WSM, dann den Firebox System Manager. Auf der Registerkarte System Status scrollen Sie dann herunter, bis Sie den Abschnitt “Interfaces” finden. Grundsätzlich sollten die Ethernet Errors und Collisions auf allen Interfaces dauerhaft auf Null bleiben. Laufen die Werte hoch, haben Sie ein Problem.
WatchGuard empfiehlt, die Netzwerk-Interfaces an der Firebox auf Auto Negotiation (Auto-Sensing) zu belassen. Insofern sollte zunächst das Interface auf dem Router oder (managebaren) Switch manuell auf einen festen Wert eingestellt werden, um eine Kombination zu finden, die keine Errors und Collisions produziert. Gelegentlich hilft auch der Austausch des Netzwerkkabels! Bei den aktuellen Supportfällen handelte es sich jeweils um eine Company Connect Leitung der Telekom / T-Systems mit einem Cisco als Übergaberouter. Nach einer Störungsmeldung bei der Telekom dauerte es ca. 10 Minuten, bis die Kollegen dort ihren Router per Fernzugriff umkonfiguriert hatten – in der Regel wird der LAN-Port des ISP-Routers auf einen festen Wert von z.B. 100 Mbit Full Duplex gesetzt – und der Spuk mit den Errors und Collisions ein Ende hatte… 🙂
Hier noch ein historischer Screenshot einer Firebox X Edge e-series mit Softwareversion 10.x, bei der sich die Ethernet Statistik bei System Status > Interfaces befand. Im Screenshot ist erkennbar, dass Ethernet Collisions auftreten.
Dieser Artikel wurde erstmals am 22.12.2008 im „Technischen WatchGuard-Blog von Bernd Och“ veröffentlicht. Hierher verschoben und aktualisiert in 2016.
Eine WatchGuard Firebox / XTM speichert lokal immer nur die letzten Minuten des Traffic Logs. Wenn Logging Informationen über einen längeren Zeitraum aufbewahrt werden sollen/müssen – und wenn die Alarm-Funktion (Notification) genutzt werden soll – muss ein separater WatchGuard Log Server bereitgestellt werden, zu dem die WatchGuard Box die Logmeldungen schicken kann. Die aktuelle und empfohlene Variante ist der Einsatz eines kostenfreien WatchGuard Dimension Servers, der als fertige virtuelle Appliance für VMware ESXi und Microsoft Hyper-V Umgebungen bereitgestellt wird. Wenn keine Virtualisierungsplattform vorhanden ist, können alternativ auch die althergebrachten Logging- und Reporting-Dienste des “WatchGuard System Managers” auf einem Windows Server verwendet werden. Interessant in diesem Zusammenhang ist auch folgender HOWTO Artikel, der die Bereitstellung eines “WatchGuard Dimension Servers auf einem kostengünstigen Intel NUC (Mini-PC) beschreibt.
Wenn eine WatchGuard Firebox / XTM an einen Logging Server angeschlossen und dieser korrekt konfiguriert ist, können für viele unterschiedliche Ereignisse auf der Firewall Notifications (Benachrichtigungen) erzeugt und per E-Mail an den Firewall-Administrator oder einen Support-Alias verschickt werden. Wichtig: Der Versand der Notification E-Mails erfolgt vom Logging Server aus – die Firewall liefert über das laufende Logging lediglich das Triggersignal dazu!
Ein solches Ereignis kann die Unterbrechung eines BOVPN-Tunnels sein. Die Benachrichtigungs-Option kann nur global für alle BOVPN-Tunnel ein- bzw. ausgeschaltet werden: Policy Manager > VPN > VPN Settings > BOVPN Notification:
Dieser Artikel wurde erstmals am 13.01.2009 im „Technischen WatchGuard-Blog von Bernd Och“ veröffentlicht. Hierher verschoben und aktualisiert in 2016.
