Tag Archives: IKE

Fireware 12.8 mit Problemen bei IKEv2 – behoben mit 12.8 Update 1

Update 2022-04-29:

Das Release 12.8 Update 1 enthält einen Fix für das in diesem Artikel beschriebene Problem.
Bei uns sind in den letzten 2 Wochen keine negativen Rückmeldungen zu 12.8 Update 1 eingegangen.

Wir haben inzwischen mehrere Kundenfälle, bei denen nach Upgrade auf die Version 12.8 Probleme mit IKEv2 aufgetreten sind. Leider ist es noch nicht klar ersichtlich, unter welchen Bedingungen die Probleme auftreten – bei manchen Kunden gibt es keine Probleme, bei anderen treten die Probleme auf.

Die Symptome sind i.d.R. “unstabile” BOVPN.Tunnel, meist mit BOVPN-Virtual-Interfaces.

Es scheint möglich, dass die Änderungen für die IKEv2-Erweiterung für MOBIKE (also der MOBIKE-Support für IKEv2, der mit der 12.8 reingekommen ist) damit zusammen hängen.

Der Mobike-Support kann über die CLI wie folgt abgeschaltet werden:

diagnose vpn "/ike/param/set mobike_support=0"
diagnose vpn "/ike/restart"

Vorsicht bei dem Befehl vpn ike/restart werden Ihre IKE Verbindungen möglicherweise unterbrochen.

Das Abschalten des Mobike-Supports hat bei einigen Kunden Besserung gebracht, allerdings hat es nicht überall das Problem vollständig beseitigen können.

In einem Support-Case zu diesem Problem haben wir folgende Antwort bekommen:

Our Engineering Team identified a BUG for this and are working on a fix.

Mainly it seems to affect only VPNs configured for VPN Failover.

FBX-23104 After upgrade to 12.8 IKEv2 BOVPNs using VPN failover are instable

Workaround is switching to IKEv1 for the affected VPNs.

Sobald wir mehr Informationen haben, werden wir diesen Blogartikel ergänzen.

Update 2022-04-29:

Das Release 12.8 Update 1 enthält einen Fix für das in diesem Artikel beschriebene Problem.
Bei u
ns sind in den letzten 2 Wochen keine negativen Rückmeldungen zu 12.8 Update 1 eingegangen.

 

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

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.

IKE Keep Alive und Dead Peer Detection (DPD)

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.