Slashdot Log In
VPN Solutions for Distributed Installations?
Posted by
Cliff
on Thu Apr 13, 2006 01:45 PM
from the viable-private-network-across-different-locales dept.
from the viable-private-network-across-different-locales dept.
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)"
This discussion has been archived.
No new comments can be posted.
VPN Solutions for Distributed Installations?
|
Log In/Create an Account
| Top
| 85 comments
| Search Discussion
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Yes. (Score:5, Informative)
(http://www.numbski.com/ | Last Journal: Thursday May 26 2005, @10:44PM)
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. (Score:5, Informative)
(http://www.sigsegv.cx/)
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 [sigsegv.cx]
- 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 ofCaveats:
- 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.Debian... and PPTP (Score:2)
(http://stalag99.net/ | Last Journal: Tuesday August 14, @12:20PM)
IPCOP Works Well (Score:2, Informative)
Tinc (Score:1)
(Last Journal: Saturday November 27 2004, @09:16PM)
Also for your NAT boxes, if you want to do it cost effectively, get some Linksys WRT54GL's and install OpenWRT. You can then run your VPN (openvpn or tinc) on those routers, which would make a much cleaner VPN network.
ssh could be good enough (Score:5, Informative)
If you need constant monitoring and interaction a real VPN may make more sense, but
one word... Hamachi (Score:1)
(http://www.psyberia.com/)
compartmentalize! (Score:2)
(http://www.shambala.net)
Try SSH (Score:1)
"Some sort of NAT box" (Score:3, Insightful)
Buy some small, even older, used, Netscreen firewalls for a few hundred each. If you do the preshared keys trick, and put them in aggressive mode, they'll all connect back to the central hub firewall, a Netscreen 10, or whatever model replaced it.
It just works, no dicking around with
OpenVPN rocks for this (Score:5, Informative)
(Last Journal: Tuesday December 31 2002, @08:24AM)
Quick breakdown of obvious options (Score:1, Interesting)
I use IPSec pretty extensively. If you're dealing with inter-Linux-server communications where each end has a static IP address, IPSec is hard to beat. It's simple and pretty easy.
PPTP is mainly a Microsoft thing. Not applicable here obviously.
"Everything else" breaks down into application-specific protocols for specific applications. This is what I would recommend. Go take a look at OpenVPN. When you don't know the remote IP address, it's a great way to go. You give it a static IP address (I use 10.2.0.0/16 for this) via OpenVPN, and you can log in quickly and easily. OpenVPN has a plethora of options which make it very useful for unknown remote networks. The most useful ones are its decent support for TCP/IP (so you set your colo'd server's OpenVPN to listen on TCP/IP port 80), and the ability to use arbitrary ports (TCP/IP isn't the best protocol for a VPN application; UDP is better - set it to port 53, and that'll get past most over-anal firewalls).
Have fun
ZyWalls (Score:2)
Easier (Score:3, Informative)
(http://www.weigel-mohamed.org/ | Last Journal: Sunday August 13 2006, @09:36PM)
On your client box, run a script that hits the web site (wget) and fetches the IP address. If that has changed, post the new IP address, and installation name.
Now you have the clients and the assigned IP addresses. You can then use SSH to build whatever infrastructure you need to the client box, securely. No need to worry about the brand of router used, etc. About the only problem is if the client uses a dialup on demand connection. To accomodate this, the "poll for IP" can be modified to always submit information, and ask if the connection should be retained.
If the connection should be retained, the remote operator can be notified.
I used this approach to securely administer remote Linux machines over direct connection and dialup for years. Now I find none of my users use dialup anymore (finally).
Ratboy
Groove (Score:2)
(http://www.cyberspaceengineers.org/)
OpenVPN (Score:3, Interesting)
(http://dimss.homeunix.org/)
We use Intel-based Linux server at our datacenter as VPN server. It runs several instances of OpenVPN on different UDP ports (OpenVPN can use TCP as well) for different customers. Endpoints are Asus WL-500g Deluxe routers with OpenWRT Linux and OpenVPN installed. Maximum throughput is 3Mbps with blowfish encryption and authentication (limited by 200 MHz CPU). These devices are small, silent, inexpensive and reliable enough. Endpoints are connected using various types of Internet access -- DSL, Cable, LAN, WiFi etc. Some customers have ~70 endpoints without problems.
If you insist on using Debian computers as VPN endpoints, do not use harddisks!!! They will die. Use IDE flash, for example. Use fanless CPU and PSU if possible.
Made in Japan - The Teriyaki Experience (Score:3, Interesting)
(http://www.viewtouch.com/ | Last Journal: Thursday September 29 2005, @12:09AM)
Hardware (Score:1)
This approch can even be taken to the open source "fanboys" Just download a firewall distro like smoothwall. Install on cheap whitebox.
Hardware is so much easier to maintain then maintaining each client and dealing with "some sort of NAT box"
m0n0 baby!!! (Score:1)
http://img.m0n0.ch/gallery/brandon_kahler/01_19_0
They run off of compact flash and the WRAP boards + case are ~$200. They will act as your NAT firewall behind the commodity broadband interface (dsl/cable) and have a great number of features, including a captive portal if you want to allow customers to use the wireless network.
pfsense is based on m0n0, but not meant for the embedded platforms
OpenVPN all the way! (Score:2)
Router-based (Cisco 800) (Score:4, Informative)
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 [cisco.com]) 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 [cisco.com]) 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.
Openvpn & hardware solution (Score:1)
(Last Journal: Saturday July 01 2006, @07:56AM)
i've run an openvpn solution between corporate LAN and datacenter, and it worked okay but i'll take a look at some dedicated hardware box for the next implementation. maybe netscreen or so.
why?
Well first off, when one doesnt yet have a linux router/fw available one has to buy that. this'll probably cost as much as a cheap netscreen box.
second, when running openvpn on a nondedicated box openvpn has to fight over resources with other services on that box. with a netscreen box this is not a problem.
vtun devices (Score:1)
(http://robmarkovic.com/ | Last Journal: Monday July 28 2003, @01:09AM)
FreeSwan (Score:1)