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.