test

SunScreen EFS Release 3.0 Reference Manual

Network Address Translation (NAT)

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

NAT enables a Screen to map an internal network address to a different 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 map is monitored. You specify when a packet using ordered NAT translations is applied based on source and destination addresses.

Note -

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

Additionally, 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 in the following situations when:

Note -

Using NAT to hide addresses differs from tunneling in that NAT does not rely on the use of encryption and decryption and consequently does not require an encryption-decryption device at each end of the connection over the public network.

NAT lets you use private or 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 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).

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, so the reverse rules must be generated by you.

Static NAT maps a specific unregistered address to a specific registered address. Static translations can also map a range of unregistered addresses to a range of registered addresses, which requires the number of addresses in each range to match.

Dynamic NAT

Dynamic NAT maps a large set of unregistered IP addresses to a smaller set of registered addresses. Dynamic NAT lets you connect a very 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 mapping between internal private addresses and external public addresses, dynamic NAT creates a many-to-one mapping 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. When the Screen uses a public address that is already in use, it uses a different source port number, thereby making a distinction between the two connections. A Screen can multiplex many thousands of translations over a single registered address by ensuring the source ports for the connections differ.

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.

NAT Examples

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

Example One:

When you only have one registered IP address ("A") and you want to have all inbound traffic to "A" go to your Screen and have all other hosts use that address ("A") for unidirectional, outbound traffic, then set up the following NAT mappings:

Table 2-1 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" 

"" 

where "Internet" is all addresses on inbound interface "qe0" and "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.

Valid mapping combinations are:

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, either machines that host public resources must have stable registered addresses, or their internal (unregistered) 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 FIGURE 2-5, 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 2-5 Scenario 1: Static and Dynamic NAT

Graphic

The Screen uses dynamic NAT to map the addresses in its unregistered address range (U2-Un) to map 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

FIGURE 2-6 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 2-6 Scenario 2: Static and Dynamic NAT

Graphic

In FIGURE 2-6, 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 map 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 mapped 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.

In routing-mode (not needed in stealth-mode), the Screen must respond to ARP requests the public addresses (R2 through R8) because it will be translating public addresses to private addresses. You must add an arp entry (using the command arp -s IP_address ether_address pub) for them. You must either add this entry each time that you reboot the Screen or add it to the /etc/inetd.conf file. If you are remotely administering the Screen in routing mode, you either must go to the Screen to add this entry, or you must have a rule in your policy that allows you to log in remotely (rlogin) to your Screen.

The Screen uses dynamic NAT to map 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 readdress all the hosts on your internal registered network.

Applying NAT

NAT mappings 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.

NAT and Mapping Collisions

Mapping collisions can cause service to be denied to a network user. Mapping collisions occur when network software cannot complete the address mapping 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: (dest IP addr, 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. For a mapping collision to occur, multiple internal machines using the same registered IP address must try to access the same registered address Xn at the same destination port number, and from the same source port number, all at the same time-an unlikely scenario.

Suppose a user at the unregistered address U5, shown in FIGURE 2-5, 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.

Table 2-2 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 

R5 

192.4.15.44 

80 

34080 (on U7)

tcp 

The following table shows a mapping of unregistered addresses, Un, to registered addresses, Rn.

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 mapping collision will occur. The user at U7 would have to use another source port to have a unique 5-tuple and avoid a mapping collision, which would happen automatically during a subsequent connection attempt.

Situations such as power failures typically result in mapping 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. It may take time for the counters on each machine to cycle up to higher and more randomized port numbers (which are more likely to produce unique 5-tuples). In the interim, mapping collisions may cause network service to be denied temporarily. Internal hosts must continue trying to establish network connections until the NAT rules resolve the mapping collisions.

Note -

Ports 0 though 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