Thursday, 18 January 2007
One of the coolest things to come out of the SOHO router market has been the ability to take a few of the Linux-based routers and significantly upgrade their capabilities using community driven 3rd-party firmware. The most popular of these of course is the WRT54G(S) varieties since they can be had for under $50 pretty easily. Unfortunately, Linksys (or Cisco) decided that they didn't appreciate the competition, so newer WRT54G based routers no longer have as much memory or even run Linux anymore, making them much more difficult to upgrade. Instead, they now offer a more expensive WRT54GL (where L stands for Linux I guess) model that is essentially what the older models were and still are easily upgradeable. Of course, Asus and Buffalo make decent and affordable routers that can be upgraded as well, so you needn't worry too much if you can't find an affordable Linksys version.
I have previously mentioned OpenVPN on this blog and sang its praises as an extremely capable SSL VPN solution. In the past, I was running a VPN server on my home computer and forwarding the port through the WRT54G such that my client laptop could connect from anywhere to my home network. This is very useful when you have very restrictive firewall or web proxy policies you don't feel like obeying.
I use DD-WRT firmware on my WRT54GS router. I initially looked at using Sveasoft, but found their business model to be a little disturbing and hypocritical. The DD-WRT firmware is top notch, well maintained, and free however. The other day I was checking out what progress has been made for new features, and found that in addition to working as an OpenVPN client, the latest release of the DD-WRT firmware also allows the router to work as a server. This is huge. This means that I can now remove the VPN server from my home box and locate it on the router which allows me to hit each and every computer easily on my network instead of just one.
Setting up everything appears intimidating, but it really isn't. Here is how to perform this simple task and get your own SSL VPN. Assuming you have a capable router, just follow these easy steps:
- Download the DD-WRT firmware from here. Install the one with VPN support built into the image. When I did this, it was v.23 SP2 VPN (dd-wrt.v23_vpn_wrt54gsv4.bin). However, you should read the Wiki to make sure you are installing the correct version for your model (mine was a v4 GS version).
- Download the OpenVPN GUI or OpenVPN Admin software and install on your client. For Vista users, first install the latest OpenVPN (version 2.0.9 or later) and then install one of the clients on top (GUI only). Vista will choke on installing a new TAP adapter if you don't use a later release (I used version 2.1 RC1 with no problems). Since the GUIs are packaged usually a bit behind the latest release of OpenVPN, you may not be able to download and use an all-in-one install on Vista.
- Follow directions here on how to create SSL certificates for your server and for each client machine that will be connecting. Note, I was unable to get OpenSSL to sign my certificate request from Vista (even running as an admin). When I took the files to an XP machine, I had no problems however. Technically, you don't even need to use certs and can use a static key. However, I like the idea of using certificates as you can get even fancier later with your own CA authority and automatic enrollment if you would like.
- Use this script here in the section entitled "Server Mode with Certificates" to install the server certificates and startup script on your router. Reboot your router. You just need to cut and paste your information into the script.
- Create your client configuration file and start it! This is very easy to do using OpenVPN Admin and pretty easy to do using the sample config file from your OpenVPN installation or if you used OpenVPN GUI. You now have a secure VPN connection back to your home network and should find that you can ping any machine on your network as if you were sitting behind the router. See screenshots below using OpenVPN Admin for config params. Note, if you are at a place that has a web proxy, use the Proxy tab to tunnel right on through.
A couple final notes: If you are using a web proxy, you must be using TCP instead of UDP. The server is already setup using TCP, so your client should be setup with that as well. Additionally, you can use a TLS handshake initially for even more security. I did not do this in my router install, but had it working on my home server installation. I also modified the scripts in step #4 and in step #5 to use port 443 instead of the default 1194. The reason is that certain locations will block all ports but 80 and 443 typically, so it is easiest to use this and tunnel through this port.
So, with a couple hours effort (to initially read the Wiki) and a $30 hardware investment, I now have an extremely capable and resilient solution that allows me to securely access my home network from virtually any place that has an internet connection.
Monday, 12 September 2005
As a traveling consultant, I often find myself working for clients that have very restrictive internet access policies (to say the least). I have worked on clients that keep things so locked down that I actually have difficulty doing my job as a developer. One client in particular was causing me grief because of the following restrictions:
- No outside laptops on the network (they issued me one when I got there). Their intent is to stop outsiders from introducing worms or viruses, but in reality it is just a pain for the hundreds of contractors that are engaged there and an added expense in needing to provide a laptop to everyone. I was lucky enough to get local admin rights to my laptop, but there are plenty that don’t have that. With local admin access, I could at least install the tools I needed to get my job done.
- No outside mail on the network – including all types of web mail. This is also intended to stop the spread of any mail bound viruses. I would think they would make an exception for work email, but that is not the case. This means that I am totally disconnected from the mothership except for my smartphone during the day. This is pretty hard to deal with as I get plenty of mail from work during the day and ignoring it until I can check it from the hotel is usually not a good option.
- Extremely restrictive web filtering: I am talking no blogs, no Google groups, nothing remotely related to the word ‘download’. This hurts a bit since I tend to use Google groups and blogs quite a bit for .NET development. I never realized what a handicap this would be until I tried to go without it. I think the intent here is to keep people from looking at anything considered ‘social’.
I respect the intent of the restrictions, no matter the methods used. I decided to keep the spirit of this and just terminal into my home machine when I needed to check my work mail and look at Google groups for answers. I would leave the local drives disconnected so as not to introduce anything from their network to mine or vice versa. This would keep their network risk free of the viruses they were afraid of, but allow me to be able to function. It initially worked pretty well and I was able to just keep a remote window open and reference it as needed during the day.
Then something changed… I could no longer access my machine using RDS. I managed to RDS to another machine and then RDS from there back to my machine. I changed the port my server listened on from the default 3389 and got it working again. This told me that they had decided to block 3389. Things continued fine for a few more weeks when all of a sudden, it stopped working again. This time, it looked like they had put a filter on the firewall to block all RDS traffic because port changing had no effect. I could see this was an escalating arms race. I decided to to look at getting a personal VPN solution.
In my research, I found that there are a few consumer router models on the market that can act as VPN end-points. I also knew that I could buy a Linksys WRT54G and use something like Sveasoft to get a cheap but sophisticated VPN solution. However, the one nagging issue with all of these was that they relied on either IPSec or PPTP. These can easily be blocked and cannot traverse an HTTP Proxy. I wanted something that would tunnel through an HTTP Proxy – which meant SSL VPN.
If you are not aware, buying an SSL VPN device is not a cheap proposition (they start in the low $10K ranges). Some of them are a bit of a mis-nomer as well as they just web-ify certain applications, but do not actually provide a VPN. In my searching, I finally found OpenVPN. It is a free, flexible, and powerful software SSL VPN solution. All I had to do was setup the VPN client on my home machine and my laptop, create a couple certificates (easy to do), twiddle the config slightly and I have an encrypted connection back to my home server to use as I please. I also had to use port forwarding to send the OpenVPN traffic through my router’s firewall to my home machine VPN Server. If I really wanted to, I could even route my internet traffic over the SSL VPN and evade their proxy server filtering completely. However, as I mentioned earlier, it is not my intent to do anything that violates the spirit of why they have these restrictions. So, I am typing this in my RDS session that is being tunneled through the proxy server over an encrypted SSL VPN connection. I have launched the latest salvo in the arms race, I wonder what will be next…