Fehlerbehebung bei einem IKEv1 IPsec-VPN-Tunnel, der von DPD heruntergefahren wurde

• Überprüfen Sie die DPD-Konfiguration (Dead Peer Detection) auf beiden Endpunkten des IPsec-VPN-Tunnels.
• Verwenden Sie den Zeitstempel des DPD-Ausfallereignisses, um mit anderen Ereignissen zu korrelieren, die sich auf die Konnektivität zwischen den VPN-Peers auswirken könnten.
• Beheben Sie Probleme mit der IPsec-VPN-Konnektivität.
• Sammeln Sie Debug-Paketerfassungen, um zu überprüfen, ob die Firewall DPD-Pakete sendet und empfängt.

• IPsec-VPN-Tunnel
• IKEv1
• Dead-Peer-Erkennung (DPD)

1. Überprüfen Sie die DPD-Konfiguration für die Erkennung toter Peers auf beiden Endpunkten des IPsec-VPN-Tunnels. Navigieren Sie für NGFW zu Netzwerk- > Netzwerkprofile > IKE-Gateways > Erweiterte Optionen. Stellen Sie sicher, dass die Dead Peer Detection aktiviert ist und das DPD-Intervall und der DPD-Wiederholungsversuch mit den Einstellungen am anderen Ende des Tunnels übereinstimmen:
2. Wenn der IPsec-Tunnel aufgrund von DPD ausfällt, werden die folgenden Protokollmeldungen im Systemprotokoll angezeigt:

   > show log system direction equal backward
   2021/01/14 21:05:02 IKE phase-1 SA is down determined by DPD.
   2021/01/13 21:17:24 IKE phase-1 SA is down determined by DPD.
   2021/01/12 20:41:32 IKE phase-1 SA is down determined by DPD. 

   Und die folgenden Meldungen werden in den IKEMGR-Protokollen angezeigt.

   > less mp-log ikemgr.log
   2021-01-14 11:25:12 2021-01-14 21:05:02.001 +0200 [INFO]: { 14: 219}: DPD down, rekey vpn tunnel <NIDA_VPN_MACH:ProxyID15> 

   Das Standardintervall für das Senden des DPD-Pakets beträgt alle 5 Sekunden, wenn sich die SA im Leerlauf befindet. Wenn die Verbindung unterbrochen wird, führt die Firewall 5 DPD-Wiederholungen durch, und nachdem die maximale Anzahl von Wiederholungen erreicht ist, beendet die Firewall die SAs der Phase 1 und 2. Suchen Sie nach den obigen Meldungen und notieren Sie sich den Zeitstempel, damit Sie ihn verwenden können, um andere Ereignisse zu korrelieren, die bei der Suche nach der Ursache des DPD-Fehlers hilfreich sind.
3. Wenn der IPsec-Tunnel aufgrund von DPD ausfällt, ist dies ein Hinweis darauf, dass es Verbindungsprobleme zwischen den IPsec-VPN-Peers gibt. Weitere Informationen zur Behebung finden Sie unter Beheben von Problemen mit der IPSec-VPN-Konnektivität.
4. Bei einem anhaltenden Problem mit DPD, wenn das Problem durch Deaktivieren der DPD-Prüfung behoben wird und wenn Zweifel bestehen, dass die Firewall das DPD-Paket empfängt oder sendet, bei dem es sich um das leere Informations-R-U-There-Paket handelt. Legen Sie ein Wartungsfenster fest, um eine Debug-ikemgr-Paketerfassung zu erfassen. Da der DPD "nicht persistent" ist und nur durch einen Phase 2 Rekey ausgelöst wird, müssen Sie mit dem unten stehenden Testbefehl manuell einen Phase2 Rekey auslösen, um die DPD-Funktionalität testen und überprüfen zu können. :

   debug ike pcap on
   test vpn ipsec-sa tunnel <name of the tunnel>
   debug ike pcap off
   view-pcap no-dns-lookup yes no-port-lookup yes debug-pcap ikemgr.pcap
   scp export debug-pcap from ikemgr.pcap to username@host:path

5. Hinweis: Seien Sie vorsichtig mit den oben genannten Befehlen: Der orange hervorgehobene Befehl kann zu einem ressourcenintensiven Befehl werden, weshalb es empfohlen wird, ihn während eines Wartungsfensters auszugeben, andernfalls stellen Sie sicher, dass das pcap für kurze Zeit eingeschaltet ist, bevor Sie es mit dem dritten Befehl oben ausschalten.
   1. Wenn die Firewall das leere informative DPD-Paket sendet und empfängt, sieht die Paketerfassung wie folgt aus:
   2. Aktivieren Sie die Debugger für das betroffene Gateway mit dem folgenden Befehl:

      debug ike gateway <name of the gateway> on debug

      The ikemg logs in this case will show the below messages:The ikemg logs in this case will show the below messages:
      

      2024-07-15 16:11:24.016 -0700  [DEBG]: {    2:     }: DPD monitoring.... ip 0 0
      2024-07-15 16:11:24.016 -0700  [DEBG]: {    2:     }: compute IV for phase2
      2024-07-15 16:11:24.016 -0700  [DEBG]: {    2:     }: phase1 last IV:
      2024-07-15 16:11:24.016 -0700  [DEBG]: {    2:     }: encryption(aes)
      2024-07-15 16:11:24.016 -0700  [DEBG]: {    2:     }: phase2 IV computed:
      2024-07-15 16:11:24.016 -0700  [DEBG]: {    2:     }: HASH with:
      2024-07-15 16:11:24.016 -0700  [DEBG]: {    2:     }: hmac(hmac_sha1)
      2024-07-15 16:11:24.016 -0700  [DEBG]: {    2:     }: HASH computed:
      2024-07-15 16:11:24.017 -0700  [DEBG]: {    2:     }: begin encryption.
      2024-07-15 16:11:24.017 -0700  [DEBG]: {    2:     }: encryption(aes)
      2024-07-15 16:11:24.017 -0700  [DEBG]: {    2:     }: pad length = 8
      2024-07-15 16:11:24.017 -0700  [DEBG]: {    2:     }: encryption(aes)
      2024-07-15 16:11:24.017 -0700  [DEBG]: {    2:     }: with key:
      2024-07-15 16:11:24.017 -0700  [DEBG]: {    2:     }: encrypted payload by IV:
      2024-07-15 16:11:24.017 -0700  [DEBG]: {    2:     }: save IV for next:
      2024-07-15 16:11:24.017 -0700  [DEBG]: {    2:     }: encrypted.
      2024-07-15 16:11:24.017 -0700  [DEBG]: {    2:     }: 92 bytes from 10.46.36.241[500] to 10.46.36.240[500]
      2024-07-15 16:11:24.017 -0700  [DEBG]: {    2:     }: sendto Information notify.
      2024-07-15 16:11:24.017 -0700  [DEBG]: {    2:     }: DPD R-U-There sent (0)
      2024-07-15 16:11:24.017 -0700  [DEBG]: {    2:     }: rescheduling send_r_u (5).
      2024-07-15 16:11:24.019 -0700  [DEBG]: {    2:     }: receive Information.
      2024-07-15 16:11:24.019 -0700  [DEBG]: {    2:     }: compute IV for phase2
      2024-07-15 16:11:24.019 -0700  [DEBG]: {    2:     }: phase1 last IV:
      2024-07-15 16:11:24.020 -0700  [DEBG]: {    2:     }: encryption(aes)
      2024-07-15 16:11:24.020 -0700  [DEBG]: {    2:     }: phase2 IV computed:
      2024-07-15 16:11:24.020 -0700  [DEBG]: {    2:     }: begin decryption.
      2024-07-15 16:11:24.020 -0700  [DEBG]: {    2:     }: encryption(aes)
      2024-07-15 16:11:24.020 -0700  [DEBG]: {    2:     }: IV was saved for next processing:
      2024-07-15 16:11:24.020 -0700  [DEBG]: {    2:     }: encryption(aes)
      2024-07-15 16:11:24.020 -0700  [DEBG]: {    2:     }: with key:
      2024-07-15 16:11:24.020 -0700  [DEBG]: {    2:     }: decrypted payload by IV:
      2024-07-15 16:11:24.020 -0700  [DEBG]: {    2:     }: decrypted payload, but not trimed.
      2024-07-15 16:11:24.020 -0700  [DEBG]: {    2:     }: padding len=8
      2024-07-15 16:11:24.020 -0700  [DEBG]: {    2:     }: decrypted.
      2024-07-15 16:11:24.020 -0700  [DEBG]: {    2:     }: HASH with:
      2024-07-15 16:11:24.020 -0700  [DEBG]: {    2:     }: hmac(hmac_sha1)
      2024-07-15 16:11:24.020 -0700  [DEBG]: {    2:     }: HASH computed:
      2024-07-15 16:11:24.020 -0700  [DEBG]: {    2:     }: hash validated.
      2024-07-15 16:11:24.020 -0700  [DEBG]: {    2:     }: begin.
      2024-07-15 16:11:24.020 -0700  [DEBG]: {    2:     }: seen nptype=8(hash)
      2024-07-15 16:11:24.020 -0700  [DEBG]: {    2:     }: seen nptype=11(notify)
      2024-07-15 16:11:24.020 -0700  [DEBG]: {    2:     }: succeed.
      2024-07-15 16:11:24.020 -0700  [DEBG]: {    2:     }: DPD R-U-There-Ack received
      2024-07-15 16:11:24.020 -0700  [DEBG]: {    2:     }: received an R-U-THERE-ACK
      2024-07-15 16:11:24.020 -0700  [PNTF]: {    2:     }: notification message 36137:R-U-THERE-ACK, doi=1 proto_id=1 spi=30712ff29eddaded 8256275ddba5a1c2 (size=16).
      2024-07-15 16:11:46.016 -0700  [DEBG]: {    2:     }: del packet d0f81e2a:20 size    44, rcp 0
      

   3. Basierend auf der Paketerfassung, die zwischen den beiden Peers des Tunnels erfasst wurde, kann die Lösung des Problems die Anpassung der DPD-Timeoutwerte umfassen, indem das DPD-Intervall und die Wiederholungswerte auf beiden Endpunkten erhöht werden, um die DPD-Überprüfung weniger streng zu machen. Andere Lösungen können das Korrigieren falsch konfigurierter Richtlinien, das Konfigurieren korrekter Routeneinträge oder das Beheben potenzieller Netzwerkprobleme umfassen, die sich auf die Erreichbarkeit des Remote-Peers auswirken.

Weitere zu überprüfende Referenzen:

Das Site-to-Site-IPSec-VPN zwischen der Palo Alto Networks Firewall und dem Cisco Router ist instabil oder intermittierend.
Was ist Dead Peer Detection und Tunnelüberwachung über IPSec-Tunnel?