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
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
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
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
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
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
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?