Bug 126907

Hello, Graham.  There were no config file changes between
2.4.21-15.EL and 2.4.21-15.0.2.EL.  Could you please explain
why you think a config change was applied?  Are you perhaps
building and/or reconfiguring your own kernels?

Just to clarify, the line "CONFIG_CRYPTO=y" was present in
config-x86-generic in both 2.4.21-15.EL and 2.4.21-15.0.2.EL.

That's correct, there were no config changes in this area.

In fact, the only changes made to IPSEC and/or CRYPTO were
minimal bug fixes and none of which resulted in added
or majorly changed functionality and all of which were done
in response to actual submitted bugs against the product.

Any bug fixes referred to by David in comment #3 were either
made prior to 2.4.21-15.EL or in Update 3 (which has not yet
been released).  Specifically, there were no IPSEC and/or
CRYPTO changes made between 2.4.21-15.EL and 2.4.21-15.0.2.EL.

A user on the users.org mailing list reported that on
their system, upgrading to the latest RHEL3 kernel broke a working
openswan setup.

In my case, I have spent two days trying to get openswan to work with
no success whatsoever. Posting a message on the openswan mailing list
in connection with one of the error messages got the following response:

>>ERROR: netlink response for Add SA comp.0.223.165 included errno 
>> 3: No such process
>
> There is a problem with that kernel, or with the combination of kernel
> and userland. If ipsec --version doesn't show non-matching klips errors,
> then there is another problem with that kernel.

Giving up on openswan (it's unreliable anyway) and moving to racoon,
the following errors are encountered:

Jun 29 03:23:24 gatekeeper racoon: INFO: main.c:174:main(): @(#)racoon
- IPsec-tools 0.2.3
Jun 29 03:23:24 gatekeeper racoon: INFO: main.c:175:main(): @(#)This
product linked OpenSSL 0.9.7a Feb 19 2003 (http://www.openssl.org/)
Jun 29 03:23:24 gatekeeper modprobe: modprobe: Can't locate module
ripemd160
Jun 29 03:23:24 gatekeeper modprobe: modprobe: Can't locate module cast128
Jun 29 03:23:24 gatekeeper modprobe: modprobe: Can't locate module lzs
Jun 29 03:23:24 gatekeeper modprobe: modprobe: Can't locate module lzjh
Jun 29 03:23:24 gatekeeper modprobe: modprobe: Can't locate module
ripemd160
Jun 29 03:23:24 gatekeeper modprobe: modprobe: Can't locate module cast128
Jun 29 03:23:24 gatekeeper modprobe: modprobe: Can't locate module lzs
Jun 29 03:23:24 gatekeeper modprobe: modprobe: Can't locate module lzjh
Jun 29 03:23:24 gatekeeper modprobe: modprobe: Can't locate module
ripemd160
Jun 29 03:23:24 gatekeeper modprobe: modprobe: Can't locate module cast128
Jun 29 03:23:24 gatekeeper modprobe: modprobe: Can't locate module lzs
Jun 29 03:23:24 gatekeeper modprobe: modprobe: Can't locate module lzjh

Racoon refuses to make an attempt to connect to the remote machine,
although it is not clear whether these are due to the kernel modules
being missing altogether, or whether there are config errors (Redhat's
racoon docs if followed to the letter do not produce a useable config).

Unfortunately the people who worked on both freeswan and racoon didn't
believe in plain english error messages, so whether the problems with
ipsec are in the kernel or due to it's incomprehensible config, it's
hard to tell.

Those module load messages are perfectly normal, the racoon program
is going through a list of crypto routines and asking the kernel
which ones it does support.  The way the kernel checks is by
trying to load a module of the appropriate name, and since Linux
lacks support for cast128, lzs, lzjh, or ripemd160 those modules
are not found and racoon is told that we don't support them.

This is a dup or another bogus bugzilla report, namely #113095

You've not provided your racoon config, nor the commands you ran,
nor the configuration at the other end of your IPSEC configuration,
therefore it is not possible to diagnose your problem much further.

ifcfg-ipsec0 looks like this:

DEVICE=ipsec0
TYPE=IPsec
ONBOOT=yes
IKE_METHOD=X509
IKE_CERTFILE=patricia-hostCert.pem
IKE_PEER_CERTFILE=chandler-hostCert.pem
#SRCGW=192.168.200.150
#DSTGW=196.30.143.209
SRCNET=192.168.200.0/24
DSTNET=109.61.173.189/32
DST=164.49.223.165

When the interface is started up, the following error is logged:

RTNETLINK answers: Network is unreachable

This is caused by this command:

ip route add to 109.61.173.189/32 via 164.49.223.165

The IP address 164.49.223.165 is 20 hops across the internet, so it
looks wrong from the start.

A tcpdump on the peer machine shows no attempts to connect to it, and
no error messages are logged by the host, even after hacking the
startup scripts to add -d to the racoon startup. The only stuff logged
is this:

Jun 29 04:28:37 gatekeeper racoon: INFO: isakmp.c:1387:isakmp_open():
192.168.200.150[500] used as isakmp port (fd=7)
Jun 29 04:28:37 gatekeeper racoon: INFO: isakmp.c:1387:isakmp_open():
196.30.143.210[500] used as isakmp port (fd=8)
Jun 29 04:28:37 gatekeeper racoon: INFO: isakmp.c:1387:isakmp_open():
127.0.0.1[500] used as isakmp port (fd=9)

None of which indicates anything about the tunnel, or problems setting
it up.

I'm reassigning this to owner of ipsec-tools.  -ernie

Did this configuration work before the kernel update?

After a continuous 48 hours of trying, no combination of either
ipsec-tools nor openswan will work correctly on RHEL3 with the latest
kernel applied.

Reports on the openswan list indicate that upgrading from the previous
kernel to the latest kernel breaks a working openswan config. Every
attempt to get openswan to work in my case has failed, and the
openswan lists say the kernel is broken (see previous comments).

Following the extremely limited instructions for ipsec-tools has not
yet yielded a successful config, or even an error message saying that
something is wrong, so it is not clear whether the problems I am
having with ipsec-tools are caused by a broken kernel, or a broken
config. The likelihood is of both.

Apart from ipsec-tools and freeswan (+ forks) what other ipsec
software is available for Linux and is known to work?

Dumping ipsec-tools again, and going back to openswan.

Ignoring the latest RPMs of openswan v2.1.2, I rebuilt RPMs myself of
openswan v2.1.4 - the latest source version. One gateway is kernel
2.4.21-15.EL, the second gateway is 2.4.21-15.0.2.EL.

This combination works, at last!

It would seem that upgrading from 2.4.21-15.EL to 2.4.21-15.0.2.EL
breaks openswan v2.1.2, but the problem can be fixed by upgrading
openswan to v2.1.4, which works with both the latest and second-latest
kernel.

The error seen above does seem like a potential configuration issue,
yes. As for openswan, we don't ship that, so we can't support it.

Without more information on exactly where ipsec-tools is failing, it's
really hard to conclusively say anything at this point.

The route error is covered in a different bug; marking as a duplicate.

*** This bug has been marked as a duplicate of 146169 ***