VPN Solutions for Distributed Installations?

merreborn asks: "I work for a very small software company (10 employees) that's developing a Point of Sale solution for a small retail chain (~20 stores in several states) on the other side of the country. We're going to be shipping Debian systems with our software installed to these locations -- all of which are connected to the Internet via consumer-grade DSL, and inevitably behind some sort of NAT box. Our office is similarly connected, and we've got a couple of dedicated, co-located servers off-site with static IPs. We'd like to be able to access these systems remotely for maintenance from the office -- what would that entail? Which VPN solutions are best suited to this situation these days (IPSec, PPTP, vtun, ssh, ssl/OpenVPN)? Are there any detailed, current books on the subject? (O'reilly's VPN book is 6 years old now)"

Comments

Re:Yes.

[arivanov]

If you are doing it yourself the choice is between OpenVPN and OpenVPN.

Advantages:

• Ease of setup. Once you have an SSL CA setup the OpenVPN part is a piece of cake
• Possibility to use multiple links, load balance, failover, hang yourself by any means necessary. See Caveats though...
• Possibility to use QoS and run VOIP on top with no worries. While IPSEC security is considerably better studied than OpenVPN (this does not mean it is better, it is just a devil we know), IPSEC has a major failing. In its most common VPN use which is tunnel mode it is utter piece of horrid shite as far as QoS is concerned. Shameless plug: you can lift off QoS setup for OpenVPN off my website
• Possibility to get hardware acceleration on the cheap. It is trivial to get OpenVPN to work with an SSL library which has via padlock support. A padlock capable motherboard is around 120$. This theoretically gives you 50Mbit hardware accelerated AES. Practically - see caveats
• Ease of debug and understanding. It provides you with the notion of interface. You can tcpdump it, collect stats, check its status, you name it. You do not get any of that with IPSEC.

What you need to keep in mind are a list of

Caveats:

• OpenVPN will copy from userland to kernel and back to perform its task. As a result it has a speed limit per client which cannot be worked around. It is a fundamental limitation and is around 5MBit per client (multiple clients bandwidth grows as a log of the number to a total of around 15-20MBit). For a distributed installation or road warriors this may prove to your advantage, because no single client can eat all the resources. There is always some resource to go around. If you want higher speeds on a single encrypted point to point link you are better off with IPSEC transport mode overlay of IP-in-IP or IPSEC overlay of PPTP.
• OpenVPN route mechanism has minimal error checks and will bugger up your routing table majestically of you decide to do something really fancy. If you want to run a large distributed infrastructure you have to run quagga and use OSPF or RIP for routing. Either works fine provided that you can do them and you use peer-to-peer mode of OpenVPN. This also allows you to interoperate nicely with any failover within your network and this is something you never get out of IPSEC.
• You cannot use the Server mode of OpenVPN along with routing protocols. Actually I think that there are some fixes in the Quagga CVS head that will allow this but I will advise against this. This is a mode for road warriors. If you want infrastructure you better set your tunnels properly as peer mode ones.

If you are doing it vs someone else, especially someone with an overgrown IT department full of certification waving droids you have to use IPSEC. I have had some bad experience with SWAN varieties and personally I would suggest using Racoon and the KAME stack. Anything else aside they have some good debugging and so far I have managed to make them interop versus every implementation I have tried.