Configure a Win2K VPN

Over the past 4 years, I've written articles about a variety of Windows 2000 and Windows NT subjects. However, I've received (and still receive) more email about one article than any other: "Create a Virtual Private Network with RRAS," November 1997.

In 1997, VPN was a hot topic, but using NT Server to implement a VPN between two networks was, to put it mildly, a less-than-intuitive process. Because I still receive email messages about a 3-year-old article, I'd say VPN is still a hot topic. Fortunately, in addition to improving VPN capabilities in Win2K, Microsoft has made it easier to use Win2K to implement VPNs. Still, you might welcome some instructions about the process. Let's look at how you can create a fully functional VPN across the Internet with only two Win2K servers.

What's a VPN?
A VPN is a private, secured network that runs over a public, unsecured network, with both networks having the same entry and exit points. In effect, you can run your WAN on top of an existing network (usually the Internet) and incur the costs of maintaining only one WAN connection instead of two connections. Not only can you run your network on top of another, but you can do so in a secure manner so that your data isn't at risk.

You might have heard the analogy that likens the privacy of data sent over the Internet to the privacy of a message written on a postcard. As a postcard travels through the US Postal Service, any postal worker who handles the card can read it, so postcards aren't a very secure way to pass information. The same is true for regular Internet traffic—anyone with means and motive can read the data you send.

Suppose you want to "securely" send a message. You write the message on a sheet of paper and put the paper in an envelope before sending it through the mail. This process involves roughly the same amount of effort, but postal workers can't see the message. A VPN works in the same manner, protecting your data as it travels from one end of a network to the other.

Connecting Offices
Consider a company with a main office and a remote office—both connected to the Internet—that need to communicate. These offices have two main options for connecting to each other. The first option is to buy a dedicated circuit to run between the two sites. This option—which usually involves an ISDN, fractional T1, or frame-relay connection at each site—is the tried-and-true method for linking offices but usually involves a monthly connection fee based on the distance between locations or the amount of bandwidth requested.

Alternatively, if both offices have public Internet connections and a private back-end LAN, you can simply configure a Win2K server at each location and link them with a VPN. Figure 1 shows a WAN with two Win2K servers: MAIN-OFFICE and REMOTEOFFICE. The main office has an internal subnet range of 172.16.0.1 through 172.16.0.254, and the remote office has an internal subnet range of 192.168.0.1 through 192.168.0.254. Between these offices is the Internet, which you can use to build the VPN. In this article, any address in the 10.x.x.x range denotes a public Internet address.

Let's assume that each of the two sites has a permanent, dedicated connection to the Internet and a fixed IP address from an ISP. Although you can make a VPN work with dial-up Internet connections, dedicated Internet connections are simpler to work with. Fixed Internet IP addresses are an absolute necessity at each site because you'll define static routes that require static addresses to route to.

The Win2K servers in the example WAN are standalone machines (not members of any domain or Active Directory—AD) and have only Win2K Server loaded on them. For security reasons, a system connected to the public Internet should have as few accounts as possible. Building your server as a standalone system helps you keep accounts to a minimum. I strongly advise using a dedicated, low-power machine for this task with nothing other than the OS loaded on it. I'm always amazed when people wonder why they have trouble getting Microsoft Proxy Server, Microsoft Exchange Server, RRAS, Microsoft IIS, and a host of other applications to run on the same server. Microsoft might lead you to believe that you can load all the applications you want on any system and they'll all work fine. However, the reality is that more often than not they won't, and having many applications makes for a confusing configuration. To keep things simple, I recommend giving a low-powered system—maybe an old 300 MHz Pentium II processor system that you have lying around—the sole job of routing your traffic.

The CliffsNotes Version
If you're like me, you appreciate a quick overview of how to perform a task before you do it. First, at each site, you define a demand-dial interface that points to the Win2K server at the other site. Then, on each server, you program a static route that points to the network at the other site. Next, you create user accounts at each site for the routers to use when they need to connect to each other. Last, you configure the workstations on each network to use the VPN-enabled Win2K server at their site as their default gateway.

Building a network-to-network VPN with Win2K is a bit easier than with NT, but the wizards are still a bit lacking, so I'll walk you through each of the configuration steps for the remote office that Figure 1 shows. After you repeat the same configuration steps for the main office, you should have a fully functional VPN solution.

On your server, select the Routing and Remote Access option from the Administrative Tools menu. If you don't have RRAS set up on your system, you'll need to add it to your server's configuration. Win2K Server doesn't install or configure RRAS by default. If you've previously installed RRAS and configured any routing or remote-access options on the system, you'll need to work around your existing settings with the VPN settings I recommend.

Right-click the server name (i.e., REMOTEOFFICE, in this case) in the left pane of the Microsoft Management Console (MMC) window, then select Configure and Enable Routing and Remote Access (RRAS). This action launches a wizard that takes you through the process of configuring RRAS on your system. Although wizards are helpful for most administration and configuration tasks, in this case, the wizard doesn't ask you to complete all the necessary configuration items. Therefore, I recommend selecting the Manually Configured Server option in the wizard's first dialog box.

After you instruct the wizard that you want to manually configure your system, it starts RRAS. After RRAS is running, right-click the server name in the left pane of the MMC window again. This time, select Properties to open the REMOTEOFFICE Properties page. From the General tab, make sure the option for enabling LAN and demand-dial routing is selected. You might question the demand-dial term because these servers both have an Internet connection and won't be using a phone line to connect to each other. However, Microsoft simply chose to use telephone terminology for VPN connection initiation.

The next step is to select the protocols your server can route. A VPN encrypts and tucks data inside IP packets, so it can carry protocols that usually can't cross the Internet, such as NWLink IPX/SPX. To select the protocols you want to route across the Internet, click their tabs, select their options to enable routing and to allow demand-dial connections, then click Apply. Figure 2 shows the IP tab with the necessary options selected. Check the tabs for protocols you don't want to route, and clear any options that enable routing and allow demand-dial connections.