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:

• "Source" and "Translated Source" are the same, and "Destination" and "Translated Destination" are the same (no translation will occur).

• "Source" and "Translated Source" are the same, and "Destination" and "Translated Destination" are different.

• "Source" and "Translated Source" are different, and "Destination" and "Translated Destination" are the same.

• You cannot translate both the source and destination addresses in any single packet with either a single mapping or in a combination of mappings.

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

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

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.