[ale] Why I Chose IPsec over OpenVPN (Was: Re: How to test your public internet connection for open ports)

[Michael H. Warfield]

On Fri, 2011-02-11 at 12:33 -0500, Michael B. Trausch wrote: 
> On Fri, 2011-02-11 at 12:09 -0500, David Tomaschik wrote:
> > Not to nitpick, but....
> > 
> > On Fri, Feb 11, 2011 at 11:55 AM, Michael B. Trausch <mike at trausch.us> wrote:
> > > I lied.  *this* is my last post on this thread.
> 
> David, David.  Making a liar out of me yet again.  ;-)
> 
> > >> * They usually have a stupid well published default password.  That
> > >> definitely needs to be changed.
> > >
> > > Only accessible on the LAN, unless explicitly enabled by the user on the
> > > WAN side.  If the workstations on the network are secure, this makes
> > > absolustely zero difference whatsoever.
> > >
> > Except for the tiny detail that DNS rebinding attacks
> > (http://en.wikipedia.org/wiki/DNS_rebinding) are comparatively hard to
> > defend against.  And DNS rebinding attacks have been a headache for
> > routers for a while, even those with 3rd party firmware like DD-WRT.
> > But I suspect that most COTS routers allow admin password setting
> > during the installation.  I've seen others that use the MAC address
> > (or a subset thereof) as the default password.

> You're right; I failed to consider that.  I'm not perfect!

You and me both.  I wasn't thinking about the rebinding attacks (which
is a very legitimate concern) but the related reflection attacks.

> +1 point for routers that are managed via HTTPS with proper certificates
> or via SSH, side-stepping this problem entirely... yet more proof that
> security encompasses far more than just what the firewall is doing (or
> not).

Very true.  But watch out for the ones with hard coded certificates (I'm
sure there are lots still out there).

> > > There is no reason to change the DHCP settings unless the user is an
> > > advanced user such as myself, utilizing multiple subnetworks in
> > > different ranges.  For example, I have three routed networks that are
> > > tied together using a virtual network built over top of the Internet,
> > > all in RFC 1918 space.  I'm phasing that out, however.  It's getting
> > > replaced with public IPv6 addresses and the use of IPsec to secure
> > > communications between those networks.  Two of those networks do that
> > > right now.  The third will happen in the next month.
> > 
> > I'm curious as to what you're doing with those 3 networks tied
> > together, if you don't mind sharing.

> Mostly to simplify management of secure data and connections for legacy
> applications that aren't easily secured.

> I've had awful luck with stunnel and adding SSL to services in an
> "aftermarket" fashion.  Some of these things need to be transported over
> the public Internet in order to be replicated or processed or whatever.
> Given that there is a lot of private data that is going over the
> networks (and also given that, for example, Samba is used and
> connections need to be allowed for it between sites) it's just easier to
> create an IP-in-IP tunnel and completely secure the link.  Then
> application-level encryption for things over the Internet isn't
> important.

> I still use SSH over the encrypted link, even though its redundant.
> Mostly because I don't want to be bothered with a telnetd that just
> listens on the private address, and the private addresses will be going
> away at some point, to be replaced with iptables rules that implement
> the required business-level policies.

User of SSH or stunnel and ssl as a true tunneled VPN is just a plain
performance headache because it runs over TCP and all it's bookkeeping
headaches and packet assembly and opportunistic windows and cruft.  Just
compare OpenVPN over UDP vs OpenVPN over TCP.  You really don't want to
run routed tunnels over TCP.

> > I'm also curious as to why you
> > chose IPSec as opposed to something like OpenVPN.  (I know there are
> > good reasons for both, just curious what yours are.)

> IPsec operates at a lower level than OpenVPN and requires less in the
> way of resources.  It's also relatively easy to use for
> network-to-network communication, and doesn't require a whole heck of a
> lot of setup.  (That's not to say it's completely painless; the first
> time or two someone sets up an IP-in-IP tunnel secured with IPsec it can
> be a bit daunting.)  The downside is that all of the routers that
> participate in bidirectional IPsec secured communication have to be
> configured to match each other's configurations, which implies (but does
> not require) that all the routers be under the administrative control of
> a single party or entity.

> OpenVPN has the advantage that you can hand out client certs, and have
> host-to-network interconnections with relative ease.  My understanding
> of OpenVPN is that it's more difficult to use it for routed
> interconnections between networks.  I haven't really tried it for that,
> though; I went with IPsec primarily because it is usable when all the
> systems are Linux systems on an IPv4 network, and can be run on the WAN
> side of a NAT appliance.  IPv6 mandates support for IPsec, as well, so
> the forward-migration path is pretty easy; the IP-in-IP tunneling can go
> away entirely, reducing the complexity of the interconnect while at the
> same time retaining the same level of security.

IPsec:
+ Performance (kernel level transport)
+ Interoperability (multivendor)
+ Platform support
+ Fully mesh capable
+ Opportunistic encryption (if you're into that)
+ Multiple tunnels handled by common processes
+ Incorporated into the Linux Kernel natively
+ FIPS compliant (if that's important)
- UDP mode with IPSec NAT-T but otherwise won't work over NAT
- IPv6 over IPv4 only supported with IKEv2, not IKEv1
- Some firewalls mangle protocol 50/51 handling (Checkpoint)
- Cannot do over TCP (Cisco is about the only one I know that does)
- Can be blocked at some sites (proto 50/51 and/or udp 500/4500)

OpenVPN:
- No easy full mesh.  PtP or server modes.
- Multiple PtP tunnels require unique ports.
- User space tunnels.  2 context switches per packet.
- Not compatible with IPsec gateways (Cisco, Juniper, etc).
- Does not appear to be FIPS compliant (nothing on their site).
+ Will do direct IPv6 over IPv4.
+ UDP (works over NAT) as a default base transort.
+ Can be run over a multitude of ports (including port 53/UDP stealth).
+ Much more difficult to block than IPsec.
+ Can do TCP (sucks).

Pick yer poison.

For anything other than the simplest of connections, IPsec is no more
complicated to set up than OpenVPN.  Like Michael T. said, it's that
first IPsec tunnel you set up that takes some effort.  After that, it's
pretty much a piece of cake.  RedHat / Fedora complicated that a bit
when they introduced NSS and FIPS compliance into the mix for IPsec.

For the record, I use both, each for different reasons.  I'm the author
of some of the code in Openswan for talking to Cisco ASA gateways with
XAUTH IPsec and I'm probably one of the few people left with the tunnel
broker scrips from the old Join project for running an IPv6 tunnel
broker service over OpenVPN.  So I have my feet in both worlds.

> 	--- Mike
> _______________________________________________
> Ale mailing list
> Ale at ale.org
> http://mail.ale.org/mailman/listinfo/ale
> See JOBS, ANNOUNCE and SCHOOLS lists at
> http://mail.ale.org/mailman/listinfo

-- 
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://mail.ale.org/pipermail/ale/attachments/20110211/2034dcd9/attachment.bin