[strongSwan] question about DPD

Harald Dunkel harald.dunkel at aixigo.com
Tue Jun 8 17:03:50 CEST 2021

Hi Tobias,

On 6/8/21 10:19 AM, Tobias Brunner wrote:
> 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.

Looking at the Fritzbox web page I see

The FRITZ!Box checks all incoming and outgoing data packets and
automatically rejects unwanted data from the internet (Stateful
Packet Inspection). This way only data packets that are direct
replies to previous requests reach the home network.

I have read this as "If the DPD exchange wasn't initiated locally
by the laptop, stateful packet information cache is not renewed."

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

Maybe thats the point. Looking at the IPsec gateway's log file I
don't have the impression that Windows 10 on the peer sends DPD
packets at all. I will increase the dpddelay (90sec --> 600secs),
hoping that either Windows sends a DPD request first or that it is
reconnected on the fly via Mobike, as you suggested.


> 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).

I have several road warrior laptops with occasional DPD problems. They
don't answer DPD anymore, but create a new connection instead. Most of
them (if not all) use IPv6 and ESP, AFAICT. No NAT.


More information about the Users mailing list