<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">Hi Tobias,</div><div class=""><br class=""></div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>Thank you for your reply.</div><br class=""><div><blockquote type="cite" class=""><div class="">On 14 Sep 2015, at 15:17, Tobias Brunner <<a href="mailto:tobias@strongswan.org" class="">tobias@strongswan.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class="">Hi,<br class=""><br class=""><blockquote type="cite" class="">Everything works perfectly until I notice that if the strongswan<br class="">client and server re-authenticate each other, this solution does not<br class="">work because the IKE_SA_ID will increase but the IKE_SA_ID in the<br class="">callback job is not updated and if the http request returns FALSE,<br class="">the plugin will kill the ipsec connection with IKE_SA_ID equals to 1,<br class="">which is the id of the first ipsec connection.<br class=""></blockquote><br class="">What exactly do you mean with IKE_SA_ID? Because the actual ike_sa_id_t<br class="">object that identifies an IKE_SA (get_id) is the combination of the two<br class="">SPIs and the IKE version. So this is not increased by 1 but actually<br class="">changes completely for each new IKE_SA. However, if you mean an<br class="">IKE_SA's unique ID (get_unique_id) then, yes, that value is increased by<br class="">1 for each new IKE_SA. I'd recommend you use the actual ike_sa_id_t<br class="">object to identify the IKE_SA because checkout() is faster than<br class="">checkout_by_id().<br class=""></div></blockquote><br class="">Sorry about the confusion, here I mean IKE_SA's unique ID, which increases by</div><div>one for each new IKE_SA. </div><div><br class=""></div><div>In this plugin I use </div><div><br class=""></div><div><i class=""><span class="Apple-tab-span" style="white-space:pre"> </span>charon->controller->terminate_ike(charon->controller, this->ike_sa_id, NULL, NULL, 0);</i></div><div><br class=""></div><div>to close the ipsec connection (where this->ike_sa_id is the IKE_SA's unique id) </div><div>if some condition value in this plugin is FALSE. </div><div><br class=""></div><div>This code runs in an infinite while loop in the callback job, so that the condition </div><div>value is continuously checked by the plugin between each (re-)authentication.</div><div> <br class=""><blockquote type="cite" class=""><div class=""><br class="">During a reauthentication the authorize() callback should be called<br class="">again for the new IKE_SA, so you could theoretically schedule a new job<br class="">for the new IKE_SA then. </div></blockquote><div><br class=""></div>Yes, I set a flag in the plugin so this callback job is created only in the first</div><div>authentication phase. But if I schedule a new job, the previous job is still </div><div>running, and as I mentioned, it is running in an infinite loop, so it will not </div><div>be stopped.</div><div><br class=""><blockquote type="cite" class=""><div class="">But if you are actually referring to rekeying<br class="">then you might have to implement the ike_rekey() callback to keep track<br class="">of the IKE_SA_ID of the SA, which probably requires you to organize your<br class="">plugin differently. For instance, only have a single job that regularly<br class="">goes through a collection of SAs to check, which you then can update so<br class="">only the currently active SAs are contained in that collection. Or</div></blockquote></div><div><blockquote type="cite" class=""><div class="">structure the data passed to the job in a way that allows the<br class="">ike_rekey()-listener to update the IKE_SA_ID used by the job when it<br class="">runs later on.</div></blockquote><div><br class=""></div><div>This is exactly how the plugin is organised. In the first authentication phase between </div><div>the client and the server, the callback job is created and it keeps running in the </div><div>background, and if the condition value changes, it will close the ipsec connection as </div><div>I mentioned before. In the re-authentication phase, the callback job is ignored.</div><div><br class=""></div>May I ask how to get this collection of SAs? I tried to use enumerator in the callback</div><div>job before the condition value check, then the compile fails.</div><div><br class=""></div><div>Meanwhile, I already have a structure of data as one of the inputs to the callback job.</div><div>So it could be even better if there is a way to get the IKE_SA_ID which is up.<br class=""><blockquote type="cite" class=""><div class=""><br class=""><blockquote type="cite" class="">In this case, I am curious if there is a way to destroy the callback<br class="">job created in the ipsec connection first authentication phase?<br class=""></blockquote><br class="">No, scheduled jobs currently can't be canceled in a generic way. But<br class="">lets say the first thing your job does is checking out the IKE_SA based<br class="">on the IKE_SA_ID, then you could just terminate the job (i.e. not<br class="">reschedule it again) if you don't find the IKE_SA anymore because it was<br class="">replaced. Or as mentioned above, you organize your plugin a bit<br class="">differently, e.g. if there were only a single job that checks all SAs<br class="">you want to track there would be no need to cancel it (at least while<br class="">there are still active IKE_SAs).<br class=""></div></blockquote><div><br class=""></div>Please give me some hint of how to track the active IKE_SAs in the callback job.</div><div>It is even better not to cancel and create the job again and again.</div><div><br class=""></div><div>Thank you very much for your time and best wishes!</div><div>Tao</div><div><br class=""><blockquote type="cite" class=""><div class=""><br class=""></div></blockquote><blockquote type="cite" class=""><div class="">Regards,<br class="">Tobias<br class=""></div></blockquote></div><br class=""></body></html>