[Openswan Users] Openswan on RHEL3?

[Nels Lindquist]

Hi, all.

Due to problems with support and maintenance, we'd like to migrate a
couple of production RH9 Openswan 1.x gateways to CentOS 3 (a RHEL 3
rebuild).  The migration process is relatively easy because RHEL 3 was
based on RH9.  Upgrading to CentOS 4 would be a prohibitively complex
project due to time constraints right now.

In my testing environment, I built an Openswan RPM from the 2.4.5 source
(rpmbuild -ts) and installed it with the current stock kernel-2.4.21-40,
which of course requires running with the backported NETKEY setup rather
than KLIPS.  The testing we've done so far has been pretty
successful--interoperating with OpenSWAN 1.x and WinXP/L2TP is working
fine (with a caveat; see below)--but I'm worried by the references in
the archives to major problems with OpenSWAN on RHEL 3.  Paul has
mentioned several times that it isn't an optimal platform for OpenSWAN,
to say the least.

What sort of problems can we expect to encounter?  So far I've noticed a
couple of issues--"setkey -D" produces "Invalid extension type" for
transport-mode connections used by L2TP.  When interoperating with
OpenSWAN 1.09, connections initiated from the 1.x end fail:

Jun  1 10:43:51 rapier pluto[20888]: "maei-nelsnet" #30: ERROR:
netlink_get_spi for comp.0 at 68.149.3.195/65536/4293853184 failed with
errno 22: Invalid argument
Jun  1 10:43:51 rapier pluto[20888]: "maei-nelsnet" #30: responding to
Quick Mode {msgid:cd7a6e0f}
Jun  1 10:43:51 rapier pluto[20888]: "maei-nelsnet" #30: ERROR: netlink
response for Add SA comp.0 at 68.149.3.195 included errno 3: No such process
Jun  1 10:43:51 rapier pluto[20888]: | add_sa ipcomp failed
Jun  1 10:44:01 rapier pluto[20888]: "maei-nelsnet" #30: next payload
type of ISAKMP Hash Payload has an unknown value: 156
Jun  1 10:44:01 rapier pluto[20888]: "maei-nelsnet" #30: malformed
payload in packet
Jun  1 10:44:01 rapier pluto[20888]: "maei-nelsnet" #30: sending
notification PAYLOAD_MALFORMED to 66.225.146.217:500

As long as the connection is initiate from the OpenSWAN 2.x side,
everything appears to work properly.

Also, Routing/firewalling will be more complex because of the lack of
/dev/ipsec(n) and because the kernel version doesn't see both the ESP
packets and the unencrypted packets for marking/mangling purposes.

Assuming we can work around these issues, are there any dealbreakers
with this setup?

Any feedback would be most welcome, please. :-)

----
Nels Lindquist