[Openswan Users] Security of xl2tpd without KLIPS?
Aaron Gage
gage.aaron at gmail.com
Sun Dec 2 16:33:52 EST 2007
Greetings all --
I have been trying to set up IPSec/L2TP on Fedora 5 (i.e. NETKEY in
kernel 2.6.20) for XP and OSX 10.4 roadwarriors that will probably be
behind NAT.
After working on this for a while, it looks like I am trying to do the
impossible. There are several alternatives, all of which seem to be
mutually exclusive:
* Using Fedora 5 as my router/firewall/VPN server, which has kernel
2.6.20 and NETKEY. Also using xl2tpd that ships with Fedora 5 so that
I don't need a RADIUS server and addresses are allocated on my
internal network automatically.
* Using NETKEY means leaving L2TP vulnerable if OpenSwan goes down (my
current status is very much like this poster's:
http://lists.openswan.org/pipermail/users/2004-December/003147.html).
I can't use the trick of routing ipsec0 to the internal network to let
xl2tpd listen to an internal address. I could get ipsec0 if I used
KLIPS.
* Using NAT-T for the roadwarriors. I expect to be using the
roadwarriors from behind cable modem or DSL routers while on travel.
* Using KLIPS with NAT-T is not recommended/possible with kernel
2.6.20 (http://lists.openswan.org/pipermail/users/2007-May/012486.html).
I'm not optimistic that if I did downgrade the kernel and apply all
of the patches that it would actually work the way I want; that
prevents auto-updates to my kernel later; and I have hardware support
(Via ACE) that is included in that kernel.
* pluto that ships with Fedora 5 crashes if I use:
rightprotoport=17/%any right=%any rightsubnet=vhost:%priv,%no
which means that OSX probably will not work (and if it did, I would
have to edit the registry to make XP work by adding
forceenccaps=yes).
I am first trying to set up IPSec/L2TP from XP to Fedora 5 to secure
my wireless. It's safer to leave L2TP open on that interface while I
experiment than on the real thing, since the access point has its own
NIC in the firewall and the access point has some minimal security
(MAC address filtering and WPA). Once that was working, I was gong to
extend it to the real hostile Internet.
At present, I can get the entire VPN to come up with this
configuration, but only if I set listen-addr= the external (in this
case, DMZ between the router and the access point) address in
xl2tpd.conf. I would rather have no VPN than have listen-addr= the
real outside address (I don't need this badly enough to compromise
security).
My question is this: what is the state of the art with respect to
IPSec/L2TP, NETKEY, kernel 2.6.20 or newer, NAT-T, not exposing L2TP
to the hostile interface, and getting the whole ball of wax to work
with XP and OSX 10.4 roadwarriors?
If there is simply no way to do all of this at once, please let me
know so I can stop trying. About the only thing I am not doing to
make this as hard as possible is to have the VPN server also behind
NAT...and if I want OSX to work, I may as well. I shouldn't mention
that the VPN server is also on a dynamic IP -- I was just going to
brazen that one out and hope that dyndns.org would help.
I can post my various config files if desired, but they are all based
on Jacco de Leeuw's very informative web pages. Also, it works, just
not the way I'd like (L2TP vulnerable, OSX might not work).
Since this is turning into a dissertation anyway, I'll add another question:
When I did have the VPN running, I could ssh to the VPN server
(10.0.0.254 on the internal network) and it would show the expected
remote host (10.0.0.224 as assigned by xl2tpd/pppd, and my XP box
showed this as its PPP address). I saw the expected ESP packets
between the VPN server and the "outside". However, when I hit another
machine (10.0.0.253) over the VPN, it showed that I had logged in from
the VPN server (10.0.0.254). I could not ping 10.0.0.224 from the
internal network, but XP could ping that address (since that was
effectively localhost). I could ping the "local ip" interface
(10.0.0.252) from the internal network, but I wouldn't expect that to
go anywhere. Is this the way things are supposed to route, or did I
get that one wrong? It seemed to work well enough for my purposes (I
don't need to connect to the roadwarrior from the internal network) ,
but I am curious.
Sorry for the long post.
--Aaron
More information about the Users
mailing list