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

root@srx2> show version 
Hostname: srx2
Model: firefly-perimeter
JUNOS Software Release [12.1X47-D20.7]

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.

root@srx2> show security ike sa | match 
3592751 UP     5161c49b0129f92d  1b5656bbb3139ab5  Main     

root@srx2> show security ipsec sa | match  
  <131074 ESP:   sha1   cc830e9d 10993/unlim   -   root 500    
  >131074 ESP:   sha1   29b19e03 10993/unlim   -   root 500    

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.


    root@srx2> show security ike sa | match      
    3592751 UP     5161c49b0129f92d  1b5656bbb3139ab5  Main     
    root@srx2> show security ipsec sa | match    
      <131074 ESP:   sha1   cc830e9d 10448/unlim   -   root 500    
      >131074 ESP:   sha1   29b19e03 10448/unlim   -   root 500    

    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
  • set security ike gateway LAB1007 dead-peer-detection interval 10
    set security ike gateway LAB1007 dead-peer-detection threshold 3

    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.

    root@srx2> set cli timestamp        <------At this time, we power off the remote peer.
    Jun 12 20:43:57
    CLI timestamp set to: %b %d %T
    root@srx2> show security ike sa | match 
    Jun 12 20:44:09
    3748964 UP     b176e4e8878575ff  724de9b628717413  Main     
    root@srx2> show security ike sa | match    
    Jun 12 20:46:40                                                                <---- 3 minutes passed and still the tunnel is up.
    3748964 UP     b176e4e8878575ff  724de9b628717413  Main  

    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,

    root@srx2> show security ike sa | match    
    Jun 12 20:48:55

    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

    root@srx2# set security ike gateway LAB1007 dead-peer-detection ?  
    Possible completions:
      <[Enter]>            Execute this command
      always-send          Send probes periodically regardless of incoming and outgoing data traffic 
    + apply-groups         Groups from which to inherit configuration data
    + apply-groups-except  Don't inherit configuration data from these groups
      interval             The time between DPD probe messages  Default :10 (10..60 seconds)
      optimized            Send probes only when there is outgoing and no incoming data traffic - RFC3706 (Default mode)   <----
      probe-idle-tunnel    Send probes same as in optimized mode and also when there is no outgoing & incoming data traffic
      threshold            Maximum number of DPD retransmissions Default :5 (1..5)
      |                    Pipe through a command

    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

    5.5.  Implementation Suggestion
       Since the liveliness of a peer is only questionable when no traffic
       is exchanged, a viable implementation might begin by monitoring
       idleness.  Along these lines, a peer's liveliness is only important
       when there is outbound traffic to be sent.  To this end, an
       implementation can initiate a DPD exchange (i.e., send an R-U-THERE
       message) when there has been some period of idleness, followed by the
       desire to send outbound traffic.  Likewise, an entity can initiate a
       DPD exchange if it has sent outbound IPSec traffic, but not received
       any inbound IPSec packets in response.  A complete DPD exchange
       (i.e., transmission of R-U-THERE and receipt of corresponding R-U-
       THERE-ACK) will serve as proof of liveliness until the next idle
       Again, since DPD does not mandate any interval, this "idle period"
       (or "worry metric") is left as an implementation decision.  It is not
       a negotiated value.

    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.

    About: rtoodtoo

    Worked for more than 10 years as a Network/Support Engineer and also interested in Python, Linux, Security and SD-WAN // JNCIE-SEC #223 / RHCE / PCNSE

    3 thoughts on “Practical guide to IPsec DPD”

    You have a feedback?

    Discover more from

    Subscribe now to keep reading and get access to the full archive.

    Continue reading