Tag Archives: VPN

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.

Any-Alias in Firewall-Regeln und BOVPN-Probleme

Comment

Im Rahmen eines weiteren PCI Compliance Projekts stand vor zwei Wochen auch die Migration einer WatchGuard X5500e von Fireware 10.2.9 nach Fireware XTM 11.2.3 an sowie die Erweiterung um eine zweite X5500e zu einem HA Active/Passive Cluster. Der Kunde hatte bereits vor einigen Monaten die Migration auf eine frühere 11-er Version versucht, war aber daran gescheitert, dass zwar alle über den WatchGuard Management Server verwalteten Branch Office VPN-Tunnel funktioniert haben – nicht jedoch die über “Manual IPSec” eingerichteten BOVPN-Tunnel zu seinem outgesourceten Rechenzentrum und zu ein paar anderen externen Partnern.
Ich konnte nun erkennen, dass das Problem nicht auf Seiten der VPN-Konfiguration lag, sondern in der Formulierung einiger FIREWALLREGELN. So lautete die Firewall-Regel für “ping” From:Any To:Any. Offenbar hat aber die Firewall nicht erkannt, dass auch Ziele hinter einem BOVPN-Tunnel zu dem Alias “Any” gehören… Insofern wurden pings trotz korrekt vorhandenem VPN-Tunnel als Unhandled Internal Packet eingestuft und verworfen. Abhilfe schuf hier die Aufsplittung dieser einen Firewall-Regel in mehrere einzelne Regeln, z.B. Ping.Out.Internet = From:Any-Trusted To:Any-External und Ping.Out.VPN = From:Any-Trusted To:Any-BOVPN sowie ein paar weitere erforderliche Kombinationen z.B. für die Gegenrichtung From:Any-BOVPN To:Any-Trusted. Diese grundsätzliche Splittung in separate Firewall-Regeln für klassischen gerouteten Firewall-Traffic und VPN-Traffic hat sich bewährt! Die Migration von 10 auf 11 auf Basis der geänderten Konfigurationsdatei war dann auf Anhieb erfolgreich.

SSL VPN Probleme nach Update von 11.1 auf 11.2

1 Comment

In einem aktuellen Supportfall hatte der Kunde seine Firebox X550e von Fireware XTM v11.1 auf 11.2 upgedated. Anschließend konnten die mobilen User über den WatchGuard SSL VPN Client 11.1 keine Verbindung mehr herstellen. Fehlermeldung: “Could not download the configuration file…”.
Ich vermute einen Zusammenhang mit der fehlerhaften Migration der integrierten WatchGuard-eigenen SSL-Zertifikate. Neben den gültigen SSLVPN-Zertifikaten (“Signed”) befinden sich im Zertifikatsspeicher noch weitere Zertifikate im Status “Pending”, die offenbar die gültigen Zertifikate behindern.

Die “Pending” Zertifikate können wie folgt gelöscht werden: Per WSM mit der Firebox verbinden, den Firebox System Manager starten, dort View > Certificates, Pending-Zertifikate anklicken und “Delete”. Anschließend Reboot der Firebox. Handelt es sich um einen Cluster, müssen beide Boxen zur gleichen Zeit ausgeschaltet werden!

Vorsicht bei Leerzeichen im Namen von IPSec Phase 2 Proposals

Comment

Bei einer Migration einer WatchGuard Firebox X Peak X5500e von einer 10.2.x Version auf die Version 11.2 ist es mir die Tage passiert, dass plötzlich etwa die Hälfte der vorher ca. 40 BOVPN-Tunnel nicht mehr vorhanden war und im WSM / Firebox System Manager auch nicht mehr angezeigt wurde. Und zwar wurden nur noch die Tunnel angezeigt, deren Tunnel-Name alphabetisch aufsteigend von A bis zu einem bestimmten Buchstaben ging…
Die Fehlersuche führte natürlich sofort zu einem Vergleich des letzten noch angezeigten und des ersten nicht mehr angezeigten Tunnels. Dabei stellte sich als Besonderheit heraus, dass der Name des Phase 2 Proposals im ersten nicht mehr angezeigten VPN-Tunnel ein Leerzeichen enthielt! Nach dem Ersetzen des Leerzeichens durch ein “-” (Minus) und erneutem Speichern der Konfigurationsdatei waren dann auch alle VPN-Tunnel wieder da…

Achtung bei Migration auf Fireware XTM: Routing Table – Abarbeitung ändert sich

1 Comment

Momentan habe ich wenig Zeit für meinen Blog, weil jeden Tag neue Support-Anforderungen bei mir eingehen. Admins migrieren ihre WatchGuard Firebox mit bestem Wissen und Gewissen auf Fireware XTM (Version 11) – und erleiden bisweilen Schiffbruch. In den allermeisten Fällen lassen sich die Probleme darauf zurückführen, dass bei Fireware XTM (Version 11) die interne Routing Table der Firebox in einer anderen Reihenfolge abgearbeitet wird als bei der bisherigen Fireware 10.2.x.

Generell gilt bei XTM: VPN hat Vorrang!

Welche Probleme können daraus entstehen und welche Lösungsansätze gibt es:

  • 1. Mobile User VPN. Während noch bei der Version WFS 7.x empfohlen wurde, den IP-Pool für die Einwahl der mobilen User INNERHALB des lokalen LAN-Subnetzes zu definieren (Beispiel: LAN = 192.168.0.0/24, mobile User (egal ob PPTP oder IPSec) bekommen 192.168.0.200 bis 220 zugewiesen), ist dies bei Fireware XTM (Version 11) grundsätzlich ein Problem und führt zu gravierendem Fehlverhalten.

    Verwenden Sie grundsätzlich für die Einwahl von mobilen Usern IP-Bereiche, die in dieser Form an keiner anderen Stelle Ihrer (verteilten) IP-Infrastruktur verwendet werden. Ich persönlich verwende gerne für PPTP den Bereich 172.31.254.1 bis 50, für IPSec 172.31.255.1 bis x (je nach Lizenz) und für SSL-VPN 172.31.253.0/24. Diese Bereiche werden in aller Regel noch nicht für andere Zwecke verwendet – und haben eben den Vorteil, dass die WatchGuard Firebox zu diesen Bereichen ein sauberes Routing fahren kann.

  • 2. Network > Routes. Das Problem hier lässt sich anhand von folgendem Support Fall verdeutlichen: als eth1 (=Trusted) war bei einem Kunden definiert: 192.168.0.1/30, d.h. außer der Firebox gibt es in diesem Subnetz nur noch genau einen weiteren Host, 192.168.0.2. Dies ist ein Standleitungs-Router, der eine Leitung zu einem 10-er IP-Netz am Hauptstandort des Unternehmens bedient, an dem sich auch die AD-Domänencontroller des Unternehmens befinden, über die u.a. auch die Einwahl der mobilen User gegenüber Active Directory authentifiziert wurde (Eintrag unter Setup > Authentication > Authentication Servers > Active Directory). Dummerweise gab es in dieser Konfiguration auch noch einen BOVPN-Tunnel (sprich eine feste Außenstelle), der auf der Gegenseite das IP-Netz 192.168.0.0/24 bedient hat. Während unter der Software-Version Fireware 10.2.x das auf eth1 definierte lokale Netzwerk 192.168.0.0/30 Vorrang hatte und daher die DCs in dem 10-er Netz per Routing erreichbar waren, verhält sich die WatchGuard Firebox unter Fireware XTM (Version 11) nun anders und schickt den Traffic zu dem Standleitungs-Router 192.168.0.2 nun nicht mehr zum lokalen Interface eth1 raus – sondern packt ihn in den Tunnel in die Außenstelle x ein, wo er im Nirwana landet… Problematik klar? In diesem Fall am einfachsten die Konfiguration von eth1 und die IP-Adresse und das Routing des/zum Standleitungs-Router so abändern, dass das verwendete IP-Subnetz an keiner anderen Stelle der Unternehmens-IP-Infrastruktur verwendet wird…

  • 3. Problematik: vermaschte IP-Netze. Unter einem “vermaschten IP-Netz” verstehe ich hier ein verteiltes Netzwerk mit mehreren Standorten, die auf TCP/IP-Basis miteinander kommunizieren können, wobei das Routing jedoch nicht direkt von Außenstelle zu Außenstelle geführt wird, sondern über einen gemeinsamen, zentralen Punkt (i.d.R. ein Rechenzentrum). Auch ich habe in der Vergangenheit Netze gebaut, die in einer Außenstelle z.B. ein IP-Netz à la 10.0.23.0/24 verwendet haben – und einen BOVPN-Tunnel zu 10.0.0.0/8 hinter einem zentralen Gateway angesteuert haben. Dort befand sich eine WatchGuard Firebox X Core oder X Peak, die den Traffic angenommen hat – und auch tatsächlich wieder korrekt in die ebenfalls dort terminierten BOVPN-Tunnel zu den anderen Außenstellen eingepackt hat. Damit ließen sich auch schon in der Vergangenheit zentralisierte VoIP-Lösungen (z.B. Asterisk, Siemens HiPath, Avaya) abbilden. Ein Problem entsteht unter Fireware XTM insbesondere dann, wenn auch das zentrale Netzwerk in einem IP-Subnetz des o.g. vermaschten Netzwerks betrieben wird. Die zentralen Server sind dann aus den Außenstellen heraus nicht mehr korrekt erreichbar. Trifft dieses Szenario auf Sie zu, sprechen Sie mich bitte direkt an, um eine Lösung gemeinsam zu erarbeiten.

  • 4. Allgemein gilt: sofern Ihre IP-Infrastruktur *KLAR* definiert ist und es zwischen den verwendeten IP-Bereichen keine Konflikte/Überschneidungen gibt, wird ein Update auf die aktuelle Version WSM 11.x und Fireware XTM v11.x relativ einfach und überschaubar über die Runden gehen.

SSL-VPN bei Multi-WAN auf einer X Edge

1 Comment

Bei Vorhandensein der Edge Pro (Standard bei X55e, Nachrüst-Option bei X10e und X20e) können beide WAN-Anschlüsse der X Edge (WAN1 und WAN2) mit einem Internet-Anschluss belegt werden (z.B. zweimal aktives DSL für Multi-WAN oder einmal DSL und einmal UMTS als Fallback).

Obwohl die GUI auch andere Einstellungen zulässt, terminieren VPN-Verbindungen immer auf WAN1, solange WAN1 aktiv ist. Insofern handelt es sich bezüglich VPN bei WAN2 um ein reines Failover-Interface. Hat man die Konstellation, dass z.B. zunächst auf WAN1 ein normaler ADSL-Anschluss liegt (z.B. T-DSL 6000 mit 512 kBit Upload) – und nach einiger Zeit kommt ein SDSL-Anschluss hinzu (2 Mbit symmetrisch), der gerade wegen des höheren Upload für VPN-Verbindungen genutzt werden soll – sollte man die External Interface neu zuordnen, so dass der SDSL auf WAN1 und der ADSL auf WAN2 zu liegen kommt.

Im Falle von Mobile User SSL-VPN kann man eine Primary IP und eine Secondary IP angeben. Hierbei sollte Primary immer die WAN1-IP sein (bzw. der DYNDNS-Hostname) und Secondary immer die WAN2-IP. Der Client ist zwar in der Lage, die Secondary IP zu connecten und bekommt von dort auch die VPN-Konfig zugewiesen, die eigentliche VPN-Verbindung wird dann aber zu der Primary IP (sprich WAN1) aufgebaut, solange dieses Interface aktiv ist. Sind die IPs vertauscht oder wird z.B. nur die WAN2-IP in die Konfiguration eingetragen, kommt keine Verbindung zustande. Der Client zeigt im Log die Fehlermeldung “Connection refused (WSAECONNREFUSED)” und steht im Logon-Fenster in einer Endlosschleife “Paused, waiting 5 seconds”.

Support kennt hierzu auch ähnliche Berichte aus der Praxis:
BUG30110: Cannot construct SSL VPN and MOVPN on WAN2 while WAN1 is up und BUG23704: Cannot construct a tunnel on WAN2 while WAN1 is up. Diese wurden aber abgeschlossen mit dem Hinweis, dass dieses Verhalten “normal” und “by design” ist.

IKE Keep Alive und Dead Peer Detection (DPD)

1 Comment

Die Kernaussage vorweg: Steigern Sie die Stabilität Ihrer BOVPN Tunnel, indem Sie IKE Keep Alive –ODER– Dead Peer Detection (DPD) verwenden – aber nicht beides zusammen!

Branch Office VPN Tunnel sind im Regelfall darauf ausgerichtet, möglichst 24 Stunden am Tag voll verfügbar zu sein (always on). Brechen Tunnel weg, liegt es meist an:

  • Ein oder beide Endpunkte haben eine instabile Internet-Anbindung, hohe Latenzzeiten oder Paketverluste. In meinem Artikel Verbindungsprobleme wegen Ethernet Collisions bin ich darauf bereits einmal eingegangen.

  • Veraltete Software-Stände oder Kompatibilitäts-Probleme (möglichst immer die aktuelle Software-Version einsetzen, sowohl auf WatchGuard Firebox Produkten als auch auf VPN Devices von Fremdherstellern).

  • Kein Traffic im VPN-Tunnel. Tunnel ohne Traffic tendieren dazu, instabil zu werden.

Die WatchGuard Fireboxen kennen mehrere Verfahren, die zur Stabilität von VPN-Tunneln beitragen: IKE Keep Alive, Dead Peer Detection – und bei der X Edge Serie zusätzlich noch VPN Keep Alive.

IKE Keep Alive sollte nur eingesetzt werden, wenn auf beiden Enden des VPN-Tunnels WatchGuard Produkte stehen!
Dead Peer Detection (DPD) hingegen ist ein Industriestandard (RFC3706), der von den meisten IPSec Devices unterstützt wird. Die aktuellen Default Einstellungen sollten auch verwendet werden: NAT-Traversal (aktiv), 20 Sekunden. Bei Nutzung von IKE Keep Alive: 30 Sekunden, max. 5 Failures. Bei Nutzung von DPD: 20 Sekunden, max. 5 Versuche. Verwenden Sie IKE Keep Alive und DPD NICHT GLEICHZEITIG, dies bewirkt genau das Gegenteil: Wenn beide Verfahren aktiviert sind und ein Verfahren eine Phase 1 Renegotiation auslöst, erkennt das andere Verfahren den Tunnel als down und startet seinerseits eine zweite Phase 1. So entsteht ein Konflikt mit der gerade zuvor ausgehandelten Phase 1…

Auf der X Edge gibt es alternativ noch VPN Keep Alive (VPN > VPN Keep Alive). Hier kann pro Tunnel eine IP-Adresse eines Hosts auf der anderen Seite des Tunnels eingetragen werden, der 24/7 läuft und auf ping antwortet (z.B. ein Server, ein managebarer Switch oder ersatzweise die IP-Adresse des Trusted Interface der dortigen Firewall bzw. VPN-Komponente):

Es wird empfohlen, sich jedoch nur auf EIN Verfahren zu beschränken!

BOVPN Notification einschalten

1 Comment

Wenn die Firebox an einen Logging Server angeschlossen und dieser korrekt konfiguriert ist, können für viele unterschiedliche Ereignisse auf der Firewall Notifications (Benachrichtigungen) erzeugt und per E-Mail an den Firewall-Administrator oder einen Support-Alias verschickt werden. Wichtig: Der Versand der Notification E-Mails erfolgt vom Logging Server aus – die Firewall liefert über das Logging lediglich das Triggersignal dazu!

Ein solches Ereignis kann die Unterbrechung eines BOVPN-Tunnels sein. Die Benachrichtigungs-Option hierfür ist noch relativ neu. Sie kann nur global für alle BOVPN-Tunnel ein- bzw. ausgeschaltet werden: Policy Manager > VPN > VPN Settings > BOVPN Notification: