Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.

Bug 1105180

Summary: ipsec_auto --ready doesn't work properly
Product: Red Hat Enterprise Linux 7 Reporter: Aleš Mareček <amarecek>
Component: libreswanAssignee: Paul Wouters <pwouters>
Status: CLOSED CURRENTRELEASE QA Contact: BaseOS QE Security Team <qe-baseos-security>
Severity: medium Docs Contact:
Priority: unspecified    
Version: 7.0CC: jaster
Target Milestone: rc   
Target Release: ---   
Hardware: All   
OS: All   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: 1105179 Environment:
Last Closed: 2014-10-24 04:30:59 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: 1105179    
Bug Blocks:    

Description Aleš Mareček 2014-06-05 14:03:35 UTC 
+++ This bug was initially created as a clone of Bug #1105179 +++

Description of problem:
ipsec auto --up <connection> doesn't work properly when it's used with connection_name like: ipsec auto --ready MyConnection. ipsec auto --ready without any other parameter seems doesn't work also.


Version-Release number of selected component (if applicable):
openswan-2.6.32-27.4.el6_5
libreswan-3.8-5.el7

How reproducible:
Always

Steps to Reproduce:
1. Config files:
cat <<EOF >/etc/ipsec.conf
version 2.0

config setup
	crlcheckinterval="180"
	strictcrlpolicy=no
	protostack=netkey
	interfaces=%defaultroute
	plutodebug=all

conn connA
	connaddrfamily=ipv4
	phase2=esp
	ike=aes-md5
	phase2alg=aes-sha1
	authby=secret
	left=127.0.0.1
	right=127.0.0.1
	loopback=yes
	auto=add

conn connB
	connaddrfamily=ipv4
	phase2=esp
	ike=3des-md5;modp2048
	phase2alg=aes-sha1
	authby=secret
	left=127.0.0.1
	right=127.0.0.1
	loopback=yes
	auto=add

conn connC
	connaddrfamily=ipv4
	phase2=esp
	ike=3des-sha1
	phase2alg=3des-md5
	authby=secret
	left=127.0.0.1
	right=127.0.0.1
	loopback=yes
	auto=add

conn connD
	connaddrfamily=ipv4
	phase2=esp
	ike=aes-sha1;dh22
	phase2alg=aes-sha1;dh22
	authby=secret
	left=127.0.0.1
	right=127.0.0.1
	loopback=yes
	auto=add

conn connE
	connaddrfamily=ipv4
	phase2=esp
	ike=aes-sha1;dh23
	phase2alg=aes-sha1;dh23
	authby=secret
	left=127.0.0.1
	right=127.0.0.1
	loopback=yes
	auto=add

conn connF
	connaddrfamily=ipv4
	phase2=esp
	ike=aes-sha1;dh24
	phase2alg=aes-sha1;dh24
	authby=secret
	left=127.0.0.1
	right=127.0.0.1
	loopback=yes
	auto=add

EOF
echo ': PSK "RedHat"' >/etc/ipsec.secrets

2. service ipsec restart; ipsec auto --ready connF; echo ">>> 1st try <<<"; ipsec auto --up connF; ipsec auto --status | grep -q 'connF.*STATE_MAIN_I4.*ISAKMP SA established' || { sleep 3; echo ">>> 2nd try <<<"; ipsec auto --up connF; } ; service ipsec stop

3. service ipsec restart; ipsec auto --ready; echo ">>> 1st try <<<"; ipsec auto --up connF; ipsec auto --status | grep -q 'connF.*STATE_MAIN_I4.*ISAKMP SA established' || { sleep 3; echo ">>> 2nd try <<<"; ipsec auto --up connF; } ; service ipsec stop

Actual results:
2.
Redirecting to /bin/systemctl restart  ipsec.service
Usage:
	ipsec auto [--showonly] [--asynchronous] --up connectionname
	ipsec auto [--showonly] --{add|delete|replace|down} connectionname
	ipsec auto [--showonly] --{route|unroute} connectionname
	ipsec auto [--showonly] --{ready|status|rereadsecrets|rereadgroups}
        ipsec auto [--showonly] --{rereadcacerts|rereadaacerts}
        ipsec auto [--showonly] --{rereadacerts|rereadcrls|rereadall}
        ipsec auto [--showonly] [--utc] --{listpubkeys|listcerts}
        ipsec auto [--showonly] [--utc] --checkpubkeys
        ipsec auto [--showonly] [--utc] --{listcacerts|listaacerts}
        ipsec auto [--showonly] [--utc] --{listacerts|listgroups}
        ipsec auto [--showonly] [--utc] --{listcrls|listall}

	other options: [--config ipsecconfigfile] [--verbose] [--show]
>>> 1st try <<<
000 initiating all conns with alias='connF' 
021 no connection named "connF"
>>> 2nd try <<<
104 "connF" #1: STATE_MAIN_I1: initiate
003 "connF" #1: received Vendor ID payload [Dead Peer Detection]
003 "connF" #1: received Vendor ID payload [FRAGMENTATION]
106 "connF" #1: STATE_MAIN_I2: sent MI2, expecting MR2
108 "connF" #1: STATE_MAIN_I3: sent MI3, expecting MR3
003 "connF" #1: received Vendor ID payload [CAN-IKEv2]
004 "connF" #1: STATE_MAIN_I4: ISAKMP SA established {auth=OAKLEY_PRESHARED_KEY cipher=aes_128 prf=oakley_sha group=modp2048}
117 "connF" #3: STATE_QUICK_I1: initiate
004 "connF" #3: STATE_QUICK_I2: sent QI2, IPsec SA established tunnel mode {ESP=>0x351063fa <0x0cf36604 xfrm=AES_256-HMAC_SHA1 NATOA=none NATD=none DPD=none}
Redirecting to /bin/systemctl stop  ipsec.service

3.
Redirecting to /bin/systemctl restart  ipsec.service
>>> 1st try <<<
000 initiating all conns with alias='connF' 
021 no connection named "connF"
>>> 2nd try <<<
104 "connF" #1: STATE_MAIN_I1: initiate
003 "connF" #1: received Vendor ID payload [Dead Peer Detection]
003 "connF" #1: received Vendor ID payload [FRAGMENTATION]
106 "connF" #1: STATE_MAIN_I2: sent MI2, expecting MR2
108 "connF" #1: STATE_MAIN_I3: sent MI3, expecting MR3
003 "connF" #1: received Vendor ID payload [CAN-IKEv2]
004 "connF" #1: STATE_MAIN_I4: ISAKMP SA established {auth=OAKLEY_PRESHARED_KEY cipher=aes_128 prf=oakley_sha group=modp2048}
117 "connF" #3: STATE_QUICK_I1: initiate
004 "connF" #3: STATE_QUICK_I2: sent QI2, IPsec SA established tunnel mode {ESP=>0xdadb5fc1 <0x9dbc6297 xfrm=AES_256-HMAC_SHA1 NATOA=none NATD=none DPD=none}
Redirecting to /bin/systemctl stop  ipsec.service


Expected results:
"ipsec auto --ready <connection>" works


Additional info:
Is there any other way how to know that whole config has been parsed?
Comment 2 Paul Wouters 2014-06-05 15:38:39 UTC 
ipsec auto --ready does not take a connection name. This is a bug in the man page that states:

       ipsec auto { --status | --ready } connection

(ipsec auto --status also does not take a connection name)

It does state so later in the man page:

The --ready, --rereadsecrets, --rereadgroups, and  --statusoperations do not take a connection name.  

The displayed usage message is correct in this respect:

	ipsec auto [--showonly] --{ready|status|rereadsecrets|rereadgroups}


The startup of the IKE daemon does allow for that initial gap within the first 1-3 seconds. The pluto daemon starts. It performs setup and when it is ready to be configured it will launch "ipsec addconn --autoall" in a thread. Immediately after launching the thread, it will listen on the socket (eg issue an internal 'ipsec auto --ready' which is really 'ipsec whack --listen').

What your scripts do is to immediately try to --up a connection that the thread has not yet run --add on.

While we could add a pauze to wait for loading the connections, this causes an unwanted delay when people have thousands of connections loading. There is no reason to wait for the first connections that are loaded to not be available while other connections load.

The proper way to start a connection on boot is not your script, but to use auto=start (for connections you want to ipsec auto --up on boot) or auto=route (for connections you want to ipsec auto --route on boot)


I've just commited the fixes to the man page of auto. These will be in libreswan-3.9 (which will be rebased into RHEL 7.1)
Comment 3 Paul Wouters 2014-10-24 04:30:59 UTC 
This was already pushed into rhel 7 via 3.9