Category Archives: Technischer Blog

SSL VPN Probleme nach Update von 11.1 auf 11.2

1 Comment

In einem aktuellen Supportfall hatte der Kunde seine Firebox X550e von Fireware XTM v11.1 auf 11.2 upgedated. Anschließend konnten die mobilen User über den WatchGuard SSL VPN Client 11.1 keine Verbindung mehr herstellen. Fehlermeldung: “Could not download the configuration file…”.
Ich vermute einen Zusammenhang mit der fehlerhaften Migration der integrierten WatchGuard-eigenen SSL-Zertifikate. Neben den gültigen SSLVPN-Zertifikaten (“Signed”) befinden sich im Zertifikatsspeicher noch weitere Zertifikate im Status “Pending”, die offenbar die gültigen Zertifikate behindern.

Die “Pending” Zertifikate können wie folgt gelöscht werden: Per WSM mit der Firebox verbinden, den Firebox System Manager starten, dort View > Certificates, Pending-Zertifikate anklicken und “Delete”. Anschließend Reboot der Firebox. Handelt es sich um einen Cluster, müssen beide Boxen zur gleichen Zeit ausgeschaltet werden!

Probleme mit self-signed Zertifikaten beim Update auf 11.2

Comment

Mir ist es heute zum zweiten Mal passiert, dass nach dem Update einer Firebox X Core bzw. X Peak von Fireware (Pro) 10.2.x auf Fireware XTM v11.2 zwar die Firewall/VPN-Funktionalität da war, die Box jedoch über den WatchGuard System Manager (WSM) nicht mehr ansprechbar war.

In beiden Fällen führe ich das Problem auf das Vorhandensein bzw. die Nutzung eines selbst generierten 3rd Party Zertifikats für die SSL-geschützte Web Authentication Page (Port 4100) zurück. Die Zertifikate waren jeweils von einer eigenen Active Directory-integrierten Zertifizierungsstelle erzeugt worden, damit beim Laden der Firewall-Anmeldeseite auf den Domänen-Mitglieds-PCs die Warnmeldung des Browsers nicht angezeigt wird. Unter Fireware (Pro) 10.2.x hatte dies auch die ganze Zeit problemlos funktioniert.

Beim ersten Fall vor ca. 2 Wochen stand ich sehr unter Zeitdruck (Downtime…) und habe zur schnellen Problemlösung die Brachialmethode gewählt: Factory Default Reset über das Command Line Interface (CLI) [PuTTY/SSH auf Port 4118 der Firebox, Anmeldung als User “admin” mit der Configuration Passphrase (dem “schreibenden Kennwort”)] und Eingabe des Kommandozeilen-Befehls “restore factory-default”. Hierdurch werden u.a. die Firewall-Kennwörter auf die Fireware XTM v11.x Defaults “readwrite” (für den User “admin” bzw. die Configuration Passphrase) und “readonly” (für den User “status” bzw. die Status Passphrase) zurückgesetzt… Anschließend dann das übliche Spiel: Durchklicken des Quick Setup Wizard, Verbinden per WSM, Öffnen des Policy Managers, Laden der letzten funktionierenden Konfigurationsdatei, Ändern der Einstellungen für das Web Server Certificate und “Save to Firebox”…

Heute konnte ich ein paar Minuten Zeit mehr investieren und habe dabei herausgefunden, dass es offenbar auch ausreicht, auf Kommandozeilenebene die Befehle “configure” und “web-server-cert default” auszuführen – also anstelle des 3rd Party Zertifikats das eingebaute Original-WatchGuard-Zertifikat auszuwählen. Anschließend konnte ich auch sofort wieder per WSM auf die Box zugreifen… Interessanterweise konnte ich anschließend im Policy Manager sogar wieder das 3rd Party Zertifikat auswählen und problemlos wieder aktivieren… Das Problem tritt also offenbar nur genau im Moment des Software Upgrades von 10.2.x auf 11.2 auf. Ich werde mir also angewöhnen, bei Migrationen künftig vorsorglich über Setup > Authentication > Web Server Certificate zunächst das Original-WatchGuard-Zertifikat auszuwählen und erst nach der Migration wieder das 3rd Party Zertifikat zu aktivieren…

Menü unvollständig im Policy Manager

Comment

Ein Kunde berichtete heute, dass nach der Einrichtung von WSM 11.2 auf einer frischen virtuellen Maschine im Policy Manager einige (Unter-)Menüs unvollständig angezeigt werden. So würden zum Beispiel unter Setup > Authentication > Authentication Settings die Felder für SSO (Single Sign On) überhaupt nicht angezeigt…

…die auf seinem alten System aber da gewesen wären:

Des Rätsels Lösung ist ein einfaches Grafikproblem: Die Bildschirmauflösung der virtuellen Maschine war auf 1024×768 eingestellt – und bei dieser “geringen” Auflösung werden umfangreiche Menüs eben unvollständig dargestellt. Abhilfe schafft hier entweder das Verbreitern des Pop-Up-Fensters, so dass durch geänderten Zeilenumbruch (weniger Zeilen) mehr “Platz” in der Vertikalen entsteht – oder aber einfach das Hochsetzen der Bildschirmauflösung auf 1280×1024 oder darüber…

Zeitgesteuerter PPPoE Reconnect oder Reboot bei 11.2

2 Comments

Die Fireware XTM v11.2 stellt für alle Plattformen ein neues Feature bereit, das speziell für den deutschen Markt mit seiner berühmten 24 Stunden DSL-Zwangstrennung interessant ist. Wenn ein External Interface auf PPPoE eingestellt ist, kann über Network > Configuration > [External] > Configure > Advanced Properties (Button ganz unten) ein täglicher PPPoE Reconnect zu einer bestimmten Uhrzeit ausgelöst werden.

Legt man diesen Zeitpunkt in eine betriebsarme Zeit (Nacht), kann man bei sonst stabiler DSL-Verbindung dadurch verhindern, dass durch eine eventuell sonst tagsüber erfolgende DSL-Zwangstrennung eine kurzzeitige Betriebsunterbrechung erfolgt.
In diesem Zusammenhang: auch bei dem Tarif T-DSL Business mit fester IP-Adresse erfolgt alle 24 Stunden eine Zwangstrennung. Bei der sofort danach erfolgenden Wieder-Einwahl wird lediglich nur wieder die gleiche IP-Adresse zugewiesen!

Alternativ dazu gibt es auch die Möglichkeit, einen zeitgesteuerten Reboot der gesamten Firewall durchzuführen – zum Beispiel einmal pro Woche. Dies ist interessant, weil dadurch regelmäßig wieder ein sauberer Ausgangszustand hergestellt wird und eventuelle Memory Leaks nicht dazu führen, dass die Firebox nach sehr langen Laufzeiten ggfs. instabil wird. Dieses Feature befindet sich unter Setup > Global Settings:

Vorsicht bei Leerzeichen im Namen von IPSec Phase 2 Proposals

Comment

Bei einer Migration einer WatchGuard Firebox X Peak X5500e von einer 10.2.x Version auf die Version 11.2 ist es mir die Tage passiert, dass plötzlich etwa die Hälfte der vorher ca. 40 BOVPN-Tunnel nicht mehr vorhanden war und im WSM / Firebox System Manager auch nicht mehr angezeigt wurde. Und zwar wurden nur noch die Tunnel angezeigt, deren Tunnel-Name alphabetisch aufsteigend von A bis zu einem bestimmten Buchstaben ging…
Die Fehlersuche führte natürlich sofort zu einem Vergleich des letzten noch angezeigten und des ersten nicht mehr angezeigten Tunnels. Dabei stellte sich als Besonderheit heraus, dass der Name des Phase 2 Proposals im ersten nicht mehr angezeigten VPN-Tunnel ein Leerzeichen enthielt! Nach dem Ersetzen des Leerzeichens durch ein “-” (Minus) und erneutem Speichern der Konfigurationsdatei waren dann auch alle VPN-Tunnel wieder da…

Vorsicht bei “Deny” Firewall Rules auf der X Edge!

Comment

Durch die Migration einer Firebox X Edge von der Version 10 auf die neue Fireware XTM v11.x ändert sich unter anderem auch die Reihenfolge, in der die Firewallregeln ausgeführt werden. Unter Version 10 war es kein Problem, bei Firewall > Outgoing die nicht benötigten Services auf “Deny” (roter Hintergrund) zu setzen, solange z.B. die “Outgoing”-Regel selbst auf “Allow” (grüner Hintergrund) stand.

Bei Fireware XTM v11.x ist es anders. Dies zeigt dieser Supportfall: Kunde führt ein Update einer X Edge mit 10-er Software auf Fireware XTM v11.x durch. Das Update läuft erfolgreich durch. Anschließend ist plötzlich kein HTTP-Zugriff mehr auf das Internet möglich. Beim Versuch, auf das Webinterface der X Edge (neu, Port 8080) zuzugreifen, erscheint die Meldung, dass hierfür zunächst der Adobe Flash Player heruntergeladen und installiert werden müsse. Dumm gelaufen, HTTP funktioniert ja gerade eben nicht… Gut, wenn noch ein weiterer PC lokal vorhanden ist, auf dem schon Flash installiert ist und man von diesem PC aus auf das Webinterface der X Edge zugreifen kann – oder wenn vor der Migration eine Remote Access Regel für Port 8080 (Firewall > Incoming) angelegt wurde, die einem externen Supporter Zugang zu dem Gerät ermöglicht… 😉 Dieser konnte so die “Deny”-Regel für HTTP aus dem Regelwerk löschen, die nun “weiter oben” saß und dadurch den kompletten HTTP-Verkehr verhinderte.

Meine Empfehlung: Prüfen Sie vor der Migration einer X Edge von Version 10 auf Fireware XTM v11.x, ob es Firewallregeln gibt, die auf “Deny” stehen (roter Hintergrund). Wenn es hierfür keinen dringenden Grund gibt, sollten Sie diese Regeln auf “No Rule” setzen (grauer Hintergrund). Nach der Migration wird das Regelwerk wesentlich anschaulicher dargestellt und Sonderregelungen können hier viel einfacher eingebaut werden.

Created session list ”fwusers” entry for…

Comment

Nach dem Update auf die aktuelle Version Fireware XTM v11.2 erscheinen bisweilen im Traffic Monitor im Sekundenabstand Einträge

kernel xt_session: Created session list “fwusers” entry for [IP]

Hierbei handelt es sich um eine Diagnosemeldung, die keinerlei Bedeutung hat. Der Bug besteht lediglich darin, dass die Meldung nicht unterdrückt wird. Der Status für dieses Verhalten steht auf “resolved in future release”.

SSL-VPN Client 11 läuft nicht in Verbindung mit Fireware 10.x

Comment

Es freut mich sehr, dass mein Blog eine ansehnliche Zahl von WatchGuard-Usern erreicht. Sinn und Zweck dieser Institution ist natürlich auch, meine eigene Expertise in diesem Umfeld darzustellen und auf diese Weise konstruktive Kundenkontakte anzubahnen – unbestritten! Umsonst ist der Tod, und der kostet bekanntlich das Leben! Es entsteht jedoch auch ein interessanter Dialog, wie sich an diesem Beitrag von Michael Schramm zeigt, der mich per E-Mail erreicht hat und den ich hier gerne wiedergeben möchte – ungeprüft, da ich genau die beschriebene Konstellation noch nicht “vor der Flinte” hatte :-). Michael Schramm schreibt:

“Der aktuelle WatchGuard SSLVPN-Client in der Version 11.1 funktioniert nicht mit einer 10er-Fireware. Dies ist leider in den Release Notes nirgends erwähnt – jedenfalls konnte ich keinen entsprechenden Hinweis finden. Öffnet man den Client direkt mit einem passenden Configfile (*.wgssl), erscheint beim Connecten eine irreführende Fehlermeldung: Die Softwareversion auf dem Gerät (1.x) ist kleiner als die Version des Clients (5.x), und man soll auf Yes klicken, um die neue Softwareversion herunterzuladen. Das klappt natürlich nicht und der Client springt dann nach einiger Zeit wieder zurück zur Login-Maske. Der automatische Download des Config-Files funktioniert ebenfalls nicht, da sich in der Fireware XTM 11.x offensichtlich der Pfad zu diesem File geändert hat. Der 11er-Client fragt bei der Firebox nach dem File

https://FIREBOX:4100/?action=sslvpn_download&fw_username=USERNAME&fw_password=PASSWORD&filename=client.wgssl

und bekommt daraufhin von der Firebox “401 unauthorized” zurück (im Logfile des Clients: FAILED, Access denied), während der alte 10er-Client nach diesem File fragt:

https://FIREBOX:4100/?action=sslvpn_download&username=USERNAME&password=PASSWORD&filename=client.wgssl

und dieses dann auch bekommt – man kann es sogar manuell mit einem Browser herunterladen. Das “fw_” vor Username und Password gab es also in der alten Version noch nicht.

Allen Benutzern, die also unter Windows 7 Probleme mit dem 10er-Client haben und deswegen den 11er-Client benutzen wollen, kann von dieser Idee nur abgeraten werden, solange auf der WatchGuard Firebox noch eine Fireware 10.x läuft.

Der 10er-Client funktioniert im übrigen bei mir unter Windows 7, nativ und ohne Kompatibilitätsmodus, einwandfrei! Falls es also mit dem 10er-Client unter Windows 7 zu Problemen kommt, liegt das schätzungsweise eher an etwas anderem. Ich hatte z.B. konkret das Problem, dass sich der Client immer nur sporadisch und völlig ohne erkennbares Muster connecten ließ. Des Rätsels Lösung war ein falsch konfigurierter Switchport für das entsprechende WAN-Interface auf der Secondary Firebox [Anm. BO: in einem Cluster!]. Die Ports auf beiden Fireboxen stehen auf 100FDx, der entsprechende Switchport stand auf Auto und hat sich dann immer auf 100HDx eingependelt. Deswegen konnte ich mich immer dann nicht verbinden, wenn gerade die Secondary Firebox die aktive war…”

Soweit Michael Schramm! Vielen Dank für diesen konstruktiven Beitrag. Ergänzend zum letzten Absatz von mir noch einmal der Hinweis auf einen meiner früheren Beiträge: http://de.watchguard-blog.com/2008/12/verbindungsprobleme-wegen-ethernet.html: Lassen Sie möglichst ALLE Interfaces der WatchGuard Firebox auf “Auto Sensing” – und sorgen Sie NUR bei offensichtlichen Kompatibilitätsproblemen zunächst dafür, dass das direkt an der WatchGuard Firebox angeschlossene Ethernet-Device (Switch/Router) auf einen festen Wert eingestellt wird…

Probleme mit HTTP Proxy unter Fireware XTM 11.1

1 Comment

In ein paar Fireware XTM 11.1-Installationen habe ich aktuell das Problem, dass Traffic durch eine HTTP-Proxy Regel gar nicht oder nicht zu allen Zielen funktioniert, während ein HTTP-Paketfilter und andere paketfilter-basierte Services (z.B. ping/ICMP) einwandfrei funktionieren. Für alle proxy-basierten Services ist der Prozess wkrcfm-1 zuständig. Prüfen Sie über den Status Report, ob dieser Prozess korrekt läuft. Sollten Sie in Ihrer Konfiguration einen POP3-Proxy verwenden, sollten Sie diesen vorübergehend durch ein POP3-Paketfilter ersetzen, sofern Ihre Sicherheitsrichtlinie bezüglich E-Mail Sicherheit dies zulässt (in Verbindung mit einem POP3-Paketfilter kann kein Gateway Antivirus/IPS und Tagging durch spamBlocker verwendet werden). Wenn Sie auf den POP3-Proxy angewiesen sind, öffnen Sie ein Support Incident auf der WatchGuard Website.

[12.02.2010]: Dieser Bug steht in der Version 11.2 auf fixed!
.

Downloads von der Microsoft Website brechen ab

Comment

In einem aktuellen Supportfall berichtete ein Kunde mit einer X550e und Fireware XTM 11.0.2, dass regelmäßig große Downloads von der Microsoft Website abbrechen würden. Dies aber nur, wenn eine HTTP-Proxy Regel verwendet würde. Mit einer HTTP-Filter Regel würde der Download erfolgreich abschließen.

Die genauere Untersuchung in diesem Fall zeigte auf, dass im Rahmen der UTM Services auch Intrusion Prevention aktiviert war. Ich konnte im Traffic Monitor mitverfolgen, dass in den Downloads die Endeavor IPS Signatur ED-49005 (FILE.CUE.VideoLANVLC.Buffer.Overflow) erkannt worden ist. Ob die Downloads nun tatsächlich dieser Anfälligkeit unterliegen oder ob es sich um ein so genanntes “False Positive” handelt, habe ich nicht weiter untersucht. In Abstimmung mit dem Kunden habe ich zunächst *.microsoft.com im HTTP-Proxy als HTTP Proxy Exception eingetragen.