Chapter 3 Configuring Network Address Translation (NAT)

A Screen using network address translation (NAT) transparently maps an internal, unregistered IP address to an external, registered IP address. 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, you use NAT for the following situations:

• When adding a previously configured private network to the Internet, or when changing Internet service providers (ISPs).

• When you do not want to renumber all your unregistered addresses.

• To ensure that the internal unregistered 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 NAT address mappings, STATIC and DYNAMIC.

• A STATIC mapping sets up a one-to-one relationship between two addresses, and generally (though not exclusively) is used 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 ensures that all traffic leaving the Screen appears to come from a single address or group of addresses. You generally use DYNAMIC NAT for outbound connections only (initiated from inside the Screen) but "reverse" NAT rules are allowed.

You should 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 3.2 Installation Guide to help organize your addresses.

The instructions in this section provide detailed steps about setting up NAT. For more NAT details, see the SunScreen 3.2 Administrators Guide; for background information on NAT, see the SunScreen 3.2 Administrators Overview.

Network Example

Figure 3-1 (and the instructions that follow) demonstrate how you can configure NAT on a Screen to make hosts on an internal network routable 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 to a public, registered address (from 10.0.1.1 to 192.168.2.101 for this example). Use dynamic NAT to translate all other addresses in the San Francisco network to a single, public registered address (192.168.2.102 in this example).

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

Static NAT Example

Configure Static NAT

1. Install and configure the Screen in either stealth or routing mode.

   In our example, sf-screen1 is configured in routing mode with sf-host4 as a remote Administration Station. For instructions on configuring a Screen with remote administration, refer to "Setting Up Remote Administration with SKIP".

2. Create an Address HOST object for the private, unregistered host.

   In this example, the unregistered host sf-host1 is defined as 10.0.1.1.

3. Create an Address HOST object for the public, registered IP address and give it a name.

   In this example, the you would name the address object sf-host-static and assign it an address of 192.168.2.101.

4. Create an Address GROUP object that contains everything but the Screen.

   In this example this object is defined as internet-static. You would create this object by including * and excluding localhost(the Screen).

5. Check that you created Packet Filtering rules to allow appropriate traffic to through the Screen.

   In this example, you would allow http traffic from any host (*) to sf-host1 through the Screen as shown in the following figure.

   Figure 3-2 Rule for HTTP Traffic

   
   

6. Create a STATIC NAT rule to translate the internal address to the legal address.

   Rule 1 in Figure 3-3 maps internal address sf-host1 to legal address sf-host-static. This rule enables the internal host to initiate connections to any host on the internet (provided they are allowed by packet filtering rules.)

   Because the SunScreen firewall keeps state information about NAT connections, return packets destined for the NAT address (sf-host-static) are translated back to the original internal address before entering the internal network

7. Create a STATIC NAT rule to translate the legal address to the internal address.

   Rule 2 in Figure 3-3 is needed for hosts on the internet to initiate connections to the internal host. The rule translates the legal address (sf-host-static) to the internal address (sf-host1) .

   Figure 3-3 STATIC NAT Rules

   
   

8. Add an arp entry on the Screen so it can respond to ARP requests from the external router.

   ---

   Note -

   If you configured the Screen in stealth mode, this step is not required.

   ---

   Use the following command as a model.

   # 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 external interface of the Screen (qe1 in this example.)

   Run this arp command for each legal IP address that the Screen uses for NAT .

   Place this command in a start-up script to run each time the system boots because the arp entry 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/S72sunscreenARP #!/bin/sh # startup script example to publish ARP entries # for IP addresses sunscreen performs NAT on # # STATIC NAT mappings arp -s 192.168.2.101 8:0:20:a3:ec:27 pub # DYNAMIC NAT mappings arp -s 192.168.2.102 8:0:20:a3:ec:27 pub 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

9. Save and activate your policy.

10. 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 Screen and try a ping from the Screen to the router. If the configuration is set up correctly, the result should be that the router is alive, and the snoop output should look similar to the following examples:

    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 Example

Configure Dynamic NAT

SunScreen also supports DYNAMIC NAT. In our example, the remaining hosts on the San Francisco network (those not already translated) need access to the internet. However, they do not need to allow inbound connections from the internet. Their source addresses can be translated to a single external legal addresses for this purpose.

1. Define an Address GROUP object and add all the internal hosts that need to use DYNAMIC NAT to this group.

   In our example, we define sf-ten-net as containing sf-host2, sf-host3 and so forth.

2. Define an Address HOST object for the private, unregistered hosts.

   In this example sf-host-dynamic is defined as 192.168.2.102.

   ---

   Note -

   DYNAMIC NAT can use a group of addresses when needed. The sf-host-dynamic object could be a RANGE or GROUP object in such an instance.

   ---

3. Create an Address GROUP object that contains every address that you want to use DYNAMIC NAT but excludes those systems which you do not want to use it.

   In this example this object is defined as sf-internal. You would create this object by including sf-ten-net and excluding localhost and sf-host1.

4. Create an Address GROUP object that represent systems outside your internal network.

   In this example, you would create an Address group called external that includes * and excludes localhost, sf-ten-net, and sf-host1.

5. Add an ARP entry on the Screen for the legal address, as described in the preceding STATIC example.

   ---

   Note -

   If you configured the Screen in stealth mode, this step is not necessary.

   ---

   In this example, sf-host-dynamic would need an ARP entry.

6. Add a DYNAMIC NAT rule to translate the internal address group to the public, registered IP address.

   In this example, sf-internal is translated to sf-host-dynamic. Refer to the following figure.

   Figure 3-4 DYNAMIC NAT Rules

   
   

7. Save and activate your policy

8. Verify that connections work from the internal host to the internet.

   For details, refer to Step 10 in "Static NAT Example".