Clarify Firepower Threat Defense Access Control Policy Rule Actions

Available Languages

Download Options

PDF (4.1 MB)
View with Adobe Reader on a variety of devices
ePub (4.0 MB)
View in various apps on iPhone, iPad, Android, Sony Reader, or Windows Phone
Mobi (Kindle) (3.3 MB)
View on Kindle device or Kindle app on multiple devices

Updated:August 21, 2019

Document ID:212321

Background Information

How ACP is Deployed

Configure

ACP Available Actions

How ACP and Prefilter Policy Interact

ACP Block Action

Scenario 1. Early LINA Drop

Scenario 2. Drop Due to Snort Verdict

ACP Allow Action

Scenario 1. ACP Allow Action (L3/L4 Conditions)

Scenario 2. ACP Allow Action (L3-7 Conditions)

Scenario 3. Snort Fast-Forward verdict with Allow

ACP Trust Action

Scenario 1. ACP Trust Action (L3/L4 Conditions)

Scenario 2. ACP Trust Action (L7 Condition)

Scenario 3. ACP Trust Action (L3/L4 with SI Disabled)

Prefilter Policy Block Action

Prefilter Policy Fastpath Action

Prefilter Policy Fastpath Action (Inline-Set)

Prefilter Policy Analyze Action

Scenario 1. Prefilter Analyze with ACP Block Rule

Scenario 2. Prefilter Analyze with ACP Allow Rule

Scenario 3. Prefilter Analyze with ACP Trust Rule

Scenario 4. Prefilter Analyze with ACP Trust Rule

FTD Behavior with Protocols that Open Secondary Connections

FTD Rule Guidelines

Summary

Related Information

Introduction

This document describes the various actions available on the Firepower Threat Defense (FTD) Access Control Policy (ACP) and Prefilter Policy. Furthermore, the background operation of each action is examined along with its interaction with other features like Flow Offload and protocols that open secondary connections.

Prerequisites

Requirements

Cisco recommends that you have knowledge of these topics:

Flow Offload
Packet captures on Adaptive Security Appliance (ASA) appliances
Packet tracer on ASA appliances

Components Used

The information in this document is based on these software and hardware versions:

Cisco Firepower 4110 Threat Defense Version 6.2.2 (Build 81)
Firepower Management Center (FMC) Version 6.2.2 (Build 81)

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, ensure that you understand the potential impact of any command.

Background Information

FTD is a unified software image that consists of 2 main engines:

LINA engine
Snort engine

This figure shows how the 2 engines interact:

A packet enters the ingress interface and it is handled by the LINA engine
If it is required by the FTD policy the packet is inspected by the Snort engine
The Snort engine returns a verdict (whitelist or blacklist) for the packet
The LINA engine drops or forwards the packet based on Snort’s verdict

How ACP is Deployed

The FTD policy is configured on FMC when off-box (remote) management is used or Firepower Device Manager (FDM) when local management is used. In both scenarios, the ACP is deployed as:

A global Access Control List (ACL) named as CSM_FW_ACL_ to the FTD LINA engine
Access Control (AC) rules in the /var/sf/detection_engines/UUID/ngfw.rules file to the FTD Snort engine

Configure

ACP Available Actions

The FTD ACP contains one or more rules and each rule can have one of these actions and as shown in the image:

Allow
Trust
Monitor
Block
Block with reset
Interactive Block
Interactive Block with reset

Similarly, a Prefilter Policy can contain one or more rules and the possible actions are shown in the image:

How ACP and Prefilter Policy Interact

Prefilter Policy got introduced in 6.1 version and serves 2 main purposes:

It allows the inspection of tunneled traffic where the FTD LINA engine checks the outer IP header while the Snort engine checks the inner IP header. More specifically, in case of tunneled traffic (e.g. GRE) the rules in the Prefilter policy always act on the outer headers while the rules in the ACP are always applicable to the inside sessions (inner headers). The tunneled traffic refers to these protocols:

GRE
IP-in-IP
IPv6-in-IP
Teredo Port 3544

It provides Early Access Control (EAC) which allows a flow to bypass completely the Snort engine as shown in the image.

The Prefilter Rules are deployed on FTD as L3/L4 Access Control Elements (ACEs) and are placed above the ACP configured L3/L4 ACEs as shown in the image:

Note: Prefilter v/s ACP rules = first match is applied.

ACP Block Action

Consider the topology shown in the image:

Scenario 1. Early LINA Drop

The ACP contains a Block rule which uses a L4 condition (Destination Port TCP 80) as shown in the image:

The deployed policy in Snort:

268435461 deny any 192.168.1.40 32 any any 192.168.2.40 32 80 any 6

The deployed policy in LINA. Note that the rule is pushed as deny action:

firepower# show access-list
…
access-list CSM_FW_ACL_ line 9 remark rule-id 268435461: L4 RULE: Rule1
access-list CSM_FW_ACL_ line 10 advanced deny tcp host 192.168.1.40 host 192.168.2.40 eq www rule-id 268435461 event-log flow-start (hitcnt=0) 0x6149c43c

Verify Behavior:

When host-A (192.168.1.40) tries to open an HTTP session to host-B (192.168.2.40) the TCP synchronize (SYN) packets are dropped by the FTD LINA engine without reaching the Snort Engine or the destination:

firepower# show capture
capture CAPI type raw-data buffer 33554432 trace trace-count 100 interface INSIDE [Capturing - 430 bytes]
  match ip host 192.168.1.40 any
capture CAPO type raw-data buffer 33554432 trace trace-count 100 interface OUTSIDE [Capturing - 0 bytes]
  match ip host 192.168.1.40 any

firepower# show capture CAPI
   1: 11:08:09.672801  192.168.1.40.32789 > 192.168.2.40.80: S 3249160620:3249160620(0) win 2920 <mss 1460,sackOK,timestamp 4060517 0>
   2: 11:08:12.672435  192.168.1.40.32789 > 192.168.2.40.80: S 3249160620:3249160620(0) win 2920 <mss 1460,sackOK,timestamp 4063517 0>
   3: 11:08:18.672847  192.168.1.40.32789 > 192.168.2.40.80: S 3249160620:3249160620(0) win 2920 <mss 1460,sackOK,timestamp 4069517 0>
   4: 11:08:30.673610  192.168.1.40.32789 > 192.168.2.40.80: S 3249160620:3249160620(0) win 2920 <mss 1460,sackOK,timestamp 4081517 0>

firepower# show capture CAPI packet-number 1 trace
   1: 11:08:09.672801  192.168.1.40.32789 > 192.168.2.40.80: S 3249160620:3249160620(0) win 2920 <mss 1460,sackOK,timestamp 4060517 0>
...

Phase: 4
Type: ACCESS-LIST
Subtype: log
Result: DROP
Config:
access-group CSM_FW_ACL_ global
access-list CSM_FW_ACL_ advanced deny tcp host 192.168.1.40 host 192.168.2.40 eq www rule-id 268435461 event-log flow-start
access-list CSM_FW_ACL_ remark rule-id 268435461: ACCESS POLICY: ACP1 - Mandatory
access-list CSM_FW_ACL_ remark rule-id 268435461: L4 RULE: Rule1
Additional Information:   
                             <- No Additional Information = No Snort Inspection

Result:
input-interface: INSIDE
input-status: up
input-line-status: up
output-interface: OUTSIDE
output-status: up
output-line-status: up
Action: drop
Drop-reason: (acl-drop) Flow is denied by configured rule

Scenario 2. Drop Due to Snort Verdict

The ACP contains a Block rule which uses a L7 condition (Application HTTP) as shown in the image:

The deployed policy in Snort:

268435461 deny any 192.168.1.40 32 any any 192.168.2.40 32 any any any  (appid 676:1)

Appid 676:1 = HTTP

The deployed policy in LINA.

Note: The rule is pushed as a permit action because LINA cannot determine that the session uses HTTP. On FTD the Application Detection mechanism is in Snort engine.

firepower# show access-list
…
access-list CSM_FW_ACL_ line 9 remark rule-id 268435461: L7 RULE: Rule1
access-list CSM_FW_ACL_ line 10 advanced permit ip host 192.168.1.40 host 192.168.2.40 rule-id 268435461 (hitcnt=0) 0xb788b786

For a Block Rule that uses Application as a condition, the trace of a real packet shows that the session is dropped by the LINA due to Snort engine verdict.

Note: In order for the Snort engine to determine the application it has to inspect a few packets (usually 3-10 which depends on the application decoder). Thus a few packets are allowed through the FTD and they make it to the destination. The allowed packets are still subject to the Intrusion Policy check based on the Access Policy > Advanced > 'Intrusion Policy used before Access Control rule is determined' option.

Verify Behavior:

When host-A (192.168.1.40) tries to establish an HTTP session with host-B (192.168.2.40) the LINA ingress capture shows:

firepower# show capture CAPI

8 packets captured

   1: 11:31:19.825564  192.168.1.40.32790 > 192.168.2.40.80: S 357753151:357753151(0) win 2920 <mss 1460,sackOK,timestamp 5450579 0>
   2: 11:31:19.826403  192.168.2.40.80 > 192.168.1.40.32790: S 1283931030:1283931030(0) ack 357753152 win 2896 <mss 1380,sackOK,timestamp 5449236 5450579>
   3: 11:31:19.826556  192.168.1.40.32790 > 192.168.2.40.80: P 357753152:357753351(199) ack 1283931031 win 2920 <nop,nop,timestamp 5450580 5449236>
   4: 11:31:20.026899  192.168.1.40.32790 > 192.168.2.40.80: P 357753152:357753351(199) ack 1283931031 win 2920 <nop,nop,timestamp 5450781 5449236>
   5: 11:31:20.428887  192.168.1.40.32790 > 192.168.2.40.80: P 357753152:357753351(199) ack 1283931031 win 2920 <nop,nop,timestamp 5451183 5449236>
 ...

The egress capture:

firepower# show capture CAPO

5 packets captured

   1: 11:31:19.825869  192.168.1.40.32790 > 192.168.2.40.80: S 1163713179:1163713179(0) win 2920 <mss 1380,sackOK,timestamp 5450579 0>
   2: 11:31:19.826312  192.168.2.40.80 > 192.168.1.40.32790: S 354801457:354801457(0) ack 1163713180 win 2896 <mss 1460,sackOK,timestamp 5449236 5450579>
   3: 11:31:23.426049  192.168.2.40.80 > 192.168.1.40.32790: S 354801457:354801457(0) ack 1163713180 win 2896 <mss 1460,sackOK,timestamp 5452836 5450579>
   4: 11:31:29.426430  192.168.2.40.80 > 192.168.1.40.32790: S 354801457:354801457(0) ack 1163713180 win 2896 <mss 1460,sackOK,timestamp 5458836 5450579>
   5: 11:31:41.427208  192.168.2.40.80 > 192.168.1.40.32790: S 354801457:354801457(0) ack 1163713180 win 2896 <mss 1460,sackOK,timestamp 5470836 5450579>

Trace shows that the first packet (TCP SYN) is allowed by the Snort since the Application Detection verdict is pending:

firepower# show capture CAPI packet-number 1 trace
   1: 11:31:19.825564  192.168.1.40.32790 > 192.168.2.40.80: S 357753151:357753151(0) win 2920 <mss 1460,sackOK,timestamp 5450579 0>
...

Phase: 4
Type: ACCESS-LIST
Subtype: log
Result: ALLOW
Config:
access-group CSM_FW_ACL_ global
access-list CSM_FW_ACL_ advanced permit ip host 192.168.1.40 host 192.168.2.40 rule-id 268435461
access-list CSM_FW_ACL_ remark rule-id 268435461: ACCESS POLICY: ACP1 - Mandatory
access-list CSM_FW_ACL_ remark rule-id 268435461: L7 RULE: Rule1
Additional Information:
 This packet will be sent to snort for additional processing where a verdict will be reached
...
Phase: 10
Type: FLOW-CREATION
Subtype:
Result: ALLOW
Config:
Additional Information:
New flow created with id 23194, packet dispatched to next module
…
Phase: 12
Type: SNORT
Subtype:
Result: ALLOW
Config:
Additional Information:
Snort Trace:
Packet: TCP, SYN, seq 357753151
AppID: service unknown (0), application unknown (0)
Firewall: starting rule matching, zone -1 -> -1, geo 0 -> 0, vlan 0, sgt 65535, user 9999997, icmpType 0, icmpCode 0
Firewall: pending rule-matching, id 268435461, pending AppID
NAP id 1, IPS id 0, Verdict PASS
Snort Verdict: (pass-packet) allow this packet

Result:
input-interface: OUTSIDE
input-status: up
input-line-status: up
output-interface: OUTSIDE
output-status: up
output-line-status: up
Action: allow

The same for the TCP SYN/ACK packet:

firepower# show capture CAPO packet-number 2 trace
   2: 11:31:19.826312 192.168.2.40.80 > 192.168.1.40.32790: S 354801457:354801457(0) ack 1163713180 win 2896 <mss 1460,sackOK,timestamp 5449236 5450579>
…

Phase: 3
Type: FLOW-LOOKUP
Subtype:
Result: ALLOW
Config:
Additional Information:
Found flow with id 23194, using existing flow
…

Phase: 5
Type: SNORT
Subtype:
Result: ALLOW
Config:
Additional Information:
Snort Trace:
Packet: TCP, SYN, ACK, seq 1283931030, ack 357753152
AppID: service unknown (0), application unknown (0)
Firewall: starting rule matching, zone -1 -> -1, geo 0 -> 0, vlan 0, sgt 65535, user 9999997, icmpType 0, icmpCode 0
Firewall: pending rule-matching, id 268435461, pending AppID
NAP id 1, IPS id 0, Verdict PASS
Snort Verdict: (pass-packet) allow this packet

Result:
input-interface: INSIDE
input-status: up
input-line-status: up
output-interface: INSIDE
output-status: up
output-line-status: up
Action: allow

Snort returns a DROP verdict after inspecting the third packet:

firepower# show capture CAPI packet-number 3 trace
   3: 11:31:19.826556  192.168.1.40.32790 > 192.168.2.40.80: P 357753152:357753351(199) ack 1283931031 win 2920 <nop,nop,timestamp 5450580 5449236>

Phase: 3
Type: FLOW-LOOKUP
Subtype:
Result: ALLOW
Config:
Additional Information:
Found flow with id 23194, using existing flow

Phase: 5
Type: SNORT
Subtype:
Result: DROP
Config:
Additional Information:
Snort Trace:
Packet: TCP, ACK, seq 357753152, ack 1283931031
AppID: service HTTP (676), application unknown (0)
Firewall: starting rule matching, zone -1 -> -1, geo 0(0) -> 0, vlan 0, sgt 65535, user 9999997, url http://192.168.2.40/128k.html
Firewall: block rule, id 268435461, drop
Snort: processed decoder alerts or actions queue, drop
NAP id 1, IPS id 0, Verdict BLACKLIST, Blocked by Firewall
Snort Verdict: (black-list) black list this flow

Result:
input-interface: INSIDE
input-status: up
input-line-status: up
Action: drop
Drop-reason: (firewall) Blocked or blacklisted by the firewall preprocessor

You can also run the command system support trace from FTD CLISH mode. This tool provides 2 functions:

Shows the Snort verdict for each packet as it is sent to Data Acquisition library (DAQ) and seen in LINA. DAQ is a component located between the FTD LINA engine and the Snort engine
Allows to run system support firewall-engine-debug at the same time to see what happens within the Snort engine itself

Here is the output:

> system support trace

Please specify an IP protocol: tcp
Please specify a client IP address: 192.168.1.40
Please specify a client port:
Please specify a server IP address: 192.168.2.40
Please specify a server port:
Enable firewall-engine-debug too? [n]: y
Monitoring packet tracer debug messages

Tracing enabled by Lina
192.168.2.40-80 - 192.168.1.40-32791 6 Packet: TCP, SYN, seq 2620409313
192.168.2.40-80 - 192.168.1.40-32791 6 AppID: service unknown (0), application unknown (0)
192.168.1.40-32791 > 192.168.2.40-80 6 AS 1 I 0 New session
192.168.1.40-32791 > 192.168.2.40-80 6 AS 1 I 0 Starting with minimum 2, 'Rule1', and SrcZone first with zones -1 -> -1, geo 0 -> 0, vlan 0, inline sgt tag: untagged, ISE sgt id: 0, svc 0, payload 0, client 0, misc 0, user 9999997, icmpType 0, icmpCode 0
192.168.1.40-32791 > 192.168.2.40-80 6 Firewall: starting rule matching, zone -1 -> -1, geo 0 -> 0, vlan 0, sgt 65535, user 9999997, icmpType 0, icmpCode 0
192.168.1.40-32791 > 192.168.2.40-80 6 AS 1 I 0 pending rule order 2, 'Rule1', AppID
192.168.1.40-32791 > 192.168.2.40-80 6 Firewall: pending rule-matching, 'Rule1', pending AppID
192.168.1.40-32791 > 192.168.2.40-80 6 NAP id 1, IPS id 0, Verdict PASS
Trace buffer and verdict reason are sent to DAQ's PDTS

Tracing enabled by Lina
192.168.2.40-80 - 192.168.1.40-32791 6 Packet: TCP, SYN, ACK, seq 3700371680, ack 2620409314
192.168.2.40-80 - 192.168.1.40-32791 6 AppID: service unknown (0), application unknown (0)
192.168.1.40-32791 > 192.168.2.40-80 6 AS 1 I 0 Starting with minimum 2, 'Rule1', and SrcZone first with zones -1 -> -1, geo 0 -> 0, vlan 0, inline sgt tag: untagged, ISE sgt id: 0, svc 0, payload 0, client 0, misc 0, user 9999997, icmpType 0, icmpCode 0
192.168.1.40-32791 > 192.168.2.40-80 6 Firewall: starting rule matching, zone -1 -> -1, geo 0 -> 0, vlan 0, sgt 65535, user 9999997, icmpType 0, icmpCode 0
192.168.1.40-32791 > 192.168.2.40-80 6 AS 1 I 0 pending rule order 2, 'Rule1', AppID
192.168.1.40-32791 > 192.168.2.40-80 6 Firewall: pending rule-matching, 'Rule1', pending AppID
192.168.1.40-32791 > 192.168.2.40-80 6 NAP id 1, IPS id 0, Verdict PASS
Trace buffer and verdict reason are sent to DAQ's PDTS

Tracing enabled by Lina
192.168.2.40-80 - 192.168.1.40-32791 6 Packet: TCP, ACK, seq 2620409314, ack 3700371681
192.168.2.40-80 - 192.168.1.40-32791 6 AppID: service HTTP (676), application unknown (0)
192.168.1.40-32791 > 192.168.2.40-80 6 AS 1 I 0 Starting with minimum 2, 'Rule1', and SrcZone first with zones -1 -> -1, geo 0(0) -> 0, vlan 0, inline sgt tag: untagged, ISE sgt id: 0, svc 676, payload 0, client 686, misc 0, user 9999997, url http://192.168.2.40/128k.html, xff
192.168.1.40-32791 > 192.168.2.40-80 6 Firewall: starting rule matching, zone -1 -> -1, geo 0(0) -> 0, vlan 0, sgt 65535, user 9999997, url http://192.168.2.40/128k.html
192.168.1.40-32791 > 192.168.2.40-80 6 AS 1 I 0 match rule order 2, 'Rule1', action Block
192.168.1.40-32791 > 192.168.2.40-80 6 AS 1 I 0 deny action
192.168.1.40-32791 > 192.168.2.40-80 6 Firewall: block rule, 'Rule1', drop
192.168.1.40-32791 > 192.168.2.40-80 6 Snort: processed decoder alerts or actions queue, drop
192.168.1.40-32791 > 192.168.2.40-80 6 AS 1 I 0 Deleting session
192.168.1.40-32791 > 192.168.2.40-80 6 NAP id 1, IPS id 0, Verdict BLACKLIST
192.168.1.40-32791 > 192.168.2.40-80 6 ===> Blocked by Firewall

Summary

The ACP Block Action gets deployed as either permit or deny rule in LINA which depends on the rule conditions
If the conditions are L3/L4 then the LINA blocks the packet. In case of TCP the first packet (TCP SYN) is blocked
If the conditions are L7 then the packet is forwarded to the Snort engine for further inspection. In case of TCP, a few packets are allowed through FTD until Snort reaches a verdict. The allowed packets are still subject to the Intrusion Policy check based on the Access Policy > Advanced > 'Intrusion Policy used before Access Control rule is determined' option.

ACP Allow Action

Scenario 1. ACP Allow Action (L3/L4 Conditions)

Normally, you would configure an Allow rule to specify additional inspections like an Intrusion Policy and/or a File Policy. In this first scenario here, is demonstrated the operation of an Allow rule when L3/L4 condition is applied.

Consider this topology as shown in the image:

This policy is applied as shown in the image:

The deployed policy in Snort. Note that the rule is deployed as an allow action:

# Start of AC rule.
268435461 allow any 192.168.1.40 32 any any 192.168.2.40 32 80 any 6

The policy in LINA.

Note: The rule is deployed as a permit action which essentially means redirect to Snort for further inspection.

firepower# show access-list
…
access-list CSM_FW_ACL_ line 9 remark rule-id 268435461: L7 RULE: Rule1
access-list CSM_FW_ACL_ line 10 advanced permit tcp host 192.168.1.40 host 192.168.2.40 eq www rule-id 268435461 (hitcnt=1) 0x641a20c3

In order to see how a flow that matches an Allow rule is handled by FTD there are a few ways:

Verify Snort Statistics
With the use of system support trace CLISH tool
With the use of capture with trace in LINA and optionally with capture-traffic in Snort engine

LINA capture vs Snort capture-traffic:

Verify Behavior:

Clear the Snort statistics, enable system support trace from CLISH and initiate an HTTP flow from host-A (192.168.1.40) to host-B (192.168.2.40). All the packets are forwarded to the Snort engine and get the PASS verdict by the Snort:

firepower# clear snort statistics

> system support trace

Please specify an IP protocol:
Please specify a client IP address: 192.168.1.40
Please specify a client port:
Please specify a server IP address: 192.168.2.40
Please specify a server port:
Enable firewall-engine-debug too? [n]:
Monitoring packet tracer debug messages

Tracing enabled by Lina
192.168.2.40-80 - 192.168.1.40-32797 6 Packet: TCP, SYN, seq 361134402
192.168.2.40-80 - 192.168.1.40-32797 6 AppID: service unknown (0), application unknown (0)
192.168.1.40-32797 > 192.168.2.40-80 6 Firewall: allow rule, 'Rule1', allow
192.168.1.40-32797 > 192.168.2.40-80 6 NAP id 1, IPS id 0, Verdict PASS
Trace buffer and verdict reason are sent to DAQ's PDTS

Tracing enabled by Lina
192.168.2.40-80 - 192.168.1.40-32797 6 Packet: TCP, SYN, ACK, seq 1591434735, ack 361134403
192.168.2.40-80 - 192.168.1.40-32797 6 AppID: service unknown (0), application unknown (0)
192.168.1.40-32797 > 192.168.2.40-80 6 Firewall: allow rule, 'Rule1', allow
192.168.1.40-32797 > 192.168.2.40-80 6 NAP id 1, IPS id 0, Verdict PASS
Trace buffer and verdict reason are sent to DAQ's PDTS

Tracing enabled by Lina
192.168.2.40-80 - 192.168.1.40-32797 6 Packet: TCP, ACK, seq 361134403, ack 1591434736
192.168.2.40-80 - 192.168.1.40-32797 6 AppID: service HTTP (676), application unknown (0)
192.168.1.40-32797 > 192.168.2.40-80 6 Firewall: allow rule, 'Rule1', allow
192.168.1.40-32797 > 192.168.2.40-80 6 NAP id 1, IPS id 0, Verdict PASS

Snort statistics reflect the above Snort PASS verdicts:

> show snort statistics

Packet Counters:
  Passed Packets                                           54
  Blocked Packets                                           0
  Injected Packets                                          0
  Packets bypassed (Snort Down)                             0
  Packets bypassed (Snort Busy)                             0

Flow Counters:
  Fast-Forwarded Flows                                      0
  Blacklisted Flows                                         0
...

Passed Packets = Inspected by the Snort engine

Scenario 2. ACP Allow Action (L3-7 Conditions)

Similar behavior is seen when the Allow rule is deployed as follows.

Only a L3/L4 condition as shown in the image:

A L7 condition (e.g. Intrusion Policy, File Policy, Application etc) as shown in the image:

Summary

In order to summarize, this is how a flow is handled by an FTD deployed on a FP4100/9300 when an Allow rule is matched as shown in the image:

Note: Management Input Output (MIO) is the Supervisor engine of the firepower chassis.

Scenario 3. Snort Fast-Forward verdict with Allow

There are specific scenarios where the FTD Snort egnine gives a WHITELIST verdict (fast-forward) and the rest of the flow is offloaded to the LINA engine (in some cases then is offloaded to the HW Accelarator - SmartNIC). These are:

Access control policy with trust action
SSL traffic without an SSL policy configured
File-detection policy
Intelligent application bypass(IAB)

The above can be visualized to:

or in some cases to:

Main Points

The Allow Rule is deployed as allow in Snort and permit in LINA
In most cases, all the packets of a session are forwarded to Snort engine for additional inspection

Use Cases

You would configure an Allow rule when you need L7 inspection by Snort Engine such as:

Intrusion Policy
File Policy

ACP Trust Action

Scenario 1. ACP Trust Action (L3/L4 Conditions)

If you don't want to apply any L7 actions at Snort level (e.g. Intrusion Policy, File Policy, Application Detection, URL Filtering, Security Intelligence etc) then it is recommended to use the Trust action in your rule.

Consider the topology as shown in the image:

This policy is applied as shown in the image:

The Trust rule as it is deployed in FTD Snort engine:

# Start of AC rule.
268435461 fastpath any 192.168.1.40 32 any any 192.168.2.40 32 80 any 6

Note: The number 6 is the protocol (TCP).

The rule in FTD LINA:

access-list CSM_FW_ACL_ line 10 advanced permit tcp host 192.168.1.40 host 192.168.2.40 eq www rule-id 268435461 (hitcnt=0) 0x641a20c3

Verify Behavior:

Initiate an HTTP session from host-A (192.168.1.40) to host-B (192.168.2.40) while you are running the system support trace CLI tool. There is only one packet (the TCP SYN) that is forwarded to Snort engine. Snort engine sends to LINA the WHITELIST verdict which essentially offloads the rest of the flow to the LINA itself:

> system support trace

Please specify an IP protocol: tcp
Please specify a client IP address: 192.168.1.40
Please specify a client port:
Please specify a server IP address: 192.168.2.40
Please specify a server port:
Enable firewall-engine-debug too? [n]:
Monitoring packet tracer debug messages


Tracing enabled by Lina
192.168.2.40-80 - 192.168.1.40-32791 6 Packet: TCP, SYN, seq 69186463
192.168.2.40-80 - 192.168.1.40-32791 6 AppID: service unknown (0), application unknown (0)
192.168.1.40-32791 > 192.168.2.40-80 6 Firewall: trust/fastpath rule, 'Rule1', allow
192.168.1.40-32791 > 192.168.2.40-80 6 NAP id 1, IPS id 0, Verdict WHITELIST

LINA capture shows the flow which goes through it:

> show capture CAPI

29 packets captured

   1: 19:14:29.214817 192.168.1.40.32791 > 192.168.2.40.80: S 69186463:69186463(0) win 2920 <mss 1460,sackOK,timestamp 3139222 0>
   2: 19:14:29.215549 192.168.2.40.80 > 192.168.1.40.32791: S 413254738:413254738(0) ack 69186464 win 2896 <mss 1380,sackOK,timestamp 3137895 3139222>
   3: 19:14:29.215687 192.168.1.40.32791 > 192.168.2.40.80: P 69186464:69186662(198) ack 413254739 win 2920 <nop,nop,timestamp 3139223 3137895>
   4: 19:14:29.216038 192.168.2.40.80 > 192.168.1.40.32791: . 413254739:413256107(1368) ack 69186662 win 2698 <nop,nop,timestamp 3137896 3139223>
   5: 19:14:29.216053 192.168.2.40.80 > 192.168.1.40.32791: P 413256107:413257475(1368) ack 69186662 win 2698 <nop,nop,timestamp 3137896 3139223>
   6: 19:14:29.216144 192.168.1.40.32791 > 192.168.2.40.80: . ack 413257475 win 2736 <nop,nop,timestamp 3139224 3137896>
   7: 19:14:29.216251 192.168.2.40.80 > 192.168.1.40.32791: P 413257475:413258843(1368) ack 69186662 win 2698 <nop,nop,timestamp 3137896 3139224>
…

when you trace the first packet, you can see the WHITELIST verdict:

firepower# show capture CAPI packet-number 1 trace
   1: 19:14:29.214817  192.168.1.40.32791 > 192.168.2.40.80: S 69186463:69186463(0) win 2920 <mss 1460,sackOK,timestamp 3139222 0>
…
Phase: 4
Type: ACCESS-LIST
Subtype: log
Result: ALLOW
Config:
access-group CSM_FW_ACL_ global
access-list CSM_FW_ACL_ advanced permit tcp host 192.168.1.40 host 192.168.2.40 eq www rule-id 268435461
access-list CSM_FW_ACL_ remark rule-id 268435461: ACCESS POLICY: ACP1 - Mandatory
access-list CSM_FW_ACL_ remark rule-id 268435461: L7 RULE: Rule1
Additional Information:
 This packet will be sent to snort for additional processing where a verdict will be reached
…
Phase: 12
Type: SNORT
Subtype:
Result: ALLOW
Config:
Additional Information:
Snort Trace:
Packet: TCP, SYN, seq 69186463
AppID: service unknown (0), application unknown (0)
Firewall: trust/fastpath rule, id 268435461, allow
NAP id 1, IPS id 0, Verdict WHITELIST
Snort Verdict: (fast-forward) fast forward this flow

For the rest of the flow (e.g. TCP SYN/ACK) you see:

firepower# show capture CAPO packet-number 2 trace
   2: 19:14:29.215503  192.168.2.40.80 > 192.168.1.40.32791: S 60351089:60351089(0) ack 1577779944 win 2896 <mss 1460,sackOK,timestamp 3137895 3139222>
…
Phase: 3
Type: FLOW-LOOKUP
Subtype:
Result: ALLOW
Config:
Additional Information:
Found flow with id 25353, using existing flow

Phase: 4
Type: SNORT
Subtype:
Result: ALLOW
Config:
Additional Information:
Snort Verdict: (fast-forward) fast forward this flow

Snort statistics confirm this:

> show snort statistics

Packet Counters:
  Passed Packets                                            0
  Blocked Packets                                           0
  Injected Packets                                          0
  Packets bypassed (Snort Down)                             0
  Packets bypassed (Snort Busy)                             0

Flow Counters:
  Fast-Forwarded Flows                                      1
  Blacklisted Flows                                         0
...                               0

Snort-level capture also confirms this:

> capture-traffic

Please choose domain to capture traffic from:
  0 - management0
  1 - Router

Selection? 1

Please specify tcpdump options desired.
(or enter '?' for a list of supported options)
Options: -n
19:04:17.429711 IP 192.168.1.40.32791 > 192.168.2.40.80: Flags [S], seq 69186463, win 2920, options [mss 1380,sackOK,TS val 2527484 ecr 0], length 0

Tip: The 'n' parameter does not convert IP addresses to names.

Scenario 2. ACP Trust Action (L7 Condition)

Consider this ACP rule as shown in the image:

The rule as it is deployed in FTD Snort engine:

268435461 fastpath any 192.168.1.40 32 any any 192.168.2.40 32 any any any  (appid 676:1)

The rule in FTD LINA:

access-list CSM_FW_ACL_ line 10 advanced permit ip host 192.168.1.40 host 192.168.2.40 rule-id 268435461 (hitcnt=0) 0xb788b786

Verify Behavior

Initiate an HTTP session from host-A (192.168.1.40) to host-B (192.168.2.40) while you run system support trace CLI tool. There are a few packets (2 in this case) that are sent to Snort engine and get the PASS Verdict while the AppID is pending. After Snort determines the Application it forwards the WHITELIST Verdict to LINA and the rest of the flow is handled by LINA:

> system support trace

Please specify an IP protocol: tcp
Please specify a client IP address: 192.168.1.40
Please specify a client port:
Please specify a server IP address: 192.168.2.40
Please specify a server port:
Enable firewall-engine-debug too? [n]:
Monitoring packet tracer debug messages


Tracing enabled by Lina
192.168.2.40-80 - 192.168.1.40-32836 6 Packet: TCP, SYN, seq 3970971741
192.168.2.40-80 - 192.168.1.40-32836 6 AppID: service unknown (0), application unknown (0)
192.168.1.40-32836 > 192.168.2.40-80 6 Firewall: starting rule matching, zone -1 -> -1, geo 0 -> 0, vlan 0, sgt 65535, user 9999997, icmpType 0, icmpCode 0
192.168.1.40-32836 > 192.168.2.40-80 6 Firewall: pending rule-matching, 'Rule1', pending AppID
192.168.1.40-32836 > 192.168.2.40-80 6 NAP id 1, IPS id 0, Verdict PASS
Trace buffer and verdict reason are sent to DAQ's PDTS

Tracing enabled by Lina
192.168.2.40-80 - 192.168.1.40-32836 6 Packet: TCP, SYN, ACK, seq 18638120, ack 3970971742
192.168.2.40-80 - 192.168.1.40-32836 6 AppID: service unknown (0), application unknown (0)
192.168.1.40-32836 > 192.168.2.40-80 6 Firewall: starting rule matching, zone -1 -> -1, geo 0 -> 0, vlan 0, sgt 65535, user 9999997, icmpType 0, icmpCode 0
192.168.1.40-32836 > 192.168.2.40-80 6 Firewall: pending rule-matching, 'Rule1', pending AppID
192.168.1.40-32836 > 192.168.2.40-80 6 NAP id 1, IPS id 0, Verdict PASS
Trace buffer and verdict reason are sent to DAQ's PDTS

Tracing enabled by Lina
192.168.2.40-80 - 192.168.1.40-32836 6 Packet: TCP, ACK, seq 3970971742, ack 18638121
192.168.2.40-80 - 192.168.1.40-32836 6 AppID: service HTTP (676), application unknown (0)
192.168.1.40-32836 > 192.168.2.40-80 6 Firewall: starting rule matching, zone -1 -> -1, geo 0(0) -> 0, vlan 0, sgt 65535, user 9999997, url http://192.168.2.40/16k.html
192.168.1.40-32836 > 192.168.2.40-80 6 Firewall: trust/fastpath rule, 'Rule1', allow
192.168.1.40-32836 > 192.168.2.40-80 6 NAP id 1, IPS id 0, Verdict WHITELIST

LINA capture shows that the packet # 3 had the HTTP GET method:

firepower# show capture CAPI dump
   1: 11:24:38.895888       192.168.1.40.32836 > 192.168.2.40.80: S 3970971741:3970971741(0) win 2920 <mss 1460,sackOK,timestamp 320516154 0>
0x0000   2c33 118d 570e 00c0 a801 2800 0800 4500        ,3..W.....(...E.
0x0010   0038 c03d 0000 4006 35e2 c0a8 0128 c0a8        .8.=..@.5....(..
0x0020   0228 8044 0050 ecb0 385d 0000 0000 9002        .(.D.P..8]......
0x0030   0b68 630e 0000 0204 05b4 0402 080a 131a        .hc.............
0x0040   b03a 0000 0000                                 .:....
   2: 11:24:38.896682       192.168.2.40.80 > 192.168.1.40.32836: S 18638120:18638120(0) ack 3970971742 win 2896 <mss 1380,sackOK,timestamp 320514827 320516154>
0x0000   00c0 a801 2800 2c33 118d 570e 0800 4500        ....(.,3..W...E.
0x0010   0038 1d1e 0000 4006 d901 c0a8 0228 c0a8        .8....@......(..
0x0020   0128 0050 8044 011c 6528 ecb0 385e 9012        .(.P.D..e(..8^..
0x0030   0b50 3efb 0000 0204 0564 0402 080a 131a        .P>......d......
0x0040   ab0b 131a b03a                                 .....:
   3: 11:24:38.896849       192.168.1.40.32836 > 192.168.2.40.80: P 3970971742:3970971940(198) ack 18638121 win 2920 <nop,nop,timestamp 320516155 320514827>
0x0000   2c33 118d 570e 00c0 a801 2800 0800 4500        ,3..W.....(...E.
0x0010   00fa c03e 0000 4006 351f c0a8 0128 c0a8        ...>..@.5....(..
0x0020   0228 8044 0050 ecb0 385e 011c 6529 8018        .(.D.P..8^..e)..
0x0030   0b68 0f62 0000 0101 080a 131a b03b 131a        .h.b.........;..
0x0040   ab0b 4745 5420 2f31 366b 2e68 746d 6c20        ..GET /16k.html
0x0050   4854 5450 2f31 2e30 0d0a 486f 7374 3a20        HTTP/1.0..Host:
...

Snort statistics confirm the above:

> show snort statistics

Packet Counters:
  Passed Packets                                            2
  Blocked Packets                                           0
  Injected Packets                                          0
  Packets bypassed (Snort Down)                             0
  Packets bypassed (Snort Busy)                             0

Flow Counters:
  Fast-Forwarded Flows                                      1
  Blacklisted Flows                                         0
...

On FTD which runs on FP4100/9300 appliance scenarios 1 and 2 can be visualized as shown in the image:

Scenario 3. ACP Trust Action (L3/L4 with SI Disabled)

In case you want the FTD to apply Security Intelligence (SI) checks to all flows SI is already enabled at ACP level and you can specify the SI sources (TALOS, feeds, lists etc). On the other hand, in case you want to disable it, you disable SI for Networks globally per ACP, SI for URL and SI for DNS. The SI for Networks and URL is disabled as shown in the image:

In this case the Trust rule is deployed to LINA as full trust:

> show access-list
...
access-list CSM_FW_ACL_ line 9 remark rule-id 268435461: L4 RULE: Rule1
access-list CSM_FW_ACL_ line 10 advanced trust ip host 192.168.1.40 host 192.168.2.40 rule-id 268435461 event-log flow-end (hitcnt=0) 0x5c1346d6

Note: As from 6.2.2 FTD supports TID. TID works in a way similar to SI, but in case SI is disabled, it does not ‘force’ packet redirection to Snort engine for TID inspection.

Verify the behavior

Initiate an HTTP session from host-A (192.168.1.40) to host-B (192.168.2.40). Since this an FP4100 and supports Flow Offload in hardware these things happen:

A few packets are forwarded through the FTD LINA engine and the rest of the flow is offloaded to SmartNIC (HW accelerator)
No packets are forwarded to Snort engine

The FTD LINA connection table shows the flag ‘o’ which means the flow was offloaded to HW. Also note the absence of ‘N’ flag. This essentially means 'no Snort redirection':

firepower# show conn
1 in use, 15 most used

TCP OUTSIDE  192.168.2.40:80 INSIDE  192.168.1.40:32809, idle 0:00:00, bytes 949584, flags UIOo

Snort statistics shows only logging events at the start and at the end of the session:

firepower# show snort statistics

Packet Counters:
  Passed Packets                                            0
  Blocked Packets                                           0
  Injected Packets                                          0
  Packets bypassed (Snort Down)                             0
  Packets bypassed (Snort Busy)                             0

Flow Counters:
  Fast-Forwarded Flows                                      0
  Blacklisted Flows                                         0

Miscellaneous Counters:
  Start-of-Flow events                                      1
  End-of-Flow events                                        1

FTD LINA logs show that for each session there were 2 flows (one per each direction) offloaded to HW:

Sep 27 2017 20:16:05: %ASA-7-609001: Built local-host INSIDE:192.168.1.40
Sep 27 2017 20:16:05: %ASA-6-302013: Built inbound TCP connection 25384 for INSIDE:192.168.1.40/32809 (192.168.1.40/32809) to OUTSIDE:192.168.2.40/80 (192.168.2.40/80)
Sep 27 2017 20:16:05: %ASA-6-805001: Offloaded TCP Flow for connection 25384 from INSIDE:192.168.1.40/32809 (192.168.1.40/32809) to OUTSIDE:192.168.2.40/80 (192.168.2.40/80)
Sep 27 2017 20:16:05: %ASA-6-805001: Offloaded TCP Flow for connection 25384 from OUTSIDE:192.168.2.40/80 (192.168.2.40/80) to INSIDE:192.168.1.40/32809 (192.168.1.40/32809)
Sep 27 2017 20:16:05: %ASA-6-805002: TCP Flow is no longer offloaded for connection 25384 from OUTSIDE:192.168.2.40/80 (192.168.2.40/80) to INSIDE:192.168.1.40/32809 (192.168.1.40/32809)
Sep 27 2017 20:16:05: %ASA-6-805002: TCP Flow is no longer offloaded for connection 25384 from INSIDE:192.168.1.40/32809 (192.168.1.40/32809) to OUTSIDE:192.168.2.40/80 (192.168.2.40/80)
Sep 27 2017 20:16:05: %ASA-6-302014: Teardown TCP connection 25384 for INSIDE:192.168.1.40/32809 to OUTSIDE:192.168.2.40/80 duration 0:00:00 bytes 1055048 TCP FINs
Sep 27 2017 20:16:05: %ASA-7-609002: Teardown local-host INSIDE:192.168.1.40 duration 0:00:00

On FTD which runs on FP4100/9300 appliance scenarios 1 and 2 can be visualized as shown in the image:

Use Cases

You must use Trust action when you want only a few packets to be checked by Snort engine (e.g. Application detection, SI check) and the rest of the flow to be offloaded to LINA engine
If you use FTD on FP4100/9300 and want the flow to completely bypass the Snort inspection then consider Prefilter rule with Fastpath action (see related section in this document)
Do not use Trust action for protocols that open secondary connections (e.g. FTP, SIP etc), but use Allow action instead (see related section in this document)

Prefilter Policy Block Action

Consider the topology as shown in the image:

Consider also the policy as shown in the image:

This is the deployed policy in FTD Snort engine (ngfw.rules file):

# Start of tunnel and priority rules.
# These rules are evaluated by LINA. Only tunnel tags are used from the matched rule id.
268437506 deny any 192.168.1.40 32 any any 192.168.2.40 32 any any any  (tunnel -1

In LINA:

access-list CSM_FW_ACL_ line 1 remark rule-id 268437506: PREFILTER POLICY: FTD_Prefilter
access-list CSM_FW_ACL_ line 2 remark rule-id 268437506: RULE: Prefilter1
access-list CSM_FW_ACL_ line 3 advanced deny ip host 192.168.1.40 host 192.168.2.40 rule-id 268437506 event-log flow-start (hitcnt=0) 0x76476240

when you trace a virtual packet, it shows that the packet is dropped by LINA and never forwarded to Snort:

firepower# packet-tracer input INSIDE icmp 192.168.1.40 8 0 192.168.2.40
…
Phase: 4
Type: ACCESS-LIST
Subtype: log
Result: DROP
Config:
access-group CSM_FW_ACL_ global
access-list CSM_FW_ACL_ advanced deny ip host 192.168.1.40 host 192.168.2.40 rule-id 268437506 event-log flow-start
access-list CSM_FW_ACL_ remark rule-id 268437506: PREFILTER POLICY: FTD_Prefilter
access-list CSM_FW_ACL_ remark rule-id 268437506: RULE: Prefilter1
Additional Information:

Result:
input-interface: INSIDE
input-status: up
input-line-status: up
output-interface: OUTSIDE
output-status: up
output-line-status: up
Action: drop
Drop-reason: (acl-drop) Flow is denied by configured rule

Snort statistics show:

firepower# show snort statistics

Packet Counters:
  Passed Packets                                            0
  Blocked Packets                                           0
  Injected Packets                                          0
  Packets bypassed (Snort Down)                             0
  Packets bypassed (Snort Busy)                             0

Flow Counters:
  Fast-Forwarded Flows                                      0
  Blacklisted Flows                                         0

Miscellaneous Counters:
  Start-of-Flow events                                      0
  End-of-Flow events                                        0
  Denied flow events                                        1

LINA ASP drops show:

firepower# show asp drop

Frame drop:
  Flow is denied by configured rule (acl-drop)                1

Use Cases

You can use Prefilter Block rule when you want to block traffic based on L3/L4 conditions and without the need to do any Snort inspection to the traffic.

Prefilter Policy Fastpath Action

Consider the Prefilter Policy rule as shown in the image:

This is the deployed policy in FTD Snort engine:

268437506 fastpath any 192.168.1.40 32 any any 192.168.2.40 32 80 any 6  (tunnel -1)

In FTD LINA:

access-list CSM_FW_ACL_ line 1 remark rule-id 268437506: PREFILTER POLICY: FTD_Prefilter
access-list CSM_FW_ACL_ line 2 remark rule-id 268437506: RULE: Prefilter1
access-list CSM_FW_ACL_ line 3 advanced trust tcp host 192.168.1.40 host 192.168.2.40 eq www rule-id 268437506 event-log flow-end (hitcnt=0) 0xf3410b6f

Verify Behavior

When host-A (192.168.1.40) tries to open an HTTP session to host-B (192.168.2.40) a few packets go through LINA and the rest are offloaded to SmartNIC. In this case ‘system support trace’ with firewall-engine-debug enabled shows:

> system support trace

Please specify an IP protocol: tcp
Please specify a client IP address: 192.168.1.40
Please specify a client port:
Please specify a server IP address: 192.168.2.40
Please specify a server port:
Enable firewall-engine-debug too? [n]: y
Monitoring packet tracer debug messages

192.168.1.40-32840 > 192.168.2.40-80 6 AS 1 I 8 Got end of flow event from hardware with flags 04000000

LINA logs show the offloaded flow:

Oct 01 2017 14:36:51: %ASA-7-609001: Built local-host INSIDE:192.168.1.40
Oct 01 2017 14:36:51: %ASA-7-609001: Built local-host OUTSIDE:192.168.2.40
Oct 01 2017 14:36:51: %ASA-6-302013: Built inbound TCP connection 966 for INSIDE:192.168.1.40/32840 (192.168.1.40/32840) to OUTSIDE:192.168.2.40/80 (192.168.2.40/80)
Oct 01 2017 14:36:51: %ASA-6-805001: Offloaded TCP Flow for connection 966 from INSIDE:192.168.1.40/32840 (192.168.1.40/32840) to OUTSIDE:192.168.2.40/80 (192.168.2.40/80)
Oct 01 2017 14:36:51: %ASA-6-805001: Offloaded TCP Flow for connection 966 from OUTSIDE:192.168.2.40/80 (192.168.2.40/80) to INSIDE:192.168.1.40/32840 (192.168.1.40/32840)

LINA captures show 8 packets going through:

firepower# show capture
capture CAPI type raw-data buffer 33554432 trace trace-count 100 interface INSIDE [Capturing - 3908 bytes]
  match ip host 192.168.1.40 host 192.168.2.40
capture CAPO type raw-data buffer 33554432 trace trace-count 100 interface OUTSIDE [Capturing - 3908 bytes]
  match ip host 192.168.1.40 host 192.168.2.40

firepower# show capture CAPI

8 packets captured

   1: 14:45:32.700021  192.168.1.40.32842 > 192.168.2.40.80: S 3195173118:3195173118(0) win 2920 <mss 1460,sackOK,timestamp 332569060 0>
   2: 14:45:32.700372  192.168.2.40.80 > 192.168.1.40.32842: S 184794124:184794124(0) ack 3195173119 win 2896 <mss 1380,sackOK,timestamp 332567732 332569060>
   3: 14:45:32.700540  192.168.1.40.32842 > 192.168.2.40.80: P 3195173119:3195173317(198) ack 184794125 win 2920 <nop,nop,timestamp 332569060 332567732>
   4: 14:45:32.700876  192.168.2.40.80 > 192.168.1.40.32842: . 184794125:184795493(1368) ack 3195173317 win 2698 <nop,nop,timestamp 332567733 332569060>
   5: 14:45:32.700922  192.168.2.40.80 > 192.168.1.40.32842: P 184795493:184796861(1368) ack 3195173317 win 2698 <nop,nop,timestamp 332567733 332569060>
   6: 14:45:32.701425  192.168.2.40.80 > 192.168.1.40.32842: FP 184810541:184810851(310) ack 3195173317 win 2698 <nop,nop,timestamp 332567733 332569061>
   7: 14:45:32.701532  192.168.1.40.32842 > 192.168.2.40.80: F 3195173317:3195173317(0) ack 184810852 win 2736 <nop,nop,timestamp 332569061 332567733>
   8: 14:45:32.701639  192.168.2.40.80 > 192.168.1.40.32842: . ack 3195173318 win 2697 <nop,nop,timestamp 332567734 332569061>

FTD Flow-offload statistics show 22 packets offloaded to HW:

firepower# show flow-offload statistics
 Packet stats of port : 0
        Tx Packet count                  :               22
        Rx Packet count                  :               22
        Dropped Packet count             :                0
        VNIC transmitted packet          :               22
        VNIC transmitted bytes           :            15308
        VNIC Dropped packets             :                0
        VNIC erroneous received          :                0
        VNIC CRC errors                  :                0
        VNIC transmit failed             :                0
        VNIC multicast received          :                0

You can also use the 'show flow-offload flow' command to see additional information related to the offloaded flows. Here is an example:

firepower# show flow-offload flow
Total offloaded flow stats: 2 in use, 4 most used, 20% offloaded, 0 collisions
TCP intfc 103 src 192.168.1.40:39301 dest 192.168.2.40:20, static, timestamp 616063741, packets 33240, bytes 2326800
TCP intfc 104 src 192.168.2.40:20 dest 192.168.1.40:39301, static, timestamp 616063760, packets 249140, bytes 358263320
firepower# show conn
5 in use, 5 most used
Inspect Snort:
        preserve-connection: 1 enabled, 0 in effect, 4 most enabled, 0 most in effect

TCP OUTSIDE  192.168.2.40:21 INSIDE  192.168.1.40:40988, idle 0:00:00, bytes 723, flags UIO
TCP OUTSIDE  192.168.2.40:21 INSIDE  192.168.1.40:40980, idle 0:02:40, bytes 1086, flags UIO
TCP OUTSIDE  192.168.2.40:80 INSIDE  192.168.1.40:49442, idle 0:00:00, bytes 86348310, flags UIO N1
TCP OUTSIDE  192.168.2.40:20 INSIDE  192.168.1.40:39301, idle 0:00:00, bytes 485268628, flags Uo  <- offloaded flow
TCP OUTSIDE  192.168.2.40:20 INSIDE  192.168.1.40:34713, idle 0:02:40, bytes 821799360, flags UFRIO

The percentage is based on 'show conn' output. For example if 5 conns are in total going through the FTD LINA engine and 1 of them is offloaded then 20% will be reported as offloaded
The maximum limit of offloaded sessions depends on the software version (e.g. ASA 9.8.3 and FTD 6.2.3 support 4 million bi-directional (or 8 million unidirectional) offloaded flows)
In case the number of offloaded flows reaches the limit (e.g. 4 million bi-directional flows) no new connections will be offloaded, until existing connections are removed from offloaded table

In order to see all the packets on FP4100/9300 that go through FTD (offloaded + LINA) there is need to enable capture at chassis level as shown in the image:

Chassis backplane capture shows both directions. Due to FXOS capture architecture (2 capture points per direction) every packet is shown twice as shown in the image:

Based on the above:

Total packets through FTD: 30
Packets through FTD LINA: 8
Packets offloaded to SmartNIC HW accelerator: 22

Use Cases

Use Prefilter Fastpath action when you want to bypass completely the Snort inspection. You typically want to do this for big fat flows that you trust like backups, database transfers etc
On FP4100/9300 appliances the Fastpath action triggers flow-offload and only a few packets goes through the FTD LINA engine. The rest is handled by SmartNIC which decreases the latency

Prefilter Policy Fastpath Action (Inline-Set)

In case a Prefilter Policy Fastpath action is applied on traffic going through an inline-set (NGIPS interfaces) the following points should be taken into consideration:

The rule will be applied to the LINA engine as a trust action
The flow will not be inspected by the Snort engine
Flow offload (HW acceleration) will not occur since flow offload is not applicable on NGIPS interfaces

Here is an example of a packet trace in case of Prefilter Fastpath action applied on an inline-set:

firepower# packet-tracer input inside tcp 192.168.1.40 12345 192.168.1.50 80 detailed

Phase: 1
Type: NGIPS-MODE
Subtype: ngips-mode
Result: ALLOW
Config:
Additional Information:
The flow ingressed an interface configured for NGIPS mode and NGIPS services will be applied
Forward Flow based lookup yields rule:
in id=0x2ad7ac48b330, priority=501, domain=ips-mode, deny=false
hits=2, user_data=0x2ad80d54abd0, cs_id=0x0, flags=0x0, protocol=0
src ip/id=0.0.0.0, mask=0.0.0.0, port=0, tag=any
dst ip/id=0.0.0.0, mask=0.0.0.0, port=0, tag=any, dscp=0x0
input_ifc=inside, output_ifc=any

Phase: 2
Type: ACCESS-LIST
Subtype: log
Result: ALLOW
Config:
access-group CSM_FW_ACL_ global
access-list CSM_FW_ACL_ advanced trust ip object 192.168.1.0 object 192.168.1.0 rule-id 268438531 event-log flow-end
access-list CSM_FW_ACL_ remark rule-id 268438531: PREFILTER POLICY: PF1
access-list CSM_FW_ACL_ remark rule-id 268438531: RULE: 1
Additional Information:
Forward Flow based lookup yields rule:
in id=0x2ad9f9f8a7f0, priority=12, domain=permit, trust
hits=1, user_data=0x2ad9b23c5d40, cs_id=0x0, use_real_addr, flags=0x0, protocol=0
src ip/id=192.168.1.0, mask=255.255.255.0, port=0, tag=any, ifc=any
dst ip/id=192.168.1.0, mask=255.255.255.0, port=0, tag=any, ifc=any, vlan=0, dscp=0x0
input_ifc=any, output_ifc=any

Phase: 3
Type: NGIPS-EGRESS-INTERFACE-LOOKUP
Subtype: Resolve Egress Interface
Result: ALLOW
Config:
Additional Information:
Ingress interface inside is in NGIPS inline mode.
Egress interface outside is determined by inline-set configuration

Phase: 4
Type: FLOW-CREATION
Subtype:
Result: ALLOW
Config:
Additional Information:
New flow created with id 7, packet dispatched to next module
Module information for forward flow ...
snp_fp_ips_tcp_state_track_lite
snp_fp_ips_mode_adj
snp_fp_tracer_drop
snp_ifc_stat

Module information for reverse flow ...
snp_fp_ips_tcp_state_track_lite
snp_fp_ips_mode_adj
snp_fp_tracer_drop
snp_ifc_stat

Result:
input-interface: inside
input-status: up
input-line-status: up
Action: allow

The above can be visualized as:

Prefilter Policy Analyze Action

Scenario 1. Prefilter Analyze with ACP Block Rule

Consider the Prefilter Policy which contains an Analyze rule as shown in the image:

The ACP contains only the default rule which is set to Block All Traffic as shown in the image:

This is the deployed policy in FTD Snort engine (ngfw.rules file):

# Start of tunnel and priority rules.
# These rules are evaluated by LINA. Only tunnel tags are used from the matched rule id.
268435460 allow any 192.168.1.40 32 any any 192.168.2.40 32 any any any  (tunnel -1)
268435459 allow any any  1025-65535 any any  3544 any 17  (tunnel -1)
268435459 allow any any  3544 any any  1025-65535 any 17  (tunnel -1)
268435459 allow any any  any any any  any any 47  (tunnel -1)
268435459 allow any any  any any any  any any 41  (tunnel -1)
268435459 allow any any  any any any  any any 4  (tunnel -1)
# End of tunnel and priority rules.
# Start of AC rule.
268435458 deny any any  any any any  any any any  (log dcforward flowstart)
# End of AC rule.

This is the deployed policy in FTD LINA engine:

access-list CSM_FW_ACL_ line 3 advanced permit ip host 192.168.1.40 host 192.168.2.40 rule-id 268435460 (hitcnt=0) 0xb788b786

Verify Behavior

In order to test with packet-tracer, it shows that the packet is allowed by LINA, is forwarded to Snort engine (due to permit action) and Snort Engine returns a Block verdict since the default action from AC is matched.

Note: Snort does not evaluate traffic based on tunnel rules

When you trace a packet it reveals the same:

firepower# packet-tracer input INSIDE icmp 192.168.1.40 8 0 192.168.2.40
...
Phase: 4
Type: ACCESS-LIST
Subtype: log
Result: ALLOW
Config:
access-group CSM_FW_ACL_ global
access-list CSM_FW_ACL_ advanced permit ip host 192.168.1.40 host 192.168.2.40 rule-id 268435460
access-list CSM_FW_ACL_ remark rule-id 268435460: PREFILTER POLICY: Prefilter_Policy1
access-list CSM_FW_ACL_ remark rule-id 268435460: RULE: Prefilter_Rule1
Additional Information:
 This packet will be sent to snort for additional processing where a verdict will be reached

…
Phase: 14
Type: SNORT
Subtype:
Result: DROP
Config:
Additional Information:
Snort Trace:
Packet: ICMP
AppID: service ICMP (3501), application unknown (0)
Firewall: starting rule matching, zone -1 -> -1, geo 0 -> 0, vlan 0, sgt 65535, user 9999997, icmpType 8, icmpCode 0
Firewall: block rule, id 268435458, drop
Snort: processed decoder alerts or actions queue, drop
NAP id 1, IPS id 0, Verdict BLACKLIST, Blocked by Firewall
Snort Verdict: (black-list) black list this flow

Result:
input-interface: INSIDE
input-status: up
input-line-status: up
output-interface: OUTSIDE
output-status: up
output-line-status: up
Action: drop
Drop-reason: (firewall) Blocked or blacklisted by the firewall preprocessor

Scenario 2. Prefilter Analyze with ACP Allow Rule

If the goal is to allow the packet to traverse through the FTD, there is need to add a rule in ACP. The Action can be either Allow or Trust which depends on the goal (e.g. if you want to apply a L7 inspection you must use Allow action) as shown in the image:

The deployed policy in FTD Snort engine:

# Start of AC rule.
268435461 allow any 192.168.1.40 32 any any 192.168.2.40 32 any any any
268435458 deny any any  any any any  any any any  (log dcforward flowstart)
# End of AC rule.

In LINA engine:

access-list CSM_FW_ACL_ line 3 advanced permit ip host 192.168.1.40 host 192.168.2.40 rule-id 268435460 (hitcnt=1) 0xb788b786

Verify Behavior

Packet-tracer shows that the packet matches rule 268435460 in LINA and 268435461 in Snort engine:

firepower# packet-tracer input INSIDE icmp 192.168.1.40 8 0 192.168.2.40
...
Phase: 4
Type: ACCESS-LIST
Subtype: log
Result: ALLOW
Config:
access-group CSM_FW_ACL_ global
access-list CSM_FW_ACL_ advanced permit ip host 192.168.1.40 host 192.168.2.40 rule-id 268435460
access-list CSM_FW_ACL_ remark rule-id 268435460: PREFILTER POLICY: Prefilter_Policy1
access-list CSM_FW_ACL_ remark rule-id 268435460: RULE: Prefilter_Rule1
Additional Information:
 This packet will be sent to snort for additional processing where a verdict will be reached
…
Phase: 14
Type: SNORT
Subtype:
Result: ALLOW
Config:
Additional Information:
Snort Trace:
Packet: ICMP
AppID: service ICMP (3501), application unknown (0)
Firewall: starting rule matching, zone -1 -> -1, geo 0 -> 0, vlan 0, sgt 65535, user 9999997, icmpType 8, icmpCode 0
Firewall: allow rule, id 268435461, allow
NAP id 1, IPS id 0, Verdict PASS
Snort Verdict: (pass-packet) allow this packet
…
Result:
input-interface: INSIDE
input-status: up
input-line-status: up
output-interface: OUTSIDE
output-status: up
output-line-status: up
Action: allow

Scenario 3. Prefilter Analyze with ACP Trust Rule

In case the ACP contains a Trust rule then you have this as shown in the image:

Snort:

# Start of AC rule.
268435461 fastpath any 192.168.1.40 32 any any 192.168.2.40 32 any any any
268435458 deny any any  any any any  any any any  (log dcforward flowstart)
# End of AC rule.

LINA:

access-list CSM_FW_ACL_ line 3 advanced permit ip host 192.168.1.40 host 192.168.2.40 rule-id 268435460 (hitcnt=2) 0xb788b786

Remember that since the SI is enabled by default, the Trust rule is deployed as permit action on LINA so at least a few packets are redirected to Snort engine for inspection.

Verify Behavior

Packet-tracer shows that the Snort engine Whitelists the packet essentially offloading the rest flow to LINA:

firepower# packet-tracer input INSIDE icmp 192.168.1.40 8 0 192.168.2.40
...
Phase: 4
Type: ACCESS-LIST
Subtype: log
Result: ALLOW
Config:
access-group CSM_FW_ACL_ global
access-list CSM_FW_ACL_ advanced permit ip host 192.168.1.40 host 192.168.2.40 rule-id 268435460
access-list CSM_FW_ACL_ remark rule-id 268435460: PREFILTER POLICY: Prefilter_Policy1
access-list CSM_FW_ACL_ remark rule-id 268435460: RULE: Prefilter_Rule1
Additional Information:
 This packet will be sent to snort for additional processing where a verdict will be reached
…
Phase: 14
Type: SNORT
Subtype:
Result: ALLOW
Config:
Additional Information:
Snort Trace:
Packet: ICMP
AppID: service ICMP (3501), application unknown (0)
Firewall: starting rule matching, zone -1 -> -1, geo 0 -> 0, vlan 0, sgt 65535, user 9999997, icmpType 8, icmpCode 0
Firewall: trust/fastpath rule, id 268435461, allow
NAP id 1, IPS id 0, Verdict WHITELIST
Snort Verdict: (fast-forward) fast forward this flow
…
Result:
input-interface: INSIDE
input-status: up
input-line-status: up
output-interface: OUTSIDE
output-status: up
output-line-status: up
Action: allow

Scenario 4. Prefilter Analyze with ACP Trust Rule

In this scenario the SI was disabled manually.

The rule is deployed in Snort as follows:

# Start of AC rule.
268435461 fastpath any 192.168.1.40 32 any any 192.168.2.40 32 any any any
268435458 deny any any  any any any  any any any  (log dcforward flowstart)
# End of AC rule.

In LINA the rule is deployed as full trust. A packet though must match the permit rule (see the ACE hit-counts) that is deployed due to Analyze Prefilter rule and the packet is inspected by the Snort engine:

access-list CSM_FW_ACL_ line 3 advanced permit ip host 192.168.1.40 host 192.168.2.40 rule-id 268435460 (hitcnt=3) 0xb788b786
...
access-list CSM_FW_ACL_ line 13 advanced trust ip host 192.168.1.40 host 192.168.2.40 rule-id 268435461 event-log flow-end (hitcnt=0) 0x5c1346d6
...
access-list CSM_FW_ACL_ line 16 advanced deny ip any any rule-id 268435458 event-log flow-start (hitcnt=0) 0x97aa021a

Verify Behavior

firepower# packet-tracer input INSIDE icmp 192.168.1.40 8 0 192.168.2.40
...
Phase: 4
Type: ACCESS-LIST
Subtype: log
Result: ALLOW
Config:
access-group CSM_FW_ACL_ global
access-list CSM_FW_ACL_ advanced permit ip host 192.168.1.40 host 192.168.2.40 rule-id 268435460
access-list CSM_FW_ACL_ remark rule-id 268435460: PREFILTER POLICY: Prefilter_Policy1
access-list CSM_FW_ACL_ remark rule-id 268435460: RULE: Prefilter_Rule1
Additional Information:
 This packet will be sent to snort for additional processing where a verdict will be reached
...
Phase: 14
Type: SNORT
Subtype:
Result: ALLOW
Config:
Additional Information:
Snort Trace:
Packet: ICMP
AppID: service ICMP (3501), application unknown (0)
Firewall: starting rule matching, zone -1 -> -1, geo 0 -> 0, vlan 0, sgt 65535, user 9999997, icmpType 8, icmpCode 0
Firewall: trust/fastpath rule, id 268435461, allow
NAP id 1, IPS id 0, Verdict WHITELIST
Snort Verdict: (fast-forward) fast forward this flow
…
Result:
input-interface: INSIDE
input-status: up
input-line-status: up
output-interface: OUTSIDE
output-status: up
output-line-status: up
Action: allow

Main Points

The Analyze Action is deployed as permit rule in LINA engine. This has as an effect the packet to be forwarded to Snort engine for inspection
The Analyze Action does not deploy any rule in Snort engine so you need to ensure that you configure a rule in ACP that matches in Snort
It depends on the ACP rule that is deployed in Snort engine (block vs allow vs fastpath) none or all or a few packets are allowed by Snort

Use Cases

A use case of Analyze Action is when you have a broad Fastpath rule in the Prefilter policy and you want to put some exceptions for specific flows so that they are inspected by Snort
Additionally, the Snort inspection implies that the flow is not offloaded into hardware (SmartNIC), but it is handled by Snort and LINA

FTD Behavior with Protocols that Open Secondary Connections

There are protocols like FTP, SIP etc which negotiates and open secondary connections dynamically. FTD opens pinholes for the secondary connections at 2 levels independently:

LINA engine
Snort engine

Additionally, when Snort opens a pinhole it signals LINA to open the same pinhole in case it is not already open.

With protocols that negotiate and open secondary connections you must use Allow action in ACP and never use Trust. The reason is that since Snort also opens pinholes it needs to inspect a few packets (the number depends on the application) before you open a pinhole at Snort level. If you use a Trust action, most of the times only a few packets are sent to Snort engine for inspection and the flow is offloaded to LINA before Snort has the time to check the protocol negotiation phase and open the needed pinholes at Snort level. The result is LINA to open pinholes, but Snort to drop the secondary connections (e.g. FTD Data channel).

Note: For protocols that require pinholes to be opened by FTD ensure that the ACP Rule matches an Application.
If the rule uses a Protocol Port as a condition then the Snort engine will not open a pinhole and flows like FTD Data will be dropped by FTD

FTD Rule Guidelines

Use Prefilter Policy Fastpath rules for big fat flows and in order to decrease latency through the box
Use Prefilter Block rules for traffic that must be blocked based on L3/L4 conditions
Use ACP Trust rules if you want to bypass many of the Snort checks, but still take advantage of features like Identity Policy, QoS, SI, Application detection, URL filter
Place more specific rules at the top of the Access Control Policy with the use of these guidelines

a. L3/L4 rules at the top

b. L7 rules below (Application detection, URL filtering etc)

c. Rules that require advanced Snort inspection (Intrusion Policy/File Policy) at the bottom of the policy

Avoid excessive logging (log at the start or at the end and avoid both at the same time)
Be aware of rule expansion, to check the number of rules in LINA

firepower# show access-list | include elements
access-list CSM_FW_ACL_; 7 elements; name hash: 0x4a69e3f3

Summary

How rules are deployed:

Allow vs Trust

Note: As from 6.3 FTD software code Dynamic flow offload can offload connections that meet additional criteria including Trusted packets that require Snort inspection. Check the 'Offload Large Connections (Flows)' section from the Firepower Management Center Configuration Guide for more details

Related Information

Contributed by Cisco Engineers

Mikis Zafeiroudis
Cisco TAC Engineer
Veronika Klauzova
Cisco TAC Engineer

Was this Document Helpful?

Clarify Firepower Threat Defense Access Control Policy Rule Actions

Available Languages

Download Options

Contents

Introduction

Prerequisites

Requirements

Components Used

Related Products

Background Information

How ACP is Deployed

Configure

ACP Available Actions

How ACP and Prefilter Policy Interact

ACP Block Action

Scenario 1. Early LINA Drop

Scenario 2. Drop Due to Snort Verdict

ACP Allow Action

Scenario 1. ACP Allow Action (L3/L4 Conditions)

Scenario 2. ACP Allow Action (L3-7 Conditions)

Scenario 3. Snort Fast-Forward verdict with Allow

ACP Trust Action

Scenario 1. ACP Trust Action (L3/L4 Conditions)

Scenario 2. ACP Trust Action (L7 Condition)

Scenario 3. ACP Trust Action (L3/L4 with SI Disabled)

Prefilter Policy Block Action

Prefilter Policy Fastpath Action

Prefilter Policy Fastpath Action (Inline-Set)

Prefilter Policy Analyze Action

Scenario 1. Prefilter Analyze with ACP Block Rule

Scenario 2. Prefilter Analyze with ACP Allow Rule

Scenario 3. Prefilter Analyze with ACP Trust Rule

Scenario 4. Prefilter Analyze with ACP Trust Rule

FTD Behavior with Protocols that Open Secondary Connections

FTD Rule Guidelines

Summary

Related Information

Contributed by Cisco Engineers

Was this Document Helpful?

Contact Cisco

Related Cisco Community Discussions

This Document Applies to These Products

Share