Tag Archives: Fireware 11

(K)ein Problem von spamBlocker

Comment

Einen kuriosen Support-Fall durfte ich gestern lösen: seit dem Update auf WatchGuard Fireware XTM 11.2.3 lief der spamBlocker in einem X1250e Active/Passive HA Cluster nicht mehr. Alle Spams kamen ungefiltert durch, im Traffic Monitor stand jedes Mal ProxyAllow: SMTP Message classification is unknown because an error occurred while classifying.
Die Analyse brachte jedoch ein ganz anderes Problem ans Tageslicht: der Status Report des Firebox System Manager vermeldete, dass das externe Interface (eth0) des zweiten Cluster-Knotens keinen Ethernet-Link hatte. Nach Austausch des Patchkabels war der Link wieder da. Nach einem darauf folgenden Failover auf den zweiten Cluster-Knoten lief der spamBlocker wieder.Nach einem erneuten Failover/Failback auf den zuvor “alleine” aktiven Clusterknoten lief spamBlocker wieder nicht. Erst nach einem Reboot des ersten Clusterknoten arbeitete spamBlocker wieder korrekt auf beiden Cluster-Knoten.

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

Unable to load proxy bei 11.2.3

Comment

Wegen ein paar größerer Projekte in den letzten Wochen hatte ich für den Blog leider keine Zeit. Nächste Woche schreibe ich wieder mal ein paar Artikel, denn es gibt doch einiges zu berichten. Hier in aller Schnelle schon mal eine Problembeschreibung, für die es aber schon eine Lösung gibt:

Die Version 11.2.3 hat teilweise Probleme mit Proxy-Regeln. Das äußert sich so, dass Traffic durch Paketfilter einwandfrei abgearbeitet wird (ping, Filtered-DNS usw.), Traffic durch Application Proxies (z.B. HTTP-Proxy, FTP-Proxy, POP3-Proxy, SMTP-Proxy) jedoch nicht. Auf Deutsch: Kunde kann pingen, Namensauflösung funktioniert, er kann aber trotzdem nicht auf Webseiten zugreifen. Im Traffic Monitor tauchen Meldungen auf wie “http-proxy unable to load” oder “proxy failed”.

WatchGuard stellt in diesen Fällen im Rahmen eines Support Incident einen Patch (11.2.3CSP2, appliance build 270901) zur Verfügung, der das Problem behebt (BUG44474: Proxies fail after configuration save).

Probleme beim Update von Gateway Antivirus Signaturen im HA Cluster Betrieb

1 Comment

Mir ist in zwei Cluster-Installationen ein merkwürdiges Verhalten bei den Updates der GAV Signaturen aufgefallen. Verbindet man sich über den Firebox System Manager mit der Cluster-IP, wird bei Subscription Services > Gateway Antivirus als Installed version eine kleinere Zahl angezeigt als bei Version available – es steht also eine aktuellere Version bereit. Wenn man über Klick auf Update ein manuelles Update auslöst, läuft dies auch erfolgreich durch und bei Installed version taucht KURZZEITIG die gleiche Zahl auf wie bei Version available. Nach einigen Sekunden bzw. nach dem nächsten Refresh steht dort jedoch wieder die ursprüngliche, niedrigere Zahl. Ein Klick auf History zeigt jedoch, dass das Update korrekt durchgelaufen ist.
Verbindet man sich nun mit der Management IP der aktiven Box (master), wird dort auch korrekt die höhere Versionsnummer angezeigt. Verbindet man sich mit der Management-IP der Standby-Box (backup master), wird die niedrigere Versionsnummer angezeigt. Offenbar scheitert also der automatische Abgleich zwischen den beiden Boxen, der eigentlich im Hintergrund stattfinden sollte.

Die Lizensierung der UTM-Services beim Active/Passive HA Betrieb erfordert ja, dass NUR auf der Primary Box die UTM Services lizensiert sind, für die Secondary Box reicht die normale Live Security aus. Im Praxisbetrieb gibt es aber offenbar derzeit Schwierigkeiten bei der Synchronisierung der Lizenzen, so dass es wohl vorkommt, dass die UTM-Services nicht korrekt laufen, wenn gerade einmal die Secondary Box die aktive Box (master) ist.
USA Support stellt in diesem Fall neue Feature Keys bereit, wenn im Rahmen eines Support Incidents die betroffenen Seriennummern der Cluster Member angegeben werden. Das Lizenzproblem soll im kommenden Software-Release behoben sein.

Fireware XTM v11 und Windows 2000 Active Directory User Authentication

3 Comments

Die Release Notes von WSM und Fireware XTM v11 enthalten den lapidaren Satz “We no longer support Microsoft Windows 2000”. Eine damit zusammenhängende Erscheinung hat mir die Tage etwas Kopfzerbrechen beschert: User Authentication gegenüber einer nativen Windows 2000 Domäne. Nach dem Upgrade von WSM/Fireware 10.2.7 auf 11.2.1 funktionierte sowohl die Web Authentication über Port 4100 nicht mehr (“user name or password invalid”) als auch die MUVPN-Einwahl über den IPSec-Client (“admd ADM auth Firewall user [xxxxx@Active Directory] Error, Reason – Generic error id=”1100-0012” bzw. “wgcgi Firewall user xxxxx@Active Directory from [IP] rejected – all other error”).
Das liegt daran, dass eine Firebox mit Fireware XTM v11 “anders” in das Active Directory abfragt als die bisherige Fireware 10. Zum Auslesen von Gruppenmitgliedschaften werden jetzt tokenGroups_get Abfragen ins AD gestellt. Damit kann ein natives Windows 2000 Active Directory aber noch nichts anfangen. Erst ein Windows 2003 Domänencontroller kommt damit zurecht. Natürlich sollte heutzutage die AD-Migration kein Problem mehr sein, will aber natürlich trotzdem gut vorbereitet sein. Für die Übergangszeit kann daher mit einem Trick gearbeitet werden, der zwar nicht offiziell supported wird, aber trotzdem funktioniert: anstelle der direkten Active Directory Authentication auf LDAP umstellen – mit ansonsten identischen Einstellungen:

In der Pulldown-Liste von Login Attribute findet sich bei LDAP jedoch nicht das klassische Windows-Attribut sAMAccountName. Dies kann dort aber händisch über die Tastatur eingegeben werden… Natürlich müssen dann ggfs. noch die in Firewallregeln verwendeten Gruppennamen unter Setup > Authentication > Authorized Users and Groups nachgezogen werden. Und unter VPN > Mobile VPN muss auch an den entsprechenden Stellen von Active Directory auf LDAP umgestellt werden.

Spam Quarantine 11.2.1 – User können keine Spams löschen oder weiterleiten

Comment

Bei Nutzung der Spam Quarantine in Verbindung mit spamBlocker, einem der UTM Service, kommt es nach dem Update von WSM 11.2 auf WSM 11.2.1 zu folgendem Verhalten: Ein User, der sich über den Link “Go to Quarantine Server” in seiner Benachrichtigungs-E-Mail an der Weboberfläche der Spam Quarantine angemeldet hat, kann dort nichts löschen oder weiterleiten. Die PopUp-Fehlermeldung lautet: “Enter a numeric value for page number”.

Das Problem wird im nächsten Release behoben sein. Es handelt sich um einen Bug in zwei Steuerdateien für das Apache Frontend: user_messages.tmpl und webui.mo. Ich habe bereits korrigierte Versionen von USA Support bekommen. Bei kurzfristigem Bedarf bitte ein Support Incident öffnen.

Management IP der passiven Box in einem 11.2.1 Active/Passive HA Cluster nicht erreichbar

Comment

In einem Active/Passive HA Cluster unter Fireware XTM v11.x haben beide Firewalls zusätzlich zu der gemeinsamen Traffic IP auch noch jeweils eine eigene Management IP-Adresse. Bei der Einrichtung des Clusters wird gefragt, über welches Interface der Management-Zugriff erfolgen soll. In vielen Fällen wird man das reguläre Trusted Interface wählen, wodurch die Management IP als Secondary IP (z.B. eth1:1) mit auf das Trusted Interface gebunden wird. Die Management IP hat u.a. den Vorteil, dass man nun auch die passive Box in einem Cluster “ansprechen” kann, was vorher nicht ging.

Wenn ein Netzwerk-Monitoring-System im Einsatz ist (z.B. Nagios), wird man daher auch die Management IP Adressen – auch die der passiven Box – überwachen (oder zumindest anpingen) wollen. In einem aktuellen Projekt hat das jedoch nicht funktioniert. Die nähere Untersuchung hat ein Verhalten aufgezeigt, das bei WatchGuard bereits als Bug bekannt ist:
Im passiven Zustand werden alle IP-Adressen von den Interfaces entfernt, bis auf die Management IP (und die Cluster IP auf dem dedizierten HA Interface). Die Subnetzmaske auf dem Interface der Management IP wird jedoch fest auf /24 (255.255.255.0) eingestellt:

– unabhängig davon, welche Subnetzmaske im aktiven Zustand auf diesem Interface eingestellt ist (!):

Zudem enthält die Routing Table der passiven Box kein Default Gateway:

Dies führt dazu, dass die Management IP der passiven Box dem Monitoring-System nicht antworten kann, es sei denn, dass die ersten drei Oktets der IP-Adresse zufälligerweise identisch sind und das Netz größer gleich /24 ist…

Neue Versionen Fireware XTM und WSM 11.2.1 verfügbar

2 Comments

Seit dem 1. März 2010 stehen die neuen Softwareversionen Fireware XTM und WSM 11.2.1 im Download-Portal der WatchGuard-Website zur Verfügung. Mit dieser Version wird nun erstmalig auch Microsoft Windows Server 2008 (32-bit und 64-bit) offiziell als Plattform für die Server Services (Logging, Reporting, Spam Quarantine, WebBlocker Server, Management Server) unterstützt. Es wird jedoch ausdrücklich darauf hingewiesen, dass R2 NICHT unterstützt wird!

Hier die Liste der Resolved Issues in 11.2.1:

  • It is no longer possible to save configuration changes to the Firebox or XTM device with the Escape key and the configuration passphrase. [42609]
  • Per-policy and global NAT settings now apply correctly to IPSec traffic. [39366]
  • This release includes improvements to the Single Sign-on agent software that affected customers with a large number (>1000) of Single Sign-on users. [42406, 42407, 42408]
  • WatchGuard System Manager and Firebox System Manager connections no longer fail after you upgrade your device from Fireware v10.2.11 to Fireware XTM v11.x. [41806]
  • Ping traffic through a branch office VPN tunnel configured to a Firebox or XTM device configured for multi-WAN is now encrypted correctly. [42617]
  • The external IP address of a Firebox X Edge e-Series device is no longer counted as an active IP address in the Outbound Access List. [42581]
  • The Firebox X Edge e-Series no longer includes VPN traffic in the results on the Outbound Access List. [42582]
  • DHCP relay now works correctly with multiple VLANs. [42288]
  • Firebox System Manager no longer fails with the error ” Missing data for XPATH /network/wan/failback_status/failback_status” when connected through an active/passive FireCluster configured with multi-WAN. [42334]
  • The Management Server now correctly handles Edge configuration templates that have properties with values longer than 1023 characters. [42630]
  • The Fireware to Fireware XTM upgrade process now correctly upgrades Mobile VPN resource entries with zero route functionality enabled. [42216]
  • This release resolves an issue that caused management connections to fail after several days of device uptime. [40768]

Proxies

  • The H.323 ALG no longer drops a call when the call is on hold longer than the timeout setting. [40370]
  • The H.323 ALG no longer times out when audio and video content is being sent between Polycom systems. [40377]
  • The H.323 ALG no longer fails with kernel panic error (EIP: 0060: [< 380112c6 >]) when dynamic NAT is not used. [40757]
  • NetMeeting to NetMeeting connections configured to use the H.323 ALG no longer time out when audio and video content is being sent. [40692]
  • Trusted phones configured to use the SIP ALG can now make correctly re-negotiate connections when a call is put on hold several times. [40447]
  • The SIP ALG now correctly recognizes the hold signal and maintains audio and video content after a long hold period. [40100]
  • The HTTP proxy now supports more possible characters in the customizable deny message. [42566]
  • Multi-byte languages are now supported in SMTP notification messages. [38335]
  • The SMTP proxy now correctly recognizes multi-byte attachment file names. [39559]
  • You can now add user email addresses longer than 32 characters to the Quarantine Server. [42283]

Mobile User with SSL

  • The Mobile VPN with SSL client upgrade no longer fails when the client is used with CryptoCard two-factor authentication. [42467]
  • The Force users to authenticate after a connection is lost option now works correctly. [42470]
  • You can now correctly save changes to the Mobile VPN with SSL Advanced configuration. [42426]

Web UI

  • The Firebox X Edge Outbound Access List feature is now available for both wired and wireless devices. [42602]
  • The Web UI can now correctly display third-party certificates. [41324]
  • The HTTP proxy now includes configuration for Application Blocker in the Web UI. [40331]

WatchGuard Servers

  • Symantec Backup Exec backups no longer fail because of an embedded “..” in the registry keys of the WatchGuard server products. [40010]
  • Report Manager now displays the correct counts for “bytes_in” and “bytes_out”. [42628]
  • Report Manager now correctly displays reports after you upgrade your device from Fireware v10.x to Fireware XTM. [42651]
  • On-demand reports generated with the Reporting Web UI now correctly handle the date for non-English locales and generate without error. [42522]
  • Report start and end dates that cross a month boundary are now handled correctly in the Reporting Web UI. [42547]
  • The Reporting Web UI no longer gives an HTTP 403 error when the WSM Report Server is installed in a non-default location. [42552]
  • It is no longer necessary to restart the Report Server and Log Server when you restart the PostgreSQL database. [35063]

SSL VPN Probleme nach Update von 11.1 auf 11.2

1 Comment

In einem aktuellen Supportfall hatte der Kunde seine Firebox X550e von Fireware XTM v11.1 auf 11.2 upgedated. Anschließend konnten die mobilen User über den WatchGuard SSL VPN Client 11.1 keine Verbindung mehr herstellen. Fehlermeldung: “Could not download the configuration file…”.
Ich vermute einen Zusammenhang mit der fehlerhaften Migration der integrierten WatchGuard-eigenen SSL-Zertifikate. Neben den gültigen SSLVPN-Zertifikaten (“Signed”) befinden sich im Zertifikatsspeicher noch weitere Zertifikate im Status “Pending”, die offenbar die gültigen Zertifikate behindern.

Die “Pending” Zertifikate können wie folgt gelöscht werden: Per WSM mit der Firebox verbinden, den Firebox System Manager starten, dort View > Certificates, Pending-Zertifikate anklicken und “Delete”. Anschließend Reboot der Firebox. Handelt es sich um einen Cluster, müssen beide Boxen zur gleichen Zeit ausgeschaltet werden!

Probleme mit self-signed Zertifikaten beim Update auf 11.2

Comment

Mir ist es heute zum zweiten Mal passiert, dass nach dem Update einer Firebox X Core bzw. X Peak von Fireware (Pro) 10.2.x auf Fireware XTM v11.2 zwar die Firewall/VPN-Funktionalität da war, die Box jedoch über den WatchGuard System Manager (WSM) nicht mehr ansprechbar war.

In beiden Fällen führe ich das Problem auf das Vorhandensein bzw. die Nutzung eines selbst generierten 3rd Party Zertifikats für die SSL-geschützte Web Authentication Page (Port 4100) zurück. Die Zertifikate waren jeweils von einer eigenen Active Directory-integrierten Zertifizierungsstelle erzeugt worden, damit beim Laden der Firewall-Anmeldeseite auf den Domänen-Mitglieds-PCs die Warnmeldung des Browsers nicht angezeigt wird. Unter Fireware (Pro) 10.2.x hatte dies auch die ganze Zeit problemlos funktioniert.

Beim ersten Fall vor ca. 2 Wochen stand ich sehr unter Zeitdruck (Downtime…) und habe zur schnellen Problemlösung die Brachialmethode gewählt: Factory Default Reset über das Command Line Interface (CLI) [PuTTY/SSH auf Port 4118 der Firebox, Anmeldung als User “admin” mit der Configuration Passphrase (dem “schreibenden Kennwort”)] und Eingabe des Kommandozeilen-Befehls “restore factory-default”. Hierdurch werden u.a. die Firewall-Kennwörter auf die Fireware XTM v11.x Defaults “readwrite” (für den User “admin” bzw. die Configuration Passphrase) und “readonly” (für den User “status” bzw. die Status Passphrase) zurückgesetzt… Anschließend dann das übliche Spiel: Durchklicken des Quick Setup Wizard, Verbinden per WSM, Öffnen des Policy Managers, Laden der letzten funktionierenden Konfigurationsdatei, Ändern der Einstellungen für das Web Server Certificate und “Save to Firebox”…

Heute konnte ich ein paar Minuten Zeit mehr investieren und habe dabei herausgefunden, dass es offenbar auch ausreicht, auf Kommandozeilenebene die Befehle “configure” und “web-server-cert default” auszuführen – also anstelle des 3rd Party Zertifikats das eingebaute Original-WatchGuard-Zertifikat auszuwählen. Anschließend konnte ich auch sofort wieder per WSM auf die Box zugreifen… Interessanterweise konnte ich anschließend im Policy Manager sogar wieder das 3rd Party Zertifikat auswählen und problemlos wieder aktivieren… Das Problem tritt also offenbar nur genau im Moment des Software Upgrades von 10.2.x auf 11.2 auf. Ich werde mir also angewöhnen, bei Migrationen künftig vorsorglich über Setup > Authentication > Web Server Certificate zunächst das Original-WatchGuard-Zertifikat auszuwählen und erst nach der Migration wieder das 3rd Party Zertifikat zu aktivieren…