Tag Archives: Fireware

IKE Keep Alive und Dead Peer Detection (DPD)

Die Kernaussage vorweg: Steigern Sie die Stabilität Ihrer BOVPN Tunnel, indem Sie IKE Keep Alive –ODER– Dead Peer Detection (DPD) verwenden – aber nicht beides zusammen!

Branch Office VPN Tunnel sind im Regelfall darauf ausgerichtet, möglichst 24 Stunden am Tag voll verfügbar zu sein (always on). Brechen Tunnel weg, liegt es meist an:

  • Ein oder beide Endpunkte haben eine instabile Internet-Anbindung, hohe Latenzzeiten oder Paketverluste. In meinem Artikel Verbindungsprobleme wegen Ethernet Collisions bin ich darauf bereits einmal eingegangen.
  • Veraltete Software-Stände oder Kompatibilitäts-Probleme (möglichst immer die aktuelle Software-Version einsetzen, sowohl auf WatchGuard Firebox Produkten als auch auf VPN Devices von Fremdherstellern).
  • Kein Traffic im VPN-Tunnel. Tunnel ohne Traffic tendieren dazu, instabil zu werden.

Die WatchGuard Fireboxen kennen mehrere Verfahren, die zur Stabilität von VPN-Tunneln beitragen: IKE Keep Alive, Dead Peer Detection – und bei der X Edge Serie zusätzlich noch VPN Keep Alive.

IKE Keep Alive sollte nur eingesetzt werden, wenn auf beiden Enden des VPN-Tunnels WatchGuard Produkte stehen!
Dead Peer Detection (DPD) hingegen ist ein Industriestandard (RFC3706), der von den meisten IPSec Devices unterstützt wird. Die aktuellen Default Einstellungen sollten auch verwendet werden: NAT-Traversal (aktiv), 20 Sekunden. Bei Nutzung von IKE Keep Alive: 30 Sekunden, max. 5 Failures. Bei Nutzung von DPD: 20 Sekunden, max. 5 Versuche. Verwenden Sie IKE Keep Alive und DPD NICHT GLEICHZEITIG, dies bewirkt genau das Gegenteil: Wenn beide Verfahren aktiviert sind und ein Verfahren eine Phase 1 Renegotiation auslöst, erkennt das andere Verfahren den Tunnel als down und startet seinerseits eine zweite Phase 1. So entsteht ein Konflikt mit der gerade zuvor ausgehandelten Phase 1…

Auf der X Edge gibt es alternativ noch VPN Keep Alive (VPN > VPN Keep Alive). Hier kann pro Tunnel eine IP-Adresse eines Hosts auf der anderen Seite des Tunnels eingetragen werden, der 24/7 läuft und auf ping antwortet (z.B. ein Server, ein managebarer Switch oder ersatzweise die IP-Adresse des Trusted Interface der dortigen Firewall bzw. VPN-Komponente):

Es wird empfohlen, sich jedoch nur auf EIN Verfahren zu beschränken!

Funktionsweise des WatchGuard Firebox Regelwerks

Die WatchGuard Firewall prüft jede neu anstehende Verbindung von einem Host auf der einen Seite der Firewall zu einem Host auf der anderen Seite der Firewall. Dabei werden zunächst die Header der IP-Pakete untersucht: Quell-IP-Adresse, Ziel-IP-Adresse, Quell-Port, Ziel-Port, verwendetes Protokoll (TCP, UDP, ICMP etc.). Die Firewall durchforstet nun das Regelwerk sequentiell “von oben nach unten” (wenn man sich in der Standard-Listenansicht des Policy Managers befindet).
Nacheinander wird jede einzelne Regel geprüft, ob sie die o.g. Kriterien erfüllt – so lange bis der erste “Treffer” gefunden wird. Nur diese Regel wird auch ausgeführt. Gibt es “weiter hinten” im Regelwerk eine andere Regel, auf die ebenfalls die o.g. Kriterien zutreffen, wird diese niemals erreicht/ausgeführt. Wird eine passende Regel gefunden, wird die Verbindung authentisiert und (bei TCP) in die TCP Session Table der Firewall eingetragen. Nachfolgende Pakete in der gleichen TCP-Verbindung werden dann automatisch von der Firewall durchgelassen und nicht noch einmal aufs Neue authentisiert (anders bei Application Proxy Regeln, die eine zusätzliche Kontrolle des Inhalts vornehmen).

Ganz am Ende des Regelwerks steht eine unsichtbare Deny Regel. Jeder Datenverkehr, der nicht ausdrücklich durch eine Firewall-Regel zugelassen wird, wird von dieser Default Deny-Regel ABGELEHNT. Je nachdem, ob der Verbindungsaufbau von innen oder von außen erfolgen sollte, erscheint im Traffic Monitor und im Logfile ein Unhandled Internal Packet oder ein Unhandled External Packet.

Warum werden die Unhandled Packets angezeigt?

Weil im Policy Manager bei Setup > Default Threat Protection > Deafult Packet Handling > Logging das Häkchen “Send Log message” bei den Kategorien “Unhandled Internal Packet” und “Unhandled External Packet” gesetzt ist. Das Logging könnte zwar durch Entfernen des Häkchens ausgeschaltet werden – das ist aber keine gute Idee (bessere Idee weiter unten :-). Der Traffic Monitor und die Unhandled Packets sind ein extrem wichtiges und hochinteressantes Tool, um Fehlverhalten von Maschinen bzw. Fehlkonfigurationen im lokalen Netzwerk aufzudecken und abzustellen! Die Anzeige der Denied Packets kann der Administrator auch sehr gut nutzen, um den Bedarf für neue Regeln zu erkennen und wie diese auszusehen haben.

Das Default Regelwerk und die globale Outgoing-Regel

Der Quick Setup Wizard erzeugt bei der Ersteinrichtung der WatchGuard Firebox ein kleines Default Regelwerk, das im Prinzip sämtlichen TCP- und UDP-Verkehr sowie Ping in ausgehende Richtung (outgoing) zulässt – und sämtlichen eingehenden Verkehr (incoming) verbietet.
Gewissenhafte Administratoren wollen jedoch genau definieren, welcher ausgehende Datenverkehr zulässig ist und diesen auf Maschinen- und/oder User-Ebene auf das absolute Minimum beschränken. Neue Firewall-Regeln werden ins Regelwerk aufgenommen und so weit wie möglich einschränkt. Ein gutes Firewall-Regelwerk wächst dadurch auf 20-30 Regeln, teilweise aber auch auf 80-100 Regeln an. Das schöne feingliedrige Regelwerk wird aber nur dann wie beabsichtigt funktionieren, wenn die defaultmäßig vorhandene Outgoing-Regel auf disabled gesetzt oder ganz gelöscht wird. Denn: das Regelwerk wird “von oben nach unten” abgearbeitet, der erste Treffer zählt. Solange “unten” die globale Outgoing-Regel steht, nützen die Einschränkungen weiter “oben” nichts. Der Verkehr würde trotzdem über die Outgoing-Regel rausgehen, also weg damit!

Anzeige von bestimmten Unhandled Packets unterdrücken

Bisweilen ärgert man sich doch über die Anzeige von Unhandled Packets. Eventuell kann man die Ursache dafür einfach nicht abstellen usw. Bei der Lösung hilft nun das bisher Gesagte: das unzulässige Paket erzeugt eben ein Unhandled Packet, weil es eben keine explizite Regel für diesen Verkehr gibt. Das Paket bleibt an der unsichtbaren Deny Regel ganz am Ende des Regelwerks hängen.
Der Trick besteht nun einfach darin, eine explizite Firewall-Regel zu bauen, die den Verkehr genau beschreibt (siehe oben: Quell-IP, Ziel-IP, Quell-Port, Ziel-Port, Protokoll), aber verbietet (“Denied”) – und das Logging ausschaltet. Der lästige Verkehr taucht künftig nicht mehr im Traffic Monitor und im Logfile auf. Im Regelwerk werden Deny-Regeln mit einem roten X angezeigt:

Konfigurationsbeispiel: HostWatch Namensauflösung (Port 137/udp) unterdrücken

Properties > Logging

Eine Denied-Regel verankert sich im Regelwerk automatisch OBERHALB einer Allow-Regel für den gleichen Port bzw. das gleiche Protokoll, wird also zeitlich gesehen früher geprüft. Das kennen wir: ein explizites Verbot ist mächtiger als eine nicht erfolgte Erlaubnis. Ich nutze die Kombinationsmöglichkeit aus Denied- und Allow-Regeln auch ganz gerne so: Ping.Allow von Any nach Any -und- Ping.Denied von Any-External nach Firebox. Damit kann innerhalb des lokalen Netzwerks/VPN fröhlich hin- und hergepingt werden – auf Pings aus dem Internet reagiert unsere Firebox jedoch nicht. Wenn’s stört, kann für die Denied-Regel natürlich auch das Logging ausgeschaltet werden…

Fireware Installer zweimal starten

Wenn eine neue Fireware-Version (z.B. 10.2.7) auf eine Windows Management Station installiert werden soll, auf der sich bereits eine etwas ältere Version (z.B. 10.2.6) befindet, erscheint nach dem Aufruf des (neuen) Fireware-Installers die Meldung “Do you want to completely remove the selected application and all of its features?”:

Diese Meldung verwundert zunächst: warum soll etwas deinstalliert werden – es soll doch etwas installiert werden… Antworten Sie mit JA! Nun wird zunächst die ältere Version deinstalliert! Rufen Sie anschließend den Fireware-Installer einfach ein zweites Mal auf. Erst dann wird die neue Fireware-Version tatsächlich installiert…

HA Cluster: “Peer Status is in-transition”

Beim Speichern einer neuen Konfiguration auf einen HA Cluster kommt es bisweilen zu dem Zustand Peer Status is in-transition anstelle des normalen “Peer Status is standby”. Zu diesem Verhalten kann es kommen, wenn während des Speicherns gerade mobile User über PPTP-VPN eingewählt sind.

[30.01.2009]: Laut Release Notes soll dies nun mit der Fireware 10.2.7 behoben sein.

WSM und Fireware 10.2.7 verfügbar

Die neuen Versionen WSM, Fireware und SSL-VPN-Client 10.2.7 stehen im Software Download Bereich der WatchGuard Website bereit. In den Release Notes sind als “Resolved Issues” die folgenden Bugs aufgeführt. Mit den meisten hatte ich auch schon persönlich Bekanntschaft geschlossen. Ich werde die neue Version in ein paar Minuten installieren und dann Anfang nächster Woche über meine Erfahrungen berichten.

  • This release resolves a kernel crash associated with branch office VPN and Mobile VPN with IPSec traffic through the Firebox X Core or Peak e-Series. [29491]
  • The Firebox no longer stops passing traffic when you save a configuration. [27821]
  • Policy Manager no longer prevents the entry of host ranges for 1-to-1 NAT on the BOVPN tunnel route settings page. [30010]
  • The Server Load Balancing feature in Fireware now correctly detects that a server is not responding and stops sending traffic to that server. [27276]
  • You can now apply QoS and a schedule when you create a VPN firewall policy template for managed BOVPN tunnels. [10270]
  • You should no longer see the error message “HTTP response code: 500 for URL https://x.x.x.x:4117/cmm/cmd” when you try to connect to WSM. [29336]
  • If there is an active Mobile VPN with PPTP tunnel connected to the Firebox during a configuration save, Firebox System Manager no longer shows the HA peer status as “in-transition.” [27557]
  • WSM and Firebox System Manager connections no longer fail after a configuration save to two Fireboxes configured in an HA configuration. [31990]
  • The Windows SSL VPN client no longer fails to install on Windows XP with a Runtime Error message. [31932]
  • The Windows SSL VPN client now operates correctly after a computer returns from sleep mode. [31523]

BOVPN Notification einschalten

Wenn die Firebox 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 Logging lediglich das Triggersignal dazu!

Ein solches Ereignis kann die Unterbrechung eines BOVPN-Tunnels sein. Die Benachrichtigungs-Option hierfür ist noch relativ neu. Sie kann nur global für alle BOVPN-Tunnel ein- bzw. ausgeschaltet werden: Policy Manager > VPN > VPN Settings > BOVPN Notification:

Kernel Crash bei Fireware 10.2.x

Im Zusammenhang mit meinem Posting “Upper Port Problem bald gelöst” vom 08.01.09 kam folgende Frage auf: “Wie kann man feststellen, ob/wann überhaupt ein Kernel Crash aufgetreten ist?” Hier die Antwort: Starten Sie den WatchGuard System Manager (WSM), verbinden Sie sich mit Ihrer Firebox und rufen Sie über Rechtsklick den Firebox System Manager auf. Gehen Sie dort auf die Registerkarte “Status Report” und scrollen Sie bis ganz unten. Endet die Anzeige mit

** Routing Protocol (BGP)
**
bgp is not enabled

liegt kein unmittelbarer Kernel Crash vor. Gibt es darunter jedoch noch ein paar Zeilen zum Thema VM Dump, dann sind ein oder mehrere Kernel Crashes aufgetreten:

**
** VM Dump
**
Found kernel crash, time of crash was Sun Jan 11 21:14:26 2009
Crash dump data recovered on Sun Jan 11 21:15:08 CET 2009
Crash dump data saved in /var/log/vmdump/vmdump.3.

In diesem Beispiel bedeutet die Ziffer 3 ganz zum Schluss, dass aktuell sogar vier Kernel Crashes in den internen Support Logfiles der WatchGuard Firebox protokolliert sind. Ein Kernel Crash löst anschließend einen Reboot der Firebox aus.

“Wie kann ich die internen Support Logfiles auslesen?”

Antwort: Ganz rechts unten in der Ecke des Status Reports (vgl. auch den o.g. Screenshot) findet sich ein Button “Support…”:

Mit Klick auf “Retrieve” kann man alle internen Logfiles in einer gemeinsamen Datei namens support.tgz auf die Windows Management-Station herunterladen. Dort kann sie z.B. mit Hilfe von WinZip oder WinRAR ausgepackt werden. Im Unterverzeichnis varlogvmdump finden sich im aktuellen Beispiel die Dateien vmdump.0, vmdump.1, vmdump.2 und vmdump.3 – jeweils mit Datum und Uhrzeit des tatsächlichen Kernel Crashes:

Da alle Uhrzeiten recht ähnlich sind, liegt ein Vergleich mit den Uhrzeiten der 24-stündigen T-DSL Zwangstrennung durch die Telekom nahe (adsl.log). Und siehe da: ja, passt. Im vorliegenden Beispiel steht die T-DSL-Zwangstrennung im direkten Zusammenhang mit den Kernel Crashes… 🙁

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…

XML-Konfigurationsdatei auf anderes Modell portieren

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.

Neue Software-Versionen

Die Version 10.2.4 soll am Montag, 17.11.08, amerikanischer Zeit zum Download über die WatchGuard-Website bereitgestellt werden. Hier soll sich speziell die Funktion Single Sign On bei Verwendung von User Authentication in Verbindung mit Active Directory verbessern. Bislang hatte der SSO Agent auf dem Domänencontroller Schwierigkeiten mit PCs, an denen mehrere wechselnde Benutzer arbeiten oder Dienstkonten genutzt werden (z.B. für Backup- oder Antivirus-Software). Mit 10.2.4 soll ein zusätzlicher Software-Client bereitgestellt werden, der – auf den PCs installiert – die Erkennung des aktiven Benutzerkontos für den Agent vereinfacht.
Vor Weihnachten soll dann noch eine Version 10.2.5 erscheinen, bevor dann Ende Januar mit dem nächsten Major Release Fireware 11 zu rechnen ist.