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

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

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!
.

Blocked Ports List

Vor ein paar Tagen kam eine Supportanfrage herein, weil eine statische NAT-Regel (eingehend) nicht funktionieren würde, die auf den Port 8000 eines bestimmten internen Servers zielte. Im internen Netz antwortete der Server aber völlig korrekt auf Port 8000 und auch das Routing war in Ordnung.
Die Lösung fand sich im Untermenü Setup > Default Threat Protection > Blocked Ports... Per Default läßt die WatchGuard Firebox keine eingehenden Verbindungen auf den Ports 1, 111, 513, 514, 2049, 6000, 6001, 6002, 6003, 6004, 6005, 7100 und 8000 zu. Diese Liste kann jedoch manuell angepasst werden.