In the Pacific Northwest, some rainbow trout move from rivers to the open water--large lakes or even saltwater. At that point, they're no longer rainbow trout. They're called steelhead trout, Oncorhybchus Mykiss. They're still good eating, but they're a fight, and you have to watch for bones.
Microsoft's Routing and Remote Access Service (RRAS) is the newest version of its Multi-Protocol Routing (MPR) software for Windows NT Server. Before release in June, the product was code-named Steelhead, and it has a few things in common with the fish. For one thing, MPR software has moved from a very basic routing system that Microsoft never intended for heavy-duty use--more suited to the smaller tributaries and woodland streams of most intranets--to (Microsoft claims) enough routing power to take on jobs dedicated routers currently do. (Or perhaps the ichthyological name shows that it scales well--sorry, couldn't resist.)
With a new version of MPR, I decided to revisit a subject that I covered in several columns in 1996--using NT Server as a LAN/WAN Internet router for a small C class or Classless Inter-Domain Routing (CIDR) network. But RRAS does more than make existing NT routing tasks easier; it adds new capabilities, including single-seat router administration, greater speed, support for Open Shortest Path First (OSPF) routing, integration with Point-to-Point Tunneling Protocol (PPTP), and packet filtering.
The Test Spawning Ground
I tested the Steelhead beta software, which Microsoft released as RRAS as I
finished writing this article. The scenario I tested was basic, what Microsoft
calls "home-office LAN" in the Steelhead documentation.
Figure 1 shows the configuration.
Suppose you have a small business (or a small part of a large business) and want to connect your local LAN to the Internet over a dial-up connection. You could always do this with NT, but doing so was a bit of a pain. Steelhead makes it easier for the NT Server to act as your LAN/WAN Internet router. The solution isn't perfect, but it's an improvement.
I started with a C network, or CIDR block of addresses, from my Internet Service Provider (ISP). To set up a router with NT, I also needed a machine with at least 32MB of RAM, NT Server 4.0, Service Pack 2 (SP2), Steelhead beta 2, a modem, Integrated Services Digital Network (ISDN) or other Remote Access Service (RAS)-capable connection, and a network card. Other PCs on my local network have network cards, and I had to configure them with IP addresses from the block my ISP provided.
First, I set up all the PCs on the LAN with the ISP-provided IP addresses. This step is important: Each machine must have a separate and distinct, honest-to-goodness Internet address. Do not make up addresses, and do not use the non-routable addresses. (A surprising number of people email me looking for help in setting up their routers, and the problem turns out to be that they just made up some IP addresses.)
Then, I set up the NIC on the router PC and gave it an ISP-supplied address. The router PC eventually ends up with two IP addresses, one for the NIC and another for the RAS connection to the ISP. I installed a fresh copy of NT Server 4.0 on the router machine from the distribution CD-ROM. I did not install RAS, because Steelhead removes RAS before installing. I pointed all the PCs' default gateways to the IP address on the router PC's NIC. Then I made sure that all the PCs on the LAN could ping each other. With that done, I knew the LAN worked properly.
I installed SP2 on the router PC; yes, that's SP2, because SP3 didn't work
with Steelhead and my dial-up configuration. Microsoft fixed this problem for
the final release, and RRAS requires SP3. I then installed Steelhead. It arrived
as one EXE file but expanded to several files that install with the command
mprsetup
Next, I logged on at the server, opened up Dial-Up Networking (DUN), and figured out how to connect to my ISP. I wasn't worried about routing yet; I just wanted to get the NT Server to successfully dial up the ISP and establish a Point-to-Point Protocol (PPP) connection so that I could ping and run Internet Explorer and the like from the NT Server--I'll discuss routing to the other PCs a bit later. Mike Reilly covered using DUN to dial in to an ISP in "New to NT: Remote Access Service," May 1997, so I won't repeat how to do it here. You have to noodle around with the IP parameters to make a PPP connection with your ISP work well. And when I say, "You have to noodle," I mean it. My ISP had a specific FAQ on connecting with RAS and DUN, and some recommended settings were wrong. If tech support from your ISP is like tech support from most ISPs--that is, practically nonexistent--plan to spend a day or two messing with the DUN parameters. If you use a full-time connection such as a Frame Relay Access Device (FRAD) look to tech support for that device. In this case, don't buy the FRAD until you speak to both your ISP and the FRAD maker to be sure that someone will be around to help get you up and running.
You'll also need to experiment to find out how to automate your dial-in. With ordinary DUN, you can just tell NT to pop up a terminal window that lets you type in your username and password. But RRAS doesn't let you do that. Your ISP has to support Password Authentication Protocol (PAP) or Challenge Handshake Authentication Protocol (CHAP), or you'll need to write a login script. Now is the time to get the bugs out of this procedure, before you start worrying about routing. My ISP supported PAP, so authentication wasn't a problem.
Once you figure out all that ISP configuration stuff, write it down and keep the information in a safe place. Now you're ready to route.
If you've tried to make an NT Server act as a LAN and WAN IP router, you know that at this point, you must typically make a handful of Registry changes and reboot. But with RRAS, this stage is easy downstream swimming.
RRAS has an administrative tool called Routing and RAS Administrator; you'll find it in the Administrative Tools group. In my example, Steelhead doesn't yet know about the dial-in connection, so you'll see a screen similar to Screen 1, showing only the Ethernet connection. Steelhead doesn't know about the modem, so I had to build the WAN link. I right-clicked the Ethernet interface to get the Add Interface option. That action kicked off the Demand Dial Interface Wizard, which looks a lot like the wizard that helps create new phone book entries. A couple of clicks in, I found Screen 2, which tells Steelhead that I'm using this modem as a dial-up IP router. The next few screens are similar to ordinary New Phonebook Entry wizard screens. The last screen let me set filters, which I'll get back to in a moment. Routing and RAS Admin then looked like Screen 3; note the new interface, Clark Net. The Clark Net line type is demand-dial, meaning that the interface senses when you need it. In my example, I haven't tried to route through it yet, so it's disconnected.
You must take one more step before routing. The router knows that an Ethernet interface and a demand-dial interface exist, but it doesn't know anything about the demand-dial interface--what IP addresses the router can access through this dial-up interface. RRAS needs a static route to get to the Internet. To add a static route, I clicked the plus sign next to IP Routing and right-clicked the Static Routes line. That step gave me an Add Static Route option, and I saw the dialog box in Screen 4.
I filled in the values: The first two are trivial because this connection will be a gateway to the Internet, and the Internet's network address is 0.0.0.0 and subnet mask is 0.0.0.0. I also had to fill in a gateway address, the one an ISP assigns to you when you dial in. Your router must have the same dial-in IP address as the gateway address, as near as I can tell. When you get a CIDR block or C network from your ISP, make sure the ISP always assigns the same address when you dial in. I filled in the metric of 2, because my connection has a hop across the router to get to the Internet; If you set the metric to 1, you might not be able to route within your local network. The Interface lets me associate this route with my dial-up connection, the Clark Net interface.
Next, you need to wake up the demand-dial connection. I went to a PC on my network and tried to ping a location such as www.microsoft.com. Now the cool stuff happens. From across the Ethernet, my NT Server router got the clue that it needed to dial up, and did. At this point, I was live on the Net using an NT Server as a router. The connection takes a couple of minutes to get set up, so your first few pings might fail. I usually set a big timeout, like
ping www.microsoft.com -w 10000
What's the Catch?
Other than the two pitfalls I've mentioned so far--you must end up with the
same IP address all the time on the demand-dial interface, and you need to use
either PAP/CHAP or an authentication script--how does the rest of RRAS work? For
the application I explored here, I give Steelhead a grade of C; sometimes it
seemed more like a croaker. The modem connection sometimes dropped for no
apparent reason in the middle of transferring data. Steelhead, my ISP, or
perhaps line noise was at fault. Other times, the connection stayed up, but the
Steelhead router stopped responding to external pings. I attempted to send the
four screenshot bitmaps that you see in this article over the connection as
attachments to a mail message. But the connection never stayed up long enough to
perform the operation, and I had to SneakerNet the files over in the end. The
router was sometimes smart enough to reconnect, but not always. Sometimes the
connection dropped--the off-hook light on the modem turned off--but the Routing
and RAS Admin program showed the connection still up. Other times, I had to drop
the connection manually and force it to reset before I could get packets to
route correctly.
All in all, Steelhead wasn't as hands-off as I'd like. But it was a big improvement over messing around with Registry parameters. And my old method of making NT act as a LAN/WAN router wasn't kosher in the eyes of Microsoft tech support, which meant that if you couldn't make it work, you were high and dry. Presumably that lack of support won't be true with RRAS.
I'd like to see a throughput measure built into the tool, but Perfmon's RAS counters let you watch those statistics. And the user interface is a bit clumsy. For example, I had to fumble around just to dump the IP routing table from the GUI, although the familiar route print command works just as well as it ever did. And best of all for us stodgy old command-line types: From the command line, you can use routemon to do everything that you can do from the GUI.
To answer whether the problem was the router or the ISP, I re-implemented the C network connection to the ISP with a dedicated router, the Micro Router 900i (MR900i), from Compatible Systems. The MR900i is reasonably priced (about $850 discounted) and comes with an Ethernet connection and a serial port, a nice basic LAN-to-WAN router. It does not do Open Shortest Path First (OSPF) or port filtering (or at least the one I own doesn't; Compatible Systems' Web site shows that later models do), but you can do single-seat management of multiple Compatible routers through a Windows program that comes with the router. Rebuilding the network with the Compatible router was a snap--no hitches--and the PCs on the network were able to access the Internet for big and small jobs without trouble. This result suggests that the instability lay in the Steelhead software.
Trolling for More
Well, suppose you're concerned about security in your intranet. In that
case, RRAS is quite a catch. Virtual Private Networks (VPNs) offer one approach
to Internet security. They let you use the Internet as a big, private LAN. PPTP
lets you do that trick, but for the best PPTP security, the router machine must
also be the PPTP server. RRAS's higher performance means that you can use an NT
machine as your LAN/WAN router even on a T1 connection, and that machine can
also act as a PPTP server.
Or you might choose to open your network to the Internet but protect the network from people using NetBIOS over TCP (NBT) to penetrate your network. In that case, filter TCP and UDP ports 135 through 139. Under IP Routing/Summary, right-click the WAN link and choose IP Configuration to get a dialog box that lets you filter particular ports from particular locations. With such precise control, you can, for example, filter out port 25 from a particular IP address, denying that address the ability to send Internet mail to mail servers inside your network.
As the network gets bigger, walking around to all the NT Server machines to administer the machines acting as routers will become tiresome. But the Routing and RAS Admin tool can control any Steelhead router from one location. Large networks can't handle the chatty nature of the Routing Information Protocol (RIP), so you'll welcome RRAS's OSPF protocol support. Both RIP and OSPF are dynamic routing algorithms that discover routes through your network rather than requiring static routing.
Test the Water
RRAS takes NT's routing capabilities and moves them forward considerably.
First, it runs faster than the built-in IP routing software and might now be
good enough to replace dedicated routers. Second, single-seat management makes
RRAS more practical to manage. Third, taking NT's LAN/WAN routing capabilities
out of the closet and making them officially supported tools is incredibly
significant not only for Internet users but also for ISPs who want to move from
a UNIX-based network to an NT-based network. Add the PPTP and packet filtering
capabilities, and RRAS is a neat tool.
That said, I must warn that prospective RRAS users must experiment with their IP environments to see whether RRAS does what they need. My experience with my ISP and the test C network would not have been sufficiently reliable to leave my intranet in the hands (fins?) of MPR. If you use the network constantly, stay with the compatible route. In fairness, remember I did those tests with beta software. Try out the release version and see whether it's a good catch or you'll want to just throw it back.
