Practical guide to IPsec DPD

Finally my virtual SRX lab is ready for my DPD tests . As you might know, DPD (Dead Peer Detection) is a method used to detect if an IPsec peer is alive or not. Here we will see the ways DPD can be configured also why we really need a monitoring method like DPD. I will talk about VPN monitoring probably in a different post though.

For DPD tests, I will use the following IPsec topology.


Test Environment

Test 1

  • Establish Phase1 and Phase2 of the IPsec tunnel
  • wait a minute or so and send an ICMP probe.


Above packet capture is taken on the core network to see the packets exchanged during tunnel establishment. Packets from number 1-6 belong to Phase1 and 7-9 belong to Phase2. Then we are waiting ~174 seconds and send an ICMP packet from the EAST IPsec peer’s internal network. What I am trying to show is that from the moment tunnel is established and the first ICMP is sent, there isn’t any packet exchanged. We have a default IPsec tunnel configuration with no monitoring configured but ICMP is successfully sent through the tunnel and response is received.

We also confirmed that tunnel is UP everyting is fine so far.

Test 2

  • We power off the remote IPsec peer (co-a: LAB1007) on the west side abruptly without giving any chance for IPsec to terminate the tunnel
  • After we power off the remote IPsec peer, we send one ICMP packet and we take another capture on the core network. Heyy, we can see that packet is encrypted properly and sent to the dead peer but why are we sending packets to a dead peer, isn’t that the remote peer is powered off. Let’s look SRX2 device’s view on this.


    Apparently SRX2 IPsec peer has no idea what happened to its peer. Phase1 and Phase2 are still UP. Because it doesn’t really check if it is alive or not.

    Test 3

  • We enable DPD to check if the remote peer is alive or not
  • Now if 3 probes in 10 seconds intervals towards remote peer fails we should declare the tunnel dead and terminate it in 30 seconds but I won’t generate any traffic during this period.

    More than 3 minutes passed but DPD didn’t bring the tunnel down. What is happening? Now I will send one ICMP from local network towards the WEST internal network to create traffic.


    1st packet is my ICMP packet and just after that we see the DPD probes. After the last probe fails,

    IPsec tunnel is terminated. Now the question is why DPD waits so long and why it starts probing after our ICMP packet i.e we create traffic. The answer lies in the CLI prompt

    DPD default mode is optimized which means DPD probes are only sent when there is outgoing traffic but no incoming traffic is received but in our case, I intentionally didn’t generate any traffic because of which no DPD probe was sent. As soon as we sent ICMP, DPD probes were sent and tunnel is terminated.

    Apparently the default mode is due to the following RFC3706 implementation suggestion

    If you want probes to be sent all the time regardless of traffic activity, then you must set always-send option instead to make sure that DPD probes will be always triggered.

    3 thoughts on “Practical guide to IPsec DPD

    You have a feedback?

    This site uses Akismet to reduce spam. Learn how your comment data is processed.