[Openswan Users] Security of xl2tpd without KLIPS?

Aaron Gage ratcrow at gmail.com
Tue Dec 4 14:49:41 EST 2007


Thank you for the information, Paul.  I will check whether it would be
easier to acquire and build these versions of the kernel, openswan,
and xl2tpd or to update to Fedora 7 or 8 (8 has kernel 2.6.23, so that
could be a problem).

I have a couple of questions about your reply, so if you could bear with me:

> > * 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 [...]
>
> Should work, though you need openswan 2.4.10+ to be able to support OSX
> using rightprotoport=17/0 (instead of the old 17/%any causing problems)

Does XP work if I use rightprotoport=17/0 instead of 17/%any, and if
not, can I just define a second connection that is otherwise equal but
uses 17/%any for XP?

> You can mark all ESP packets, then have a rule to accept all marked packets,
> and append a rule that drops all udp port 1701 packets.

My iptables-fu is a little weak, so I have a security question: is it
possible for an attacker to mark the packets before they arrive at the
firewall so that they gain automatic acceptance?  Or are the markings
strictly internal to the kernel?

> Are you trying to hand out IP addresses via l2tp in the same subnet as
> where you already are? That will not work.

I am not sure I understand, so here is a better description of my
topology (hopefully this comes out okay).  My firewall/router/VPN
server has three NICs:

10.0.0.0/24  (internal network)
^
|
|
+=====> 172.16.1.0/24  (DMZ) <=====> 192.168.1.0/24 (WiFi access point)
|
|
v
Internet

At the moment, I am trying to VPN from WiFi hosts so none of this is
open to the world yet.  My XP roadwarrior gets 192.168.1.100 from the
WiFi access point, which it translates to 172.16.1.199 (the access
point's IP in the DMZ) which then gets masqueraded into 10.0.0.254
(the router's IP) on the internal network.

What I want to do is this: the XP roadwarrior negotiates for
IPSec/L2TP on the 172.16.1.0/24 interface, and when accepted, ESP
packets go through the DMZ.  The roadwarrior then gets an address in
10.0.0.224/28 (reserved in dhcpd and named).  Is there something about
this arrangement that won't work?

I'll start downloading the latest packages and see where I end up.
Thanks for the help!

--Aaron


More information about the Users mailing list