Bug 126907 - kernel update broke openswan, warnings with ipsec-tools
kernel update broke openswan, warnings with ipsec-tools
Status: CLOSED DUPLICATE of bug 146169
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: ipsec-tools (Show other bugs)
3.0
i386 Linux
medium Severity high
: ---
: ---
Assigned To: Bill Nottingham
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2004-06-28 18:36 EDT by Graham Leggett
Modified: 2014-03-16 22:46 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-04-19 23:22:56 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 Graham Leggett 2004-06-28 18:36:00 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7) Gecko/20040623

Description of problem:
Recently Redhat released an update from kernel kernel-2.4.21-15.EL to
kernel-2.4.21-15.0.2.EL.

In this update, the crypto stuff was changed from being compiled as
modules to being compiled into the kernel itself, and it would seem
that some of the crypto modules have been left out altogether.

The latest version of openswan is broken - warnings about missing
modules are given on startup, the ipsecX interfaces no longer created
and none of the tunnels work.

In the case of ipsec-tools, warnings about missing modules are given.
As it's taken virtually half a day to work through the bugs in
Redhat's implementation of ipsec-tools and docs, it is not clear yet
whether ipsec-tools is also broken, will know more tomorrow.

The whole point behind RHEL3 is that there are no new features - just
bugfixes and security fixes. Major behavior changes such as this one
undermine confidence in the system, and the concept of Redhat Network.
Please be more careful the next time you push updates through that
break production systems.


Version-Release number of selected component (if applicable):
kernel-2.4.21-15.0.2.EL

How reproducible:
Always

Steps to Reproduce:
xxx

Additional info:
Comment 2 Ernie Petrides 2004-06-28 19:50:38 EDT
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.
Comment 3 David Miller 2004-06-28 20:12:40 EDT
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.
Comment 4 Ernie Petrides 2004-06-28 20:25:21 EDT
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.
Comment 5 Graham Leggett 2004-06-28 21:47:14 EDT
A user on the users@lists.openswan.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@164.49.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.
Comment 6 David Miller 2004-06-28 22:12:49 EDT
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.
Comment 7 Graham Leggett 2004-06-28 22:29:44 EDT
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.
Comment 8 Ernie Petrides 2004-06-28 23:29:21 EDT
I'm reassigning this to owner of ipsec-tools.  -ernie
Comment 9 Bill Nottingham 2004-06-29 01:19:28 EDT
Did this configuration work before the kernel update?
Comment 10 Graham Leggett 2004-06-29 06:20:16 EDT
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?
Comment 11 Graham Leggett 2004-06-29 09:55:41 EDT
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.
Comment 12 Bill Nottingham 2004-06-29 14:40:29 EDT
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.
Comment 14 Bill Nottingham 2005-04-19 23:22:56 EDT
The route error is covered in a different bug; marking as a duplicate.

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

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