Configurable IKE rekeying delay about strongswan

[Thermi]

Note it is not convenient to use {start,dpd,close}_action = trap to delay IKE SA renegotiation, as it is less reliable (in contrary with documentation!) than {start,dpd,close}_action

That is wrong. using "start" does not renegotiate the CHILD_SA if it is explicitely closed by any of the peers and none of the peers negotiate a new one.

[kouli]

That is wrong. using "start" does not renegotiate the CHILD_SA if it is explicitely closed by any of the peers and none of the peers negotiate a new one.

Fortunately not. I have tested it quite extensively before creating this feature request (strongSwan 5.9.1). Combination of {start,dpd,close}_action = start, or probably at least close_action = start, ensures immediate IKE SA and child SA renegotiation if the opposite peer closes child or even IKE SA cleanly (e.g. swanctl -t -{c|i} ... or clean strongSwan shutdown). And with keyingtries = 0, it repeats the renegotiation until it succeeds. Without this being true, I would have created a more important feature request :-)

I have been using {start,dpd,close}_action = trap exclusively for long time trusting the note in documentation. But if you have a device behind NAT and only want to make it remotely accessible via an IPsec tunnel, I believe {start,dpd,close}_action = start to be the only solution: such a device never sends a packet to the tunnel just on its own behalf (which would trigger the trap policy).

[Thermi]

Okay, sure, we can implement that. But it costs much more money to implement that than to just eat up the carrier charges, or optimize that first.