Configuring Static Address Translation

Static address translation translates an internal IP address to an external IP address on a one-to-one ratio. This is in contrast to hide-mode translation, which translates many internal IP addresses to one external IP address ( many-to-one ). Situations especially suited to static-mode translation include cases where external hosts on the Internet have to initiate connections with hosts on your protected network. Using hide-mode translation would not allow for this ”internal hosts are hidden, as the name suggests, and therefore cannot be contacted directly from external sources. Static address translation is also useful in situations where hide-mode will not work, such as with certain VPN clients or other specialized applications.

Static address translation rules come in two flavors: static source and static destination. Rules are generally generated in pairs ”you will want matching source and destination rules for each internal object involved with static-mode translation. If you have only static source or static destination, it will provide NAT for connections only in one direction. The NAT rulebase is similar to the Security Policy rulebase in that it works based on the connection, not the individual packet. Therefore, for incoming connections to a web server, it is not required that you define a static source NAT rule just to enable response packets to be translated on the way out to the Internet.

The following sections provide more detail about the two types of static-mode translation rules and describe an example configuration. In the example, there is a Web server sitting behind the firewall, called Web_Server, on an internal IP address, 172.16.0.10. Our objective here is to use static address translation to allow external users to access this Web server. To do this, we will first create a static source rule to allow the Web server to connect to the Internet with its public IP address. We will then configure a static destination rule that will allow others on the Internet to contact the Web server.

Static Source

The first step in configuring static address translation for your Web server is to ensure that connections originating from the Web server are able to exit your network and reach their destinations on the Internet. This is the purpose of static source mode.

In both hide-mode address translation and static source mode translation, reserved IP addresses are translated into a routable IP addresses before they leave the firewall. The difference is that in static source mode there is a one-to-one relationship between reserved addresses and routable addresses. That is, each reserved address is translated into a unique routable address.

Static source rules, like hide rules, can be configured either automatically or manually. While this example will focus on manual rule configuration, you can refer to the Automatic NAT rules section for information on how to generate these rules automatically.

To configure a static source rule, open SmartDashboard, and select the Address Translation tab. Select Rules Add Rule Top . Again, depending on which rules are already present, you may need to add the rule elsewhere in the rule base. The next step is to configure this rule; see rule 1 in Figure 5.4.

Figure 5.4: Static Source Rule

Before you configure the new rule, you will need to add an object representing the routable IP address that will translate the Web server s internal address. Create a standard workstation object with a valid routable IP within your address space, and call it Web_Server_External, as in Figure 5.5.

Figure 5.5: Web Server External Object

Now, back to the translation rule. In the Original Packet section, under Source , add the Web_Server object ” double-check that this object has an internal address. Leave the Destination as Any , since we want to apply this rule no matter what external host the Web server is attempting to contact. Also leave the Service as Any , since we are not going to restrict the destination port for this rule. Note that you could specify HTTP or HTTPS here, depending on your specific application, but it s easier to allow all services in case you ever have to use another service like ICMP to test connectivity.

In the Translated Packet section, set Source to Web_Server_External , and double-check that this object is set to the routable address you are using for translation. Again, leave Destination and Service unchanged, as Original , since we are only interested in translating the source address, not in the destination or service.

Set Install On to All, or if you are only planning to use this rule on a subset of your available firewalls, set this to match that set. Be sure to add a descriptive comment, such as Static source for Web_Server, so that you will be able to identify this rule later.

The last step to enable static source translation is to ensure that your standard rule base will allow traffic from the Web server outbound if necessary. See rule 9 in Figure 5.6.

Figure 5.6: Outbound Rule for Web Server

Set the Source to Web_Server , Destination to Any , and Service to HTTP . Action will be Accept , and Track should be Log .

Once you install the policy, you will have a working static source translation rule for this Web server. Remember that this rule only takes care of allowing the Web server to reach external hosts; without any further configuration there is no means by which inbound traffic can reach the server. In general, the functionality of a Web server requires external traffic to reach the server, and so static source rules are usually created in pairs with static destination rules, which are described next.

Static Destination

Creating a static destination rule is very similar to creating a static source rule, except for the order of the objects. See rule 2 in Figure 5.7.

Figure 5.7: Static Destination Rule

Again, add a rule to the translation rule base by selecting Rules Add Rule . Here you should place this rule above or below the static source rule. In this case, in the Original Packet section, set the Destination to Web_Server_External , and leave Source and Service as Any . In the Translated Packet section, set the Destination as Web_Server , and again leave the other two columns as Original . The reason we are modifying the destination in this case and not the source is that we are concerned only with incoming traffic, which has the Web server as destination.

Finally, you must ensure that your standard rule base will allow incoming traffic to hit the routable address. If not, this traffic would be dropped before it even had a chance to go through your translation rule. In our case, we already created this rule when we were defining our rulebase. See rule 5 in Figure 5.8.

Figure 5.8: Rules for Incoming Traffic to Web Server

Here, set Source to Any , Destination to Web_Server , Service to Any , and Action to Accept . Note that you could specify specific services, such as HTTP or HTTPS, and you could also narrow down the acceptable remote hosts that can access the Web server by adding them to the destination.

After you install the policy, you will have a working static destination setup. What you can do then is configure DNS so that the name by which you want people to access this Web server, for example www.mycompany.com, points to the address you have assigned to Web_Server_External.

When this name is accessed on the Internet, traffic will be directed to your firewall, which will then translate and forward the packets to your Web server s internal address (the same one assigned to the object Web_Server ). The Web server will recognize these packets as belonging to itself, and will respond to the request. When the response reaches the firewall, the firewall will again translate the packets back to the routable address, and forward them back toward the client. The client will see the response as originating from the same address to which they sent the request, and will not even know translation took place.

Routing and ARP

Just as in hide-mode address translation, there are ARP and routing issues to take into account for static source and static destination modes.

Static-mode NAT requires the same ARP configuration as hide-mode; the routable address you are using (in this case the one assigned to Web_Server_External) must be configured on the firewall host. This is necessary so that incoming traffic bound for this address is recognized by the firewall as belonging to itself, and processed rather than forwarded elsewhere.

On a Solaris system, use the following syntax to add the static ARP entry:

 arp -s <translated IP> <MAC address> pub 

On a Windows NT system, edit the file $FWDIR\state\local.arp. In this file, add a line as follows :

 <translated IP>     <MAC address> 

In both cases, use the translated IP assigned to Web_Server_External and the MAC address of your local network card. Be sure to stop and restart the firewall process after making these changes.

If you are using a Nokia, add an ARP entry in the Voyager GUI under Configure ARP . Here, add a permanent ARP entry with type Proxy Only .

Static destination mode requires that you take into account routing the packets destined for the Web server. Specifically, the firewall will not know which interface to use to transmit the packets unless told explicitly. This may seem confusing, since you may think the translation rule will take care of routing the packet properly. However, if you upgraded your firewall to NG from a previous version (for instnace v4.1), then translation takes place after the packets are routed. You can think of this as the packet header being rewritten just as the packet is on its way out of the firewall s interface. So, it must be going out of the correct interface before the address is translated. New installations of NG will translate before the packets are routed. See the section NAT Global Properties for more information.

To add a static route on a Solaris system, use the following command:

 route add <routable address> <internal adress> 

Note that in Solaris, this route, as well as any ARP entries you have added statically, will only remain present until the system is rebooted. You will need to ensure that you add this route to the appropriate startup file prior to the next reboot.

To add a static route on a Windows NT system, use the following command:

 Route add <routable address> <internal address> -p 

Here, the route will remain intact following a reboot due to the -p option, which stands for persistent. In both cases, the routable address is the address assigned to Web_Server_Ext , and the internal address is the address assigned to Web_Server or the next hop router.

To add a static route on a Nokia, open the Voyager GUI and select Configure Routing Configuration Static Routes . Add the route here, and then apply and save your changes.

Now that you have taken care of all outstanding ARP and routing issues, you can be sure that your static source and static destination translation rules will allow the Web server to function normally, while still being protected by the firewall.