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:
Same functionality as IPsec in tunnel mode: you can tunnel entire networks (IP tunnel or bridging tunnel).
A Windows XP/2000 install.exe file with a GUI is available for starting the tunnel. The config files are text based.
The OpenVPN server can push routes, DNS server IP addresses and other configuration details to the clients. This makes OpenVPN well suited for road-warrior setups, because you can modify the setup without touching far-away laptops.
You can use a bridging or routing setup.
The server/client code is the same: the config determines the role.
SSL is as solidly proven as security protocols get, using RSA public key cryptography if you want. See this paper for more information on its security setup.
OpenVPN costs you nothing in terms of money--a server, an Internet connection and know-how is all you need).
All encryption processes are handled in userland, meaning it is easy to install--much less complicated than IPsec.
The list of cons includes:
The setup uses TUN/TAP devices. This can make things complicated to figure out when things go wrong. If Microsoft changes its code, it also might just break.
The OpenVPN process is executed in userland and, thus, is relatively slow. TUN/TAP devices combine together with a userland-process to create a setup in which traffic has to cross userland/kernel borders relatively often. This setup might create rather high latency on connections.
A packet overhead is present because IP/Ethernet is encapsulated in SSL and SSL in UDP/TCP.
The latest version OpenVPN is beta; earlier versions have further drawbacks.
Who can you call when things go wrong? Some companies want to pay to get support.
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.
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.
The OpenVPN server itself, of course, could be attacked. You can minimize that risk by:
Using shared keys with the tls-auth option before public key exchange occurs. Doing so keeps people from exploiting the SSL setup, should this be possible.
Setting options user nobody and group nobody. This makes sure the server does not run as root. You also can use a chroot-jail.
Using a separate box in a DMZ. This way a successful hack is slowed down by the firewall protecting the internal network from the DMZ. Strange connects can be noticed in the firewall logging.
By using iptables firewall rules on the OpenVPN server that prevent traffic from tunnel hosts entering the server, as well as all traffic from the Internet except for the need UDP traffic.
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.
The network setup my configuration files is aiming for is this:
The OpenVPN server at 65.66.45.x.
The client is somewhere on the Internet.
The client/server P2P network is 192.168.100.0/24 or, rather, a /32 network in that network.
The company-network behind the OpenVPN server is 172.16.1.0/24.
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.
- New Products
- Android Candy: Google Keep
- A Little GUI for Your CLI
- Readers' Choice Awards 2014
- Handling the workloads of the Future
- How Can We Get Business to Care about Freedom, Openness and Interoperability?
- diff -u: What's New in Kernel Development
- Days Between Dates?
- December 2014 Issue of Linux Journal: Readers' Choice
Editorial Advisory Panel
Thank you to our 2014 Editorial Advisors!
- Jeff Parent
- Brad Baillio
- Nick Baronian
- Steve Case
- Chadalavada Kalyana
- Caleb Cullen
- Keir Davis
- Michael Eager
- Nick Faltys
- Dennis Frey
- Philip Jacob
- Jay Kruizenga
- Steve Marquez
- Dave McAllister
- Craig Oda
- Mike Roberts
- Chris Stark
- Patrick Swartz
- David Lynch
- Alicia Gibb
- Thomas Quinlan
- Carson McDonald
- Kristen Shoemaker
- Charnell Luchich
- James Walker
- Victor Gregorio
- Hari Boukis
- Brian Conner
- David Lane