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 1105179 - ipsec_auto --ready doesn't work properly
Summary: ipsec_auto --ready doesn't work properly
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: openswan
Version: 6.6
Hardware: All
OS: All
unspecified
medium
Target Milestone: rc
: ---
Assignee: Paul Wouters
QA Contact: Jaroslav Aster
URL:
Whiteboard:
Depends On:
Blocks: 1105180
TreeView+ depends on / blocked
 
Reported: 2014-06-05 14:02 UTC by Aleš Mareček
Modified: 2014-10-14 08:19 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
: 1105180 (view as bug list)
Environment:
Last Closed: 2014-10-14 08:19:36 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)
patch for ipsec auto man page and usage text (16.45 KB, patch)
2014-06-05 16:59 UTC, Paul Wouters
no flags Details | Diff


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2014:1588 0 normal SHIPPED_LIVE openswan bug fix and enhancement update 2014-10-14 01:39:53 UTC

Description Aleš Mareček 2014-06-05 14:02:50 UTC
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:42:42 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 shell scripts will call addconn to add connections. This will happen asynchronously in the background as it sometimes needs to start thousands of connections and the service starting cannot block on this operation. 

What your scripts do is to immediately try to --ready and --up a connection that has not been added to pluto yet by the backgrounded scripts.

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)

If you deem it important enough to update this man page entry for 6.6, please let me know. Otherwise, feel free to close this as not-a-bug

Comment 3 Aleš Mareček 2014-06-05 16:37:27 UTC
Hi Paul,
at first thank you for quick response!

I know about option "auto=start" but this is not a case. From some reason I would want to start my tunnel manually (then auto=add is proper option in config file).
Starting tunnel immediately after daemon start is unintentional but it's the same for the output of open/libreswan claiming it doesn't know the connection.
What I'm asking is how to know when deamon is ready to accept  requests from client (the whole config file parsed)?
We can live with "sleep <seconds>" but I'd rather have some check point that daemon is ready to go.

Anyway, there are (and I think "will be") errata for openswan in RHEL-6 in the future so the manual page should be fixed at least.

Comment 4 Paul Wouters 2014-06-05 16:59:40 UTC
Created attachment 902601 [details]
patch for ipsec auto man page and usage text

Patch to fix the usage of the --ready command to show it does not take an argument. It also removes other obsoleted options that were left in the man page related to "acerts" and "aacerts"

Comment 8 errata-xmlrpc 2014-10-14 08:19:36 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.

http://rhn.redhat.com/errata/RHBA-2014-1588.html


Note You need to log in before you can comment on or make changes to this bug.