What's New in Routing and Remote Access

An in-depth look at the features and capabilities of Win2K's updated version of RRAS

Longtime readers of Windows 2000 Magazine might remember my January 1997 article "What's New in Windows NT 4.0 RAS," in which I described the new remote access features of Microsoft's just-released NT 4.0. Now that many of us are working with Win2K, the time has come to update that article for the new OS by taking you on a tour of the features and benefits in Win2K's version of RRAS, which is now called Routing and Remote Access. As you'll see, Win2K doesn't simply provide updated versions of existing technologies: The OS introduces a completely new set of technologies that benefit the manageability, security, and usefulness of Win2K's Routing and Remote Access services.

RRAS: Now and Then
Routing and Remote Access is an update of both NT 4.0's basic RAS and the RRAS update, which Microsoft released as a superset of NT 4.0's RAS. Just as NT 4.0's RRAS update provides RAS with a wealth of new features and capabilities, Win2K's Routing and Remote Access adds new functionality to its NT 4.0 RRAS predecessor. However, Routing and Remote Access enhancements amount to more than just new features—Microsoft has also addressed several crucial RAS and RRAS shortcomings.

One such shortcoming is manageability. If you manage NT 4.0 RAS servers, you know that NT 4.0 RRAS's management UI isn't terribly intuitive. For example, although the capability to set up RRAS-based LAN-to-LAN VPN connections is an important and much-touted feature of the RRAS update, inelegant management tools and poor documentation make the setup procedure difficult.

Another major problem is stability, which isn't only an RRAS problem but an NT 4.0 problem. This basic OS stability problem brings the viability of NT RRAS-based VPN or routing solutions into question—especially when you compare those solutions with most hardware-based routing solutions. Feedback from administrators about these and other RRAS short-comings helped drive the development of Win2K's Routing and Remote Access.

Configuration and Management
Microsoft's efforts to streamline and improve RRAS are evident from the first moment you begin working with Routing and Remote Access. Unlike NT, Win2K doesn't install Routing and Remote Access as a separate network service; you don't need to install or manage Routing and Remote Access through the Control Panel Network applet. Instead, Microsoft integrated the service into the base installation of Win2K Server, Win2K Advanced Server, and Win2K Datacenter Server. Therefore, the files that Routing and Remote Access requires for proper operation are already present on any Win2K server. Also, Routing and Remote Access doesn't require a cumbersome three-part installation process (i.e., installing RAS from a CD-ROM, installing the RRAS update, and reinstalling the current service pack), as NT's RAS and RRAS installation does.

Although the Routing and Remote Access service isn't active by default, configuring and enabling it is simple. To configure Routing and Remote Access on a server, launch the Routing and Remote Access management console, which Figure 1 shows. Because this management utility provides full support for administration of remote servers and multiple servers, you can decide whether you want to run the management console from the Routing and Remote Access server, a different server, or even a Win2K Professional system (e.g., your administrative workstation). On any Win2K server, you can find the shortcut to the Routing and Remote Access management console by going to the Start menu and selecting Programs, Administrative Tools. To install the management console on a Win2K Pro system, install the adminpak.msi file, which resides in the i386 folder of any Win2K server product's installation CD-ROM. (Simply double-click the .msi file to launch the installation.)

The Setup Wizard
Now that you have the Routing and Remote Access management console running, you can configure your server. Highlight the server name in the left pane, and click Configure and Enable Routing and Remote Access from the console's Action menu or from the context menu that appears when you right-click the server's name. Doing so launches the Routing and Remote Access Server Setup Wizard.

In the wizard's second dialog box, which Figure 2 shows, the setup process lets you choose from five standard configuration selections: Internet connection server, Remote access server, Virtual private network (VPN) server, Network router, or Manually configured server. This useful dialog box simplifies the basic configuration of Routing and Remote Access servers, particularly if you plan to use the server primarily for one of the listed functions. However, you might want to usethe server to perform multiple duties (e.g., act as a network router and accept incoming VPN calls from clients). In this case, you can either select one of the configuration choices and manually configure the other element after the wizard finishes or choose the Manually configured server option.

Each of the wizard's standard configuration choices—aside from the Manually configured server option—prompts you for information necessary for initializing the configuration type. For example, the Internet connection server option asks whether you want to use Internet Connection Sharing (ICS) or Network Address Translation (NAT), then asks for additional information necessary to configure the connection-sharing type you choose. The Remote access server option prompts you for the protocols that you want to support for incoming client connections, then asks protocol-specific questions such as whether you want to use DHCP for RAS-client IP addressing or a Remote Authentication Dial-In User Service (RADIUS) server for authentication.

In most cases, after the wizard completes its work, you'll need to perform additional hand-tuning of your RAS server configuration. In general, however, the wizard simplifies the bulk of the Routing and Remote Access server's configuration and ensures that each of the crucial configuration options for a particular wizard choice are set—options that a new administrator might easily forget about.

New Routing Features
Although you might think of Routing and Remote Access primarily as a service that provides dial-up access to remote users, the service's routing functionality is also important. Routing and Remote Access, like its NT 4.0 RRAS cousin, provides Win2K servers with a relatively full-featured software-based router that you can use for several purposes.

One of the most notable routing features in Routing and Remote Access is NAT support. NAT—which Internet Engineering Task Force (IETF) Request for Comments (RFC) 1631 defines—is similar to the ICS feature that Win2K Server, Win2K Pro, Windows Millennium Edition (Windows Me), and Windows 98 Second Edition (Win98SE) support. Like ICS, NAT translates private, nonroutable internal IP addresses into routable, Internet-connected addresses on the NAT-enabled server, thereby letting you share one machine's Internet connection with the entire network. However, only Win2K Server supports NAT, implementing it as an installable routing protocol under Routing and Remote Access.

You can use the Routing and Remote Access Server Setup Wizard's Internet connection server option to install NAT. Alternatively, after the wizard finishes, you can manually install NAT from the Routing and Remote Access management console. Simply right-click the General option under IP Routing, choose New Routing Protocol, and select Network Address Translation (NAT) from the list of choices, as Figure 3 shows.

After you install NAT, you need to identify the internal (i.e., LAN) adapter and external (i.e., Internet) adapters on the server. To do so, right-click each adapter, select Properties, and in the resulting dialog box, choose the appropriate option: Private interface to be connected to the private network or Public interface connected to the Internet. (Be sure to perform this step for both adapters.) This procedure lets the server distinguish between interfaces and enables proper function of NAT.

NAT offers several significant advantages over ICS. First, NAT lets you use your Routing and Remote Access server as a WINS server proxy agent—as well as a DNS server proxy agent—for NAT clients. This feature lets you pass name-resolution requests to a WINS server on behalf of LAN clients. (However, clients can't use this proxy to register in the WINS database; clients can only resolve names.) NAT offers greater flexibility than ICS in terms of the IP addresses that you can use on the internal LAN. (ICS supports an IP numbering scheme of 192.168.x.x on the internal LAN and forces the assignment of the address 192.168.0.1 to the ICS server.) Also, NAT supports multiple public IP addresses (ICS supports only one) and can successfully translate and support client protocols such as PPTP (which ICS can't). Finally, unlike ICS, NAT lets you make services on the internal LAN (e.g., Web servers or FTP servers) accessible to Internet-based clients.

If you chose the wizard's Internet connection server option, Routing and Remote Access automatically takes you through the process of installing and configuring NAT. The wizard installs NAT, then asks you to identify your LAN and Internet adapters. If necessary, you can also use the wizard to set up a dial-on-demand connection to your ISP as the NAT Internet connection. If you're not in a domain environment, the wizard asks you whether you want to set up a simple ICS connection rather than NAT. For a comparison of ICS and NAT features, see Table 1, page 54 For more information about ICS and NAT, see "Related Articles in Previous Issues," page 54.

Another new, but lesser known, addition to Routing and Remote Access is its Internet Group Management Protocol (IGMP) support. IP hosts use IGMP to report their IP multicast group memberships to IGMP-enabled routers. Routing and Remote Access includes IGMP router and proxy components. Whereas the IGMP router tracks multicast group membership for LAN clients on the same network as the IGMP router-enabled interface, the IGMP proxy component sends IGMP group membership packets from one interface on the server (although multiple IGMP router-enabled interfaces might exist). IGMP's primary purpose is to let LAN clients run IP multicast applications—a technology that's rapidly gaining popularity because of its increased efficiency for streaming high-bandwidth data to multiple network clients.

On the Routing and Remote Access server, you can enable or disable IGMP router and proxy support on a per-interface basis on the server; however, you can enable IGMP proxy support on only one adapter. To add IGMP router or proxy support, select IGMP from the IP Routing section of the Routing and Remote Access management console's left pane. Choose New Interface from the Action menu or the context menu that appears when you right-click IGMP.

You'll also need to set up one or more IP multicast address scopes on your server. IP multicast addresses exist in the range from 239.0.0.0 to 239.254.255.255. In the Routing and Remote Access management console's IP RoutingGeneral section, you configure the addresses as one or more scopes on the Properties dialog box's Multicast Scopes tab. In addition to its new NAT and IGMP routing protocol support, Routing and Remote Access still supports the dynamic routing protocols Open Shortest Path First (OSPF) and Routing Information Protocol version 2 (RIP2), which NT 4.0 RRAS introduced.

New DHCP Digs
Routing and Remote Access contains several new DHCP-related features. One feature is the DHCP Allocator, which is a component of NAT. The DHCP Allocator is essentially a scaled-down version of a full DHCP server that lets a NAT-enabled Routing and Remote Access server provide IP addresses to NAT clients. Another feature is the improved DHCP Relay Agent, which you configure from the Routing and Remote Access management console's IP RoutingDHCP Relay Agent section. Like its NT 4.0 predecessor, the DHCP Relay Agent, which Figure 4, page 56, shows, lets a Routing and Remote Access server pass DHCP client requests from one LAN segment to a DHCP server on another network segment when the server is connected to each segment.

The DHCP Relay Agent also supports a new DHCP technology, DHCP Inform. This technology, which RAS clients running Win2K, Windows Me, and Win98 support, lets DHCP clients obtain additional IP configuration information from a DHCP server after the negotiation of their dial-up connection is complete.

DHCP Inform is important because RAS clients don't obtain their IP addresses from a DHCP server and thus don't benefit from some DHCP features. Even when you configure the RAS server for DHCP, the server obtains the address on the client's behalf and passes it, along with other IP configuration information, to the client through standard Point-to-Point Protocol (PPP) negotiation. However, Win2K, Windows Me, and Win98 RAS clients can send—and the Routing and Remote Access server can receive and respond to—special DHCPINFORM messages that let the RAS clients receive IP configuration information from a DHCP server. This information supersedes or augments information that the RAS clients receive from the Routing and Remote Access server.

The Routing and Remote Access server receives the DHCPINFORM message from the client and passes it on to the DHCP server, then returns the information it receives from the DHCP server back to the client. The information includes configuration data (e.g., additional or alternative WINS and DNS servers), a DNS domain name, and a default gateway. If the client receives DHCP options that supersede those originally obtained from the Routing and Remote Access server, the new information replaces the old information. This feature requires that a DHCP server exist on one of the LANs to which the Routing and Remote Access server is connected. Also, before this feature will work properly, you must add each of the network interfaces on which you want to support DHCP relaying to the management console's IP Routing/DHCP Relay Agent section. (The system automatically adds and enables a special Internal interface.)

VPNs, Win2K Style
Routing and Remote Access sports several new VPN-related improvements. One improvement is the addition of Layer 2 Tunneling Protocol (L2TP) support. L2TP, which RFC 2661 defines, acts as a successor to earlier single-vendor tunneling protocols, such as Microsoft PPTP and Cisco Systems' Layer 2 Forwarding (L2F) protocols. Unlike PPTP, Win2K's L2TP implementation uses IP Security (IPSec) rather than Microsoft Point-to-Point Encryption (MPPE) to secure and encrypt PPP datagrams that pass over a VPN connection. Therefore, a RAS client that wants to use L2TP must support both IPSec and L2TP. Currently, only one OS—Win2K—meets this requirement.

Another notable improvement is enhanced VPN administration, which includes the Routing and Remote Access Server Setup Wizard that I discussed earlier. Like the wizard's other options, the Virtual private network (VPN) server option prompts you for all the basic information necessary to complete the VPN server configuration, including the identification of your Internet-connected adapter. (This connection must occur through a NIC—not a dial-up connection—so you must have at least two NICs, or one adapter with at least two LAN ports, in any server that you intend to make a VPN server.) The wizard then automatically configures the Routing and Remote Access server with whopping 128 PPTP and 128 L2TP connections. (Other configuration choices configure 5 PPTP and 5 L2TP ports.)

If you want to manually change these default numbers after the wizard completes, simply right-click the Ports entry in the Routing and Remote Access management console's left pane and choose Properties. Doing so displays all the ports available on the Routing and Remote Access server, including the WAN miniport drivers for PPTP and L2TP (assuming both are present). To modify the number of ports available for each protocol and to determine the direction of the connection (i.e., inbound or outbound), highlight the protocol, click Configure, and use the resulting Configure Device dialog box to set the desired options, as Figure 5 shows.

The Virtual private network (VPN) server option also configures the DHCP Relay Agent so that Routing and Remote Access clients can use DHCP Inform and IGMP support to let Routing and Remote Access clients use IP multicast applications. The option also automatically configures a default remote access policy and creates filters on the Internet-connected interface so that the Routing and Remote Access server will accept only PPTP and L2TP connections and drop all other traffic. This feature is similar to NT 4.0's PPTP Filtering feature. If your configuration requires you to permit additional traffic, or if you later change your Routing and Remote Access server's configuration to handle other duties such as remote access or routing, you might need to modify or remove these filters.

Routing and Remote Access's VPN features, like those of NT 4.0 RRAS, also support VPN-based LAN-to-LAN routing over LAN or dial-up interfaces (which now include L2TP as well as PPTP). Fortunately, the process of setting up a VPN-based LAN-to-LAN router is much easier than the NT 4.0 process and involves far less guesswork. For more information about configuring VPNs with Routing and Remote Access, see "Related Articles in Previous Issues."

The Power of Policies
A significant improvement in Routing and Remote Access is the introduction of remote access policies. Under NT 4.0, the only policies that you can enable for RAS connections are users' dial-in privileges and callback capabilities. Routing and Remote Access's policies greatly expand the amount of flexibility and control that you have over how and when users connect to a Routing and Remote Access server. A remote access policy defines a set of necessary conditions and connection settings for the server to use to authorize particular connection attempts.

Policies, which you manage in the Routing and Remote Access management console's Remote Access Policies section, let you grant or deny authorization on a Routing and Remote Access server according to several criteria:

Environments that use Internet Authentication Service (IAS) in conjunction with Routing and Remote Access also support several other criteria.

Remote access policies let you configure a wide array of options for a dial-up session. For example, you can limit the maximum permitted connection time, the strength of authentication and encryption, and the dynamic allocation of bandwidth on multilink connections. With remote access policies, a connection is authorized only when the connection attempt's settings match at least one of the policies that you've defined. If the settings match none of the policies, the server drops the connection even if you've enabled dial-in access for the user's account. Remote access policies reside locally on individual Routing and Remote Access servers or on an IAS server for servers that you've configured to use IAS for RADIUS-based authentication. Because you can use IAS as a centralized location for all your enterprise's remote access policies, using IAS in networks that contain many Routing and Remote Access servers is extremely advantageous.

By default, the Routing and Remote Access Server Setup Wizard defines one basic policy, which lets a user call in if dial-in access is enabled for the user. This policy is the equivalent of NT 4.0 User Manager's Enable dial-in privileges option. To create additional policies, go to the Routing and Remote Access management console's Remote Access Policies section. Launch the Add Remote Access Policy Wizard by choosing New Remote Access Policy from the Action menu (or by right-clicking Remote Access Policies and choosing the same option from the context menu that appears). For additional information about remote access policies, see "Related Articles in Previous Issues."

RRAS: Under New Management
Routing and Remote Access's administrative improvements don't end with the enhanced management console and the configuration wizard. Routing and Remote Access offers several other additions that can make your life easier. One such addition is support for RADIUS, a service that lets you centralize authentication, administration, and accounting in heterogeneous networks that contain different types of dial-up access equipment. Win2K supports RADIUS on both the client side and the server side. The client-side support takes the form of a Routing and Remote Access server connecting to a RADIUS server on the network to authenticate or provide accounting services for dial-up clients.

One useful feature of Routing and Remote Access's RADIUS support is that you configure authentication and accounting separately. In other words, you can opt to configure a server to use either Windows or RADIUS for both authentication and accounting—you don't need to use the same provider for both. Although Microsoft designed Routing and Remote Access's RADIUS client support to work with any vendor's RADIUS server, Win2K includes a proprietary RADIUS server implementation—IAS. One major benefit of using IAS as your RADIUS server is that you can centrally store and manage remote access policies for all your Routing and Remote Access servers. IAS is worth your consideration if you administer a heterogeneous corporate LAN or ISP environment and need to support several network-access service devices that support RADIUS, if you want to centrally manage your remote access policies, or if you need dial-up connection accounting features. RADIUS also has the advantage of providing a single-logon environment for clients accessing RADIUS-aware hosts.

Win2K also simplifies the command-line administration of Routing and Remote Access servers. You can use Win2K's new Net Shell (Netsh) command to configure and administer many network-related components. Using the Netsh and Netsh Ras routing commands and their related options, you can configure virtually every aspect of a Routing and Remote Access server, including authorizing the server in Active Directory (AD); configuring, adding, and managing ports, protocols, and features; and saving and restoring server configuration information. You can even use Netsh commands in scripts or batch files to fully automate the installation and configuration of your Routing and Remote Access servers.

You can enter Netsh commands in several ways. First, you can enter commands interactively within the Netsh shell. For example, to display the current RAS IP configuration on a server, type

netsh

at the command prompt. Then, at the netsh prompt, type

ras

At the ras prompt, type

ip

and at the ras ip prompt, type

show config

Second, you can simply enter the commands at the command line, as follows:

netsh ras ip show config

With either of these methods, you can enter Netsh commands in online or offline mode. In the default online mode, the system executes commands immediately as you type them into the Netsh console. In offline mode, the system queues the commands and doesn't execute them on the Routing and Remote Access server until you enter the Commit command. (To clear offline-mode commands before committing them, you can enter the Abort command. Microsoft incorrectly identifies Abort as Flush in the Routing and Remote Access online Help file.) To change between online and offline mode, simply use the Online and Offline commands at any time in the Netsh command-line console.

The third method for entering Netsh commands is to do so through a script or batch file. For example, through the Netsh interface, you can use the Exec Scriptfile command to execute a file that contains multiple Netsh commands. Alternatively, you can use the special ­f switch on the Netsh command line. (For information about this option, use the Netsh ­? command.)

Another useful Netsh feature, the Dump command, lets you create a script file that represents a Routing and Remote Access server's existing configuration. You can run Netsh's Dump command at various levels in the Netsh shell, depending on the scope of the configuration data you want to dump. (For example, using Dump at Netsh's main prompt dumps the machine's entire network configuration, whereas using Dump at the ras prompt dumps only the RAS configuration information.) To dump RAS and routing-related configuration data into a file, you can use the following two command lines:

netsh ras dump > filenamenetsh routing dump > filename

where filename is the name of the script file you want to create from the Dump command's output.

When you make changes to a Routing and Remote Access server either interactively or through batch or script files, you should always run the Dump command first to save the machine's existing configuration. That way, you can restore the configuration later if you encounter problems. Table 2, page 61, shows a list of all Netsh commands related to Routing and Remote Access.

Routing and Remote Access also contains logging (aka tracing) improvements. The service supports three levels of logging:

In addition, you can now enable logging for nearly every component of Routing and Remote Access from within the GUI management console or from the command line.

The facilities for managing logging are far more intuitive than they are under NT 4.0. You can access logging options for individual Routing and Remote Access components within the Routing and Remote Access management console from each component's Properties dialog box. For example, to enable general Routing and Remote Access server event logging and PPP logging, right-click the Routing and Remote Access server name in the management console, choose Properties, and select the Event Logging tab, which Figure 6 shows. To configure logging from the command line, use the command

netsh ras set tracing component 

where component is the Routing and Remote Access component (e.g., PPP) for which you want to configure logging. To globally enable or disable logging for all Routing and Remote Access components, enter the command

netsh ras set tracing * 

Unlike other Routing and Remote Access events, which the system records in the system event log, these component-level logging entries reside in the server's %windir%tracing folder (e.g., C:winnttracing). The system creates separate log files in this folder for each component for which you've enabled logging and names the log files after the component. For example, enabling PPP logging results in the creation of a ppp.log file.

Other New Features
Routing and Remote Access offers other features that you'll appreciate. One such improvement is the service's elimination of NT 4.0's 256-ports-per-server limitation. In Routing and Remote Access, each server can support a virtually unlimited number of ports. (Hardware limitations such as network bandwidth, memory, and CPU resources will be the primary constraints on this number.)

Routing and Remote Access also introduces several features that will help you reduce unwanted dial-up connections, such as dial-up Internet access by users and dial-on-demand LAN-to-LAN router links. First is the inclusion of a demand-dial filter feature, which lets you define filters that prevent demand-dial connections for certain traffic types. Second is the capability to define the hours during which users can make dial-out connections. Over time, both of these features will help you significantly reduce your organization's dial-up connection costs.

If you're using multilink RAS connections, you'll be interested in Routing and Remote Access's support for the Bandwidth Allocation Protocol (BAP) and the Bandwidth Allocation Control Protocol (BACP). These protocols, which are commonly used on hardware-based routers that employ multilink connections (e.g., ISDN lines, with their two 64KB "B" data channels), enable Win2K to automatically add or subtract lines from a multilink RAS connection based on the amount of consumed bandwidth or the time of the connection. You must enable bandwidth-allocation support on both the client and the server, and you configure the rules through the Routing and Remote Access management console's remote access policies. You configure BAP and BACP support for a Routing and Remote Access server in the server's Properties dialog box. Right-click the server name in the Routing and Remote Access management console's left pane, go to the PPP tab, and select the Dynamic bandwidth control using BAP or BACP check box.

Another improvement in Routing and Remote Access is the capability to define multiple IP address allocation ranges or pools from which Routing and Remote Access servers can assign IP addresses to dial-up clients. (NT 4.0 limits address allocation to one contiguous IP address range.) Routing and Remote Access also supports Extensible Authentication Protocol (EAP) and Microsoft Challenge Handshake Authentication Protocol (MSCHAP 2.0). EAP lets Routing and Remote Access support plug-in authentication modules for devices such as smart cards and lets RAS extend its authentication support to existing and forthcoming devices and technologies. MSCHAP 2.0 provides better security for authentication with Windows dial-up clients that support it (including Win2K, Windows Me, Win98, and Win95 with DUN update 1.3). The protocol also supports stronger encryption of passwords and password changes, and mutual authentication between the RAS client and server—rather than the one-way authentication that MSCHAP 1.0 supports.

Consider Migrating
Win2K's Routing and Remote Access introduces many important new features and smoothes several administrative bumps in NT 4.0's RAS and RRAS. Boasting a seamless integration with the Win2K OS, an improved management interface, policy-based client permissioning, and flawless Internet connectivity through ICS and NAT, Routing and Remote Access gives you a plethora of useful new tools that will make life in Win2K much easier. Even if your organization hasn't yet moved to AD, you might find these benefits compelling enough to warrant an early migration of your NT 4.0 RAS and RRAS member servers to Win2K.