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

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

12881
Created On 07/15/24 21:31 PM - Last Modified 08/14/24 01:48 AM


Objective


  • Vérifiez la configuration de la vérification de l’activité 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 de vérification de l’activité.

Environment


  • Tunnel VPN IPsec
  • IKEv2
  • DPD/ Contrôle de la vivacité

Procedure


  1. Vérifiez la configuration de la vérification de l’activité 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 vérification de l’activité est activée et que l’intervalle correspond aux paramètres de l’autre extrémité du tunnel :Vérification de la vivacité
    1. IKEv2 utilise une vérification de l’activité (similaire à la détection d’homologue mort (DPD) dans IKEv1) pour déterminer si un homologue est toujours disponible. L’option de vérification de l’activité est activée par défaut.
  2. Lorsque le tunnel IPsec tombe en panne à cause de DPD, les messages de journaux ci-dessous s’affichent dans le journal système : 
    > show log system direction equal backward
2019/03/06 18:24:04 low      vpn     seapa- ikev2-n 0  IKEv2 IKE SA is down determined by DPD.
2019/03/06 17:26:27 low      vpn     seapa- ikev2-n 0  IKEv2 IKE SA is down determined by DPD.

    Et les messages ci-dessous apparaîtront dans les journaux IKEMGR : 
    > less mp-log ikemgr.log
2019-03-06 17:26:28.000 -0800  [INFO]: \{    1:    1}: DPD down, rekey vpn tunnel <awsseapa-to-azeapa>, SA state ESTABLISHED
2019-03-06 18:24:05.000 -0800  [INFO]: \{    1:    1}: DPD down, rekey vpn tunnel <awsseapa-to-azeapa>, SA state ESTABLISHED
    L'intervalle par défaut de vérification de la durée de vie est toutes les 5 secondes lorsque sa est inactive. En cas de perte de connexion, le pare-feu effectuera 10 tentatives d’activité. 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 pour corréler d’autres événements connexes, ce qui vous aidera à trouver la cause profonde de l’échec de la vérification de l’activité.
  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. En cas de problème continu de tunnel en panne due à DPD et en cas de doute sur le fait que le pare-feu reçoit ou envoie le paquet de vérification de l’activité, qui est le paquet d’information vide. Définissez une fenêtre de maintenance pour collecter une capture de paquets ikemgr de débogage : 
    debug ike pcap on
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
debug ike pcap off
    Remarque : Soyez très prudent avec les commandes ci-dessus, en particulier avec celle surlignée en orange car elle peut devenir gourmande en ressources, c’est pourquoi il est recommandé de l’émettre pendant une fenêtre de maintenance.
    1. Si le pare-feu envoie et reçoit le paquet de vérification de l’activité des informations vide, la capture de paquet ressemblera à ce qui suit :capture de paquets
    2. De même, vous pouvez effectuer une capture de paquets de plan de données entre les deux points de terminaison du tunnel en définissant la source et la destination du filtre de paquets sur les adresses IP des points de terminaison, comme illustré dans l’image ci-dessous :capture de paquets 3
    3. Activez les débogages pour la passerelle affectée à l’aide de la commande : 
      debug ike gateway <name of the gateway> on debug
      Dans ce cas, les journaux ikemg afficheront les messages ci-dessous : 
      2024-07-15 10:55:41.005 -0700  [DEBG]: 10.46.36.241[500] - 10.46.36.240[500]:(nil) 1 times of 76 bytes message will be sent over socket 1024
2024-07-15 10:55:41.007 -0700  [DEBG]: processing isakmp packet
2024-07-15 10:55:41.007 -0700  [DEBG]: ===
2024-07-15 10:55:41.007 -0700  [DEBG]: 76 bytes message received from 10.46.36.240
2024-07-15 10:55:41.007 -0700  [DEBG]: {    2:     }: [IKE Initiator] response message_id 704 expected 704
2024-07-15 10:55:41.013 -0700  [DEBG]: {    2:     }: response exch type 37
2024-07-15 10:55:41.013 -0700  [DEBG]: {    2:     }: update response message_id 0x2c0
2024-07-15 10:55:46.005 -0700  [DEBG]: 10.46.36.241[500] - 10.46.36.240[500]:(nil) 1 times of 76 bytes message will be sent over socket 1024
2024-07-15 10:55:46.006 -0700  [DEBG]: processing isakmp packet
2024-07-15 10:55:46.006 -0700  [DEBG]: ===
2024-07-15 10:55:46.006 -0700  [DEBG]: 76 bytes message received from 10.46.36.240
2024-07-15 10:55:46.006 -0700  [DEBG]: {    2:     }: [IKE Initiator] response message_id 705 expected 705
2024-07-15 10:55:46.014 -0700  [DEBG]: {    2:     }: response exch type 37
2024-07-15 10:55:46.014 -0700  [DEBG]: {    2:     }: update response message_id 0x2c1
    4. Désactivez les débogages à l’aide de la commande : 
      debug ike gateway <name of the gateway> off
  5. REMARQUE IMPORTANTE sur le comportement de la vérification de l’activité IKEv2 :
    1. DPD (qui est le contrôle de l’activité dans le cas d’IKEv2) est toujours activé. Tous les paquets IKEv2 à l’exception du paquet d’informations vide servent à vérifier l’activité.
    2. Le paquet de vérification de l’activité (informationnel) n’est envoyé que lorsqu’il n’y a aucune activité après dpd_interval sur la SA IKE et la SA enfant.
    3. enable : s’il est défini sur yes, un message d’information vide sera envoyé après un certain temps d’inactivité (IKE). Ce temps d’attente est défini par dpd_interval.
    4. En cas d’échec de la vérification de l’activité, la SA IKE et toutes les SA enfants configurées via cette SA IKE sont supprimées. La passerelle IKE démarre un nouvel échange de IKE_SA_INIT.
  6. 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 de la valeur de l’intervalle de vérification de l’activité, en l’augmentant sur les deux points de terminaison pour rendre la vérification 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.

Additional Information


Vérification de la vivacité : S’il n’y a eu que du trafic sortant sur toutes les SA associées à une SA IKE, il est essentiel de confirmer la vivacité de l’autre point de terminaison pour éviter les trous noirs. Les passerelles IKEv2 peuvent effectuer des vérifications d’activité pour empêcher l’envoi de messages à un homologue mort. La réception d’un nouveau message protégé par chiffrement sur une SA IKE ou l’une de ses SA enfants garantit la vivacité de la SA IKE et de toutes ses SA enfants.
Other users also viewed:
Actions
  • Print
  • Copy Link

    https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA14u000000HDbVCAW&lang=fr&refURL=http%3A%2F%2Fknowledgebase.paloaltonetworks.com%2FKCSArticleDetail

Choose Language