Comment dépanner un tunnel VPN IPsec IKEv1 mis en panne par DPD

• Vérifiez la configuration DPD (Dead Peer Detection) sur les deux points de terminaison du tunnel VPN IPsec.
• Utilisez l’horodatage de l’événement DPD down pour établir une corrélation avec d’autres événements susceptibles d’affecter la connectivité entre les homologues VPN.
• Résoudre les problèmes de connectivité VPN IPsec.
• Collectez les captures de paquets de débogage pour vérifier si le pare-feu envoie et reçoit des paquets DPD.

• Tunnel VPN IPsec
• IKEv1
• Détection des pairs morts (DPD

1. Vérifiez la configuration DPD de la détection d’homologue mort sur les deux points de terminaison du tunnel VPN IPsec. Pour NGFW, accédez à Réseau > Profils réseau > Passerelles IKE > Options avancées. Assurez-vous que la détection d’homologue mort est activée et que l’intervalle DPD et la nouvelle tentative correspondent aux paramètres de l’autre extrémité du tunnel :
2. Lorsque le tunnel IPsec tombe en panne en raison de DPD, les messages de journal ci-dessous s’affichent dans le journal système :

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

   Et les messages ci-dessous apparaîtront dans les journaux IKEMGR.

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

   L’intervalle par défaut d’envoi du paquet DPD est toutes les 5 secondes lorsque SA est inactif. En cas de perte de connexion, le pare-feu effectue 5 tentatives DPD et, une fois le nombre maximal de tentatives atteint, le pare-feu détruit les SA de phase 1 et de phase 2. Recherchez les messages ci-dessus et notez l’horodatage afin de pouvoir l’utiliser afin de corréler d’autres événements qui aideront à trouver la cause profonde de l’échec de DPD.
3. Lorsque le tunnel IPsec tombe en panne à cause de DPD, cela indique qu’il existe des problèmes de connectivité entre les homologues VPN IPsec. Pour plus d’informations sur la résolution du problème, reportez-vous à la section Résolution d’un problème de connectivité VPN IPSec.
4. Dans le cas d’un problème persistant avec DPD, si les problèmes sont résolus en désactivant la vérification DPD et en cas de doute sur le fait que le pare-feu reçoit ou envoie le paquet DPD qui est le paquet d’information R-U-There vide. Définissez une fenêtre de maintenance pour collecter une capture de paquets ikemgr de débogage. Étant donné que le DPD n’est « pas persistant » et n’est déclenché que par une nouvelle clé de phase 2, vous devez déclencher manuellement une nouvelle clé de phase 2 à l’aide de la commande de test ci-dessous pour pouvoir tester et vérifier la fonctionnalité DPD. :

   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. Remarque : Soyez prudent avec les commandes ci-dessus : celle surlignée en orange peut devenir une commande gourmande en ressources, c’est pourquoi il est recommandé de l’émettre pendant une fenêtre de maintenance, sinon assurez-vous que le pcap est activé pendant une courte période de temps avant de le désactiver à l’aide de la troisième commande ci-dessus.
   1. Si le pare-feu envoie et reçoit le paquet DPD d’information vide, la capture de paquet se présente comme suit :
   2. Activez les débogages pour la passerelle affectée à l’aide de la commande :

      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. Sur la base de la capture de paquets collectée entre les deux homologues du tunnel, la résolution du problème peut inclure l’ajustement des valeurs de délai d’expiration DPD, en augmentant l’intervalle DPD et en réessayant les valeurs sur les deux points de terminaison pour rendre la vérification DPD moins stricte. D’autres solutions peuvent impliquer la correction de stratégies mal configurées, la configuration d’entrées de route appropriées ou la résolution de tout problème réseau potentiel affectant l’accessibilité de l’homologue distant.

Autres références à vérifier :

Le VPN IPSec site à site entre le pare-feu Palo Alto Networks et le routeur Cisco est instable ou intermittent.
Qu’est-ce que la détection des homologues morts et la surveillance des tunnels sur le tunnel IPSec ?