Configure IT Quick: Configuring Routing and Remote Access on your Windows 2000 server

Learn how to allow remote users access to your Windows 2000 server

In the Daily Drill Down “Introducing Windows 2000 Routing and Remote Access,” I discussed the Windows 2000 Routing and Remote Access Service (RRAS), which provides support for dial-out connections, dial-in connections, and routing. I also explained the connection and network protocols supported by Windows 2000 RRAS, along with security and integration features. Now, it’s time to start configuring your RRAS servers, starting with a network address translation (NAT) proxy.

Configuring a network address translation server (Internet gateway)
The Routing and Remote Access Server Setup Wizard, which runs when you enable the RRAS service, gives you five options for settings up a Windows 2000 RRAS server. The first wizard option, Internet Connection Server, lets you configure a Windows 2000 RRAS server to share its Internet connection, and function as a gateway to the Internet for other computers on the server’s local network.

In this configuration, the server sits on both the public Internet and the private local network as illustrated in Figure A. The client computers reside on the local private network, and the server performs the necessary NAT required to enable the clients to connect to the Internet. This option actually offers two different methods to support the Internet connection. The first method uses Internet Connection Sharing (ICS), which also is available in Windows 2000 Professional and Windows 98SE. The second method provides essentially the same function but much more flexibility for configuration. Before diving into NAT setup, though, take a minute to get a background understanding of NAT.

Figure A
NAT enables computers on a private, non-routable subnet to access the Internet.

Understanding network address translation (NAT)
To configure a NAT server, you need to understand the different functions that the NAT server performs. NAT handles three main responsibilities, each performed by a different RRAS component. Address translation is the first function the NAT server performs by translating IP address and TCP/UDP ports for packets traveling between the public interface (the Internet) and the private local network. This is the function that enables clients to reside on a private, non-routable subnet but still gain access to the Internet. The server handles the translation, replacing its own IP address for the client’s address, enabling the packets to be routed back. The server replaces the IP address for incoming packets in the same fashion, applying the local address of the target client.

The second function the NAT server performs is address allocation. As in the case of ICS, the NAT server can allocate IP addresses to clients that are configured to obtain their address leases via DHCP. This function isn’t a necessity if you want to use a different subnet from the default of 192.168.0.n or if you already have a DHCP server on the network to handle address allocation. The following are the network IDs reserved for private networks:
  • with subnet mask
  • with subnet mask
  • with subnet mask

The third function the NAT server performs is DNS resolution. Clients submit DNS requests to the NAT server. The NAT server then forwards the requests to the DNS servers configured in the NAT server’s TCP/IP settings. The NAT server redirects replies to the requesting client.

The NAT server performs address translation through the use of a NAT table. Here’s how it works: A client on the private network generates packets for a public node, and the server intercepts that traffic (since it functions as the default gateway for the client). The server replaces the client’s IP address with its own public address and replaces the source port with a different, unique port number.

For example, assume that the server resides on the public interface and uses a private interface of A client on the private network at requests a Web site on a standard TCP port 80. The server replaces with, and replaces the port with, say, port 5000. The server stores the replacement data in the NAT table and sends the packet. When a packet comes back, it checks the NAT table, reverses the translation according to the data in the packet and in the NAT table, and forwards the packet to the correct client.

NAT works just fine as long as the IP address and port data are contained in the IP header of the packet. When the address or port data is contained in the body of the packet (also referred to as the payload), translation could fail. For example, PPTP doesn’t use a TCP or UDP header but instead uses a Generic Routing Encapsulation (GRE) header with a tunnel ID stored in the GRE header identifying the data stream. Certain FTP operations, as well as other IP operations, can also have problems with NAT because of the way the packets are built.

To get around this problem, the NAT server needs a means of determining the appropriate address and port information for routing the packets. NAT servers, including Windows 2000 RRAS, employ NAT editors to perform this additional processing. Windows 2000 RRAS includes NAT editors for FTP, ICMP, PPTP, and NetBIOS over TCP/IP. The NAT editor analyzes the packet and performs the necessary additional translation to send the packet on its way, doing the same for incoming packets before passing them to the destination client on the private network. Figure B illustrates the concept.

Figure B
NAT editors provide additional processing for both incoming and outgoing traffic where needed.

Internet Connection Sharing (ICS)
The first of the two methods that Windows 2000 offers for NAT services is Internet Connection Sharing (ICS). ICS is included with Windows 2000 Server, Windows 2000 Professional, and Windows 98SE. In an ICS connection, the server shares its Internet connection and acts as a proxy for the clients to enable them to use the connection, as well. That connection could be something as simple as an analog dial-up connection or a dedicated, high-speed connection, such as a T1.

The practicality of the connection depends on the type of connection, number of clients, and ways in which the clients use the connection. Several clients sharing a 56K dial-up connection to access e-mail is a practical application of ICS, but sharing a dial-up line such as this to enable Web browsing or concurrent FTP sessions isn’t very practical. Even so, ICS presents an easy way to share a single connection and can provide a layer of security between the clients and the Internet because the local clients reside on a non-routable subnet. Here’s why: Enabling ICS on a Windows 2000 Server computer automatically assigns the IP address to the server’s local network interface, using a Class B subnet mask of The server then allocates IP addresses to clients when they start up, assigning addresses in the range through, much like a DHCP server. You can also configure clients to use static addresses in that range, if preferred. The ICS server provides DNS proxy name resolution for the clients and performs the network address translation necessary for the clients to use the connection. This network address translation and the fact that the local network resides on a non-routable private subnet can provide a layer of protection for the clients, helping isolate them from the Internet.

If you decide to use ICS, you don’t use the RRAS console to configure it. If you select ICS in the RRAS Wizard, the wizard points you to the Network And Dial-Up Connections folder to enable ICS. Simply make sure you have two functioning network interfaces, one for the local network and one for the Internet connection (which can be a dial-up connection). Then, open the Network And Dial-Up Connections folder, right-click the Internet connection, and choose Properties. Click the Sharing tab, and then select the option Enable Internet Connection Sharing For This Connection. Select the network interface through which the connection is shared from the drop-down list, if the server has more than one interface. This is the interface that will be assigned the address. If the shared connection is a dial-up connection, select the Dial On Demand option to enable the server to automatically dial the connection when a client attempts to access an Internet resource. When you click OK, Windows 2000 automatically reconfigures the network address of the computer’s local network interface and begins handling requests from clients for IP address assignment and Internet access.

ICS provides an extremely easy means of setting up a shared Internet connection for clients and is essentially a one-click procedure. What you gain in ease of configuration, you lose in flexibility, however, because ICS offers few configurable options. If you need to use a different subnet or need to control other aspects of the connection, you’ll need to use the second method, NAT.

Starting NAT server configuration
Although both the ICS and NAT features in Windows 2000 perform network address translation, NAT provides full control over server configuration and is the Internet connection sharing option you configure through the RRAS console. You can configure RRAS to function as a NAT server either through the RRAS Setup Wizard or manually. (Skip to the section on completing the NAT server configuration, if you want to configure the NAT server manually.)

When you choose the NAT method in the RRAS Setup Wizard, the wizard first prompts you for the Internet connection for which the server will provide NAT services. You can choose an existing network interface with an Internet connection or direct the wizard to create a new demand dial interface. If the server has more than two additional network interfaces, the wizard prompts you to select the private interface. If there is only one interface, the wizard selects it automatically. After you specify the public and private interfaces, Windows 2000 starts the RRAS, and you can then use the RRAS console to fine-tune the configuration. If you choose the latter option to create a new demand dial interface, Windows 2000 starts the RRAS and then starts the Demand Dial Interface Wizard.

Configuring a demand dial interface
A demand dial interface doesn’t remain connected all the time but instead connects only when a client requests a resource that resides beyond the interface. Using a demand dial interface can reduce costs by reducing connection time for metered services.

The Demand Dial Interface Wizard, which runs as part of the RRAS Setup Wizard, prompts you for the following:
  • Name—This is a friendly name for the connection as it appears in the RRAS console. Choose a name that adequately describes the remote connection.
  • Connection type—You can choose between physical devices such as modems and ISDN adapters or a VPN connection. If you choose a physical device, the wizard prompts you to select the device, which you should already have installed and functioning, as well as the dial-up number.
  • VPN protocol—If you choose a VPN connection for the demand dial interface, the wizard prompts you to select the protocol, whether PPTP or L2TP. If you choose Automatic Selection, Windows 2000 will attempt to use L2TP for the connection, and if that fails, it will use PPTP.
  • Server address—For VPN connections, specify the IP address or Fully Qualified Domain Name (FQDN) of the remote VPN server.
  • Protocols and security—The wizard prompts for the protocols that should be routed through this connection, which include IP and IPX. You also specify a user account to use for authentication and set other security and connection options, such as password handling and connection scripting.

Completing the NAT server configuration
After you run the wizard and configure the server for NAT, you’ll probably need to fine-tune the configuration. Or, you might have already configured the server for another purpose, and you can’t use the wizard to configure the server for NAT (since you’ll lose your current configuration). In that case, you can configure the server manually. This section explains how to do that, as well as modify the configuration for both situations.

Enabling NAT manually
If you’ve already configured the server through the wizard for a function other than NAT (such as dial-up remote access) or simply prefer not to use the wizard, you can manually configure the server for NAT. (You don’t need to perform this step if you’ve configured NAT through the wizard.) Open the RRAS console and expand the server in the left pane. Right-click General, and select New Routing Protocol. Select Network Address Translation, and click OK. RRAS adds a Network Address Translation node under the IP Routing branch. The next step is to add the interfaces for NAT.

Adding a NAT interface
After adding the NAT protocol, you need to specify the interfaces on which the RRAS server should perform translation. If you configure the server through the wizard, the wizard prompts you for the two minimum interfaces, the public Internet connection and the private network interface. However, Windows 2000 RRAS can provide NAT services on more than one interface. If you have multiple network subnets, for example, you could configure the server with a network interface for each and have the server provide NAT for all of the subnets.

To add NAT interfaces, open the RRAS console and expand the server. Open the IP Routing branch, right-click Network Address Translation, and choose New Interface. Select the interface for which you want to add NAT services, as shown in Figure C, and click OK.

Figure C
Add the public and private interfaces to the NAT protocol through the RRAS console.

Windows 2000 then prompts you to specify whether the interface is public or private. Select the option Private Interface Connected To Private Network to identify the interface as residing on the private side of the server. Select Public Interface Connected To The Internet if the interface resides on the public side of the server.

Selecting the latter option enables the Translate TCP/UPD Headers option. Select this option to have the server translate TCP and UDP ports in addition to the IP address for translated packets. In most cases you’ll need to select this option to enable NAT to function properly for the private networks.

The property sheet displays two additional pages if you select the public interface option: Address Pool And Special Ports. You can reach these pages later, if needed, by double-clicking the public interface. You use the Address Pool page to configure the range of IP addresses assigned by your ISP for your network’s use. The Special Ports page lets you define special translation properties for specific TCP or UDP ports.

Configuring address ranges
Use the Address Pool tab on the NAT interface’s property sheet to specify the range of addresses allocated by your ISP to the public side of your network, as shown in Figure D. RRAS uses this pool of addresses for mapping packets to and from the private network. If your ISP allocated only one IP address, you can leave this list empty. In this situation, the RRAS server requests unique TCP and UDP ports from the protocol stack, using those ports to translate packets to and from the private network. If you have multiple public IP addresses, the server leaves the ports as is and only translates the IP address, selecting a currently unused address from the pool. If the server runs out of addresses, it switches to translating the ports, just as it does when only one IP address is available.

Figure D
Specify the range of addresses the NAT server uses for translating traffic to and from the private network.

You need to add the address range to the list if your ISP allocated more than one. Once you’ve done that, you can apply reservations to reserve one or more of the allocated addresses for other nodes on the public side of your network (for other servers, for example).

To do this, first click Add on the Address Pool page to open the Add Address Pool dialog. Type the starting address of the allocated range and the subnet mask. RRAS determines the ending address automatically. Or, you can specify the starting and ending addresses if you can’t use a subnet mask to define the range.

Next, click Reservations if you need to reserve one or more addresses for other nodes on the public side of the network or if you need to reserve an IP address for use by a computer on the private side of the network. For example, you might have a Web server located on the private network and need to reserve a public address for it, mapping the public address to the Web server’s private address.

Finally, click Add in the Reserve Addresses dialog to open the Add Reservation dialog. Specify the public IP address to reserve and the IP address of the computer on the private side that will use that address. If the computer needs to be accessible to Internet clients, select the option Allow Incoming Sessions To This Address.

Configuring special ports
In most cases you can allow NAT to handle TCP and UDP port translation on its own. In special circumstances, however, you might need to direct the server to handle specific ports in a certain way. For example, if a packet comes in for a specific port, you might need that traffic redirected to a specific port on a specific private IP address. Here’s an example: Assume you have a Web server on the private network, but it’s using port 8080 instead of the default port 80 and you want to map incoming port 80 traffic to port 8080. So, you’d configure a special port so that incoming traffic bound for port 80 is translated to port 8080 on the appropriate IP address. You can have the special translation apply to all incoming traffic on the interface or only to traffic for a specific public IP address.

To configure a special port, click the Special Ports tab. Select either TCP or UDP from the drop-down list, as appropriate; then click Add. To translate the port for all addresses on the public interface, select On This Interface. Otherwise, select On This Address Pool Entry, and enter the IP public address for which the special translation needs to occur. In the Incoming Port text box, type the port number to which incoming traffic is directed. Specify the private IP address to which the traffic needs to be routed and the control destination port on the private computer in the Outgoing Port box. In the previous example of the Web server, you’d put 80 in the Incoming Port box and 8080 in the Outgoing Port box.

Configuring general NAT properties
After you configure each interface as I’ve explained, you need to turn your attention to general NAT service properties. In the RRAS console, expand the server, right-click Network Address Translation under IP Routing in the left pane, and choose Properties. The General page of the NAT properties lets you configure the level of logging by NAT in the System log. The options are self-explanatory.

The Translation page lets you specify how long the NAT server maintains port mappings in the NAT table. There are separate settings for TCP and UDP.

Configuring applications
The Translation page of the NAT server’s properties also lets you configure applications for NAT. For example, you might run an application that uses non-standard ports to communicate with a server on the Internet, which is common with Internet games such as Subspace or Diablo. So, you can configure the NAT server to provide the appropriate port translation, either for UDP or TCP, as needed.

To configure applications, open the properties for NAT, click the Translation tab, and then click Applications. Click Add to display the Internet Connection Sharing Application dialog. Provide the following information:
  • Name—This name serves to identify the application in the RRAS console’s list.
  • Remote server port number—Specify the port on the remote server that needs to be remapped on the private network.
  • TCP or UDP—Select the port type for the remote server port.
  • Incoming response ports—Specify the port translations for the ports on the private network. You can specify TCP and UDP ports separately.

Add additional port assignments as required by the applications you use. A given application could require more than one entry.

Configuring address assignment
The clients on the private network must reside on the same subnet as the NAT server’s private network interface. You can configure the clients for static IP addressing or rely on DHCP for address assignment. While you could install a DHCP server to provide addresses to the clients, the NAT server can also handle that function, eliminating the need for a separate DHCP server.

To configure address assignment, open the RRAS console, and expand the server in the left pane. Open the properties for NAT under IP Routing, then click the Address Assignment tab. Select the option Automatically Assign IP Addresses By Using DHCP; then specify the address range by entering the starting IP address in the range and the subnet mask. Click Exclude if you need to exclude one or more addresses from DHCP assignment, making those available for other servers or fixed-address nodes on the private network.

Configuring name resolution
The private clients need a server to provide proxy DNS lookup, and the NAT server can optionally fill that role if no other DNS proxy is available. To configure DNS lookup on the NAT server, first configure the NAT server’s TCP/IP properties on the public interface to add the DNS servers the NAT server will use for lookup. Then, open the RRAS console, and open the properties for NAT under IP Routing. Click the Name Resolution tab, and select the option Clients Using Domain Name System (DNS). If you’re using a demand dial interface to connect to the Internet, select the option Connect to the Public Network; then select the demand dial interface from the drop-down list.

What’s next?
This time around, we looked at network address translation and configured a Windows 2000 RRAS server to function as a gateway between a private network and the Internet. In another Daily Drill Down, I’ll take a look at configuring a remote access server to support incoming connections.

Jim Boyce is a former contributing editor and monthly columnist for WINDOWS Magazine. Jim has authored and co-authored over 40 books about computer software and hardware. He has been involved with computers since the late 1970s as a programmer and systems manager in a variety of capacities. He has a wide range of experience in the MS-DOS, Windows, Windows NT, Windows 2000, and UNIX environments. In addition to a full-time writing career, Jim is a founding partner and vice president of Minnesota Webworks, a Midwest-based Web development firm.

The authors and editors have taken care in preparation of the content contained herein, but make no expressed or implied warranty of any kind and assume no responsibility for errors or omissions. No liability is assumed for any damages. Always have a verified backup before making any changes.

Editor's Picks