A VPN is the expansion of a private network (e.g., a LAN) that leverages links across a shared or public network, such as the Internet. VPNs are a secure way of providing access to the servers on your LAN. In previous articles, I've warned against implementing remote access technologies such as Windows 2000 Server Terminal Services without first implementing a VPN solution. Now, I show you how to install and implement a VPN server on a Win2K machine to establish secure remote access for Web server administration.
VPN Technology Solutions
With a VPN, data is encapsulated with a header that provides routing information. This header lets data securely traverse a public network to reach the data's endpoint. The data is encrypted, so if packets are intercepted, they're indecipherable without the encryption keys that generated the data on the endpoints. (You can also use a VPN to establish routed connections between two or more LANs—for example, geographically separate offices—through a dedicated WAN connection, but that's beyond the scope of this article.) Two types of VPN technology solutions are available for remote client access in Win2K:
- PPTP—uses user-level Point-to-Point Protocol (PPP) authentication methods and Microsoft Point-to-Point Encryption (MPPE) for data encryption
- Layer 2 Tunneling Protocol (L2TP) with IP Security (IPSec)—uses user-level PPP authentication methods and machine-level certificates with IPSec for data encryption
I show you how to set up a PPTP VPN solution here.
Preparing for VPN Server Installation
Before you begin setting up and configuring a PPTP VPN solution, you might need to take a few preliminary steps. For example, if you have a firewall protecting your servers, you'll need to reference your firewall documentation for information about setting up and configuring your firewall to pass VPN traffic. In addition, a VPN server requires a dedicated NIC, so you need to set up and configure a second NIC that will move this private LAN traffic. The second NIC can use a static or dynamically generated IP address. If you have multiple LAN interfaces, I recommend naming each interface to keep them straight. To give your LAN interfaces names that are more descriptive of their function, open the Control Panel Network and Dial-up Connections applet, then right-click the LAN connection and select Rename.
Next, your VPN server needs a mechanism for resolving computer names to IP addresses. Win2K has two methods to accomplish this task: It uses DNS and a HOSTS file for host name resolution, and WINS and an LMHOSTS file for NetBIOS name resolution. Whatever form of name resolution is already running on your network will be sufficient for your VPN server.
Finally, if your VPN server belongs to a Win2K Active Directory (AD) domain, you need to log on as a user with Domain Admin privileges (or get the help of someone in your company who has Domain Admin privileges). You don't need to have Domain Admin privileges when you're setting up the VPN server, but you need them to add the VPN server to the list of valid remote access servers in AD before remote clients can use the service.
Installing the VPN Server
Installing a VPN server on Win2K is simple. On the server on which you want to run VPN services, click Start, Programs, Administrative Tools, Routing and Remote Access. Right-click the name of the server, then select Configure and Enable Routing and Remote Access to initiate the Routing and Remote Access Server Setup Wizard. On the first screen, click Next. On the Common Configurations screen, select the Virtual private network (VPN) server option, as Figure 1 shows, then click Next. On the Remote Client Protocols screen, verify the client protocols that you want to use in your VPN connection. Most likely, TCP/IP is the only protocol that will appear and the only protocol you need, but some shops still run IPX for backward compatibility to Novell and NetBEUI for backward compatibility to earlier versions of Windows. If you need to add protocols, you must quit the wizard and set them up appropriately in the Network and Dial-up Connections applet. Click Next.
On the Internet Connection screen, specify the Internet connection on the NIC that you've dedicated to your VPN server. This connection corresponds to the NIC connected to the Internet or to your perimeter network. Click Next. On the IP Address Assignment screen, which Figure 2 shows, configure how your VPN clients will be issued valid IP addresses on your network. If you have an operational DHCP server on your network, select the Automatically option. Otherwise, select the From a specified range of addresses option. With this option, you can choose a valid range of IP addresses that are compatible with the subnet on your network. (You can use a range of IP addresses in an off-subnet address range, but you'll need to add routes to your routing infrastructure for VPN clients to be reachable.) Click Next.
The Managing Multiple Remote Access Servers screen, which Figure 3 shows, lets you configure Remote Authentication Dial-In User Service. RADIUS is a client/server protocol and supporting software platform that lets remote access servers communicate with a central server to authenticate dial-up users and authorize their access to the requested system or service. RADIUS lets you maintain user profiles in a central database that all remote servers can share. That is, you can off-load authentication and authorization to a RADIUS server. This scenario is the most likely scenario if you're going to use multiple VPN servers. Win2K includes a RADIUS server known as Internet Authentication Service (IAS), which centralizes authentication, accounting, and administration of remote access policies for multiple Win2K VPN and dial-in remote access servers. IAS also manages third-party network-access servers. (Configuring an IAS server is beyond the scope of this article, but for more information, see Tao Zhou's Windows NT Magazine article "Remote Access Management with RADIUS," http://www.winnet mag.com, InstantDoc ID 5377.) If you choose not to use RADIUS for authentication, a Win2K VPN server can authenticate users by contacting a domain controller (DC) to authorize them through locally configured remote access policies. When you've decided which technology to use for authentication and authorization, click Next.
Click Finish to complete the VPN configuration process. Note that if you're not authenticated under an account with Domain Admin privileges, you'll receive an error message.
When your VPN server is running, your Microsoft Management Console (MMC) Routing and Remote Access snap-in should look similar to the one that Figure 4 shows. Now, you need to lock the VPN server down.
Setting Remote Access Policies
You grant authorization to your VPN server through a user account's dial-in properties or through Remote Access Policies. If your VPN server exists in a Win2K domain, you access a user account's dial-in properties by opening the MMC Active Directory Users and Computers snap-in. Click the Users container, then double-click a user in the right pane. On the user's Properties dialog box, click the Dial-in tab, which Figure 5 shows. If your VPN server is a standalone Win2K server, you access a user account's dial-in properties by right-clicking My Computer and selecting Manage to open the MMC Computer Management snap-in. Expand the Local Users and Groups container, click the Users container, then double-click a user in the right pane. Click the Dial-in tab. No matter whether your VPN server is part of a domain or a standalone, make sure that you select the Control access through Remote Access Policy option for the IIS administrators to whom you want to provide remote access. Select the Deny access option (the default) for everyone else.
You can also use Remote Access Policies to create a Win2K group policy that globally controls access. Remote Access Policies are a set of conditions and connection settings that provide flexibility when you're authorizing connections. With Remote Access Policies, you can grant or deny authorization in many ways, including by the day of the week and the time of day, by Win2K group membership, and by the type of connection being requested (e.g., dial-up, VPN). You can also limit the maximum session time, specify the authentication and encryption strengths, and set Bandwidth Allocation Protocol (BAP) policies.
Unless you've set up an IAS to centralize management, Remote Access Policies reside locally on the VPN server and aren't stored in AD. As a result, each VPN server can have a unique set of locally stored policies. The VPN server provides access as long as the connection settings match at least one Remote Access Policy. If the connection setting doesn't match a Remote Access Policy, the VPN server denies the connection, regardless of the user account's dial-in properties.
You create and manage Remote Access Policies through the Routing and Remote Access snap-in. In the snap-in, navigate to the Remote Access Policies container. You'll see that a default policy called Allow access if dial-in permission is enabled exists. Double-click this policy to open its Properties dialog box, which Figure 6 shows. Notice that the policy has been specifically set up to deny access because the Deny remote access permission option is selected.
Usually, technologies are completely open upon installation and you must manually lock them down. However, with remote access, the opposite is true. Routing and Remote Access comes locked down by default. Simply changing the default remote access policy to Grant remote access permission permits access. Microsoft provides a flowchart, which I've reproduced in Figure 7, of the way in which Remote Access Policies are processed.
You can create custom Remote Access Policies through the Add Remote Access Policy Wizard. To access the wizard, right-click the Remote Access Policies container, then select New Remote Access Policy. First, you must provide a friendly name for your Remote Access Policy. Then, you specify the conditions for your policy.
A myriad of condition attributes, ranging from day and time restrictions to Windows groups to protocols, are available. For example, you might have a Win2K group called IIS Admins that includes the users to whom you want to grant remote access through the VPN. To do so through the wizard, you choose Windows-Groups from the Attribute Types list. Then, you choose whether you want to grant or deny access. Finally, you specify the user profile, which includes Authentication, Encryption, and IP and Dial-in constraint options.
Configuring a VPN server for secure remote access is one of the more complex operations in Win2K. Remote access is also one of the more robust technologies in Win2K. The multiple configuration options and the complexities derived from backward compatibility are intimidating and seemingly endless. The Microsoft documentation, although thorough, doesn't seem to follow any logical order to facilitate easy implementation. I provide the foundation to get you up and running securely. In addition, you can find a helpful article about the security options and implications of a VPN server in the Microsoft TechNet column "The Cable Guy: Planning and Installing a Windows 2000 Remote Access VPN Server" (http://www.microsoft.com/technet/columns/cableguy/cg0101.asp).
Next month, I'll show you how to configure a VPN connection. I'll also provide a few additional tips about point-to-point VPN connections.