On Thu, 22 Jun 2017, Nick Howitt wrote:
I've just noticed something similar. I have a conn with auto=add and rekey=no:
I looks like it has got its knickers in a twist and having either lost or deleted the conn, it is attempting to initiate one and retries every four seconds. I don't think it should ever do this with auto=add and rekey=no.
There is some understandable confusion about this. And yes this behaviour has changed recently. What does auto=add plus ipsec auto --up mean? This can either mean that the connection was loaded, and then the --up command placed the tunnel in "must always be up" mode (aka auto=start) And the reverse, when you have auto=start and you receive a DELETE, do you not try to bring the tunnel up (aka go into auto=add mode) or do you immediately try to bring it up again to honour auto=start ? And what if you have auto=start but the admin give a --down command? Should we move into auto=add or should we honour start and initiate immediately? I've argued on different sides of this argument. I'm always happy to hear what others think is best :) We had issues where people had auto=start, received a DELETE and their tunnel would never try to come back up again. So we changed that behaviour to immediately initiate. Now we have reports that we try too aggressively and it is causing lots of logging and failed IKE attempts. It is also making interoperability a litte more tricky because this can end up in both endpoints initiating against each other more often, because a replace/delete causes initiating on both ends now. Clearly we need some kind of back-off method for some of this. Avoiding interop issues is a little more tricky. And then its more confusing if you think about rekey. With auto=add and the connection --up'ed and rekey=no, if we deem that the same as auto=start, then what do we do at the end of the keylife. We used to let the connection die because rekey=no, but then now the delete causes a new initiate to happen, in effect causing the same effect as rekey=yes If anyone has any smart ideas, please let me know :) Paul _______________________________________________ Swan mailing list [email protected] https://lists.libreswan.org/mailman/listinfo/swan
