Inside Windows Server 1002003 [Electronic resources] نسخه متنی

Configuring an Internet Gateway Using NAT

Figure 20.34 shows a typical SOHO network configuration. In this example, a single server running Windows Server 2003 supports all network services, including acting as a gateway to the Internet.

You may look at this diagram and wonder why the vendor who set up the system didn't simply use a low-cost SOHO appliance as the gateway. Part of the reason is money. The additional equipment isn't free and many SOHO installations are

extremely price sensitive. A better reason, technologically speaking, is the generous feature set supported by Windows Server 2003. This feature set includes a firewall, flexible inbound port forwarding, the ability to have multiple public IP addresses, and virtually unlimited client connections.

Using a single server for file-and-print and network services isn't the most fault tolerant solution, of course, but small business owners are accustomed to thinking in terms of bottom line rather than business recovery. This same business probably has critical machines on the operations floor and rolling stock in the parking lot that do not have redundancy, either. Most small business owners measure risk against cost and decide to have a single server. You can mitigate the impact of a downed server by designating one or more XP desktops as alternate Internet gateways. An XP desktop functions tolerably well in these circumstances and it only takes a second to make the configuration change as long as you already have a second network adapter in the desktop.

Setting up a Windows Server 2003 as an Internet gateway involves installing an additional network interface that connects to the Internet (this could be a network cable connected to a cable modem, a DSL adapter, or a demand-dial connection) then configuring the following RRAS components:

• Routing service




• Network Address Translation (NAT) service




• Firewall service

If the public interface connects to a DSL provider that requires individual connections, setting up the gateway also involves configuring the integrated

Point-to-Point Protocol over Ethernet (PPPoE) support in Windows Server 2003. See the previous section, "PPPoE," for details.

Functional Description of Network Address Translation

If the server in Figure 20.34 were configured as a standard router, each client in the office would need a public IP address. This presents two problems. One involves security. The clients would be exposed to the Internet where all the bad guys can find them and do nasty things to them.

The other problem involves architecture. The supply of available IP addresses is dwindling rapidly. IPv6 will alleviate this problem, and the security problem as well, but it will take many years for the deployment of IPv6-capable devices and hosts to reach the point where address availability is not an issue.

For the time being, NAT solves both problems by a trick that any teenager would love. NAT translates one IP address into another IP address, permitting a client to be something different on a private network and a public network. NAT is documented in RFC 1597, "Address Allocation for Private Internets," and RFC 1631, "Network Address Translation (NAT)."

Address Mapping

To take advantage of NAT, you need to deploy IP addresses from one of the reserved ranges set aside for private use. Internet routers are configured to block any traffic from these reserved ranges. They are as follows:

Class A:
10.0.0.0 to 10.255.255.255

Class B:
172.16.0.0 to 172.31.255.255

Class C:
192.168.0.0 to 192.168.255.255

As an administrator thinking about how to implement NAT, you are free to choose any of the private address ranges that fit your needs. The most flexible is the Class A because of the large number of networks and hosts it can support, but the Class C range is simpler to manage for a small network.

Here's how NAT works. Consider a client on the private side of a NAT device. The client makes an HTTP connection to a web server on the public side. The client sends HTTP traffic to the web server via well-known Transport Control Protocol (TCP) port 80. The client selects an unused TCP port on which to listen for a response. This source port is included in the datagram sent to the web server so the server knows where to reply.

When the HTTP packet from the client arrives at the NAT device, the NAT device modifies the IP header by substituting its own public IP address for the client's address then sends the packet on its way.

The web server responds to that IP address, which returns the traffic to the public interface on the NAT device. The NAT service swaps back the client's IP address and sends the packet into the private network where it is routed to the client.

Port Mapping

True NAT uses a one-to-one mapping between a private address and a public address. This protects the client's identity, but it does very little to minimize the use of public IP addresses. That is the job of another feature called

Port Address Translation , or PAT. The NAT service in Windows Server 2003 implements both NAT and PAT.

Here's now PAT differs from NAT. When a private client sends traffic to a host on the public side of the NAT device, the NAT device not only substitutes its public IP address, it substitutes a random TCP port number for the port on which the client is listening for a response. It keeps the original IP address and port number in a lookup table.

When the web server responds, it returns an HTTP packet to the public interface on the NAT device using the number of the substituted port. The NAT device swaps the client's information back into the packet then sends it onto the private network where it is routed to the client.

So, the difference between NAT and PAT lies in the way they use the public address. With pure NAT, you would need a public address for each client on the private side. With PAT, you essentially multiplex the private clients onto one public IP address.

Windows Server 2003 RRAS, like most NAT devices, uses a combination of NAT and PAT. You can see the address and port mappings used by the Windows Server 2003 NAT service by opening the RRAS console, right-clicking the NAT interface, and selecting the Show Mappings option.

If the public interface of the RRAS server has more than one IP address, the NAT service maps private clients one-to-one with the public addresses until it arrives at the last available address. It then shifts to PAT for the remainder of the clients. This is sometimes called

NAT overloading . There is no performance difference between NAT and PAT.

NAT Editors

In addition to simply translating IP header addresses, NAT may need to peer inside the TCP or User Datagram Protocol (UDP) packet itself to find source IP addresses put there by an application.

For example, when you ping a host, the ICMP packet contains the IP addresses of the source and destination hosts. The same is true for the FTP port command and other applications. In addition, there are instances when source addressing is used outside of the TCP or UDP payload. This occurs in Point-to-Point Tunneling Protocol (PPTP), where the Generic Routing Encapsulation (GRE) protocol handles IP communication with the TCP and UDP datagrams and their port number tunneled inside the packet. (The embedded IP addresses in L2TP over IPSec are encrypted, making them impervious to NAT translation.) Windows Server 2003 NAT uses information stored in special configuration files called

NAT Editors to determine the location of IP address information in an application packet. Each application requires its own NAT Editor. Windows Server 2003 has NAT Editors for FTP, ICMP, and PPTP. NAT Editors are not included for Simple network Management Protocol (SNMP), Lightweight Directory Access Protocol (LDAP), Microsoft COM, and Remote Procedure Call (RPC).

Inbound Connections Through NAT

As long as a connection to a public host originates from a client in the private network, the NAT service will permit inbound traffic from the public side. If the connection request originates on the public side, however, NAT blocks the request.

There may be situations when you want clients on the public side of the NAT to connect to a server on the private side. Linux calls this

port forwarding .

Routing inbound traffic backwards through NAT is a little like taking a guest to a State Department dinner. Admittance is strictly by invitation only. Inbound mapping through NAT is done on a port-by-port basis. For instance, if you have a web server in the private network that you want to make available to public clients, you can configure the NAT router to accept inbound connections directed at port 80 and route them to the selected web server. A user on the public side who points a browser at the IP address of the NAT would see web pages returned by the server on the private side.

RRAS has two ways to configure port forwarding through NAT. The simplest way is to associate a port on the public side with a server and a port on the private side. This is done using the Services and Ports tab in the Properties window of the public interface. Figure 20.35 shows an example.

If you want to publish a private web server on the public side, select the Web Server option. This opens an Edit Service window where you can define the private address and ports.

This one-to-one mapping of external well-known ports to internal servers works fine so long as you have only one server on the private side hosting a particular service. But what if you have three web servers on the private side that you want to publish on the public side? You could use different ports on the public side, but this would require using non-standard ports, which complicates the connection for clients.

A better solution is to obtain a pool of addresses from your ISP then configure the public interface to use this pool for inbound NAT mapping. You can then select an IP address and port number on the public side to represent each server and service on the private side.

You can assign addresses to the public interface using the Address Pool tab of the Properties window for the public interface.

If you have cannot obtain a contiguous set of addresses from your ISP, you can enter the addresses one at a time as separate address ranges with a range of 1 address. There is no need to stop and start the RRAS service after making a new port mapping.

NAT Deployment Checklist

Here are the key points to remember about NAT before installing and configuring the service:

• NAT requires a separate IP network for the local LAN that either uses a private IP address space (preferred) or public addresses that are unique in your organization.




• NAT maintains a volatile mapping of TCP/UDP ports and private IP addresses. If you down the server, this map is lost and clients must reconnect to the public hosts to get new mappings.




• NAT can use multiple public IP addresses for inbound port forwarding if you have several servers hosting the same service.




• If you have a unique application that inserts IP addresses into the payload of a TCP or UDP packet, or puts IP address information into another protocol, you must configure a NAT Editor to translate the addresses properly or the application will not work through NAT.




• Network clients must be configured to use the NAT router as a gateway to the Internet. This is most easily done using DHCP, but you can manually configure the IP stack on the clients, if you prefer.

Internet Connection Sharing (ICS)

Creating an Internet gateway using the NAT service available in RRAS requires some fairly sophisticated skills. You need to know how to set up RRAS as a router, how to configure NAT and the interfaces within NAT, how to set up clients to use the NAT server as a gateway, and how to handle DNS requests from clients on the private side of the NAT server.

For a small office with a single server running Windows Server 2003, there is a much simpler way to configure the gateway. You can click two selections and restart the clients and call it a day. This convenience comes to you in the form of

Internet Connection Sharing , or ICS. ICS is also available in XP desktops, Windows 2000 servers and desktops, Windows ME and Windows 98 Second Edition.

ICS is enabled via the Network Connections window as an option in the Advanced tab of the Properties window of the public interface (see Figure 20.37).

ICS is a suite of services that automates the creation of an Internet gateway. Here is what happens automatically when you enable ICS on the public interface:

• The IP address of the private interface is automatically changed to 192.168.0.1. This address cannot be changed, bypassed, or overridden. (There is a Registry hack for ICS in Windows 98/ME, but not for Windows Server 2003/XP.) If you have already configured the network with a different private address, you will have to change your selection.




• Then, if the public interface is a circuit-switched device, it is reconfigured as a demand-dial router.




• A small DHCP service is initialized to pass out addresses in the 192.168.0.0/24 network. This service is controlled by the Ipnathlpr.dll. It is not a full-blown installation of DHCP.




• A small DNS proxy service is installed, also controlled by Ipnathlpr.dll. This proxy passes DNS queries to the DNS server configured on the public interface. This generally comes from the service provider via DHCP.

Internet Connection Firewall (ICF)

Although NAT is a key component of a firewall, NAT in and of itself is

not a firewall. In other words, NAT takes no active part in blocking traffic directed at ports on the public side of an RRAS server. Microsoft responded to the presence of an integrated firewall in Linux with a new feature in Windows Server 2003 and XP called the

Internet Connection Firewall , or ICF.

Compared to more sophisticated (and costlier) firewall solutions, such as Microsoft's Internet Security and Acceleration (ISA) Server or CheckPoint Firewall, ICF looks relatively pale. It lacks the enterprise controls and extensive reporting you'd expect from an enterprise firewall solution; but for its niche, which is to act as a firewall for ICS, it performs very well.

As of this writing, there have been no tactical or strategic weaknesses identified (or at least reported) in ICF. The service lacks many of the features you would expect in a commercial firewall, but as a way of blocking access to the Internet-facing side of a server, it seems to do the trick. With ICF in place, all ports resisted probing by the typical tools used to do such things. For instance, the public interface came up negative when probed by Legion and LanGuard and the ShieldsUp page at the Gibson Research web site, www.grc.com.

ICF is enabled in one of two ways. If you use NAT, it is an option on the private interface under NAT in the RRAS console. If you use ICS, it is an option on the same properties page where you enable ICS.

Configuring NAT in RRAS

Setting up NAT on an Internet gateway is much simpler than configuring a standard routed connection because there is no need for additional services from your ISP. Here is a quick checklist to use for your preparations:

• If you have a DNS server that is the Start of Authority (SOA) for your public DNS namespace, you'll need to either keep the server in the public network or map port 53 in NAT to point at the DNS server. If you move the DNS server into the private address space and do not map the original address to the public interface for NAT, you will need to contact your ISP or the operator of your top-level domain (TLD) to change the address of the name server at the TLD servers. Do the same for any other servers that are moved to the private side, such as your email server (which uses an MX record in DNS).




• The gateway needs at least two network interfaces: one for the private side and one for the public side. The public interface can be a circuit-switched interface (modem or ISDN) or a dedicated interface.




• Do not use a domain controller as a NAT router. You will get erratic results, especially with DNS and LDAP.




• RRAS must be configured to support routing.




• The circuit-switched interface, if any, must be configured for demand-dial routing. This is done from the RRAS console by opening the Port Properties window, double-clicking the device to open the Configure Device window, then selecting the Demand-Dial Routing Connections option.




• Some ISPs have fair use policies barring NAT connections to their systems. Check to make sure so you won't get your service disconnected.

With these prerequisites in place, you're ready to set up the gateway.

Configuring NAT and ICF

Start by making sure that the connection to the Internet at the gateway server is fully functional. Then load interfaces into NAT and configure them as directed in Procedure 20.14.

Procedure 20.14 Configuring NAT and ICF

1. Open the Routing and Remote Access console.

2. Expand the tree under the IP Routing icon to show the Network Address Translation icon.

3. Right-click the Network Address Translation icon and select N

   EW I

   NTERFACE from the flyout menu. The New Interface For Network Address Translation window opens.

   Double-click the public interface. A Properties window opens for the interface.

4. Select the Public Interface radio button then check the Translate TCP/UDP Headers option and the Enable Firewall On This Interface option. Click OK to save the change.

5. Double-click the private interface. A Properties window opens for the interface. Select the Private Interface radio button and click OK.

If you use DHCP, change the configuration settings to point your clients at the IP address of the NAT server. If you do not currently use DHCP but would like to start because of NAT, you can simplify your DHCP setup by using the DHCP Allocator in NAT. You can also use NAT to configure a DNS proxy.

Open the Properties window for the NAT service and select the Address Assignment tab (see Figure 20.38).

The simplest configuration is to check the Automatically Assign checkbox and leave the address range at 192.168.0.0/24. This is the same range that would be allocated by ICS.

Select the Name Resolution tab and select Resolve IP Addresses for Clients Requesting DNS. This configures NAT to forward DNS requests to the DNS server assigned to the public interface. Make sure one the DNS server is available before you make this change.

Enabling ICS and ICF

After verifying that you have a reliable Internet connection on a public interface, enable ICS by following the steps in Procedure 20.15.

Procedure 20.15 Enabling Internet Connection Sharing and Internet Connection Firewall

1. Check that no users have open files or connections on the server. This is necessary because the next steps result in a change of the server's private IP address. Use the Computer Management console, Compmgmt.msc, to check for live sessions.

2. Open the Network Connections window.

3. Open the Properties window for the public interface.

4. Select the Advanced tab.

5. Under Internet Connection Firewall, select the Protect My Computer option.

6. Under Internet Connection Sharing, select the Allow Other Network Users to Connect option.

7. Click OK to save the changes. The system presents a warning that the IP address of the local area connection will be changed to 192.168.0.1 and that this may cause loss of connection to the local network. Click Yes to acknowledge the warning and proceed with the ICS installation. The loss of network connection is temporary until the clients acquire a new network address using DHCP.

It only takes a few seconds for the updates to take effect. Use ipconfig to verify that the IP address of the LAN interface has changed to 192.168.0.1.

At each DHCP client, do an ipconfig /release and ipconfig /renew (or the winipcfg equivalent for Windows 9x clients) to obtain a new DHCP address in the 192.168 network. Verify with Ping that you can touch the gateway and the Internet from the client. Open Network Connections at an XP desktop and verify that you have an Internet Gateway icon.

If you are using an ISDN line to connect to the Internet, keep an eye on usage for a while. The ICS features should not keep the line hot, but you never know what the clients might do after they get access to the Internet. Use Network Monitor at the server to sniff for traffic if the line never goes down.