Bug 1283468

Summary: keyingtries=0 is broken - meaning it is interpreted as keyingtries=1
Product: Red Hat Enterprise Linux 7 Reporter: Paul Wouters <pwouters>
Component: libreswanAssignee: Paul Wouters <pwouters>
Status: CLOSED ERRATA QA Contact: Ondrej Moriš <omoris>
Severity: medium Docs Contact: Mirek Jahoda <mjahoda>
Priority: high    
Version: 7.2CC: jaster, ksrot, mkolaja, omoris, pvrabec, tmraz
Target Milestone: rcKeywords: ZStream
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard: Regression
Fixed In Version: Doc Type: Bug Fix
Doc Text:
In Libreswan 3.13, 3.14, and 3.15, the "keyingtries=0" option for the "ipsec whack" command did not work properly. Consequently, the pluto IKE daemon stopped trying to establish the tunnels that were not immediately established if "keyingtries=0" was used. With this update, pluto tries to establish the tunnel with "keyingtries=0" indefinitely.
Story Points: ---
Clone Of:
: 1289498 1386666 (view as bug list) Environment:
Last Closed: 2016-11-03 21:22:02 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 1386666    

Description Paul Wouters 2015-11-19 04:05:13 UTC
Bug was introduced upstream in 3.15 only.

Patch is in upstream git 3c8dc46d53e3e5004b88f30b5ec3d06d5337951c

Comment 2 Ondrej Moriš 2015-11-25 14:22:30 UTC
Adding a Regression keyword.

Comment 3 Ondrej Moriš 2015-11-25 14:25:23 UTC
It might be good to fix this either in 7.2.z or 7.3.0. It is not really FIPS-related but I might be quite important.

Comment 5 Paul Wouters 2015-11-25 16:18:26 UTC
note the effects are:

if during negotiation failure there is a temporary problem, it will not try to connect for more than one time.

If the connection is up, and the remote end sends a delete ( eg restats) the local end will not attempt to reconnect (but the remote end might)

Comment 7 Paul Wouters 2015-11-26 16:15:41 UTC
the default values is 0 (keep retrying forever)

Comment 8 Ondrej Moriš 2015-11-27 14:54:38 UTC
(In reply to Paul Wouters from comment #7)
> the default values is 0 (keep retrying forever)

Ah, that is correct (I was mistakenly looking into ipsec_pluto(8) where the default value is 3).

Comment 9 Paul Wouters 2015-11-27 15:36:37 UTC
Fixed ipsec_pluto man page upstream :)

Comment 16 errata-xmlrpc 2016-11-03 21:22:02 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHSA-2016-2603.html