NAT Policy Overview
You configure a NAT rule to match a packet’s source zone and destination zone, at a minimum. In addition to zones, you can configure matching criteria based on the packet’s destination interface, source and destination address, and service. You can configure multiple NAT rules. The firewall evaluates the rules in order from the top down. Once a packet matches the criteria of a single NAT rule, the packet is not subjected to additional NAT rules. Therefore, your list of NAT rules should be in order from most specific to least specific so that packets are subjected to the most specific rule you created for them.
Static NAT rules do not have precedence over other forms of NAT. Therefore, for static NAT to work, the static NAT rules must be above all other NAT rules in the list on the firewall.
NAT rules provide address translation, and are different from security policy rules, which allow or deny packets. It is important to understand the firewall’s flow logic when it applies NAT rules and security policy rules so that you can determine what rules you need, based on the zones you have defined. You must configure security policy rules to allow the NAT traffic.
Upon ingress, the firewall inspects the packet and does a route lookup to determine the egress interface and zone. Then the firewall determines if the packet matches one of the NAT rules that have been defined, based on source and/or destination zone. It then evaluates and applies any security policies that match the packet based on the original (pre-NAT) source and destination addresses, but the post-NAT zones. Finally, upon egress, for a matching NAT rule, the firewall translates the source and/or destination address and port numbers.
Keep in mind that the translation of the IP address and port do not occur until the packet leaves the firewall. The NAT rules and security policies apply to the original IP address (the pre-NAT address). A NAT rule is configured based on the zone associated with a pre-NAT IP address.
Security policies differ from NAT rules because security policies examine post-NAT zones to determine whether the packet is allowed or not. Because the very nature of NAT is to modify source or destination IP addresses, which can result in modifying the packet’s outgoing interface and zone, security policies are enforced on the post-NAT zone.
A SIP call sometimes experiences one-way audio when going through the firewall because the call manager sends a SIP message on behalf of the phone to set up the connection. When the message from the call manager reaches the firewall, the SIP ALG must put the IP address of the phone through NAT. If the call manager and the phones are not in the same security zone, the NAT lookup of the IP address of the phone is done using the call manager zone. The NAT policy should take this into consideration.
No-NAT rules are configured to allow exclusion of IP addresses defined within the range of NAT rules defined later in the NAT policy. To define a no-NAT policy, specify all of the match criteria and select No Source Translation in the source translation column.
You can verify the NAT rules processed by using the CLI test nat-policy-match command in operational mode. For example:
user@device1> test nat-policy-match ?
+ destination Destination IP address
+ destination-port Destination port
+ from From zone
+ ha-device-id HA Active/Active device ID
+ protocol IP protocol value
+ source Source IP address
+ source-port Source port
+ to To Zone
+ to-interface Egress interface to use
| Pipe through a command
<Enter> Finish input
user@device1> test nat-policy-match from l3-untrust source destination destination-port 443 protocol 6
Destination-NAT: Rule matched: CA2-DEMO =>
NAT Address Pools Identified as Address Objects
When configuring a Dynamic IP or Dynamic IP and Port NAT address pool in a NAT policy rule, it is typical to configure the pool of translated addresses with address objects. Each address object can be a host IP address, IP address range, or IP subnet.
Because both NAT rules and security policy rules use address objects, it is a best practice to distinguish between them by naming an address object used for NAT with a prefix, such as “NAT-name.”
Proxy ARP for NAT Address Pools
NAT address pools are not bound to any interfaces. The following figure illustrates the behavior of the firewall when it is performing proxy ARP for an address in a NAT address pool.
The firewall performs source NAT for a client, translating the source address to the address in the NAT pool, The translated packet is sent on to a router.
For the return traffic, the router does not know how to reach (because the IP address is just an address in the NAT address pool), so it sends an ARP request packet to the firewall.
If the address pool ( is in the same subnet as the egress/ingress interface IP address (, the firewall can send a proxy ARP reply to the router, indicating the Layer 2 MAC address of the IP address, as shown in the figure above. If the address pool ( is not a subnet of an interface on the firewall, the firewall will not send a proxy ARP reply to the router. This means that the router must be configured with the necessary route to know where to send packets destined for, in order to ensure the return traffic is routed back to the firewall, as shown in the figure below.

Related Documentation