Meet OpenVPN |
 |
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).
Plenty of
man pageand
HOWTOs are available
to get you going.
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.
Setting Up an OpenVPN (Routing) Scenario
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:
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.
Network Setup
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.
OpenVPN Server Install
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):
Client Install
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:
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.
Making RSA Keys
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:
Testing
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.
Conclusion
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.
