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
