Ich musste heute wieder einmal feststellen, dass der Download der WebBlocker Datenbank furchtbar langsam und abgehackt ist (zumindest von Deutschland aus dem Telekom-Backbone…). Ich verweise einfach mal auf ein früheres Posting, das schon damals die Lösung/Workaround beschrieben hat: https://www.boc.de/watchguard-info-portal/webblocker-download-und-update-langsam/.
Begriffsbestimmung “WatchGuard System Manager”: Dieser wird auch im internen WatchGuard-Sprachgebrauch etwas uneindeutig verwendet.
Zum einen taucht er auf bei den Software Downloads und steht dort für die Software-Komponenten, die für die Installation auf einem Windows-basierten “WatchGuard Management Computer” gedacht sind. Der Dateiname für die aktuelle Version 11.4.2 lautet z.B.: WSM11_4_2s.exe (s steht hierbei für Strong Encryption) oder WSM11_4_2b.exe (b für Base Encryption – wenn z.B. beim Anlegen Ihres WatchGuard Accounts etwas schief gelaufen ist und Sie versehentlich in einem Land angesiedelt wurden, das unter US-Export-Beschränkungen steht 😉 Einen solchen Fehler sollten Sie schleunigst über einen Support Incident bei WatchGuard beheben lassen…)
Zum anderen wird der Begriff WatchGuard System Manager auch etwas irreführend für den Server Service “WatchGuard Management Server” verwendet. Das ist der Nachfolger des früheren “VPN Manager”, also die Möglichkeit, mehrere WatchGuard Fireboxen zentral zu verwalten und Branch Office VPN Tunnel zwischen den angeschlossenen Standorten per Mausklick einzurichten… Der “WatchGuard Management Server” ist ein optionales Kaufprodukt, das in 5-er Schritten (auch 25, 50, 100) zusätzlich erworben werden kann (taucht in den Preislisten lustigerweise auch wieder als “WatchGuard System Manager” auf…). Wenn Sie mindestens eine X750e oder eine XTM 505 in Ihrem Account haben, hat WatchGuard Ihnen bereits kostenfrei eine Lizenz für 4 Standorte bereitgestellt. Diese finden Sie bei Ihren “Activated Products”: Die Lizenznummern beginnen mit WSMMGR-1-xxx, WSMMGR-4-xxx, WSMUPGRADE-5-xxx o.ä. Nun ja, zumindest fanden Sie dort die Lizenznummern, bevor WatchGuard am 02.07.2011 das Customer Portal umgestellt hat… 😉 Sie werden irgendwann dort auch einmal wieder erscheinen. Vorher hilft nur ein Support Call, mit der Bitte, die entsprechende(n) Lizenznummer(n) telefonisch oder per E-Mail oder im Support Incident bekannt zu geben…
Hinweis: es kann immer nur eine WSMMGR- (Basislizenz) verwendet werden. Die Anzahl der lizensierten Standorte lässt sich dann nur durch WSMUPGRADE- (Erweiterungslizenzen) erhöhen.
Den Installer WSM11_4_2s.exe können Sie auch ohne diese Lizenznummer(n) vollständig durchklicken und je nach Bedarf sowohl die Client Komponenten als auch die Server Services “Management Server”, “WebBlocker Server”, “Logging Server”, “Quarantine Server” und “Report Server” erfolgreich installieren.
Wenn Sie jedoch anschließend die Server Services über das WatchGuard Server Center konfigurieren (und bei der Installation den “Management Server” angeklickt haben), werden Sie zur Eingabe der Lizenznummer(n) aufgefordert. Dies können Sie zwar überspringen, jedoch wird der Management Server erst dann funktionstüchtig sein, wenn Sie die Lizenznummer(n) nachträglich über das WatchGuard Server Center eingetragen haben.
Hinweis: Wenn Sie überhaupt nur eine einzelne WatchGuard Firebox besitzen, bringt Ihnen der Management Server auch gar nichts. Sie sollten dann beim Durchklicken des WSM11_4_2s.exe Installers das Häkchen beim Management Server einfach weg lassen.
Verwirrt? Na ja, kommt wie gesagt auch in den besten Kreisen vor… 🙂
In manchen VPN-Projekten kommt es vor, dass nicht nur der netzinterne Verkehr von Außenstellen durch einen VPN-Tunnel zur Zentrale geroutet wird, sondern auch der gesamte Internet-Traffic. Dann können nämlich z.B. auch die möglicherweise nur in der Zentrale vorhandenen UTM Security Services (WebBlocker, spamBlocker, Gateway Antivirus, Intrusion Prevention Services, Reputation Enabled Defense) auf den Internet-Verkehr der Außenstellen angewendet werden, wo möglicherweise nur WatchGuard Firebox Produkte mit Live Security eingesetzt werden.
Dabei muss natürlich berücksichtigt werden, dass über die Internet-Leitung in der Zentrale eben auch der komplette Internet-Traffic der Außenstelle(n) läuft – und das nicht nur einmal, sondern DOPPELT (aus dem Internet in die Zentrale und weiter über den VPN-Tunnel in die Filiale).
Im Branch Office VPN Tunnel wird dies häufig über die Verwendung der BOVPN Tunnel Route Local Network <-> 0.0.0.0/0 realisiert.
Wenn in der Außenstelle jedoch keine feste IP-Adresse existiert, sondern mit einem DYNDNS-Hostname gearbeitet wird, führt dies gerade in Verbindung mit dem WatchGuard Management Server zu Problemen. Der auf der WatchGuard laufende DYNDNS-Updater meldet eine Adressänderung nämlich per http an einen Webserver von DYNDNS. Dieser http-Verkehr wird jedoch von der Firebox oder XTM Appliance nicht direkt ins Internet hinaus geroutet, sondern durch den 0.0.0.0/0 Tunnel zunächst in die Zentrale geschickt und von dort aus weiter zu DYNDNS. Das hat aber zur Folge, dass die “gemeldete” IP-Adresse nicht zu der Quell-IP-Adresse passt, von der die Meldung bei DYNDNS eingeht. DYNDNS verweigert daher das Update des DNS-Eintrags, und der WatchGuard Management Server und die am VPN-Tunnel beteiligte zentrale Firebox haben ein Problem, die Außenstelle zu “finden”.
In einem solchen Fall sollte die Außenstelle in einen Internet-Tarif wechseln, bei dem eine feste öffentliche IP-Adresse möglich ist.
Mir ist in zwei Cluster-Installationen ein merkwürdiges Verhalten bei den Updates der GAV Signaturen aufgefallen. Verbindet man sich über den Firebox System Manager mit der Cluster-IP, wird bei Subscription Services > Gateway Antivirus als Installed version eine kleinere Zahl angezeigt als bei Version available – es steht also eine aktuellere Version bereit. Wenn man über Klick auf Update ein manuelles Update auslöst, läuft dies auch erfolgreich durch und bei Installed version taucht KURZZEITIG die gleiche Zahl auf wie bei Version available. Nach einigen Sekunden bzw. nach dem nächsten Refresh steht dort jedoch wieder die ursprüngliche, niedrigere Zahl. Ein Klick auf History zeigt jedoch, dass das Update korrekt durchgelaufen ist.
Verbindet man sich nun mit der Management IP der aktiven Box (master), wird dort auch korrekt die höhere Versionsnummer angezeigt. Verbindet man sich mit der Management-IP der Standby-Box (backup master), wird die niedrigere Versionsnummer angezeigt. Offenbar scheitert also der automatische Abgleich zwischen den beiden Boxen, der eigentlich im Hintergrund stattfinden sollte.
Die Lizensierung der UTM-Services beim Active/Passive HA Betrieb erfordert ja, dass NUR auf der Primary Box die UTM Services lizensiert sind, für die Secondary Box reicht die normale Live Security aus. Im Praxisbetrieb gibt es aber offenbar derzeit Schwierigkeiten bei der Synchronisierung der Lizenzen, so dass es wohl vorkommt, dass die UTM-Services nicht korrekt laufen, wenn gerade einmal die Secondary Box die aktive Box (master) ist.
USA Support stellt in diesem Fall neue Feature Keys bereit, wenn im Rahmen eines Support Incidents die betroffenen Seriennummern der Cluster Member angegeben werden. Das Lizenzproblem soll im kommenden Software-Release behoben sein.
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.
Bisweilen findet man im Traffic Monitor Einträge wie:
proxy[1756] webblocker server=IP:5003/udp is now active
proxy[1756] webblocker server=IP:5003/udp is now inactive
proxy[1756] webblocker server=IP:5003/udp is now active
proxy[1756] webblocker server=IP:5003/udp is now inactive
Diese Meldungen haben nur informellen Charakter, man kann sie getrost ignorieren. Das Verhalten ist durchaus normal und tritt dadurch auf, dass der WebBlocker-Dienst eine gewisse Zeit lang nichts zu tun hat, wodurch die udp-Verbindung zwischen der Firebox und dem WebBlocker Server in einen idle-Timeout läuft, getrennt wird und dadurch die Meldung “inactive” auslöst. Wenn der WebBlocker dann das nächste Mal wieder angesprochen wird, springt der Status wieder auf “active”. In den allermeisten Fällen liegt somit kein akutes Problem vor.
Updates der WebBlocker-Datenbank können auch automatisiert werden. Im Unterverzeichnis C:ProgrammeWatchGuardwsm10.2bin befindet sich eine Batch-Datei names updatedb.bat, die mit Hilfe des Windows Task Scheduler auch unbeaufsichtigt ausgeführt werden kann (Windows / Start / Alle Programme / Zubehör / Systemprogramme / Geplante Tasks). Die Batch-Datei beendet zunächst den WebBlocker-Dienst, schaut dann nach Updates und startet den Dienst erneut.
Zu beachten ist, dass der HTTP-Proxy standardmäßig keinen Webzugriff zulässt, wenn der WebBlocker-Dienst nicht läuft. Dieses Verhalten kann im Policy Manager über Tasks / WebBlocker… / Configure… und nochmals Configure… auf der Registerkarte Advanced geändert werden. Ich wähle hier üblicherweise die Einstellung “If your Firebox cannot connect to the WebBlocker server in 5 seconds then Allow the user to view the website”. Außerdem muss sichergestellt sein, dass der WebBlocker-Server direkten, gerouteten http-Zugriff auf das Internet über Port 80 hat.
Ein Get Full Database oder Get Incremental Update der WebBlocker-Datenbank ist in manchen Installationen derzeit extrem langsam. Hierbei handelt es sich um ein DNS-Problem. Die DNS-Server der Deutschen Telekom zum Beispiel liefern für den (im Hintergrund fest hinterlegten Hostname listsrv.surfcontrol.com derzeit die IP 204.15.69.70 zurück. Die Performance dieses Servers lässt aber sehr zu wünschen übrig. Wesentlich (!!!) schneller ist der 204.15.67.70, der z.B. von amerikanischen DNS-Servern aufgelöst wird.
Man könnte nun entweder dafür sorgen, dass für die DNS-Auflösung ein anderer Forwarder verwendet wird (zum Beispiel 4.2.2.2) – oder auf dem WebBlocker-Server einen Eintrag in die lokale HOSTS-Tabelle schreiben. Diese liegt auf Windows-Systemen unter C:windowssystem32driversetc und heisst einfach nur “hosts“. Die Datei kann mit einem Texteditor bearbeitet werden:
Anschließend noch den DNS-Cache leeren: ipconfig /flushdns und den Download/Update erneut starten. Dies ist natürlich nur eine Übergangslösung. Man sollte im Auge behalten, wann sich die DNS-Auflösung auf dem standardmäßigen DNS-Server wieder entsprechend ändert – und dann den Eintrag in der HOSTS-Tabelle wieder rückgängig machen, um nicht bei einem möglicherweise in der Zukunft stattfindenen Wechsel der IP-Adresse plötzlich im Regen zu stehen…
