Internet & Intranet Security

11.4 NETWORK ADDRESS TRANSLATION

Many contemporary firewall systems provide support for what is known as network address translation (NAT). NAT basically means that an organization can use private IP addresses on its own network (i.e., the intranet) to increase its address space. If IP packets are sent to the Internet, the private IP addresses are dynamically converted to IP addresses that have been officially assigned to the organization and that are routable on the Internet. Similarly, if IP packets are received from the Internet, the officially assigned IP addresses are converted back to the appropriate private IP addresses. Based on the private IP addresses, the IP packets are then routed on the intranet to their appropriate destination.

In RFC 1918 and BCP 5 [3], three blocks of the IP address space are reserved for private use. The blocks are summarized in Table 11.1.

A firewall that supports NAT works similarly to a transparent firewall. IP packets with unknown destination IP addresses are routed to the network segment that hosts the firewall configuration. The firewall, in turn, grabs the the IP packets that request a TCP connection establishment and establishes the connection on behalf of the client. In addition, a firewall that supports NAT also substitutes the private IP addresses (used on the intranet) with officially assigned IP addresses (used on the Internet). Obviously, this substitution is reversed in the opposite direction.

For example, we assume a company that is officially assigned an IP class C address. For its internal use, the company uses IP addresses from the 20-bit block itemized in Table 11.1 (i.e., 172.16.0.0 to 172.31.255.255). As illustrated in Figure 11.6, an FTP client (on the left) with a private IP address C wants to retrieve a file from a destination FTP server with IP address S located somewhere on the Internet (on the right). Therefore, the client makes use of a transparent firewall with IP address F (in the middle). The transparent firewall, in turn, actively supports NAT.

Figure 11.6: A firewall supporting NAT.

In this situation, the following steps are performed to establish a connection between the FTP client and the FTP server:

1. The FTP client sends out a TCP connection establishment request message to port 21 of the destination FTP server (the notation c@C > 21@S indicates that a message is sent out from source IP address C and port number c to destination IP address S and port number 21). Because the FTP server is not directly reachable by the client, the message is forwarded to the network segment that hosts the firewall and its proxy servers.

2. The FTP proxy server of the firewall grabs the initial TCP connection establishment request message, authenticates and authorizes the user, and eventually forwards the message to the destination FTP server. In this case, however, the message source is initialized with an IP address F and a randomly chosen and dynamically assigned port number (the port number is specific for this particular FTP session).

3. The destination FTP server receives the TCP connection establishment request message and eventually establishes a TCP connection to the FTP proxy server. Any FTP command that is sent out by the FTP client is then automatically forwarded by the FTP proxy server to the destination FTP server.

In the opposite direction, FTP application data are sent from the destination FTP server to the proxy server of the firewall, and from the proxy server to the FTP client. Note that in this direction, the source IP address is usually not substituted by the proxy server, and that officially assigned IP addresses may appear on the intranet accordingly (in the source IP address fields).

Transparent application gateways provide the most recent and most sophisticated firewall technology available today. Whenever possible, this technology should be the preferred one to use, as it does not require user procedures or client software to be modified. Unfortunately, most firewalls that implement this technology also must use NAT. The IETF has debated NAT for some time and there is considerable feeling that it is an unfortunate technical approach that is justified only when an organization is unable to acquire adequate IP address space. Because of its increased address space, the use and wide deployment of IPv6 will make NAT obsolete in the future.