NetBSD-Users archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: Problems with pf, ipsec nat-t, l2tp

Thor Lancelot Simon wrote:
On Sat, Sep 05, 2009 at 01:18:25PM +0100, Matthias Scheler wrote:
On Fri, Sep 04, 2009 at 03:18:12PM -0700, Alex Barclay wrote:
I'm having some difficulty configuring IPSec NAT-T l2tp from a Mac
(client) to NetBSD (server).
If I remember correctly NetBSD does not support L2TP at the moment.
And I don't think you need L2TP anyway. Windows 2000 and XP (and newer
versions?) use L2TP over IPSec transport mode by default to support
some of Micosoft's weird legacy protocol and to allow network browsing.
In most cases IP routing should be good enough and you don't need L2TP.

You need L2TP if you want to use Apple's canned "VPN connection"
configuration tool (part of the Network preferences pane and also
one of the menu options in "Internet Connect" in any modern OS X).  If
you tell it to use IPsec, it uses L2TP to be more compatible with VPN
headend boxes configured for Windows XP clients.

I believe Microsoft can now use normal tunnel-mode IPsec with hybrid
authentication, to do most of what they wanted L2TP for.  But OS X can't.

The best thing to do is to use IPSecuritas as your configuration interface
for the OS X IPsec.  Then you don't have to cobble together a bunch of
shell scripts to sense the network state and adjust the configuration
files for ipsec, racoon, etc. automatically -- the IPSecuritas guys have
done that for you already -- but you also can use standard IPsec using
the built-in OS X implementation without having to use L2TP on the other

I was trying to use just the canned VPN connection is OS X. Really a case of reducing it to the lowest common denominator given I know I can get this config to work with both OS X and Windoze.

Now for my discoveries. It looks like my basic issues is with the UDP checksum on the re-assembled packet. When I add a judicious "if (uh->uh_dport == htons(1701)) uh->uh_sum = 0;" to udp_input in udp_usrreq.c then the packet correctly shows up in userspace and l2tpd gets to work - it doesn't work yet completely but I was more concerned as to whether it was OS X screwing up this inner checksum or NetBSD failing to correctly check it. Also, from what I can see this problem wouldn't be restricted to l2tp because it happened before that. I could be a problem with any IPSec transport mode connection using NAT-T.

Thanks for the IPSecuritas reference. It looks really really good! And of course it may work better because tunnel mode ESP has the complete packet rather than just the particular IP protocol headers . This may actually be a bug only on transport mode IPSec.

Another observation is that once we've decrypted the incoming packet we submit directly to the protocol where it would seem that there could be some usefulness in resubmitting the decrypted packet to pf. Right now if I give someone permission to connect on the VPN I give them permission for everything because I don't get that second bite with pf.

Fun times


Home | Main Index | Thread Index | Old Index