ASA pre-8.3 vs post-8.

3 NAT explained
In ASA software version 8.3(1), Cisco completely restructured ASA NAT syntax. Quite a bit
has already been written about these changes. However, since this is often a cause of
confusion, I will try to provide an explanation of three of the most commonly used forms of
NAT on an ASA: dynamic PAT, static NAT, and "nonat." Below you'll find pre-8.3 and post-8.3
configuration examples with translations into into plain English. Please feel free to
comment if you have any questions.

What is NAT?
I'll start with the basics. NAT stands for network address translation. It translates the real IP
address of a device to the mapped IP and vice versa.

Real IP: the actual IP address of the device generating the traffic (on the inside interface in
the examples below)
Mapped IP: the IP address the ASA translates the real IP address to (on the outside interface
in the examples below).

NAT is most often used to translate private RFC 1918 IP addresses to publicly routable IP
addresses (there are other less common uses as well).

For example:
A ping is sent from TestVM (192.168.10.2) to R1 (72.163.4.166). In this example, R1 is on the
internet, so the ASA cannot route the private address of 192.168.10.2 to R1. It must NAT the
packet.

We can see this happen in the Wireshark captures below:

When the ASA receives the packet on its inside interface, the source is 192.168.10.2
and the destination is 72.163.4.166. The packet header is re-written, and the packet is sent
out the outside interface with a source address of 72.163.4.161. The destination address
72.163.4.166 is not changed.
When the return traffic is received on the outside interface with a destination IP of
72.163.4.161, the packet header is once again re-written. The packet is sent out the inside
interface with a destination IP of 192.168.10.2. The source address 72.163.4.166 is not
changed.

On to the configuration examples...

Dynamic PAT - many-to-one

PAT stands for port address translation. It is many to one NAT translation. This is what
some vendors simply refer to as NAT. It is more accurately called PAT because in order to
translate many IPs to one IP, randomly selected ephermal ports must be used on the
mapped IP address. When return traffic is received, the ASA must check the xlate table (NAT
translation table) in order to determine where to send the return traffic.

Here is the xlate table from the example ping above:

asa01# sh xlate
1 in use, 1 most used
Flags: D - DNS, i - dynamic, r - portmap, s - static, I - identity, T - twice
ICMP PAT from inside:192.168.10.2/1 to outside:72.163.4.161/43857 flags ri idle
0:00:09 timeout 0:00:30
asa01#

Pre-8.3:
Configuration:
asa01(config)# nat (inside) 1 192.168.10.0 255.255.255.0
asa01(config)# global (outside) 1 interface
INFO: outside interface address added to PAT pool
asa01(config)#

This configuration says: Translate any traffic received on the inside interface from
192.168.10.0/24 (NAT ID 1) to the corresponding global PAT pool. In this case, nat (inside) 1
corresponds to global (outside) 1, so anything from 192.168.10.0/24 is translated to the
outside interface IP. Return traffic will be translated back to the real IP address by checking
the xlate table for the appropriate translation.

You could also use an IP address or range of IP addresses in place of the word "interface" in
the global statement. If you were to use a range of IP addresses in the global statement,
you would have a many-to-many dynamic NAT instead of many-to-one dynamic PAT.

Post-8.3:
Configuration:
asa01(config)# object network inside-network
asa01(config-network-object)# subnet 192.168.10.0 255.255.255.0
asa01(config-network-object)# nat (inside,outside) dynamic interface
asa01(config-network-object)#

This configuration says: Define a network object for subnet 192.168.10.0/24. Any traffic
received on the inside interface that matches this network object, translate to the outside
interface IP address. Return traffic will be translated back to the real IP address by checking
the xlate table for the appropriate translation.

Show run output:

asa01# sh run object

object network inside-network
subnet 192.168.10.0 255.255.255.0
asa01# sh run nat
!
object network inside-network
nat (inside,outside) dynamic interface

Notice when we configure object NAT in 8.3+, we configure both the subnet and the NAT
under the same network object. However, they appear separately in the show run output.
As with pre-8.3 config, we can also specify a specific IP or range of IPs for the translation.
Static NAT - one to one
Static NAT translates a single real IP to a single mapped IP. This is commonly used to NAT a
device on the inside or DMZ of an ASA to a static IP on the subnet of the outside interface.

Pre-8.3:
Configuration:
asa01 (config)# static (inside,outside) 72.163.4.162 192.168.10.2 netmask
255.255.255.255

Post-8.3:
Configuration:
object network inside-host
host 192.168.10.2
nat (inside,outside) static 72.163.4.162

Both of the above say the following: Traffic that is received on the inside interface from
192.168.10.2, translate to 72.163.4.162 on the outside interface, and vice versa.

In 8.2(5) and earlier, the syntax is static (inside,outside) [outside ip] [inside ip] netmask
[netmask]. I find this syntax to be counter intuitive, because it reads (inside,outside) and
then outside inside. I am not aware of any logical reason for this.

I find 8.3+ syntax to be easier to read, however it does dramatically increase the number of
lines per NAT statement. As with the PAT example above, if you look at the show run output
you will see the object listed twice - once to define the host and once to define the static
NAT. Therefore, what took a single line in 8.2(5) now takes four lines in 8.3(1) and above.

Both 8.3+ configuration examples so far have used network object NAT. Object NAT is easy
to use, but somewhat limited and only takes into account the source address. If we need
more control over our NAT statements, we can use twice NAT, which I will cover in greater
detail in a future post.

No-nat (NAT exemption & identity NAT)

There are certain circumstances when traffic is being translated on an ASA, but we do not
want this traffic to be translated when destined to specific subnets. The most common
example is VPN traffic. We want the source address of the VPN traffic to have the real IP,
not the mapped IP, for obvious reasons.

Pre-8.3:
Configuration:
access-list nonat extended permit ip 192.168.10.0 255.255.255.0
192.168.20.0 255.255.255.0
nat (inside) 0 access-list nonat

In ASA 8.2(5) and earlier, this is called NAT exemption. This says: define an extended access
list (in this case nonat) and specify the appropriate source and destination traffic. Any traffic
received on the inside interface that matches this access list, use NAT ID 0. NAT ID 0
exempts the traffic from being translated.

Post-8.3:
Configuration:
asa01(config)# object network inside-network
asa01(config-network-object)# subnet 192.168.10.0 255.255.255.0
asa01(config)# object network remote-network
asa01(config-network-object)# subnet 192.168.20.0 255.255.255.0
asa01(config)# nat (inside,outside) source static inside-network inside-
network destination static remote-network remote-network

In ASA 8.3(1) and above, NAT exemption no longer exists. This can now only be
accomplished by using identity NAT. Identity NAT is a form of twice NAT, which allows us to
specify both source and destination in our NAT statements. In the above configuration
example, we define two network objects: inside-network and remote-network. We then
configure an identity NAT statement that tells the ASA not to NAT the traffic.

The structure of the identity NAT statement is as follows:

nat (real_interface,mapped_interface) source static real_object mapped_object destination
static mapped_object real_object

So the example above says: Any traffic received on the inside interface from inside-network
destined to remote-network translate to the source to inside-network and the destination to
remote-network (ie. don't NAT it).

This is clearly less intuitive than the 8.2(5) syntax, but it's not that bad once you get used to
it.
ASA 8.2: Packet Flow through an ASA Firewall

Introduction

This document describes the packet flow through a Cisco Adaptive Security
Appliance (ASA) firewall. It shows the Cisco ASA procedure to process internal
packets. It also discusses the different possibilities where the packet could be
dropped and different situations where the packet progresses ahead.

Prerequisites

Requirements

Cisco recommends that you have knowledge of Cisco 5500 Series ASAs.

Components Used
 The information in this document is based on Cisco ASA 5500 Series ASAs that run
Software Version 8.2.

The information in this document was created from the devices in a specific lab
environment. All of the devices used in this document started with a cleared (default)
configuration. If your network is live, make sure that you understand the potential
impact of any command.

Background Information

The interface that receives the packet is called the ingress interface and the
interface through which the packet exits is called the egress interface. When you
refer to the packet flow through any device, the task is easily simplified if you look at
it in terms of these two interfaces. Here is a sample scenario:

When an inside user (192.168.10.5) attempts to access a web server in the

demilitarized zone (DMZ) network (172.16.10.5), the packet flow looks like this:

Source address - 192.168.10.5

Source port - 22966

Destination address - 172.16.10.5

Destination port - 8080

Ingress interface - Inside

Egress interface - DMZ

Protocol used - TCP (Transmission Control Protocol)

After you determine the details of the packet flow as described here, it is easy to
isolate the issue to this specific connection entry.

Cisco ASA Packet Process Algorithm

Here is a diagram of how the Cisco ASA processes the packet that it receives:
 Here are the individual steps in detail:

1. The packet is reached at the ingress interface.

2. Once the packet reaches the internal buffer of the interface, the input counter of
the interface is incremented by one.

3. Cisco ASA first looks at its internal connection table details in order to verify if this
is a current connection. If the packet flow matches a current connection, then the
Access Control List (ACL) check is bypassed and the packet is moved forward.

If packet flow does not match a current connection, then the TCP state is verified. If it is
a SYN packet or UDP (User Datagram Protocol) packet, then the connection counter is
incremented by one and the packet is sent for an ACL check. If it is not a SYN packet,
the packet is dropped and the event is logged.

4. The packet is processed as per the interface ACLs. It is verified in sequential order
of the ACL entries and if it matches any of the ACL entries, it moves forward.
Otherwise, the packet is dropped and the information is logged. The ACL hit count is
incremented by one when the packet matches the ACL entry.

5. The packet is verified for the translation rules. If a packet passes through this
check, then a connection entry is created for this flow and the packet moves forward.
Otherwise, the packet is dropped and the information is logged.

6. The packet is subjected to an Inspection Check. This inspection verifies whether or

not this specific packet flow is in compliance with the protocol. Cisco ASA has a built-in
inspection engine that inspects each connection as per its pre-defined set of
application-level functionality. If it passed the inspection, it is moved forward.
Otherwise, the packet is dropped and the information is logged.

Additional security checks will be implemented if a Content Security (CSC) module is

involved.

7. The IP header information is translated as per the Network Address Translation/

Port Address Translation (NAT/PAT) rule and checksums are updated accordingly. The
packet is forwarded to Advanced Inspection and Prevention Security Services Module
(AIP-SSM) for IPS related security checks when the AIP module is involved.

8. The packet is forwarded to the egress interface based on the translation rules. If
no egress interface is specified in the translation rule, then the destination interface is
decided based on the global route lookup.
9. On the egress interface, the interface route lookup is performed. Remember, the
egress interface is determined by the translation rule that takes the priority.

10. Once a Layer 3 route has been found and the next hop identified, Layer 2
resolution is performed. The Layer 2 rewrite of the MAC header happens at this stage.

11. The packet is transmitted on the wire, and interface counters increment on the
egress interface.

Cisco ASA Order of Operation

JUN 18TH, 2013 | COMMENTS

This post will cover the order of operation that takes place in a
Cisco ASA. Specifically the packet flow and each step that is
conducted.

Consider the following image that displays the packet flow.

1. Packet is received from the wire

2. Packet hits the ingress interface. Input counters are

incremented.
Inbound Packet Capture: Packet is processed by any packet
captures that exists on that interface

3. Does this packet have an existing connection?

If yes. Move ahead to step 6.
If no. If packet is TCP-SYN or UDP packet, proceed to ACL check.
Else drop packet.

4. Packet is processed by inbound access-list. Notes about

ACL checks:
First packet in flow is checked. All others are considered
existing connections.
The first matching rule in the ACL is all that will be checked
ACL hitcnt will increment with matching rule

5. NAT rules process packet. Notes regarding NAT rules:

In post 8.3 nat control is turned off on the ASA and cannot be
turned on. Pre 8.3 if nat control was on and a packet did not
match an XLATE it was dropped.
A route lookup is conducted only to determine egress interface
to match NAT rules
After translation takes place, the connection is created

6. Packet is processed by any inspect rules.

CSC Module: Packet is processed by CSC module if firewall has
it
CX Module: Packet is processed by CX module if firewall has it

7. Packet gets the IP address translated in the header. The

port is also translated if the translation is a PAT. New
 checksums are created for packet.
IPSM: If IPS module is installed the packet is then passed to the
module.

8. Packet is virtually forwarded to egress interface. Egress

interface is determined first by translation rules if known.

9. L3 route check. Once on the egress interface a route

check is performed. Only routes pointing to the egress interface
will be forwarded. If you receive a syslog that looks like this ASA-
6-110001: No route to 111.111.11.11 from 10.0.5.5 the NAT and route
have conflicting interfaces.

10. L2 address lookup. An ARP lookup is conducted at this

stage.
Outbound Packet Capture: Packet is processed by any
packet captures that exists on that interface

11. Packet is transmitted and put on wire. Interface counters

go up.

Source: Cisco Live Presentation in 2011, updated in 2012. I

have confirmed with a Cisco Technical Solutions Architect who
got confirmation from a Cisco developer that this packet
processing flow is valid for both pre 8.3 and post 8.3.
Data Flow
Heres another way to look at it which shows which plane the
packet is on during which

time.