Hi, > Everything works perfectly until I notice that if the strongswan > client and server re-authenticate each other, this solution does not > work because the IKE_SA_ID will increase but the IKE_SA_ID in the > callback job is not updated and if the http request returns FALSE, > the plugin will kill the ipsec connection with IKE_SA_ID equals to 1, > which is the id of the first ipsec connection.
What exactly do you mean with IKE_SA_ID? Because the actual ike_sa_id_t object that identifies an IKE_SA (get_id) is the combination of the two SPIs and the IKE version. So this is not increased by 1 but actually changes completely for each new IKE_SA. However, if you mean an IKE_SA's unique ID (get_unique_id) then, yes, that value is increased by 1 for each new IKE_SA. I'd recommend you use the actual ike_sa_id_t object to identify the IKE_SA because checkout() is faster than checkout_by_id(). During a reauthentication the authorize() callback should be called again for the new IKE_SA, so you could theoretically schedule a new job for the new IKE_SA then. But if you are actually referring to rekeying then you might have to implement the ike_rekey() callback to keep track of the IKE_SA_ID of the SA, which probably requires you to organize your plugin differently. For instance, only have a single job that regularly goes through a collection of SAs to check, which you then can update so only the currently active SAs are contained in that collection. Or structure the data passed to the job in a way that allows the ike_rekey()-listener to update the IKE_SA_ID used by the job when it runs later on. > In this case, I am curious if there is a way to destroy the callback > job created in the ipsec connection first authentication phase? No, scheduled jobs currently can't be canceled in a generic way. But lets say the first thing your job does is checking out the IKE_SA based on the IKE_SA_ID, then you could just terminate the job (i.e. not reschedule it again) if you don't find the IKE_SA anymore because it was replaced. Or as mentioned above, you organize your plugin a bit differently, e.g. if there were only a single job that checks all SAs you want to track there would be no need to cancel it (at least while there are still active IKE_SAs). Regards, Tobias _______________________________________________ Dev mailing list [email protected] https://lists.strongswan.org/mailman/listinfo/dev
