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).
Regards, Tobias
