Category Archives: Technischer Blog

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.

Fehler -10 bei Update mit edge_11_1.exe

Comment

Um eine WatchGuard Firebox X Edge mit 10-er Software auf die aktuelle Fireware XTM 11.1 upzudaten und dabei die bisherige Konfiguration beizubehalten, muss die X Edge zunächst auf 10.2.9 oder höher upgedatet werden. Anschließend wird der Install Wizard edge_11_1.exe ausgeführt, am besten von einem PC aus, der am Trusted oder Optional Interface angeschlossen ist (also “lokal”). Der Wizard fragt zunächst nach der IP-Adresse der X Edge und den bisherigen Zugangsdaten (Username/Password). Außerdem wird nach den “neuen” Firewall-Kennwörtern gefragt, die Sie vergeben wollen – die Status Passphrase (das “lesende Kennwort”) und die Configuration Passphrase (das “schreibende Kennwort”), so wie sie auch von den größeren Gerätefamilien X Core und X Peak in Verbindung mit dem WatchGuard System Manager (WSM) bekannt sind. Danach läuft der Wizard los. Wenn alles gut geht, bootet die X Edge nach ca. 5 Minuten und am Bildschirm erscheint eine Erfolgsmeldung.

In einer Installation bekam ich aber vorher eine Fehlermeldung angezeigt und das Update wurde abgebrochen. Auch ein erneuter Aufruf der edge_11_1.exe scheiterte mit der gleichen Fehlermeldung: “Error installing utm_edge.sysa-dl (error = -10)”.

Abhilfe schaffte hier ein Reboot der X Edge. Anschließend lief edge_11_1.exe erfolgreich durch. Offenbar braucht der Update Wizard auf der X Edge “Platz” zum Arbeiten, der eventuell im längerfristigen Dauerbetrieb von temporären Dateien o.ä. belegt wird. Ich empfehle also nun immer ein Reboot der X Edge, bevor der Update Wizard gestartet wird!

Bitte denken Sie daran, dass nach dem Update auf die 11-er Version das Webinterface jetzt auf Port 8080 liegt und nicht mehr auf Port 443. Sie müssen daher gerade bei Remote Administration auch diesen Port ggfs. von außen berücksichtigen – am besten BEVOR Sie das Update durchführen 🙂 Generell empfehle ich Besitzern einer X Edge jedoch, sich mit den neuen Möglichkeiten der Administration durch den WatchGuard System Manager (WSM) vertraut zu machen. Erst hiermit blüht Ihre X Edge zur vollen Leistungsfähigkeit auf!

Bugfixes in WatchGuard WSM und Fireware XTM 11.1

Comment

Die Versionen Fireware XTM v11.1 und WSM v11.1 beheben eine Reihe von Bugs und Known Issues früherer Versionen. Diese Aufstellung wurde den aktuellen Release Notes der Version 11.1 entnommen. Obwohl man aufgrund der Vielzahl eventuell auf den Gedanken kommen könnte, dass das Produkt sehr fehlerlastig ist (bzw. war), sehe ich diese offene Kommunikation hingegen sehr positiv. Die meisten anderen Hersteller geben kaum vergleichbare Informationen heraus, sondern werkeln eher im Hintergrund. Zudem zeigt sich, dass das Produkt “lebt” und intensiv weiterentwickelt wird. Auch schon in den Versionen 11.0.1 und 11.0.2 war das Produkt ausreichend stabil, auch wenn ich meinen Kunden anfangs eher zur Zurückhaltung geraten habe!

General

  • The WSM Quick Setup Wizard now allows you to enter a feature key that contains a model upgrade for Edge e-Series. [40405]

  • Fireware XTM v11.1 resolves a cross site scripting vulnerability found in the web server used with the authentication applet. [40332]

  • Fireware XTM v11.1 resolves a cross site scripting vulnerability found in the WatchGuard servers’ Apache HTTP server implementation. [40581]

  • The lighttpd version used by Fireware XTM has been upgraded to v1.4.22 to resolve several reported vulnerabilities. [38808]

  • The ISC DHCP server version has been upgraded to v4.1.0p1 to resolve several reported vulnerabilities. [40032]

  • HostWatch now shows VLAN traffic. [40401]

  • You can now right-click in Firebox System Manager > Traffic Monitor to add an IP address to the blocked sites list. [40488]

  • ServiceWatch now correctly displays bandwidth for auto-generated BOVPN policies created by the WatchGuard Management Server. [40364]

Authentication

  • The Authentication redirect feature now works when you use a wireless guest network on the Firebox X Edge e-Series. [40029]

  • This release resolves an issue that causes Active Directory authentication to fail with the following log message: user=”test1″ domain=TESTQAWIN2K30. [40786]

Proxies

  • You can now enable notification for Application Blocker. [40422]

  • Application Blocker has been enhanced to add support for Winny, a popular peer to peer application used in Japan. [35027]

  • You can now unlock a file with an “&” in the file name with the unlock.exe utility. [40718]

  • This release resolves several reported issues in which certain web applications did not work through the HTTP Proxy. [40293] [38121] [40392]

  • This release resolves an issue that caused FTP proxy traffic to stop after a multi-WAN failover. [37965]

Subscription Services

  • Subscription services now update when you use an internal HTTP proxy server. [40517]

  • WebBlocker override now works on Firebox X e-Series devices configured in Bridge Mode. [39283]

  • The Quarantine Server client now accepts firstname.lastname@domain.com email format. [39743]

Networking

  • You can now use either Policy Manager or the Web UI to add multicast addresses in a policy. [39947, 39948]

  • If you enable a network interface and change the Interface Name (Alias) at the same time you enable the interface, the interface now becomes active without the need for a reboot.[39815]

  • When you use multi-WAN, DNS servers with static IP addresses on WAN 1 are now used even when other external interfaces use DNS servers from an ISP through PPPoE or DHCP. [40322]

  • DHCP relay through a branch office VPN tunnel now works. [40844]

  • You can now change the MTU of an external interface configured with PPPoE. [40705]

  • The DHCP server now works when there are multiple VLANs in the configuration. [40556]

  • Server Load Balancing now works when the internal server IP addresses are on different subnets. [41041]

  • We have made enhancements to the Server Load Balancing server status detection mechanism. [40300] [40519]

  • The Server Load Balancing Stickiness function has been improved to maintain a sticky connection state until the idle timeout is reached. [40297]

  • Static MAC address binding now works when your device is configured in Bridge Mode. [40665]

  • This release resolves an issue that prevented some Windows computers from getting an IP address via DHCP when your device is configured in Drop-In Mode. [40184]

  • The Blocked Ports and Blocked Sites features now apply only to traffic on an external interface. [39918]

Multi-WAN

  • Several multi-WAN issues related to PPPoE and branch office and Mobile VPN have been resolved. [40007]

  • Multi-WAN now works when the source IP address for incoming traffic is on the same network subnet as one of the external interfaces of the Firebox. [41026]

  • This release resolves an issue that caused the external interfaces to become inactive when you used multi-WAN configured in Round-robin mode. [40357]

FireCluster

  • Firebox devices with a model upgrade in the feature key can now join a FireCluster. [39370]

Branch Office VPN

  • The choice of Any has been removed from the Tunnel Route Settings Local and Remote drop-down menu. The Web UI now shows “any (0.0.0.0/0)”. [40409]

  • This release resolves an issue that caused the IKED process to crash and all IPSec tunnels to fail. [40442]

Mobile VPN

  • The Windows SSL VPN client has been updated to support Windows 7 and Windows 64-bit operating systems. [39841]

  • This release resolves an issue that caused SSL VPN to fail to connect after an upgrade from v10.2.x to v11.0.x. When this problem occurred, the SSL VPN client logs showed: sslvpn State: initialization of prerequisites Debug. [40408]

  • This release resolves several reported vulnerabilities in the SSL VPN client for Mac. [40292]

  • Mobile VPN with PPTP and SSL now continue to work when the LiveSecurity subscription is expired in your Firebox feature key. [41045]

  • When you disconnect the Mobile VPN with SSL client from one Firebox and then connect to a different Firebox, the SSL VPN profile is now updated to show the new connection. [41052]

  • The Mobile VPN with IPSec v11.1 client supports Windows 7 (32-bit and 64-bit) and contains additional bug fixes.

Web UI

  • You can now export your device configuration with the Web UI. [35234]

  • The Web UI now prevents the use of custom SSL VPN ports that conflict with ports used by the Firebox. [39382]

Policy Manager

  • The Firebox no longer becomes unresponsive if you use more than 28 characters in a proxy policy name. [40679]

  • The alias “Firebox” is now treated the same as other aliases the Firebox determines policy precedence. [38891]

Management Server

  • When a Firebox is in Full Management Mode and you clear the Enable TCP Syn Checking check box, TCP Syn Checking is now correctly disabled. [40853]

  • When a Firebox is under centralized management, an update from the WatchGuard Management Server no longer overwrites any blocked sites configured manually on the Firebox. [40312]

  • You can now right-click on a device and add that device to a folder. [36077]

  • The ability to schedule a reboot time is now available from the Management Server. [38230]

  • You can now perform a mass update of managed devices to force all selected appliances to check for a configuration update. [36958]

  • The Management Server now sorts the IPSec-action-list and abs-ipsec-action-list for tunnels created by the Management Server. The IPSec actions for Manual BOVPN tunnels are left in the order sorted by the user. Manual tunnels are always placed at the top of the list, followed by the sorted list of the tunnels created by the Management Server.

  • For each firewall policy template in use, there is now a single firewall policy created in the appliance configuration. As an example, if you have three tunnels (to different endpoints) that all use the same firewall policy template, there is a single firewall policy with the attributes set in the template. If there are two firewall policy templates in use, then two firewall policies are created. [38877]

Report Server

  • If you use an IIS server to serve published reports, you no longer get an error about missing files. [39319]

Log Server

  • The performance of the LogViewer Search function has been improved in v11.1. To facilitate the performance improvements, a log database migration will occur when you upgrade from v11.0.x to v11.1. During the migration, all log messages generated for a particular device are not visible until the migration is finished. [38833]

Certificates

  • You can now import a CRL in DER format into Firebox System Manager. [36643]

  • This release resolves a memory leak that occurred when you used 3rd-party certificates on the Firebox and kept WatchGuard System Manager or Firebox System Manager connected. [41008]

  • WatchGuard System Manager and Firebox System Manager no longer display the certificates status as valid even if a certificate is invalid. [40378]