Category Archives: Technischer Blog

WatchGuard XTM 2 wird warm

Comment

Die aktuellen WatchGuard XTM 21, XTM 22 und XTM 23 Appliances werden im laufenden Betrieb recht warm. Einige Kunden sorgen sich daher über die dauerhafte Zuverlässigkeit. Ich darf folgendes Original-Zitat des PM wiedergeben:

“The 2 Series enjoys a more powerful set of components than were available at the time of Edge development. These components produce more heat that must be dissipated out the 2 Series case. Part of the design of the case is to use the bottom plate as a heat sink, in order to move the heat away from critical components. As such, the user may sense that the bottom plate, or the case overall, is warm or hot to the touch. This is expected, and even desirable to keep the product running in optimal fashion for the entire product life. It is within specifications for this device, and a similar heat output to many laptop computers and power supplies sold into consumer markets.
There is actually a KB article on the 2-Series wireless ‘heat’. Also in the wireless version, we’ve put more powerful, heat producing components in this design as compared with Edge, and we use the bottom plate as a heat sink, which actually siphons the heat away from the sensitive components and keeps your equipment running properly. You know it’s doing its job if it’s warm. Also, it’s been tested many times and is within engineering tolerance.”

Laut WatchGuard ist die Wärmeentwicklung also kein Grund zur Besorgnis. Ich empfehle jedoch darauf zu achten, dass die Wärmeabfuhr über die Unterseite des Geräts nicht behindert wird: Stellen Sie die XTM 2 NICHT oben auf ein anderes Gerät, das ebenfalls warm wird wie z.B. ein DSL-Modem oder einen DSL-Router. Wenn die XTM 2 in einem sehr kleinen abgeschlossenen Gehäuse oder Schrank betrieben werden soll, prüfen Sie bitte ob auch die Wärmeabfuhr aus diesem Schrank heraus gewährleistet wird. Und schützen Sie das Gerät vor direkter Sonneneinstrahlung, die das Gerät nur zusätzlich aufheizen würde…

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.

XCS Feature Keys ohne Firmennamen

Comment

In den letzten Monaten hat die Registrierung einer WatchGuard XCS E-Mail Security Appliance dazu geführt, dass ein sehr umfangreicher “Feature Key” (Lizenzdatei) generiert wurde, in dem unter anderem auch der Firmenname enthalten war, über deren Account die Box aktiviert wurde. Wenn im Firmennamen z.B. Non-ASCII Zeichen wie äöüß enthalten waren – oder sogar nur das &-Zeichen einer “GmbH & Co. KG”, gab es beim Import des Feature Keys in das Produktivsystem Schwierigkeiten.
Stand HEUTE sieht ein Feature Key für eine XCS-Box anders aus und enthält auch keinen Firmennamen mehr:

Serial Number: B0E10024xxxxx
License ID: B0E10024xxxxx
Name: 07-06-2010_17:23
Model: XCS170
Version: 1
Feature: ATTACHMENT_CONTROL@Mar-12-2011
Feature: CENTRALIZED_MANAGEMENT
Feature: CLUSTERING
Feature: CONTENT_RULES_EMAIL@Mar-12-2011
Feature: CONTENT_SCANNING@Mar-12-2011
Feature: DOCUMENT_FINGERPRINTING_EMAIL@Mar-12-2011
Feature: EMAIL
Feature: KASPERSKY@Mar-12-2011
Feature: LIVESECURITY@Mar-12-2011
Feature: OCF_EMAIL@Mar-12-2011
Feature: OUTBREAK_CONTROL@Mar-12-2011
Feature: QUEUE_REPLICATION
Feature: REPUTATION_AUTHORITY@Mar-12-2011
Expiration: never
Signature: x-x-x-x-x-x

Blocked Sites List wegen Skype und Teamviewer

12 Comments

Aktuell erreichen mich Berichte, dass die Verwendung von Skype, Teamviewer und ähnlichen Produkten bei der Version 11.3 mitunter dazu führen, dass die IP-Adressen der INTERNEN Clients auf die Blocked Sites List der Firebox gesetzt werden – und die Firebox dann sämtlichen Datenverkehr von und zu diesen IP’s unterbindet.
Ein Workaround ist, die betreffenden Clients (oder auch das gesamte interne IP-Netz) auf die Liste der Blocked Sites Exceptions zu setzen: Policy Manager: Setup > Default Packet Handling > Blocked Sites: Blocked Sites Exceptions.

Vodafone und WatchGuard MUVPN IPSec Client

1 Comment

Die Vodafone-Software, die den UMTS-Verbindungsaufbau steuert, enthält in einigen Versionen einen Fehler. Wenn bei bestehender UMTS-Verbindung der WatchGuard MUVPN IPSec-Client gestartet wird, wird die UMTS-Verbindung getrennt! Erklärung: im Hintergrund wird eine “Zero-Click-Connect” Verbindung, welche augenscheinlich deaktiviert ist, dennoch ausgeführt. Diese wechselt die Verbindung und es kommt zu dem Abbruch. Die fehlerhaften Versionen der Vodafone-Software versuchen, die Verbindung über den Tunnel aufzubauen, was eben ja nicht möglich ist. Die aktuelle Version 9.49 der Vodafone-Software enthält diesen Fehler nicht mehr.

SSL 100 Feature Key wrong

Comment

Bei der Inbetriebnahme einer WatchGuard SSL 100 SSL-VPN Appliance musste ich heute feststellen, dass der nach Produkt-Registrierung auf der WatchGuard Website heruntergeladene Feature Key korrupt war und die SSL 100 sich mit dem Fehler “Wrong Feature Key” verweigerte. Anders als bei den klassischen WatchGuard Produkten steckt in einem SSL 100 Feature Key u.a. auch der Firmenname und die E-Mail-Adresse des Ansprechpartners, so wie sie im betreffenden Account hinterlegt sind. Wurden bei der erstmaligen Erzeugung des Accounts im Firmennamen Sonderzeichen, Umlaute etc. verwendet, kann dies zu diesem Fehlerbild führen. Im vorliegenden Fall war das &-Zeichen der Übeltäter (eine GmbH & Co. KG…)
Leider kann man den Firmennamen im Account NICHT selbst ändern. Hierzu muss ein Support Incident geöffnet werden oder die Customer Care Abteilung in USA anderweitig informiert werden. Diese entfernt dann verdächtige Zeichen aus der Datenbank. Dieses Verhalten ist von WatchGuard als Bug bestätigt, es gibt aber noch keine Aussage, wann dieser Fehler beseitigt wird.

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…

Wie Auto Negotiation auf HA Port abschalten?

1 Comment

In einem Hochverfügbarkeits-Projekt sollten zwei WatchGuard Firebox X5000 mit Fireware 10.2.11, die bislang “klassisch” per Crossover-Patchkabel miteinander verbunden waren, auf zwei mehrere Hundert Meter auseinander liegende, aber mit ausreichend LWL/Glasfasern verbundene Serverräume verteilt werden. Die Telekom stellte zudem eine Zweiwege-Zuführung bereit. Die beteiligten Router regeln die dynamische Umschaltung der IP-Adressen im Bedarfsfall selbst. Aus Sicht des Firebox-Clusters handelt es sich also um eine einfache, klassische “Static IP” Konfiguration.

Für alle im Einsatz befindlichen Interfaces (hier: External, Trusted und eine DMZ) wurde pro Serverraum jeweils ein dedizierter Cisco-Switch bereitgestellt, die per LWL direkt miteinander verbunden sind. Die HA-Ports der Fireboxen wurden jedoch NICHT über Switche, sondern DIREKT miteinander verbunden – mit zwei Medienkonvertern, die RJ45 auf LWL umsetzen. Bei Inbetriebnahme des Clusters stellte sich heraus, dass die Heartbeats zwischen den Fireboxen nicht korrekt liefen, die Synchronisation der Konfiguration nur teilweise funktionierte und häufig zufällige Failovers ausgelöst wurden.

Problemursache war das offenbar nicht korrekt funktionierende Auto-Sensing zwischen Firebox und Medienkonverter am HA-Interface. Die Konverter waren nicht managebar, also musste seitens der Firebox ein fester Wert für den Betrieb des HA-Interfaces eingestellt werden, z.B. 100 Mbit Full-Duplex. Die GUI des Policy Managers erlaubt dies aber nicht! Sobald HA auf einem Interface aktiviert wird, wird dort automatisch “Auto-Sensing” eingestellt – auch wenn das Interface vorher fest mit 100 Mbit Full-Duplex konfiguriert wurde…

Abhilfe schafft hier der manuelle Eingiff in die XML-Konfigurationsdatei. Nach Aktivierung von HA kann in der XML-Datei für das entsprechende Interface der Wert für < auto-sensing > von 1 auf 0 geändert und die gewünschten Parameter (100 Mbit, Full Duplex) eingetragen werden. Im vorliegenden Fall musste diese Einstellung anschließend auch noch für die zweite Firebox manuell in deren Konfigurationsdatei geändert werden, denn die Synchronisation der Konfigurationen lief auch nach Anpassung der ersten Firebox noch immer nicht korrekt. Danach funktionierte der HA Cluster jedoch korrekt.

Hinweis: Manuelle Eingriffe in die XML-Konfigurationsdatei werden von WatchGuard offiziell “nicht supported” und erfolgen auf “eigene Gefahr”.