Bug 147500 - IPsec tunnelling AH security association creation problem
Summary: IPsec tunnelling AH security association creation problem
Alias: None
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: kernel
Version: 4.0
Hardware: i686
OS: Linux
Target Milestone: ---
: ---
Assignee: Bill Nottingham
QA Contact: Brian Brock
Depends On:
TreeView+ depends on / blocked
Reported: 2005-02-08 16:44 UTC by Yue Shi Lai
Modified: 2014-03-17 02:52 UTC (History)
3 users (show)

Clone Of:
Last Closed: 2005-09-21 20:58:31 UTC

Attachments (Terms of Use)

Description Yue Shi Lai 2005-02-08 16:44:28 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; rv:1.7.3) Gecko/20041020

Description of problem:
(Due to unclear description in Bug 145424, I am not sure whether this
is in fact a duplicate.)

After upgrading the router/VPN gateway to RHEL 4 Beta 2, IPsec
connection from RHEL 3 WS does work anymore.

Problem tracking sofar (a lengthy description for clarification):

On RHEL 3 WS, racoon will automatically manage key exchange and will
create security association for the IPsec security policies crated
using IKE managed bidirectional tunnels with ESP and AH (as in
ifup-ipsec). This can be seen by using /usr/sbin/setkey -D, and note
that especially two AH security associations are created for two
direction, each with hmac_sha1 or whatever you specified to be the AH
protocol. This looks like

<remote ip> <local ip>
        esp mode=tunnel spi=...
        E: rijndael-cbc  ...
        A: hmac-sha1   ...
<remote ip> <local ip>
        ah mode=tunnel spi=...
        A: hmac-sha1   ...
<local ip> <remote ip>
        esp mode=tunnel spi=...
        E: rijndael-cbc  ...
        A: hmac-sha1   ...
<local ip> <remote ip>
        ah mode=tunnel spi=...
        A: hmac-sha1   ...

However on RHEL 4 Beta 2, depending on each situation (no obvious
reaon), either you only get AH tunnel security association from local
to remote, but not in the other direction. Or you get an AH
association from remote to local, but "plain" without hmac-sha1.

Downgrading ipsec-tools to 0.2.5 as shipped in RHEL 3 will NOT solve
the problem. Change the kernel to 2.6.9-1.667 of FC3 does not change
the problem. If AH tunnelling is not used (IPsec with ESP only), the
problem does not appear.

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

How reproducible:

Steps to Reproduce:
1. Use the following ifcfg-ipsec0

DSTGW=<the other host's IP>
SRCGW=<the other host's IP>
DST=<the other host's IP>

on a RHEL 3 and RHEL 4 Beta 2 host.

2. issue /sbin/ifup ipsec0 on both hosts
3. watch the traffic using ethereal and the security association
created using setkey -D

Actual Results:  The result is that network only works in one
direction (i.e. ICMP will travel to the RHEL 4 Beta 2 host, but
nothing will go to the RHEL 3 host (a ping will in fact fail by
"connect: Resource temporarily unavailable")

Expected Results:  The security association created by racoon should
be symmetric (i.e. not just one AH tunnel or one AH tunnel without any
hash algorithm associated). Bidirectional network traffic should work.
For example, ICMP should be able to travel back.

Additional info:

Comment 1 Yue Shi Lai 2005-02-08 16:52:04 UTC
Clarification to

: a ping will in fact fail by
: "connect: Resource temporarily unavailable"

The ping is from RHEL 4 Beta 2 to RHEL 3, and it fails repeatedly
(i.e. still after about 20 pings with 1 second interval, and not
because of the initial ISAKMP negotiation)

Comment 2 Yue Shi Lai 2005-02-08 21:48:09 UTC
The hassless AH created looks like this:

        ah mode=tunnel spi=0(0x00000000) reqid=0(0x00000000)
        seq=0x00000000 replay=0 flags=0x00000000 state=larval

Note that it has SPI=0 and is essnetially empty.

Comment 3 Bill Nottingham 2005-03-04 20:25:19 UTC
Please try the ipsec-tools at:


Does that help at all?

Comment 4 Bill Nottingham 2005-03-11 22:12:46 UTC
Actually, you *may* be better off trying the kernel at


rather than the ipsec-tools.

Comment 5 Jefferson Ogata 2005-04-13 01:52:24 UTC
I am seeing the same problem with a tunnel on RHEL 4.

On the initiating side (A), racoon creates SAs for A->B/esp, B->A/esp, and
B->A/ah. The A->B/ah is never created, even though the log claims that it is,
with a line like:

INFO: IPsec-SA established: AH/Tunnel A.A.A.A->B.B.B.B spi=229899015(0xdb3fb07)

setkey -D shows this SA on B, but not on A.

On the other side, racoon creates all 4 SAs properly. The SPI of the fourth
SA--the one missing on the A side--matches the SPI logged on A but not added.

If I create the fourth, missing SA by hand using setkey on A, the tunnel starts

This is with the current kernel from Red Hat for RHEL 4 (2.6.9-5.0.3.EL).

I will test with the notting.ipsec kernel...

Comment 6 Jefferson Ogata 2005-04-13 01:56:18 UTC
Indeed, the notting.ipsec kernel seems to fix this problem.

Can we get an ERRATA? Please? Or some other workaround and an explanation?

Comment 8 Jefferson Ogata 2005-04-20 05:32:27 UTC
Okay, a new kernel just came out and now I'm stuck with an insecure kernel until
you guys fix this. Am I the only person using ipsec tunneling on RHEL 4? Well, I
guess there can't be many of us, actually, since it doesn't work in the stock

Please fix or provide workaround ASAP.

Comment 9 Bill Nottingham 2005-04-20 15:52:54 UTC
This will be fixed in RHEL 4 Update 1. There is a kernel in the beta channel


that has this fix (and I believe has the security fixes that were released as well.)

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