Tag Archives: BOVPN

Anbindung an ZIVIT (Atlas Zollverfahren) mit WatchGuard ab 11.12.2

Comment

Eine Anbindung an ZIVIT (Atlas Zollverfahren) mit einer WatchGuard Firebox ist mit Fireware 11.12.2 unterstützt und getestet. Das Setup basiert auf einem oder mehreren route-based VPNs, es wird also über ein/mehrere virtuelle BOVPN-Interface(s) realisiert. Um die nötigen kundenspezifischen VPN-Einstellungen in Erfahrung zu bringen, sind der Zugang auf der Website des Zoll-Portals sowie ein per Briefpost überstellter Aktivierungs-Code notwendig. Genauere Informationen zu den WatchGuard-seitigen Einstellungen können Sie über unser Kontaktformular anfordern.

Neuer Knowledge Base Content im Juli 2016

Comment

WatchGuard erstellt ständig neue Inhalte in der Knowledge Base. Die folgenden Artikel wurden im Mai 2016 hinzugefügt. Um die WatchGuard Knowledge Base zu durchsuchen, verwenden Sie die Technische Suche (Technical Search) im WatchGuard Support Center.

Known Issues (Login auf der WatchGuard Website erforderlich)

Neuer Knowledge Base Content im Juni 2016

Comment

WatchGuard erstellt ständig neue Inhalte in der Knowledge Base. Die folgenden Artikel wurden im Mai 2016 hinzugefügt. Um die WatchGuard Knowledge Base zu durchsuchen, verwenden Sie die Technische Suche (Technical Search) im WatchGuard Support Center.

Artikel

Known Issues (Login auf der WatchGuard Website erforderlich)

BOVPN Notification einschalten

Comment

Logging

Eine WatchGuard Firebox / XTM speichert lokal immer nur die letzten Minuten des Traffic Logs. Wenn Logging Informationen über einen längeren Zeitraum aufbewahrt werden sollen/müssen – und wenn die Alarm-Funktion (Notification) genutzt werden soll – muss ein separater WatchGuard Log Server bereitgestellt werden, zu dem die WatchGuard Box die Logmeldungen schicken kann. Die aktuelle und empfohlene Variante ist der Einsatz eines kostenfreien WatchGuard Dimension Servers, der als fertige virtuelle Appliance für VMware ESXi und Microsoft Hyper-V Umgebungen bereitgestellt wird. Wenn keine Virtualisierungsplattform vorhanden ist, können alternativ auch die althergebrachten Logging- und Reporting-Dienste des “WatchGuard System Managers” auf einem Windows Server verwendet werden. Interessant in diesem Zusammenhang ist auch folgender HOWTO Artikel, der die Bereitstellung eines “WatchGuard Dimension Servers auf einem kostengünstigen Intel NUC (Mini-PC) beschreibt.

Notification

Wenn eine WatchGuard Firebox / XTM 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 laufende Logging lediglich das Triggersignal dazu!

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

bovpn-notification-1   bovpn-notification-2

Dieser Artikel wurde erstmals am 13.01.2009 im „Technischen WatchGuard-Blog von Bernd Och“ veröffentlicht. Hierher verschoben und aktualisiert in 2016.

IKE Keep Alive und Dead Peer Detection (DPD)

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.

ike-keep-alive-und-dpd-dead-peer-detection

Die WatchGuard Firebox / XTM kennt mehrere Verfahren, die zur Stabilität von VPN-Tunneln beitragen:

Bei IKE Keep Alive handelt es sich um ein WatchGuard-proprietäres Verfahren. Dieses sollte nur genau dann eingesetzt werden, wenn auf beiden Enden des VPN-Tunnels WatchGuard Produkte stehen und die Verwendung von DPD nicht gewünscht ist!

Dead Peer Detection (DPD) hingegen ist ein Industriestandard (RFC3706), der von den meisten IPSec Devices unterstützt wird. Wenn kein sonstiger Tunnel Traffic fließt, erzeugt der eine VPN-Endpunkt einen DPD-Request, der von der VPN-Gegenstelle mit einem DPD-Acknowledge beantwortet werden muss. Geschieht das nicht rechtzeitig innerhalb der eingestellten Settings (Default für DPD: 20 Sekunden, max. 5 Versuche) => 5 x 20 Sekunden plus die ursprünglichen 20 Sekunden => 120 Sekunden => 2 Minuten, dann geht der VPN-Endpunkt davon aus, dass die VPN-Gegenstelle “dead” ist, verwirft die SAs und startet die Neuaushandlung von Phase 1 und Phase 2. Hieraus geht auch hervor, dass DPD eben auf BEIDEN VPN-Endpunkten korrekt aktiviert und konfiguriert sein muss, denn sonst bewirkt diese Funktion das genaue Gegenteil: Statt dass der Tunnel über einen langen Zeitraum stabil bleibt, wird er im Extremfall alle 2 Minuten unterbrochen und neu ausgehandelt.

Es wird empfohlen, jedoch nur genau EIN Verfahren einzusetzen! 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 und die Verfahren spielen Ping-Pong.vpn-keep-alive-edge

Auf der alten WatchGuard Firebox 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).

Dieser Artikel wurde erstmals am 07.02.2009 im „Technischen WatchGuard-Blog von Bernd Och“ veröffentlicht. Hierher verschoben und aktualisiert in 2016.

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.

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 einzelneCompany Connect Anbindung der Telekom mit 2 Mbit/s gereicht. Diese Leitung war mit redundanten Cisco-Routern und zudem einerZweiwegefü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 vonredundanten 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 dieHSRP 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: