I’ve spent the last couple of days setting up OpenVPN, the open-source VPN software, and I’m very impressed.
My parents’ office is increasingly mobile, with my sister working from home with the baby, and Mum and Dad needing to access data while out at clients’ offices. Up to now they’ve coped with a laptop, copying files back and forth as necessary, but this isn’t great for backups or security. As most businesses have wireless broadband internet these days, a Virtual Private Network – connecting to the office network via the Internet – seemed like a good idea. The trouble was, VPNs scared me.
I’m not a total novice – I’ve had some experience setting up a proprietary Cisco system. I didn’t get into the real nitty-gritty of that setup, but I understood the basic concepts: the need for encryption and authentication etc.. However, I also knew that things get very complicated very quickly. Encryption alone is a nightmare. I know from experience that these things are easy to grasp at a basic level, and there’s always plenty of information at the technical level, but bridging the two is difficult. Without a structured training course you run the risk of missing something important, or – and this was my primary worry – configuring something that works, but that you don’t really understand.
So I tentatively started exploring the options. If I needed to buy a bunch of books, so be it. And I quickly came across Hamachi.
Hamachi is VPNs for doofuses, like me. You install a client onto each computer, and these then register with a central server. When you want to connect to another machine on this virtual network, the central server mediates a secure connection, then leaves them to it. I didn’t understand the ins-and-outs of the security features, but it’s recommended by the ever-paranoid security expert Steve Gibson, so I figured it must be pretty good. Icing on the cake: it’s free.
I installed it. It was indeed remarkably easy to set up – I had to configure a couple of port-forwardings to get it fast enough, but when it worked, it worked very well. Other machines were accessible by their Hamachi name, so I could treat them as if they were on my network. Totally seamless. Great! But, the service was occasionally down. And if the central server isn’t working, there’s nothing you can do. Plus I had intermittent connectivity to certain computers – Hamachi would sometimes only establish a proxied connection, so data would have to flow through the Hamachi central server rather than directly (and you’re only allowed a certain bandwidth before they kick you off – unless you pay a subscription). If this were continuous I could have fixed it, but it only happened occasionally, and that’s just annoying. I also had problems with kicking machines off the network, as well as annoying bugs in the client generating demands to set a ‘master password’ every restart. So I started looking elsewhere.
And that’s when I first found mention of OpenVPN (again from Mr Gibson). It seemed to do exactly what I was after, but without the external infrastructure – the software handles the connection at both ends, so there’s no need for central servers. It’s also open-source, free and highly recommended. But this obviously comes at the price of extra complexity, and it would clearly be far from the easy ride of the Hamachi setup. Nevertheless, this seemed to be the best option, so yesterday morning I took a deep breath and dived in.
I needed an overview, and their home page links to OpenVPN and the SSL VPN Revolution – a white-paper on the concept of OpenVPN. Sounds terrible, right? Official documentation is usually extremely detailed and extremely useless for the beginner – I usually have to search for clarifying blog posts or forum questions, and piece it together from a thousand different sources. Not this time.
That document explains everything, and explains it clearly. Even amusingly (“There are many ways to exchange keys, some elegant and some barbaric”). From the basic problems a VPN needs to solve, to the various different attempts to solve said problems (and why some of them suck *cough* IPSec *cough*), to the most advanced and battle-hardened encryption methods and authentication standards, it covers everything. I was amazed.
I was particularly fascinated by public/private key encryption. I thought I understood it. Turned out, not so much. I’d love to be a mathematician in that field, as it’s very cool. Here’s how the aforementioned document describes it:
Certificates use Public Key Cryptography, meaning a host generates a public and private key pair that are mathematically related to one another. Any data encrypted with the public key can only be decrypted with the private key, and vice versa. Each end system has its own public/private key pair. The public key is given out to the world to encrypt traffic bound for the system, and the private key is kept secret to decrypt this traffic. The private key can also be used to prove that data was actually sent by a specific entity, which is called non-repudiation. If I encrypt something with my private key you can confirm it is really me by decrypting it with my public key.
As I said, I’ve been introduced to these concepts before, but the above was like a light bulb flicking on. I can’t recommend the white-paper enough as an all-round introduction to VPNs. I’ll probably need to read it again within a week, then refresh it occasionally, to keep the not-often-used concepts in my head, but that should be do-able.
Armed with this knowledge, I set about installing OpenVPN. I pretty much followed the HOWTO on the website. I set up the GUI, generated the various certificates, forwarded one UDP port at the server end, configured the text files and copied the right files to the right places. It took maybe 40 minutes to get everything ready, so i clicked ‘connect’. Didn’t work. Obviously – nothing does first time. I quick glance at the logs and…I hadn’t put a file path in quotation marks. This fixed, I hit connect again and…it connected.
I was logged in to my parents’ network over an uber-secure connection, and could ping the server. Just like that. A config line, a static route and an XP registry tweak later, I could ping any machine on their network. Another generated key and I had an extra authentication layer. A tweak to the certificates and the initial connection startup was passworded, just so anyone messing about with the laptop can’t play havoc by accident. No hassle, no stupid bugs, no stress. That’s pretty rare. So the technical side was set up exactly how I wanted it, which was lovely, but I needed more. It needed to be used by non-geeks, so required prettification.
OpenVPN GUI let me create a desktop shortcut, and via registry tweaks I turned on the silent connection options, which hide the ugly console windows and encryption info. There’s also the option to run a batch file on connect/disconnect – I set these to map/delete network drives. Sorted.
So on their laptop my parents can click a shortcut, enter a password, and a few seconds later they have an E: containing all of their documents, as if they were at home. On any wifi connection. This is exactly what I wanted, and it’s brilliant that it worked so well, but more important is that I understand what’s happening this time. It’s not magical Hamachi superpowers, it’s blowfish encryption and certificate-based authentication over an SSL connection. And writing that didn’t scare me at all.
This somehow got very long. But in conclusion: I haven’t tested OpenVPN extensively yet, but initial impressions are great. So far it’s been easy to understand, rock-solid stable and everything I could ask for. And the white-paper = as good. Recommended.
The only worry I had was that Windows File Sharing might need to know the names of individual computers, which wouldn’t work over the VPN1. I thought I might have to set up a WINS or samba server to control computer names, and a bit of googling suggested there are no WINS servers for XP, and installing samba would always require linux – a whole other skillset. But I was wrong – Windows File Sharing is happy to work via IP, so I just used that.
Today I set it up on my sister’s Vista laptop. This presented its own challenges that I shan’t bore you with. I will just say that a) the promised client installers will be a great help – deploying the current setup to many computers would require jumping through a few hoops atm – and b) transferring executable files over the Internet is increasingly nightmareish: the combination of Gmail, Live Messenger and Vista paranoia drove me doolally. If you want to set up a machine, it’s easiest to drive over with a usb stick.
FYI, the current state of remote control software for Vista is appalling. Vista Home doesn’t support Remote Desktop; TightVNC doesn’t support Vista; UltraVNC does, but its site and setup procedure are currently such a mess that talking a novice through it on the phone would be formidable. But the built-in Remote Assistance, of all things, saved the day. XP’s version was a bit rubbish, but Vista’s implementation actually understands NAT and routers, and Just Worked. I was actually pretty impressed, as it can even handle UAC prompts. Worth a look.
- I set up a ‘routing’ network rather than a ‘bridging’ network. This means only IP-based protocols can flow between the two, and netbios is certainly not IP-compatible. Bridging makes it all look like one big network, but is more complex and unwieldy [↩]