This chapter is from the book
This chapter is from the book
This chapter is from the book
How NAT Works in FireWall-1
NAT is configured via the Address Translation tab in the Security Policy Editor. The rules are processed in the order in which they are listed. Once a rule matches a packet, the packet is translated, and no further processing occurs. If a packet does not match a rule in the address translation rules, the packet is not translated.
Four types of NAT are available in FireWall-1, and they can be mixed and matched as necessary: Source Static, Destination Static, Destination Port Static, and Source Hide:
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 munged (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 Internet Key Exchange (IKE) as used with IPSec implementations.
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. However, it does not allow you to make services running on machines other than the firewall accessible with the firewall's IP address; that is, if you want to make services accessible through the firewall, a different routable IP address is needed.3
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.4
Even though NAT can be configured in the Security Policy Editor, you need to configure the host OS, as described in the next section, in order to support NAT.
The Order of Operations
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 9-2).
){kind=link}
Figure 9-2 Client A communicating with Client B
NOTE
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.
Once the packet is received at the firewall, FireWall-1 processes the packet according to the following steps:
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.
Checks IP Options. If the packet is denied because of this check, you will see a drop on Rule 0 in the Log Viewer, assuming that IP Options logging is enabled.
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 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.
Checks properties and the rulebase.
The OS routes the packet. The OS determines that in order to communicate with Client B, it needs to route the packet out the 10.21.31.1 interface.
Performs IP Options and anti-spoofing checking on the 10.21.31.1 interface. The destination of the packet (10.21.31.41) is compared against the valid address setting. If the packet is denied because of this check, you will see a reject on Rule 0 in the Log Viewer, assuming that anti-spoofing logging is enabled on that interface. The remote end of the connection will receive a reset, which means a client application will see a "connection refused" message.
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 was a matching NAT rule, this is where NAT would take 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. When you do NAT, it means you must make sure that the untranslated packet can pass through your anti-spoofing checks and your rulebase.