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:
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)
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.
Please try the ipsec-tools at: http://people.redhat.com/notting/ipsec/ Does that help at all?
Actually, you *may* be better off trying the kernel at http://people.redhat.com/notting/ipsec/ rather than the ipsec-tools.
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...
Indeed, the notting.ipsec kernel seems to fix this problem. Can we get an ERRATA? Please? Or some other workaround and an explanation?
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.
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.)