[strongSwan] DPD and rekeying useless for road^w home warriors

[Tobias Brunner]

Hi Kajetan,

> How is it supposed to work in real life?

Maybe by force-sending NAT keepalives (IKE messages with a single byte 
as payload), which are usually only sent if a NAT is detected (and only 
by the client behind the NAT, and only if there was no outbound 
traffic).  However, since they are not answered, a firewall might still 
delete the state.  Also, many clients probably won't support this, and 
sending them from the server might not keep the state alive (again, the 
client won't send anything from behind the firewall as a response). 
I've no practical experience, so no idea how firewalls would actually 
behave.

An alternative would be to force-send DPDs (i.e. only consider if IKE 
traffic was exchanged and ignore any IPsec traffic that might have been 
received) and possibly with a lower interval.  That could be done from 
the client or the server I guess, but on the server, the number of 
retransmits might have to be increased to allow clients to roam around 
for a while without connectivity (not a problem if your clients are not 
mobile).

Note that strongSwan currently supports neither of these two options. 
So the only solution then is probably to delay initiating any exchanges 
from the server for a long time (i.e. use high DPD and rekey intervals), 
so clients are responsible for keeping the IKE_SAs alive.

A similar problem might occur if there was no ESP traffic for a while 
and that state was susequently closed, so traffic from the server would 
get dropped unless the client starts sending first.  The IKE daemon 
couldn't really do anything about that.

> For clients connecting over
> IPv4 I *think* this works fine because of active traffic being
> encapsulated in UDP 4500.

That's the case if a NAT is detected (fake or real) and it works the 
same for IPv6.

> Support for IPv6 UDP IPsec has been added only
> recently to Linux kernel and I'm not even sure if Windows or Mac OS
> clients can do this.

No idea if they do.  You could try forcing UDP encap on the server 
(fakes a NAT situation) to see how these clients react when connecting 
via IPv6.

> Also - why go with UDP at all? Pure ESP has lower
> overhead, doesn't it?

Yes, avoid UDP encap whenever possible.

> When I started developing the VPN solution, I came across the problem
> that clients (mostly Windows and Mac) sometimes loose connection
> (problems at ISP, at home WiFi, having the laptop sleep, etc), reconnect
> and demand the same IP address. This address is granted by Strongswan
> but it is impossible to install policies in Kernel as the old ones still
> exist.

Not sure if this is the same issue as the one in [1], but there was a 
fix for that in 5.9.2.  An alternative would be to enforce a uniqueness 
policy (only allows a single IKE_SA per client identity, though).

> I have given up on rekeying, timers are set to some absurd values
> ensuring that clients can work fine the whole day.

Yeah, some proprietary clients don't like it if the server initiates 
rekeyings (or they implement it incorrectly).

Regards,
Tobias

[1] https://wiki.strongswan.org/issues/3541