Configure a Win2K VPN

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.