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.
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. The Order of OperationsIn 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). Figure 10.2. Client A communicates with Client B
NOTE!
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 important detail to note in this process is that NAT is not done until near the very endthat 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.
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 |