[strongSwan] question about DPD

Tobias Brunner tobias at strongswan.org
Tue Jun 8 10:19:56 CEST 2021

Hi Harri,

> question about DPD in a road-warrior configuration: Is it
> sufficient for either side to answer DPD packets, or should
> both sides run their own DPD in parallel, independent from
> the DPD sent by their peer?

DPDs are INFORMATIONAL exchanges, so both peers will send a message in a 
single DPD exchange, doesn't really matter which peer initiates it. 
However, in road warrior setups with mobile clients it's usually better 
if the server doesn't send DPDs for a relatively long time as it might 
otherwise remove state when a client is asleep or roaming about for a 
while.  Keeping the state allows such clients to quickly restore 
connectivity via MOBIKE.

> Reason for asking is, I have the impression that some home
> office gateways keep track only of the outgoing traffic
> (laptop to VPN gateway) to keep their stateful firewall
> alive, ignoring incoming DPD traffic sent by the VPN gateway.

Again, DPDs are exchanges, so for any inbound INFORMATIONAL request 
there will be an outbound INFORMATIONAL response.

But DPDs are not really intended to keep firewall or NAT mappings alive, 
as they are usually sent only if no packet (IKE or ESP) has been 
_received_ from the peer for the configured DPD delay (which might also 
be longer that the lifetime of firewall/NAT mappings).

If a client is behind a NAT, there is a second mechanism that prevents 
NAT mappings from disappearing, NAT keepalives, which use the opposite 
trigger, i.e. they are sent if no other traffic (IKE or ESP) has been 
_sent_ to the peer.  However, for strongSwan, there is currently no 
option to force sending such keepalives if there is no NAT (e.g. to keep 
firewall states alive).  If there is a NAT, you might have to adjust the 
keepalive interval if the NAT mappings/firewall states disappear often 
(depends on the client if you can actually adjust that).


More information about the Users mailing list