Bug 600167 - ipsec requires a reload before connections are available
ipsec requires a reload before connections are available
Status: CLOSED CURRENTRELEASE
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: openswan (Show other bugs)
6.0
All Linux
high Severity medium
: rc
: ---
Assigned To: Avesh Agarwal
Aleš Mareček
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2010-06-04 00:35 EDT by Josh Stone
Modified: 2010-11-10 16:18 EST (History)
2 users (show)

See Also:
Fixed In Version: openswan-2.6.24-6.el6
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 1093785 (view as bug list)
Environment:
Last Closed: 2010-11-10 16:18:15 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Josh Stone 2010-06-04 00:35:59 EDT
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 Product and Program Management 2010-06-07 12:14:10 EDT
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 14:50:43 EDT
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 14:25:59 EDT
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 15:14:16 EDT
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 17:49:45 EDT
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 18:00:01 EDT
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 18:17:59 EDT
(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 11:30:40 EDT
(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 01:29:18 EDT
Fixed in openswan-2.6.24-6.el6
Comment 14 Josh Stone 2010-07-01 15:48:43 EDT
(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 15:56:11 EDT
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 16:21:28 EDT
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 17:02:31 EDT
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 17:08:41 EDT
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 17:16:09 EDT
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 17:39:20 EDT
(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 17:40:52 EDT
(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 17:43:20 EDT
(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 18:01:51 EDT
(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 09:52:22 EDT
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 13:14:40 EDT
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 16:18:15 EST
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.