Tag Archives: Reboot

Reboot der WatchGuard per Script

1 Comment

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 "yes\r"
 } "\[Pp\]assword*" {
 exp_send "$fbpassword\r"
 } -re "WG.*(#|>)" {
 set logged_in 1
 }
 }

# Reboot-Befehl absetzen und SSH Verbindung beenden

set timeout 20
 exp_send "reboot\r"
 expect timeout {
 } "Reboot (yes or no)?" {
 exp_send "yes\r"
 }
 expect -re "WG.*(#|>)"
 exp_close
 exp_wait

Dieses Script kann nun über die Cygwin-Umgebung ausgeführt werden: C:\cygwin\bin\bash.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

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…

Probleme mit PPTP-VPN

4 Comments

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.

Trade-Up / Migration von X Core e-series X550e, X750e, X1250e auf XTM 5

18 Comments

Viele Kunden steigen derzeit von einer WatchGuard X Core e-series X550e, X750e, X1250e auf ein entsprechendes Nachfolge-Modell XTM 505, XTM 510, XTM 520 und XTM 530 um (respektive von X Peak e-series auf XTM8). Fast immer taucht die Frage auf, ob die bestehende Konfiguration des “alten” Geräts auf das “neue” Gerät übertragen werden kann. Ja, sie kann. Es gilt aber ein paar kleine Hürden zu überwinden.

Zunächst muss natürlich die neue Box über die WatchGuard Website registriert und der neue Feature Key (Lizenzdatei) heruntergeladen werden. Auf dem Konfigurations-PC/Notebook haben Sie den aktuellen WSM 11.4.2 und die entsprechende Fireware XTM 11.4.2 für Ihre Geräte-Familie installiert, und auch das Adobe Flash Plugin für Ihren Browser ist vorhanden. Über https://10.0.1.1:8080 melden Sie sich mit dem User “admin” und dem Factory Default Kennwort “readwrite” an. Sie klicken den Setup Wizard mit den Default-Werten durch, importieren dabei auch den Feature Key und vergeben am Schluss Ihre eigenen Firewall-Kennwörter. Nach der erneuten Anmeldung mit Ihrem eigenen “admin”-Kennwort installieren Sie über System > Upgrade OS die neueste Fireware XTM 11.4.2 auf der Box, die daraufhin einmal durchbooten wird. Auf Ihrem Konfigurations-PC/Notebook starten Sie dann den WSM 11.4.2 und machen ein “Connect to Device” zu Ihrer neuen XTM-Box. Anschließend öffnen Sie den Policy Manager, der Ihnen die praktisch “leere” XML-Konfigurationsdatei der neuen XTM-Box anzeigt.

So weit, so gut. Erst jetzt wird es interessant:

Im Policy Manager laden Sie über File > Open > Configuration File die letzte XML-Konfigurationsdatei Ihrer “alten” WatchGuard. Auf die Frage “Do you want to save this new configuration to a file?” antworten Sie mit NEIN.

Sie sehen daraufhin die Konfigurationsdatei Ihrer “alten” WatchGuard. Falls Sie bisher eine X750e/X1250e im Einsatz hatten, bei der das Interface ganz rechts außen (eth7) im Einsatz war, sollten Sie sich die Network > Configuration Einstellungen für dieses Interface auf Papier notieren und prüfen, ob das Interface irgendwo namentlich in Firewall-Regel(n) auftaucht und auch diese entsprechend dokumentieren! Über Setup > System > Model wählen Sie Ihr neues Hardware-Modell aus. Es folgt eine Warnmeldung, die auf die veränderte Anzahl der Ethernet-Schnittstellen hinweist (eine XTM5 hat jetzt 7 Interfaces, eine alte X550e hatte 4, eine X750e/X1250e 8 Interfaces). Anschließend müssen Sie noch bei Setup > Feature Keys den Feature Key der alten Box removen und den Feature Key der neuen Box importieren. Beachten Sie bitte, dass im Policy Manager ganz unten rechts noch der Hinweis steht, dass es sich um eine Konfigurationsdatei des Typs “Fireware XTM v11.0-v11.3.x” handelt:

Auch bis hierhin alles planmäßig.

Anschließend starten Sie ein “Save to Firebox”. Die eventuelle Warnmeldung “The specified IP address does not match any of the interfaces specified in this config file. Are you sure you want to save to this Firebox?” (…ist klar, weil Ihre alte Konfigurationsdatei höchstwahrscheinlich eben nicht die 10.0.1.1 für eth1 enthält…) bestätigen Sie mit JA.

und erhalten dann eine zweite Warnmeldung: “The configuration file must be upgraded before it can be saved to the v11.4.2 device. Would you like to upgrade the configuration now?”. Auch die bestätigen Sie mit JA.

Anschließend folgt überraschend: “Error communicating with Firebox [IP]. INTERNAL_ERROR: The configuration is invalid, missing application action object”, die Sie nur mit OK bestätigen können.

=> Brechen Sie den Vorgang dann mit CANCEL ab und schließen Sie den Policy Manager.

Öffnen Sie den Policy Manager erneut, und öffnen Sie über File > Open > Configuration File die NEUESTE Version der Konfigurationsdatei, die im Zuge des vorigen “Save to Firebox” gespeichert wurde (ist nur wenige Minuten alt…). Bestätigen/ignorieren Sie die weiter oben bereits beschriebenen Warnmeldungen und starten Sie dann erneut den Vorgang “Save to Firebox”. Beachten Sie in diesem Zusammenhang, dass nun im Policy Manager ganz unten rechts für die Konfigurationsdatei der Typ “Fireware XTM v11.4.2” angezeigt wird:

=> Jetzt – beim zweiten Mal – sollte das Hochladen der Konfigurationsdatei funktionieren:


Danach sollten Sie die neue Box dann auch über die “alten” TCP/IP-Einstellungen auf den entsprechenden Interfaces ansprechen können! [Hinweis: die Firewall-Kennwörter sind nicht Bestandteil der Konfigurationsdatei, sondern hardwarespezifisch! D.h. die neue Firebox hat nicht automatisch die Kennwörter der alten Firebox, sondern die, die Sie ihr über den Setup Wizard verpasst haben!]

RMA Fälle der letzten Zeit

Comment

Ich hatte in den letzten Wochen drei Fälle, in denen WatchGuard die Hardware Appliance im Zuge eines Support Incidents ausgetauscht hat:

  • Defekte XTM 505: nachdem die Ersteinrichtung (incl. Aufspielen des Feature Key) einwandfrei geklappt hatte, blieb beim nächsten Boot-Vorgang das LCD-Display komplett leer (Hintergrundbeleuchtung an), die Box “kam nicht hoch” und auch die Lüfter liefen nach wie vor auf 100% (reduziert sich normalerweise nach ca. 20-30 Sekunden auf eine geringe Drehzahl).

  • Defekte X10e: trotz korrekter Ausführung eines “Factory Reset” (für mehr als 1 Minute gedrückter RESET-Buttons während Power On) startete die Box nicht in die Maintenance-Partition SYS-B (Safe Mode) – stattdessen war wieder die reguläre Partition SYS-A und die reguläre Konfigurationsdatei aktiv…

  • Defekte SSL100: Probleme mit User Authentication (Microsoft ActiveSync gegenüber Active Directory für den SSL-Zugriff von Apple iPhone auf Microsoft Exchange Server)

Command Line Interface (CLI) auf Port 4118 tcp

1 Comment

WatchGuard Firebox e-series und XTM Systeme mit Software 10.x oder 11.x bieten auch die Möglichkeit der Administration und Programmierung im Kommandozeilenmodus (CLI). Ausnahme: X Edge e-series mit v10.x. Hierzu läuft auf der WatchGuard ein SSH-Daemon, der auf Port 4118 tcp hört. Dieser Port ist Bestandteil der standardmäßig im Regelwerk enthaltenen Firewall-Regel “WatchGuard”, die ebenfalls standardmäßig den Zugriff auf die “Firebox” von “Any-Trusted” und “Any-Optional” ermöglicht. Das From-Feld dieser Regel kann natürlich auch so erweitert werden, dass der Zugriff über das Internet oder für mobile User möglich wird (Sicherheitsüberlegungen berücksichtigen!).
Das CLI kennt wie das WebUI zwei User: status und admin. Zu status gehört immer das lesende Kennwort der Firebox (status passphrase). Zu admin gehört immer das schreibende Kennwort der Firebox (configuration passphrase).
Wenn Sie nun über einen SSH-Client (z.B. PuTTY) eine SSH-Verbindung zu Port 4118 öffnen und sich als admin an der Firebox anmelden, können Sie dort zunächst durch die Eingabe eines Fragezeichens (?) eine Übersicht der verfügbaren Befehle anzeigen lassen:

Hier findet sich unter anderem auch der Befehl “reboot”, über den die Firebox durchgebootet werden kann. Gerade bei Fireboxen mit v10.x ist dieser Einstieg manchmal “der letzte Rettungsanker”, wenn durch Memory Leak Effekte der Hauptspeicher auf der Firebox zugelaufen ist und die Firebox in Folge den Daemon abgeschaltet hat, über den sich der WSM mit der Firebox verbindet…
Ebenfalls sehr hilfreich ist der CLI-Befehl “ping”, der es ermöglicht, pings direkt von der Firebox aus zu verschicken.
Theoretisch kann über das CLI auch eine weitgehende Administration des Gesamtsystems erfolgen, also auch Konfigurationsänderungen etc., jedoch kommt dies in der Praxis eher selten vor. WatchGuard bietet hierfür unter http://www.watchguard.com/help/documentation/xtm.asp eine umfangreiche PDF: die Command Line Interface Reference.

Kein automatischer Reboot nach Migration

Comment

In einem früheren Posting hatte ich beschrieben wie man eine Firebox regelmäßig und automatisch zu einem bestimmten Zeitpunkt booten lassen kann. Ich habe nun Fälle gesehen, dass dies mit Softwareversionen kleiner 11.2.3 überhaupt nicht gegriffen hat – oder nach Migration auf 11.2.3 nicht mehr greift. Ich konnte Abhilfe schaffen, in dem das Häkchen bei Automatic Reboot (Policy Manager: Setup > Global Settings) entfernt wurde, die Konfig auf die Firebox gespeichert wurde, anschließend das Häkchen wieder gesetzt und die Konfig erneut auf die Firebox gespeichert wurde. Der 1:1 Vergleich der XML-Dateien zeigt keinen Unterschied, insofern muss das Setting wohl auf der Firebox selbst hinterlegt gewesen sein.

(K)ein Problem von spamBlocker

Comment

Einen kuriosen Support-Fall durfte ich gestern lösen: seit dem Update auf WatchGuard Fireware XTM 11.2.3 lief der spamBlocker in einem X1250e Active/Passive HA Cluster nicht mehr. Alle Spams kamen ungefiltert durch, im Traffic Monitor stand jedes Mal ProxyAllow: SMTP Message classification is unknown because an error occurred while classifying.
Die Analyse brachte jedoch ein ganz anderes Problem ans Tageslicht: der Status Report des Firebox System Manager vermeldete, dass das externe Interface (eth0) des zweiten Cluster-Knotens keinen Ethernet-Link hatte. Nach Austausch des Patchkabels war der Link wieder da. Nach einem darauf folgenden Failover auf den zweiten Cluster-Knoten lief der spamBlocker wieder.Nach einem erneuten Failover/Failback auf den zuvor “alleine” aktiven Clusterknoten lief spamBlocker wieder nicht. Erst nach einem Reboot des ersten Clusterknoten arbeitete spamBlocker wieder korrekt auf beiden Cluster-Knoten.