All information is based on a series of tests and provided "AS IS" without warranty of any kind.
Contents- 1 Introduction
- 2 DPD on routers
- 3 DPD on ASA
- 4 DPD in IPSec VPN Client 4.8 - 5.0.04.0300
- 5 DPD in IPSec VPN Client 5.0.05.0290
- 6 Relevant Cisco VPN Client Parameters
- 7 Common Pitfalls
|
Introduction
Dead Peer Detection (DPD) is a method that allows detection of unreachable Internet Key Exchange (IKE) peers. DPD is described in the informational RFC 3706: "A Traffic-Based Method of Detecting Dead Internet Key Exchange (IKE) Peers" authored by G. Huang, S. Beaulieu, D. Rochefort.
This RFC describes DPD negotiation procedure and two new ISAKMP NOTIFY messages. Specifically, DPD is negotiated via an exchange of the DPD ISAKMP Vendor ID payload, which is sent in the ISAKMP MM messages 3 and 4 or ISAKMP AM messages 1 and 2. DPD Requests are sent as ISAKMP R-U-THERE messages and DPD Responses are sent as ISAKMP R-U-THERE-ACK messages.
The primary idea of DPD is as follows:
DPD addresses the shortcomings of IKE keepalives- and heartbeats- schemes by introducing a more reasonable logic governing message exchange. Essentially, keepalives and heartbeats mandate exchange of HELLOs at regular intervals. By contrast, with DPD, each peer's DPD state is largely independent of the other's. A peer is free to request proof of liveliness when it needs it - not at mandated intervals. This asynchronous property of DPD exchanges allows fewer messages to be sent, and this is how DPD achieves greater scalability.
It is important to note that the decision about when to initiate a DPD exchange is implementation specific. IKE peer should send an R-U-THERE query to its peer if it is interested in the liveliness of this peer. An implementation might even define the DPD messages to be at regular intervals following idle periods.
An implementation should retransmit R-U-THERE queries when it fails to receive an ACK. After some number of retransmitted messages, an implementation should assume its peer to be unreachable and delete IPSec and IKE SAs to the peer.
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.
Thus the RFC doesn't define specific DPD timers, retry intervals, retry counts or even algorithm to be used to initiate a DPD exchange. Almost everything is left to an implementation. DPD parameters are not negotiated by peers.
Thanks authors. We now have at least four (!) different implementations of DPD on Cisco gear.
DPD on routers
Cisco routers support two DPD types: On-demand DPD and Periodic DPD:
crypro isakmp keepalive <threshold> <retry-interval> {[on-demand] | periodic}
In case of on-demand DPD a router sends its R-U-THERE message to a peer if there is a traffic to send to the peer and the peer was idle for <threshold> seconds (i.e. there was no traffic from the peer for <threshold> seconds). On-demand DPD was introduced in IOS 12.2(8)T and the implementation has changed multiple times since then.
In case of periodic DPD a router sends its R-U-THERE messages at regular intervals. It doesn't take into consideration traffic coming from peer. This is the only Cisco platform that supports true periodic DPD. Periodic DPD was introduced in IOS 12.3(7)T and the implementation has changed multiple times since then.
Specifically, in the DDTS CSCin76641 (IOS 12.3(09.08)T) a decision was made to not send R-U-THERE request when the periodic DPD is configured and a traffic is received from the peer. Finally, it has reverted to the original behavior. See DDTS CSCsh12853 (12.4(13.11)T 12.4(11)T02 12.4(09)T05 12.4(06)T08) for details.
Periodic DPD can improve convergence in some scenarios.
DPD is disabled by default on Cisco routers. The default mode is "on-demand" if not specified.
If the peer doesn't respond with the R-U-THERE-ACK the router starts retransmitting R-U-THERE messages every <retry-interval> seconds with a maximum of five retransmissions. After that the peer is declared dead.
You cannot specify the number of retries on Cisco routers.
Also, it is possible to configure DPD in ISAKMP profiles. The caveat, however, is that there are no "periodic" and "on-demand" configuration options. So, the ISAKMP profile will inherit global setting. I.e., if you enable periodic DPD globally, all your ISAKMP profiles will operate in "periodic" DPD mode with profile-specific DPD timers.
crypto isakmp profile QQQ
keepalive <interval> retry <retry-interval>
Another caveat is that you cannot disable DPD completely. DPD is always negotiated, even if not configured or disabled in ISAKMP profile with "no keepalive". In this case the router will answer DPD requests with R-U-THERE-ACK, but will not initiate DPD requests with R-U-THERE ("one-way" mode).
In brief, on routers we have the following:
- true periodic DPD and on-demand DPD
- DPD cannot be completely disabled
- one-way mode is supported and is the default mode
- retry interval can be configured
- retry count cannot be configured and equals to five
DPD on ASA
ASA and PIX firewalls support "semi-periodic" DPD only. I.e. they send R-U-THERE message to a peer if the peer was idle for <threshold> seconds. ASA may have nothing to send to the peer, but DPD is still sent if the peer is idle. If the VPN session is comletely idle the R-U-THERE messages are sent every <threshold> seconds. If there is a traffic coming from the peer the R-U-THERE messages are not sent.
Unlike routers, you can completely disable DPD on ASA and it will not negotiate it with a peer ("disable" configuration option).
Also, you can configure "one-way" DPD mode on ASA. The ASA will respond to R-U-THERE messages, but will not initiate DPD exchange ("threshold infinite" configuration option).
isakmp keepalive {disable | threshold <threshold> retry <retry-interval> | threshold infinite}
If the peer doesn't respond with the R-U-THERE-ACK the ASA starts retransmitting R-U-THERE messages every <retry-interval> seconds with a maximum of three retransmissions. After that the peer is declared dead.
You cannot specify the number of retries on ASA.
DPD is enabled by default on ASA for both L2L and RA IPSec:
tunnel-group DefaultL2LGroup ipsec-attributes
isakmp keepalive threshold 10 retry 2
tunnel-group DefaultRAGroup ipsec-attributes
isakmp keepalive threshold 300 retry 2
In brief, on ASA we have the following:
- only "semi-periodic" DPD is supported
- DPD can be completely disabled
- one-way mode is supported
- bidirectional mode is the default one
- retry interval can be configured
- retry count cannot be configured and equals to three
DPD in IPSec VPN Client 4.8 - 5.0.04.0300
It seems that Cisco VPN Client sends its R-U-THERE message to a peer if it has sent traffic to the peer, but hasn't received response back within ten seconds. This basically means that R-U-THERE messages are not sent if the VPN session is completely idle or the peer responds in a timely manner.
If the peer doesn't respond with the R-U-THERE-ACK the VPN Client starts retransmitting R-U-THERE messages every five seconds until "Peer response timeout" is reached. After that the peer is declared dead.
The only parameter that can be configured on the Cisco VPN Client is "Peer response timeout".
You cannot disable DPD in Cisco VPN Client GUI or configuration files. DPD is always used if negotiated with a peer. I.e. to disable DPD disable it on the peer.
In brief, on Cisco VPN Client we have the following:
- very specific DPD algorithm is implemented
- DPD can be disabled if disabled on a peer
- most of DPD parameters cannot be configured
- retry interval equals to five seconds
- retry count is not used
- "peer response timeout", which equals to 90 seconds by default, is used instead
DPD in IPSec VPN Client 5.0.05.0290
It seems that this version of Cisco VPN Client uses different DPD algorithm, which is similar to ASA "semi-periodic" DPD. I.e. the VPN Client sends its R-U-THERE message to a peer if the peer was idle for approximately ten seconds. The VPN Client may have nothing to send to the peer, but DPD is still sent if the peer is idle. If the VPN session is comletely idle the R-U-THERE messages are sent every ten seconds. If there is a traffic coming from the peer the R-U-THERE messages are not sent.
In brief, in this version we have the following:
- in this version "semi-periodic" DPD is implemented
- DPD can be disabled if disabled on a peer
- most of DPD parameters cannot be configured
- retry interval equals to five seconds
- retry count is not used
- "peer response timeout", which equals to 90 seconds by default, is used instead
Relevant Cisco VPN Client Parameters
Cisco VPN Client Parameters
ForceKeepAlives
There are rumors that this parameter does nothing since 4.6. However, it is still compiled into the VPN Client code even in the latest version. Also, this parameter is mentioned in the DDTS CSCso05782. Testing reveals that DPD bahavior is not changed whether you set it to 0 or 1 (at least on Windows XP). Your mileage may vary.
PeerTimeout
This is the "Peer response timeout" configured in the Cisco VPN Client GUI (the number of seconds to wait before terminating a connection because the VPN central-site device on the other end of the tunnel is not responding).
UseLegacyIKEPort
This parameter is set to 0 by default since 4.8.01. This means that the source UDP port, which is used by ISAKMP, will be greater than 1023. In this case VPN Client need not stop Microsoft IPSec Service on GUI startup. If the parameter is set to 1, then the source UDP port will be 500 (or 4500 if NAT-T is used) and the Client will stop Microsoft IPSec Service on GUI startup.
ForceNatT
Causes the VPN Client to negotiate NAT-T, even if there is no NAT device involved in the connection attempt. This helps with some firewalls' disconnecting the VPN Client unexpectedly.
Also, please note that NAT-T has its own keepalive mechanism which is used by Cisco VPN Client by default.
Common Pitfalls
The most common problem with DPD is Windows or network firewall that blocks server to client communications over UDP.
As mentioned above the VPN Client doesn't send R-U-THERE requests if it receives traffic from a server. The UDP state is not updated on the firewall and expires quickly. This results in the server not being able to propagate its R-U-THERE request to the client and the tunnel is dropped.
In this case it is possible to use "ForceNatT" parameter to encapsulate data into UDP. Now data traffic, DPD and NAT-T keepalives will be sent over UDP and the above situation is unlikely.
Also, watch out the following bugs:
- CSCso05782 - Vista VPN client disconnect after few minutes - DPD enabled
- CSCsz22256 - ASA disconnects IPSec VPN client at P2 rekey with vlan mapping in grppol
