Hi Paul,
Originally the "roadwarrior" set up was that one end would never
initiate or rekey. This was done with auto=add and rekey=no, and
possibly also setting DPD to clear (and implicitly wait for the
other end to re-initiate). Somehow a way must be found again to stop
the listening end initiating even if it means adding a further
parameter. I think that the changes have introduced a significant
interop problem and makes my conn unreliable. I hardly use it but it
has been rekeying for days and I only noticed it because of the size
of the log file. In my case you can even argue it is rekeying to the
wrong IP as right is defined as %any so should not rekey to a
specific IP address. I am pretty certain changing the behaviour is
wrong as it can potentially break working setups (like mine). To
change the behaviour, really another parameter should be introduced
which defaults to allow the original behaviour.
There are other possibilities. If an auto=add conn was started with
and --auto up, it could default to rekeying until an auto
--down/replace is issued in which case the behaviour reverts. This
may mean tracking how each conn was started.
I *think* auto=start and --down should always rekey and the conn
would have to be replaced or deleted to permanently down it, but I
can see arguments both ways.
rekey=no should mean never rekey. Perhaps you could use that as the
main flag. If set to yes, always reinitiate if a conn has been
established, upped or started but never initiate if set to no. I am
not sure what behaviour to expect if a conn is then downed and
rekey=yes. I am open to arguments both ways.
Similarly if DPD is set to clear, it should never rekey.
Regards,
Nick
On 22/06/2017 19:57, Paul Wouters
wrote:
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
