Category Archives: Technischer Blog

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”.

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.