Installing and Configuring a Linux VPN Server (Part 2)

In the first article in this two-part series we took a look at the process of installing The IPSec VPN software FreeS/WAN on a Red Hat Linux server. In this article we continue the process, taking a look at how the service needs to be configured, are ultimately and a secure tunnel established.

The configuration of FreeS/WAN is not terribly difficult but can be a little bit tricky. You will need to configure some general start-up parameters and create connection objects that define the tunnels you wish to implement. To start, draw a basic diagram of the implementation scenario, which can be added to later. There are many variables that need to be documented at this point including the interfaces and their IP addresses, private subnet addresses, and the address of the next-hop Internet gateways.

For this example, assume that what we’re trying to connect are two single subnet networks that are connected to the Internet using either straight routing or masquerade. On the test network, we’re using masquerade to NAT private internal IP addresses (192.168.x.y) to public external interfaces, with this configured correctly on both gateway systems running FreeS/WAN (note that for illustration purposes, the entire test network is running private addresses). Internal clients should ultimately point to the IPSec server’s internal interface as their default gateway. Given that IPSec isn’t configured with any tunnels yet, we’ll assume that your private internal clients can ping Internet systems from both networks.

Installing and Configuring a Linux VPN Server

The best thing about Linux is that you can make it do just about anything. For many of you, Linux is possibly already your router, firewall, NAT server, and more. With a little work, you can easily extend your Linux setup to build a cost-effective WAN replacement in the form of IPSec VPN tunnels. In the article, the first of a two-part series, I’ll walk you through the installation process that will prepare you towards deploying your own Linux-based IPSec VPN servers. In the second part of the series we’ll take a look at configuring those servers so that you have the ability to allow encrypted communications to take place between 2 or more locations using the Internet as your virtual WAN.

When considering a VPN solution, it’s usually important to insist on two things. The first is that it supports at least end-toend tunnels and roaming users, the second being that it should be standards-based (that means IPSec support) to make interoperability with other systems possible when required. This article covers how to install and configure FreeS/WAN to create secure, IPSec-based VPN tunnels between locations. If your needs are relatively simple, you’ll have a secure Linux-based VP solution securing your traffic between locations in no time. If you want to get fancy, extending the design outlined here isn’t much more difficult at all.

The main purpose of deploying an IPSec-based VPN tunnel solution is as a replacement or backup for your current (and probably expensive) WAN links. Companies spend thousand of dollars on WAN infrastructure that can potentially be avoided with the proper implementation of a VPN over a standard (but hopefully high-speed) Internet link. The idea is to use Linux and an unsecured network (such as the Internet) as a vehicle for secure communications between two or more locations. This will provide easy and seamless connections to remote network servers and resources for our local network users.

Internet Authentication Service (IAS)

Windows 2000 implements a powerful centralized authentication, authorizations and accounting service (often referred to as AAA) in the form of IAS, its implementation of the Remote Access Dial-in Authentication Service (RADIUS). Used for both dial-in and VPN connections, IAS allows you to control in a more centralized manner the authentication of users, accounting of their connection start and stop times, as well as a way to centralize the application of remote access policies (authorization).

Not installed by default, IAS must be added via Add/Remove programs in Control Panel. Once installed, IAS is accessed using the associated Internet Authentication Services administrative tool.

Many people get confused about the purpose and configuration of IAS, so lets consider the basics. First of all, a big reason for using IAS is to centralize the authentication requests sent to remote access servers. For example, consider an environment that consists of a variety of remote access solutions (these are sometimes referred to as a NAS, or Network Access Server), such as Windows NT RAS, Windows 2000 RRAS, Cisco routers, various VPN and dial-in hardware solutions, and so forth. Maintaining accounts on those various platforms could be difficult, if not impossible. What RADIUS allows you to do is have all requests from the various remote access servers forwarded to the RADIUS server for authentication instead. As such, it is important to remember that a RADIUS client is actually a remote access server. The remote access server has client connections as well, but these are not RADIUS clients. I repeat, a RADIUS client is a remote access server. The remote access server does not authenticate client requests when RADIUS is used; instead it forwards them to the RADIUS server for processing.

This centralization provides a number of other benefits as well, including the ability to centralize the distribution of remote access policies. Remember that by default, remote access policies are local to the server on which they are created. In instances where you choose to set up a remote access server as a RADIUS client, all remote access policies on the server are ignored in favor of those configured on the RADIUS server. This presents a powerful way to control the application of remote access policy settings, especially in large distributed environments.

The actual configuration of IAS is quite simple, but there are a few things that you will need to be aware of. For starters, if you want a remote access server to act as a RADIUS client, it must be capable of authenticating to RADIUS. Most vendors add this functionality to their remote access servers, since RADIUS is an industry standard. Windows 2000 RRAS can act as a RADIUS client if correctly configured both in the RRAS settings and IAS setting. In RRAS, the setting are configured from the Security tab in the properties of the RRAS server.

By default, an RRAS-based server will authenticate to the Windows provide, either Active Directory or the local SAM database, depending on your setup. If RADIUS is chosen, further configuration is required, including the address of the server and a shared secret, which will be used between the RADIUS client and server for authentication purposes.

Simply configuring the RADIUS client is not enough. The settings for the RADIUS server must be configured via IAS.

Note the three sections that exist – Clients, Remote Access Logging, and Remote Access Policies. The Clients sections will allow you to add remote access server addresses and the corresponding shared secret that you originally set up. You will need to do this for each and every remote access server that you wish to act as a RADIUS client. The remote access logging pages allows you to configure what type information you wish log (and the associated format). Note that by default, nothing is logged, but recommendations are provided.

The last section allows you to configure the centralized remote access policies that I discussed earlier. These policies are configured and work in exactly the same manner as explained in the earlier remote access article.

You should understand that if you want IAS to be able to access a user’s dial-in properties in Active Directory, you must configure it to do so. This is accomplished choosing ‘Register Service in Active Directory’ from the Action menu of the snap-in (if the server is not a member of an AD domain, this option will be grayed out). Note that IAS will authenticate users against Active Directory or the local SAM database, as applicable. Note also that if you want redundant IAS servers, you should configure them similarly, being sure to copy the remote access policies to the second server, while configuring the RADIUS clients appropriately to account for the second server as well.

Configuring VPN Services

For the purpose of authentication protocols, IP address assignment, and so forth, the VPN ports use