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

[Michael B. Trausch]

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!

+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).

> > 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.

> 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.

	--- Mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
Url : http://mail.ale.org/pipermail/ale/attachments/20110211/ce667bf2/attachment-0001.bin