Bug 147500 - IPsec tunnelling AH security association creation problem
IPsec tunnelling AH security association creation problem
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: kernel (Show other bugs)
4.0
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Bill Nottingham
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-02-08 11:44 EST by Yue Shi Lai
Modified: 2014-03-16 22:52 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-09-21 16:58:31 EDT
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 Yue Shi Lai 2005-02-08 11:44:28 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; rv:1.7.3) Gecko/20041020
Firefox/0.10.1

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):
ipsec-tools-0.3.3-2.1

How reproducible:
Always

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

ONBOOT=no
IKE_METHOD=X509
IKE_CERTFILE=some.pem
DSTGW=<the other host's IP>
SRCGW=<the other host's IP>
SRCNET=0.0.0.0/0
DST=<the other host's IP>
TYPE=IPSEC
ESP_PROTO=rijndael

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 11:52:04 EST
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 16:48:09 EST
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 15:25:19 EST
Please try the ipsec-tools at:

http://people.redhat.com/notting/ipsec/

Does that help at all?
Comment 4 Bill Nottingham 2005-03-11 17:12:46 EST
Actually, you *may* be better off trying the kernel at

http://people.redhat.com/notting/ipsec/

rather than the ipsec-tools.
Comment 5 Jefferson Ogata 2005-04-12 21:52:24 EDT
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
working.

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-12 21:56:18 EDT
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 01:32:27 EDT
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
kernel.

Please fix or provide workaround ASAP.
Comment 9 Bill Nottingham 2005-04-20 11:52:54 EDT
This will be fixed in RHEL 4 Update 1. There is a kernel in the beta channel

https://rhn.redhat.com/network/software/packages/details.pxt?pid=309164

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.