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.

The two VPNs we're going to examine are based instead on SSL - the Secure Socket Layer - which is widely known as the protocol used by secure web servers. When you connect to a server whose URL starts "https", your browser is using SSL, which encrypts the web traffic. In the case of a web browser, SSL tunnels the normal web requests in encrypted form over the internet, while in the systems we're going to look at, OpenVPN and SSL-Explorer, the VPN is constructed using an SSL connection and the private packets are sent over that. OpenVPN is a VPN system for the command-line generation - there are GUIs for it, but you're going to have to write a configuration file - although, as a result it's very lightweight and simple to deploy. SSL-Explorer, on the other hand, is a complete solution with a web interface and a rather different approach.

OpenVPN

OpenVPN implements VPNs for almost every computer system. Both clients and servers are readily available for Linux, Mac OS, Solaris and Windows as installable binaries, and for other Unix systems it should be a fairly simple job to compile them up from the source. We decided to install the server onto a Linux system (CentOS 5 to be precise) using binaries we downloaded from Dag Wieers' excellent RPM site (http://dag.wieers.com). As expected with an RPM package, installation was easy, but configuration requires some thought and some reading of documentation. Our aim was to be able to set up VPNs for people at home or on the road, enabling them to access our company's resources, and we'll explain the process so you can do the same.

The first thing you need to understand about OpenVPN (and to some extent all VPNs) is how remote machines are going to appear to your local network. OpenVPN presents two options: a bridged or a routed setup. A bridged setup is the easiest to understand, so we'll start by explaining that. Imagine you have your internal network set up to use the IP address range 10.1.1.0 to 10.1.1.255 and you have a subnet mask 255.255.255.0. If you've set up IP before, you'll understand what that means (and may recognise it by the more succinct 10.1.1.0/24 address space). In a bridged setup, the VPN is allocated a collection of addresses in the address range from the main network and then the users of the VPN seem to be located in the address space of the office. In a routed setup, the users of the VPN are allocated a different address range from the main network.

At first glance, it might seem that a bridged setup is what you'd always want: from certain standpoints it does make things simpler to understand, and in some circumstances it leads to a simpler setup on the clients, because network broadcasts - which are used, for example, in browsing a network for shares - are carried correctly over the VPN. However, this extra traffic can cause problems and may make it more difficult to impose a security model on the users of the VPN. Also, setting up the bridging interfaces (which are called TAP devices in Linux and Windows) is more complicated and involved.

As you may have already guessed, a routed setup has none of these problems and is easier to set up from the VPN standpoint. However, you may have a problem in that your existing network may not know how to reach your VPN network, and as such you'll have to reconfigure all your existing machines to be accessible via the VPN. In some circumstances, this may be seen as an advantage, since you might decide to enable only these extra routes for those machines you explicitly want to be accessible via the VPN. If you do use a routed setup and you do want Windows clients to be able to browse the network, you'll need to set up a WINS server, which under Windows is easy to do. If you're using a Unix system, it's a simple-to-configure option using the open-source Samba package.