Tag Archives: WSM

WatchGuard WSM und Fireware XTM 11.3.1

1 Comment

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]

Kein DYNDNS-Update bei VPN-Tunnel Routing 0.0.0.0/0

Comment

In manchen VPN-Projekten kommt es vor, dass nicht nur der netzinterne Verkehr von Außenstellen durch einen VPN-Tunnel zur Zentrale geroutet wird, sondern auch der gesamte Internet-Traffic. Dann können nämlich z.B. auch die möglicherweise nur in der Zentrale vorhandenen UTM Security Services (WebBlocker, spamBlocker, Gateway Antivirus, Intrusion Prevention Services, Reputation Enabled Defense) auf den Internet-Verkehr der Außenstellen angewendet werden, wo möglicherweise nur WatchGuard Firebox Produkte mit Live Security eingesetzt werden.
Dabei muss natürlich berücksichtigt werden, dass über die Internet-Leitung in der Zentrale eben auch der komplette Internet-Traffic der Außenstelle(n) läuft – und das nicht nur einmal, sondern DOPPELT (aus dem Internet in die Zentrale und weiter über den VPN-Tunnel in die Filiale).
Im Branch Office VPN Tunnel wird dies häufig über die Verwendung der BOVPN Tunnel Route Local Network <-> 0.0.0.0/0 realisiert.
Wenn in der Außenstelle jedoch keine feste IP-Adresse existiert, sondern mit einem DYNDNS-Hostname gearbeitet wird, führt dies gerade in Verbindung mit dem WatchGuard Management Server zu Problemen. Der auf der WatchGuard laufende DYNDNS-Updater meldet eine Adressänderung nämlich per http an einen Webserver von DYNDNS. Dieser http-Verkehr wird jedoch von der Firebox oder XTM Appliance nicht direkt ins Internet hinaus geroutet, sondern durch den 0.0.0.0/0 Tunnel zunächst in die Zentrale geschickt und von dort aus weiter zu DYNDNS. Das hat aber zur Folge, dass die “gemeldete” IP-Adresse nicht zu der Quell-IP-Adresse passt, von der die Meldung bei DYNDNS eingeht. DYNDNS verweigert daher das Update des DNS-Eintrags, und der WatchGuard Management Server und die am VPN-Tunnel beteiligte zentrale Firebox haben ein Problem, die Außenstelle zu “finden”.
In einem solchen Fall sollte die Außenstelle in einen Internet-Tarif wechseln, bei dem eine feste öffentliche IP-Adresse möglich ist.

Logging Datenbank unter 11.3 hat jetzt feste Größe

Comment

Nach einem Auslandsprojekt und etwas Urlaub nun neuer Input: Wer sich gewundert hat, warum im WatchGuard Server Center 11.3 unter “Logging Server” nicht mehr die bisher üblichen Angaben zu finden sind, nach wie vielen Tagen die alten Daten gelöscht werden sollen bzw. nach Erreichen von wieviel Prozent der maximalen Datenbank-Größe eine Notification E-Mail an den Administrator zu senden ist, sei beruhigt: in der Version 11.3 ist die Angabe “Database Size” tatsächlich die Maximalgröße der Datenbank. Bei Erreichen von 95% dieser Größe werden ältere Daten automatisch gelöscht. Es gibt keine Notifications mehr. Wenn also aufgrund von Unternehmensrichtlinien eine entsprechende Anzahl von vorzuhaltenden Tagen verbindlich ist, müsste dies im Rahmen der Datenbankgröße und des anzuwendenden Backup-Konzepts aufeinander abgeglichen werden. Hier bietet sich das freie Tool “pgadmin” an, mit dem u.a. auch zeitgesteuerte Datenbank-Dumps geplant werden können.

Management user status from [IP] logged in / out

Comment

Diese derzeit teilweise alle 10 Sekunden im Traffic Monitor / Logfile auftretenden Meldungen können ignoriert werden. Die Meldungen werden immer dann erzeugt, wenn der WSM (WatchGuard System Manager) das angeschlossene Device pollt. In Version 11.3 wurde neu eingeführt, dass auch Vorgänge getrackt werden, die vom User “status” (=lesendes Kennwort) ausgeführt werden. Da der WSM ebenfalls mit dem lesenden Kennwort pollt, erscheinen nun diese Meldungen. Dieser (Anzeige-)Bug soll in Version 11.3.1 gefixt sein.

SMTP error 571 message refused bei “Quarantine”

Comment

Der spamBlocker erzeugt bei Fireware XTM 11.2.x derzeit einen nicht RFC-konformen SMTP-Fehler “571 Delivery not authorized, message refused”, wenn eine E-Mail vom SMTP-Proxy in die Quarantäne Station verschoben wird. Korrekt wäre ein “200 OK”, da die Mail ja in Wahrheit angenommen worden ist. Dieser Fall wird jedoch in der Praxis nur selten auftreten, da legitime E-Mails in der Regel nicht als “Bulk” oder “Confirmed Spam” eingestuft und daher ggfs. in die Quarantäne Station verschoben werden. Dieses Verhalten wurde von WatchGuard als Bug bestätigt. Mit einer Korrektur ist in einer der nächsten Releases zu rechnen.

Keine Sonderzeichen in Firewall-Kennwörtern!

Comment

Kleine Erinnerung (obwohl schon des öfteren thematisiert): Verwenden Sie an allen Stellen der XML-Konfigurationsdatei sowie in VPN Pre-Shared Keys und vor allem in der Status und der Configuration Passphrase der Firewall selbst ausschließlich ASCII-Zeichen des Zeichensatzes US-ASCII 7bit! Keine deutschen Umlaute äöü/ß, keine speziellen Sonderzeichen!
Ich musste heute eine X750e mit Fireware 10.2.11 “retten”, bei der der Kunde in der Configuration Passphrase ein €-Zeichen (EUR) verwendet hat. Effekt war, dass nur noch die Anmeldung mit der Status Passphrase möglich war, jedoch eben keine Änderungen mehr an der Konfigurationsdatei usw. Problemlösung war nur über Factory Reset und Restore/Aufspielen der letzten Konfigdatei möglich…

Active/Passive Cluster in 11.2.3 verwendet wieder vrrp

1 Comment

Eine der Neuerungen der Softwareversion Fireware XTM 11.2.3 ist, dass Active/Passive Cluster nun wieder vrrp verwenden – wie bei Fireware 10. In der Version Fireware XTM 11.1 wurden Unicast IP-Adressen eingeführt, so dass die ARP Tabelle die IP 1.1.1.1 zusammen mit der MAC Adresse des Master Devices zeigte. Bei einem Failover auf den Backup Master sah man die IP 1.1.1.1, jetzt aber mit der MAC Adresse des Secondary Devices. Der Wechsel wurde durch ein GARP Paket angekündigt (Gratuitous ARP), was jedoch von vielen Switchen und Routern nicht verstanden wurde, wodurch die tatsächlichen Unterbrechungszeiten wesentlich länger waren als eigentlich nötig.

In der Version 11.2.3 wird nun wieder vrrp verwendet. Die IP 1.1.1.1 hat nun eine unveränderliche virtuelle MAC Adresse 00-5E-00-xx-xx-xx – egal welcher Cluster-Knoten gerade aktiv ist. Die Management IP-Adressen sind aber noch immer Unicast.
Bei einem Software-Update auf 11.2.3 kann es nun erforderlich sein, auch die Switch-Konfiguration anzupassen, weil ggfs. Spanning Tree und Port Security Restriktionen die ARP/MAC Tabellen auf ein einzelnes Interface begrenzen. Der zuständige Switch-Admin sollte also immer “mit im Boot sein”…

Generell gilt ja bei Clustern unter Version 11, dass immer alle aktiven Ethernet-Ports überwacht werden (“Link State”). Unter Version 10 konnte dies noch portweise abgeschaltet werden. Bei Version 11 ist also genau zu überlegen, ob/wann einmal ein Kabel eines aktiven Interfaces aus der Firebox gezogen werden soll, denn dadurch wird ein Failover ausgelöst. Nicht benötigte Interfaces sollten daher unter Network > Configuration immer auf “Disabled” gesetzt werden.

Any-Alias in Firewall-Regeln und BOVPN-Probleme

Comment

Im Rahmen eines weiteren PCI Compliance Projekts stand vor zwei Wochen auch die Migration einer WatchGuard X5500e von Fireware 10.2.9 nach Fireware XTM 11.2.3 an sowie die Erweiterung um eine zweite X5500e zu einem HA Active/Passive Cluster. Der Kunde hatte bereits vor einigen Monaten die Migration auf eine frühere 11-er Version versucht, war aber daran gescheitert, dass zwar alle über den WatchGuard Management Server verwalteten Branch Office VPN-Tunnel funktioniert haben – nicht jedoch die über “Manual IPSec” eingerichteten BOVPN-Tunnel zu seinem outgesourceten Rechenzentrum und zu ein paar anderen externen Partnern.
Ich konnte nun erkennen, dass das Problem nicht auf Seiten der VPN-Konfiguration lag, sondern in der Formulierung einiger FIREWALLREGELN. So lautete die Firewall-Regel für “ping” From:Any To:Any. Offenbar hat aber die Firewall nicht erkannt, dass auch Ziele hinter einem BOVPN-Tunnel zu dem Alias “Any” gehören… Insofern wurden pings trotz korrekt vorhandenem VPN-Tunnel als Unhandled Internal Packet eingestuft und verworfen. Abhilfe schuf hier die Aufsplittung dieser einen Firewall-Regel in mehrere einzelne Regeln, z.B. Ping.Out.Internet = From:Any-Trusted To:Any-External und Ping.Out.VPN = From:Any-Trusted To:Any-BOVPN sowie ein paar weitere erforderliche Kombinationen z.B. für die Gegenrichtung From:Any-BOVPN To:Any-Trusted. Diese grundsätzliche Splittung in separate Firewall-Regeln für klassischen gerouteten Firewall-Traffic und VPN-Traffic hat sich bewährt! Die Migration von 10 auf 11 auf Basis der geänderten Konfigurationsdatei war dann auf Anhieb erfolgreich.

Quick Setup Wizard 11.2.3 und XTM 830

Comment

Ich konnte nun bei der Erst-Inbetriebnahme von zwei WatchGuard XTM 830 sehen, dass der Quick Setup Wizard der Version 11.2.3 bei diesem Modell offenbar etwas Probleme hat festzustellen, dass die Installation eigentlich korrekt durchgelaufen ist. Trotz Fehlermeldungen seitens des Quick Setup Wizard waren beide Boxen korrekt installiert und konnten anschließend auch sauber als HA Active/Passive Cluster in Betrieb genommen werden.

Dual Install von WSM 10.2.x und WSM 11.2.x

Comment

Wenn Sie – zum Beispiel für Migrationszwecke – auf der gleichen Windows-Maschine sowohl die Client-Komponenten des WSM 10.2.x als auch WSM 11.2.x benötigen, ist die Reihenfolge wichtig, in der die Installer ausgeführt werden:
Installieren Sie immer zuerst den WSM 10.2.x – und erst danach den WSM 11.2.x!

Wird der WSM 10 nämlich nach dem WSM 11 installiert, zerschießt der nachträglich ausgeführte WSM 10-Installer wichtige Teile der WSM 11-Komponenten. So kommt es dann bei der Migration von Fireboxen zu Problemen. Der Policy Manager von WSM 11 meldet beispielsweise beim Zugriff auf eine 10-er Box java.lang.IllegalArgumentException: Cannot support TLS_RSA_WITH_AES_256_CBC_SHA with currently installed providers. Oder sowohl “Quick Setup Wizard” als auch “Web Quick Setup Wizard” von WSM 10 laufen zwar durch, enden aber mit einer Fehlermeldung. Die Firebox selbst hängt, im LCD Display steht XModemRcv 115200 Start Remote Send…. Die Box lässt sich in diesem Zustand nur noch wieder in den Safe Mode booten (Down-Button), aber das hilft nicht weiter…

Bereinigen Sie die Installation auf Ihrer Windows-Maschine wie folgt:

  • WSM 10.x und 11.x deinstallieren
  • Restliche Fragmente der Java Runtime Engine in “Common FilesWatchGuardjava” löschen (“Gemeinsame Dateien”…)
  • Neuinstallation WSM 10.2.x
  • Neuinstallation WSM 11.2.x
  • Quick Setup Wizard der 10.2.x durchführen
  • Box sollte dann wieder „normal“ booten
  • Über den WSM 11.2.x mit der Box verbinden
  • Über den Policy Manager von 11.2.x die Box updaten…

Natürlich haben Sie sichergestellt, dass Sie Zugriff auf die letzte funktionierende XML-Konfigdatei und eigene Zertifikate/CA haben… 🙂