VPN’s, or Virtual Private Networks, are a bit of a tricky beast.  VPN’s allow remote clients or sites to join with your internal network as if they are right there in the building.  Hence the “Virtual” part of the term.  You can get complete connectivity and access to all the internal server resources you would normally have access to, albeit at a speed limited by your network connection.  Still, it’s very effective.  Being able to “VPN” into your network is essential for getting work done away from the office.  And having a VPN server is essentially second nature for business nowadays…it’s a logical, broad, and secure line of defense against outside intrusions.

The problem with VPN’s is that there are apparently all sorts of different ways to set one up.

Microsoft implements PPTP (probably the most common) and L2TP VPN’s.  These are very popular because you can do it all with just Windows workstations and servers.
There are a bunch of hardware VPN concentrators, which can do different flavors of VPN, many forms of which are often proprietary. Cisco is pretty well known for these.  I’ve never had a desire to set one of these up until recently, nor do I understand the appeal in general, but I’m sure they exist for a reason.
And then there are some different alternatives, like Hamachi and OpenVPN.

VPN’s sound pretty simple in theory.  Just point me at a VPN server and let me on the network…right?

In fact, it’s not really that easy.  One trouble I’ve faced for a long time is the fact that routing VPN traffic through a firewall or NAT is nowhere near as transparent as it should be.

For example, my router at home can only have one Microsoft style VPN connection going through it at a time…which, obviously, is lame.  If my computer at home is VPN’d out, I can’t VPN in.  If someone was at my house with a laptop and wanted to VPN somewhere else…they couldn’t if I was VPN’d into work.

Another example of a problem is the internet service I get through my cellular plan.  I use the $20 unlimited MediaNet plan from Cingular.  The router behind which the phone’s internet connection sits is basically a NAT that won’t or can’t pass PPTP or L2TP VPN traffic.  So if I try to connect with my laptop through my phone to the internet, I can do a lot of stuff pretty slowly…but connecting via VPN into the office is flat out not possible.

Both of these problems appear to be mostly due to the fact that someone, in their infinite wisdom, chose some completely different internet protocol for establishing VPN connections than good old UDP or TCP.  Something called IP Protocol 47, or GRE, is used to negotiate the connections.  For the life of me, I cannot figure out why this was necessary, but the upshot is that numerous routers and other networking equipment have a horrible time routing this type of VPN traffic successfully.  In fact, I’d like to lock whoever made the decision to use anything besides UDP and TCP in a room with nothing but Celine Dion records playing 24/7.

So here’s where I was at.  I’m well aware that the odd protocol used in MS VPN solutions causes issues and, especially, prevents me from establishing a VPN to my home or office in particular cases.  We’re not planning to buy a hardware VPN solution to solve this…we’re a small company and in most cases, VPN does work.  It’s just that, me being me, I like a complete solution to my problems, and the inability to VPN into work via my wireless WAN service bugs the crap out of me.

I checked out Hamachi briefly.  Didn’t seem like something particularly oriented towards serious use…running as a service appeared to be a bit of a hack job, and the options appear to be very limited…documentation is all in the form of forum posts. Hamachi seemed to be an application focused on working, but not necessarily working specifically how you needed it to work.  In the end, I had to take a pass..

Luckily, next I stumbled across OpenVPN, which is, as you might have guessed from the name, an open source application for VPN servers and clients.  I would never have bothered with something like this if it weren’t for all these silly VPN troubles I’ve had in the past and continue to have.  But I have them, and I would like them solved.

After scanning through the OpenVPN website, I took special notice of the fact that OpenVPN supposedly runs completely over UDP or TCP.  Ah yes, this showed promise…if such information was true, it would be free of the painful and yet avoidable troubles that plague standard MS VPN solutions.  But I also noted that the extensive documentation on the site was both a blessing and a curse…everything was probably going to be tweakable, but getting it running correctly looked like it was going to be very tough.

Nevertheless, the capabilities were more important to me than the ease of setting it up in this case.  I downloaded and started poring over the docs.

As expected, OpenVPN is rather painful to set up.  I had to use what is known as a bridging configuration, which I only figured out after blundering through the routing configuration and hitting a dead end.  And I spent a lot of time reading and re-reading all the different how-to’s and guides to absorb what I needed to know.   Most of the configuration of OpenVPN takes place via creating text files and following text prompts from command line tools.  Figuring out what options you must configure, generating all kinds of certificates and keys, and figuring out what options you can omit are, as with most open source applications, completely unclear.

But here’s the important part…after much fudging, it works.  About a month ago, after experimenting all day, I got OpenVPN working over UDP on my home network over the standard UDP/1194 port.  I rather carefully documented the procedure and server/client .ovpn files so that I could repeat the same process at work.

Fast forward.  At work, I ran into several snags.  The first being that I actually needed a separate Windows 2003 box and there was no such box ready.  Windows 2000 doesn’t support bridging adapters, which I found to be necessary for letting the client appear on the server’s network.  So I had to wait for our admin to get that box up and running.

The second snag was that our router was returning some of the UDP packets from the intial VPN negotiation on different ports than expected…apparently due to the port translations necessary.  I couldn’t establish a connection this way.

My initial setup instructions weren’t working so well…it was clear at this point that this wasn’t going to be a straight adaptation of the setup I created at home.  Luckily, I managed to work past the new problems I encountered anyway.  By switching the clients and servers from UDP to TCP, I dodged around the UDP packet issues introduced by the router/gateway.  Since TCP, unlike UDP, establishes a connection, not having the router mess up port translations looked like a promising way to deal with whatever was happening in the UDP approach…and as it turned out, it most definitely was.  And in addition, the occasional timeout during key negotations I managed to deal with by raising the timeout to 120 seconds…apparently over a slow link this timeout really is an issue and it can stop you from ever completing a connection unless you pay attention.

Anyway, it took a while to put it all together, but the scary part is that it works, and without any of the unholy and completely unsolvable routing issues normally associated with VPN.  I can have multi
ple VPN connections inbound and outbound through my router. And I can now VPN into my home or work through my cell phone’s internet plan.

So my short verdict on OpenVPN…complicated, but totally worth it if you’re hitting brick walls like I was.  It’s now doing exactly what I needed it to do…making VPN connections and making the intervening junk on the network invisible instead of an obstacle.  If you need to set up a VPN, I highly recommend trying OpenVPN.  Once configured, it’s actually more capable of doing what it says it does than most regular VPN solutions…and at no cost except for your time and whatever box you put the server on.