This bug was initially created as a copy of Bug #1734058

I am copying this bug because it is a separate issue from the original bug.

ExecSum: use keyingtries=1 to work around shunt handling issues.


When using keyingtries=0 (the default) it means infinite rekeying tries. For Opportunistic on-demand this makes little sense, as nodes not supporting libreswan would be tried indefinitely. In larger networks this would add up quickly. An overriding value for Opportunistic to keyingtries=1 makes sense.

There is no point in retrying more than once. The first keyingtry already includes a number of retransmit attempts. The remote host is just really not ready. Upon failure, there is little point to retry unless the remote host changes. When the remote host changes, it will receive (negotiationshunt/failureshunt) cleartext traffic if the host was in the group private-or-clear and that remote host will immediately trigger Opportunistic if it can do it. If the host is in the private group, all traffic will be blocked, and if it recovers and has no traffic for the original host trying, the connection will remain down for the failureshunt lifetime. This part would be sped up by infinite keyingtries, but that requires a fix (see below)

With infinite keyingtries, the failureshunt becomes meaningless, as we are always in the negotiation phase, so the negotiationshunt is used. The codes does not handle this case properly and there is shunt interference. Since this only matters for private (not private-or-clear) perhaps no failureshunt should ever be installed when keyingtries=0 (and should be postponed for keyingtries >1 until the last failure)