Our recent Linux.com survey results told us that you want more tutorials on the site, so today we are introducing a new series called “Weekend Projects.” These tutorials will run on Fridays and will be longer than our regular original tutorials, since their purpose is to provide Linux users with a fun project to embark upon over the weekend. Please share with your friends and colleagues and have fun with it! And, as always, let us know if it’s useful and what other topics you would like to see in this series.
Virtual Private Networks (VPNs) are no longer the domain of highly-sensitive remote office workers. As the workforce becomes more mobile and the number of connected devices in our homes rises, we’re increasingly finding the need to connect to our home network from the hotel room, Internet cafe, or simply from across town. Linux offers an array of free VPN alternatives, which you can set up and test in just a few hours’ time. If you are running a Linux-based router as the gateway between your LAN and the Internet, the task becomes even simpler.
Getting Up To Speed
VPNs come in two basic flavors (barring proprietary, single-vendor offerings, of course): those that use the IPSec protocol, and those that use Transport Layer Security (TLS) or its predecessor SSL to create a tunnel between the client computer and the VPN server. IPSec is an official IETF specification that works as a secure Internet Layer replacement to the IP protocol. While powerful and robust, it suffers from the practical problem of many ISPs and public access points blocking IPSec in order to sell access to it as a business service. TLS/SSL-based VPNs operate two layers up in the protocol stack, at the application layer, and encrypt traffic over normal TCP and UDP channels. Virtually all ISPs and public access points permit TLS/SSL traffic because it is vital to Web commerce sites.
Currently the leading IPSec VPN system for Linux is Openswan, and the leading TLS/SSL VPN system is OpenVPN. In addition to the TLS/SSL availability issue, OpenVPN also has the advantage of being available as a package for the popular Broadcom-based Linux router distributions: DD-WRT,OpenWRT, and Tomato all run on low-cost Linksys and Buffalo router hardware, and can run OpenVPN with a simple, web-based administration panel as a bonus.
OpenVPN Basics
To set up a VPN, OpenVPN must be installed on each machine that contacts an endpoint: in the typical use-case, that means the router at the edge of the LAN, and a notebook or mobile device that needs to connect to that LAN remotely. The same OpenVPN executable can run as the “server” (i.e., on the router) or as the “client” (i.e., the notebook). When the client initiates a connection to the server, both machines authenticate each other’s identities, either with a pre-shared key, or with SSL certificates.
Certificates are the preferred method. You create a separate certificate for each machine when you are setting up your VPN; that way you can revoke a compromised certificate and replace it without affecting other clients. Furthermore, you sign each certificate with a “master certificate” that never has to get copied or transmitted on-line at all; you can even perform the signing step disconnected from the network entirely, and store the master key in a vault.
At runtime, OpenVPN has two modes of operation from which to choose: With the routing mode, the client machines get a separate block of IP address space that works like any other subnet. OpenVPN doles out the addresses, and routes traffic based on this subnet division. In bridging mode, you first set up a virtual Ethernet adapter on the server that bridges the server’s physical Ethernet device with the virtual OpenVPN device, creating a single, combined interface.
Bridging is notably more work, and in most circumstances the only difference is that the clients connect to the LAN’s DHCP server and receive IP addresses from it — not from OpenVPN — just like local machines. However, some use cases, such as multiplayer LAN games, rely on this functionality. For everyone else, though, starting with routing mode is the best idea.
Install OpenVPN and Generate the Master Certificate
Your Linux router’s distribution may or may not include OpenVPN as part of its normal firmware; getting the appropriate update is step one.
If you are working with DD-WRT, the _mega and _vpn builds include OpenVPN support; these can give you flash directly onto your router. Developer Keith Moyer provides Tomato firmware packages with OpenVPN pre-installed on his Web site and provides regular updates. OpenWRT does not ship pre-installed firmware images with OpenVPN but provides it as an installable package. Finally, all major desktop and server Linux distributions include OpenVPN in their package management systems — if you are using a standard PC as your OpenVPN server, simply install the package.
Next, install OpenVPN on the client machines you will be using to connect to your LAN. Official binaries are provided for OS X and Windows on the OpenVPN page. Linux packages are available, too, but try your distro’s package management system first.
You will need a working OpenVPN installation in order to create the necessary SSL certificates; for the sake of simplicity we will assume that this is a Linux box, but the same steps are possible on other OSes. OpenVPN includes a set of convenient certificate-generation scripts, which should be located within the installation directory (typically /usr/share/doc/openvpn/examples/easy-rsa/). Either change to this directory, or copy the scripts to another location before proceeding.
First, run (either as root, or preceded with sudo) the initialization script:
./init-config
Next, initialize the settings with:
sudo source ./vars
Then clear away any leftover files from previous runs with sudo
./clean-all
Run sudo ./build-ca to generate the master certificate and an associated key (which is also referred to as the Certificate Authority). The script will prompt you for various information, such your country name, organization name, and email address — for a privately-used certificate like this one, the answers are not critical, but you cannot leave them blank. The most important is Common Name, which in the master certificate’s case should be chosen to be clear in its purpose, lest you forget — such as “My OpenVPN Master CA.” The result will be the files ca.crt containing the master certificate, and ca.key, containing its key.
Create, Sign, and Install Your Certificates
Next, create a certificate for the OpenVPN server by running:
sudo ./build-key-server server1
and for each client by running:
sudo ./build-key client1
through
sudo ./build-key clientN
As before, the scripts will prompt you for information including Common Name. It is a very good idea to choose an easily-associated Common Name; in these examples the files created will have the prefix server1 and client1 through clientN, so reusing those as Common Names makes everything simple.
Each build-key script will also ask you if you want to sign the certificate being created — always say yes. This signs the newly-minted certificate via the master CA key you created earlier; it is this common signature that allows the server and clients to authenticate each other in the wild. Last but not least, run sudo ./build-dh to generate Diffie-Hellman key agreement parameters. These will be stored on the server and used to set up connections.
With all of your cryptographic files now complete, it is time to move them to their proper locations on the server and clients. Each client will need only a copy of its own certificate and matching key, for example client1.crt and client1.key, plus a copy of the master CA certificate but not the master CA key. The server needs a copy of its certificate and key, the Diffie Hellman parameters, and the master CA certificate.
The security-conscious will tell you that it is important to transfer these files (especially the keys) over a secure channel. Certainly if you use a USB key to move the files to the clients, you should securely erase it once you are finished — USB keys are too easy to lose. The server keys will be copied to the router through the web administration interface, so do not perform that step over unsecured WiFi. The master CA key does not serve any function after the signing step, so it can be safely stored offline.
Server Configuration
Go to your router’s web administration panel. OpenVPN is normally found under the “Services” tab, alongside Quality-of-Service, VoIP routing and other add-on functionality. You must typically enable the service, select the basic settings, copy over the certificates and keys, and restart the system in order to launch the OpenVPN daemon.
On DD-WRT, OpenVPN configuration is located in the “Services” -> “Services” tab. In the current release (v24 Service Pack 1), you can perform all of the necessary configuration through the web administration interface; prior to in Service Pack 1, you had to upload a server configuration file and make other changes via SSH. The selected defaults are sensible for a routing-mode VPN, although you can change the TCP/UDP port number to be used (the default is 1194) and whether to use TCP or UDP as the transport (default is UDP), if necessary. The configuration screen has text-entry boxes into which you must cut-and-paste the cryptographic certificates and keys (like GPG and SSH keys, they are ASCII text), and into which you paste or type the configuration file.
There are sample server and client configuration files in the same directory as the easy-rsa folder; a basic server config file looks like this:
push “route 192.168.1.0 255.255.255.0”
server 192.168.2.0 255.255.255.0
dev tun0
proto udp
keepalive 10 120
dh /tmp/openvpn/dh.pem
ca /tmp/openvpn/ca.crt
cert /tmp/openvpn/cert.pem
key /tmp/openvpn/key.pem
To explain, the “push” line indicates which network addresses belong to the LAN — here, 192.168.1.*. The “server” line indicates that OpenVPN clients will be given the 192.168.2.* address block. Further down, the “dev tun0” line indicates that this is a routing-mode setup — bridging mode VPNs use tap0 instead of tun0. The final few lines indicate the location of the uploaded cryptographic files.
Finally, set “Start type” to “WAN Up” to tell OpenVPN to start whenever the WAN interface is activated, and click the “Apply Settings” button. If you are running a firewall on your router, be sure that you permit traffic on UDP port 1194.
Client Configuration and Testing
Client configuration is more straightforward; no web-only interface is required. Simply copy the client certificate and key files to the /etc/openvpn/ directory and create (or copy from the sample files) client.conf. A basic file should contain:
client
remote yourserver.dyndns.org 1194
remote-cert-tls server
dev tun0
proto udp
resolv-retry infinite
nobind
persist-key
persist-tun
float
ca ca.crt
cert client1.crt
key client1.key
The important values to check are the “dev” entry, the names of the cryptographic files, and the protocol. The “remote” line gives the name or address of the OpenVPN server and the port number to which to connect. If you have a static IP address on your router’s external interface, you can place it here. Most ISPs do not provide this, however, so you can use a Dynamic DNS service instead. DD-WRT comes with built-in support for a variety of Dynamic DNS services you can try.
Once set up, start the OpenVPN client service with openvpn /etc/openvpn/client.conf(do this while not connected via the LAN, of course). The client will report any error messages in console output; you should see time stamped output reporting initialization of the TLS tunnel. Try pinging an IP address on the LAN; a response — even if it’s slow — indicates that your VPN is up and running.
Common problems when setting up OpenVPN initially include firewall trouble (which you can test for by temporarily disabling the firewall), server configuration file trouble (which you can catch by enabling error logging on your router) and routing trouble. Unfortunately, because you must test OpenVPN from a remote network, there is always the chance that the WiFi hotspot you connect to happens to have an address conflict with the reserved IP address space you use on your home LAN. If 192.168.1.100 is used in both locations, OpenVPN doesn’t know where to route the packets. The only surefire way to work around this problem is to change your addresses!
You may also find differences in the location of sample files between the official OpenVPN packages and those supplied by your Linux distribution. OpenVPN is widely supported enough, though, that finding the correct directory is usually no more complex than searching the distribution’s documentation. For OS X and Windows clients, you can stick with the directory information provided by the OpenVPN project.
Digging Deeper
Setting up OpenVPN on a home Linux router is simple enough with the modern router distributions. But you may not find that it meets all of your needs, or you may need to set up OpenVPN on a full-fledged server. The best place to start is the OpenVPN project’s documentation site, which has detailed directions for server installation and setup, as well as a reference to the various configuration parameters.
Setting up a bridging mode VPN is a good next step if you are comfortable with Linux’s Ethernet bridging functionality. Despite requiring extra steps at setup time, a bridged network is easier in some respects to maintain; all connected OpenVPN clients appear as clients on the LAN, at the link level. This not only means they can send and receive broadcast traffic, but when used between two routers, can connect two remote offices in a single network configuration that is easier to administer. The OpenVPN site has a full reference on using Ethernet bridging with your VPN.
Finally, if your ISP does not block IPSec traffic, consider learning Openswan and setting up an IPSec VPN. Using IPSec has the advantage that all application layer and all TCP and UDP traffic can use it without alteration. Properly setting up an IPSec VPN is complex, perhaps too much for a home network, but that shouldn’t stop you from exploring it. Who knows when you’ll need yet another VPN option in your tool belt?
