Tag Archives: WSM

Trade-Up / Migration von X Core e-series X550e, X750e, X1250e auf XTM 5

18 Comments

Viele Kunden steigen derzeit von einer WatchGuard X Core e-series X550e, X750e, X1250e auf ein entsprechendes Nachfolge-Modell XTM 505, XTM 510, XTM 520 und XTM 530 um (respektive von X Peak e-series auf XTM8). Fast immer taucht die Frage auf, ob die bestehende Konfiguration des “alten” Geräts auf das “neue” Gerät übertragen werden kann. Ja, sie kann. Es gilt aber ein paar kleine Hürden zu überwinden.

Zunächst muss natürlich die neue Box über die WatchGuard Website registriert und der neue Feature Key (Lizenzdatei) heruntergeladen werden. Auf dem Konfigurations-PC/Notebook haben Sie den aktuellen WSM 11.4.2 und die entsprechende Fireware XTM 11.4.2 für Ihre Geräte-Familie installiert, und auch das Adobe Flash Plugin für Ihren Browser ist vorhanden. Über https://10.0.1.1:8080 melden Sie sich mit dem User “admin” und dem Factory Default Kennwort “readwrite” an. Sie klicken den Setup Wizard mit den Default-Werten durch, importieren dabei auch den Feature Key und vergeben am Schluss Ihre eigenen Firewall-Kennwörter. Nach der erneuten Anmeldung mit Ihrem eigenen “admin”-Kennwort installieren Sie über System > Upgrade OS die neueste Fireware XTM 11.4.2 auf der Box, die daraufhin einmal durchbooten wird. Auf Ihrem Konfigurations-PC/Notebook starten Sie dann den WSM 11.4.2 und machen ein “Connect to Device” zu Ihrer neuen XTM-Box. Anschließend öffnen Sie den Policy Manager, der Ihnen die praktisch “leere” XML-Konfigurationsdatei der neuen XTM-Box anzeigt.

So weit, so gut. Erst jetzt wird es interessant:

Im Policy Manager laden Sie über File > Open > Configuration File die letzte XML-Konfigurationsdatei Ihrer “alten” WatchGuard. Auf die Frage “Do you want to save this new configuration to a file?” antworten Sie mit NEIN.

Sie sehen daraufhin die Konfigurationsdatei Ihrer “alten” WatchGuard. Falls Sie bisher eine X750e/X1250e im Einsatz hatten, bei der das Interface ganz rechts außen (eth7) im Einsatz war, sollten Sie sich die Network > Configuration Einstellungen für dieses Interface auf Papier notieren und prüfen, ob das Interface irgendwo namentlich in Firewall-Regel(n) auftaucht und auch diese entsprechend dokumentieren! Über Setup > System > Model wählen Sie Ihr neues Hardware-Modell aus. Es folgt eine Warnmeldung, die auf die veränderte Anzahl der Ethernet-Schnittstellen hinweist (eine XTM5 hat jetzt 7 Interfaces, eine alte X550e hatte 4, eine X750e/X1250e 8 Interfaces). Anschließend müssen Sie noch bei Setup > Feature Keys den Feature Key der alten Box removen und den Feature Key der neuen Box importieren. Beachten Sie bitte, dass im Policy Manager ganz unten rechts noch der Hinweis steht, dass es sich um eine Konfigurationsdatei des Typs “Fireware XTM v11.0-v11.3.x” handelt:

Auch bis hierhin alles planmäßig.

Anschließend starten Sie ein “Save to Firebox”. Die eventuelle Warnmeldung “The specified IP address does not match any of the interfaces specified in this config file. Are you sure you want to save to this Firebox?” (…ist klar, weil Ihre alte Konfigurationsdatei höchstwahrscheinlich eben nicht die 10.0.1.1 für eth1 enthält…) bestätigen Sie mit JA.

und erhalten dann eine zweite Warnmeldung: “The configuration file must be upgraded before it can be saved to the v11.4.2 device. Would you like to upgrade the configuration now?”. Auch die bestätigen Sie mit JA.

Anschließend folgt überraschend: “Error communicating with Firebox [IP]. INTERNAL_ERROR: The configuration is invalid, missing application action object”, die Sie nur mit OK bestätigen können.

=> Brechen Sie den Vorgang dann mit CANCEL ab und schließen Sie den Policy Manager.

Öffnen Sie den Policy Manager erneut, und öffnen Sie über File > Open > Configuration File die NEUESTE Version der Konfigurationsdatei, die im Zuge des vorigen “Save to Firebox” gespeichert wurde (ist nur wenige Minuten alt…). Bestätigen/ignorieren Sie die weiter oben bereits beschriebenen Warnmeldungen und starten Sie dann erneut den Vorgang “Save to Firebox”. Beachten Sie in diesem Zusammenhang, dass nun im Policy Manager ganz unten rechts für die Konfigurationsdatei der Typ “Fireware XTM v11.4.2” angezeigt wird:

=> Jetzt – beim zweiten Mal – sollte das Hochladen der Konfigurationsdatei funktionieren:


Danach sollten Sie die neue Box dann auch über die “alten” TCP/IP-Einstellungen auf den entsprechenden Interfaces ansprechen können! [Hinweis: die Firewall-Kennwörter sind nicht Bestandteil der Konfigurationsdatei, sondern hardwarespezifisch! D.h. die neue Firebox hat nicht automatisch die Kennwörter der alten Firebox, sondern die, die Sie ihr über den Setup Wizard verpasst haben!]

WSM und Fireware XTM 11.4.2

2 Comments

Im Software-Download-Bereich der WatchGuard Website stehen seit gestern die neuesten Verisonen WSM und Fireware XTM 11.4.2 für die Geräteserien XTM2, XTM5, XTM8 und XTM1050 bereit. WatchGuard hat den Download- und andere Customer-Care-Bereiche vor zwei Wochen ausgelagert, daher sieht die User-Anmeldeseite mittlerweile anders aus – und auch die dahinter liegenden Inhalte werden “anders präsentiert”, verstecken sich zum Teil oder sind (noch) gar nicht auffindbar… Das ändert/bessert sich hoffentlich in den nächsten Tagen/Wochen/xxx… 🙂

Die Liste der Resolved Issues der Version 11.4.2 liest sich so:

General

  • This release resolves an issue that caused the XTM device to lock up when configured with a combination of proxy policies, subscription services, and FireCluster. [61091]
  • A kernel memory leak and subsequent kernel crash that occured when the XTM device received many packets with MSS =0 has been resolved. [59953]
  • An issue that caused a kernel crash and complete XTM device lock up has been resolved. [59031]
  • This release resolves an issue that caused excessive logging from lighthttpd. [60508]
  • The “message” field from a WatchGuard log message now appears in a syslog message for the same traffic. [60045]
  • The ip_dst_cache cleanup timer has been improved to make sure that the ip_dst_cache table does not become full and cause packets to be dropped. [61558]
  • Dynamic DNS updates now work correctly when the XTM device is configured with a zero route branch office VPN tunnel. [56166]
  • A memory leak in the networkd process has been resolved. [61905]

Networking

  • Blocked sites that are added by IPS are now correctly removed from the Blocked Sites list when the expiration time configured to block them is reached. [60631]
  • An XTM device configured to use the server load balancing feature no longer allows connections to servers that are non-responsive. [60292]
  • Firewall policies are now applied to traffic that passs through two interfaces configured for the same VLAN (VLAN Bridge). [61352]
  • When you enable IPS on a policy configured for VLAN Bridged interfaces, it no longer causes traffic to fail though the policy. [61585]
  • This release resolves an issue that triggered MAC address flapping on Cisco switches when using an active/passive FireCluster. [60619]

Proxies

  • An issue that caused some web pages to not load correctly when using Internet Explorer v8.0 has been resolved. [58259]
  • Several issues that caused some downloads to fail through the HTTP proxy when using Gateway AV has been resolved. [61291] [60654]
  • The XTM device no longer fails to send quarantined emails to the Quarantine Server. [60940]
  • A Custom SOAP web application that required 255 or more requests through the HTTP proxy now works correctly. [58097]

FireCluster

  • This release resolves an issue that caused the master device in a FireCluster to become idle after a Force Failover command is issued. [60217]
  • The Backup Master can now send log messages to a WatchGuard Log Server that is not on the same subnet as the management IP addresses. [61109]
  • A rule to always allow management traffic between the FireCluster management interfaces is now added automatically when you configure FireCluster. This new rule makes sure that management functions to both devices in a cluster are not blocked by policy misconfiguration. [56062]
  • This release improves the performance of FSM when connected to an active/passive FireCluster. [61886]
  • The FSM Status Report tab now correctly displays data for the backup master device in a FireCluster. [60454]

Mobile VPN with SSL

  • This release adds support for multiple Mobile VPN with SSL policies for different users/groups from Policy Manager. [60741]
  • The Mobile VPN with SSL client for Windows now connects correctly to the IP address specified by the user in the connection settings instead of always using the IP address in the Mobile VPN with SSL configuration created by the XTM device. [60082]

Mobile VPN with IPSec

  • The Mobile VPN Shrew Soft client and the Mobile VPN with IPSec client now work with certificates generated by the WatchGuard Management Server. [61380, 61060]

Mobile VPN with PPTP

  • PPTP authentication no longer fails when there are a large number of previous PPTP connections that were not terminated correctly. [61117]

Branch Office VPN

  • You can now use Branch Office VPN with an External Wireless interface. [36232]
  • Ping traffic through a Branch Office VPN tunnel is no longer given low processing priority to improve latency for ping traffic through VPN tunnels. [60427]
  • We have increased the default buffer size for the xfrm_dst_cache on the XTM device to prevent a condition where Branch Office VPN traffic stops when there are many TCP connections through the tunnel. [58141]
  • Tunnels no longer fail with a “no proposal chosen” error when you use a dynamic external interface for the tunnel Gateway. This problem occurred when the gateway name for each gateway was not unique enough, which caused the wrong gateway to be selected for Phase 2. [60594]
  • This release resolved an issue that caused VoIP traffic with the ToS bit set to fail to pass through a Branch Office VPN tunnel. [59479]

Authentication

  • The Terminal Services Agent no longer uses 100% of the CPU when the first user starts an RDP session. [60111]
  • Terminal Server/Citrix users can now use the Interbase SQL client to get access to a remote server. [60847]
  • A Terminal Services Agent installation problem that occurred on some servers has been resolved. [60848]
  • Radius Authentication for PPTP users now works correctly on XTM 2 Series devices. [61164, 61151]
  • The deny message shown for authentication denies that occur because only one authentication is allowed for the same user account has been improved. [59214]
  • We have improved performance when many users authenticate to the XTM device using Firebox-DB authentication. [61760]

Management

  • Firewall policies can now be applied to intra-VLAN traffic. [61382]
  • The Management Server can now correctly apply updates to remote devices using dynamic external interfaces. [61141]
  • When you upgrade from Fireware XTM software v11.3 or earlier to v11.4.x, IPS is no longer disabled for policies that previously had IPS enabled. [61108]
  • Configuration saves now take effect without the need to reboot on XTM 5 Series appliances running v11.4 or v11.4.1. [60074]
  • This release resolves an issue that caused some Management Server backups created in v11.4 to fail to restore. [61075]

Certificates

  • A problem that caused custom web server certificates to not generate correctly has been resolved. [61421]
  • Management connections no longer fail because a web server certificate has many DNS names. [56441]

WatchGuard Log Server

  • LogViewer searches no longer fail to find a match after a new installation of the WatchGuard Log Server. [60411]
  • The WatchGuard Server Center no longer shows an abnormally high maximum database size immediately after a change is made to lower the database size. [61378]

Firebox System Manager (FSM)

  • FSM connections no longer fail if there are three or more FSM instances connected to the same XTM device. [61728]
  • Traffic Monitor no longer stops displaying log messages after a PPTP connection. [61227]

Installations-Problem bei WSM 11.3.2

Comment

Mir ist mittlerweile in ein paar Update-Installationen des WatchGuard System Manager (WSM) 11.3.2 aufgefallen, dass der Installer mit einer Fehlermeldung an ein paar Stellen hängengeblieben ist, die etwas mit den Dateien C:ProgrammeGemeinsame DateienWatchGuardwsm11libnlsen_US logging_res.loc und C:ProgrammeWatchGuardwsm11postgresqllib pgevent.dll zu tun hatten. Wenn die Dateien im Hintergrund z.B. im Windows Explorer umbenannt oder gelöscht werden, kann der Installer anschließend fortgesetzt werden…

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

2 Comments

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

1 Comment

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

1 Comment

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

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.