Tag Archives: VPN

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.

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!!

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.

Multi-WAN Konflikt mit zwei redundanten Cisco HSRP Router-Paaren

Comment

Das Debugging einer problembehafteten HA Umgebung aus zwei X750e mit Fireware XTM 11.3.2 (ich betrachte diese Version derzeit für Cluster aus X Core / Peak e-series am stabilsten) hat heute einen netten Sonderfall aufgezeigt, der für die Störungen sicher mitverantwortlich war:

Der Kunde betreibt schon seit vielen Jahren ein WatchGuard VPN mit ca. 40 Außenstellen. Wie so oft hat in der Vergangenheit dafür eine einzelne Company Connect Anbindung der Telekom mit 2 Mbit/s gereicht. Diese Leitung war mit redundanten Cisco-Routern und zudem einer Zweiwegeführung ausgestattet. Der Kunde hatte nun bei der Telekom eine weitere Company Connect Anbindung beauftragt, mit 34 Mbit/s und ebenfalls redundanten Cisco-Routern und Zweiwegeführung. Auf der WatchGuard waren diese beiden Anbindungen als Multi-WAN konfiguriert – im Failover-Modus.

Bei einem Routine-Check des “Status Report” im Firebox System Manager ist mir in der ARP Table der WatchGuard aufgefallen, dass dort beide vorgelagerten Router-Paare (2 Mbit an eth0 und 34 Mbit an eth1) mit der gleichen Hardware MAC Adresse 00:00:0C:07:AC:01 aufgeführt waren.

Recherche hat ergeben, dass dies eine virtuelle MAC-Adresse ist, die von redundanten Cisco-Routern im HSRP Modus verwendet wird – und zwar dann, wenn auf den Routern die HSRP Group ID = 1 eingestellt ist. Offenbar hat der ISP also beide Router-Paare (da verschiedene Einzelaufträge) per Default mit der gleichen HSRP Group versehen… Das wird auch erst dann zum Problem, wenn beide Leitungen wie im vorliegenden Fall an das gleiche System angeschlossen werden. Die Auswirkungen kann man sich ausmalen.

Ein Support Call bei der Telekom hat dazu geführt, dass ein Router-Paar auf die HSRP Group ID = 2 eingestellt wurde, wodurch sich die virtuelle MAC-Adresse auf 00:00:0C:07:AC:02 geändert hat und nunmehr aus Sicht der WatchGuard die Interfaces sauber konfiguriert sind:


Policy Based Routing

2 Comments

Die Voraussetzung für die Nutzung von Policy Based Routing ist die Fireware Pro bzw. XTM Pro Zusatzoption und die korrekte Konfiguration von mehr als einem externem Interface für den Multi-WAN-Betrieb (vgl. z.B. http://de.watchguard-blog.com/2011/08/multi-wan-und-policy-based-routing.html).
Anschließend erweitert sich das Erscheinungsbild jeder einzelnen Firewall-Policy – und über die dort erscheinenden, eigentlich selbsterklärenden erweiterten Einstellungen lässt sich das gewünschte Verhalten im Multi-WAN-Umfeld bestimmen:

Sinn macht an dieser Stelle natürlich – speziell für ausgehende HTTP und HTTPS Policies – hier das vom Multi-WAN-Default abweichende Interface auszuwählen (im Beispiel das Interface “VDSL50” anstelle der defaultmäßigen “STANDLEITUNG”). Das hat zur Folge, dass eben der durch ausgehende HTTP/HTTPS-Verbindungen (also auch Downloads!) verursachte Traffic über das “zweite” externe Interface geführt wird (VDSL50) – und somit die STANDLEITUNG von eben diesem Traffic entlastet wird, so dass die dortige Bandbreite für die unternehmenskritischeren Anwendungen wie VPN, E-Mail etc. genutzt werden kann.

XTM: Mobile User verlieren Routing in das lokale Netzwerk

1 Comment

In einem Support Incident hatte ich in den letzten Wochen mit dem Problem zu kämpfen, dass Mobile User, die sich per MUVPN (NCP IPSec Client) oder WatchGuard SSL-VPN-Client einwählen, zwar eine augenscheinlich stabile VPN-Verbindung stehen haben – aber trotzdem nicht auf Resourcen im lokalen Netzwerk zugreifen können.
Die Besonderheit hierbei war jedoch, dass der Zugriff unmittelbar nach der Einwahl möglich war (z.B. Test per “ping -t”) – nach ein paar Sekunden jedoch plötzlich nicht mehr. Ein Vergleich der Routing Table des Einwahl-PCs (“route print”) sofort nach der Einwahl und später nach dem Auftreten des Problems zeigt, dass die Einwahl-Routen in das lokale Netzwerk plötzlich verschwinden, wodurch natürlich nicht mehr auf die internen Resourcen zugegriffen werden kann… Umfangreiche Fehlersuche zeigte auf, dass das beschriebene Problem nur in Kombination aus bestimmten Faktoren auftritt. Reproduzierbar war das Problem insbesondere, wenn auf dem betroffenen Client-PC:

  • Windows XP läuft als Betriebssystem
  • eine Broadcom-Netzwerkkarte eingebaut ist, die IEEE 802.1X Authentication unterstützt (oder ein anderer Hersteller)
  • eventuell begünstigt auch das Vorhandensein des “Novell-Client” auf dem gleichen PC das Problem.

Der Workaround, der das Problem bei dem betreffenden Kunden zunächst umschifft hat (ohne dabei jedoch das eigentliche Problem zu beheben) basiert darauf, unter Systemsteuerung > Netzwerkverbindungen in dem virtuellen Netzwerkadapter, der von dem MUVPN-IPSec-Client (NCP) erzeugt wird, auf dem Tab “Authentication” das Häkchen entfernen bei Enable IEEE 802.1X Authentication:

Das o.g. Häkchen scheint auch bei virtuellen Adaptern automatisch aktiviert zu sein (wie dem IPSec MUVPN-Client und dem WatchGuard SSLVPN-Client), wenn der darunter liegende physikalische Netzwerk-Adapter diese Funktion unterstützt. Nachdem die VPN-Software die Verbindung hergestellt hat, greift offenbar die 802.1X Authentication ein und unterbricht für kurze Zeit die Netzwerkverbindung. Anschließend kommt offenbar zwar die Netzwerkverbindung zurück, aber die Routen sind aus der Routingtabelle verschwunden…

Fireware XTM: HA Cluster Probleme mit MTU Size im BOVPN Tunnel

1 Comment

Ich habe aktuell einige offene Support-Fälle, die folgende Gemeinsamkeiten aufweisen: Active/Passive Cluster unter Fireware XTM v11.3.x, Branch Office IPSec VPN Tunnel zu festen Außenstellen, Kommunikationsprobleme innerhalb des/der BOVPN Tunnel.
In allen Fällen scheinen die Probleme mit fehlerhafter Fragmentierung von IPSec-Paketen zu tun zu haben. Ich konnte etwas ausführlicher debuggen und feststellen, dass bisweilen (also nur zeitweise!) IP-Pakete größer als 1394 Bytes im VPN-Tunnel nicht korrekt fragmentiert, sondern komplett verworfen werden. WatchGuard hat das Szenario im TestLab nachgestellt, konnte jedoch die Fehlerursache bis jetzt noch nicht weiter eingrenzen.
Zur schnellen Dokumentation des Problems verwende ich von einem PC in einer Außenstelle eine MSDOS-Eingabeaufforderung mit dem Befehl

ping [IP] -l 2000 -t

wobei [IP] eine IP-Adresse am anderen Ende eines BOVPN-Tunnels (in der Zentrale) ist. Der Befehl erzeugt Ping-Pakete mit einer Größe von 2000 Byte, die also beim Transport über das Internet zwingend fragmentiert werden müssen, da die maximale MTU Size auf Internet-Routern in der Regel 1500 Bytes beträgt. Erhalte ich korrekte ICMP-Antworten, weiss ich, dass die Fragmentierung korrekt funktioniert. Wenn nicht, liegt ein Problem vor. Durch Verkleinern der Paketlänge kann man sich iterativ an den kritischen Wert herantasten. Im vorliegenden Problemfall werden Pings mit 1394 Bytes korrekt übertragen, Pings mit 1395 Bytes und mehr jedoch NICHT:

Das Problem scheint zudem nur auf dem Rückweg von dem angepingten Host aufzutreten. Offenbar erreichen im Problemfall auch größere Datenpakete den Zielhost, der auch korrekt antwortet – jedoch scheint die WatchGuard Firebox ein Problem mit dem “Rücktransport” der Antwortpakete zu haben, wie sich am Vergleich der folgenden, im Abstand von ein paar Minuten aufgenommenen Screenshots erkennen lässt. Die mit grünen Streifen markierten Werte zählen im Laufe der Zeit korrekt hoch, während der eine rot markierte Wert (RCVD zurück auf dem ursprünglich sendenden System) sich nicht ändert…:

In allen meinen Support-Fällen konnte ich das Problem zunächst durch einen Workaround umgehen: auf dem Cluster Reduktion der MTU Size auf den Interfaces, die an BOVPN-Tunneln beteiligt sind, von 1500 auf 1380 Bytes:

WatchGuard muss jedoch das eigentliche Problem finden und beheben, denn durch den Workaround wird die Gesamtleistung der WatchGuard Firebox etwas ausgebremst.

Kein DYNDNS-Update bei VPN-Tunnel Routing 0.0.0.0/0

Comment

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.

Vodafone und WatchGuard MUVPN IPSec Client

1 Comment

Die Vodafone-Software, die den UMTS-Verbindungsaufbau steuert, enthält in einigen Versionen einen Fehler. Wenn bei bestehender UMTS-Verbindung der WatchGuard MUVPN IPSec-Client gestartet wird, wird die UMTS-Verbindung getrennt! Erklärung: im Hintergrund wird eine “Zero-Click-Connect” Verbindung, welche augenscheinlich deaktiviert ist, dennoch ausgeführt. Diese wechselt die Verbindung und es kommt zu dem Abbruch. Die fehlerhaften Versionen der Vodafone-Software versuchen, die Verbindung über den Tunnel aufzubauen, was eben ja nicht möglich ist. Die aktuelle Version 9.49 der Vodafone-Software enthält diesen Fehler nicht mehr.