600167 – ipsec requires a reload before connections are available

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 600167 - ipsec requires a reload before connections are available

Summary: ipsec requires a reload before connections are available

Keywords:
Status:	CLOSED CURRENTRELEASE
Alias:	None
Product:	Red Hat Enterprise Linux 6
Classification:	Red Hat
Component:	openswan
Sub Component:
Version:	6.0
Hardware:	All
OS:	Linux
Priority:	high
Severity:	medium
Target Milestone:	rc
Target Release:	---
Assignee:	Avesh Agarwal
QA Contact:	Aleš Mareček
Docs Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+	depends on / blocked

Reported:	2010-06-04 04:35 UTC by Josh Stone
Modified:	2010-11-10 21:18 UTC (History)
CC List:	2 users (show)
Fixed In Version:	openswan-2.6.24-6.el6
Doc Type:	Bug Fix
Doc Text:
Clone Of:
Clones:	1093785 (view as bug list)
Environment:
Last Closed:	2010-11-10 21:18:15 UTC
Target Upstream Version:
Embargoed:

Attachments	(Terms of Use)

Description Josh Stone 2010-06-04 04:35:59 UTC

Description of problem:
After a reboot, ipsec doesn't seem to load the configuration for my vpn.  I have to manually poke it to reload before I can connect to the vpn.


Version-Release number of selected component (if applicable):
openswan-2.6.24-3.el6.i686


How reproducible:
100%


Steps to Reproduce:
1. Reboot the system.
2. Attempt to connect to the vpn.
  
Actual results:

# ipsec auto --up rh-vpn
000 initiating all conns with alias='rh-vpn' 
021 no connection named "rh-vpn"
# ipsec setup reload
ipsec_setup: Stopping Openswan IPsec...
/usr/libexec/ipsec/addconn Non-fips mode set in /proc/sys/crypto/fips_enabled
ipsec_setup: Starting Openswan IPsec U2.6.24/K2.6.32-31.el6.i686...
ipsec_setup: /usr/libexec/ipsec/addconn Non-fips mode set in /proc/sys/crypto/fips_enabled
# ipsec auto --up rh-vpn
(proceeds to connect)


Expected results:
It should get the available configurations to begin with.  A "reload" implies that it did a "load" to begin with, but it doesn't seem so.

Additional info:
In /etc/ipsec.conf, I uncommented the line "include /etc/ipsec.d/*.conf" and I have my settings in /etc/ipsec.d/redhat.conf.  Same thing for secrets.

Comment 2 RHEL Program Management 2010-06-07 16:14:10 UTC

This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux major release.  Product Management has requested further
review of this request by Red Hat Engineering, for potential inclusion in a Red
Hat Enterprise Linux Major release.  This request is not yet committed for
inclusion.

Comment 3 Avesh Agarwal 2010-06-18 18:50:43 UTC

IPsec (Openswan) is not started by default. We must do "chkconfig ipsec on" if we want it to start at the boot time. I tried this locally, and it loads the config at startup. could you please try with the latest openswan-2.6.24-4?

Comment 4 Josh Stone 2010-06-21 18:25:59 UTC

I have:

$ rpm -q openswan
openswan-2.6.24-5.el6.i686
$ chkconfig --list ipsec
ipsec          	0:off	1:off	2:on	3:on	4:on	5:on	6:off

... and the problem persists.

Comment 5 Avesh Agarwal 2010-06-24 19:14:16 UTC

I am not able to reproduce it locally as when I reboot, the connection is always loaded. I would suggest you to enable "plutodebug=all" in your /etc/ipsec.conf, and then please send me the output of "ipsec barf" after reboot.

Comment 7 Avesh Agarwal 2010-06-24 21:49:45 UTC

I looked at the file, and it seems that "network" is not getting up and because of that ipsec (Openswan) can not configure its default route. Could you please check your machine why the network does not start before ipsec starts?

Comment 8 Avesh Agarwal 2010-06-24 22:00:01 UTC

Another thing I noticed that because of network is not starting, openswan is not able to resolve vpn-phx2.redhat.com, and because of that on reboot, the connection is not getting loaded.

Comment 9 Josh Stone 2010-06-24 22:17:59 UTC

(In reply to comment #7)
> check your machine why the network does not start before ipsec starts?    

AFAIK, the network service should be fine, but I don't use a wired connection on my laptop.  I even assigned eth0 to NetworkManager so I wouldn't get bootup complaints about missing eth0.

(In reply to comment #8)
> openswan is not able to resolve vpn-phx2.redhat.com

This is to be expected - there's no wired connection and thus no DNS available during boot.  Only once I login do I get connected to my wireless network.

> and because of that on reboot, the connection is not getting loaded.    

This doesn't seem like good behavior -- you never know what state the network may have during boot.  IMO, as long as the network is established by the time a vpn connection is actually attempted, it ought to work.

Comment 10 Avesh Agarwal 2010-06-25 15:30:40 UTC

(In reply to comment #9)
> (In reply to comment #7)
> > check your machine why the network does not start before ipsec starts?    
> 
> AFAIK, the network service should be fine, but I don't use a wired connection
> on my laptop.  I even assigned eth0 to NetworkManager so I wouldn't get bootup
> complaints about missing eth0.
> 
> (In reply to comment #8)
> > openswan is not able to resolve vpn-phx2.redhat.com
> 
> This is to be expected - there's no wired connection and thus no DNS available
> during boot.  Only once I login do I get connected to my wireless network.
> 
> > and because of that on reboot, the connection is not getting loaded.    
> 
> This doesn't seem like good behavior -- you never know what state the network
> may have during boot.  IMO, as long as the network is established by the time a
> vpn connection is actually attempted, it ought to work.    

I agree (well to some extent) with your point, and I am looking at it. The main reason, as I understand, not to function this way is that if network is not supposed to be up at the boot time (as in case of a client scenario, and wireless interface case), there does not seem to be any reason auto-starting Openswan (acting as a client) at the boot time.

Comment 12 Avesh Agarwal 2010-06-30 05:29:18 UTC

Fixed in openswan-2.6.24-6.el6

Comment 14 Josh Stone 2010-07-01 19:48:43 UTC

(In reply to comment #12)
> Fixed in openswan-2.6.24-6.el6    

Hi -- it does recognize the connection name now, but it still won't connect.  I get this message:

022 "rh-vpn": We cannot identify ourselves with either end of this connection.

And like before, reloading ipsec fixes it.

Comment 15 Avesh Agarwal 2010-07-01 19:56:11 UTC

Are you making sure that the network is up before doing "ipsec auto --up rh-vpn" ?

Could you please show me your "ipsec barf" output again, also your routing tables at the time of you issue the command ""ipsec auto --up rh-vpn"?. Also please write that what steps you are following?

Comment 16 Josh Stone 2010-07-01 20:21:28 UTC

1. Clean boot
2. Log in
3. Make sure wireless is connected
4. Open a terminal, sudo -s

# route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
192.168.0.0     0.0.0.0         255.255.255.0   U     2      0        0 wlan0
0.0.0.0         192.168.0.1     0.0.0.0         UG    0      0        0 wlan0
# ipsec auto --up rh-vpn
022 "rh-vpn": We cannot identify ourselves with either end of this connection.

Comment 21 Josh Stone 2010-07-01 21:02:31 UTC

So it seems that it is noticing the new routes, but is not able to make a fresh DNS query.  I wonder if you need res_init() to notice the changed resolv.conf?  There was a recent thread to this effect on fedora-devel:
http://lists.fedoraproject.org/pipermail/devel/2010-June/137685.html

Comment 22 Avesh Agarwal 2010-07-01 21:08:41 UTC

Thanks for your suggestion, I am looking at it. The one workaround I can suggest you to put 209.132.183.55 in your conf file, and then it should work even after the boot. Even this was not possible with the previous version. Because, right now it seems a different problem than the original issue. 

So, I am looking at the ipaddress-resolving-routine in Openswan. Because I have been simulating the same conditions locally, and it works fine. 

Thanks
Avesh

Comment 23 Avesh Agarwal 2010-07-01 21:16:09 UTC

This may be the issue, as Openswan also calls gethostbyname.  So I am looking deeper into it. But it does not seem to be reproducible on my RHEL6 VM running on F12 host.

Comment 24 Josh Stone 2010-07-01 21:39:20 UTC

(In reply to comment #23)
> But it does not seem to be reproducible on my RHEL6 VM running on F12 host.

How are you simulating the network down in the VM?  Do you have an empty /etc/resolv.conf when openswan starts?

Comment 25 Avesh Agarwal 2010-07-01 21:40:52 UTC

(In reply to comment #24)
> (In reply to comment #23)
> > But it does not seem to be reproducible on my RHEL6 VM running on F12 host.
> 
> How are you simulating the network down in the VM?  Do you have an empty
> /etc/resolv.conf when openswan starts?    

Yes.

Comment 26 Avesh Agarwal 2010-07-01 21:43:20 UTC

(In reply to comment #25)
> (In reply to comment #24)
> > (In reply to comment #23)
> > > But it does not seem to be reproducible on my RHEL6 VM running on F12 host.
> > 
> > How are you simulating the network down in the VM?  Do you have an empty
> > /etc/resolv.conf when openswan starts?    
> 
> Yes.    

My mistake, it is not empty. It has the default gateway as its entry in /etc/resolv.conf?

Comment 27 Josh Stone 2010-07-01 22:01:51 UTC

(In reply to comment #26)
> My mistake, it is not empty. It has the default gateway as its entry in
> /etc/resolv.conf?    

Right, I think the default for virt-manager has dnsmasq on the host which answers DNS for the guests.  So the gateway and DNS for the guest are the same.

Your case seems to leave the stale resolv.conf entries, so there's something for openswan to see which will later be valid.  In my case, NetworkManager clears resolv.conf out when it disconnects.

Comment 28 Avesh Agarwal 2010-07-02 13:52:22 UTC

From the bz, https://bugzilla.redhat.com/show_bug.cgi?id=442172

It seems to me that the suggestion is to use 

/etc/init.d/nscd condrestart
/usr/sbin/nscd -i hosts

instead of patching each application.

Comment 29 Josh Stone 2010-07-02 17:14:40 UTC

I gather that NM does that, and everyone else benefits automatically -- IF they have nscd.  IMO we can't rely on nscd, since is not Required or part of the standard install.  I will try it though to confirm if it fixes the problem...

Comment 32 releng-rhel@redhat.com 2010-11-10 21:18:15 UTC

Red Hat Enterprise Linux 6.0 is now available and should resolve
the problem described in this bug report. This report is therefore being closed
with a resolution of CURRENTRELEASE. You may reopen this bug report if the
solution does not work for you.

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