Red Hat Bugzilla – Bug 112554
Racoon fails to rekey when one node is rebooted
Last modified: 2014-03-16 22:41:04 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4.1)
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
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
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
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.
/etc/racoon/racoon.conf is default one distributed with Fedora Core 1.
/etc/sysconfig/network-scripts/ifcfg-srva on server-b looks like:
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).
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.
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).