In "Point-to-Point Tunneling Protocol" (June 1997), I explained how to build Virtual Private Networks (VPNs) to let client systems access your Windows NT network securely through the Internet. The response to that article showed that many of you have found this solution useful. Some readers anticipated my next article, because one of the most frequent responses was, "This is great. Can I use this to connect my offices?"
Well, the short answer to that question is no. Unfortunately, you can't use standard Remote Access Service (RAS) and PPTP to connect your offices. The RAS and PPTP that come with NT Server 4.0 are for client/server communications, not server-to-server communications. Fortunately, Microsoft has just released a tool that lets you build true VPNs securely, across the Internet, to connect servers and networks.
Time for a Little RRAS
Meet Microsoft's Routing and RAS (RRAS). RRAS (formerly code-named
Steelhead) is Microsoft's set of enhancements to NT's RAS and Multi-Protocol
Routing (MPR) services. Among the significant enhancements that RRAS includes,
you'll find support for newer routing protocols such as Routing Information
Protocol (RIP) 2.0 and Open Shortest Path First (OSPF), a graphical interface
and administration tool (for details about OSPF, see Tao Zhou, "Steelhead's
OSPF Routing," August 1997); Remote Authentication Dial In User Service
(RADIUS) client support; demand-dial routing; and PPTP server-to-server
connections. In short, RRAS is industrial-strength routing for NT. (For an
in-depth look at RRAS features, see Mark Minasi, "Steelhead Swims into the
Mainstream," August 1997.)
By taking advantage of the PPTP enhancements to build VPNs, you can connect remote offices securely with nothing more than an Internet connection at each site. Here, I describe what you need to connect remote offices as VPNs and tell you how to do it.
Can't Say Enough
Routing can be a very complex subject. If the world of IP, routing
protocols, static routes, name resolution, and other WAN areas makes you uneasy,
consider taking Microsoft's TCP/IP course to get your feet wet. In the meantime,
if you follow the example here, you can build a sample VPN across the Internet
and experience firsthand how RRAS works. I assume you have at least a
rudimentary understanding of TCP/IP networking principles.
The Scenario
Because predicting what a typical network configuration might look like
isn't possible, let's use a hypothetical situation to configure and demonstrate
the capabilities of RRAS. Assume you work at a US corporation. Your CEO has just
signed a merger deal with a large corporation in Europe, joining your two
companies. Your assignment is to set up communications between the two networks.
Your CEO assumes you need only to connect a few wires in the back room to get
things going and is wondering why you haven't finished yet.
Fortunately for you, the European company is running NT 4.0 with the new RRAS update. You're also lucky because the firm's technical employees speak English and mention that you can download the RRAS update from Microsoft's Web site at http://www.microsoft.com/ntserver/info/routing&ras.htm. After downloading the 5.5MB update and Service Pack 3 (SP3--you must install SP3 before you install RRAS), you're ready to go.
What You Need
For this example, you need two systems running NT Server 4.0 (we'll call
them EUROPE and AMERICA) and one workstation, which we'll call EUROPE-W0001. The
workstation can be running either Windows 95 or NT Workstation.
You need two connections (dedicated or dial-up) to the Internet. Dedicated connections work better than dial-up, but dial-up connections are acceptable.
You also need two fixed Internet IP addresses. Although you can make dynamically assigned addresses work, I recommend avoiding them. I've successfully tested RRAS with dynamically assigned addresses, but because this solution requires building static routing tables, IP addresses that change make a mess of things. Therefore, this example assumes you have fixed addressing.
Finally, if you're trying out RRAS on a dedicated Internet connection that goes through a firewall, you need an open port on the firewall to work through. To let PPTP traffic pass through your firewall, open port 1723 for protocol ID number 47 going in either direction (port 1723 is the port defined for PPTP traffic over TCP/IP connections).
Figure 1 depicts the sample network's layout; the workstation is on the EUROPE network. Table 1 lists the network's IP address ranges. Make sure that TCP/IP and PPTP are the only protocols in use anywhere.
Basic IP Configuration
Let's start by configuring the workstation. Simply set up the workstation
with the standard Microsoft TCP/IP stack, and assign the workstation a
fixed internal (i.e., non-Internet) IP address such as 172.16.10.2 with a subnet
mask of 255.255.255.0 and a default internal gateway address of 172.16.10.1.
Although I'm using internal IP addresses (in the 172.x.x.x range) as
sample Internet addresses, remember that your interface to the Internet must
have InterNIC-approved IP addresses. Test your configuration by making
sure you can ping your own IP address. Because this sample network won't be
running any name resolution, create an LMHOSTS file on the workstation with an
IP address such as 172.16.1.1 pointing to server AMERICA.
Next, configure the EUROPE server by installing Microsoft's TCP/IP stack, and assign the server a fixed internal IP address such as 172.16.10.1 and a subnet mask of 255.255.255.0. No default gateway is necessary on the server because the MPR service will run on it. Ping your own address to verify that you've configured the server correctly. Make sure your workstation and server are on the same logical network segment, and verify your connectivity by pinging each one from the other.
Now, configure the AMERICA server by installing Microsoft's TCP/IP stack, and assign the server an internal fixed IP address such as 172.16.1.1 and a subnet mask of 255.255.255.0. Again, no default gateway is necessary because the MPR service will run on this server, too. I recommend you put this server on a different logical network segment from the EUROPE server to make sure you can't communicate with the EUROPE server across the LAN.
Install RRAS
Once you've assigned internal IP addresses to the workstation and servers,
you can move on to installing RRAS. Make sure you first install SP3 (with the
Uninstall option selected).
Let's start with the EUROPE server. Before you begin your installation, install PPTP on the server that you'll install RRAS on: From Control Panel, Network, Protocols, select Add. Accept the default selection (1) for VPN connection, and click OK. When the Remote Access Setup window appears, click Add to add the PPTP device to your configuration, and click OK in the Add RAS Device window, as you see in Screen 1. Configure the port as a demand-dial router connection only: Click Configure in the Remote Access Setup window, and clear the boxes for Dial out as a RAS client and Receive calls as a RAS server in the Configure Port Usage window, as you see in Screen 2. Then restart NT.
Next, run the MPRI386 executable to install RRAS, and install RRAS in the directory where you want it. The RRAS setup routine will ask whether you want to delete your existing RAS, RIP, SAP, and BOOTP relay agent services if you have them installed. Those services and their Registry settings are now a part of RRAS, so answering Yes is OK.
As Screen 3 shows, you will see a prompt for the services you want RRAS to install on your system. Select all three services. If necessary, add ports to your RAS server when the Remote Access Setup window appears. If you'll be using a dial-up connection to the Internet, configure the dial-up port as a RAS client, RAS server, and demand-dial router. Accept the default RAS Server TCP/IP configuration parameters when the window appears: Let clients access the entire network, and use the Dynamic Host Configuration Protocol (DHCP) to dynamically assign addresses to clients.
Again, restart NT. Now, repeat the same configuration on the AMERICA server.
Adding the Connections
Once you've installed RRAS on the servers, you must perform the following
tasks on each server:
1. Set up RRAS to connect to the Internet.
2. Define your PPTP connection.
3. Define user credentials that the servers use for validation.
The first part of making your PPTP connection is to set up a valid Internet connection. For this sample network, let's set up a dial-up connection to the Internet Service Provider (ISP) in the RRAS Administration program. This program is now in your Administrative Tools group (if you have a dedicated Internet connection, you can skip this part). Remember, you need a fixed Internet IP address.
Right-click LAN and Demand Dial Interfaces in the left pane of the RRAS Administration window to add a new demand-dial interface to connect to your ISP. Select the Add Interface option, and name your connection ISP Connection. Check the I know all about demand-dial interfaces and would like to edit the properties directly box, and click Finish.
You then see the familiar Dial-up Networking phone book entry box. Configure the connection as you ordinarily do to connect your system to your ISP. Double-check the Security tab to make sure your authentication type is correct for your ISP.
When you're finished, click OK, and a new dialog box titled IP Configuration--ISP Connection appears. For now, accept the defaults.
In the right pane, right-click the new ISP Connection interface you've created, and choose the Set Credentials option. Because this is a demand-dial interface, you won't get a prompt for the name and password to use to establish your connection to an ISP. You'll need to provide them in the Interface Credentials dialog box, which you see in Screen 4. Enter the correct name and password combination, and click OK.
Right-click ISP Connection again and choose Connect to verify that you've done everything correctly up to this point. This verification starts the process to connect you to your ISP. If the connection isn't established correctly, troubleshoot it before proceeding further. (Chapter 6 of the RRAS online documentation provides useful troubleshooting tips and tools.)
Once you've established your Internet connection, you must define your PPTP connection. Right-click the LAN and Demand Dial Interfaces option again in the RRAS Administration program, and select Add Interface. Name this interface PPTP-AMERICA, leave blank the checkbox for I know all about demand-dial interfaces, and click Next. In the Protocols and Security dialog box, select Route IP packets on this interface. Also select the two options Add a user account so a remote router can dial in and Authenticate a remote router when dialing out (Screen 5 shows these options). At the prompts, select the RASPPTPM VPN adapter for this connection and then enter the Internet IP address of the AMERICA server at the prompt for a phone number or address.
After defining the PPTP connection, you must define user credentials that your two NT servers can use to validate themselves against the other. User credentials are user IDs that RRAS sets up for you and that the routers use to identify each other. The dial-out credentials are the first credentials you must create while configuring the EUROPE server. By default, the username is the same as the machine name (EUROPE), so change this name to PPTP-EUROPE. For testing, leave the password blank, and click Next. In the next window, you see a prompt to create dial-in credentials for remote routers connecting in. By default, RRAS will fill in PPTP-AMERICA as the username, and you won't have an option to change it. Again, in the test, leave the password blank and accept the defaults by clicking Next. (Note: if you end up going live with this configuration, remember to come back and enter a password.)
You're almost finished with the PPTP configuration. RRAS tells you that you need to create the same configuration on the other router (i.e., AMERICA) to complete this connection. In the configuration box, select the Enable router-discovery advertisements checkbox.
Now, repeat the same configuration for the AMERICA server. Configure your dial-up ISP connection and verify it. Build a PPTP connection on the AMERICA server and call it PPTP-EUROPE. For the IP address, enter the Internet IP address of the EUROPE server. At the prompt, to set up dial-in and dial-out credentials, define the dial-out credentials as PPTP-AMERICA with no password and set the dial-in credentials as PPTP-EUROPE with no password.
Are We There Yet?
You're not quite there yet. Don't try connecting now. You still have a bit
of work to do, including setting up static routing and security.
This time, work with the AMERICA server first. Click the IP Routing option in the left pane of the RRAS Administration program. Right-click the Static Routes to bring up the dialog box that you see in Screen 6. Define a static route to the destination address of the EUROPE server, that is, its Internet IP address (here, 172.16.77.46). Give it a subnet mask of 255.255.255.255 and any gateway address you want; I usually use 101.101.101.101. Set the Metric to 2, and choose your ISP Connection as the interface. This setting directs your system to go through the ISP connection to access the interface on the EUROPE server.
Build a secondary static route to the internal network in EUROPE by defining a route to the destination address 172.16.10.0, a subnet mask of 255.255.255.0, and a gateway of the Internet IP address of the EUROPE server. Set the Metric to 1, and choose your RASPPTPM device as the interface.
You have just built two static routes for your server that will direct all packets for the 172.16.10.x network to 172.16.77.46. However, your server needs to know how to get to 172.16.77.46, and your first static route entry gives it directions. Any packets destined for 172.16.77.46 will be directed to the ISP Connection demand-dial interface. Now, build the same configuration on the EUROPE server, but with routes pointing to the AMERICA server, with an internal address of 172.16.1.0.
Let's check this work before going any further. Verify that your Internet connections are active on each side of the network. Ping each server from the other through the Internet to make sure the connection is working. Once everything is in place, right-click your PPTP connection (from either server) and choose Connect. If you've done everything correctly, your connection will negotiate, and you'll have a VPN connection running between the two servers at 10,000,000 baud. I've seen the negotiation take up to a minute, so give it time.
If you run into trouble at this point and can't connect, don't worry; you're not alone. This part is the trickiest of the entire system and had me tripped up for a while. Keep working at it, and test your configuration at each logical checkpoint along the way.
Not Yet Secure
Okay, so you're connected. Take a break and have fun playing with the
connection. From the workstation, try to connect to a share on your AMERICA
server, and watch it connect across the Internet. If you have a print queue
defined on this server, print a job to it. Ping the 172.16.1.1 address of the
AMERICA server directly. For even more fun, run the tracert program and notice
that the Internet never appears in the trace--you just get a hop from your
EUROPE server to your AMERICA server. When you're finished, right-click the PPTP
interface and choose Disconnect to end the VPN connection.
You have a connection, but it's not yet secure. To secure it, edit the PPTP interface on each server and click the Security tab. Choose Accept only Microsoft encrypted authorization and Require data encryption. You can select Require strong data encryption if you want, but this option requires you to have the 128-bit version of NT 4.0 on each end.
Just for verification, reestablish your VPN connection to make sure everything is still functioning normally. If not, go back and double-check the changes you just made, or remove and retry them if necessary.
Next, you might want to enable packet filters if this server will perform only PPTP functions. If so, right-click the Summary option under IP Routing in the left pane of the RRAS Administration program and select Configure IP Parameters. Select the Enable packet-filtering box on the General tab, as you see in Screen 7. The program will set up on the ISP Connection interface and will block anything but PPTP packets. Right-click the ISP Connection interface and choose Configure interface.
At the bottom of the window in a section labeled Packet filters, you see two buttons: one for input filters and one for output filters. For the input filters, add a filter for protocol type Other and protocol ID number 47. Then create a filter for protocol TCP with source port 1723 and a destination port 0, and create another filter with source port 0 and destination port 1723. Make sure to select Drop all except listed below, and then repeat the same operation for the output filters. When you're finished, your filter screen will look like Screen 8. Now, repeat the same operation on your other server.
One last time, reestablish your VPN connection to make sure everything is still functioning properly. If so, congratulations! You've just built a sample VPN across the Internet.
Great...Now What Do I Do with It?
Now that you've built this great prototype, you'll still have to face some
design issues, particularly with the use of routing protocols. Microsoft's RRAS
documentation is comprehensive, so it's a good place to start.
Even if you don't decide to connect remote offices as VPNs, RRAS has a robust set of features that let you do other things, such as establish demand-dial routing to the Internet so that your clients can have direct Internet access. Or perhaps you'd like to set up a demand-dial interface for your corporate network to a home network to support a virtual office.
A Word About 1.0 Software
Finally, a word about bugs. With any first-edition software, you are bound
to find a few rough edges. Please keep that caveat in mind while you're trying
to implement any solutions with RRAS. While writing this article, I encountered
a few annoying behaviors I'd classify as bugs.
One bug you need to keep an eye out for is in the option to add a static route. After working in the RRAS Administration program for a while, I found that sometimes when I tried to add a static route, it never appeared in the list. Exiting the program and restarting seemed to correct the problem, but this bug is definitely something to watch for. Nothing is more annoying than plowing forward without realizing that one critical change you implemented never took effect.
