[Openswan Users] openswan crashing kernel (long)

Wed May 13 17:20:32 EDT 2009

Hello list,

I'm having a problem with openswan-2.4.10 and above on systems running
FC5. Any attempt to upgrade from openswan-2.4.9 to any newer versions
causes a Oops, apparently in KLIPS module. Recently I tried to upgrade
to 2.4.14, due to CVE-2009-0790, and I had several crashes on three
different servers. On top of that, I could not get the tunnel to work. I
could ping the remote subnet, but any other protocol would not go
through, and eventually, one of the servers would crash. Here is the
scenario:

Server A with subnet 192.168.0.0/24 connected with Server B with subnet
192.168.2.0/24
Server A with subnet 192.168.0.0/24 connected with Server C with subnet
192.168.3.0/24

All servers running FC5, kernel 2.6.19-1.2293 or 2.6.20-1.2320 SMP (both
would crash) and KLIPS compiled as a module. Kernel's are patched with
NAT-T, layer7 and IMQ. Layer7 filtering is active, IMQ is not. All gets
stable when I fall back to kernel-2.6.19-1.2293 and openswan-2.4.9. With
kernel-2.6.20-1.2320 I had noticed some instability and eventual
crashes, even with openswan-2.4.9, but nothing near what happened when I
upgraded to 2.4.14.

Here is the ipsec.conf from Server A:

config setup
        klipsdebug=none
        plutodebug=none
        interfaces="ipsec0=eth1"
        nat_traversal=yes
        uniqueids=yes
        nhelpers=0

virtual_private=%v4:10.0.0.0/8,%v4:172.31.0.0/12,%v4:!192.168.0.0/24,%v4
:192.168.1.0/24,%v4:192.168.2.0/24,%v4:192.168.3.0/24

conn %default
        compress=yes
        disablearrivalcheck=no

conn Giardino-Casaretto
        keyingtries=0
        authby=rsasig
        left=x.x.x.181
        leftnexthop=x.x.x.1
        leftsubnet=192.168.0.0/24
        leftid=@combo.domain.com.br
        leftrsasigkey=...
        right=y.y.y.137
        rightnexthop=y.y.y.1
        rightsubnet=192.168.2.0/24
        rightrsasigkey=...
        rightid=@vpn1.domain.com.br
        auto=start

conn EngPizza-Casaretto
        keyingtries=0
        authby=rsasig
        left=x.x.x.181
        leftnexthop=x.x.x.1
        leftsubnet=192.168.0.0/24
        leftid=@combo.domain.com.br
        leftrsasigkey=...
        right=z.z.z.81
        rightnexthop=z.z.z.65
        rightsubnet=192.168.3.0/24
        rightrsasigkey=...
        rightid=@vpn2.domain.com.br
        auto=start

conn MR-Casaretto
        authby=rsasig
        rightcert=mr.pem
        rightid="..."
        auto=add
        also=l2tp-ipsec

conn RD1-Casaretto
        authby=rsasig
        rightcert=rd1.pem
        rightid="..."
        auto=add
        also=l2tp-ipsec

conn l2tp-ipsec
        pfs=no
        left=x.x.x.181
        leftcert=combo.pem
        leftrsasigkey=%cert
        leftprotoport=17/1701
        right=%any
        rightca=%same
        rightprotoport=17/1701
        rightrsasigkey=%cert
        rightsubnet=vhost:%no,%priv
        rekey=no

include /etc/ipsec.d/examples/no_oe.conf

and from Server B

config setup
        klipsdebug=none
        plutodebug=none
        interfaces="ipsec0=eth0"
        nat_traversal=yes
        uniqueids=yes
        nhelpers=0

virtual_private=%v4:10.0.0.0/8,%v4:172.31.0.0/12,%v4:192.168.0.0/24,%v4:
192.168.1.0/24,%v4:!192.168.2.0/24,%v4:192.168.3.0/24

conn %default
        compress=yes
        disablearrivalcheck=no

conn Giardino-Casaretto
        keyingtries=0
        authby=rsasig
        left=x.x.x.181
        leftnexthop=x.x.x.1
        leftsubnet=192.168.0.0/24
        leftid=@combo.domain.com.br
        leftrsasigkey=...
        right=y.y.y.137
        rightnexthop=y.y.y.1
        rightsubnet=192.168.2.0/24
        rightrsasigkey=...
        rightid=@vpn1.domain.com.br
        auto=start

include /etc/ipsec.d/examples/no_oe.conf

Server C ipsec.conf is pretty much the same as Server B.

As you can see I tried to set nhelpers=0, as I read somehwre that it
might help, but nothing changed. Since I could not be on the spot when
the crashes occurred, I could not get the complete output of the crash.
The best I could get is this Oops happening before the Server C hangs,
as follow:

vpn2 kernel: Code: 06 00 85 c0 75 17 31 f6 f6 43 04 10 75 05 f0 ff 03 89
de 8d 43 08 e8 13 15 1a 00 eb 27 8d 43 08 e8 09 15 1a 00 8b 3f 85 ff 74
17 <8b> 07 0f 18 00 90 8d 5f e4 8b 44 24 08 39 43 28 75 e8 e9 7b ff
vpn2 kernel: EIP: [<c047f962>] __d_lookup+0xc1/0xe4 SS:ESP 0068:ec08fdac
vpn2 kernel: Oops: 0000 [#6]
vpn2 kernel: SMP
vpn2 kernel: CPU:    1
vpn2 kernel: EIP:    0060:[<c047f962>]    Not tainted VLI
vpn2 kernel: EFLAGS: 00010206   (2.6.19-1.2293_nattsmp #1)
vpn2 kernel: EIP is at __d_lookup+0xc1/0xe4
vpn2 kernel: eax: c30830ac   ebx: ee1df088   ecx: 00000011   edx:
c18588cc
vpn2 kernel: esi: ee825b04   edi: 484e4547   ebp: ef2a48f8   esp:
eca78dac
vpn2 kernel: ds: 007b   es: 007b   ss: 0068
vpn2 kernel: Process bash (pid: 6227, ti=eca78000 task=ebca96b0
task.ti=eca78000)
vpn2 kernel: Stack: eca78e30 00000010 c30830ac ed551006 c30830ac
ee825b04 ed551006 eca78f08
vpn2 kernel:        c0476abb eca78e3c eca78e30 eca78f08 c19192c0
c30830ac ee825b04 ed551006
vpn2 kernel:        eca78f08 c0478aee 00000000 00000000 ed551016
00000000 00000001 00000000
vpn2 kernel: Call Trace:
vpn2 kernel:  [<c0476abb>] do_lookup+0x24/0x143
vpn2 kernel:  [<c0478aee>] __link_path_walk+0x8cc/0xd79
vpn2 kernel:  [<c0478ffa>] link_path_walk+0x5f/0xe8
vpn2 kernel:  [<c0479398>] do_path_lookup+0x1cf/0x222
vpn2 kernel:  [<c0479b5f>] __user_walk_fd+0x2f/0x40
vpn2 kernel:  [<c0473445>] vfs_stat_fd+0x19/0x40
vpn2 kernel:  [<c04734f9>] sys_stat64+0xf/0x23
vpn2 kernel:  [<c0403f85>] sysenter_past_esp+0x56/0x79
vpn2 kernel:  [<00178410>] 0x178410
vpn2 kernel:  =======================

I also have a picture (yes, a picture) that my client took from the
screen after the crash. Should I send it?

So, anyone has ever seen something like this before? I'm not sure it's
openswan fault, but I'm sure it's related to it somehow. I can try to
reproduce this on a test environment if necessary.

Thanks,

Giovani Moda