[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:
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.
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
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.
Main Index |
Thread Index |