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.
Creating the Demand-Dial Interface
After you've selected which protocols the remote office system will route over the Internet, you must define on the remote system a demand-dial interface to the main office system to create an Internet connection between the two. In the MMC Routing and Remote Access window, right-click the Routing Interfaces option under the REMOTE-OFFICE server and select New Demand-Dial Interface.
The first wizard step—naming the interface—is very important. Although most Win2K wizards use a supplied name simply as the item description, the name of the demand-dial interface at the remote office must be exactly the same as a dial-in user account at the main office. The reason for this consistency is simple: When the main office server receives an incoming call (a call is just another computer connecting to the server over the Internet), Win2K must determine whether the caller is a user or a router. To do this, Win2K compares the name of the user calling in with its list of demand-dial interfaces. If an exact match exists, Win2K assumes that the incoming caller is a router and reacts accordingly. Otherwise, Win2K simply assumes that the incoming caller is a typical remote-access user.
Because naming is such an important step, I repeat the following: You must give the demand-dial interface on one system the exact name you give the dial-in user account on the other system. For the remote office server in the example network, you must call the demand-dial interface MAIN-OFFICE because you'll use the interface to connect to the main office.
After choosing a name for your demand-dial interface, click Next. You can use demand-dial interfaces to route traffic over standard analog telephone lines and ISDN circuits or across the Internet (as with a VPN). You're building a VPN, so select the second option—to connect using a VPN. Click Next.
Figure 3 shows the wizard dialog box in which you choose a protocol. Microsoft included two VPN protocols with Win2K Server: PPTP and Layer 2 Tunneling Protocol (L2TP). Microsoft developed PPTP, which Internet Engineering Task Force (IETF) Request for Comments (RFC) 2637 defines, and released it with NT 4.0 in 1996. PPTP uses TCP port 1723 and IP protocol 47 (Generic Routing Encapsulation—GRE). At about the same time, Cisco Systems developed the Layer 2 Forwarding (L2F) VPN protocol for use on its devices. Eventually, Microsoft and Cisco combined their respective protocols to form L2TP (RFC 2661), which uses UDP ports 500 and 1701. I prefer L2TP to PPTP because the former relies on IP Security (IPSec) for its encryption routines instead of Microsoft Point-to-Point Encryption (MPPE). However, according to Microsoft's online Help files, PPTP is a bit easier to set up, so in this example, let's use PPTP.
After selecting a VPN protocol to use, click Next. Demand-dial interfaces need to know a number to "dial," so enter the public IP address of the MAIN-OFFICE system (i.e.,10.0.0.130), as Figure 4 shows. Win2K will attempt to make a VPN connection at this address to route LAN-based workstation traffic from the remote office to the main office.
The next step in defining a demand-dial interface is to select the protocols to route across this interface. You previously configured the protocols the server could route; now you define protocols for a specific demand-dial interface. Figure 5 shows the screen for selecting the desired protocols. You can also select the option to create an account for a remote router to dial in, but I prefer to perform that step manually. Click Next.
When your remote office system "dials in" to the main office router, the main office system must authenticate the remote system before routing the remote system's traffic to the main office network. Thus, you need to set up a special set of Dial Out Credentials for Win2K Server to use when the server demand-dials into remote systems. The name and password you choose are important because you must create an account on the main office system that uses the same name and password. Your demand-dial interface at the main office will use this name as well.
After you've named your remote system, your demand-dial interface from the remote office to the main office is complete. The next step is to define on the remote office server a static route to the main office network.
Building a Static Route
To build a static route, open the MMC Routing and Remote Access window and expand the server container and the IP Routing option. Right-click Static Routes, and select New Static Route to open the dialog box that Figure 6, page 102, shows. You use this dialog box to tell Win2K Server to use the demand-dial interface to deliver any packets sent to this range of IP addresses. For the example network, you want the remote office Win2K server to use the previously defined MAIN-OFFICE interface to route any packets with a destination address of 172.16.0.1 to 172.16.0.254 to the main office. Therefore, to make sure the correct demand-dial interface appears in the Interface field, enter the appropriate IP address and subnet mask, and select the Use this route to initiate demand-dial connections check box.
You've now completed the routing configuration of your remote office system, but you still must add a user. When one server wants to connect to another server to route traffic, it must provide a username and password combination so that the receiving system can authenticate the sending system. On the remote office server, create a user with the name MAIN-OFFICE, the same name you used for the demand-dial interface. Give the user standard permissions (clear the User must change password at next logon check box, the Password never expires check box, and the User cannot change password check box). Then, configure the user's dial-in properties as Figure 7, page 102, shows.
Select the Allow access option to grant the user "dial-in" access. I also recommend assigning a fixed IP address for the incoming traffic. Although I've made a VPN configuration without a permanent IP address work, I prefer to specify the IP address Win2K will use. Click OK to save the user property modifications.
The last step at the remote office location is to configure all the client workstations to use the address 192.168.0.1 as the default gateway. This setting will cause the workstations to hand off to the Win2K server any packets headed for another network segment (i.e., packets headed to an address outside the 192.168.0.1 to 192.168.0.254 range). The server then determines the best way to deliver the packets. For packets addressed to the main office, the server connects the demand-dial interface and establishes the VPN connection.
Configuring the Main Office System
If you've come this far, take a break for a moment—you've reached the halfway point. You now need to repeat on the main office system the entire configuration routine you just performed on the remote office system. Follow the same steps, but enter the correct name and address information for the main office system. For example, name the demand-dial interface REMOTEOFFICE this time. After you've configured the main office system (including defining the correct static routes, user accounts, and IP addresses), you should have a functional VPN.
To test your configuration, go to the left pane of the MMC Routing and Remote Access window on the remote or main office system and navigate to the list of routing interfaces on the system. Right-click the demand-dial interface you defined, and select Connect. If you see a connection status of "Connected" in the MMC, your VPN should be fully functional. If the connection isn't successful, review the steps and troubleshoot your configuration for any possible errors before proceeding any further. (For more information about VPN troubleshooting, see Paula Sharick, "15 Tips for Troubleshooting VPN Connections," April 2000.)
When you obtain a valid connection, go to a workstation and use the Ping command to test connectivity. Have the workstation ping itself, its default gateway (the local Win2K server), the public IP address of the VPN server at the other office, and the address of a device at the other office.
If your pings travel from one end of the VPN to the other, the last thing to test is the demand-dial functionality. At the MMC Routing and Remote Access window, disconnect your VPN connection by right-clicking the demand-dial interface and selecting Disconnect. When the interface has been disconnected, go back to the workstation you used earlier to ping from and try to ping a device at the other office again. Although your first few pings might fail, you should ultimately see a response from the remote system if everything is working correctly. If you refresh the MMC Routing and Remote Access window on your server, you should see that your demand-dial interface has a connection. If the ping isn't receiving a response, try again; I've seen a VPN connection take from 2 to 12 seconds to be established, depending on network conditions.
More Information
If a firewall protects your LAN from the Internet at either or both ends of your planned VPN, ask your firewall vendor whether the firewall supports L2TP or PPTP connections. I assumed that firewalls were configurable to allow any connection type, but a client of mine discovered that some firewalls don't support some configurations. A quick call to your firewall's support line before you set up a VPN will let you know where you stand and save you from configuring a VPN only to find that your firewall won't let it work.
The configuration walk-through in this article should provide enough information for you to set up your VPN. However, if you want more information, Microsoft included a significant amount of online VPN documentation in Routing and Remote Access MMC Help. Look for the documents "L2TP-based router-to-router VPN," "PPTP-based router-to-router VPN," "Tunneling protocols," "Troubleshooting demand-dial routing," and "An on-demand router-to-router VPN." Although setting up a VPN can be a complex task, after it's working, it will be a reliable, cost-effective means of keeping your offices connected.
