If your company has people on the road, such as sales or technical people, a VPN is a good method for letting them access data on the company network. Many different VPN solutions can be bought, but many are free. Here, I discuss only solutions you can set up without buying a commercial VPN product.

The main VPN solution used for more complex tasks is IPsec; some people use PPTP. Although PPTP is usable, security flaws have occurred in its past, and it simply does not match up to IPsec.

IPsec in tunnel mode would be a much better solution, were it not for the crippled Windows-client implementation: Windows XP/2000 clients can't use IPsec in tunnel mode without using L2TP. There is nothing wrong with L2TP security-wise, but it increases latency--through the need for both PPP and L2TP processes--and increases packet-overhead, slowing down connections. Open-source servers have not had much experience with L2TP yet, so using open source for it is problematic at this time.

A disadvantage of plain IPsec is its notorious complexity: many, many things can and do go wrong. To the rescue, then, comes OpenVPN, a full-blown open-source VPN solution based on SSL. OpenVPN offers the same functionality as IPsec in tunnel mode; you can tunnel entire networks through it. In this article, I focus on using OpenVPN as a road warrior's VPN solution.

Every VPN approach has its list of pros and cons. The pros of OpenVPN are:

The list of cons includes:

Considering these arguments, OpenVPN should be a serious option if you are setting up a VPN. The days when only money could get you a decent VPN definitely are over.

The rest of this article is a guide to setting up a road-warrior scenario using routing, not bridging, with TUN devices. Its aim is to make sure laptops on the Internet can connect safely to companies' networks, using internal servers and data.

The basic HOWTO I drew on when writing this article can be found here. It is a HOWTO for setting up OpenVPN in bridging mode on a Linux SME-server. My setup is slightly different, because I do not use a bridging setup. Another good source is the OpenVPN HOWTO.

The Security Setup

Anyone setting up a VPN without considering the different kinds of security risks one faces is a fool. Therefore, you should start any VPN setup doing exactly that--considering security.

Connection Security

OpenVPN traffic flowing over the Internet is protected by TLS. The setup here uses public key exchange; computer authentication is done by RSA-based public/private key-pairs (public keys also are called certificates). In this setup we make our own root certificate; that is, for our VPN scheme, we are our own Verisign, so to speak. We are the root of the Web of trust here. We make a server key pair and multiple client-key pairs. We sign those with our own root certificate. This setup is this basic cryptography design of OpenVPN.

The SSL/TLS connection is set up up with those keys. After authentication is done, Diffie-Hellmann encryption is used to exchange keys to set up the connection. New keys are negotiated every hour using perfect forward secrecy, or PFS--the next key used is not derived by using the former key. By default, the connection uses 128-bit Blowfish in Cipher Block Chaining mode, with SHA1 message digests.

Server Security

The OpenVPN server itself, of course, could be attacked. You can minimize that risk by:

Authentication of Users

The security setup of your client laptops is critical. If your road warriors are using laptops and can access your company's network, your data may become public in the future. No matter how good the SSL crypto, this is a separate risk. If a laptop can connect through an OpenVPN tunnel directly into your networks, you have a problem. To avoid this, you need to establish authentication of the user to the laptop or to the SSL keys.

Many ways exist to do this authentication. You can password-protect the SSL keys of the client, which is recommended. But if workers have the habit of writing down passwords near their laptops, password protection is not sufficient. An option is to get USB-based iKeys with a pincode that holds the client keys. Pincodes are easier to remember, so the need to write them down is smaller. Of course, the iKey should be carried on a keychain and not with the laptop itself. You should establish an AUP (acceptable user policy) to make sure all users understand this. Doing so may prevent a stolen laptop from becoming a disaster. In addition, you might use encrypted filesystems on laptops.

Another option is to set up your own custom authentication scheme. For instance, you can use strong authentication with hardware tokens, coupled with a Kerberos server. OpenVPN has the script hooks to do that. You also can use the server password file.

Network Setup

The network setup my configuration files is aiming for is this:

So, the internal mailserver of this company might be at 172.16.1.3, the DC at 172.16.1.5 and the fileserver at 172.16.1.6. Schematically, this setup looks like this:

CLIENT -> [modem/adsl-router] -> Internet <-UDP-> OpenVPNserver 
CLIENT - TUNInterFace <=tunnel=> TUNInterFace ==> Internal network
CLIENT - 192.168.100.6 <=======> 192.168.100.5 <==> 172.16.1.0

I am using a Linux SME-server, which basically is a Red Hat system stripped down to what a file/printer/firewall/e-mail server needs, with a Perl/HTTP-based config panel. After being a problematic open-source project for a while, Linux SME-server is being developed further by Lycoris. I have used Linux SME-server for years and will migrate only if forced to--it is extremely easy to use.

Installing OpenVPN is easy to do. On the Linux server side, you must install one or two RPMs. On SME these RPMs are lzo.xxx.rpm and openvpn-2.0_beta17-1.i386.rpm. Most systems already include lzo. Your kernel should include TUN devices, most kernels do. If you run openvpn from /usr/sbin/openvpn, you should find a TUN device. With the settings we are going to use, it has a P2P connection.

The config file on my box is saved at /etc/openvpn/server.conf, but yours may be stored somewhere else. My server configuration file looks like the output shown below; see the man page to see what all the items reference. they mean):

###OpenVPN server config routing TUN setup########
port 1194
dev tun
tls-server
mode server
dh dh1024.pem
ca ca.crt
cert SERVER.crt
key SERVER.key
duplicate-cn
ifconfig 192.168.100.1 192.168.100.2
ifconfig-pool 192.168.100.5 192.168.100.200 # IP range clients
mtu-test
tun-mtu 1500
tun-mtu-extra 32
mssfix 1450
#keep tunnel open by ping
push "ping 10"
push "ping-restart 60"
ping 10
ping-restart 120
#route to be established on the server
route-up "route delete -net 192.168.100.0/24"
route-up "route add -net 192.168.100.0/24 tun0"
#route to push to clients
push "route 172.16.1.0 255.255.255.0" #route to company network
push "dhcp-option DOMAIN hansceess.net"  #push the DNS domain suffix
push "dhcp-option DNS 172.16.1.7"  #push DNS entries to client
push "route 192.168.100.1" # add route to protected network
comp-lzo
status-version 2
status openvpn-status.log
verb 5
####################### end server config ##############

On the Windows client side, you should download the Windows installer and run it. The normal installer is available on the OpenVPN Web site, while and the GUI version can be found here. I recommend using the latter: it gives you a tray-icon with which you can start the OpenVPN service. In the Network connections window under Settings, you should find a tap win32 adapter. You also should see that adapter in your routing table when you type route print in a DOSBox.

After the setup has installed everything, you should adjust the config settings in D:/Program Files/OpenVPN/config/*.ovpn to those you want. You might want to tune your personal firewall as well, if it sees the interface at all--mine didn't. My adjusted settings file looks like this:

####################client.ovpn######
port 1194 #udp by default
dev tun
##remote is the openvpn-server
remote 65.66.45.x
tls-client
ca ca.crt
cert CLIENT.crt
key CLIENT.key
mtu-test
tun-mtu 1500
tun-mtu-extra 32
mssfix 1450
pull
#ip-win32 ipapi|manual|dynamic|netsh (see man page, use 
#when ip address on interface does not appear, but dhcp server 
#is visible in ipconfig /all)
#ip-win32 ipapi
comp-lzo
verb 4
##############################end########

The OpenVPN process on the client is a Windows service you can start with a script or with the GUI, if you want. The TAP device (in tun-modus) can be tcpdumped, as can any interface, which makes it nice when troubleshooting. The rest of the configuration comes from the server.

You can make keys for OpenVPN in the same way as you would make them for OpenSSL. But for those who like comfort, OpenVPN has an easy RSA set of scripts to help you out. You first must edit some variables in the vars file for the keys: names for server/clients keys, your company name, e-mail and so on. Next, run ./build-ca to build your root private key. Then, run ./build-key server to build the server key pair. Build the client key(s) with ./build-key client. In this client step, you can add a passphrase in the keys for key-authentication, as discussed above. Finally, you must run ./build-dh to generate the Diffie-Hellmann .pem file that the server needs. This file holds a large prime number and another parameter (see this article for details). Using these numbers, the server can generate new keys quickly, which it does every hour by default for standing connections.

You also need to copy the server keys, root certificate and *.pem file to /openvpn. The client needs the client keys and the root certificate. These should be transported over a secure medium, such as winscp.

There is one thing left to do: get the firewall iptables rules on the server. The rules I added were:

#  internet interface eth1 let OpenVPN udp port in
    /sbin/iptables --append INPUT -p udp --dport 1194 -m state --state     NEW -i eth1 -j ACCEPT
#block anything into the server from tun interface
	/sbin/iptables --append INPUT -i tun0 -j DROP 
#tun0 debugging
    #/sbin/iptables --append INPUT -i tun0 -j LOG --log-prefix     tun0-input 
	#/sbin/iptables --append OUTPUT -o tun0 -j LOG --log-prefix tun0-output 
	#/sbin/iptables --append FORWARD -i tun0 -j LOG --log-prefix Forward-ComingFrom-Tunnel 
	#/sbin/iptables --append FORWARD -o tun0 -j LOG --log-prefix Forward-OutTo-Tunnel

#OpenVPN Forward chain: if you have a Tun-device, the forward chain 
#screens traffic from networks/hosts outside the tunnel, going to 
#internal networks and back. we want this traffic to go through, 
#default but first we might want to block some things: remember, the 
#other side of the tunnel is not safe by default: he could be routing 
#so we should log syns at least coming in
	/sbin/iptables --append FORWARD -i tun0 -m state --state NEW --jump LOG --log-prefix Tunnel_into_intranet
#you should know the networks allowed in and out through the tunnel
#let client network in.
	/sbin/iptables --append FORWARD -i tun0 --source 192.168.0.0/16 -j ACCEPT 
#let company network out
	/sbin/iptables --append FORWARD -o tun0 --source 172.16.0.0/16
 -j ACCEPT
##troubleshoot: let all through
#	/sbin/iptables --append FORWARD -i tun0 -j ACCEPT
#	/sbin/iptables --append FORWARD -o tun0 -j ACCEPT
#you might want to allow some, but not all
#	/sbin/iptables --append FORWARD -i tun0 -p tcp --dport 25 -j ACCEPT
##drop the rest
	/sbin/iptables --append FORWARD -i tun0 -j DROP
	/sbin/iptables --append FORWARD -o tun+ -j DROP

Once you have installed OpenVPN, it is time to test it. Make sure the server process is started with service openvpn [re]start. You should see the TUN device with ifconfig. With my config, it shows:

Link: encap:Point-to-Point Protocol 
Inet addr:192.168.100.1 P-t-P 192.168.100.2.

Now, start up the client OpenVPN service. A file found at D:/Program Files/Openvpn/*.log contains debugging information. With the verb setting, you can elaborate the logging. When you start the client service, the icon in your tray shouts it is connected. Ipconfig /all in a DOSBox shows an IP address on the tap interface, for instance, 192.168.100.10

Ethernet adapter Local Area Connection 8:

	Connection-specific DNS Suffix  . : 
	Description . . . . . . . . . . . : TAP-Win32 Adapter V8
	Physical Address. . . . . . . . . : 00-FF-CF-10-9F-A6
	DHCP Enabled. . . . . . . . . . . : Yes
	Autoconfiguration Enabled . . . . : Yes
	IP Address. . . . . . . . . . . . : 192.168.100.10
	Subnet Mask . . . . . . . . . . . : 255.255.255.252
	Default Gateway . . . . . . . . . : 
	DHCP Server . . . . . . . . . . . : 192.168.100.5

print route gives you some routes:

192.168.100.1  255.255.255.255    192.168.100.9               4	  1
192.168.100.8  255.255.255.252   192.168.100.10               4	  1
192.168.100.10  255.255.255.255    127.0.0.1       127.0.0.1	  1
192.168.100.255  255.255.255.255   192.168.100.10               4	

Although this all may look quite odd, it works. You now can ping 192.168.100.1; if that succeeds the tunnel is okay. On the server you can see the pings coming in with tcpdump -nlpi tun0. Also, tail -f /var/log/messages supplies some information.

The routes on the server look something like this (netstat -rn) kernel IP routing table:

Destination  	Gateway     Genmask          Flags   MSS Window  irtt Iface
192.168.100.2 	0.0.0.0     255.255.255.255  UH        0 0         0  tun0
192.168.100.0	0.0.0.0     255.255.255.0    U         0 0         0  tun0
65.66.45.2    	0.0.0.0     255.255.255.0    U         0 0         0  eth1
172.16.1.0    	0.0.0.0     255.255.255.0    U         0 0         0  eth0
127.0.0.0     	0.0.0.0     255.0.0.0        U         0 0         0  lo
0.0.0.0      	65.66.45.1  0.0.0.0          UG        0 0         0  eth1

If all goes well, your connection should be there. If not, check the server routing table and tcpdump the TUN interfaces. You also can use the iptables debug rules.

In this article I have shown a simple setup for a OpenVPN. In real life, the setup will not be much more complex. Although the security implications of any VPN should be well thought-out, setting up OpenVPN turned out to be rather easy. If you do get into trouble, plenty of helping hands can be found on the mailing lists.

OpenVPN is a serious VPN product. It can contend with IPsec in many ways. It certainly is cheap--try buying a Cisco concentrator--easy to install and, in the open-source tradition, tinkerable.

If OpenVPN has a disadvantage, it might be latency. However, no real-life data exists yet to back up that claim.

"Exchange Functionality on Linux"

"VPN Implementation in Cluster Computing"