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 192.168.18.2 
3592751 UP     5161c49b0129f92d  1b5656bbb3139ab5  Main           192.168.18.2    

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

Test 2

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 192.168.18.2      
3592751 UP     5161c49b0129f92d  1b5656bbb3139ab5  Main           192.168.18.2    

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

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

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 192.168.18.2 
Jun 12 20:44:09
3748964 UP     b176e4e8878575ff  724de9b628717413  Main           192.168.18.2    

root@srx2> show security ike sa | match 192.168.18.2    
Jun 12 20:46:40                                                                <---- 3 minutes passed and still the tunnel is up.
3748964 UP     b176e4e8878575ff  724de9b628717413  Main           192.168.18.2 

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 192.168.18.2    
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

[edit]
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
   period.

   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.