[Openswan dev] openswan 2.1.0rc1 rpms

Axel Thimm Axel.Thimm at physik.fu-berlin.de
Mon Mar 8 13:34:07 CET 2004

On Sat, Mar 06, 2004 at 01:00:08AM +0100, Axel Thimm wrote:
> On Wed, Mar 03, 2004 at 01:27:24AM +0100, Axel Thimm wrote:
> > On Wed, Mar 03, 2004 at 01:13:11AM +0100, Paul Wouters wrote:
> > > On Wed, 3 Mar 2004, Axel Thimm wrote:
> > > 
> > > > Note: No kernel patches, so any feature tied to that (NAT-T) is not
> > > > there. Do you consider it worth while to patch up the FC1 kernel to
> > > > allow for NAT-T (e.g. the ATrpms patched kernels?), or is it wiser to
> > > > wait another month for FC2 and 2.6.x?
> > > 
> > > FC should have UDP_ENCAPS for nat-t. When openswan-2 adds the userland part,
> > > it will work without kernel recompiles.
> > 
> > Even FC1? I thought only RHEL3 and FC2 would do that w/o kernel
> > patching. If so, then the FC1 rpms should already support NAT-T. :)
> The FC1 kernels say
> NAT-Traversal: ESPINUDP(1) not supported by kernel -- NAT-T disabled
> So they probably do need the openswan-2.1.0rc1.kern.patch.gz. I
> checked that it applies cleanly on the current FC kernels, so I'll try
> to build kernels for FC over the WE.

OK, the builds for FC1 and RH9 are uploaded, but I saw that I had
ipsec statically linked into the kernel, so I will redo a modular
build :(

Just to be on the safe side, do the following settings make sense as
a _default_ for production sites ("production" as in "let's pretend I
haven't seen the rc1 suffix" ;)?


Anyway, the ipsec.o module shipped with this kernel should be
overridable by more recent openswan releases, so probably all I am
really after is UDP_ENCAPS, which should be part of
http://www.openswan.org/code/openswan-2.1.0rc1.kern.patch.gz, or not?

A user (Cced) testing the statically linked in openswan patch from
above reported that NAT-T still does not work:

ipsec__plutorun: 003 NAT-Traversal: ESPINUDP(1) not supported by kernel -- NAT-T disabled

How can this be? Do I need another patch?

> This kernel patch will provide its own ipsec.o, is it a problem if
> another ipsec.o is built out of the tree (against this kernel) and
> overrides this one?
> While this may seem completely redundant and senseless, it will make a
> packager's like simpler and happier, since I will be able to use the
> same src.rpm for patched and unpatched kernels ;)
Axel.Thimm at physik.fu-berlin.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.openswan.org/pipermail/dev/attachments/20040308/059d1fda/attachment.bin

More information about the Dev mailing list