Tag Archives: XTM 2

GAV Probleme beim Update der Virenscanner-Patterns auf XTM2-Series

Manchmal kommt es vor, dass keine aktuellen Gateway Antivirus Pattern heruntergeladen werden können. Siehe hierzu auch unseren Blog-Artikel “Crash Report kann AV-Update verhindern”.

Neben diesen “Crash Reports” kann es – je nach Größe des vorhandenen Flash-Speichers in einer WatchGuard XTM/Firebox (vom Modell vorgegeben) – auch zu Problemen mit der Aktualisierung der Antivirus-Pattern kommen, wenn auf der Firebox die Firmware-Images von WatchGuard Access Points gespeichert sind/werden. Dies ist bei älteren Softwareversionen auch standardmäßig der Fall, selbst wenn beim Kunden überhaupt keine WatchGuard Access Points im Einsatz sind. Bekannt ist derzeit ist ein Fall auf der XTM2-Serie (XTM25, XTM25-W, XTM26, XTM26-W), bei dem diese AP Firmware-Images nötigen Speicherplatz blockiert haben, so dass die AV-Updates nicht heruntergeladen bzw. gespeichert werden können. Abhilfe schafft hier das manuelle Löschen der AP Firmware-Images von der XTM/Firebox. Ab der Softwareversion Fireware 11.12.4 sind die AP Firmware-Images auch gar nicht mehr im eigentlichen Firebox-Betriebssystem enthalten und müss(t)en ohnehin einzeln auf die Firebox heruntergeladen werden.

Trifft dieses Szenario zu, sieht die Fehlermeldung bei einem GAV-Update wie folgt aus:

2017-04-14 11:04:12 sigd Manual GAV update is currently running Debug 
2017-04-14 11:04:18 sigd Decompression failed for '/sigs//tmp/incavi.avm' Debug 
2017-04-14 11:04:18 sigd Curl returned error: Failed writing body (4294967295 != 16384) Debug 
2017-04-14 11:04:18 sigd unable to download files for GAV Debug

Web-UI:

  1. Ggfs. Einschalten des Gateway Wireless Controller unter Network => Gateway Wireless Controller => [x] enable the Gateway Wireless Controller (danach muss eine Passphrase vergeben werden)
  2. Danach unter Dashboard > Gateway Wireless Controller (der Punkt existiert sonst nämlich nicht) unter Manage Firmware => Remove all Firmware
  3. Ggfs. Ausschalten des Gateway Wireless Controller unter Network => Gateway Wireless Controller => [_] enable the Gateway Wireless Controller

WatchGuard System Manager

  1. Im Policy Manager nötigenfalls den Gateway Wireless Controller aktivieren: Network => Gateway Wireless Controller => [x] enable the Gateway Wireless Controller
  2. Save to Firebox
  3. Firebox System Manager starten
  4. Im Tab Gateway Wireless Controller => Manage Firmware => Remove all Firmware
  5. Nötigenfalls den Gateway Wireless Controller wieder abschalten: Network => Gateway Wireless Controller => [_] enable the Gateway Wireless Controller

IKE (IPSec) Subsystem einzeln neu starten

Wie man die Neu-Aushandlung von BOVPN Tunneln (einzeln oder alle) über den Firebox System Manager erzwingen kann, dürfte allgemein bekannt sein (FSM > Front Panel > Branch Office VPN Tunnels und dann Rechtsklick auf dieser Zeile oder einem der darunter angezeigten Gateway-Einträge: “Rekey All BOVPN Tunnels” bzw. “Rekey Selected BOVPN Tunnel”). Manchmal reicht dies aber nicht aus und man möchte gerne das komplette IKE/IPSec Subsystem auf der WatchGuard neu starten, um auf diese Weise eventuell auch “quer sitzende” SA-Fragmente los zu werden, die ein einfaches Re-Keying eines BOVPN Tunnels verhindern. Natürlich kann man dazu einfach die komplette WatchGuard neu booten – das geht aber im Produktiveinsatz nicht immer ohne weiteres. Über den Kommandozeilenmodus / Command Line Interface (CLI) gibt es die Möglichkeit, nur den IKE Prozess einzeln neu zu starten und dadurch alle SAs und Fragmente restlos zurückzusetzen:

* Als “admin” per Putty/SSH an der WatchGuard anmelden
* Befehl diagnose vpn “/ike/restart” absetzen
* Mit exit wieder abmelden

Ob der iked Prozess korrekt neu gestartet hat, kann man im FSM auf der Registerkarte “Status Report” sehen. In der Prozessliste sollte für iked nun das aktualisierte Datum/Uhrzeit zu sehen sein.

Reboot der WatchGuard per Script

Dass ein zeitgesteuerter Reboot einer WatchGuard eingerichtet werden kann, dürfte allgemein bekannt sein (im Policy Manager unter Setup > Global Settings > Automatic Reboot). Neulich fragte ein Kunde, ob ein solcher Reboot auch event-gesteuert eingerichtet werden kann. Konkret sollte die WatchGuard jede Nacht durchbooten – aber erst dann, wenn die nächtlichen Online-Backup Jobs zu Ende gelaufen waren. Die verwendete Backup-Software hat die Option, abschließend ein Programm/Script zu starten, das diese Aufgabe übernehmen könnte.
Eine mögliche Lösung sieht so aus: Auf dem Backup-Server wird die 3rd-Party Software Cygwin installiert (http://cygwin.com). Bei der Installation müssen die Module expect und openssh mitinstalliert werden. Das auszuführende Skript sieht in etwa so aus:

#!/usr/bin/expect

set firebox    “a.b.c.d”   ;# IP-Adresse der WatchGuard
set fbusername “admin”     ;# admin Account verwenden
set fbpassword “xxxxxxxx”  ;# admin Kennwort

spawn ssh $fbusername@$firebox -p 4118

# SSH Warnmeldung übergehen bei erstmaliger Anmeldung

set logged_in 0
while {!$logged_in} {
   expect timeout {
    } “Are you sure you want to continue connecting (yes/no)? ” {
      exp_send “yesr”
    } “[Pp]assword*” {
      exp_send “$fbpasswordr”
    } -re “WG.*(#|>)” {
      set logged_in 1
    }
}

# Reboot-Befehl absetzen und SSH Verbindung beenden

set timeout 20
exp_send “rebootr”
  expect timeout {
    } “Reboot (yes or no)?” {
      exp_send “yesr”
    }
expect -re “WG.*(#|>)”
exp_close
exp_wait

Dieses Script kann nun über die Cygwin-Umgebung ausgeführt werden: C:cygwinbinbash.exe –login -c [Dateiname].

Und kann somit flexibel in jegliche Scripting-/Batch-Umgebungen eingebunden werden. Natürlich kann der v.g. Befehl auch wiederum zeitgesteuert ausgeführt werden, wenn über den Task Scheduler / Aufgabenplanung entsprechende Tasks eingerichtet werden. Während die integrierte Funktion “Automatic Reboot…” nur tägliche oder wöchentliche Intervalle zulässt, können auf diesem Weg also auch davon abweichende Reboot-Zyklen umgesetzt werden. Auch alle anderen Command Line Interface (CLI) Befehle lassen sich auf die o.g. Methode von außen scripten… Damit sind viele kreative Ideen umsetzbar, z.B. auch das regelmäßige Auslesen der XML-Konfigurationsdatei und Ablegen auf einen FTP-Server… Die vollständige Referenz der Kommandozeilen-Befehle findet sich auf der WatchGuard Website unter http://www.watchguard.com/help/documentation/xtm.asp

BOVPN Tunnel nur auf Primary IP terminieren!

Ein Kunde berichtete über BOVPN Tunnel, die instabil laufen und häufig abbrechen. Hier folgender wichtige Hinweis: Als Gateway-Adresse darf in der BOVPN-Konfiguration nur die Primary IP eines External Interface verwendet werden – auf keinen Fall eine Secondary IP!Dieser Hinweis ist natürlich nur in einer Umgebung relevant, bei der auf dem/den External Interface(s) als Konfigurationsmethode “Static IP” gewählt ist, also die Kombination aus einer vom Internet Service Provider zugewiesenen IP-Adresse, Subnetzmaske und Default Gateway (typischerweise eine “Standleitung” mit vorgelagertem ISP-Router, z.B. Telekom Company Connect). In einem solchen Fall weist der Provider üblicherweise ein 8-er IP-Netz (/29) oder 16-er IP-Netz (/28) zu. Aus einem solchen IP-Subnetz können theoretisch alle verwendbaren IP-Adressen (5 respektive 13) dem Interface der WatchGuard zugewiesen werden. Hiervon ist nur eine unter Network > Configuration > Interfaces direkt eingetragen (das ist die Primary IP!), die anderen werden über die Registerkarte “Secondary” eingetragen. Jedoch darf eben nur genau die “Primary IP” als Gateway-IP in der/den BOVPN-Konfiguration(en) verwendet werden!!

WatchGuard XTM und Telekom VDSL

Mich erreichen zahlreiche Anfragen bezüglich des Betriebs einer WatchGuard XTM an einem VDSL Anschluss der Telekom. In einem früheren Post hatte ich bereits darauf hingewiesen, dass das Speedport 221 Modem ohne umständliche VLAN-Konfiguration direkt funktioniert, wenn auf der WatchGuard die üblichen PPPoE (V)DSL-Zugangsdaten eingetragen werden. Leider ist dieses Modem auf dem Markt nur noch gebraucht zu bekommen. Ein weiterer VDSL-Kunde hat mir nun berichtet, dass er eine WatchGuard XTM über einen Telekom Speedport W923v Router an VDSL 50 anschließen konnte. Dies ist die beschriebene Vorgehensweise: zunächst den W923v als Router einrichten und mit den PPPoE VDSL-Zugangsdaten versehen. Anschließend den W923v vom “Router” auf “Modem” umstellen, die VDSL-Zugangsdaten aber drin lassen! Auf der WatchGuard dann ebenfalls im Interface die PPPoE VDSL-Zugangsdaten eintragen! Vielleicht kann hier jemand diese Vorgehensweise bestätigen oder gerne auch andere Wege aufzeigen, wie eine WatchGuard XTM erfolgreich an einem VDSL-Anschluss betrieben werden kann.

Secondary IP nicht auf VLANs

Ich musste aktuell in einem Projekt feststellen, dass Secondary IPs nur auf physikalischen Interfaces konfiguriert werden können, nicht aber auf VLANs. Ich konfiguriere Secondary IPs z.B. sehr gerne auf External Interfaces, um damit mehrere (oder alle) vom Provider zugewiesenen externen IP-Adressen auf einem externem Interface verfügbar zu machen, so dass diese für eingehenden Datenverkehr als Basis für einen SNAT-Eintrag (Statisches NAT oder Server Load Balancing) verwendet werden können.
In dem angesprochenen Projekt musste das neu hinzu kommende externe Interface aber auf einem VLAN-Interface konfiguriert werden. Hier konnte ich die weiteren IPs nur auf dem Weg über 1-to-1-NAT Einträge nachträglich verfügbar machen, was aber natürlich deutlich weniger flexibel ist wie die typischen SNAT-Einträge, die z.B. nur einen bestimmten Port einer IP-Adresse zu einem bestimmten internen Server weiterleiten…

Maximal vier physikalische External Interfaces

Aus früheren Zeiten hat auch die aktuelleste Fireware XTM 11.4.2 noch die Beschränkung, dass maximal vier physikalische Interfaces konfiguriert werden können. Wenn aber doch einmal MEHR als vier externe Interfaces konfiguriert werden sollen, bleibt noch der Weg über VLANs. Hierbei wird z.B. ein physikalisches Interface der WatchGuard als VLAN-Interface eingerichtet – und die ganzen externen Anschlüsse dann eben als Tagged VLAN mit unterschiedlichen VLAN-IDs. Zwischen der WatchGuard und den externen Leitungen sitzt dann ein VLAN-fähiger Switch, auf dem die gleichen VLAN-IDs konfiguriert sind. Die verschiedenen ISP-Router sind dann jeweils an einem Untagged Port angeschlossen, der dem passenden VLAN zugeordnet ist. Der Switch-Port, an dem die WatchGuard angeschlossen wird, muss als Trunk Port eingerichtet werden (Tagged).

Auf diese Weise kann man natürlich auch physikalische Ports auf der WatchGuard einsparen, wenn es in komplexen Umgebungen einmal eng wird. Statt z.B. mehrere Trusted oder Optional Networks direkt als physikalische Interfaces auf der WatchGuard einzurichten, können diese auch als VLANs auf einem VLAN-Switch abgebildet werden, der nur über ein einzelnes Kabel an der WatchGuard angeschlossen ist…

Probleme mit PPTP-VPN

In der letzten Zeit stolpere ich häufiger über Probleme mit Mobile User VPN über PPTP, die nach einiger Zeit im laufenden Betrieb oder nach einer Hardware-Migration auftreten. Die WatchGuard verweigert einfach die PPTP-Einwahl, obwohl sich an der Konfiguration, Benutzername, Kennwort und Client-Einstellungen nichts geändert hat. Wenn auch ein Reboot der WatchGuard nicht weiter hilft, hat sich folgender Trick bewährt:

  • Aktuelle Konfigurationsdatei (XML) unter einem anderen Namen sichern.
  • VPN > Mobile VPN > PPTP… komplett deaktivieren (Häkchen entfernen).
  • Eventuelle Firewall-Regeln löschen, die auf Basis der Gruppe “PPTP-Users” geschrieben waren.
  • “Save to Firebox”
  • File > Open > Configuration File (die zuvor auf die Seite gelegte Version öffnen)
  • “Save to Firebox”

Nun sollte die VPN-Einwahl per PPTP wieder funktionieren. Eine Erklärung dafür habe ich nicht.

Diagnostic Tasks / Extended Ping / TCP Dump

Eine relativ unbekannte Funktion des Firebox System Managers sind die Diagnostic Tasks, die im Traffic Monitor per Rechtsklick mit der Maus erreicht werden können:

Eine Funktion ist Extended Ping, mit dem z.B. pings von der Firewall selbst aus gestartet werden können – und zwar auch unter Angabe des tatsächlich zu verwendenden Interfaces! Das kann gerade im Multi-WAN Umfeld interessant sein, wenn geprüft werden muss, ob ein bestimmter Ziel-Host auch genau über das angegebene Interface erreichbar ist (Problematik vgl. http://de.watchguard-blog.com/2011/08/multi-wan-und-policy-based-routing.html). Ein weiterer Anwendungsfall kommt aus dem Umfeld Dynamic Routing, wenn geprüft werden muss, ob das Routing eben auch auf den alternativen Wegen/Interfaces möglich ist. Die Advanced Options werden erst angezeigt, wenn das entsprechende Häkchen gesetzt ist. Im u.g. Screenshot wird die Ziel-IP 10.10.10.200 direkt von der Quell-IP 192.168.1.1 (Firebox Interface) angepingt:

Mittels TCP Dump lässt sich z.B. rudimentär mit verfolgen, welche Datenpakete auf welchem Interface transportiert werden – auch ohne dass sie zwingend im Traffic Monitor angezeigt werden:

Traffic Management funktioniert nicht richtig unter 11.4.1

In der Version 11.4.1 hat sich ein Bug in den Bereich Traffic Management eingeschlichen. Eine Traffic Management Action, die eine Bandbreitenbegrenzung für den Fall enthält, dass der Verbindungsaufbau zwar in ausgehende Richtung erfolgt – der eigentliche Traffic aber von außen nach innen fließt, greift derzeit nicht!
Dies betrifft leider auch den “typischen” Anwendungsfall, dass HTTP Downloads bzw. allgemein das “Websurfen” nur eine begrenzte Bandbreite verwenden dürfen… 🙁