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.
[snip]
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.
Regards
Harri
