This series of articles covers the development of a Linux-based server
to support a number of workstations running the Microsoft Windows
operating system in the computer laboratory of a 55+ RV Resort in Mesa,
Arizona.
Part I and
Part II covered
the background of our organization, the establishment of our Linux system,
the rules for our iptables firewall and network functions such as IP address serving, a cache-only name
server, an Intranet Web server and print and file services using
the service-message block (SMB) protocol. This article describes the
implementation of a virtual private network (VPN) server, which we built so our
wireless users can encrypt their transmissions over an unsecured network.
Wi-Fi System
The owners of Mesa Regal have supplied the computer lab with superb
equipment, and the resort is being wired with Wi-Fi hotspots that should
make it possible for all residents to have free broadband access from
their RV sites. Some locations will require high-sensitivity antennas, but
the capability will be there. For comparison, most RV resorts that have
Wi-Fi capability charge $20 - $30 per month for it. In the campground where
we are residing as I write this, access is $25 per week! The main
problem is the owners require the network to be unsecured, despite all
recommendations to the contrary. Although most, if not all, sensitive
communications use SSL, many of our members are reluctant to divulge
any information over an unsecured channel. To provide security for them,
I have implemented a VPN server that provides encrypted tunnels from
the user to our Linux machine.
VPN Technologies
Mick Bauer (see Resources) recently published a complete description
of VPN technologies for Linux. Unfortunately for me, that article was
published after I had finished my setup, but it is an excellent
starting point. In that article, he describes the two different needs
addressed by VPNs. His first case, which allows users to connect to
a private network using an encrypted connection through an untrusted
medium, describes our situation. Once the data has reached our server
and is on the wired network, it is treated exactly the same as material
originating from one of the workstations in the computer lab.

For connecting Windows workstations to the Linux server, we could use
the IP Security (IPSec) protocol, which is highly secure. This method,
however, requires digital certificates and could not be implemented
easily on the many user machines that can be expected to connect through
the VPN server once the Wi-Fi network has been implemented fully. Our
other option is the Point-to-Point Tunneling Protocol (PPTP) designed by
Microsoft and built into all the recent Windows OS releases. In addition,
clients are available for Mac OS X and Linux. Although this protocol
has serious security problems, as described by Schneir and Mudge (see
Resources), v2 of this method is secure enough for our purposes and can
prevent interception by the casual hacker. A determined professional
would be able to crack our network; however, I doubt that we have any
information that would be worth the effort.
Implementing PPTP on Linux
To implement the PPTP server on Linux, I chose the PoPToP package,
v1.2.1 currently maintained by James Cameron (see Resources). This
package consists of a daemon that listens for a connection request on
port 1723. When one arrives, it spawns a process to make a Point-to-Point
Protocol (PPP) connection back to the originating computer. This process
also assigns the IP numbers to be used for both the client and server
ends of this connection. Once our Wi-Fi network is implemented, the
overhead of these various processes and the data encryption/decryption
may overwhelm our server. In that case, a separate machine is be
required. At the moment, we still have plenty of compute power available
to use a single host for all of our services.

The PoPToP package is not a standard feature of the SuSE distribution.
Therefore, I had to download the source package from the Web site, unpack
and configure the software, build the package and install it. These
steps are standard for most software for Linux and are described in the
material contained with the package. In short, they require only a few command-line
entries, and only the installation step requires superuser privileges. The
package also requires that the kernel modules associated with PPP
be available. In particular, ppp_mppe.ko, which handles Microsoft
Point-to-Point Encryption (MPPE), is needed. Additional modules handle
the RC4 cipher used by this method. As long as the default
kernel from the SuSE distribution is used, all necessary modules should
be present.

A user that generates a custom kernel, however, has to take some
care when doing the configuration step. In particular, all PPP and all
cryptographic options should be selected. I have done it both ways;
the computer lab system uses the SuSE default, but my test system at
home has a custom kernel that was self-generated. It also is possible
to incorporate Microsoft Point to Point Compression (MPPC). The kernel
must be patched to employ this option, though, which probably is more
effort than it is worth.
PPTPD Configuration
When configuring the VPN software, three configuration files
need to be established. The first is /etc/pptpd.conf,
which controls the operation of the PPTP daemon. The default values are
correct for many of the parameters. In our case, only four parameters
need to be defined: the path for the PPP daemon, the path for the
PPP options file, the IP number for the PPP server and the IP
number range for the PPP clients. The values that have been defined in
my configuration are as follows:

ppp /usr/local/sbin/pppd      # this tag defines the path of the PPP daemon
option /etc/ppp/options.pptpd # the path for the pppd options file
localip 10.10.100.1           # the IP number for the PPP server
remoteip 10.10.100.100-199    # the range of IP numbers for the clients

This set of parameters configures the network 10.10.100.x for the IP
addresses of the VPN tunnels, with 10.10.100.1 as the IP address of the
server. The standard configuration for PoPToP allows for 100 simultaneous
clients, which is covered by the range specified with the remoteip
tag. Please note that any firewall rules must account for this extra network.
In our network layout, the traffic from the VPN client to the server
enters by way of the external interface and is routed back out through
that same interface on the way to the Internet.

Our options for the PPP daemon are minimal. An unencrypted connection
makes no sense; therefore, we require Microsoft Point to Point Encryption
(MPPE). In addition, the client must utilize v2 of the Microsoft Challenge
Authentication Protocol, MSCHAP- V2. The resulting options.pptpd file
contains the following information:

require-mschap-v2                # required authentication method
require-mppe                     # MPPE encryption required

One note of caution: several versions of the PPP daemon are available
and they have different sets of commands. In fact, the software on my computer
did not match the man pages. I had to read the command parser section
of the code to determine the proper commands to use.

The final configuration file, /etc/ppp/chap-secrets, needed to implement
the VPN server contains the user IDs and the secrets (passwords) needed
for CHAP. As each of our members has a user number and password for
printing, it seems reasonable to use those values as the basis for VPN
authentication. The first few lines of that file are as follows:

# /etc/ppp/chap-secrets file for MRCC VPN connections
# client    server  secret   IP Address
    0         *     xxxxx       *
    1         *     yyyyy       *
    2         *     zzzzz       *

The four fields of each line of the file contain, in order, the client
identifier, or the user ID; the server name, an * allows all servers;
the secret; and the IP address for this connection. The *
allows the PPTP daemon to select the address. Two things should be noted here.
First, CHAP is designed to connect computer systems, not users; however,
we ignore this point and use user names and passwords. Second, the
server/client roles are reversed for PPP--the PPTP server becomes the
PPP client. It also is important to note that VPN users do not need
login accounts on the Linux server.

To test if the encryption/decryption processing slows network
traffic, I ran one very crude test. When downloading a Linux kernel
source file from www.kernel.org, the speed of both the open and VPN
links was determined by the T-1 line, without any noticeable slowdown
for encryption.
Resources
"Linux in a
Windows Workstation Environment, Part II

"Linux in a
Windows Workstation Environment, Part I

"Linux VPN
Technologies", Mick Bauer, Linux
Journal, February 2005, Issue 130, pp. 30-35.

The
IPSec Protocol

An analysis of
PPTP v2 and links to other sites discussing PPTP security
problems

PoPToP, the PPTP Server for
Linux

The Mesa Regal Computer Club Home
Page

Larry Finger is retired from the Carnegie Institution of Washington,
Washington DC, and currently is the volunteer technical advisor for
the Computer Club of the Mesa Regal RV Resort, Mesa. Arizona. Besides
maintaining the system described in these articles, he also
collaborates in the development of a program to
display models of crystal
structures.