Understanding Firepower Packet Processing

I want to touch on a subject that is definitely something important to understand. This topic is Cisco Firepower NGFW packet processing. I will briefly hit on NGFW policies as well as they play a role in overall packet processing. To start, packet processing is handled via two main engines:

1. Lina (or ASA) engine

2. Snort (Firepower) engine

High level diagram looks like this:

Now to take this a little deeper for our understanding:

The LINA engine is based on the ASA firewall engine, which is responsible for traffic handling and filtering specific functions that include routing, L3/L4 ACLs, NAT, and VPN. The SNORT engine handles traffic inspection; specifically functions like security intelligence, IPS, AMP, URL filtering, or essentially anything requiring inspection beyond the L3/L4 header.

So, what does a more detailed traffic flow look like between the two engines? Let's dissect a little deeper:

For myself, so I can remember, I like to breakdown the packet flow into 3 phases: LINA start, SNORT, LINA finish. For sake of learning we will walk through a flow for a new connection. Also, keep in mind that not all 3 phases are always used, and we will go over this via the following flow walkthrough:

LINA start: The flow begins with a packet entering the ingress interface. The firewall then determines if there is an existing connection for the packet. During this decision it allows the firewall to determine if any phases can be skipped. Suppose a packet is new and there is no existing connection, the NGFW does a route lookup to identify which egress interface will be used to send the packet (*Very important: from a processing perspective this part is valuable as it can save processing power since there really is no true value on processing a packet that will not get routed out). Once the connection check and route lookup are performed the firewall proceeds with the next step, NAT.

Now the firewall will determine if the packet is subject to NAT, if it is it will change and determine the egress interface based on the NAT config. If not, it will utilize the egress interface determined via route lookup. Note that this determination is referenced later on.

Now the flow moves to the Pre-Filter policy check. This policy known as pre-filtering, is the first thing that is checked in relation to the access control phase. Quick note on pre-filtering: pre-filter policies are used first to determine quick blocks, ignore traffic, or fast-path traffic skipping further evaluation from the within the SNORT engine. If traffic is determined to be fast-pathed then the SNORT phase is skipped, and the packet is sent to what I like to call the LINA finish phase.

Now that the packet has traversed through the first few phases, the firewall begins more resource intensive checks. This part of the flow starts with the L3/L4 ACL checks via the LINA engine. *Remember that this applies only to new packets since existing/established sessions have already been processed via this check. This LINA engine ACL check is specifically for access control entries (ACE) that use L3/L4 rules only.

SNORT phase: Now that the packet has been processed through the first few phases to determine if the packet is for an existing connection or not, performed route lookup, determined any NAT related desires, conducted L3/L4 checks, it is now time for the firewall to determine if the packet needs to be redirected to the SNORT engine. This part of the packet flow is determined via the access control entry. If the ACE has configuration to require further inspection the packet is sent to SNORT. Examples triggering further inspection include: URL filtering, file policy, IPS policy.

Something you will see often when studying firepower in general is the acronym DAQ (Data Acquisition). The DAQ library is responsible for communicating with data path processes and the SNORT engine. *Essentially think of DAQ as the component of firepower that translates packets into syntax that the SNORT engine can understand.

Ok, so for our new flow and learning example let’s say the packet has been sent to SNORT. The SNORT engine processes the packet to determine a result to return back to the data path in the LINA engine.

LINA Finish: Once the result has been returned to LINA, LINA updates the flow connection table, and processes the packet based on the SNORT result (forward/drop). The last few potential/optional items before sending the packet out the egress interface include performing NAT, or encrypting the packet. Remember the firewall will use the route table lookup from the LINA start phase to get the next hop ip, and finally determine the L2 information to send the packet out.

At this point in the flow, the packet has been processed and forwarded. Note, that packet flows will vary in your environment based on your security configuration, and intended use of resources.


Recent Posts

See All

In the post I want to cover understanding IKEv1 status messages & debugging IKEv1 main mode. It is important as each message has its own unique meaning, and these messages are typically seen when att

"The What?" - In this post I will cover configuring & verifying a basic site-to-site VPN tunnel between two Cisco ASAs using IKEv1 with pre-shared keys (PSK). These types of VPNs are also known as L2