Creating VPNs with Linux

Virtual Private Networks (VPNs) are a cost-effective,
relatively secure means of transporting data between a number of connected points. And Linux can be
used quite easily to set up and administer such a network. Using simple tools created by the folks
at LinuxCare, someone with a basic Linux background can set up and maintain a VPN for either
corporate or personal use.

What is a Private Network?

Figure 1

A private network is a network of computers that is not accessible to the outside world. A
corporate WAN is usually a good example of a private network. Let’s look at a fictional company
called BigCo, illustrated in Figure 1. They have four campuses, one in New York, one in London, one
in Miami, and one in San Francisco. Each campus has its own LAN, which means that people on one
campus can communicate with other people on the same campus. In addition, there are dedicated
communications lines be- tween each office and the New York office. These dedicated lines are
usually leased lines, or frame relay connections that are “circuit-switched” — in other words, it’s
as if they’re just fast telephone lines connecting any two campuses to each other. These
circuit-switched lines are considered private — only company data is passing over them. One trouble
is that these dedicated lines are very expensive, especially when they involve transoceanic
distances. They are also very inefficient, because they are only used when there is company data to
go over them, which means that every millisecond they are not being used is money lost. Lastly,
these circuit-switched networks are vulnerable to wiretapping — if a sinister force were to put a
physical tap on a dedicated line, the company’s data would be at risk, since it is generally sent
over the line in the clear.

Virtual Private Networks

So, while private networks provide a seamless network across multiple campuses, they are
expensive, inefficient, and in reality, aren’t all that private. And in addition due to the price of
the leased lines, it is very expensive to link offices to each other — it is much more
cost-effective to have what is shown in Figure 1 — a “hub-and-spoke” network. In this type of
network, all packets must go through some central site (the New York office in this example) in
order to go from one side of the network to the other. Unfortunately, this creates more inefficiency
and a possible single point of failure for the network. The answer to all of these problems is to
use a packet-switched network like the Internet to connect all of the offices. This means that each
office only needs to get a local Internet connection — then each office can communicate directly
with each other office on the network — a Virtual Private Network, as shown in Figure 2.

Figure 2

A virtual private network is a private network that runs over a public, packet-switched medium.
From each campus’s point of view, they have a private connection to each other campus. However, the
packets traveling from one campus to the next are sent over a public network — the Internet — and
they are sent encrypted so that someone eavesdropping would not be able to make sense of that was
being communicated.

In this example, each office gets a low cost connection to the Internet, then establishes a
“tunnel” connection between itself and each of the other offices. A tunnel connection is a network
connection between two campuses that passes securely encrypted packets as data. The true data
packets are unencrypted and authenticated by the two machines at the endpoints of the connection,
and the true data is passed along to the internal machines on the campus. The packets that are sent
over the Internet effectively create a hard wrapper around the true data — protecting it against
the big bad world of the public network.

So, How Is It Done?

The tunneling concept can be implemented in numerous ways. It’s difficult to do each justice
without going into a deep technical discussion. Without descending to the details of the protocols
involved, I’ll mention the most popular alternatives and the strengths and weaknesses among them. If
you’re interested in learning more about the nitty-gritty, see the list of references in the sidebar
below.

The first method used is PPTP. This is a protocol that was originally developed by the folks at
Microsoft as an extension to PPP that assisted in the encryption of packets sent over the wire. It
comes bundled with NT 4.0 and Windows 95 and 98 with DUN 1.2or greater. Unfortunately, PPTP wasn’t
designed very well from a security point of view. It has several drawbacks, the biggest of which are
its lack of dynamic re-keying (changing cryptographic keys in mid-stream to enhance cryptographic
security) and that it is possible to sniff passwords during session setup. The latest invocation of
PPTP (DUN 1.4) has fixed some of these problems, but others remain.

The second method used is IPSec. It is an open standard, designed under the direction of the
IETF. It takes some of the security methods that have been developed for IPv6, the next generation
IP, and applies them to current IPv4. Since it has been developed completely in public, under public
scrutiny, it is quite strong and has no obvious flaws. The goal of the IETF is to make IPSec an
open, inter operable standard for secure communications. There are two problems with IPSec, however.
The first is that the current IPSec implementation for Linux is a kernel module, and is still beta
code. I do expect that the code will continue to improve and in time will be rock solid. The second
problem is that the IPSec protocol currently only supports a limited number of cryptographic and
authentication mechanisms, and vendors are still working out inter operability problems in regular
“bake-offs”. While I believe that IPSec (and it’s bigger brother, IPv6) is the way of the future,
I’m concerned enough with it right now to support an alternative until IPSec is ready for prime
time.

That alternative is running PPP over an encrypted ssh connection. PPP is a standard method of
communicating packets over a serial (usually modem) connection. ssh is the secure shell, an open
source cryptographic product that has been analyzed for years by many of the top cryptographers in
the world. By running PPP over a securely encrypted ssh connection, you get the best of both worlds
– a stable tunneling mechanism that is not kernel code running PPP, which means that you can tunnel
multiple protocols over the connection, and not just IP! The PPP software that comes with most
modern Linux distributions has capabilities for sending IP, IPX, and AppleTalk over the link.

Setting up Your Own VPN with Linux

Linux comes with many of the raw materials you need to set up, use, and administer a VPN. It
already supports PPP in the kernel. Networking support, both for TCP/IP, IPX and AppleTalk is quite
solid. The scripting languages available at your disposal are well-suited to the task at hand. And
as such, there are at least two ways that you can set up a VPN on Linux with PPP over ssh. One way
is described by Arpad Magosanyi in the VPN Mini-HOWTO, which is in the sidebar at left.

He describes a scripted approach to setting up a VPN, using a similar technique to the one I’ll
describe in this article. Another method is to use SecureVPS, the Virtual Private Server, that
myself and some of the folks at LinuxCare wrote, in order to make the process of setting up the VPN
as quick and painless as possible. It incorporates a GUI to set up the VPN, and automates the
process of creating and managing VPNs. It is released under the GPL.

To get SecureVPS, first you’ll need the following installed on each VPN server:

* ssh 1.x (the current version of ssh is 1.2.26. I don’t recommend using the ssh 2.0.x series
yet, for stability and licensing reasons)

* perl 5.004 or greater

* PPP support available to the kernel (either built-in or as a module)

Installing SecureVPS is pretty easy. Download the RPMs or the tarballs from the website
(http//:www.strongcrypto.com/) and install them. Some people have experienced trouble getting the
Perl/Tk RPMs working, so you may need to rebuild them for your system — either use the SRPMs or use
the tarball to build them from source.

Figure 3

Once everything is installed, SecureVPS is installed in /usr/local/ bin/vps2.0 — so if
/usr/local/bin is in your PATH, type in vps2.0. The main configuration screen should appear
[see Figure 3].

SecureVPS uses configuration files that are normally saved in the /etc/vps directory on
each VPN server. The two main types of files that are stored on each VPN server are key files and
tunnel configuration files. A key file is a file containing one half of a cryptographic key — both
halves are needed to secure and authenticate a connection. There are public key files, which are put
on the receiving end of the VPN connection, and there are private key files, which are kept on the
originating VPN server. By default, the private key files are kept in /etc/vps/ keys on the
local server, and the public keys are kept in the /root/.ssh/ authorized_keys file on the
remote server. You can load and save configuration files from the File menu, and you can create and
modify tunnel configurations from the Configure menu [see Figure 4].

Figure 4

The tunnel configuration files are straight ASCII files — there’s a sample configuration file
that comes with SecureVPS that has further explanations on each of the configuration commands and
their meanings. Basically, when setting up a tunnel, you need to create pseudo- or ghost-network
addresses that represent the two endpoints of the tunnel. Usually, I use a private network like
192.168.x.x at each endpoint — this allows us the potential to fully mesh 253 different locations
without changing the network architecture.

Figure 5

The last point is that you may need to add static routes to each endpoint’s system so that it
knows to route packets for tunneled networks through the tunnel instead of the default gateway.
These routes get added into a file called /etc/ppp/ip-up-NAME at each end of the connection
where NAME is the tunnel name. This allows for the addition and deletion of the routes whenever the
tunnel is brought up and down. Once you have configured a tunnel or two, you can start it by
clicking on Manage Tunnels in the Configure menu [see Figure 5].

You have to create a new keyfile by selecting the tunnel and then clicking on the New Key
button. Once you’ve created the key, you have to put the key on the remote server. You can do this
by putting the key on a floppy or other medium and installing it on the remote server, or you can do
it the easy way by selecting the tunnel and clicking on the Check or Add Routes button. You’ll be
prompted a few times for the root password of the remote server, and walked through the process of
installing the key on the remote system. Once the key is installed in the remote system, simply
select the tunnel, and click on the Start Tunnel button. That should bring up the tunnel and
automatically add the routes you specified in the configuration file. To bring down a tunnel, simply
select the tunnel and click on Stop Tunnel.

That’s all there is to it. SecureVPS gives network administrators an easy-to-use GUI interface
that sets up and manages Virtual Private Networks. We’ve had tunnels that have been in use by our
clients for months at a time,and they’re very happy with the performance and reliability of a system
based around Linux running on an Intel box. We find that an otherwise unloaded Pentium 233-class
machine can handle the encryption and authentication responsibilities of a T1 (1.54 Mb/s). Another
benefit of using PPP over ssh is that we use data compression before encryption, which can result in
a 2-3x speed increase over using uncompressed, unencrypted connections for certain types of files.
The only drawback of using an Linux-based VPN over the Internet is one of latency — for
applications that are latency-dependent, only a leased line or frame relay connection will do. This
isn’t a Linux-specific problem, but a problem for all packet-switched VPNs. For most applications, a
Linux-based VPN is a great, low cost, robust solution.

David Sifry is a dedicated Linux hacker, managing several projects including SecureVPS and
CareTracker. He was involved in the development of emacs, packetrace, and majordomo. He can be
reached at dsifry@linuxcare.com.