[Swan-dev] Set keyingtries to 1 for Opportunistic Encryption connections

Paul Wouters paul at nohats.ca
Mon Mar 9 01:50:57 UTC 2020

On Thu, 5 Mar 2020, D. Hugh Redelmeier wrote:

> | I meant "resolved by setting it to 1".
> I don't really understand the issues.

A failure shunt is installed after the first keyingtries= fails.
If a second keyingtries is started, it will want to install the
negotiationshunt. What does it mean when these two shunts are
different? It is unclear what we _should_ do.

The actual bug seems to be that sometimes, the second shunt comes
in without widening to the full IP address. I do not yet know how
or when this exactly happens. When it does, pluto installs a second
shunt because it is different from the first one (eg proto 0 vs proto 6)
then later on when a tunnel is installed, only one shunt is removed.

> If the shunts fail, except in special cases, and those cases are
> undocumented, we should
> - fix the shunts issue (hard, I assume), or

We should either fix the shunt issue, or think of removing shunts
completely. While shunts give us a little more fine-grained control
on what to do during negotiation, some of that is countered by the
XFRM larval state anyway, and additionally, there is a _lot_ of
complexity with shunts. That makes it tempting to remove.

> Here's an add-on to Paul's code [UNTESTED].
> Since it changes starterwhack, something I'm not an expert in, the code is
> particularly suspect.

I actually changed it in add_connection() so it is independent on
whether the parameters came in via whack or via ipsec.conf.

> It implements that last policy, I hope.
> If one were to delete one line, it would only change a defaulted
> keyingtries.

Which makes this harder to do because we currently merge in our defaults
via libipsecconf/whack interactions. By the time add_connection() is
called, what was an implicit default is no longer known.

It's not ideal :/


More information about the Swan-dev mailing list