Cómo solucionar problemas de un túnel VPN IPsec IKEv1 desactivado por DPD

Cómo solucionar problemas de un túnel VPN IPsec IKEv1 desactivado por DPD

11098
Created On 07/15/24 21:32 PM - Last Modified 12/08/25 19:39 PM


Objective


  • Verifique la configuración de detección de pares muertos (DPD) en ambos puntos de conexión del túnel VPN IPsec.
  • Utilice la marca de tiempo del evento DPD down para correlacionarlo con otros eventos que podrían afectar a la conectividad entre los pares VPN.
  • Solucione problemas de conectividad VPN IPsec.
  • Recopile capturas de paquetes de depuración para comprobar si el firewall está enviando y recibiendo paquetes DPD.


Environment


  • Túnel VPN IPsec
  • IKEv1
  • Detección de pares muertos (DPD


Procedure


  1. Verifique la configuración de DPD de detección de pares muertos en ambos puntos de conexión del túnel VPN IPsec. Para NGFW, vaya a Red > Perfiles de red > Gateways IKE > Opciones avanzadas. Asegúrese de que la detección de pares inactivos esté habilitada y que el intervalo y el reintento de DPD coincidan con la configuración del otro extremo del túnel:Detección de pares muertos
  2. Cuando el túnel IPsec se cae debido a DPD, los siguientes mensajes de registro se mostrarán en el registro del sistema:
    > 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. 
    Y los mensajes a continuación aparecerán en los registros de 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> 
    El intervalo predeterminado de envío del paquete DPD es cada 5 segundos cuando SA está inactivo. Al perder la conexión, el firewall realizará 5 reintentos de DPD y, una vez alcanzado el número máximo de reintentos, el firewall desactivará las SA de fase 1 y fase 2. Busque los mensajes anteriores y anote la marca de tiempo para que pueda usarla para correlacionar otros eventos que ayudarán a encontrar la causa raíz de la falla de DPD.
  3. Cuando el túnel IPsec deja de funcionar debido a DPD, es una indicación de que hay problemas de conectividad entre los pares VPN IPsec. Para obtener más detalles sobre cómo solucionarlo, consulte Cómo solucionar problemas de conectividad VPN IPSec.
  4. Para un problema en curso con DPD, si el problema se resuelve deshabilitando la verificación de DPD y si tiene dudas de que el firewall está recibiendo o enviando el paquete DPD, que es el paquete R-U-There informativo vacío. Establezca una ventana de mantenimiento para recopilar una captura de paquetes debug ikemgr. Dado que el DPD "no es persistente" y solo se activa mediante una regeneración de claves de fase 2, debe desencadenar manualmente una nueva clave de fase 2 mediante el comando de prueba a continuación para poder probar y verificar la funcionalidad de 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. Nota: Tenga cuidado con los comandos anteriores: el resaltado en naranja puede convertirse en un comando que consume muchos recursos, por lo que se recomienda emitirlo durante una ventana de mantenimiento, de lo contrario, asegúrese de que el pcap esté encendido durante un corto período de tiempo antes de apagarlo usando el tercer comando anterior.
    1. Si el firewall envía y recibe el paquete DPD informativo vacío, la captura de paquetes tendrá el siguiente aspecto:Captura de paquetes IKEv1
    2. Habilite las depuraciones para la puerta de enlace afectada mediante el comando:
      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. En función de la captura de paquetes recopilada entre los dos pares del túnel, la resolución del problema puede incluir el ajuste de los valores de tiempo de espera de DPD, aumentando el intervalo de DPD y los valores de reintento en ambos puntos finales para que la comprobación de DPD sea menos estricta. Otras soluciones podrían implicar la corrección de políticas mal configuradas, la configuración de entradas de ruta adecuadas o la solución de cualquier posible problema de red que afecte a la accesibilidad del par remoto.


Additional Information


Otras referencias a comprobar:

La VPN IPSec de sitio a sitio entre el firewall de Palo Alto Networks y el router Cisco es inestable o intermitente.
¿Qué es la detección de pares muertos y el monitoreo de túneles a través del túnel IPSec?



Actions
  • Print
  • Copy Link

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

Choose Language