Chapter 3 Routing Mode and NAT

A routing-mode Screen using network address translation (NAT) enables the Screen to map an internal, unregistered IP address to an external, registered IP address. This process is performed by replacing the addresses in the original packet with new addresses transparently.

You can configure NAT on a Screen in stealth mode as well as in routing mode; although, arp entries are not needed on a stealth Screen.

Typically, NAT is used for the following situations:

• When adding a previously configured private network to the Internet, or when changing Internet service providers (ISPs), and when renumbering all the unregistered addresses might not be feasible.

• To ensure that the internal addresses, which are configured as private, unregistered addresses (due to a lack of available public addresses), appear as public, registered IP addresses on the Internet.

• To hide the addresses of your current private network from the outside world.

There are two types of address mappings that can be used when configuring NAT: STATIC and DYNAMIC. A STATIC mapping is used to set up a one-to-one relationship between two addresses, and is generally implemented for publicly accessible servers that require direct inbound connections (initiated from outside the Screen). A DYNAMIC mapping uses a many-to-one or many-to-few relationship, and is implemented to ensure that all traffic leaving the Screen appears to come from a single address or group of addresses. DYNAMIC NAT can be used for outbound connections only (initiated from inside the Screen).

Network Example

For the network example, shows the San Francisco segment of the network. Looking at the diagram, NAT is configured on sf-screen1 to enable the hosts on the San Francisco network to be routable or accessible on the Internet.

Assume that host sf-host1 is a company web server that requires access from the Internet. Use STATIC NAT to translate the private, unregistered address 10.0.1.1 to a public, registered address (192.168.2.101 for this example).

Figure 3-1 San Francisco Segment of the Sample Company Network

General NAT Configuration

To configure NAT using SunScreen, you must complete the following steps:

1. Create a table of all addresses that require translation, and determine which addresses require STATIC or DYNAMIC address mappings.

   Use the worksheets in the SunScreen Installation Guide to help organize your addresses.

2. On the Screen and remote Administration Station, when applicable, run the Solaris Web Start Wizards installer to install the SunScreen software.

3. Create address objects that contain all private and public addresses to be used in the translations.

4. Create appropriate packet filtering rule(s) to ALLOW specific traffic to pass.

5. Create NAT rules to translate the necessary addresses.

6. Add arp entries, if needed.

Detailed NAT Configuration

The following steps are needed to complete the NAT configuration for this example:

1. Install and configure Screen sf-screen1 in routing mode using the remote Administration Station sf-host4.

   For instructions on configuring a Screen in routing mode, refer to the section "Installing the Screen in Routing Mode" as described in the first example in this document.

2. Create an address object for the host sf-host1 with the private, unregistered address 10.0.1.1.

3. Create an address object for the public, registered IP address (192.168.2.101 for this example) and give it a name (sf-host1-legal for this example).

4. Check that the packet filtering rule(s) have been created to ALLOW appropriate traffic to pass to and from the web server sf-host1.

5. Create a STATIC NAT rule to translate the addresses from sf-host1-legal to sf-host1.

   This enables hosts on the Internet to connect to the IP address for sf-host1-legal, which translates to sf-host1. Because the SunScreen firewall software keeps state information about its NAT connections, return packets from sf-host1 to a host on the Internet are translated back to sf-host1-legal (192.168.2.101 in this example) as they leave the Screen.

   When it is required for host sf-host1 to initiate a connection to a host on the Internet (* in this example), add a second NAT rule to translate sf-host1 to sf-host1-legal, as shown in the following figure.

   Figure 3-2 STATIC NAT Rules

   
   

6. Add an arp entry on sf-screen1 to enable it to respond to ARP requests from sf-router1 for the public, registered IP addresses it is performing NAT on by typing:

   # arp -s translated-ip-addr screen-ethernet-addr pub

   where translated-ip-addr is the public, registered IP address (192.168.2.101 for this example) and screen-ethernet-addr is the Ethernet address of the Screen.

   Run the arp command for each legal IP address that sf-screen1 is performing NAT on.

   Place this command in a start-up script to run each time the system boots as it is only valid until the Screen is rebooted.

   The following shows an example of an arp start-up script used for STATIC and DYNAMIC NAT (see the following section on DYNAMIC NAT):

   # /etc/rc2.d/S70sunscreenARP #!/bin/sh # startup script example to publish ARP entries # for IP addresses sunscreen performs NAT on # # First STATIC mapping arp -s 192.168.2.101 8:0:20:a3:ec:27 pub # Second STATIC mapping arp -s 192.168.2.102 8:0:20:a3:ec:27 pub # Next three are the addresses used by DYNAMIC NAT arp -s 192.168.2.103 8:0:20:a3:ec:27 pub arp -s 192.168.2.104 8:0:20:a3:ec:27 pub arp -s 192.168.2.105 8:0:20:a3:ec:27 pub

7. Save and activate your policy.

8. Verify that connections work to and from the host being translated, and that the translation is actually taking place.

For example, run snoop both inside and outside the sf-screen1 Screen and try a ping from sf-host1 to sf-router. If the configuration is set up correctly, the result should be that sf-router is alive, and the snoop output should look like the following:

Inside the Screen:

sf-host1 -> sf-router 	ICMP Echo request
sf-router -> sf-host1 	ICMP Echo reply

Outside the Screen:

192.168.2.101 -> sf-router 	ICMP Echo request
sf-router -> 192.168.2.101 	ICMP Echo reply

DYNAMIC NAT

The other type of NAT supported by SunScreen is DYNAMIC. For this example the hosts sf-host2, sf-host3, and so forth, need access to the Internet. Their source addresses are translated to a legal address sf-dynamic (192.168.2.103 in this example).

1. Define an address GROUP object called sf-internal and add all the internal hosts (sf-host1, and so forth) that need to use DYNAMIC NAT to this group.

2. Define an address HOST object (sf-dynamic in this example) that contains the legal address (192.168.2.103 in this example).

   ---

   Note -

   DYNAMIC NAT can use a range of addresses. In this example, sf-dynamic can be a RANGE or GROUP object.

   ---

3. Add an ARP entry for the legal address sf-dynamic, as described in the proceeding STATIC example.

4. Add a rule to translate sf-internal to sf-dynamic, as shown in the following figure:

   Figure 3-3 DYNAMIC NAT Rule