Tag Archives: X Core

NIC Einstellungen auf dem Cluster Interface per Hand ändern

Im Normalbetrieb kann man ja für jedes Firewall-Interface die Ethernet Geschwindigkeit (10/100/1000 Mbit) und Full Duplex bzw. Half Duplex über Network > Configuration manuell einstellen, wobei aber in der Regel die Einstellung “Auto Negotiate” beibehalten werden sollte, solange keine Ethernet Errors und Collisions offensichtlich sind. Im HA Cluster-Betrieb können die NIC Einstellungen auf dem/den “Cluster-Interface(s)“, mit denen die Boxen direkt miteinander verbunden sind, jedoch NICHT manuell beeinflusst werden! Im Regelfall befinden sich beide Cluster Member direkt beieinander und sind mit einem normalen Patchkabel (1:1 oder Cross-Over) verbunden. In manchen Installationen befinden sich die beiden Cluster-Boxen aber in verschiedenen Räumen/Rechenzentren und sind teilweise mehrere Hundert Meter weit voneinander entfernt. Bei diesen Entfernungen kommen dann Querverbindungen zum Einsatz, die auf LWL/Glasfaser-Technik basieren. Je nachdem wie die Netzwerk-Infrastruktur an beiden Lokationen aussieht und wie viele freie LWL-Fasern zur Verfügung stehen, werden die Interfaces der beiden Fireboxen dann entweder direkt miteinander verbunden (über LWL-Medienkonverter) – oder über VLANs, die auf entsprechenden Switchen an beiden Lokationen konfiguriert sind. In beiden Fällen hatte ich nun in der Praxis bereits Fälle, dass speziell die HA-Verbindung (Cluster Interface) zwischen den beiden Boxen Probleme bereitet hat und Ethernet Errors und Collisions auftraten. Teilweise konnten die beteiligten externen Netzwerk-Komponenten (=Medien-Konverter) nicht auf einen festen Wert eingestellt werden oder es gab nach wie vor Probleme, egal auf welche Werte das Interface auf dem beteiligten VLAN-Switch (z.B. HP) eingestellt war. Hier kann dann nur über die WatchGuard versucht werden, das Problem abzustellen. Aber wie gesagt, für das Cluster Interface lassen sich keine festen Werte über die GUI einstellen. Also muss hier mal wieder ein Texteditor und ein manueller Eingriff in die XML-Konfigurationsdatei ran… 😉

Je nachdem, wie bzw. wie oft das betreffende Interface vorher schon mal konfiguriert war, findet sich in der Konfig-Datei dann folgende Stelle:

[Schnipp] (für die Ansicht hier “<" und ">” durch “{” und “}” ersetzt)

{interface}
   {name}Optional-5{/name}
   {description /}
   {property}0{/property}
   {if-item-list}
    {item}
     {item-type}1{/item-type}
     {physical-if}
      {if-num}6{/if-num}
      {enabled}1{/enabled}
      {if-property}4{/if-property}
      {ip}0.0.0.0{/ip}
      {netmask}255.255.255.255{/netmask}
      {mtu}1500{/mtu}
      {auto-negotiation}1{/auto-negotiation}
      {link-speed}100{/link-speed}
      {mac-address-enable}0{/mac-address-enable}
      {mac-address /}
      {full-duplex}1{/full-duplex}

[Schnapp]

Die fett markierten Stellen sprechen für sich und müssen eben entsprechend händisch angepasst werden, also Auto Negotiation ausschalten (=0) und die entsprechenden Werte für Link Speed und Full Duplex an (=1) bzw. aus (=0) einstellen. Anschließend kann die XML-Datei gespeichert und auf die Firebox hochgeladen werden. Im Policy Manager unter Network > Configuration wird dann auch die Änderung des “NIC Speed” angezeigt (also z.B. 100 Mbit Full Duplex)…

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

Korruptes Zertifikat entfernen

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!

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.

X Core und X Peak e-series nicht direkt von v10.x auf v11.3.3 oder v11.3.4 updaten!

Mit diesem Blog-Beitrag hatte ich bereits auf das Problem eines möglichen Verlusts der Konfiguration beim direkten Umstieg von Fireware v10.x auf Fireware XTM v11.3.3 und v11.3.4 hingewiesen. Der Hinweistext “Note: If you are upgrading from Fireware XTM OS v10.x, you must upgrade to Fireware XTM OS v11.3.2 before you upgrade to v11.3.4” im Software-Portal bestätigt nun also dieses Problem. Wenn Sie also auf einer X Core e-series (X550e, X750e, X1250e) oder einer X Peak e-series (X5500e, X6500e, X8500e, X8500e-F) die Migration von v10 auf v11 vorhaben, sollten Sie tunlichst den Zwischenschritt auf v11.3.2 mit in Ihren Upgrade-Pfad einbauen!

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.