Tag Archives: BOVPN

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.

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.

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…

Policy Based Routing offenbar auch bei IPSec

1 Comment

Bislang galten die Einstellungen für Policy Based Routing (PBR) im Multi-WAN Betrieb unter Fireware Pro (zwei oder mehr externe Internet-Anschlüsse auf der gleichen Firebox) ausdrücklich nur für ausgehenden non-IPSec Traffic.
Bei der Fireware XTM gilt PBR nun offenbar auch, wenn die Ziel-IP hinter einem VPN-Tunnel liegt. Aufgefallen ist mir dies daran, dass plötzlich ping nicht mehr über einen VPN-Tunnel funktioniert hat – tcp- oder udp-Verkehr hingegen schon. Die “ping”-Regel beim Kunden sah so aus: From: Any, To: Any, und hierbei PBR 2,0 (also bevorzugt eth2 und nur bei Failover eth0). Die VPN-Tunnel terminierten jedoch an eth0. Im Traffic Monitor war kein Problem zu sehen. Die Pakete wurden von der Firewall als Allowed zugelassen, erreichten eben aber nie ihr Ziel…
Es muss nun also noch genauer geschaut werden, wenn mit dem Begriff “Any” gearbeitet wird, denn auch “Any-BOVPN” (also alle BOVPN-Tunnel) sind Bestandteil von “Any”…
Ob dieses neue Verhalten jetzt eher Vorteil oder Nachteil ist, habe ich aus Zeitmangel noch nicht genauer durchdacht… 🙂

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:

X Edge: “VPN-Any” Problem nach Software Update

1 Comment

Kurzer Hinweis auf ein Problem bei der X Edge, das hoffentlich schon wieder der Vergangenheit angehört: mit Software-Version Edge 10.2.2 wurde eine neue (Default) Firewall-Regel namens VPN-Any ins Leben gerufen, die den Verkehr INNERHALB eines Branch Office VPN-Tunnels (BOVPN) zwischen dieser X Edge und einer VPN-Gegenstelle regelt (früher war dieser Traffic seitens der X Edge implizit immer zulässig…).
Es gibt Fälle, bei denen ein Software-Update auf einer X Edge mit einer älteren Software-Version (zum Beispiel 8.5.2) zu einem Fehler bei der automatischen Umschreibung der Konfigurationsdatei führt. Dann wird zwar das Software-Update durchgeführt (ohne Fehlermeldung!) – jedoch wird die Firewall-Regel “VPN-Any” nicht mit erzeugt. Das führt dazu, dass plötzlich kein Traffic mehr durch den VPN-Tunnel fließt… 🙁
So finden Sie heraus, ob Ihre X Edge nach einem Software-Update auf v10.x “gelitten” hat: Gehen Sie zu Firewall > Outgoing und prüfen Sie, ob im oberen Bereich die folgenden sieben (!) “Common Proxy Policies” angezeigt werden. Sehen Sie nur drei Proxy-Regeln (HTTP, FTP, Outgoing), haben Sie definitiv dieses Problem! Scrollen Sie weiter runter und prüfen Sie, ob bei den Common Packet Filter Policies die Regel VPN-Any (grün/Allow) angezeigt wird. Wenn nicht, haben Sie auch das hier beschriebene Problem…

Als Reparatur-Maßnahme schlägt WatchGuard vor, dass die X Edge Hardware auf Factory Default zurückgesetzt wird: Strom-Stecker ziehen, Reset-Knopf drücken, gedrückt halten, Strom-Stecker wieder einstecken, ca. 1 Minute warten, Knopf loslassen. Nach dem dann folgenden Setup Wizard (https://192.168.111.1) sollen die kundenspezifischen Einstellungen “from scratch” erneut vorgenommen werden… Der Weg über Administration > Backup Configuration und Restore Configuration behebt das Problem nach Aussage von WatchGuard-Support offenbar NICHT! Ich habe beim letzten Auftreten dieses Problems Papier-Ausdrucke der beschädigten Konfigurations-Dateien angefertigt und werde diese genauer analysieren, wenn ich Zeit dazu habe. Wenn ich einen einfacheren Weg zur Reparatur finde, werde ich hier berichten…
“Scratch” erzeugt man also zunächst am besten, indem man auf dem alten Stand auf Administration > View Configuration klickt, den Inhalt des Haupt-Frame per Cut&Paste in eine Textdatei wegspeichert und ausdruckt… Bis auf weiteres also viel Spaß beim Tippen…