IKEv2 DPD nach exakt 4 Stunden trotz Traffic

[Barbarossa]

Moin zusammen,

ich habe jetzt schon einiges unter dem Suchbegriff DPD durchwühlt (Die Forumssuche lässt DPD als Schlüsselwort leider nicht zu, aber Google listet ja einige Threads).

Folgende Situation:

• Lancom ISG-4000 mit FEster IP und direkter Provideranbindung ohne Trennung.
• ca 100 Windows 10 Clients mit Windows IKEv2 und Zertifikatsbasierter Authentifizierung
• Child SA Lifetime 8 Stunden, IKE SA Lifetime 30 Stunden
• Clients arbeiten dauerhaft über den Tunnel per RDP/Citrix sowie VoIP Client
• Nach exakt vier Stunden schickt der ISG einen DPD-REQUEST und es laufen keine Daten mehr über den Tunnel
• Nach vier Requests (ca. 2 Minuten) ist der Tunnel wieder da

die ganzen vier Stunden vorher gibt es nur regelmäßig Einträge wie diesen:

Code: Alles auswählen

[VPN-Debug] 2023/06/23 11:36:35,364  Devicetime: 2023/06/23 11:36:35,292
Client01: Rescheduling DPD-Timer in 30s 992699us

Dann auf einmal sind es keine 30s mehr:

Code: Alles auswählen

[VPN-Debug] 2023/06/23 11:38:36,097  Devicetime: 2023/06/23 11:38:35,924
Client01: Rescheduling DPD-Timer in 11s 439695us

Und 10 Sekunden später:

Code: Alles auswählen

[VPN-Debug] 2023/06/23 11:38:46,507  Devicetime: 2023/06/23 11:38:46,423
Client01: Rescheduling DPD-Timer in 31s 0us (dpd should start)
Peer Client01: Received a request to establish an exchange for (ISAKMP-PEER-Client01, SEND-DPD)
INFORMATIONAL (37) exchange created:
  Client01, ISAKMP-PEER-Client01, ComChan 11
  SPI 0xF8B426CCBE4EBB51F1F1766190D3A0D4, MSG-ID 0x00000001, flags 0x00000054
Peer Client01: Constructing an INFORMATIONAL-REQUEST (DPD-REQUEST) for send
Message encrypted and authenticated successfully
Non-ESP-Marker Prepended
Sending an INFORMATIONAL-REQUEST (DPD-REQUEST) of 57 bytes (responder encrypted)
Gateways: <ISG-public-IP>:4500--><Client-IP>:4500, tag 0 (UDP)
SPIs: 0xF8B426CCBE4EBB51F1F1766190D3A0D4, Message-ID 1
Payloads: ENCR

[VPN-Status] 2023/06/23 11:38:46,507  Devicetime: 2023/06/23 11:38:46,423
Sending DPD-REQUEST (Client01)
Peer Client01: Constructing an INFORMATIONAL-REQUEST (DPD-REQUEST) for send
Message scheduled for retransmission (1) in 4.111680 seconds
Sending an INFORMATIONAL-REQUEST (DPD-REQUEST) of 57 bytes (responder encrypted)
Gateways: <ISG-public-IP>:4500--><Client-IP>:4500, tag 0 (UDP)
SPIs: 0xF8B426CCBE4EBB51F1F1766190D3A0D4, Message-ID 1

Im gleichen Atemzug:

Code: Alles auswählen

[VPN-Debug] 2023/06/23 11:38:46,525  Devicetime: 2023/06/23 11:38:46,441
IKE_SA(0xF8B426CCBE4EBB51F1F1766190D3A0D4).SEND-MSG-ID raised to 2
Peer Client01: Trigger next pended request to establish an exchange
  Current request is ISAKMP-PEER-Client01
  IKE_SA is not REPLACED
There are 0 pending requests

Der ist hier im ersten Auftreten direkt "raised to 2", vorhergehende Trace Einträge mit 1 oder 0 (falls er bei 0 anfängt zu zählen) finde ich nicht. In diesem Fall könnte ich mir nur vorstellen, dass er bei 1 anfängt und das vier Stunden vorher beim Verbindungsaufbau übermittelt wurde. Den habe ich nicht getraced.

Das ganze zählt dann alle 30 Sekunden etwa rauf bis "raised to 5" und 30 Sekunden nachdem er auf 5 gezählt hat kommt wieder das reguläre

Code: Alles auswählen

[VPN-Debug] 2023/06/23 11:40:50,129  Devicetime: 2023/06/23 11:40:50,054
Client01: Rescheduling DPD-Timer in 28s 306929us

Als wäre nichts gewesen. Ab diesem Zeitpunkt laufen dann auch wieder Daten durch den Tunnel ohne dass es eines Benutzereingriffs bedurft hätte.

Der Client sendet laut wireshark die ganze Zeit durch brav alle 20 Sekunden seinen NAT-keepalive an den ISG.

Ich bin gerade etwas ratlos, was da passiert. Ist das was da hochzählt der Versuch des ISG, ein Rekeying durchzuführen? Warum schlägt das drei oder vier Mal fehl und dann scheint es zu klappen, ohne dass man irgendwas dazu im Trace sieht? Oder passiert gar kein Rekeying? Warum löst dann auf einmal die DPD aus bei dauerhaftem Traffic durch den Tunnel? Ich hatte eine RDP-Session zu einem Jumphost offen auf dem das Lancom Trace lief, es wurde also definitiv dauerhaft durch den Tunnel kommuniziert. Oder macht der Windows VPN Client hier komische Dinge? Aber wenn der was an den ISG schickt betreffs des VPN müsste ich das ja auch im Trace sehen, oder?

[Dr.Einstein]

Betreibst du noch andere Tunnel, S2S oder weitere Betriebssysteme wie iOS womit du das Verhalten vergleichen kannst?

[GrandDixence]

Rekeying mit den Angaben unter:
viewtopic.php?p=112560#p112560
kontrollieren.

Bevor ein VPN-Tunnel als "getrennt" erachtet wird, müssen mehrere DPD-Versuche fehlschlagen. Als Beispiel:
alles-zum-lancom-advanced-vpn-client-f3 ... tml#p93544

Als Einstieg in das Thema "DPD" dienen die unter:
fragen-zum-thema-vpn-f14/vpn-tunnel-bre ... ml#p102564
verlinkten Beiträge.

Lebenszeiten des Schlüsselmaterials unter:

LCOS-Menübaum > Status > VPN > IKE
LCOS-Menübaum > Status > VPN > ESP

beobachten. Insbesondere die Angaben in der Spalte "Alter" und "Soft-Sek" beachten! Siehe dazu:
fragen-zum-thema-vpn-f14/fast-kein-traf ... tml#p92853

Mit Trace alle (verschlüsselten) IKE-Telegramme aufzeichnen und auswerten (vpn-ike oder ähnlich). DPD und alle Schlüsselmaterialverhandlungen (Rekeying) laufen durch den Steuerkanal (IKE) des VPN-Tunnels. Wenn man einen Einwahl-VPN (RAS) mit 100 VPN-Clients betreibt, sollte man IKE-Telegramme lesen und deren Inhalt verstehen.

[GrandDixence]

Rekeying mit den Angaben unter:
viewtopic.php?p=112560#p112560
kontrollieren.

Bevor ein VPN-Tunnel als "getrennt" erachtet wird, müssen mehrere DPD-Versuche fehlschlagen. Als Beispiel:
alles-zum-lancom-advanced-vpn-client-f3 ... tml#p93544

Als Einstieg in das Thema "DPD" dienen die unter:
fragen-zum-thema-vpn-f14/vpn-tunnel-bre ... ml#p102564
verlinkten Beiträge.

Lebenszeiten des Schlüsselmaterials unter:

LCOS-Menübaum > Status > VPN > IKE
LCOS-Menübaum > Status > VPN > ESP

beobachten. Insbesondere die Angaben in der Spalte "Alter" und "Soft-Sek" beachten! Siehe dazu:
fragen-zum-thema-vpn-f14/fast-kein-traf ... tml#p92853

Mit Trace alle (verschlüsselten) IKE-Telegramme aufzeichnen und auswerten (vpn-ike oder ähnlich). DPD und alle Schlüsselmaterialverhandlungen (Rekeying) laufen durch den Steuerkanal (IKE) des VPN-Tunnels. Wenn man einen Einwahl-VPN (RAS) mit 100 VPN-Clients betreibt, sollte man IKE-Telegramme lesen und deren Inhalt verstehen.

Ich hatte eine RDP-Session zu einem Jumphost offen auf dem das Lancom Trace lief, es wurde also definitiv dauerhaft durch den Tunnel kommuniziert.

Zum sicheren Erkennen von kurzzeitigen Verbindungsunterbrüche muss Ping eingesetzt werden (ICMP-Polling). => Windows: ping -n 1000 Linux: ping -c 1000 Siehe dazu:
fragen-zum-thema-vpn-f14/ikev2-loadbala ... 17345.html

fragen-zur-lancom-systems-routern-und-g ... ml#p103515

[Barbarossa]

Betreibst du noch andere Tunnel, S2S oder weitere Betriebssysteme wie iOS womit du das Verhalten vergleichen kannst?

WIr haben noch einen IKEv1/IPSec Site to Site Tunnel, der das Problem nicht hat.
Außerdem haben wir noch iPhones dabei, bei denen fällt zumindest keine Unterbrechung auf, die werden aber auch nur sporadisch zum Telefonieren und für Email genutzt.
Zu guter Letzt haben wir auch eine Handvoll Geräte, die den Lancom VPN Client nutzen, die haben das Problem auch nicht.

Zum Thema Rekeying habe ich mir schon die FInger wund gesucht, aber bei Microsoft nichts zu Lebenszeiten gefunden. Ich habe auf einer Drittseite gefunden, dass Windows 10 das IKE Rekeying nach ca. 7,5 Stunden initiiert (was weniger als unsere konfigurierten 30 Stunden sind) und die SAs nach einer Stunde, leider alles ohne Quellen.
Zusätzlich scheint Windows nach einem gewissen Übertragungsvolumen ein Rekeying zu initiieren, beobachtet wurden 30 Rekeys bei 4,3GB Übetragener Daten.

Aber all das sollte in seiner Genauigkeit recht unerheblich für den ISG sein, wenn der Client nach einem Rekey fragt, sollte der ISG das einfach machen, oder nicht?

Lebenszeiten des Schlüsselmaterials unter:

LCOS-Menübaum > Status > VPN > IKE
LCOS-Menübaum > Status > VPN > ESP

beobachten. Insbesondere die Angaben in der Spalte "Alter" und "Soft-Sek" beachten!

Die Beobachtung deckt sich tatsächlich mit den Aussagen zum Rekeying unter Windows, keins der Notebooks erreicht 3600 Sekunden beim Alter, Soft-Sek sind 80% von den 8 Stunden Max-Sek, die Clients melden sich also deutlich eher zum Rekeying. Wenn der zusätzliche Trigger anhand des Datenvolumens dazu kommt, spricht das meiner Meinung nach auch gegen eine Clientseitige Thematik nach vier Stunden, da sich die Rekeys dann plus-minus sonstwo bewegen können.

Zum sicheren Erkennen von kurzzeitigen Verbindungsunterbrüche muss Ping eingesetzt werden (ICMP-Polling).

Es geht in diesem Falle ja darum, dass die Unterbrechung auch ohne den Ping festgestellt wird, weil eben nicht nur einzelne Pakete droppen, sondern für zwei Minuten keinerlei Nutzdaten den Tunnel (Phase2) passieren.

Schlussendlich ist leider absolut unklar, woher das vier Stunden Limit kommt.

Was auch nicht hilfreich war, aber das nur am Rande, war mein Versuch, den ISG per remote pcap über wireshark zu tracen. Wenn ich das gestartet habe, hat der einfach alle VPN-Connections verworfen und sich komplett weggehängt. Damit habe ich nicht gerechnet, das ist auch nicht dokumentiert, ich habe das mal bei unserem VoIP Router (auch Lancom) gemacht und da war keinerlei Einschränkung des Routers ersichtlich. So muss ich mich halt darauf verlassen, dass das Lancom Trace auch vollständig ist.

[Dr.Einstein]

Schneide mal bitte noch zusätzlich den VPN-IKE Trace mit. Sollte ja relativ schnell einsammelbar sein, dass du dir deine Verbindungsliste anschaust und guckst, wann der nächste auf 4h kommen müsste.

Und welche LCOS Version setzt du ein?

[GrandDixence]

Wie unter:
https://wiki.strongswan.org/issues/3400
nachlesbar, wird das Rekeying sehr wahrscheinlich fehlschlagen, wenn der "Powershell-Hack" fehlt. Siehe auch:
fragen-zum-thema-vpn-f14/vpn-via-androi ... tml#p97795