This service will be undergoing maintenance at 20:00 UTC, 2017-04-03. It is expected to last about 30 minutes
Bug 112554 - Racoon fails to rekey when one node is rebooted
Racoon fails to rekey when one node is rebooted
Status: CLOSED UPSTREAM
Product: Fedora
Classification: Fedora
Component: ipsec-tools (Show other bugs)
1
All Linux
medium Severity medium
: ---
: ---
Assigned To: Bill Nottingham
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2003-12-22 15:33 EST by Aleksandar Milivojevic
Modified: 2014-03-16 22:41 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-02-04 16:55:10 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 Aleksandar Milivojevic 2003-12-22 15:33:26 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4.1)
Gecko/20031030

Description of problem:
I'm not sure if the bug is in ipsec-tools, kernel, or configuration
built by ifup-ipsec.  Or is it simply lack in my knowledge.

Anyhow.  I have set up IPsec in transport mode between two nodes. 
Let's call them server-a and server-b.  When I try to ping (or
connect) from one node to another for the very first time (setkey -D
reports no SAD entries on both machines), I'm getting an error message:

# ping 192.168.111.114
connect: Resource temporarily unavailable

When I rerun ping, everything is fine and smooth.  Shouldn't the first
packet be delayed for some (short?) period of time until IKE daemon
(racoon in this case) does its job of setting up keys and stuff?

OK, now second thing that doesn't work all that well.  If I reboot
server-b, setkey -D on server-a will report old SAD entries (as
expected, since server-a is not yet aware that server-b rebooted), and
setkey -D on server-b will report no SAD entries (as expected, it was
just rebooted).  Now, if I ping server-b from server-a, nothing
happens.  With tcpdump, I can see that server-a is sending (encrypted)
packets to server-b with old info (using old SPI numbers), and
server-b seems to be just discarding those packets.  No rekey attempt
is made until I try to ping server-a from server-b (I get error on
first attempt, and after that everything works fine, servers rekey and
everything).  Shouldn't server-a and server-b rekey automagically as
soon as there's some traffic going on (regardless of direction of the
traffic)?

As I said, I'm not sure if this is ipsec-tools (racoon) related,
kernel ralated, or is it just default configuration (ifup-ipsec)
problem.  I've intially submited this bug report under ipsec-tools.

Version-Release number of selected component (if applicable):
ipsec-tools-0.2.2-8, kernel-2.6.0-0.test11.1.13, initscripts-7.42.2-1

How reproducible:
Always

Steps to Reproduce:
1. Setup IPsec between two nodes in transport mode (maybe the same
thing happens in tunnel mode, haven't tried it out)
2. ping one node from another, first ping fails (ping exits with
error), than everything works fine
3. try rebooting one of the servers, and than ping it from another,
servers do not rekey until you try pinging from server that was rebooted

Actual Results:  1. Applications are returned errors before racoon did
its job.
2. After reboot of one node, packets sent from the other node end up
in /dev/null, until the rebooted node initiates some traffic.

Expected Results:  1. While racoon is doing its thing, packets should
be either discarded or delayed.
2. After reboot of one node, there should be a way for both nodes to
detect something changed and rekey regardless of direction of traffic.
 The way it is now, rebooted node might end up being unreachable for
long period of time.

Additional info:

ipsec-tools-0.2.2-8
kernel-2.6.0-0.test11.1.13
initscripts-7.42.2-1

/etc/racoon/racoon.conf is default one distributed with Fedora Core 1.

/etc/sysconfig/network-scripts/ifcfg-srva on server-b looks like:
ONBOOT=yes
TYPE=IPSEC
DST=1.2.3.4
IKE_CERTFILE=server-b

ifcfg-srvb on server-b is made the same way.

/etc/racoon/certs contain public/private keys for the local server
(either A or B) and public root CA certificate (so that racoon can
verify certificate sent by remote node).
Comment 1 Bill Nottingham 2005-02-04 16:55:10 EST
Cleaning up older bugs for no-longer supported releases. Sorry about
any lack of response.
 
This is probably an issue with either racoon or the kernel. I suspect
it would have to be solved upstream; it's not something we're going to
work on significantly in Fedora outside of upstream.
Comment 2 Aleksandar Milivojevic 2005-02-04 19:57:36 EST
No problem.  I was thinking about closing this myself too.  Haven't
played with IPSec for some time, and too much changed in kernel alone
for this bug report to be of any importance (unless I find time and
spare machines to test, which was not likely to happen anytime soon).

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