Bug 124034 - Dynamically restarted IPSec connections are broken
Summary: Dynamically restarted IPSec connections are broken
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: ipsec-tools   
(Show other bugs)
Version: 3.0
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Bill Nottingham
QA Contact:
URL: http://www.kame.net/racoon/racoon-ml/...
Whiteboard:
Keywords:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2004-05-23 02:11 UTC by Yue Shi Lai
Modified: 2014-03-17 02:45 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-03-11 22:57:22 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

Description Yue Shi Lai 2004-05-23 02:11:03 UTC
From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; X11; Linux i686) Opera 
7.50  [en]

Description of problem:
Due to the limitation of the SIGHUP handling in racoon, restarted 
connection to a KAME IPSec server are broken.

Analysis: During the ifup/ifdown based restart, only a SIGHUP is sent 
to racoon to reread the configuration. However, the URL cited above 
indicates that the SIGHUP in fact result in racoon flushing 
everything, including the current negotiation. Therefore, ifdown/ifup 
restart results in a broken IPSec connection.

Suggestion to fix:

Use

killall /usr/sbin/racoon
while pidof -x /usr/sbin/racoon > /dev/null 2>&1; do sleep 1; done
/usr/sbin/racoon

instead of

killall -HUP /usr/sbin/racoon

Version-Release number of selected component (if applicable):
0.2.5-0.4

How reproducible:
Always

Steps to Reproduce:
1. Configure a tunnelling IPSec connection.
2. Test it with ping.
3. Use ifdown to stop the IPSec network device, then ifup it.
4. Test it again with ping.
    

Actual Results:  The first ping is successful, while the second 
(after restart) does not work (TCP/UDP networking now does not work 
either).

Expected Results:  After restart, the IPSec device should work as 
before. Therefore, ping, TCP, UDP should all work.

Additional info:

IPSec configuration:

Client's ifcfg-ipsec0:

ONBOOT=no
IKE_METHOD=X509
IKE_CERTFILE=client.pem
DSTGW=<server IP>
SRCGW=<server IP>
DSTNET=0.0.0.0/0
DST=<server IP>
TYPE=IPSEC

VPN server's configuration:

The racoon configuration is essentially a xxx.xxx.xxx.xxx.conf made 
by RHEL's ifup-ipsec, with the phase 1 block changed to "remote 
anonymous", renamed into anonymous.conf, included in racoon.conf just 
like what ifup-ipsec does. Then I used the following directives in 
setkey:

spdadd 0.0.0.0/0 <client IP> any -P out ipsec
esp/tunnel/<server IP>-<client IP>/require
ah/tunnel/<server IP>-<client IP>/require;

spdadd <client IP> 0.0.0.0/0 any -P in ipsec
esp/tunnel/<client IP>-<server IP>/require
ah/tunnel/<client IP>-<server IP>/require;

Comment 1 Yue Shi Lai 2005-02-08 17:05:29 UTC
The /tmp/.racoon is further causing trouble. One might want to use:

killall /usr/sbin/racoon
while pidof -x /usr/sbin/racoon > /dev/null 2>&1; do sleep 1; done
/bin/rm -f /tmp/.racoon
/usr/sbin/racoon

Comment 2 Bill Nottingham 2005-03-11 22:57:22 UTC
See 148950 for your second issue.

As for the first, as stated, fixing this requires some more upstream
work in racoon; I don't think we'll change this for older releases at
this point.


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