Tag Archives: Fireware 11

WatchGuard und Telekom VDSL 25, VDSL 50

In der Vergangenheit stellte die Deutsche Telekom VDSL nur in Verbindung mit dem TV-Paket “Entertain” zur Verfügung. Das hat sich geändert: Mittlerweile kann VDSL auch als reiner Hochgeschwindigkeits-Anschluss gebucht werden, als Call & Surf Comfort VDSL in zwei Geschwindigkeits-Varianten: VDSL 25 mit 25/5 Mbit und VDSL 50 mit 50/10 Mbit, jedoch nur mit dynamischer IP-Zuweisung (und ggfs. DYNDNS). Daher wird es künftig auch häufiger vorkommen, dass eine WatchGuard Firebox an einem VDSL-Anschluss betrieben werden soll. Bisher war die korrekte Konfiguration des dazugehörigen “External” Interfaces der WatchGuard eher umständlich, da das Interface als VLAN-Interface mit einem Tagging für die VLAN ID 7 konfiguriert werden musste. Mit Verfügbarkeit des Telekom Speedport 221 VDSL2 Modems entfällt dieser Umweg. Das VDSL-Modem übernimmt das VLAN-Tagging, so dass in der WatchGuard “nur noch” die üblichen PPPoE-Zugangsdaten hinterlegt werden müssen.
Wenn der VDSL-Zugang im Rahmen von “Multi-WAN” als “zusätzlicher” Anschluss für schnelles Surfen verwendet werden soll, beachten Sie bitte auch den folgenden Blog-Beitrag:http://de.watchguard-blog.com/2011/08/multi-wan-und-policy-based-routing.html

Verlust der Konfigurationsdatei beim Update von v10 auf v11.3.4

Mir ist es in den letzten Wochen selbst zweimal passiert, und auch ein Kunde hat übereinstimmend berichtet, dass beim Software-Update einer bestehenden X Core e-series (X550e, X750e, X1250e) von Softwareversion 10.2.x direkt auf Version 11.3.4 die Firebox anschließend eine “leere” Konfigurationsdatei hatte – genau so wie sie aus dem Setup Wizard mit durchbestätigten Default-Einstellungen heraus kommen würde.
Das Dumme dabei ist, dass sich auch die TCP/IP-Einstellungen der Interfaces auf Default zurückgesetzt haben: eth0=10.0.0.1/24, eth1=10.0.1.1/24 usw.!! Dadurch war die Firebox natürlich nicht mehr direkt “ansprechbar”, weder vom Trusted Network noch remote über das Internet!
Zum Glück war bisher in allen meinen Fällen kompetentes IT-Personal vor Ort zur Stelle, das nach telefonischer Anleitung den lokalen Zugriff und den Remote-Zugriff wieder herstellen konnte:

  • Auf eth1 lag 10.0.1.1/24, also musste zunächst irgendwie dafür gesorgt werden, dass ein PC/Notebook mit einer anderen fest konfigurierten IP-Adresse aus dem Subnetz 10.0.1.0/24 auf eth1 zugreifen kann.
  • Auf dem PC/Notebook muss bereits ein funktionsfähiges Adobe Flash Plugin vorhanden sein!
  • https://10.0.1.1:8080 ruft den WatchGuard Setup Wizard auf.
  • Die Passwörter waren jedoch NICHT die Factory Defaults readonly bzw. readwrite, sondern immer noch die bisherigen tatsächlichen Kennwörter der Firebox! (Auch der Feature Key war auf dem Gerät noch vorhanden und aktiv!)
  • Durchklicken des Setup Wizard, wobei jedoch die TCP/IP-Einstellungen für das TRUSTED Interface (und bei Remote Administration die Einstellungen für das EXTERNAL Interface) passend wiederhergestellt werden müssen!! Diese Angaben sollten also bei Durchführung eines Software-Updates grundsätzlich immer irgendwie “schwarz auf weiß” zugänglich sein… 🙂
  • Bei Remote Administration muss noch die “WatchGuard” Firewall Policy kurzfristig so erweitert werden, dass der Alias “Any-External” im From-Feld zu stehen kommt.
  • Nun kann die letzte existierende XML-Konfigurationsdatei wieder auf die Firebox hochgeladen werden – und alles sollte wie vorher sein, nur dass jetzt eben die 11-er Software darunter liegt…

Dieses Verhalten ist bei WatchGuard (noch) nicht als Problem bekannt, aber man weiß ja nie… Drei unabhängige Fälle lassen ja schon vermuten, dass da womöglich momentan ein Bug sein Unwesen treibt… Kleiner Tipp: eventuell hat das Problem ja auch etwas mit den berühmten Sonderzeichen zu tun. Sollten Sie also Firewall-Kennwörter verwenden, die nicht ausschliesslich aus A-Z, a-z und 0-9 bestehen, sollten Sie diese eventuell VOR dem Software-Update kurzfristig entsprechend ändern… 🙂

Nachgereicht: Resolved Issues in Fireware XTM 11.3.2

Fireware XTM v11.3.2 behebt einige Probleme, die in früheren Fireware XTM v11.x Versionen gefunden wurden:

General

  • This release resolves a problem that caused excessive CPU usage after multiple PPTP connection attempts. [56005]

Authentication

  • You can now add Single Sign-On exceptions by host range or subnet. [41194]
  • The Single Sign-On agent no longer fails when you have Active Directory groups or users with non-ASCII characters in their names. [41883]
  • A problem that caused the Single Sign-On client to get incorrect group membership information when used with the Microsoft Windows 7 OS has been resolved. [55738]
  • This release includes improvements to the Single Sign-On client and agent software to improve the reliability of group membership retrieval. [44134]
  • The Single Sign-on agent no longer sends login information to the Active Directory server twice. [45292]

Mobile VPN with SSL

  • Mobile VPN with SSL client connections are no longer possible for a user who is not part of the SSLVPN-Users group when you use LDAP for the authentication server. [56462]

FireCluster

  • This release resolves an issue the caused the real MAC address to be used when your Firebox or XTM device is configured for SSL VPN Bridge Mode. [55606]
  • When you configure an active/active FireCluster, the FireCluster management IP addresses are now accessible through a branch office VPN tunnel. [39728]

Logging and Reporting

  • The Log Server no longer stops functioning if a Japanese font appears in the log messages sent from the Management Server. [56593]
  • An email notification is now sent when the Log Server detects that a Firebox or XTM device has stopped sending log messages to the server. [55869]
  • When you reinstall the Report Server, the Log Server database path no longer changes. [56292]
  • If the Log Server is rebooted during the upgrade from Fireware v10.x to Fireware XTM v11.3.2, the database migration now resumes successfully. [56846]
  • The WatchGuard Server Center Setup Wizard no longer fails when you install the Log Server without also installing the Management Server. [56509]
  • A confirmation dialog now shows when you set up the Log Server or Report Server database path. [56516]

WatchGuard System Manager

  • The HTTPS proxy action is no longer blank when you create a new proxy action. [56627]
  • You can now configure up to 200 Traffic Management objects in Policy Manager. [55796]
  • Several improvements have been made to reduce the occurrence of configuration saves that fail with the error: “failed to read servers response: premature EOF”. [40706]
  • Certificate verification no longer fails for Role Based Access Control after a certificate is renewed. [56329]

Web UI

  • You can now release or renew a DHCP lease manually from the Web UI when the external interface is configured to use DHCP. [37478]
  • You can now successfully generate a Mobile VPN with IPSec .ini profile when the group name contains a space. [56537]
  • Policy Based Routing now works correctly when the external interface has a dynamic IP address. [56550]
  • You can now disable Single Sign-On in the Web UI. [56661]
  • You can now select a network subnet or host range when you configure Branch Office VPN tunnels. [44954]

Proxies and Services

  • The default Body Content Types rule for Windows EXE/DLL files has been updated to match a larger class of Windows executable files. This change applies only to new configurations created in Policy Manager using version 11.3.2 or later. The existing configuration on your device does not change when you upgrade from a previous 11.x version. To correct the Body Content Types rule in your existing configuration, go to the Body Content Types category in your HTTP proxy action and edit the Windows EXE/DLL rule. (Note that in Policy Manager, you must be in Advanced View to edit the rule.) Use Pattern Match and for the pattern use: %0x4d5a%* [40799]
  • The default WebBlocker Exception in Policy Manager to always allow WebBlocker categorizations to the WatchGuard web site has been updated to more closely match the WatchGuard domain. This change applies only to new configurations created in Policy Manager using version 11.3.2 or later. It does not apply to the Web UI. The existing configuration on your device does not change when you upgrade from a previous 11.x version. To correct the WebBlocker Exception in your existing configuration, edit your WebBlocker action and go to the Exceptions tab. Edit the WatchGuard exception. Change the “Match Type” to Regular Expression and use this expression: ^[0-9a-zA-Z_-.]{1,256}.watchguard.com/ WatchGuard would like to thank Eric Snyder from Verus Corp in Fridley, MN for bringing this issue to our attention. [44585]
  • The SMTP proxy configuration now includes an option to turn off the logging of denied SMTP Commands. [45119]
  • A problem was resolved that caused HTTP traffic to fail when Gateway AV scanning of HTTP traffic is enabled on Firebox X Edge e-Series devices that run v11.3.2 build 291323. [57372]
  • The Firebox System Manager Subscription Services tab now correctly displays IPS deny totals. [56096]
  • This release resolves a stack trace in the FTP proxy caused by a malformed user command. [56248]
  • When spamBlocker and Allow BDAT chunking are both enabled, the SMTP proxy log file now shows the spam score log message instead of a message that says: SMTP Message classification is unknown because an error occurred while classifying. [56394]

SIP and H323

  • SIP Forking (INVITE) with the same call-id now works correctly. [56000]
  • MSRP file-transfer now works correctly. [55999]
  • RTP packets are no longer sent from the wrong interface when multi-WAN is configured. [44587]
  • The media timeout is now separate from the registration timeout. [55762]
  • SIP registrations no longer fail when the server sends a NOTIFY. [56448]

Branch Office VPN

  • Branch Office VPN tunnels now rekey correctly when the remote side initiates the rekey and 1-to-1 NAT or Dynamic NAT is used within the tunnel. [56599]
  • Traffic log messages now show the source interface of the incoming Branch Office VPN tunnel traffic. [45052]

Networking

  • NAT loopback now works correctly with Server Load Balancing. [41090]
  • When a Firebox or XTM device is configured in drop-in mode with no external interfaces configured, the default route now works correctly. [41802]
  • This release resolves an issue that caused the DHCP Server on the Firebox or XTM device to hand out IP addresses slowly because of DNS host name lookup. [44571]
  • You can now correctly add a secondary address to an external interface when the interface name contains a space. [56439]
  • When you use MAC access control for wireless users and you bridge wireless to your trusted interface, you no longer need to add the MAC address to the trusted interface MAC Access Control list. [41678]
  • When your Firebox or XTM device is configured in bridge mode, MAC access control is now applied correctly to DHCP bootp traffic. [56867]
  • QoS now works correctly with FTP policies. [56266]
  • When you change the wireless configuration on an XTM 2 device, the interfaces no longer go up and down spontaneously. [42300]
  • This release resolves an issue that caused the certd process to use excessive memory. [56181]

Active/Passive HA Failover Problem

In einem Kundenprojekt (zwei XTM 505 in Active/Passive HA) wurde berichtet, dass nach einem Failover von der Primary auf die Secondary Firebox die Systeme in einer DMZ nicht mehr erreichbar wären. Die Systeme untereinander könnten kommunizieren, auch die Systeme im eigentlichen Trusted Network arbeiten korrekt.
Das Problem scheint sich auf einen bereits bekannten Bug zurückführen zu lassen, der dafür sorgt, dass sich nach einem Failover die neue MAC-Adresse des WatchGuard Clusters nicht in die ARP Table der angeschlossenen Client-PCs einträgt (BUG45223). Das Problem soll in einer der kommenden Software-Releases behoben sein.

Fireware XTM: HA Cluster Probleme mit MTU Size im BOVPN Tunnel

Ich habe aktuell einige offene Support-Fälle, die folgende Gemeinsamkeiten aufweisen: Active/Passive Cluster unter Fireware XTM v11.3.x, Branch Office IPSec VPN Tunnel zu festen Außenstellen, Kommunikationsprobleme innerhalb des/der BOVPN Tunnel.
In allen Fällen scheinen die Probleme mit fehlerhafter Fragmentierung von IPSec-Paketen zu tun zu haben. Ich konnte etwas ausführlicher debuggen und feststellen, dass bisweilen (also nur zeitweise!) IP-Pakete größer als 1394 Bytes im VPN-Tunnel nicht korrekt fragmentiert, sondern komplett verworfen werden. WatchGuard hat das Szenario im TestLab nachgestellt, konnte jedoch die Fehlerursache bis jetzt noch nicht weiter eingrenzen.
Zur schnellen Dokumentation des Problems verwende ich von einem PC in einer Außenstelle eine MSDOS-Eingabeaufforderung mit dem Befehl

ping [IP] -l 2000 -t

wobei [IP] eine IP-Adresse am anderen Ende eines BOVPN-Tunnels (in der Zentrale) ist. Der Befehl erzeugt Ping-Pakete mit einer Größe von 2000 Byte, die also beim Transport über das Internet zwingend fragmentiert werden müssen, da die maximale MTU Size auf Internet-Routern in der Regel 1500 Bytes beträgt. Erhalte ich korrekte ICMP-Antworten, weiss ich, dass die Fragmentierung korrekt funktioniert. Wenn nicht, liegt ein Problem vor. Durch Verkleinern der Paketlänge kann man sich iterativ an den kritischen Wert herantasten. Im vorliegenden Problemfall werden Pings mit 1394 Bytes korrekt übertragen, Pings mit 1395 Bytes und mehr jedoch NICHT:

Das Problem scheint zudem nur auf dem Rückweg von dem angepingten Host aufzutreten. Offenbar erreichen im Problemfall auch größere Datenpakete den Zielhost, der auch korrekt antwortet – jedoch scheint die WatchGuard Firebox ein Problem mit dem “Rücktransport” der Antwortpakete zu haben, wie sich am Vergleich der folgenden, im Abstand von ein paar Minuten aufgenommenen Screenshots erkennen lässt. Die mit grünen Streifen markierten Werte zählen im Laufe der Zeit korrekt hoch, während der eine rot markierte Wert (RCVD zurück auf dem ursprünglich sendenden System) sich nicht ändert…:

In allen meinen Support-Fällen konnte ich das Problem zunächst durch einen Workaround umgehen: auf dem Cluster Reduktion der MTU Size auf den Interfaces, die an BOVPN-Tunneln beteiligt sind, von 1500 auf 1380 Bytes:

WatchGuard muss jedoch das eigentliche Problem finden und beheben, denn durch den Workaround wird die Gesamtleistung der WatchGuard Firebox etwas ausgebremst.

Fireware XTM: Reihenfolge der Anmelde-Domänen auf der Anmeldeseite

In Verbindung mit User Authentication wird meist die manuelle Anmeldeseite der WatchGuard Firewall Appliance verwendet:
https://[IP-der-Firebox]:4100.
Die Authentication kann entweder gegenüber der lokalen Benutzer-Datenbank der Firebox selbst erfolgen (Firebox-DB), alternativ gegenüber externen Benutzer-Datenbanken unter Verwendung von RADIUS, SecureID/VASCO, LDAP oder Active Directory. Selbst wenn in der Firebox-DB gar keine lokalen User vorhanden sind, weil z.B. generell mit Active Directory gearbeitet wird, sieht die Anmeldeseite BEIM ERSTEN AUFRUF erst einmal so aus, d.h. standardmäßig wird “Firebox-DB” als Anmelde-Domäne angezeigt:

Die User müssen also in diesem Fall nicht nur geschult werden, dort ihren Windows-Benutzernamen und ihr Windows-Kennwort einzugeben, sondern auch noch in dem Pulldown-Menü darunter MANUELL von “Firebox-DB” auf “Active Directory” umzustellen. Das gestaltet sich manchmal etwas schwierig……… Besser wäre es natürlich, wenn die Anmeldeseite auch schon beim ersten Aufruf standardmäßig “Active Directory” als Anmelde-Domäne zeigen würde:

Die Reihenfolge der Anmelde-Domänen in dem Pulldown-Menü lässt sich durch einen manuellen Eingriff in die XML-Konfigurationsdatei beinflussen.
Erzeugen Sie als Backup zunächst eine Kopie Ihrer aktuellen XML-Konfigurationsdatei. Öffnen Sie die XML-Datei dann mit einem entsprechenden Editor. WordPad reicht schon. Suchen Sie nach dem Tag “auth-domain-list”. Sie werden erkennen, dass dort die von Ihnen verwendeten Anmelde-Domänen als “auth-domain” aufgelistet sind. An erster Stelle werden Sie “Firebox-DB” finden. Sie können nun die Anzeige-Reihenfolge festlegen, indem sie die jeweils vollständigen “auth-domain”-Tags per Cut&Paste in der gewünschten Reihenfolge anordnen. Speichern Sie die geänderte XML-Datei, öffnen Sie diese über den Policy Manager und laden Sie sie per “Save to Firebox” auf die WatchGuard hoch.
ACHTUNG: Wie immer ist in einem solchen Fall natürlich sehr sorgfältiges Vorgehen angesagt!!!

Fireware XTM: Öffentliches Zertifikat für Anmeldeseite (Port 4100 tcp) verwenden

Wenn auf der WatchGuard Firebox oder WatchGuard XTM mit User Authentication gearbeitet wird – also Firewall-Regeln verwendet werden, die auf User-Basis greifen und nicht auf Maschinen-Basis – kommt häufig die Anmeldeseite der Firewall ins Spiel, die über
https://[IP-der-Firebox]:4100
aufgerufen wird. Die Anmeldeseite verwendet SSL-Verschlüsselung. Hierfür wird standardmäßig ein von WatchGuard selbst generiertes Zertifikat verwendet, das aber nicht von einer öffentlichen Zertifizierungsstelle rückbestätigt ist, weswegen beim Aufruf die allseits bekannte Warnmeldung des Browsers erscheint. Folgende Zertifikate sind ab Werk auf einer WatchGuard Appliance unter Fireware XTM 11.3.x vorhanden:


Das SSL Zertifikat von WatchGuard kann durch ein offizielles, von einer allgemein bekannten Zertifizierungsstelle rückbestätigtes SSL Zertifikat ersetzt werden. Hier reicht schon ein einfaches Zertifikat z.B. von RapidSSL aus, das bereits für 10,95 USD pro Jahr erhältlich ist. Alternativ kann (mit den bekannten Einschränkungen) auch ein von einer firmeninternen, privaten Zertifizierungsstelle erstelltes Zertifikat verwendet werden. Es empfiehlt sich, das Zertifikat für einen griffigen Hostname ausstellen zu lassen (firewall.kundenname.de, watchguard.kundenname.de, fw.kundenname.de etc.) und diesen über DNS korrekt bekannt zu machen. Zur allgemeinen Vorgehensweise:
WatchGuard System Manager (WSM) > Connect to Firebox > Firebox System Manager > View > Certificates > Create Request.
Der abschließend erzeugte CSR (Certificate Signing Request) wird an die Zertifizierungsstelle geschickt, für die man sich entschieden hat. Wenn das von dort ausgestellte Zertifikat vorliegt, kann es über “Import Certificate / CRL” auf die Firebox importiert werden. Wenn das Root-Zertifikat der CA nicht in der Liste der defaultmäßig enthaltenen CA Certificates enthalten ist (http://www.watchguard.com/help/docs/wsm/11/en-US/Content/en-US/certificates/cert_auto_trusted_list_c.html), muss es VOR dem Import des eigentlichen Zertifikats auf die gleiche Weise importiert werden, da sonst ein Fehler generiert wird: “Error: Error occurred while performing ‘import certificate’: certificate add error msg=”Failed to import a certificate!! 6_982: certificate validation fail” add certificate”. Das Root-CA Zertifikat von RapidSSL findet sich übrigens hier: http://www.geotrust.com/resources/root_certificates/certificates/Equifax_Secure_Certificate_Authority.cer. Wählen Sie für den Import jeweils die Option “IPSec, Web Server, Other”. Der erfolgreiche Import wird angezeigt:

Nun ist/sind die offiziellen Zertifikat(e) zwar schon auf der Firebox vorhanden, müssen aber noch für den Einsatz auf der Authentication Webpage der Firebox ausgewählt werden:
Policy Manager > Setup > Authentication > Web Server Certificate… > Third Party Certificate auswählen > OK > Save to Firebox.
Abschließend muss die Firebox einmal durchgebootet werden, damit diese Änderung auch tatsächlich aktiv wird:


Command Line Interface (CLI) auf Port 4118 tcp

WatchGuard Firebox e-series und XTM Systeme mit Software 10.x oder 11.x bieten auch die Möglichkeit der Administration und Programmierung im Kommandozeilenmodus (CLI). Ausnahme: X Edge e-series mit v10.x. Hierzu läuft auf der WatchGuard ein SSH-Daemon, der auf Port 4118 tcp hört. Dieser Port ist Bestandteil der standardmäßig im Regelwerk enthaltenen Firewall-Regel “WatchGuard”, die ebenfalls standardmäßig den Zugriff auf die “Firebox” von “Any-Trusted” und “Any-Optional” ermöglicht. Das From-Feld dieser Regel kann natürlich auch so erweitert werden, dass der Zugriff über das Internet oder für mobile User möglich wird (Sicherheitsüberlegungen berücksichtigen!).
Das CLI kennt wie das WebUI zwei User: status und admin. Zu status gehört immer das lesende Kennwort der Firebox (status passphrase). Zu admin gehört immer das schreibende Kennwort der Firebox (configuration passphrase).
Wenn Sie nun über einen SSH-Client (z.B. PuTTY) eine SSH-Verbindung zu Port 4118 öffnen und sich als admin an der Firebox anmelden, können Sie dort zunächst durch die Eingabe eines Fragezeichens (?) eine Übersicht der verfügbaren Befehle anzeigen lassen:

Hier findet sich unter anderem auch der Befehl “reboot”, über den die Firebox durchgebootet werden kann. Gerade bei Fireboxen mit v10.x ist dieser Einstieg manchmal “der letzte Rettungsanker”, wenn durch Memory Leak Effekte der Hauptspeicher auf der Firebox zugelaufen ist und die Firebox in Folge den Daemon abgeschaltet hat, über den sich der WSM mit der Firebox verbindet…
Ebenfalls sehr hilfreich ist der CLI-Befehl “ping”, der es ermöglicht, pings direkt von der Firebox aus zu verschicken.
Theoretisch kann über das CLI auch eine weitgehende Administration des Gesamtsystems erfolgen, also auch Konfigurationsänderungen etc., jedoch kommt dies in der Praxis eher selten vor. WatchGuard bietet hierfür unter http://www.watchguard.com/help/documentation/xtm.asp eine umfangreiche PDF: die Command Line Interface Reference.

X Core und Peak out-of-the-box auf 11.3.1 updaten

WatchGuard X Core und X Peak e-series Modelle werden auch heute noch ab Werk mit der Software-Version 10.2 ausgeliefert. Ich führe derzeit folgende Schritte aus, wenn ich die Produkte out-of-the-box auf die aktuelle Version Fireware XTM 11.3.1 updaten möchte (Voraussetzung: Dual-Install eines WSM 10.2.x und WSM 11.3.1 auf dem Installations-PC vorhanden, feste IP de PC z.B. 10.0.1.100/24, verbunden mit eth1 der Firebox):

  • Registrierung der Firebox im Live Security Account auf der WatchGuard Website (vorab).
  • Feature Key (Lizenzdatei) herunterladen und in einer Textdatei speichern (vorab).
  • Starten der Firebox in den Recovery Mode (Up-Arrow-Button gedrückt).
  • Ausführen des “Quick Setup Wizard” der WSM 10.2.x Installation und Befüllen mit Dummy-Werten (IP-Adresse des Trusted Interface jedoch nach wie vor auf 10.0.1.1/24 setzen, Feature Key importieren).
  • Nach dem Reboot der Firebox WSM 11.3.1 starten und “Connect to Device” (10.0.1.1).
  • Policy Manager der 11.3.1 starten
  • File > Upgrade; Configuration Passphrase eingeben und aktuelle utm_core_peak.sysa-dl auswählen (11.3.1); Meldungen durchbestätigen, kein Backup-Image speichern.

Ich habe festgestellt, dass ein direkter Update-Versuch einer Factory Default 10.2 Firebox über den “Quick Setup Wizard” des WSM 11.3.1 scheitert, weil der Installer nach ca. 2-3 Minuten an folgender Stelle hängenbleibt:

Danach geht es auch nach 10-15 Minuten nicht weiter und der Quick Setup Wizard 11.3.1 muss mit einer Fehlermeldung abgebrochen werden. Zum Erfolg führte dann in der Regel das weiter oben beschriebene Verfahren in einer Dual-Install-Umgebung.

WatchGuard WSM und Fireware XTM 11.3.1

Dies ist die Bugfix-Liste für die aktuellen Versionen WatchGuard System Manager (WSM) und Fireware XTM 11.3.1, die im Download-Bereich der WatchGuard-Webseite zur Verfügung stehen:

General

  • This release resolves an issue that caused the logging process on a Firebox or XTM device to crash. [55676]
  • This release resolves an issue that caused the Firebox or XTM device to crash when used with PPPoE. [43811]
  • Notification for blocked sites now works correctly. [45148]
  • The unlock.exe program now supports non-ASCII characters in the file name. [42599]
  • This release resolves an issue that caused authentication to fail with the log message: wgcgi timeout after prcs msg error. [44887]
  • Traffic and management connections no longer stop when you retrieve a support.tgz file from a Firebox or XTM device running under a heavy connection load. [44956]

Fireware v10.x to Fireware XTM v11.x Upgrade Issues

  • A problem that caused the error message “INTERNAL_ERROR: The element ‘backup-firebox-ip’ has a length of 19” to appear when you upgrade from Fireware v10.x to Fireware XTM v11.x has been resolved. [42653]
  • When you upgrade a centrally managed Firebox X Edge from v10.x to Fireware XTM v11.x, the traffic control, WebBlocker custom profiles, and the Allow all traffic trusted<->optional settings are now correctly preserved during the upgrade. [43712]
  • When you upgrade a Firebox X Edge from v10.x to v11.x, IKE Keep-Alive is no longer enabled during the upgrade if it was not previously enabled in your v10.x configuration. [44219]
  • A problem that caused a Management Server upgrade from Fireware v10.x to Fireware XTM v11.x to fail because of long managed alias names has been resolved. [44232]

Fireware XTM Web UI

  • You can now successfully open and use Bandwidth Meter from the Web UI with no syntax errors. [41911]
  • You can now successfully add WebBlocker exceptions from the Fireware XTM Web UI with no “Code 8: Error 9” error message. [43744]
  • The Fireware XTM Web UI login window now appears correctly when you use Safari on Mac OS X “Snow Leopard” without the need to refresh the browser. [42791]

WatchGuard System Manager

  • You can now successfully install WatchGuard System Manager when Microsoft SQL Server 2008 Management Studio is running on your computer. [44981]

WatchGuard Servers

  • Email released from the Quarantine Server is now correctly delivered to all recipients, instead of just the first recipient in the list. [43875]
  • The Quarantine Server can now handle the apostrophe character (‘) in email addresses. [56221]
  • The Quarantine Server can now handle the dash character (-) in email addresses. [45267]
  • The Quarantine Server automatic scheduled user notification no longer stops after 2-3 days with a pyadapter exception error. [56109]
  • A problem that caused the Report Server to occasionally fail to complete reports has been resolved. [45486]
  • The default log level for WatchGuard System Manager server applications has been set back to “Warning” instead of “Debug” to keep unnecessary log messages from accumulating. [56290]
  • The Reporting Web UI now works correctly after you upgrade WatchGuard Server Center from v11.2.x to v11.3.x [55879]
  • We have resolved an issue that caused Report Server instability when you generate the Denied Packet by Client report for a large set of log messages. [56344]
  • A problem that caused the WatchGuard Server Center restore function to sometimes fail to restore a backup file with an exception error has been resolved. [55984]
  • You can now use the Reporting Web UI to access archived reports when the report generation time on the Report Server is set to a time later than 12:00 pm. [56286]
  • The installation of WatchGuard Server components no longer fails with the error: “Management server failed during -unconfig mode 1”. [44238]
  • The Management Server no longer fails to start after you restore a backup file on a computer on which the log directory specified in the WatchGuard Server Center configuration does not exist. If the log directory path does not exist, the default directory path will be used. [44380]
  • The Log Server backup process no longer fails when you use a non-English OS and the default Log Server configuration settings. [44563]
  • The Management Server no longer fails after you restore a backup file created with WatchGuard Server Center v10.2.x to a v11.x Management Server. [43201]

Policy Manager

  • You can now successfully configure a bridge interface with a user-defined name. [55827]
  • You can now connect to and make configuration changes to a Firebox or XTM device running Fireware XTM v11.1 from a management computer running WSM v11.3.x. [55834]
  • The FTP proxy setting to restrict the maximum number of failed logins per connection now operates correctly. [55721]

Authentication

  • Web Server certificates are now correctly imported and displayed in Firebox System Manager. [55758]

Firecluster

  • The stability of an active/active FireCluster running under a heavy connection load has been improved. [55728]
  • The passive device in an active/passive FireCluster no longer becomes unreachable when you change the management IP address of the backup master. [56064]
  • In an active/active FireCluster, the Mobile VPN with SSL “Bridge VPN traffic” option now operates correctly. [40608]

Networking

  • DF settings are now available when your Firebox or XTM device is configured in drop-in or bridge mode, in addition to routed mode. This setting is available on the Advanced tab of an interface configured as External. [44258]
  • On the XTM 2 Series, traffic no longer fails across bridged interfaces when the bridge consists of Ethernet ports eth0-eth2 and eth3-eth5. [55737]
  • You can now configure the Firebox X Edge e-Series and XTM 2 Series devices to forward DNS queries. Note that you can only enable this feature with the CLI; it is not available in Policy Manager or the Web UI. [42709]
  • It is now possible to add up to 200 traffic management objects. [55796]
  • A previously expired connection can no longer be re-opened when traffic matching the expired session is received. [45286]
  • The blocked site limit has been increased from 154 to 1000. [40362]
  • If a WINS server address is not defined in the configuration, the Firebox or XTM device now keeps the WINS server address blank when using DHCP. [41622]
  • When using a dynamic NAT entry from one VLAN to another VLAN, the Source IP address is no longer the primary external IP address of the Firebox. [43838]
  • After a proxy connection is closed, the Firebox or XTM device continues to accept and drop lingering connections from the remote server for a short period of time. This is done to prevent “auto-block packets not handled” from occurring due to a late reply packet from the server for a closed connection. [43866]
  • 1-to-1 NAT now takes precedence when policy-based dynamic NAT is configured to use “Set source IP”. [44257]
  • A Gratuitous ARP is now issued when you change the MAC address in the Network Interface setting to “override MAC address”. [55799]
  • The Firebox or XTM device will now send a Gratuitous ARP (GARP) every hour for interface IP addresses. The GARP is performed each hour to make sure connected devices have correct ARP entries for the Firebox IP addresses. [55811]
  • The Firebox or XTM device now correctly supports the number of allowed authenticated users per model. [56012]
  • NAT loopback will now operate correctly when the connecting client uses a zero route branch office VPN tunnel. [45149]
  • Connection rate limiting now operates correctly for inbound traffic. [43023]

Proxies

  • We no longer support SSL v2 in the HTTPS proxy in order to better comply with PCI scans. [55908]
  • This release resolves an issue that caused attachments sent through proxies to become corrupted. [40829, 55736, 56207]
  • We have improved the stability of our proxy technology. These changes fix problems that caused some proxy processes to crash. [44786, 45209, 55601, 55663,55693,55794, 55813, 45458]
  • This release resolves an issue that caused AV scans to fail after reboot. [56043]
  • When an email is quarantined as spam by the SMTP proxy, a “200 OK” message is now sent to the sending server. [44224]
  • The H.323 ALG media channel timeout no longer causes calls to be dropped after 900 seconds. [44945]
  • The H.323 ALG now correctly deletes expired connections. [44573]

Security Services

  • This release resolves several problems that caused spamBlocker to crash. [43787, 44194, 44518]
  • This release resolves an issue that caused Internet Explorer to display “friendly HTTP error messages” instead of the WebBlocker deny message if the deny message did not have enough characters in it. [44893]
  • The RED daemon no longer crashes on the passive device in an active/passive FireCluster. [56141]
  • The IPS security service no longer adds IP addresses to the blocked sites list when it is configured only to drop traffic. [45281]
  • The WebBlocker Override feature now operates correctly with VLAN interfaces. [43632]

Logging

  • In proxy traffic log messages, the network interface name now appears correctly as the name you assign the interface and not as a network alias. [56243]
  • A Firebox or XTM device now generates a log message when the maximum number of concurrent packet filter connections has been reached. [41801]