test

SunScreen 3.2 Administrator's Overview

Chapter 7 Network Address Translation

For a system to communicate with other systems on the Internet, it must have an IP address--a unique 32-bit number that identifies the system. The rapid growth of the Internet has brought about a shortage of IP addresses. Network address translation (NAT) provides a solution for this shortage. This chapter contains information on:

Network Address Translation

Network address translation 033enables a Screen to translate an internal network address to a different public network address. As it passes packets between an internal host and a public network, the addresses in the packet are replaced with new addresses transparently, checksums and sequence numbers are corrected in both the IP header and the TCP or UDP header, and the state of the address translation is monitored. You specify when a packet using ordered NAT is applied based on source and destination addresses.

SunScreen NAT gives you fine-grain control by adding ordered NAT translations, allowing table entries to intersect, and enabling you to specify when to have NAT translate the source or destination addresses.

Note -

Be sure to configure your NAT rules so they do not perform address translation while an internal host is attempting to communicate directly with the Screen

Services such as FTP also carry IP address information. These packets must also be changed, ensuring that the checksums and sequence numbers are correct. All of this is done inside the Screen's kernel to ensure high-speed processing and transparency to the end user and applications. NAT is stateful, which increases the efficiency of lookups in the address translation table by using address hashings and checksum adjustments that use differential checksum calculations.

NAT is typically used when:

NAT lets you use unregistered Internet addresses to number your internal networks and hosts and still maintain full connectivity to the Internet. The Internet Assigned Numbers Authority (IANA) has reserved the following three blocks of the IP address space for private internets:

With this approach, you can use a registered (public) Class C address space, which offers about 254 externally routable addresses, to provide connectivity for an unregistered Class B network, which supports approximately 65,000 hosts or 255 networks of 254 hosts (internally).

NAT Rules

There are two types of NAT rules: static and dynamic. Static NAT rules provide a one-to-one translation of addresses. Dynamic NAT rules provide an N-to-M, typically many to one, translation of addresses.

NAT rules are specified by their type (STATIC or DYNAMIC), their source and translated source address, and their destination and translated destination address. Addresses in NAT rules use the same set of address objects used in other rules.

NAT rules are ordered. The first NAT rule that matches a packet takes effect, and no other NAT rules apply. Therefore, place specific NAT rules first, and broader NAT rules later.

Valid translations are:

You cannot translate both the source and destination addresses in any single packet with either a single translation or in a combination of translations. A nontranslating NAT rule may be placed ahead of more general NAT rules, to override part of the later, more general NAT rule.

Static NAT

Registered addresses are necessary for advertised kinds of resources, such as publicly accessible servers on your network, because these machines must be at well-known, fixed addresses. Static NAT is frequently used to provide public access to HTTP or FTP servers that use private addresses. These servers must use static NAT reverse rules so that other hosts can use the same registered addresses to reach them, You must generate the reverse rules.

One-to-One Translations

Use static NAT rules to make one-to-one translations between either a single pair or multiple pairs of addresses. Most commonly, static NAT rules are used to translate an advertised address for a public server to a different address.

A static NAT rule translates either the source or destination addresses in a packet. In most cases, this means that you will need to define two NAT rules to:

As an example of static NAT rules in one-to-one translation, assume that your public web server has an address of 10.0.0.1 (defined by the address object "private_www") and you want to allow access to this web server through the public address 199.190.177.1 (defined by the address object "public_www"). Assume also that the address Internet represents Internet addresses. To do this requires two static NAT rules, as shown in the table below

Address Range to Another Address Range

You also can use Static translations to translate a range of unregistered addresses to a range of registered addresses. Each range of addresses must contain the same number of addresses.

Dynamic NAT

Use dynamic NAT to translate a set of unregistered IP addresses to a smaller set of registered addresses. Dynamic NAT enables you to connect to a large number of hosts to the public Internet using a limited number of registered addresses.

Unlike static NAT, which sets up a one-to-one translation between internal unregistered addresses and external registered addresses, dynamic NAT creates a many-to-one translation where several internal addresses use the same public address. Dynamic NAT avoids IP address conflicts by maintaining a state table that records five values (source address, source port, destination address, destination port, and protocol) for each TCP or UDP connection. A Screen can multiplex thousands of translations over a single registered address.

Dynamic NAT is unidirectional, meaning that communication can be initiated only internally from the unregistered private network. Dynamic NAT only works when a user originates a connection from inside the firewall; packets from outside that are not in the address lookup table of an established connection cannot identify a host on the private network and are discarded. Dynamic NAT only works for connections initiated from the Source address systems. These generally represent machines with unregistered addresses that you want to translate to registered address.

For example, assume you have workstations with unregistered addresses defined by the address group my_private that you want to allow access to the Internet using a set of public addresses defined by the address group my_public. The address Internet represents the addresses of the internet.

To do this, you define a dynamic NAT rule, as shown in the table below, that specifies that the Source address my_private becomes the translated source address group my_public. Destination and translated destination are the address Internet, which limits the scope of the translation of packets going to or from the Internet.

Table 7-2 A Dynamic NAT Rule

Type 

Source 

Destination 

Translated Source 

Translated Destination 

Comment 

DYNAMIC 

my_private 

Internet 

my_public

Internet

 

Dynamic NAT Collisions

Because dynamic NAT translates a large set of addresses into a smaller set of addresses, the addresses could be translated to the same address and port numbers, in which case the translations are said to collide.

Note -

The chance of such a collision is very small.

Address collisions occur if the Screen cannot translate the address uniquely. An address collision causes the connection to cease. Address collisions occur if all the following conditions are met:

For example, this condition is met if two systems using NAT establish a web connection to www.sun.com.

Because most systems select from a set of at least 32 000 different local port numbers, the chance of this happening is usually small.

Expressed as a probability, the chance of this happening for two systems is equal to 1/M where M is the number of addresses in the Translated Source field. For example, if the Translated Source field contains an address object that represents 10 addresses, the probability of NAT choosing the same translated source address for two systems would be 1/10 or 10 percent.

The probability of a collision is equal to the probability of two systems connecting to the same remote service times the probability of two systems choosing the same local port divided by the number of addresses in Translated Destination.

Translation collisions cause service to be denied to a network user. Translation collisions occur when network software cannot complete the address translation process because two or more packets are not uniquely identified. Each packet must have a destination IP address, a destination port, source IP address, a source port, and protocol if it is to be delivered. These elements are processed as a 5-tuple of information of the form (desaddr, dest port, srcaddr, src port, proto), which is part of the packet header.

A 5-tuple is unique as long as at least one of the five pieces of data that it contains differs from the others with which it is being compared. Since each piece of data has a large number of possible values, the number of possible permutations for the 5-tuple is enormous. Therefore, for a translation collision to occur, multiple internal machines using the same registered IP address must try to gain access to the same registered address at the same destination port number and from the same source port number, all at the same time.

Suppose a user at the unregistered address U5, shown in Table 7-3, attempts to go to a web page at the registered destination address 192.4.15.37 at destination port 80 from source port 34080 through the registered address R5. Another user at U6 can do the same to the same address and destination port through source port 34070, or go to a different web page through source port 34080.

The table below shows the translation of unregistered addresses, Un, to registered addresses, Rn.

Table 7-3 Two Dynamic Addresses

Registered IP Address 

Destination IP Address 

Destination Port 

Source Port 

Protocol 

R4 

192.4.15.37 

80 

34080 (on U5) 

tcp 

R4 

192.4.15.37 

80 

34070 (on U6) 

tcp 

R4 

192.4.15.44 

80 

34080 (on U7) 

tcp 

If a user at unregistered address U7 attempts to go to a web page at the registered destination IP address 192.4.15.44 at destination port 80 from source port 34080 using registered address R4, a translation collision will occur. The user at U7 would have to use another source port to have a unique 5-tuple and avoid a translation collision, which would happen automatically during a subsequent attempt to connect.

Situations such as power failures typically result in translation collisions. When power is restored, all hosts on a network come up at the same time and try to reestablish network connections. Each host's operating system resets its source port counter to a low number. The counters on each machine may take time to cycle up to higher and more randomized port numbers (which are more likely to produce unique 5-tuples). In the interim, translation collisions may cause network service to be denied temporarily. Internal hosts must continue trying to establish network connections until the NAT rules resolve the translation collisions.

Note -

Ports 0 through 1024 are reserved for well-known port assignments and are controlled by the IANA. To avoid conflicts, the Solaris operating environment uses ports that range approximately from 32768 through 65535. Different implementations of TCP/IP in various operating environments have different rules and limits for their optional (ephemeral) port choices.

Choosing NAT Addresses

In all NAT situations, one of the addresses in a NAT translation is virtual. It does not really exist and must be simulated by the Screen and other systems in the network.

Because virtual addresses do not physically exist, how these address are selected and who simulates them is restricted. Simulating a virtual address means providing the functions of ARPing and routing.

In routing mode, the Screen must respond to ARP requests for the public addresses (R2 through R8) because it will be translating public addresses to private addresses. Add an arp entry (using the Solaris command arp -s IP_address ether_address pub) for them. Either add this entry each time that you reboot the Screen or add it to a startup script that runs at boot time. If you are administering the Screen in routing mode remotely, either go to the Screen to add this entry, or have a rule in your policy that allows logging in (rlogin) to the Screen remotely.

In stealth mode, the Screen automatically responds to the ARP requests from a public address so the ARP entry is not necessary.

NAT Examples

The following NAT examples show how to set up NAT when using only one registered IP address, and with two scenarios that illustrate how a demilitarized zone could use registered addresses or unregistered addresses with NAT.

Example One

If you only have one registered IP address (A) and you want to have all inbound traffic go to A, go to your Screen and have all other hosts use that address (A) for unidirectional, outbound traffic. Then set up NAT as shown in the table below.

Table 7-4 Example of a One-Address NAT Table Entry

Index 

Screen 

TYPE 

Source 

Destination 

Translated Source 

Translated Destination 

Comment 

1

 

STATIC

*

A

*

A

 

2

 

DYNAMIC

Inside 

Internet

A

Internet

 

Internet is all addresses on inbound interface A; and Inside is all internal hosts on all other interfaces. With only these NAT rules, all hosts in the Inside communicate with their private, unregistered addresses when communicating with the Screen or among themselves.

Write your filtering rules in the context of the internal addresses.

Example Two

Registered addresses are necessary for advertised kinds of resources, such as publicly accessible servers on your network; consequently, these machines must be at well-known, fixed addresses. Because a host must have a registered address before it can communicate over public networks, machines that host public resources either must have stable registered addresses, or their unregistered (internal) addresses must translate to stable registered addresses. The following scenarios illustrate how a demilitarized zone (DMZ), an internal network with limited public access, could use registered addresses or unregistered addresses with network address translation.

Scenario 1: DMZ Uses Registered Addresses

In the figure below, the Screen, in routing-mode, uses Q1 as its own IP address on the external network interface. It has a DMZ network with registered addresses R1 through R8 on a second interface. The Screen (Q1) and the servers in the DMZ (the FTP server, R2, and the WWW server, R3), have routable registered addresses on the public network that allow them to communicate with any other machine with a registered address. The Screen uses the remaining registered addresses (R4 through R8) for NAT.

Figure 7-1 Scenario 1: Static and Dynamic NAT

Graphic

The Screen uses dynamic NAT to translate the addresses in its unregistered address range (U2-Un) to the remaining addresses in its registered address range (R4-R8). When an internal host with an unregistered address tries to connect to an external host with a registered address, the Screen assigns the internal host a registered address to use for the duration of the network communication session.

Scenario 2: DMZ Uses NAT Addresses

The figure below illustrates an organization that has a network consisting of a large number of unregistered addresses (Un) and a set of eight registered addresses (R1-R8). Hosts on the inside network must be able to communicate through the Screen with external hosts.

Figure 7-2 Scenario 2: Static and Dynamic NAT

Graphic

In the figure above, the Screen is connected to the public network R1-R8. R1 is its IP address on the public network interface. It uses static NAT to translate the unregistered DMZ addresses of the FTP server (U2) and the WWW server (U3) to the registered (public) addresses R2 and R3. The private addresses U4 through Un will be translated dynamically to the registered addresses R4 through R8. Because the IP addresses of the servers and the internal network are translated to routable registered addresses, they can communicate with any other registered address.

The Screen uses dynamic NAT to translate the addresses in its unregistered address range (U4-Un) to the remaining addresses in its registered address range (R4-R8). When an internal host with an unregistered address tries to connect to an external host with a registered address, the Screen assigns the internal host a registered address to use for the duration of the network communication session.

This scenario has the advantage that if you change ISPs, you do not have to re-address all the hosts on your internal registered network.

Routing Interface Examples

For routing interfaces, you can select the registered address as the address of one of the Screen's interfaces. In this case, the Screen simulates the registered address. The limitation here is that you only have a single address. Also selecting the interface address as the registered address for a static NAT rule can limit your ability to connect to the Screen itself. Because you are not adding additional networks, no routing changes are required.

For routing interfaces, you can select the unused addresses on one of the networks to which the Screen is directly connected as virtual addresses. In this case, this approach is necessary so that the addresses can respond to ARP requests for these virtual addresses.

For routing interfaces, if you select the virtual addresses from a network not directly connected to the Screen, you must make sure that the correct routing information is propagated so that packets destined for these addresses pass through the Screen. If you define new networks (especially ones in which all the addresses on the network are virtual), you may need to add static routing entries on some routers to simulate these networks.

Stealth Interface Examples

For stealth interfaces, you can select the registered addresses from the list of unused addresses on the network that the Screen segments. In this case, Screen simulates the virtual addresses and responds to ARP requests for those addresses. Since you are not adding additional networks, no routing changes are required.

For example, consider a SunScreen with stealth interfaces that segments the network 199.190.177.0 (netmask 255.255.255.0). In this example, the addresses 199.190.177.100 through 199.190.177.254 are unused and can be used as virtual addresses in network address translations.

For stealth interfaces, you can select the registered addresses from a new virtual network you create. For this to work successfully, you must be able to assign multiple addresses on multiple networks on the routers you use.

Applying NAT

NAT translations for your site are automatically applied to all packets. When packets addressed to an internal host are received from an external host, the Screen translates network address information in the packets before they are processed by the stateful packet-filtering engine. Similarly, packets travelling from an internal host to an external host are filtered before NAT takes place. This approach lets you use your internal addresses when you define filtering rules, simplifying policy management.