[Openswan Users] L2TP/IPSEC response unencrypted(wasopenswan-2.6.24rc1 NATed MacOS Kernel crash)

Tue Oct 27 01:07:52 EDT 2009

Jivin Giovani Moda lays it down ...
> 
> > So my current concern with the last patch is that is may break netkey.
> 
> In fact it did. By setting protostak=netkey, I was unable to connect using NAT-T and openswan-2.6.24rc1 + your latest patch:
> 
> 01:27:20.985552 IP 10.1.1.10.4500 > 10.1.1.9.4500: NONESP-encap: isakmp: phase 1 I ident[E]
> 01:27:20.989607 IP 10.1.1.9.4500 > 10.1.1.10.4500: NONESP-encap: isakmp: phase 1 R ident[E]
> 01:27:20.993305 IP 10.1.1.10.4500 > 10.1.1.9.4500: NONESP-encap: isakmp: phase 2/others I oakley-quick[E]
> 01:27:21.028567 IP 10.1.1.9.4500 > 10.1.1.10.4500: NONESP-encap: isakmp: phase 2/others R oakley-quick[E]
> 01:27:21.051405 IP 10.1.1.10.4500 > 10.1.1.9.4500: NONESP-encap: isakmp: phase 2/others I oakley-quick[E]
> 01:27:21.053492 IP 10.1.1.10.4500 > 10.1.1.9.4500: UDP-encap: ESP(spi=0x71442200,seq=0x1), length 156
> 01:27:22.050637 IP 10.1.1.10.4500 > 10.1.1.9.4500: UDP-encap: ESP(spi=0x71442200,seq=0x2), length 156
> 01:27:23.079834 IP 10.1.1.9.1701 > 10.1.1.10.1701:  l2tp:[TLS](42/0)Ns=0,Nr=1 *MSGTYPE(SCCRP) *PROTO_VER(1.0) *FRAMING_CAP(AS) *BEARER_CAP() |...
> 01:27:23.080538 IP 10.1.1.9.1701 > 10.1.1.10.1701:  l2tp:[TLS](42/0)Ns=0,Nr=1 ZLB
> 01:27:23.080806 IP 10.1.1.10 > 10.1.1.9: ICMP 10.1.1.10 udp port 1701 unreachable, length 139
> 01:27:23.080827 IP 10.1.1.10 > 10.1.1.9: ICMP 10.1.1.10 udp port 1701 unreachable, length 48
> 01:27:24.049890 IP 10.1.1.10.4500 > 10.1.1.9.4500: UDP-encap: ESP(spi=0x71442200,seq=0x3), length 156
> 01:27:24.051864 IP 10.1.1.9.1701 > 10.1.1.10.1701:  l2tp:[TLS](42/0)Ns=0,Nr=1 ZLB
> 01:27:24.052402 IP 10.1.1.10 > 10.1.1.9: ICMP 10.1.1.10 udp port 1701 unreachable, length 48
> 01:27:24.081143 IP 10.1.1.9.1701 > 10.1.1.10.1701:  l2tp:[TLS](42/0)Ns=0,Nr=1 *MSGTYPE(SCCRP) *PROTO_VER(1.0) *FRAMING_CAP(AS) *BEARER_CAP() |...
> 01:27:24.081888 IP 10.1.1.10 > 10.1.1.9: ICMP 10.1.1.10 udp port 1701 unreachable, length 139
> 01:27:25.081161 IP 10.1.1.9.1701 > 10.1.1.10.1701:  l2tp:[TLS](42/0)Ns=0,Nr=1 *MSGTYPE(SCCRP) *PROTO_VER(1.0) *FRAMING_CAP(AS) *BEARER_CAP() |...
> 01:27:25.082610 IP 10.1.1.10 > 10.1.1.9: ICMP 10.1.1.10 udp port 1701 unreachable, length 139
> 01:27:25.191517 IP 10.1.1.10.4500 > 10.1.1.9.4500: isakmp-nat-keep-alive
> 01:27:26.081784 IP 10.1.1.9.1701 > 10.1.1.10.1701:  l2tp:[TLS](42/0)Ns=0,Nr=1 *MSGTYPE(SCCRP) *PROTO_VER(1.0) *FRAMING_CAP(AS) *BEARER_CAP() |...
> 01:27:26.082560 IP 10.1.1.10 > 10.1.1.9: ICMP 10.1.1.10 udp port 1701 unreachable, length 139
> 01:27:27.085507 IP 10.1.1.9.1701 > 10.1.1.10.1701:  l2tp:[TLS](42/0)Ns=0,Nr=1 *MSGTYPE(SCCRP) *PROTO_VER(1.0) *FRAMING_CAP(AS) *BEARER_CAP() |...
> 01:27:27.086378 IP 10.1.1.10 > 10.1.1.9: ICMP 10.1.1.10 udp port 1701 unreachable, length 139
> 01:27:28.056206 IP 10.1.1.10.4500 > 10.1.1.9.4500: UDP-encap: ESP(spi=0x71442200,seq=0x4), length 156
> 01:27:28.058190 IP 10.1.1.9.1701 > 10.1.1.10.1701:  l2tp:[TLS](42/0)Ns=0,Nr=1 ZLB
> 01:27:28.058767 IP 10.1.1.10 > 10.1.1.9: ICMP 10.1.1.10 udp port 1701 unreachable, length 48
> 
> So I unapplied the patch (only the last one), recompiled, and I was able to connect using netkey again. This was tested on Ubuntu 8.04.

Here is a patch to apply on top of the last one so that we only do this when
running klips.  I think it should fix it,  untested though.

> > I would also like to see multiple OSX behind a single NAT working,  but
> > thats another discussion ;-)
> 
> Now, that's just not for me. No OSX over here. Anyone with the time and resources to do it?

I can test it (couple of guys here with iphones),  it's just the changes
needed may not be so acceptable in general :-)

> > Hmm, do you get an oops ?  If so it can't hurt to post them,  might help
> > figure it out.  Which kernel version is CentOS ?
> 
> Every time. I'm attaching a few of them. I've only teste on on kernels 2.6.18.7.1-128.centos.plus and 2.6.18-164.el5, and both of them crashed. I recompiled 2.6.18.7.1-128.centos.plus with old-style NAT-T, since the new style won't work with kernels below 2.6.23, and on the few times I could get the ipsec module running without oopsing, openswan-2.6.24rc1 + your patches got KLIPS and NAT-T working on CentOS. I had previously tested with openswan-2.6.24rc1, netkey and NAT-T and it did work (thanks Paul), but as soon as I loaded ipsec.ko, the oopses where all over the place. They happened while connecting a XP client using NAT-T and also while injecting/removing ipsec module. With your patch, it's now down to the problem while injecting/removing the ipsec module. At least, no more oopses with NAT-T and KLIPS! :-)

This is probably due to "using and old NAT-T" patch.  If you can,  check
that the NAT-T patch you are using for your kernels looks like:

	openswan-2.6.24rc1/nat-t/net/ipv4/udp.c.os2_6.patch

The thing to check is the udp4_unregister_esp_rcvencap function.

You should be able to just replace the udp4_unregister_esp_rcvencap
definition if its different.

Harald Jenny has proposed a fix but I haven't had a chance to try the
combinations yet.

> Oh, and your patch broke netkey on CentOS too, so it's safe to assume that it needs to be called specifically when using KLIPS.

Figured it would,  apply the attached patch after the first.

> > I tend to run Linus kernels, beats me what could cause problems with Ubuntu
> > and NAT-T, but again,  and oops may help,
> 
> I'm attaching it also. You latest patch did not help with this particular Oops. The only way to get this information I'm attaching was to use kdump. Netconsole was unable to send the Oops to the remote machine.

Again,  probably the old - vs - new NAT-T patch problem.

Hope these help,

Cheers,
Davidm

-- 
David McCullough,  david_mccullough at securecomputing.com,  Ph:+61 734352815
McAfee - SnapGear  http://www.snapgear.com                http://www.uCdot.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: win-l2tp-klips.patch
Type: text/x-diff
Size: 719 bytes
Desc: not available
Url : http://lists.openswan.org/pipermail/users/attachments/20091027/ee15a3c0/attachment.bin 