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!


Recent Posts

See All

"The What?" - In this blog I want to share some valuable Digital Network Architecture Center (DNAC) tips & tricks that I have collected that are quite useful when needing to troubleshoot/perform some

In this post I want to cover the ESA Email pipeline. The email pipeline represents how emails are processed through the system from start to finish. The pipeline consists of 3 main phases: Receipt:

I recently started pursuing email security studies. Other posts have mentioned this, and a recent post shared a deeper look at SPF. In this blog I want to cover DKIM & DMARC. Starting with DKIM, it