Hello Martin, Thank you for your reply. Just for clarification the current configuration I am testing is using IKEv1.
I tested again using reauth=no and after 4 days I once again had a single tunnel disappear for 44 minutes which would be in the right range for rekeying (keylife=1h, rekeymargin=9m). To further clarify the configuration it may be helpful to know that I am building 4 tunnels between 2 interfaces on one host to 2 interfaces on another host: h1 eth0 <--> h2 eth0 h1 eth0 <--> h2 eth1 h1 eth1 <--> h2 eth0 h1 eth1 <--> h2 eth1 Any thoughts/ideas would be much appreciated. Thanks James On 03/18/2013 03:22 PM, Martin Willi wrote: > Hi James, > >> It should be noted that I had tested the same setup with the >> configuration option 'reauth=no' previously for 5 days without such a >> situation appearing. I then removed this option and after 2 days of >> testing I had the problem described above. > > It is hard to say what ultimately lead to the second CHILD_SA, but that > reauthentication is involved is certainly possible. > > Reauthentication is actually a kludge in IKEv2, as it just reestablished > the IKE and all CHILD_SAs from scratch. There are situations that are > hard to handle, for example if one peer re-authenticates while to other > rekeys a CHILD_SA. Another problem arises if, for example, a trap policy > (auto=route) triggers while the remote end has closed the IKE_SA just > before recreating it during re-authentication. > > I usually recommend to set reauth=no, as it is just not required for > most setups to re-evaluate credentials. If it is in your setup, you > might consider having rekey/reauth times that always the same peer > initiates the reauthentication/rekeying. This certainly can help in > avoiding the issue you have seen. > > Regards > Martin > _______________________________________________ Dev mailing list Dev@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/dev
