[strongSwan-dev] [PATCH] starter: cleanup SAs when deleting a connection
emeric.poupon at stormshield.eu
Tue Mar 10 16:22:32 CET 2015
>> Maybe we would need to flush the SP first if the last connection that uses it is being deleted?
>> What do you think?
>Right, the SP should probably be removed first (as is done in the
>The order of operations must be carefully checked. Probably first
>deleting connection (starter_stroke_del_conn), to avoid immediate
>renegotiation, then delete SPs (starter_stroke_unroute_conn), then
>asynchronously terminate connections.
I tried this way, but unfortunately the starter_stroke_unroute_conn call has no immediate effect since the route is still used by the established CHILD SA. Therefore I still get the issue described before.
I also tried to have a look at the "flush" method of the ike_sa_manager to see of the "delete" with no ack is performed: maybe we would need something similar in order to synchronously flush the connections that are no longer handled in the configuration file?
>The main problem when terminating connections is to terminate the right IKE_SAs.
>Identifying CHILD_SAs to delete is rather easy (their name is the same
>as the connection name), but that is not the case of IKE_SAs: several
>"connections" may have the same left/right pair, so share the same
>- the name of an IKE_SA used by a connection may be the name of
>another connection (the IKE_SA name is the name of the first
>connection that established an IKE negotiation between the same
>- if you find an IKE_SA named after the connection that you are
>deleting, you must be sure that it is not used by other CHILD SAs
>derived from another (not deleted) connection.
>That's why starter_stroke_terminate_conn then starter_stroke_purge_ike
>are called in the patch (the first one terminates CHILD_SAs of deleted
>connections, the second one terminates IKE_SAs with no CHILD_SA). But
>in the asyncrhonous deletion case, the IKE_SAs will not be deleted
>since deletion of CHILD_SAs is pending.
How would you implement that? I guess using a new stroke message?
BTW, configuration reloading is quite a common subject on the strongswan's mailing lists,
I am wondering if one of the official developers has already some ideas about this topic and things that may be done?
More information about the Dev