Gallery

Open-source VPN

Posted on 12 Jul 2007 at 16:50

Simon Brock and Ian Wrigley examine two open-source VPNs that promise to deliver as much as their commercial rivals.

For our VPN, we elected to use a routed setup for three reasons. First, on the machines we were planning to set up the VPN it was simpler to configure. Second, we don't make much use of Windows shares, but we do already have a WINS server in our network (based on Samba). Third, we use OSPF (Open Shortest Path First) routing within our network, as we have multiple outgoing routers, and as such we can make our VPN endpoint machine publish a route to the VPN, which will be picked up by the other machines and devices in our network. OSPF routing is probably the best routing protocol option if you do have multiple redundant routes out of your network, as it's easier to configure than protocols such as BGP and more reliable than protocols such as RIP.

So having decided on our setup and having installed the software, we sat down with a page from the website and configured our server. The setup described on the website, which is based on creating public keys for network connections, is quite involved but takes only about ten minutes. Having set up the server, we then looked to configure our first client, which was a Mac. To get the software onto the machine, we installed Tunnelblick (www.tunnelblick.net), which provides a nice little menu widget to access the VPN and a simple-to-use interface to see what's going on. It does still require you to write a configuration file, but we used the one that came with OpenVPN and had to change only one line (the remote line that told our client where the VPN server was, which wasn't that surprising!) At that point, we selected "connect" from the menu and the VPN was up and running, but we couldn't access anything. We then realised we hadn't enabled routing properly on the client, so we had to add some "push route" commands to a server configuration and enable routing on the server. All this information is on the website if you have the same problem.

Having configured one client, configuring more was easy, and we soon had a number of people using our VPNs. A particularly useful feature is that you can configure multiple OpenVPN servers in your network and then refer to them with multiple "remote" lines in the client configuration files - the client will then load balance among these multiple servers, which brings resilience and reliability. Obviously, all these servers must have identical configurations. From the website, you can also find some useful articles, including one about setting up Windows installers, which can be given to your staff to allow them to access the VPN.

OpenVPN allowed us to get a VPN for remote users up and running very quickly. It's a fiddly solution, though, and is quite difficult to configure if you want to do anything more sophisticated such as set up "per user" access rules.

SSL-Explorer

SSL-Explorer is a completely different type of product to OpenVPN. While it's open source and can be downloaded from http://sourceforge.net/projects/sslexplorer, the version you get is the community version of a commercial product. There's absolutely nothing wrong with this approach, but it does mean there aren't the community contributions that are available for OpenVPN. SSL-Explorer is written by a UK company called 3SP, which is based in Nottingham (see www.sshtools.com for more information).

Where OpenVPN is really an operating system utility, SSL-Explorer is a browser-based system. As a user of the system, you don't have to put extra software onto your machine; instead, you point your web browser at the public website, which allows you access to the internal resources. Once you've authenticated yourself to this website, you'll be presented with a page that shows you which services you have access to. Clicking on a service causes a Java applet to launch, and it's this Java component that does all the work by establishing a tunnel from your machine to the destination private service. In most cases, the tunnel is set up as a "proxy service" - you connect to a service as though it were on the local machine and that connects you to the Java component, which proxies through to the remote system. This approach does have a number of advantages over OpenVPN, as it doesn't require any special software on the client, meaning a remote service could be accessed from anywhere at all. In particular, this proxy behaviour can be useful for allowing very controlled access to an internal web server - it could allow a person outside the office to access the internal web server from any web browser, without compromising security.