Cisco Firepower Threat Defense (FTD) Packet Flow


It’s important to understand the packet flow for a FTD device. By understanding the flow you can both troubleshoot and create true policy, and knowing your detection process will impact 2 things:

• How you analyze the data
• How you tune your security appliance

Optimizing detection also becomes easier when you understand the complete path a packet (and the flow) takes through the FTD device. Here are two key optimization points to remember:

  • Layer 2-4 traffic that can be matched and either blocked or allowed with FastPath will be handled entirely in hardware.
  • Layer 3 Security Intelligence is the first detection that occurs in the Snort process (Now called Firepower layer). All of this traffic will be blocked and no other additional inspection will occur. This optimized your treat monitoring by stopping active threat companies without the need for additional threat analysis.

Understand that there are 2 main engines in the FTD unified software image: Lina and Snort. Lina is the ASA code that FTD runs on, and the snort process is the network analysis of the packets that goes from security intelligence (SI) through the ACP inspection of the traffic by the Snort IPS rules.

Here is an overview of the packet flow:

  • When a packet enters the ingress interface and it is handled by the LINA engine
  • The packet is inspected by the Snort engine, if configured to do so; this can include SI, IPS, AMP, URL filtering among other inspections.
  • The Snort engine returns a verdict for the packet
  • It’s important to note that the Snort engine does not drop anything, but instead marks the packet drop or forward, based on the snort verdict.

Lina does the process of layer 2, routing, NAT, VPN, PreFilter, and layer 3-4 access control policy rules before the snort process takes over the analysis. The Lina code takes over again after the default action of the ACP and again does layer 2, routing, NAT, VPN, etc.

After a packet makes it through the Lina without being killed by the PreFiler or layer 3/4 ACP, then it starts traversing the Snort process by going through the Layer 3 Security Intelligence (SI) White and Blacklist. If the packet does make it through the Blacklist, by either not being in the Blacklist or by being in the Whitelist (the Whitelist only exists to override the Blacklist), then application detection can take place.

If there is an SSL policy, the packets can be decrypted and possibly dropped here, if not, it will then go through the L7 SI URL and DNS list and feeds. Authentication can now take place, either actively or passively via an Identity Policy.

Now finally, the packets will be compared to the rules in the main Access Control policy (L7 ACL). Packets can be dropped, passed or even trusted and sent to Egress. It’s important to understand that the packets can be passed before the Snort process by using the PreFilter FastPath rules, or ACP layer 3/4 trust rules. However, remember that the PreFilter is only layer 3/4 whereas the ACP is through L7.

Interface QoS policing can be applied here (but is actually enforced in LINA), and Network Discovery can be configured to either passively or actively gather host/user/application information to help in network analysis.

If configured, URL filtering and the Malware/file policy will be enforced as well as the IPS rules against the traffic. AMP takes the packets and assembles them into files if they match the protocol in the file policy rule. Files that match the malware and file policy can be inspected against data in the cloud, have local malware checks performed or the files themselves may be transfered to a sandbox for inspection. If traffic makes it through the file inspection  process it will finally be evaluated against the enabled Snort IPS rules.

Finally, assuming the packets are still alive, the packets will be handed to the Lina process for layer 2, routing, NAT, VPN, etc.



  1. Hi sir,

    I have a query in our environment, we have implemented Firepower , after the implementation we got an issue that bulk FTP is not working.

    After passing the traffic through pre-filter policy as fast-path bulk FTP started.

    As per the article, if we do fast-path packet wil avoid snort engine, so do you suspect that there is some issue with our snort engine ?

    Bug or some other thing .

    1. No, I don’t think that you have something wrong with the snort engine, you have something wrong in your Access Control Policy that’s blocking it. Email me a pic of your ACP rules and I’ll take a look

    1. Two places, at the beginning and end of the LINA process, and at every policy listed in the diagram for the SNORT process.

    1. Go to Devices>Device> and enable the Automatic Application Bypass option, which bypasses snort when it crashes
      this should be enabled by default, but it is not.

    1. The FMC pushes policy and provides network analysis, so you only lose AD integration and AMP if the FMC goes down

    1. That is the Lina process where NAT and VPN encryption/decryption happens, so that is the Ingress and Egress ASA code

      1. 1. Let’s consider NAT which has two options
        a. Source Nat
        b. Destination NAT
        2. Let’s consider Route which has two options
        c. Policy Route
        d. Static Route
        3.Now there are two places where NAT and Routes are being checked
        1. Before Snort
        2. After Snort
        May I know which is the order via which the packet flows ?
        Is it,
        1 (b,c,d)
        2 (a,c,d)

        1. SNORT has nothing to do with any of that, and only sends a snort verdict to the egress interface. What your asking is done 100% the same as it was with ASA code, as it is ASA code, no differences in this.

    2. I mean, why do we have two different places where the lina engine is checking for NAT and Route ?
      Also, appreciate if you can explain which would be checked first? Route or Nat ?

  2. Why “show traffic” shows different traffic rates on Inside/Outside interfaces than what appears on physical interfaces assigned on FXOS?

    On FTD
    received (in 136261.290 secs):
    8453958335 packets 5358770956222 bytes
    62010 pkts/sec 39327012 bytes/sec
    transmitted (in 136261.290 secs):
    4930655161 packets 761573415361 bytes
    36027 pkts/sec 5589003 bytes/sec
    1 minute input rate 70372 pkts/sec, 48774860 bytes/sec
    1 minute output rate 39665 pkts/sec, 6833925 bytes/sec
    1 minute drop rate, 1384 pkts/sec
    5 minute input rate 72095 pkts/sec, 49291003 bytes/sec
    5 minute output rate 40480 pkts/sec, 7182970 bytes/sec
    5 minute drop rate, 1287 pkts/sec
    received (in 136261.290 secs):
    5042376611 packets 772812853681 bytes
    37005 pkts/sec 5671015 bytes/sec
    transmitted (in 136261.290 secs):
    8975993109 packets 5439996074059 bytes
    65022 pkts/sec 39923016 bytes/sec
    1 minute input rate 40489 pkts/sec, 6936204 bytes/sec
    1 minute output rate 77346 pkts/sec, 49986945 bytes/sec
    1 minute drop rate, 1254 pkts/sec
    5 minute input rate 41448 pkts/sec, 7306418 bytes/sec
    5 minute output rate 78980 pkts/sec, 50535980 bytes/sec
    5 minute drop rate, 1328 pkts/sec
    FXOS Side:
    Eth1/2: 5 min input rate 2009.7 Mb/s, output rate 260.8 Mb/s (Mapped to Outside)
    Eth1/3: 5 min input rate 248.5 Mb/s (5.8%), output rate 2047.2 Mb/s (Mapped to Inside)

    Since the traffic rates shown by ftp is far lower than what are being observed on physical interfaces, I am not sure hot rate limits (FTD Qos) could be applied?

    Do you have any comments/suggestions? CISCO TAC is silent.

    1. Hello, I am not sure of the answer either. I am sure TAC won’t know this as well. If you do QoS, that is only interface policing and it is applied or enforced in the egress interface

  3. i have one issue with our telephonic service we are using ribbon voice gateway and for calling we are using MS teams, while making external call we are unable to hear anything but call is getting connect after i tried couple of time call may work we are able to hear each other.
    as per voice gateway vendor there is issue with my FTD 2110 firewall
    please advise on this

  4. 1. i want to know about Data Aquisition ( copy packet to memory ) ,what is this actually about .
    as per diagram i understand Lina engine will give packet to Data aquisition then DAQ will give it to Snort , Snort will inspect and again give it back to DAQ then back to Lina .

    Correct me if iam wrong and please explain what is Data aquisition .

    2. You said snort engine will never drop any packet and then at a same time you side ( Finally, assuming the packets are still alive, the packets will be handed to the Lina process for layer 2, routing, NAT, VPN, etc. )
    Confused , as per my understanding snort will mark which traffic to drop and which to allow .
    looking for your valuable answer .

    1. hello, good question.
      the packet is placed in memory and that location is sent to each snort process. The snort process hands a verdict to the LINA only, and then the packet is sent to the Egress or deleted from memory.

Leave a Reply

Your email address will not be published. Required fields are marked *