Traffic Redirection to ASA FirePOWER Module

Building off of the following blog: Installing & Configuring FirePOWER Services Module on ASA - CLI, I will now cover how to redirect traffic to an ASA SFR module. I also intend on ASA SFR packet processing in regard to order of operations.


The main rule is that in order to redirect traffic to an ASA SFR module, you must create a service policy that identifies the interesting traffic that you wish to be subject to inspection.


The building blocks to enable traffic redirection to the module are as follows:


  1. Build an ACL that identifies the target traffic

  2. Create a class-map so you can match traffic in Block 1 ACL

  3. Specify deployment mode (inline/passive)

  4. Declare location & apply policy

Examples from CLI:


Building Block 1: ACL identifying subject traffic

#access-list FP_REDIRECT extended permit ip any any

Building Block 2: Class-map Creation

(config)#class-map sfr
(config-cmap)#match access-list FP_REDIRECT

Building Block 3: Specifying Mode


NOTE: There are two modes of operation, which are fail-open or fail-close. Fail-open will allow traffic to pass by ASA OS in case of SFR module failure. Fail-close on the other hand prevents traffic from passing if there is an SFR failure.

(config)#policy-map global_policy
(config-pmap)#class sfr
(config-pmap-c)#sfr fail-open

Should you be evaluating policy & the module is in passive use the following:

(config-pmap-c)# sfr fail-open monitor-only

Building Block 4: Applying Policy


You have the ability to apply a policy globally or specifically to an interface. If applying globally it is applied to all interfaces. You can override the global policy by apply a service policy to a specific interface.


Example of enabling globally:

#service-policy global_policy global

Next I will cover ASA FirePOWER Packet Processing Order of Operations:


NOTE: When the Cisco ASA FirePOWER module is deployed, the Cisco ASA processes all ingress packets against access control lists (ACLs), connection tables, Network Address Translation (NAT), and application inspections before traffic is forwarded to the FirePOWER Services module.


  1. A packet arrives on an interface. If the packet is for a VPN connection, then the packet is decrypted at this point in time. If ACL bypass is configured, then the ASA operations proceed to step 5.

  2. Now the ASA determines if there is an existing connection for the source & destination. If an existing connection exists, the ASA will bypass ACL checks & performs application inspection via step 5.

  3. If there is no existing connection for that traffic, the Cisco ASA performs the NAT checks (or untranslate process).

  4. The ASA will allow or deny traffic based on the rules in the ACLs.

  5. If traffic is allowed, the ASA performs application inspection.

  6. At this point in time in the order of operations the ASA will forward the packet to the ASA SFR module. The packet is then inspected and dropped only if it does not adhere to configured policies. If the packet is compliant with security policies then the packet is sent back to the ASA for further processing.

  7. The ASA determines the egress interface based on NAT or Layer 3 routing.

  8. Layer 3 routing is performed.

  9. Layer 2 address lookup occurs.

  10. The packet is sent to the network.

That wraps up this blog on redirecting traffic to the SFR module on ASA, Cheers!

0 comments

Recent Posts

See All

Understanding FTD Multi-Instance Capability Mode

In this post I want to cover running the multi-instance capability with Firepower Threat Detection (FTD). This capability lets you run containers that use a batch of resources of the security module/

Configuring & Verifying FTD NAT

"The What?" - In this post I will cover configuring NAT on Cisco FTD. Then I will walkthrough how to verify deployment with successful translations. The topology used to demo is below: "The Why?" -