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

Securing Routing Protocols on ASA

"The What?" - In this blog I will cover configuring, securing, verifying, & redistributing routing protocols on the ASA. Protocols covered include RIP, OSPF, EIGRP, & BGP. "The Why?" - Securing routi

Understanding, Configuring, & Verifying ASA Clustering

"The What?" - In this blog I will be covering ASA clustering. I intend on providing a brief general overview of ASA clustering, as well as how to configure one of the modes & perform verification. "T