Bug 112554

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).