Skip to main content

Cisco ASA - Types of NAT and their Precedences

There are many types of NAT you can configure on the ASA FW. This is a short summary with examples for ASA 8.2/8.3 software.

Dynamic NAT
! The pool-number parameter ( 2, in this case) binds the 'global' and 'nat' commands
nat (dmz) 2 10.10.10.128 255.255.255.128
global (out) 2 172.16.16.129-172.16.16.254 netmask 255.255.255.128

Dynamic PAT
! Configuring PAT using the global address 172.16.16.126
ASA2(config)# nat (dmz) 1 10.10.10.0 255.255.255.0
ASA2(config)# global (out) 1 172.16.16.126

Identity NAT
! Configuring Identity NAT
ASA2(config)# nat (dmz) 0 10.10.10.128 255.255.255.192

Static NAT
! Static translation for an individual host (/32 is the default netmask)
ASA2(config)# static (dmz,out) 172.16.16.140 10.10.10.140

Static Policy NAT
ASA2(config)# access-list STATIC-POLICY1 extended permit ip host 10.10.10.148 host 172.16.16.200
ASA2(config)# static (dmz,out) 172.18.18.148 access-list STATIC-POLICY1

! For other destinations source address 10.10.10.148 is translated to 172.16.16.148
ASA2(config)# static (dmz,out) 172.16.16.148 10.10.10.148 netmask 255.255.255.255

Dynamic Policy NAT
! Packets from 10.10.10.128/27 travelling to host 172.16.16.200 undergo Policy NAT
access-list DYN-POLICY1 extended permit ip 10.10.10.128 255.255.255.224 host 172.16.16.200
!
nat (dmz) 4 access-list DYN-POLICY1
global (out) 4 172.17.17.129-172.17.17.158 netmask 255.255.255.224
!

Dynamic Policy PAT
! Policy PAT for source subnet 10.10.10.128/26 going to host 172.16.16.200
access-list DYN-POLICY2 extended permit ip 10.10.10.128 255.255.255.192 host 172.16.16.200
!
ASA2(config)# nat (dmz) 3 access-list DYN-POLICY2
ASA2(config)# global (out) 3 172.16.16.125

NAT Exemption
! Connections between 10.10.10.128/28 and 172.16.16.0/24 are exempted from NAT
access-list NONAT extended permit ip 10.10.10.128 255.255.255.240 172.16.16.0 255.255.255.0
!
nat (dmz) 0 access-list NONAT


In what order and precedence is ASA firewall processing various NAT configurations.

NAT precedence rules

Step 1.
NAT Exemption: This is always the first to be checked and has precedence over any other type of NAT rule that eventually conflicts with it.

Step 2.
Static Policy NAT: The motivation for this type of rule is to allow the selection of distinct global addresses for a given laddr, depending on the destination address (faddr) being contacted. This can be thought of as an exception to a generic static statement and, as such, needs to be configured before regular statics.

Step 3.
Static NAT: This is checked before all the Dynamic, Dynamic Policy, and Identity NAT rules. If some hosts that fall within a NAT Exemption range require static translation, the pertinent exceptions in the nat 0 access-list command need to be created, as previously illustrated in Example 8-14.

Step 4.
Dynamic Policy NAT/PAT: These rules are checked before the Dynamic and Identity NAT rules. If two rules of this category exist, the precedence is given by the order in which they were configured (does not matter if is a Policy PAT or Policy NAT).

Step 5.
Identity NAT: This unidirectional translation bypass method is evaluated before any Dynamic NAT or Dynamic PAT rule.

Step 6.
Dynamic NAT: This category has precedence over Dynamic PAT only.

Step 7.
Dynamic PAT: If after running through all the previous NAT types, ASA does not find a match, it still searches for a Dynamic PAT. If no matching rule is located, the implicit deny rule that characterizes the NAT-control model is enforced.

Labels:

Comments

Post a Comment

Popular posts from this blog

Basic Rules of Checkpoint Firewall

Managing the Firewall Rule Base: Explicit and Implied Rules These are the types of rules in the Rule Base: Explicit rules - Rules that you create to configure which connections the Firewall allows Implied rules - Rules that are based on settings in the Global Properties menu Implied rules allow connections for different services that the Security Gateway uses. For example, the Accept Control Connections option allows packets that control these services: ·          Installing the security policy on a Security Gateway ·          Sending logs from a Security Gateway to the Security Management server ·          Connecting to third party applications, such as RADIUS and TACACS authentication servers Order of Rule Enforcement: Make sure that you understand the importance of the order of rule enforcement to maximize the security of the Firewall. The Firewall always enforces the first rule that matches a connection. It does not enforce later rules tha
Post a Comment
Read more

ASA TCP Connection Flags

When troubleshooting TCP connections through the ASA, the connection flags shown for each TCP connection provide a wealth of information about the state of TCP connections to the ASA. This information can be used to troubleshoot problems with the ASA, as well as problems elsewhere in the network. Here is the output of the show conn protocol tcp command, which shows the state of all TCP connections through the ASA. These connections can also be seen with the show conn command. ASA# show conn protocol tcp 101 in use, 5589 most used TCP outside 10.23.232.59:5223 inside 192.168.1.3:52419, idle 0:00:11, bytes 0, flags saA TCP outside 192.168.3.5:80 dmz 172.16.103.221:57646, idle 0:00:29, bytes 2176, flags UIO TCP outside 10.23.232.217:443 inside 192.168.1.3:52427, idle 0:01:02, bytes 4504, flags TCP outside 10.23.232.217:5223 inside 192.168.1.3:52425, idle 0:00:10, bytes 0, flags saAUIO TCP outside 10.23.232.57:5223 inside 192.168.1.3:52412, idle 0:00:23, bytes 0, flag
Post a Comment
Read more

How to Set Up an IPSec Tunnel On PAN-OS - Palo Alto Firewalls

Set Up an IPSec Tunnel  The IPSec tunnel configuration allows you to authenticate and/or encrypt the data (IP packet) as it traverses across the tunnel.  If you are setting up the Palo Alto Networks firewall to work with a peer that supports policy-based VPN, you must define Proxy IDs. Devices that support policy-based VPN use specific security rules/policies or access-lists (source addresses, destination addresses and ports) for permitting interesting traffic through an IPSec tunnel. These rules are referenced during quick mode/IKE phase 2 negotiation, and are exchanged as Proxy-IDs in the first or the second message of the process. So, if you are configuring the Palo Alto Networks firewall to work with a policy-based VPN peer, for a successful phase 2 negotiation you must define the Proxy-ID so that the setting on both peers is identical. If the Proxy-ID is not configured, because the Palo Alto Networks firewall supports route-based VPN, the default values used as Proxy-ID are source
Post a Comment
Read more