Category Archives: Technischer Blog

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.

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.

Quick Setup Wizard 11.2.3 und XTM 830

Comment

Ich konnte nun bei der Erst-Inbetriebnahme von zwei WatchGuard XTM 830 sehen, dass der Quick Setup Wizard der Version 11.2.3 bei diesem Modell offenbar etwas Probleme hat festzustellen, dass die Installation eigentlich korrekt durchgelaufen ist. Trotz Fehlermeldungen seitens des Quick Setup Wizard waren beide Boxen korrekt installiert und konnten anschließend auch sauber als HA Active/Passive Cluster in Betrieb genommen werden.

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.

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