如何对 DPD 关闭的 IKEv1 IPsec VPN 隧道进行故障排除

如何对 DPD 关闭的 IKEv1 IPsec VPN 隧道进行故障排除

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


Objective


  • 验证 IPsec VPN 隧道的两个端点上的失效对等体检测 （DPD） 配置。
  • 使用 DPD 关闭事件的时间戳与可能影响 VPN 对等体之间连接的其他事件相关联。
  • 对 IPsec VPN 连接进行故障排除。
  • 收集调试数据包捕获，以检查防火墙是否正在发送和接收 DPD 数据包。

Environment


  • IPsec VPN 隧道
  • IKEv1
  • 失效对等体检测 （DPD

Procedure


  1. 验证 IPsec VPN 隧道的两个端点上的 Dead Peer Detection DPD 配置。 对于 NGFW，请导航至 网络>网络配置文件> IKE 网关>高级选项。 确保已启用 Dead Peer Detection，并且 DPD 间隔和重试与隧道另一端的设置匹配：失效对等体检测
  2. 当 IPsec 隧道因 DPD 而关闭时，以下日志消息将显示在系统日志中： 
    > 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.
    下面的消息将显示在 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>
    当 SA 空闲时，发送 DPD 数据包的默认间隔为每 5 秒一次。 失去连接后，防火墙将重试 5 次 DPD，在达到最大重试次数后，防火墙将关闭阶段 1 和阶段 2 SA。 查找上面的消息并记下时间戳，以便您可以使用它来关联其他事件，这将有助于找到 DPD 失败的根本原因。
  3. 当 IPsec 隧道因 DPD 而关闭时，这表明 IPsec VPN 对等体之间存在连接问题。 有关如何修正的更多详细信息，请参阅如何解决 IPSec VPN 连接问题。
  4. 对于 DPD 的持续问题，如果通过禁用 DPD 检查解决了问题，并且怀疑防火墙正在接收或发送 DPD 数据包，该数据包是空的信息性 R-U-There 数据包。 设置维护时段以收集调试 ikemgr 数据包捕获。 由于 DPD 是“非持久的”，并且仅由第 2 阶段重新密钥触发，因此您需要使用下面的测试命令手动触发第 2 阶段重新密钥，以便能够测试和检查 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. 注意：请谨慎使用上述命令：以橙色突出显示的命令可能会成为资源密集型命令，这就是为什么建议在维护时段内发出它，否则请确保 pcap 在短时间内处于打开状态，然后再使用上述第三个命令将其关闭。
    1. 如果防火墙正在发送和接收空的信息性 DPD 数据包，则数据包捕获将如下所示：数据包捕获 IKEv1
    2. 使用以下命令为受影响的网关启用调试： 
      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. 根据在隧道的两个对等体之间收集的数据包捕获，问题的解决方法可能包括调整 DPD 超时值，通过增加两个端点上的 DPD 间隔和重试值，以降低 DPD 检查的严格性。 其他解决方案可能涉及更正任何配置错误的策略、配置正确的路由条目或解决影响远程对等体可访问性的任何潜在网络问题。

Additional Information


其他需要检查的参考资料：

Palo Alto Networks 防火墙和 Cisco 路由器之间的站点到站点 IPSec VPN 不稳定或间歇性。
什么是跨 IPSec 隧道的死对等体检测和隧道监控？
Other users also viewed:
Actions
  • Print
  • Copy Link

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

Choose Language