Tag Archives: IKEv1

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

Comment

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 uns sind in den letzten 2 Wochen keine negativen Rückmeldungen zu 12.8 Update 1 eingegangen.

 

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.