Description
This article describes how to configure DPD on IPsec VPN.
Sometimes, due to routing issues or other network issues, the communication link between a FortiGate unit and a VPN peer or client may go down.
Packets could be lost if the connection is left to time out on its own. The FortiGate unit provides a mechanism called Dead Peer Detection (DPD), sometimes referred to as gateway detection or ping server, to prevent this situation and to re-establish IKE negotiations automatically before a connection times out: the active Phase 1 security associations are caught and renegotiated (rekeyed) before the Phase 1 encryption key expires.
The commands in this article will help to configure DPD (dead peer detection) on IPsec VPN.
Scope
FortiClient.
Solution
It is possible to configure DPD per phase1-interface as follows (default settings are shown):
config vpn ipsec phase1-interface
edit <Tunnel Name>
set dpd [disable | on-idle | on-demand]
set dpd-retryinterval 20
set dpd-retrycount 3
next
end
DPD:
Disable: Disable Dead Peer Detection.
On-idle: Trigger Dead Peer Detection when no IPsec traffic is received.
On-demand: Trigger Dead Peer Detection when no IPsec traffic is received AND FortiGate has been sending IPsec traffic. On-demand is the default setting.
DPD failure in the event log will look like the following:
DPD-RETRYINTERVAL:
How long is the interval in seconds after which a DPD will be attempted again.
DPD-RETRYCOUNT:
How often will the DPD be attempted.
With the default settings, DPD will be attempted every 20 seconds, 3 times. In total after one minute without DPD responses the tunnel will be turned down.
On GUI, Go to: VPN -> IPsec Tunnels -> Select the desired VPN tunnel to edit -> Edit tunnel -> Network -> Edit.
On a dial-up server, if a multitude of VPN connections is idle, the increased DPD exchange could negatively impact the performance/load of the IKE process.
For this reason, an option is available in the CLI to send DPD passively in a mode called 'on-demand'.
- When there is no traffic and the last DPD-ACK has been received, IKE will not send DPDs periodically.
IKE will only send out DPDs if there are outgoing packets to send but no inbound packets have since been received.
Crosscheck the DPD exchange with the diagnose tool on CLI:
diagnose debug console timestamp enable
diagnose debug application ike -1
diagnose debug enable
DPD with IKEv1 (RFC 3706):
- DPD is a negotiated feature.
- FOS always announces DPD VID – i.e. FortiOS always responds to DPD queries.
- R-U-THERE / R-U-THERE-ACK.
ike 3:testVPN:123123: sent IKE msg (R-U-THERE): 1.2.3.4:500->4.3.2.1:500, len=92, id=8357cf8e359f24b8/e7763893c7180208:2ab66f73...
ike 3:testVPN:123123: notify msg received: R-U-THERE-ACK
DPD with IKEv2 (RFC 5996):
- No explicit DPD mechanism. IKEv2 provides built-in support for Dead Peer Detection (DPD) and Network Address Translation-Traversal (NAT-T)
- INFORMATIONAL request with no data payload (equivalent to IKEv1 R-U-THERE).
- INFORMATIONAL_RESPONSE (equivalent to IKEv1 R-U-THERE-ACK).
2021-02-10 16:20:48.645409 ike 0:VPN-test:9: send IKEv2 DPD probe
2021-02-10 16:20:48.645478 ike 0:VPN-test:21: sending NOTIFY msg
2021-02-10 16:20:48.645543 ike 0:VPN-test:9:21: send informational
For further information, refer to the 'FortiGate/FortiOS Documentation' manual in the Fortinet Document Library.
Related articles:
Technical Tip: Explanation of the DPD effect on a dialup IPsec tunnel SA lifetime
Technical Tip: IKEv2 retransmission and DPD
