Category Archives: Technischer Blog

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

Webinterface nun auch bei X Core und X Peak

Comment

Eine der wesentlichen Neuerungen bei der Fireware XTM (Version 11) ist, dass sich nun auch die größeren Modelle der X Core und X Peak Geräteserien über ein Webinterface (auch “WebUI” genannt)administrieren lassen. Von “innen” ist das Webinterface erreichbar über https://IP-der-Firebox:8080. Die Anmeldeseite kennt zwei vordefinierte Usernamen: status und admin. Zu dem User “status” gehört die Status Passphrase (das lesende Kennwort), zu dem User “admin” die Configuration Passphrase (das schreibende Kennwort). Wenn Sie vorhaben, Änderungen am Regelwerk vorzunehmen, müssen Sie sich als User “admin” anmelden! Die Fireware XTM lässt aber zu einem Zeitpunkt nur genau EINE admin-Sitzung zu! Wenn Sie die Firebox über das Internet, sprich von “außen” administrieren wollen, müssen Sie die entsprechende automatisch hinzugekommene Regel für Port 8080 auch für externe IP-Adressen öffnen – hierbei sollte allerdings eher nicht einfach “Any-External” mit in das From-Feld aufgenommen werden, sondern besser nur einzelne, feste IP-Adressen, von denen aus die Administration gestattet werden soll.
Das Webinterface (WebUI) der Fireware XTM unterstützt jedoch nicht alle Funktionen, die über den Policy Manager des WSM nutzbar sind. WatchGuard hat hierzu eine Liste der nicht unterstützten Funktionen in den Release Notes der Fireware XTM (Version 11) bereitgestellt:

The Fireware XTM Web UI does not support the configuration of some features. These features include:

  • FireCluster
  • Full proxy configuration options
  • The editing of static NAT rules
  • Manual policy precedence
  • Certificate export
  • You cannot enable diagnostic logging or change diagnostic log levels
  • You cannot turn on or off notification of BOVPN events
  • You cannot add or remove static ARP entries to the device ARP table
  • You cannot save a device configuration file to your local computer
  • You cannot get the encrypted Mobile VPN with IPSec end-user configuration profile, known as the .wgx file. The Web UI generates only a plain-text version of the end-user configuration profile, with file extension .ini.
  • You cannot edit the name of a policy, use a custom address in a policy, or use Host Name (DNS lookup) to add an IP address to a policy.
  • You cannot use the Web UI to configure a DNS server for the DHCP settings of a wireless guest account. You must use Policy Manager or the CLI to add the DNS server. [39980]
  • If you configure a policy in the Web UI with a status of Disabled, then open Policy Manager and make a change to the same policy, the action assigned to the policy when it denies packets is changed to Send TCP RST. [34118]
  • If you use the Web UI to edit an existing proxy policy that has alarm settings enabled, the alarm settings may be disabled when you save your configuration. [38585]
  • You cannot create read-only Mobile VPN with IPSec configuration files with the Web UI. [39176]

End-Of-Life Datum 25.10.2009 für alte WatchGuard Produkte

Comment

Die Produktlinien SOHO 6 (tc), sowie die alten X Edge (X5, X15, X50 [-w]), X Core (X500, X700, X1000, X2500) und X Peak (X5000, X6000, X8000) Modelle erreichen am 25.10.2009 das so genannte “End-Of-Life” Datum. Das bedeutet nicht, dass die Geräte nach diesem Tag ihre Arbeit verweigern werden. Ab diesem Tag werden lediglich keine neuen Software-Versionen mehr bereitgestellt, es wird keine Ersatzgeräte-Lieferungen im Rahmen der Live Security mehr geben – und die eventuell bisher genutzten UTM Services WebBlocker, spamBlocker und Gateway Antivirus/IPS werden nicht mehr funktionieren. Die normalen Firewall- und VPN-Funktionen werden jedoch unverändert weiter laufen.

Wenn Sie im Rahmen von Ihrem Business Continuity Plan jedoch auf schnelle Hilfe im Problemfall angewiesen sind und die UTM Services fester Bestandteil Ihres IT Security Konzepts sind, sollten Sie dringend auf eine aktuelle WatchGuard Firebox umsteigen. WatchGuard bietet im Rahmen der Trade-Up Promotion 25% Nachlass auf den Preis von ausgewählten Produktvarianten an. Produktnummern und aktuelle Preise finden Sie unter anderem hier: http://www.boc.de/hersteller/watchguard.html.

Die folgenden End-of-Life Richtlinien stammen im Original von der WatchGuard Website. Ich habe sie lediglich auf Deutsch übersetzt:

  • WatchGuard wird End-of-Sale Ankündigungen an seine direkten Partner kommunizieren.
  • Das End-of-Life Datum wird künftig bis zu fünf (5) Jahre nach dem End-of-Sale Datum liegen.
  • Bis zum End-of-Life Datum wird WatchGuard auf freiwilliger Basis Maintenance Releases, Patches, und/oder Hotfixes herausgeben.
  • Verlängerungen von LiveSecurity, UTM Security Services und Hardware Garantieverlängerungen werden grundsätzlich bis ein (1) Jahr vor dem End-of-Life Datum bestellbar sein.
  • WatchGuard behält sich das Recht vor, zwischen dem End-of-Sale und dem End-of-Life Datum UTM Security Services durch andere, gleichwertige Services zu ersetzen.
  • Solche neuen UTM Security Services können eventuell auch nicht mehr mit WatchGuard Produkten kompatibel sein, die sich in oder bereits nach der End-of-Life Periode befinden.
  • Der RMA Prozess wird bis zum End-of-Life Datum aufrecht erhalten, wenn das Gerät durch eine Hardware Garantie abgedeckt ist.