Category Archives: Technischer Blog

IKE (IPSec) Subsystem einzeln neu starten

2 Comments

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

5 Comments

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

Korruptes Zertifikat entfernen

1 Comment

Vor ein paar Tagen hatte ich mit einer X750e (Softwareversion Fireware XTM 11.3.4) zu tun, die im Basic Managed Mode als Außenstelle an einem WatchGuard Management Server lief (Softwareversion WSM 11.5.3). Die BOVPN-Tunnel waren als Managed VPN Tunnels über den Management Server eingerichtet. Die BOVPN-Tunnel kamen nicht mehr hoch und die X750e ließ über WSM / Policy Manager auch keine Änderungen an der Konfiguration zu – auch dann nicht, wenn man mit einem lokalen WSM direkt mit der Box verbunden war. Fehlermeldung beim Schreiben einer Konfiguration: “An error occured while retrieving all certificates from the Firebox [IP]). Unable to send request to module”. Ein Neustart der Box brachte keine Änderung.

Die Fehlersuche zeigte Probleme mit den Zertifikaten auf der X750e. “View… Certificates” aus dem Firebox System Manager konnte die Zertifikate nicht anzeigen (leeres Feld und darüber eine leere Fehlermeldung).

Auch im CLI Modus brachte der Befehl “show certificates” nur eine Fehlermeldung. Der certd daemon lief auch nicht. Ich hatte einen ähnlichen Fall bereits vor ein paar Monaten. Damals waren auch Zertifikate kaputt, die Box ließ sich jedoch noch über WSM / Policy Manager administrieren. Damals konnte ich das Problem durch ein Software-Update auf eine neuere Fireware XTM Version beheben. Vermutlich hätte auch das Aufspielen der gleichen Version geholfen. Da jetzt aber WSM / Policy Manager nicht mehr funktionierten, habe ich dieses Mal über das Web-Interface gearbeitet (System > Upgrade OS) und auf diesem Weg die 11.3.4er sysa-dl Datei erneut hochgeladen. Nach dem Reboot war certd wieder da und die Zertifikate waren wieder sichtbar. Anschließend konnte die Box auch wieder an den zentralen Management Server angebunden werden, jedoch kamen die Managed VPN Tunnel immer noch nicht hoch. Als nächstes habe ich den zentralen WSM / Management Server näher untersucht. Beim Versuch, die Managed VPN Tunnel neu anzulegen, stürzte der WSM jedes Mal mit einer Fehlermeldung der AppMngr.exe ab. Ein Neustart des Dienstes half nicht, auch nicht der Reboot der kompletten Windows Server 2008 Maschine.

Als temporären Workaround wollte ich nun den BOVPN Tunnel zwischen der Außenstelle und dem zentralen System (ein XTM 810 Active/Passive Cluster mit Fireware XTM 11.5.3) manuell anlegen, damit die User zumindest erst einmal wieder arbeiten konnten. In der XML Konfigurationsdatei des zentralen XTM810 Clusters ist mir dann aufgefallen, dass dort noch die DVCP-basierte Gateway- und Tunnel-Definition der alten “Managed VPN” Verbindung angezeigt wurde, obwohl diese eigentlich gar nicht mehr vorhanden sein sollte. Durch ein Cluster Failover verschwanden diese Fragmente dann aus der zentralen Firewall-Konfiguration, woraufhin auch der WSM / Management Server nicht mehr abschmierte und schlussendlich der BOVPN Tunnel doch wieder regulär als “Managed VPN” Tunnel erfolgreich eingerichtet werden konnte…

BOVPN Tunnel nur auf Primary IP terminieren!

5 Comments

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

5 Comments

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.

Reboot / Einschaltproblem bei XTM 5

1 Comment

Ein Kunde hat berichtet, dass seine XTM 505 nach einem über den Firebox System Manager ausgelösten Reboot nicht wieder sauber hochgefahren ist. Auch ein Neustart über den Ein-/Aus-Taster am Gerät (wie bei einem PC, den man hart neu starten will: 6 Sekunden gedrückt halten) brachte keinen Erfolg: im LCD-Display waren nur ein paar unleserliche Zeichen zu sehen.
Nachdem jedoch das Stromkabel gezogen und nach ca. 1 Minute wieder eingesteckt wurde, ist die XTM 505 nach dem Einschalten wieder ganz normal hochgefahren – und hatte auch noch die zuletzt aktive Konfiguration!
WatchGuard hat hierzu auch einen offenen BUG. Offenbar zicken die Netzteile, die in einem gewissen Seriennummern-Bereich verbaut worden sind, bisweilen etwas herum… Also: bei seltsamen Verhalten der Hardware einfach mal komplett den Stromstecker ziehen… 😉

Neue XTM 33 wird nicht mehr warm

Comment

Neu in der WatchGuard-Preisliste Januar 2012 sind die Modelle XTM 33 und XTM 33-W. Optisch gleichen die Geräte der XTM 2. Im Inneren arbeitet jedoch eine DEUTLICH leistungsfähigere Hardware mit einer schnelleren CPU und doppelt so viel Hauptspeicher (512 MB) wie bei einer XTM 2. Angeboten wird eine normale “wired version” XTM 33 – und eine Wireless Version XTM 33-W mit integriertem WLAN Accesspoint.
Auf der WatchGuard Conference 2012 in Neuss wurde eine XTM 33 für den WLAN-Zugang der Teilnehmer verwendet. Auch bei gleichzeitiger Nutzung durch ca. 30-40 User war kein Leistungseinbruch bei der Performance – und auch keine nennenswerte Erwärmung feststellbar! (Die XTM 2 Modelle werden im laufenden Betrieb teilweise recht warm. WatchGuard begründete dies bislang mit Hardware-Design-Gründen: die Metallunterseite der XTM 2 wird als passiver Kühlkörper mit verwendet).
Auch bei einer XTM 33 ist das XTM Pro Upgrade bereits im Lieferumfang enthalten. Jedoch wird es – anders als bei der XTM 330 – künftig keine Freischaltung der HA (Cluster) Funktionalität für die XTM 33 geben!
Die XTM 33 liegt preislich 10% unter der XTM 330.

XTM 330 soll HA (Cluster) fähig werden

Comment

Die Watchguard XTM 330 wird ab Werk bereits mit dem XTM Pro Upgrade und den damit verbundenen Funktionserweiterungen wie Multi-WAN, Policy Based Routing, Dynamic Routing, QoS und der Maximalzahl der vorgesehenen 55 SSLVPN-User ausgeliefert. Bei den größeren Modellen ab XTM 5 aufwärts ist bei XTM Pro auch die Cluster-Fähigkeit (HA) in den Versionen Active/Active und Active/Passive enthalten.
Derzeit wird jedoch bei der XTM 330 kein HA (Cluster) unterstützt!
In einer der künftigen Softwareversionen soll jedoch die Clusterfähigkeit auch für die XTM 330 freigeschaltet werden!

Lauter Lüfter bei XTM 330 soll leiser werden

1 Comment

Das im Dezember 2011 erstmals ausgelieferte neue 19″ 1HE Modell WatchGuard XTM 330 überzeugt durch eine ausgewogene Kombination aus Dual-Core CPU und 1 GB Hauptspeicher.
Damit ist das Gerät künftig sicher die erste Wahl für kleine Unternehmen bis etwa 100 Mitarbeiter, die eine professionelle 19″ Hardware Firewall/VPN Appliance suchen, die auch in der Lage ist, alle verfügbaren WatchGuard Security Services (WebBlocker, spamBlocker, Gateway Antivirus, Intrusion Prevention Service, Reputation Enabled Defense und Application Control) performant abbilden zu können. Preislich liegt die XTM 330 genau 20% unter der XTM 505, wenn man berücksichtigt, dass das XTM Pro Upgrade bei der 330 bereits enthalten ist, aber bei der 505 separat dazu bestellt werden muss.
Während die XTM5 bereits temperaturgesteuerte Lüfter hat, die ein solches Gerät angenehm leise machen, laufen die Lüfter bei der XTM 330 derzeit ständig auf 100% und erzeugen einen hohen Geräuschpegel, der eigentlich nur in einem Serverraum erträglich ist… 🙂
Es soll jedoch demnächst ein Software-Update/Patch geben (BIOS-Update für die XTM 330), so dass auch bei diesem Modell die Temperatursteuerung funktioniert und die XTM 330 im Normalbetrieb deutlich leiser werden soll.

(Wert-)schöpferische Phase beendet…

2 Comments

Das schlechte Gewissen reist ständig mit. Seit Oktober 2011 habe ich jetzt hier auf dem Blog nichts mehr geschrieben. Begründen und entschuldigen kann ich das nur mit dem Hinweis auf die Vielzahl von WatchGuard-Projekten, die wir (BOC Computersysteme GmbH) im 4.Quartal 2011 umgesetzt haben. Knapp 200 neue WatchGuard-Boxen wurden alleine in diesen drei Monaten verkauft und großteils auch von uns installiert. Auf der WatchGuard Conference am 19.01.2012 in Neuss durfte ich dafür auch die Auszeichnung Best Performing Partner 2011 Central EMEA (Europe, Middle East and Africa) entgegen nehmen. Dazu kommen noch die Lizenzverkäufe (LiveSecurity Renewals und UTM Software Suite bzw. Security Services Verlängerungen) und die “ganz normalen” Wartungs-Dienstleistungen und Software-Migrationen, teilweise auch schon auf die neue Fireware XTM 11.5.1. Über die Erfahrungen hierbei werde ich nun in kürzerer Folge hier berichten… 🙂