ASA Packet Processing Post 8.

3 Code
In this article, I will share my notes on the ASA packet process for version 8.3+. Domain 1.0 off
the CCIE Security version blueprint focuses on perimeter security and intrusion prevention, both
of which include the ASA. In order to understand the ASA and how it works, it is important to
understand how packets are processed as they enter the ASA.

1. The packet comes into the ingress interface and the ASA checks to see if there are any
existing connections. If a connection already exists, ACL’s are bypassed and the packet is
sent straight to the packet inspection, this is also known as the fast path. If a connection
doesn’t currently exist then the packet needs to be checked against ACL’s for any matches,
we can also see by looking at the diagram above, that the packet will be untranslated before
it is matched against the ACL rules. If an ACL match is found and it is permitted, the packet
will be inspected, likewise, if the packet is not permitted it is dropped. When a connection
doesn’t exist for a connection, it is processed down what is known as the slow path. A good
way to remember the ACL process for post 8.3+ is to remember that ACLs match on the real
IP address, take the following example.

Inside network 192.168.1.0/24 is within the private RFC 1918 address space and this means in order
for hosts on this network to communicate with the internet, the addresses need to use NAT. So as a
packet arrives on the ingress interface destined for the outside interface that leads to the internet
before NAT is used new connections will undergo pre-nat ACL checks and stateful inspection against
the real IP address. So your ACL rule would look something like this;

ASA(config)#object network INSIDE_NET (creates an object network for subnet 192.168.1.0/24)

ASA(config-network-object)#subnet 192.168.1.0 255.255.255.0ASA(config-network-object)#nat
(INSIDE,OUTSIDE) source dynamic interface (tells the ASA to NAT the objects subnet using the
outside interface IP address with PAT. This type of NAT is known as object NAT) ASA(config)#access-
list IN-TO-OUT extended permit ip object INSIDE_NET any  (Creates an ACL that permits IP from
192.168.1.0/24 network to any destination) ASA(config)#access-group IN-TO-OUT in interface
INSIDE (Applies ACL IN-TO-OUT to incoming traffic on the INSIDE interface of the ASA)

1. With stateful inspection, protocol compliance at L4 is checked (TCP, UDP, ICMP). The ASA
can also perform application inspection at L7 if configured. 

2. At the NAT IP Header section of the diagram, this is where the original source and
destination IP header is translated depending on what you have configured. In my example
configuration above, I am only translating the source IP address and not the destination. This
is also where PAT takes place and in my example above we can see that I am performing PAT
against the outside interface IP address. As shown in the diagram, we also have the ability to
send traffic to the IPS module, if this is the case, the real pre-nat IP information is supplied as
metadata. Firepower will perform the necessary inspections before passing the packet on.
NOTE: If you have the Firepower module configured, it doesn’t make sense to perform
application inspection on the ASA and the FP module. 

3. When traffic is passed to the egress interface, it is first done so virtually, meaning it is not yet
passed to the Ethernet network interface. The egress interface is determined by the
translation rules or the existing connection before it is determined by the routing table. If
the destination is unroutable the packet is dropped however if the egress interface is found
the ASA then looks for a L3 route. If the ASA doesn’t find a L3 route, the packet is dropped
but if it does then the ASA sends an ARP request to resolve the MAC-Address of that device.
Once ARP has resolved the packet is transmitted along the wire.