OpenVPN Locks Down the WLAN
February 17, 2005
Why worry about WEP, WPA, or PPTP when OpenVPN provides free, open, SSL-powered security for your wireless network? Here's how to set it up and connect a Windows client.
Wireless security is in a state of flux. WEP (define) is nearly universal, but weak, and a pain to administer (see Making the Most from WEP). WPA (define) is stronger, but new enough that most wireless devices do not have it. Some can be upgraded by flashing the firmware, but for the purposes of this article we don't care, because we're going to pretend that WEP/WPA do not exist and not use them.
OpenVPN on a Linux box provides a secure, reliable way to set up a point-to-point encrypted tunnel for the wireless Windows clients on your company LAN. All traffic over the link is encrypted. You won't have to bother with WEP or WPA at all. This article is going to focus on configuration, and not much in the way of explanations -- to get the hows and whys, read the comments in the configuration files, and the links in Resources.
These are standard programs that should already be included with your distribution, or are readily available from your usual package repositories. Source tarballs are available from the home pages of each program:
And of course OpenVPN itself. It is available in all the usual package repositories and source tarballs. If you build from sources, be sure to include ~~enable-pthreads. This will help get the best performance, as OpenVPN does a lot of multi-threading.
Kernel TUN/TAP Follies
A vital element is kernel support for TUN/TAP devices. Unfortunately, some distributions such as Debian ship without this enabled, which means you'll have to build a new kernel or loadable kernel module. Check your kernel configuration file:
$ grep TUN /boot/config-2.4.26
# CONFIG_TUN is not set
Drat. What you want to see is CONFIG_TUN=m or CONFIG_TUN=y. When configuring the new kernel, look for "Device Drivers -> Networking Support -> Universal TUN/TAP device driver support." Save yourself some hassles and build it into the kernel, rather than as a module.
Configuring SSL and Generating a Certificate
We're going to use our own self-generated Certificate Authority (CA) instead of static keys. Static keys are easier to set up, but using a CA allows better client administration and scalability. We'll use the handy easy-rsa scripts that comes with OpenVPN to create a certificate and server and client keys.
Find your openvpn/examples/easy-rsa/openssl.cnf file and edit it to include your own site information: countryName, stateOrProvinceName, 0.organizationName, commonName, and emailAddress. This file provides defaults that are applied to new keys, and can be overridden on the command line when you create new keys.
Now change to the openvpn/examples/easy-rsa/ directory, and open the vars file for editing. In the top section define the directory for storing your new keys and certificates:
Then skip to the bottom section and enter your own site information. Then run the syntax checker:
# . vars
NOTE: when you run ./clean-all, I will be doing a rm -rf on /usr/share/doc/openvpn/examples/easy-rsa/keys
That means there are no syntax errors. If you see any other messages you made a mistake, and must correct it before proceeding. Heed the above warning -- openvpn/examples/easy-rsa/keys will be cleaned out, so don't use it for permanent key storage.
Next, create the new master certificate:
This creates four files: ca.crt, ca.key, index.txt, and serial. Only .key files need to be protected and kept confidential.
Now you must create the Diffie-Hellman parameters. This is necessary only on the server:
This creates keys/dh1024.pem.
Next, create a server key pair, which you may name whatever you like:
Do not add "a challenge password" or "an optional company name" when asked. Then create a client key pair:
Now you should copy all the keys and the .pem file to your desired location, such as /etc/openvpn/keys.
OpenVPN Server Configuration
This is the easy and fun part, especially if you've ever become mired in trying to set up an IPSec-type tunnel, such as FreeS/Wan. IPSec is horridly complex and demoralizing to administer, which is not good for a security product. The easy way is to find the sample openvpn/examples/sample-config-files/server.conf and edit it to suit. Most LAN wireless access points are Ethernet bridges, like in our Build A Linux-Based Wireless Access Point series, so do this:
#bridge IP plus a pool of client IPs
server-bridge 192.168.1.5 255.255.255.0 192.168.1.100 192.168.1.150
push "dhcp-option DOMAIN carlasdomain.net"
push "dhcp-option DNS 192.168.1.6"
Uncomment the entries for user nobody and group nobody. Even better is to create a unique, not-shared unprivileged user and group just for OpenVPN and use them instead of the over-used "nobody."
In the "# SSL/TLS root certificate" section, enter the file paths to your certificates and keys.
In the "# Diffie hellman parameters" enter the path to your .pem file.
Comment out the "server" line when using an Ethernet bridge.
You may leave the rest of the defaults in place or tinker to suit. Now start up OpenVPN:
# /etc/init.d/openvpn start
Download and install the Win32 client from SourceForge. Double-click to install, then copy the client keys and CA- ca.crt, wireless-client.crt, wireless-client.key - to C:/Program Files/OpenVPN. Then edit C:/Program Files/OpenVPN/config to include the IP of the access point and the names of the keys:
Then -- what else -- reboot. Then check that the TAP interface is up:
Description . . . . . . . : TAP-Win32 Adapter V8
Assuming your wireless adapter is up, you should be able to ping LAN resources from the client, and ping the client from the LAN, and then connect to LAN resources just like a wired client.
Networking and Firewalling
You may configure any type of routing and subnetting you like, just like with plain old wired Ethernet. It is a short step from using OpenVPN on the LAN to building tunnels over the Internet for remote users and road warriors. The OpenVPN Howto contains a number of great iptables examples, plus how to use routing instead of bridging.