Create a Virtual Private Network with RRAS

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.