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

Yes.

[numbski]

Next question? :D

Seriously, OpenVPN would do the trick, and I do it right now. The only thing that bugs me about OpenVPN is that you either have to set up a key signing authority, or use pre-shared keys. The key signing authority process is well documented, it's just that I've never actually been able to make it work. Pre-shared keys works just fine though. The protection isn't as good however.

Once I get key signed OpenVPN working then this solution is a no-brainer.

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.

ssh could be good enough

[georgewilliamherbert]

If you know what the remote IP addresses are going to be (consumer grade but fixed IP addresses at remote ends) then ssh would be an adequate solution by itself, and a lot simpler than most of the alternatives. With its ability to forward ports and X windows displays, it can handle pretty much anything.

If you need constant monitoring and interaction a real VPN may make more sense, but ... think carefully about how much complexity you add in the management layer here. Does that overall improve or degrade the total environment's reliability and managability?

OpenVPN rocks for this

[pavera]

We currently use openvpn for a remote management service that my company offers have been using it for over a year now, more than 50 customers up, works from behind nat, with dynamic IPs, through all sorts of nasty things, and as long as the internet is up, the VPN is up and we have connectivity. Ive used alot of different VPNs (openswan, cisco, PPTP) nothing comes close to the stability of openvpn tunnels, especially when dealing with adverse network conditions (NAT of any sort, multiple NATs, poor link quality, etc) even if the internet link is pretty spotty, openvpn does a very good job of automatically renegotiating the tunnels as soon as it has connectivity.

Made in Japan - The Teriyaki Experience

[viewtouch]

This Canadian customer of ours has about 80 restaurants and has fully deployed our Linux & X Window System POS solution in all of its restaurants all across Canada. HQ enjoys an open VPN link with each of them and all data from the restaurants, including credit/debit cards is remotely synchronized with the storage system at their Toronto HQ. The company's IT staff is actually just one person, Doug deLeeuw. The company is increasing its units by about 25% this year. When you have the kind of control that this company has you find something like that much easier to undertake and you're much more likely to succeed. I doubt that there's another restaurant organization in the world with this kind of advanced POS deployment, not to mention that one person did it all by himself. Perhaps in another five to ten years you'll be able to read about it in a book.

Router-based (Cisco 800)

[dago]

I guess that if you're asking this question, you don't have any experience with linux-based VPN. I also think that if you are have to do troubleshooting, the last thing you want to debug is your VPN.

For my part, I also started with linux-based VPN (openvpn, ipsec) for private use (3 sites), but then, I come to the conclusion it wasn't worth the effort & time spent. I switched to the Cisco SoHo routers (the 800 series) who are just working. I have automatic tunnels between all sites, and can to VPN connection directly to any of the sites, plus many other funny things (IPv6). All this with just simple configurations, mostly through the wizard (SDM) or by copy, adaptation & paste of sample configs.

Of course, these routers may be a little bit too much (of configuration or price) for you, so you may also want to try consumer-grade solutions (e.g. Linksys BEFSX41, Netgear FR114P, ...).

Disclaimer : I wish I could get a percentage of Cisco sales ;)

PS : oh, and port tunneling with SSH is, from my experience, an awful solution for VPN.