[Openswan Users] Transport mode on a home LAN

[Michael H. Warfield]

On Sat, 2010-11-20 at 14:16 -0500, Gaiseric Vandal wrote: 
> Doesn't linux support IPSec transport natively?  If all machines are on your
> home LAN, then you should not need to use OpenSWAN (a VPN solution) for
> this.  The shared secret  approach should be sufficient.

The Linux kernel supports IPSec natively and that's what we  refer to as
the Netkey transport aot KLIPS and MAST.  You still need a user space
IKE/IKE2 keying daemon unless you want to get into some really REALLY
groady work with "ip xfrm" that you really REALLY don't want to do.  You
would need this (using ip xfrm without pluto from Openswan) even with
(and then only with) the shared secret method but it's really ugly to
try and do even that much by hand and it's very poorly document (most of
the "ip" command is incredibly poorly documented).

Openswan is more than just IPSec.  It provides the user space keying
daemon do deal with keying handshake and setup and does all the ugly "ip
xfrm" work under the hood with Netkey.  Another alternative for that is
Racoon, a very BSD'ish IKE implementation which I wouldn't wish upon
anyone who is not really into the whole BSD mindset way of doing things,
but even Racoon doesn't get you away from needing to dumpster dive with
ip xfrm or setkey.  Both are available in many of repositories (Fedora,
RedHat, Debian, Ubuntu, etc) so you have your choice, but you really
need one or the other (you don't need both), especially if you are
asking the kind of question the OP asked.  Racoon comes in the
"ipsec-tools" package along with setkey, which provides an alternative
to "ip xfrm" that's a little better documented but still not for the
faint of heart.  My choice is OpenSWAN on Fedora using the native Linux
kernel Netkey layer.  I'm only using the IKE (pluto) portion of the
OpenSWAN package, since I don't need KLIPS to provide the IPSec
encapsulation / de-encapsulation.

> No, I have not actually done this myself with Linux-I have with Window
> 200x machines but I think the "design" principle applies.

Regards,
Mike

> -----Original Message-----
> From: users-bounces at openswan.org [mailto:users-bounces at openswan.org] On
> Behalf Of Jack Byer
> Sent: Saturday, November 20, 2010 11:34 AM
> To: users at openswan.org
> Subject: [Openswan Users] Transport mode on a home LAN
> 
> I have a home LAN with three machines: hydrogen (router), carbon (file
> server) and boron (main desktop). I'd like to force these machines to
> encrypt all traffic on the local network (192.168.1.0/24 and
> 2001:1938:155::/64). What is the best way to accomplish this? I tried
> setting up connections based on the linux-to-linux example but was
> unable to make this work. Should I use certificates instead or set up
> a local DNS server and put the keys in TXT records to use OE?
> _______________________________________________
> Users at openswan.org
> http://lists.openswan.org/mailman/listinfo/users
> Micropayments: https://flattr.com/thing/38387/IPsec-for-Linux-made-easy
> Building and Integrating Virtual Private Networks with Openswan: 
> http://www.amazon.com/gp/product/1904811256/104-3099591-2946327?n=283155
> 
> _______________________________________________
> Users at openswan.org
> http://lists.openswan.org/mailman/listinfo/users
> Micropayments: https://flattr.com/thing/38387/IPsec-for-Linux-made-easy
> Building and Integrating Virtual Private Networks with Openswan: 
> http://www.amazon.com/gp/product/1904811256/104-3099591-2946327?n=283155
> 

-- 
Michael H. Warfield (AI4NB) | (770) 985-6132 |  mhw at WittsEnd.com
   /\/\|=mhw=|\/\/          | (678) 463-0932 |  http://www.wittsend.com/mhw/
   NIC whois: MHW9          | An optimist believes we live in the best of all
 PGP Key: 0x674627FF        | possible worlds.  A pessimist is sure of it!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 482 bytes
Desc: This is a digitally signed message part
Url : http://lists.openswan.org/pipermail/users/attachments/20101120/7b4ffc33/attachment.bin