Low Cost VPN Solutions?

whschwartz asks: "I'm looking for a low cost solution for allowing myself and a few others the ability to share a server at one of our locations. One thought was using SSH tunnels to establish secure connections, forwarding any ports needed by our apps. We'd want to be able to map network drives, control the server with something like PC Anywhere or VNC with the possibility of running apps that have remote data on the server. I use the Cisco VPN solution for work, but that's not in our price range and is probably overkill. Are there any other options I should be looking at other than using SSH port forwarding?"

Re:OpenVPN

[the_maddman]

I second OpenVPN. Way easier to setup then FreeSWAN, and less overhead. You do have to setup the server per machine that wants to connect, but it works on my linux and windows boxes.

There are problems with tunneling ppp over SSH, since that's packing a TCP stream inside another TCP stream and can screw up the packet counters, and seriously, OpenVPN is easier to setup.

CyberGuard SG530

[brian0x00FF]

I use the CyberGuard SG530 [cyberguard.info] for my personal VPN needs. It's a box about the size of your average 8-port switch, it runs a version of embedded linux and come default with PoPToP for PPTP v2 and FreeSwan for IPSEC. It has a web based config and if fairly painless to set up.

I was searching specifically for a PPTP device simply because it is so easy to configure and use, especially for Windows-based clients.

If you have a spare computer you wanted to use for this, you may want to look at IPCop, but at about US$350 the sg530 is not a bad alternative.

Re:OpenVPN

[PGillingwater]

By default, OpenVPN uses UDP, so the problem of TCP tunneling inside TCP doesn't need to happen (although in my experience is minimal except on heavily congested or small MTU links.) I think the parent post isn't referring to using OpenVPN with TCP (although this can be done). [Aside: TCP inside TCP isn't really a problem with packet counters, it's the sliding windows and retransmissions which causes problems.]

I've used many VPN solutions, starting with proprietary (Raptor with IPIP), through to MS PPtP and IPSec (FW-1), and have also sold solutions based on FreeS/WAN, but have found OpenVPN the most simple to use and configure.

Another advantage of OpenVPN is it can tunnel at layer 2 or layer 3, i.e., you can use it to bridge or route. It will happily support host to host, host to LAN and LAN to LAN.

Its Windows client plays nice with Linux endpoints, and because it uses OpenSSL, it has very flexible keying and certificate handling options.

Its only downside is lack of interoperability with IPSec-based solutions -- but if that's a requirement, then look at OpenS/WAN.

Bottom line: if you need to build up a low cost, flexible VPN solution based only on software, with full source code available and full of features (like dynamic end-points) then OpenVPN is a great choice. It also avoids the hassle of NAT-T which IPSec has to use due to address translation.

Re:OpenVPN

[schon]

There's a theoretical problem with TCP in TCP on connections with errors

No, it's not theoretical, and it's not just with errors. A single link with high latency will kill your connections. It really does happen.

From a practical perspective it works just fine

Only if you're extremely lucky. If you're not, you *will* experience problems. If any of the connections between sites become saturated, you'll experience dropped packets, which starts the snowball rolling down the hill.