NAT Policy Overview
Table of Contents
Expand all | Collapse all
-
- Tap Interfaces
-
- Layer 2 and Layer 3 Packets over a Virtual Wire
- Port Speeds of Virtual Wire Interfaces
- LLDP over a Virtual Wire
- Aggregated Interfaces for a Virtual Wire
- Virtual Wire Support of High Availability
- Zone Protection for a Virtual Wire Interface
- VLAN-Tagged Traffic
- Virtual Wire Subinterfaces
- Configure Virtual Wires
- Configure an Aggregate Interface Group
- Configure Bonjour Reflector for Network Segmentation
- Use Interface Management Profiles to Restrict Access
-
- DNS Overview
- DNS Proxy Object
- DNS Server Profile
- Multi-Tenant DNS Deployments
- Configure a DNS Proxy Object
- Configure a DNS Server Profile
- Use Case 1: Firewall Requires DNS Resolution
- Use Case 2: ISP Tenant Uses DNS Proxy to Handle DNS Resolution for Security Policies, Reporting, and Services within its Virtual System
- Use Case 3: Firewall Acts as DNS Proxy Between Client and Server
- DNS Proxy Rule and FQDN Matching
-
- NAT Rule Capacities
- Dynamic IP and Port NAT Oversubscription
- Dataplane NAT Memory Statistics
-
- Translate Internal Client IP Addresses to Your Public IP Address (Source DIPP NAT)
- Enable Clients on the Internal Network to Access your Public Servers (Destination U-Turn NAT)
- Enable Bi-Directional Address Translation for Your Public-Facing Servers (Static Source NAT)
- Configure Destination NAT with DNS Rewrite
- Configure Destination NAT Using Dynamic IP Addresses
- Modify the Oversubscription Rate for DIPP NAT
- Reserve Dynamic IP NAT Addresses
- Disable NAT for a Specific Host or Interface
-
- Network Packet Broker Overview
- How Network Packet Broker Works
- Prepare to Deploy Network Packet Broker
- Configure Transparent Bridge Security Chains
- Configure Routed Layer 3 Security Chains
- Network Packet Broker HA Support
- User Interface Changes for Network Packet Broker
- Limitations of Network Packet Broker
- Troubleshoot Network Packet Broker
-
- Enable Advanced Routing
- Logical Router Overview
- Configure a Logical Router
- Create a Static Route
- Configure BGP on an Advanced Routing Engine
- Create BGP Routing Profiles
- Create Filters for the Advanced Routing Engine
- Configure OSPFv2 on an Advanced Routing Engine
- Create OSPF Routing Profiles
- Configure OSPFv3 on an Advanced Routing Engine
- Create OSPFv3 Routing Profiles
- Configure RIPv2 on an Advanced Routing Engine
- Create RIPv2 Routing Profiles
- Create BFD Profiles
- Configure IPv4 Multicast
- Create Multicast Routing Profiles
- Create an IPv4 MRoute
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.
It is important to understand that in firewall policy rules,
the set of IPv4 addresses is treated as a subset of the set of IPv6
addresses. However, the set of IPv6 addresses is not a subset of
the set of IPv4 addresses. An IPv4 address can match a set or range
of IPv6 addresses; but an IPv6 address cannot match a set or range
of IPv4 addresses.
In all policy types, the keyword
any
for
a source or destination address means any IPv4 or IPv6 address.
The keyword any
is equivalent to ::/0. If
you want to express "any IPv4 address", specify 0.0.0.0/0.During policy matching, the firewall converts an IPv4 address
into an IPv6 prefix where the first 96 bits are 0. An address of
::/8 means, match the rule if the first 8 bits are 0. All IPv4 addresses
will match ::/8, ::/9, ::/10, ::/11, ... ::/16, ... ::/32, ...
through ::/96.
If you want to express "any IPv6 address, but no IPv4 addresses",
you must configure two rules. The first rule denies 0.0.0.0/0 to
deny any IPv4 address (as the source or destination address), and
the second rule has ::/0 to mean any IPv6 address (as the source
or destination address), to satisfy your requirement.
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 selecting and
testing the traffic matches for the NAT rule. For example:
Device
Troubleshooting
