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.

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.

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.

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.

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.

"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