[Openswan Users] Openswan 2.4.0 + Linux 2.6.12 + Klips?

[Paul Wouters]

On Wed, 2 Nov 2005, Martin Bene wrote:

> Ok, I've now spent quite some hours compiling kernels and trying to get
> openswan 2.4.0 working with klips and a linux 2.6 kernel.
>
> (BTW, fixup for awk/"default" function was required on my gentoo box for
> openswan 2.4.0)

That patch should be in already. Perhaps you can try the latest 2.4.2drX
release?

> In all cases, nat-t patch is applied to the kernel and activated;
> 2.6.12.6 matches 2.6.12 results.
>
> Kernel 	 2.6.11  2.6.11.12  2.6.12
> Module SMP   LOCK        LOCK     ERR
> Module UP      OK          OK     ERR
> Builtin SMP  LOCK        LOCK    LOCK
> Buildin UP     OK          OK      OK

Thanks for the overview. We know there is a problem with SMP, and a general
problem with sk_alloc. This function changed between 2.6.11 and 2.6.12. There
are a few new defines that regular behaviour of the changed Linux kernel
networking code. These do NOT consider subversions of kernels (eg 2.6.11.X)

NET_26_12_SKALLOC - swapped sk_alloc paramters (changed in 2.6.12)
HAVE_SOCK_ZAPPED - cwuse SOCK_ZAPPED instead of sk->sk_zapped (changed in 2.6.12)
HAVE_SOCK_SECURITY - have skb->security or not (changed in 2.6.13)
HAVE_SKB_NF_DEBUG - have skb->nf_debug or not (changed in 2.6.13)

Worse, these versions are wrong for redhat based source kernel, since they applied
these changes before the linus kernel, and you will have to tweak your built
by either changing packaging/redhat/extra_2.6.11_1.1369_FC4.h or manually
editting linux/include/openswan/ipsec_kversion.h


> strace -f /usr/local/libexec/ipsec/klipsdebug --none
>
> open("/dev/urandom", O_RDONLY)          = 3
> read(3, ":\17t\340", 4)                 = 4
> close(3)                                = 0
> socket(PF_KEY, SOCK_RAW, 2)             = 3
> getpid()                                = 9960
> brk(0)                                  = 0x80013000
> brk(0x80034000)                         = 0x80034000
> write(3, "\2\20\0\0\t\0\0\0\1\0\0\0\350&\0\0\7\0\31\0\0\0\0\0\0\0"...,
> 72) = 72
> close(3
> 	 ^
> 	 system hangs.

Yes, there is a problem with the PFKEY socket interface. Probably there is
both a bug in init_module and in cleanup_module. (apart from the smp problem).
We have not yet figured out what changed to cause this behaviour. Another
test for this involves the even simpeler: modprobe ipsec ; rmmod ipsec
procedure, which also causes a crash in pfkey_cleanup()

> ERR:
> ====
> Kernel exception on sk_alloc, see previous mails
>
> System has a P4 w/ hyperthreading, so I'd normaly go for an SMP kernel;
> this doesn't seem to be an option at the moment? Given my prior
> experience with the stability of freeswan / openswan I find it very hard
> to believe that I'm NOT doing something incredibly stupid - I just can't
> figure out what it is I'm doing wrong. Or has everyone else on 2.6
> switched to the native ipsec implementation?

We find it hard to believe the Linux 2.6 kernel is doing such a major
overhaul of the kernel internals without any method for compatibility or
documentation for developers on how things have changed and how to rework
your code to comply to the new situation. We keep playing catch-up with
the 2.6 kernel since they started hacking it in 2.6.9.

> If so: how do you deal with firewalling, esp. how do you tell appart
> decapsulated packages that came in via VPN from packages that came in
> unencrypted?

Use the iptables MARK facility to mark encapsulated packets. The mark will
survive in the decapsulated packet.

> What I'd really like to know now:
>
> If you're using Kernel 2.6.x with klips
> * which linux kernel and
> * what version of openswan are you using
> * SMP or single processor kernel
> * klips module or patched into the kernel

linus kernels upto 2.6.12 on UP and inline will work. Anything else, as you
found out, is risky.

Paul
-- 

"Happiness is never grand"

	--- Mustapha Mond, World Controller (Brave New World)