Category Archives: Technischer Blog

Version 11.1 Download und Update-Tipps

3 Comments

Am 13.11.2009 wurde die Version 11.1 freigeschaltet. Die Release Notes weisen auf die breite Unterstützung von Windows 7 für die Komponenten des WatchGuard System Manager (WSM) und der VPN-Clients für mobile User hin. Neu ist jetzt auch die Unterstützung von 64-Bit-Betriebssystemen für den Betrieb von Server Services. Hier ein Screenshot der aktuellen Unterstützungstabelle (aus den Release Notes, betrifft Windows XP 32-bit, Windows XP 64-bit, Vista 32-bit, Vista 64-bit, Windows 7 32-bit, Windows 7 64-bit, Mac OS X v10.5 (Leopard) und Microsoft Windows Server 2003. Hier fehlt leider eine konkrete Aussage über die 64-bit Version. Windows Server 2008 wird in der Tabelle leider überhaupt nicht erwähnt):

Bevor Sie das Update durchführen, lesen Sie bitte aufmerksam die Release Notes. Es kommt wirklich darauf an, welche Softwareversion aktuell auf Ihrer WatchGuard Firebox läuft. Unter Umständen muss ein bestimmter Upgrade-Pfad eingehalten werden. Beispiele:

Firebox X Edge

  • Wenn Sie aktuell 11.0 oder 11.0.1 auf Ihrer Firebox X Edge verwenden, müssen Sie die X Edge zunächst auf 11.0.2 updaten, bevor Sie auf 11.1 gehen. Dies gilt nicht für die X Core oder X Peak Geräteserien.

  • Wenn Sie aktuell 10.2.8 oder niedriger auf Ihrer Firebox X Edge verwenden, müssen Sie zunächst auf 10.2.9 (oder höher) updaten, bevor Sie dann direkt auf 11.1 upgraden können.

  • Wenn sich Ihre Firebox X Edge mit 10.x unter “centralized management” eines WatchGuard Management Servers befindet, können Sie das Update auf 11.1 nicht über die Funktion “Scheduled Firmware Updates” des Management Servers vornehmen, sondern müssen diesen Schritt “standalone” durchführen!

  • Nach dem Update auf 11.1 müssen Sie ggfs. die Konfiguration der Mobile User erneut aktivieren. Dies betrifft Mobile VPN mit IPSec, SSL-VPN und PPTP.

  • Unter 10.x gab es nur ein “Web-Kennwort” für den Administrator. Unter 11.x gibt es für die Administration standardmäßig zwei User: admin (Default-Kennwort “readwrite”) und status (Default-Kennwort “readonly”). Wenn unter 11.x Änderungen an der Konfiguration vorgenommen werden sollen, muss die Anmeldung mit dem User “admin” erfolgen.

  • Wenn Sie sich über einen Browser auf das neue Web-Interface verbinden wollen (https://[IP-der-Firebox]:8080) (Port 8080), muss der Browser “Flash” unterstützen. Wenn nicht, müssen Sie Flash installieren. Hierzu brauchen Sie auf dem PC ggfs. Administrator-Rechte.

  • Wenn Sie das Software-Update auf 11.x durchführen, indem Sie die Datei “utm_edge.sysa-dl” über das Webinterface hochladen, wird Ihre X Edge im Zuge des Updates auf Factory Default zurückgesetzt. Erzeugen Sie VORHER über Administration > Backup ein Backup Ihrer Konfigurationsdatei. Ich empfehle außerdem über Administration > View Configuration den im Hauptfenster angezeigten Text mit Cut&Paste in eine Textdatei wegzuspeichern!

  • Ich rate davon ab, ein Update direkt über das Internet vorzunehmen. Ich empfehle, eine Möglichkeit zu schaffen, sich remote auf einen PC im entfernten Netzwerk hinter der X Edge aufschalten zu können (incoming RDP, Teamviewer, PCvisit) – und das eigentliche Update quasi “lokal” von diesem PC aus durchzuführen.

Firebox X Core, X Peak, XTM1050

  • Um eine Firebox X Core oder X Peak auf 11.1 upzudaten, muss sich diese zunächst auf einer Version 10.2.x befinden.

Software-Update auf 10.2.11 auf alten Firebox X Core und Peak

Comment

Bei den alten Modellen X Core X500, X700, X1000, X2500 sowie X Peak X5000, X6000, X8000 ist bekanntlich am 25.10.2009 das “End-of-Life” Datum erreicht worden, d.h. auch die Live Security ist an diesem Tag ausgelaufen. Ohne gültige Live Security können jedoch keine Software Updates mehr auf die Geräte aufgespielt werden. Wenn jedoch eine alte Firebox X tatsächlich bis zum 25.10.2009 unter Live Security gestanden ist, erstellt WatchGuard auf Antrag im Rahmen eines Support Incident einen 1-Tages-LiveSecurity-Key, mit dem das Gerät noch auf die letzte 10-er Version (10.2.11) upgegradet werden kann. WatchGuard weist jedoch ausdrücklich darauf hin, dass kein Support geleistet wird, sollte bei dem Software-Update etwas schiefgehen. Der Key wird jedoch nicht erstellt, wenn das Ablaufdatum der Live Security VOR dem 25.10.2009 lag, das Gerät auf “Retired” steht oder als Basis für ein Trade-Up verwendet worden ist.

[05.11.2009]: Sollten sich Probleme bei der Abwicklung über WatchGuard USA ergeben, kann auch ich Ihnen gegen Aufwandsentschädigung (ca. 1 Stunde Dienstleistung) helfen. Ich brauche das Gerät dann aber bei mir vor Ort!

X550e und X750e können mit Fireware XTM jetzt auch Gigabit

1 Comment

Obwohl auf der WatchGuard Website bei “Compare Models” die X550e ausdrücklich nur mit “10/100 Fast Ethernet” angegeben ist (Gigabit wird laut dieser Vergleichsübersicht nur von der X750e und X1250e unterstützt), synchronisiert auch eine X550e einen Gigabit Ethernet Link mit Full Duplex. Auch unter Network > Configuration könnten auf den NICs theoretisch auch 1000 Mbps, Full Duplex oder Half Duplex fest eingestellt werden, wovon jedoch abgeraten wird.
Hinweis: Unter Fireware 10.2.x wird Gigabit nach wie vor ausschließlich von der X1250e unterstützt!

Lizensierungsproblem bei FireCluster unter XTM v11.0 und 11.0.1

Comment

In den Versionen Fireware XTM 11.0 und 11.0.1 gibt es im Active/Passive Clusterbetrieb aktuell ein Lizensierungsproblem beim Einsatz der UTM Services. Grundsätzlich reicht es im Active/Passive Modus aus, dass die UTM Services nur auf der PRIMARY Box lizensiert sind. Für die SECONDARY Box reicht die “nackte” Live Security aus. Findet unter 11.0 und 11.0.1 jedoch ein Failover auf die Secondary Box statt, funktionieren die UTM Services WebBlocker, spamBlocker und Gateway Antivirus/IPS dann nicht, da ein Bug die UTM Lizenzen nicht korrekt auf die Secondary Box synchronisiert und die Services dann einfach nicht angewendet werden… Dieser Bug wird mit Version 11.0.2 behoben. Betroffene Kunden können sich in der Zwischenzeit von Customer Care eine temporäre Lizenz für die Secondary Box ausstellen lassen.

Achtung bei Migration auf Fireware XTM: Routing Table – Abarbeitung ändert sich

1 Comment

Momentan habe ich wenig Zeit für meinen Blog, weil jeden Tag neue Support-Anforderungen bei mir eingehen. Admins migrieren ihre WatchGuard Firebox mit bestem Wissen und Gewissen auf Fireware XTM (Version 11) – und erleiden bisweilen Schiffbruch. In den allermeisten Fällen lassen sich die Probleme darauf zurückführen, dass bei Fireware XTM (Version 11) die interne Routing Table der Firebox in einer anderen Reihenfolge abgearbeitet wird als bei der bisherigen Fireware 10.2.x.

Generell gilt bei XTM: VPN hat Vorrang!

Welche Probleme können daraus entstehen und welche Lösungsansätze gibt es:

  • 1. Mobile User VPN. Während noch bei der Version WFS 7.x empfohlen wurde, den IP-Pool für die Einwahl der mobilen User INNERHALB des lokalen LAN-Subnetzes zu definieren (Beispiel: LAN = 192.168.0.0/24, mobile User (egal ob PPTP oder IPSec) bekommen 192.168.0.200 bis 220 zugewiesen), ist dies bei Fireware XTM (Version 11) grundsätzlich ein Problem und führt zu gravierendem Fehlverhalten.

    Verwenden Sie grundsätzlich für die Einwahl von mobilen Usern IP-Bereiche, die in dieser Form an keiner anderen Stelle Ihrer (verteilten) IP-Infrastruktur verwendet werden. Ich persönlich verwende gerne für PPTP den Bereich 172.31.254.1 bis 50, für IPSec 172.31.255.1 bis x (je nach Lizenz) und für SSL-VPN 172.31.253.0/24. Diese Bereiche werden in aller Regel noch nicht für andere Zwecke verwendet – und haben eben den Vorteil, dass die WatchGuard Firebox zu diesen Bereichen ein sauberes Routing fahren kann.

  • 2. Network > Routes. Das Problem hier lässt sich anhand von folgendem Support Fall verdeutlichen: als eth1 (=Trusted) war bei einem Kunden definiert: 192.168.0.1/30, d.h. außer der Firebox gibt es in diesem Subnetz nur noch genau einen weiteren Host, 192.168.0.2. Dies ist ein Standleitungs-Router, der eine Leitung zu einem 10-er IP-Netz am Hauptstandort des Unternehmens bedient, an dem sich auch die AD-Domänencontroller des Unternehmens befinden, über die u.a. auch die Einwahl der mobilen User gegenüber Active Directory authentifiziert wurde (Eintrag unter Setup > Authentication > Authentication Servers > Active Directory). Dummerweise gab es in dieser Konfiguration auch noch einen BOVPN-Tunnel (sprich eine feste Außenstelle), der auf der Gegenseite das IP-Netz 192.168.0.0/24 bedient hat. Während unter der Software-Version Fireware 10.2.x das auf eth1 definierte lokale Netzwerk 192.168.0.0/30 Vorrang hatte und daher die DCs in dem 10-er Netz per Routing erreichbar waren, verhält sich die WatchGuard Firebox unter Fireware XTM (Version 11) nun anders und schickt den Traffic zu dem Standleitungs-Router 192.168.0.2 nun nicht mehr zum lokalen Interface eth1 raus – sondern packt ihn in den Tunnel in die Außenstelle x ein, wo er im Nirwana landet… Problematik klar? In diesem Fall am einfachsten die Konfiguration von eth1 und die IP-Adresse und das Routing des/zum Standleitungs-Router so abändern, dass das verwendete IP-Subnetz an keiner anderen Stelle der Unternehmens-IP-Infrastruktur verwendet wird…

  • 3. Problematik: vermaschte IP-Netze. Unter einem “vermaschten IP-Netz” verstehe ich hier ein verteiltes Netzwerk mit mehreren Standorten, die auf TCP/IP-Basis miteinander kommunizieren können, wobei das Routing jedoch nicht direkt von Außenstelle zu Außenstelle geführt wird, sondern über einen gemeinsamen, zentralen Punkt (i.d.R. ein Rechenzentrum). Auch ich habe in der Vergangenheit Netze gebaut, die in einer Außenstelle z.B. ein IP-Netz à la 10.0.23.0/24 verwendet haben – und einen BOVPN-Tunnel zu 10.0.0.0/8 hinter einem zentralen Gateway angesteuert haben. Dort befand sich eine WatchGuard Firebox X Core oder X Peak, die den Traffic angenommen hat – und auch tatsächlich wieder korrekt in die ebenfalls dort terminierten BOVPN-Tunnel zu den anderen Außenstellen eingepackt hat. Damit ließen sich auch schon in der Vergangenheit zentralisierte VoIP-Lösungen (z.B. Asterisk, Siemens HiPath, Avaya) abbilden. Ein Problem entsteht unter Fireware XTM insbesondere dann, wenn auch das zentrale Netzwerk in einem IP-Subnetz des o.g. vermaschten Netzwerks betrieben wird. Die zentralen Server sind dann aus den Außenstellen heraus nicht mehr korrekt erreichbar. Trifft dieses Szenario auf Sie zu, sprechen Sie mich bitte direkt an, um eine Lösung gemeinsam zu erarbeiten.

  • 4. Allgemein gilt: sofern Ihre IP-Infrastruktur *KLAR* definiert ist und es zwischen den verwendeten IP-Bereichen keine Konflikte/Überschneidungen gibt, wird ein Update auf die aktuelle Version WSM 11.x und Fireware XTM v11.x relativ einfach und überschaubar über die Runden gehen.

Destination IP on Spyware Blocklist

2 Comments

In einem aktuellen Supportfall ging es darum, dass keine E-Mails an eine bestimmte Domain geschickt werden konnten (X Core UTM-Bundle mit Fireware 10.2.9). Im Logfile fanden sich Deny-Meldungen

[…] Q9 Networks Inc, destination IP on Spyware Blocklist, firewall drop (internal policy)

Der Kunde hatte unter Setup > Default Threat Protection > Blocked Sites die Antispyware Blocklist aktiviert, zum Schutz vor Adware, Dialer, Downloader, Hijacker, Trackware.

Interessanterweise befand sich die IP-Adresse des für die Zieldomäne zuständigen Mailservers eben auf dieser Blocklist. Die Firebox verweigert dann sämtlichen Traffic VON und auch ZU diesen IP-Adressen. Nachforschungen haben ergeben, dass diese Liste statisch ist und von WatchGuard selbst gepflegt wird. USA Support hat empfohlen, ein Update auf Version 10.2.11 vorzunehmen, da die betreffende IP-Adresse auf der in 10.2.11 eingebauten Liste nicht mehr draufsteht. Als Alternative kann aber auch die freizugebende Ziel-IP-Adresse bei den Blocked Sites Exceptions eingetragen werden, die zeitlich gesehen offenbar VOR der Antispyware Blocklist abgearbeitet wird.

Falscher Download-Link zum SSO Agent 10.2.11

1 Comment

Aus den Release Notes der Version 10.2.11 geht hervor, dass der SSO Client unverändert auf 10.2.9 bleibt (das optionale MSI-Paket für die Installation auf dem Desktop-PC) – dass es aber einen neuen SSO Agent 10.2.11 gibt (Authentication Gateway), der im Software Download Bereich auch so angeboten wird. Der Download-Link zeigt aber derzeit auf eine falsche Datei, nämlich den alten SSO Agent 10.2.9! Zumindest bei einem Kunden mit einer X Edge musste ich feststellen, dass nach dem Update auf Edge 10.2.11 die User Authentication gegen Active Directory mit dem (alten) SSO Agent nicht mehr funktioniert.

SMTP-Proxy zerschiesst manche Text-E-Mails

1 Comment

Unter Fireware XTM 11.0.1 muss ich feststellen, dass bestimmte Text-E-Mails (ganz einfache text/plain) zerschossen werden. Der eigentliche E-Mail Body ist verschwunden – stattdessen steht nun nur der Text der Deny Message im Body, die aber eigentlich als Textdatei angehängt sein sollte…:

Cause : The message content may not be safe.
Content type : (none)
File name    : (none)
Virus status : No information.
Action       : The Firebox (none) (none).

Your network administrator can not restore this attachment.

Mir fällt auf, dass der folgende Header fehlt, der in korrekt zugestellten E-Mails regelmäßig sichtbar ist:

X-WatchGuard-AntiVirus: part scanned. error action=allow

Das legt die Vermutung nahe, dass das Problem mit einer Interaktion zwischen dem SMTP-Proxy und der Gateway Antivirus Engine zu tun hat. Die Antivirus Engine und die Signaturen der Fireware XTM (Version 11) stammen übrigens jetzt von AVG und nicht mehr wie bisher von ClamAV…

Probleme mit DSL-Modem Speedport 201

6 Comments

Es gibt offenbar Probleme im Zusammenspiel zwischen einer WatchGuard Firebox und dem derzeitigen Standard-DSL-Modem der Telekom, dem Speedport 201. Ich musste dies nun schon mehrfach feststellen – hauptsächlich mit einer X Edge unter Software 10.2.x. Die PPPoE-Einwahl kommt nicht zustande, im Logging ist aber nichts Ungewöhnliches zu sehen, auch nicht im PPPoE-Debugging-Modus. Die Vorgängerversion Speedport 200 hat immer einwandfrei funktioniert, ist aber wohl nicht mehr verfügbar. Eine Alternative wäre ein DSL-Modem eines anderen Herstellers.

Policy Based Routing offenbar auch bei IPSec

1 Comment

Bislang galten die Einstellungen für Policy Based Routing (PBR) im Multi-WAN Betrieb unter Fireware Pro (zwei oder mehr externe Internet-Anschlüsse auf der gleichen Firebox) ausdrücklich nur für ausgehenden non-IPSec Traffic.
Bei der Fireware XTM gilt PBR nun offenbar auch, wenn die Ziel-IP hinter einem VPN-Tunnel liegt. Aufgefallen ist mir dies daran, dass plötzlich ping nicht mehr über einen VPN-Tunnel funktioniert hat – tcp- oder udp-Verkehr hingegen schon. Die “ping”-Regel beim Kunden sah so aus: From: Any, To: Any, und hierbei PBR 2,0 (also bevorzugt eth2 und nur bei Failover eth0). Die VPN-Tunnel terminierten jedoch an eth0. Im Traffic Monitor war kein Problem zu sehen. Die Pakete wurden von der Firewall als Allowed zugelassen, erreichten eben aber nie ihr Ziel…
Es muss nun also noch genauer geschaut werden, wenn mit dem Begriff “Any” gearbeitet wird, denn auch “Any-BOVPN” (also alle BOVPN-Tunnel) sind Bestandteil von “Any”…
Ob dieses neue Verhalten jetzt eher Vorteil oder Nachteil ist, habe ich aus Zeitmangel noch nicht genauer durchdacht… 🙂