Tag Archives: BOVPN

BOVPN-Tunnel WatchGuard <=> Fortinet, IKEv1 – Mismatched ID Setting

Comment

Ein Kunde hatte gerade ein Problem, einen IPSec BOVPN-Tunnel zwischen WatchGuard und Fortinet / Fortigate aufzubauen.

Setup: physikalische WatchGuard => Oracle Cloud => NAT => Virtuelle Fortinet

In einer Telko mit dem Kunden und dem Techniker, der die Fortinet konfiguriert, konnten wir debuggen.

Alle Settings (IKEv1) haben soweit gepasst, allerdings kam immer ein Fehler (auf der WG gemeldet):

IKE phase-1 negotiation from xx.xx.xx.xx:500 to yy.yy.yy.yy:500 failed. Gateway-Endpoint='name-des-gateways' Reason=Authentication failure due to mismatched ID setting

Laut Aussage des Technikers kann man bei der Fortigate die ID aber nicht einstellen; die Fortinet würde
die ID erst auf Anfrage der Gegenstelle überhaupt senden, und dann dort die externe IP reinschreiben.
(also ID = externe IP, nicht die „externe IP aus dem Transfernetz“.  => bei der WatchGuard dann remote ip = remote id).

Ein Erhöhen des Diagnostic log level auf info hat nichts wirklich Neues gegeben.

Ein Erhöhen des Diagnostic log level auf debug brachte dann eine Meldung zutage:
„invalid payload type (FQDN)“ oder so ähnlich. Wir haben leider keinen Screenshot dazu.

die WG hat also Type=IP erwartet und Type=FQDN erhalten.

Ich habe danach die Remote-ID umgestellt:

( ) By IP Address
(*) By Domain Information
=> (*) Domain Name
=> Die remote IP-Adresse als Domain Name eintragen

hat geholfen:

nach dem Abspeichern kam der Tunnel sofort hoch.

HOWTO: Branch Office VPN over TLS

Comment

Seit Fireware 12.1 bietet WatchGuard die Möglichkeit, eine Standortvernetzung bequem über TLS umzusetzen. Das Server-Client Modell spielt seine Stärken besonders dann aus, wenn keine statischen IP-Adressen vorhanden oder IP-SEC durch vorgelagerte Router nicht möglich ist. Sie können also eine vorkonfigurierte Firewall an einen entsprechenden Außenstandort liefern lassen und unabhängig vom ISP benötigt das Remote-Device nur eine WAN Verbindung via Port 443. Weiterlesen »

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.