NAT is configured via the Address Translation tab in the Security Policy Editor. Two types of rules will show up here: manual rules, created by the administrator, and automatic rules that are created when NAT is configured on individual workstation, network, and address range objects. My personal preference is for manual rules because of the control you have over when these rules might apply.
If a packet does not match any rule in the address translation rules, the packet is not translated. If a packet does match a rule, the packet is translated, and no further processing occurs unless the "Allow bi-directional NAT" property in the NAT frame of the Global Properties section is enabled and automatic NAT rules exist. In this case, multiple automatically generated NAT rules can apply to a particular packet, which allows for both the source and destination IP addresses to be translated.
Four types of NAT are available in FireWall-1, and they can be mixed and matched as necessary: Source Static, Source Hide, Destination Static, and Destination Port Static.
Source Static: Translates the source IP address in an IP packet to a specific IP address. This is a one-to-one address translation. Return traffic, as necessary, is allowed back through without additional NAT rules. However, if you need to initiate connectivity from either side of the firewall, a corresponding Destination Static NAT rule is needed.
Source Hide: Makes more than one host appear as a single host (i.e., a many-to-one translation). In the text, I will refer to this simply as hide mode. This is perfect for hosts that require access to the Internet but should not be accessed from the Internet. In order to accomplish this, FireWall-1 changes the source TCP or UDP port of the packet so that it can keep track of which host the connection belongs to (and, consequently, know where to send reply packets). For ICMP packets, the data portion of the packet is modified (the data portion of an ICMP packet usually isn't used). For other IP protocols, hide mode does not work because there are no ports or data that can be modified. Most standard applications (e.g., Telnet, HTTP, FTP, HTTPS) work fine, but any application that requires a connection initiated from the outside or requires that a connection happen on a specific source port will not work in hide mode. An example of such is how Internet Key Exchange (IKE) is implemented in some VPN products.
Destination Static: Translates the destination IP address in an IP packet to a specified IP address. This is a one-to-one address translation for connections. Return traffic, as necessary, is allowed back through without additional NAT rules. However, if you need to initiate connectivity from either side of the firewall, a corresponding Source Static NAT rule is needed.
Destination Port Static: Translates only the destination (or service) port number to a different port. This, for example, allows you to transparently request going from port 8080 to port 80. It also allows you to make services on other machines accessible from the firewall's IP address.
NAT rules apply to all interfaces and cannot be applied on a per-interface basis. Usually, rules can be crafted in such a way that per-interface rules are not necessary. You can hide connections behind the IP 0.0.0.0, which is a special IP that tells FireWall-1 to use the interface the packet has routed out as opposed to a fixed IP address. When using the NAT frame of an object to define address translation (i.e., automatic rules), you can specify hiding behind the interface of the install-on gateway.
Even though NAT can be configured in SmartDashboard/Policy Editor, you generally need to configure the host operating system in order to support NAT.
In order to understand how to implement NAT, it is best to review the order of operations as it relates to FireWall-1 and passing traffic in general. Consider the following case, where Client A wants to communicate with Client B (see Figure 10.2).
In this example, NAT is not configured.
Client A determines that in order to communicate with Client B, the packet must be routed through the firewall. Client A needs to know the Media Access Control (MAC) address for the firewall's IP address (10.20.30.1), so it sends out a request via the Address Resolution Protocol (ARP) requesting the address. The firewall responds with its MAC address. Client A is then able to forward the packet to the firewall for processing.
Note that all of these events happen without any aid from FireWall-1. It is important to be aware of this exchange because when you do address translation, you must be sure that all of the translated IP addresses you set up through FireWall-1 get routed back to the firewall for processing. If the translated IP address is on the same subnet as the firewall, you need to set up a proxy ARP or static host route for that address. Otherwise, routes to those addresses will be necessary.
FireWall-1 NG has added a mechanism called Automatic ARP Configuration in the Global Properties (in the NAT frame). When this is enabled, in theory at least, the operating system of the firewall will not have to be configured to proxy ARP for any addresses it is using for NAT. This property, according to the documentation, works only for automatically generated NAT rules. Even so, I have seen a number of reports that this property doesn't work with automatic rules either. I feel more comfortable making the changes to the ARP tables manually.
Once the packet is received at the firewall, FireWall-1 processes the packet according to the following steps.
The firewall checks to see if the packet is part of an established connection. Because this is a new connection, there is no record of the packet in the connections table, so the connection must be checked against the security policy.
The firewall checks IP Options. If the packet is denied because of this check, you will see a drop on Rule 0 in the SmartView Tracker/Log Viewer, assuming that IP Options logging is enabled.
The firewall performs an anti-spoofing check on the 10.20.30.1 interface. The source of the packet (10.20.30.40) is compared against the valid address setting. If the packet is denied because of this check, you will see a drop on Rule 0 in the SmartView Tracker/Log Viewer, assuming that anti-spoof logging is enabled on that interface. The remote end of the connection will see a "connection timed out" message.
The firewall checks properties and the rulebase.
The operating system routes the packet. The operating system determines that in order to communicate with Client B, it needs to route the packet out the 10.21.31.1 interface.
The firewall checks properties and the rulebase. Properties are always checked outbound as well as inbound. A rule's check depends on how you have installed it and how you are enforcing gateway rules.
The packet proceeds through the address translation rules. If there is a matching NAT rule, this is where NAT takes place. In this example, NAT is not occurring, so translation is not performed.
The packet is sent directly to Client B.
The important detail to note in this process is that NAT is not done until near the very end?that is, after the packet has been routed and has gone through the security policy, but before the packet leaves the gateway. That is, of course, unless you've turned on the Translate Destination on Client Side option.
This particular option is set in the NAT frame of the Global Properties section. With this option, when a destination IP address needs to be translated, the firewall performs the NAT operation before the packet is routed, that is, on the client side of the connection (between steps 4 and 5 above). This has two important side effects.
Routing entries are no longer necessary on the firewall to account for NAT.
It is possible to map ports on your firewall to servers on your internal network.
In FireWall-1 NG FP2 and before, this property is specific to automatically generated NAT rules only. In NG FP3 and above, there are separate options for both manual and automatic rules. In NG FP2 and before, you need to enable the option by using the following commands in dbedit:
> modify properties firewall_properties nat_dst_client_side_manual true > update properties firewall_properties