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.0 ASA(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.

#cciesecurity #asapost83 #cciesecurityv5 #asa #cciesecuritynotes #ciscoasapacketprocess #asafirewall #asapacketprocesspost83 #asapacketprocess #ciscoasa