Tag Archives: Update

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]

Verlust der Konfigurationsdatei beim Update von v10 auf v11.3.4

2 Comments

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… 🙂

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…

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]

LDAP Authentication für IPSec Mobile User VPN

Comment

In einem Migrationsprojekt von WatchGuard Fireware 10.x nach Fireware XTM 11 fand ich neulich bestätigt, dass bei Fireware XTM 11 das Coding geändert wurde, mit dem die Firebox eine LDAP Authentication (hier: Novell e-Directory) durchführt. Problem war, dass externe Client-PCs mit installiertem IPSec-Client (NCP) nach der Umstellung auf Fireware XTM v11.2.3 zwar die VPN-Einwahl vornehmen konnten, anschließend aber kein Traffic durch den Tunnel geflossen ist. Im Traffic Monitor war der Traffic als Unhandled External Packet zu sehen – allerdings mit korrekt angezeigtem User (z.B. testaccount@LDAP). Insofern war klar: die Firebox hat aufgrund der Rückmeldung vom LDAP erkannt, dass Benutzername und Kennwort korrekt waren. Sie konnte an dieser Stelle ebenfalls die Gruppenzugehörigkeit erkennen und hat aus dem korrekten IP-Adresspool eine Einwahl-IP vergeben. Soweit so gut.

Trotzdem hat irgendetwas verhindert, dass die FIREWALLREGEL, die zu der entsprechenden Mobile User VPN Gruppe gehört, ausgeführt wird – also wurde die Gruppenzugehörigkeit für den Firewall-Part nicht korrekt hinterlegt. Bei der Ursachenforschung wurden mehrere Besonderheiten des Kunden-LDAP beleuchtet, z.B. verwendet der Kunde Leerzeichen im Benutzernamen. Im Endeffekt konnte das Problem jedoch darauf eingekreist werden, dass der LDAP Gruppenname, der eben auch als Name für die MUVPN Gruppe auf der WatchGuard Firebox verwendet wird, aus einer Kombination aus Groß- und Kleinbuchstaben bestand! Wurde also der Gruppenname im LDAP so geändert, dass er entweder NUR aus Großbuchstaben oder NUR aus Kleinbuchstaben bestand und die MUVPN Gruppe gelöscht und mit der neuen Syntax neu erzeugt wurde, FUNKTIONIERTE sowohl VPN-Einwahl als auch Traffic korrekt.
Da der Kunde mit 70 Standorten jedoch international aufgestellt ist und die LDAP Gruppennamen auch noch für andere Softwareprodukte in der bisherigen Schreibweise benötigt wurden, musste das Problem anderweitig umgangen werden. Es zeigte sich, dass die allerneueste Version des NCP-Clients, den WatchGuard als Version 11.2.3 im Software Download Portal bereit stellt, mit der Mischung aus Groß- und Kleinbuchstaben im LDAP Gruppennamen korrekt umgehen kann. Es wurde also entschieden, diesen Anlass zu nutzen und alle mobilen Clients auf den neuesten IPSec-Client upzudaten.

Kein automatischer Reboot nach Migration

Comment

In einem früheren Posting hatte ich beschrieben wie man eine Firebox regelmäßig und automatisch zu einem bestimmten Zeitpunkt booten lassen kann. Ich habe nun Fälle gesehen, dass dies mit Softwareversionen kleiner 11.2.3 überhaupt nicht gegriffen hat – oder nach Migration auf 11.2.3 nicht mehr greift. Ich konnte Abhilfe schaffen, in dem das Häkchen bei Automatic Reboot (Policy Manager: Setup > Global Settings) entfernt wurde, die Konfig auf die Firebox gespeichert wurde, anschließend das Häkchen wieder gesetzt und die Konfig erneut auf die Firebox gespeichert wurde. Der 1:1 Vergleich der XML-Dateien zeigt keinen Unterschied, insofern muss das Setting wohl auf der Firebox selbst hinterlegt gewesen sein.

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.

1-to-1 NAT Probleme bei 11.2.3 HA Active/Passive Cluster

Comment

In der Softwareversion Fireware XTM 11.2.3 ist offenbar ein Bug zurück, der vor ein paar Sub-Releases bereits gefixt war. Im Rahmen eines PCI Compliance Projekts durfte ich letzte Woche einen WatchGuard XTM 1050 Active/Passive Cluster von 11.1 auf 11.2.3 updaten. Nach dem Update mussten wir bei Tests feststellen, dass sich nach einem Failover das EXTERNE Interface nicht sauber initialisieren konnte. Alle anderen Optional und Trusted Interfaces arbeiteten korrekt. Das Problem trat nicht auf, wenn nur EIN Cluster-Knoten eingeschaltet war (zweite Box aus).
Bei der folgenden Analyse stellte sich heraus, dass die in der Konfigurationsdatei hinterlegten 1-to-1 NAT Einträge zusammen mit der aktuellen Softwareversion 11.2.3 das Problem in einer Cluster-Konstellation hervorrufen. Dieses Verhalten wurde von WatchGuard als Bug klassifiziert (BUG44667: 11.2.3 FireCluster A/P connections failing for 1-1-NAT entries). Da dieser Fehler bereits einmal behoben war, rechne ich damit, dass ein Bugfix sehr kurzfristig zur Verfügung stehen wird. In diesem Kundenprojekt wurde jedoch entschieden, dass das NATting künftig bereits auf dem vorgelagerten Router stattfindet, so dass der XTM1050-Cluster nur noch sauber routen braucht.