Quick Start Guide to Network Address Translation

For all intents and purposes, the most simple way to provide your internal network with shared access of a broadband (or for that matter dial-up or ISDN) Internet connection is the Internet Connection Sharing (ICS) feature of Windows 2000. However, ICS also imposes a number of limitations that make it a poor choice for environments that include Active Directory. For example, when the external connection (the one to which a public IP address is assigned) is shared, it will automatically give the internal adapter an IP address of 192.168.0.1. On top of this, ICS automatically configures itself as a mini-DHCP server, allocating addresses to internal clients in the 192.168.0.0/24 range. Finally, ICS also works as a DNS proxy, expecting that your clients will use the ICS system as the destination for all DNS-related queries to the public Internet.

While this may work fine for small LANs, ICS makes life complicated on networks that already have an IP addressing structure in place (either through the use of static addresses or a via a separate DHCP server), as well as those running Active Directory (and by extension, DNS). In cases where you don't want to undo your current IP addressing, and want a more robust Internet sharing solution, Windows 2000 NAT is the answer.

In this quick guide, I assume that the server on which you want to configure NAT is running Windows 2000 Server at a minimum, and has two network cards installed - one connected to your external network (using a DSL or cable connection, for example) and one connected to your internal LAN. NAT can also work with dial-on-demand modem or ISDN connections, but that's another topic for another time.

The configuration of NAT in Windows 2000 is handled via Routing and Remote Access. Although the service is installed by default, it usually will not be enabled. If the service is not present on your system, it can be added via Windows Components in the Add/Remove programs applet in Control Panel.

The first step in the configuration process is to open the RRAS Administrative Tool, right-click on your server in the console, and choose to enable and configure routing and remote access. This will launch the RRAS configuration wizard, with the choices shown below. For the purpose of this configuration, I'm choosing the manually configured server option, just in case some of you already have RRAS running on your server.

After choosing the manual option and exiting the wizard, the RRAS service will start.

In order to configure NAT, you'll need to expand the IP Routing section and, quite oddly, right click on the General item (this is obviously an interface error, as you should instead need to right click on IP Routing). From the shortcut menu, choose New Routing Protocol, as shown below.

From the New Routing Protocol tab that opens, choose the Network Address Translation option, and press OK. This will add NAT to the interface, under the IP Routing parent item. At this point, all you have done is enabled the ability to configure NAT. Until interfaces are configured, your NAT server will still not do anything NAT-like. Right click on Network Address Translation and choose the New Interface option, as shown below.

The interface will present you with a list of interfaces available on the system. To begin, choose the interface that you intend to use as your internal interface (in reality, it doesn't matter whether you configure the internal or external interface first, but I had to start somewhere). This will present the NAT Properties dialog box, as shown below.

The internal interface lacks much in the way of configurable elements - in fact, you simply designate it as the private interface and nothing more. After pressing OK, repeat the New Interface process, and add your second interface - this one will act as the external interface connected to the public Internet, as shown below.

Notice that on top of selecting the interface to be the public interface, I also selected the checkbox to translate TCP and UDP headers. This option is intended for NAT implementations where you have only one public IP address to be shared amongst many internal clients. Without this checkbox, you would literally need one public address for each and every internal client. More than likely you only have one "real" IP address (or maybe a couple), so select this checkbox in almost all cases. Once you do select the option to configure an interface as a public interface, you'll notice that two additional tabs appear - Address Pool and Special Ports.

The Address Pool tab allows you to configure your NAT server to use multiple public IP addresses. You would simply click the Add button, and then configure the addresses provided by your ISP. Again, with only a single address, you really have no need for this option. The lower portion of this property sheet gives you the ability to map a specific internal client to one of your public IP addresses if necessary. Again, with only a single address, this is not relevant.

The Special Ports tab allows you to configure your NAT server such that requests to certain ports on your external interface can be forwarded to internal clients. For example, let's say that you have a public web server on your internal network that is using a private IP address. In this case, that server is at 10.1.1.1, as shown in my example below. Based on my configuration, when the public IP address of the NAT server receives a request on Port 80 (the Incoming port), it will forward that request to my internal web server at 10.1.1.1, TCP port 80 (the Outgoing port). I know the terminology there can be a little confusing - however, the Outgoing port is simply the port number on which your internal server is waiting for a connection. In this case, my internal web server is waiting for connections on the default port as well, TCP 80.

By default, your newly configured NAT server will provide a network translation function only - it will neither provide internal users with an IP address nor act as a DNS proxy. However, both options are configurable, as shown below.

At this point, assuming that your external adapter has a public IP address, your NAT server is ready to go. The configuration of your client systems is the last major step. In this example, I'm going to assume that your internal network uses the address range 10.0.0.0 with a subnet mask of 255.0.0.0 - these addresses may be provided manually or by another server running DHCP. Remember, however, that any valid address range can be used with NAT, meaning both public and private addresses (though private would be by far the most common).

The internal or private address on the NAT server should be set to a value like 10.0.0.1 in this example. That address will need to be configured at the default gateway on your client systems, either manually or via changing the properties of your DHCP scope. Assuming that your network is running DNS for the purpose of Active Directory, you should configure your clients such that they point at your local DNS server. This will ensure that they still properly interact with Active Directory. To speed up the name resolution process, consider adding your ISP's DNS server as a forwarder address in your local DNS server's configuration.

Given this configuration, not only will internal clients be configured to properly interact with Active Directory, but they should also have no issue connecting to Internet resources.

Dan
http://www.2000trainers.com