Hi Tobias, We agree with you that this delete may be for the CHILD_SA. We have tested a couple of times again and it looks like the redundant CHILD_SA are not getting created anymore. :) We would still want to understand that what happens if I want the reauth to happen [reauth=yes] each time for the IKE_SA. In such a case there is always a possibility that during the downtime of the IKE_SA, traffic matching the installed policies will trigger a new CHILD_SA to be created. By setting the reauth=no we are blocking this issue. Don't you think that this is some kind of limiting factor in the way we can exploit the facilities provided by charon? Please let us know your opinion on this. Thanks and Regards, Anurag Ghosh
________________________________ From: ext Tobias Brunner [mailto:tob...@strongswan.org] Sent: Fri 4/13/2012 12:42 PM To: Ghosh, Anurag (EXT-Aricent - IN) Cc: users@lists.strongswan.org; jyoti.si...@aricent.com; Agarwal, Nupur (EXT-Aricent - US); Dharwadkar, Sriram (NSN - IN/Bangalore) Subject: Re: Reporting Issue:Old CHILD_SA not getting cleared Hi Anurag, > We have added reauth=no to the ipsec.conf and retested our scenario > once. We could observe from the tcpdump on the node triggering the > traffic that even now an INFORMATIONAL message (with Next Payload: > Delete) is sent just before IKE_SA re-keying [behaviour is same as > was with reauth=yes ]. Without the logs it's hard to tell exactly, but the delete could be from rekeying the CHILD_SA. You've configured > conn RULE1~VPN1 > rekeymargin=100 > rekeyfuzz=100% > ... > ikelifetime=600s > keylife=300s > ... that is, the CHILD_SA will be rekeyed the second time about when the IKE_SA is rekeyed for the first time (the exact times for both is determined randomly, see [1]). Regards, Tobias [1] http://wiki.strongswan.org/projects/strongswan/wiki/ExpiryRekey _______________________________________________ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
