cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
7807
Views
0
Helpful
5
Replies

Firepower Access Control List

CatinaMOC
Level 1
Level 1

Hello,

I installed firepower on an ASA 5545-X, version 6.1. The firewall is running in transparent mode. Firepower does not graph any connection events or graph any intrusion events. I believe the problem is caused by the firewall's global outside implicit deny statement. Is this normal? Currently, the global implicit deny will block everything before it reaches the SFR.

access-list sfr_redirect extended permit ip any any

!

class-map sfr
match access-list sfr_redirect

!

policy-map global_policy
class sfr
sfr fail-open

!

service-policy global_policy global

!

!

ACL from ASDM:

Inside:

Source ANY to Destination ANY LESS SECURE, Service IP, Action PERMIT

Global Implicit Deny:

Source ANY to Destination ANY, Service IP, Action DENY.

 

1 Accepted Solution

Accepted Solutions

I can understand your frustration but that is expected behavior. While the FirePOWER service is still a separate application even though it runs on the same box that runs the ASA code. Traffic just gets steered from the ASA to flow through FirePOWER for inspection but ouside of that the two applications run independently. Even the hardware (CPU and RAM) gets split and dedicated between the two applications. 

With that said, you have a couple of options here:

1. Upgrade the appliance to FTD (FirePOWER Threat Defense) code which combines the ASA and Sourcefire code into a single/unified image. This requires a complete re-image of the box and a good chuck of ASA features are not supported. At the current version, there is 100% Sourcefire feature parity and about 20% ASA feature parity. 

2. Remove all ASA based ACLs and only use FirePOWER based rules. I have several customers that did that before FTD was available and worked fine for them.

Thank you for rating helpful posts!

View solution in original post

5 Replies 5

nspasov
Cisco Employee
Cisco Employee

This is definitely possible. The ASA based ACLs and NATs come in place before the FirePOWER redirection and inspection. Take a look at the following link that provides more information about the order of operations and a nice diagram:

http://www.ciscopress.com/articles/article.asp?p=2730336&seqNum=7

I hope this helps!

Thank you for rating helpful posts!

Yeah that's a shame Firepower doesn't graph the data the primary ACL is dropping.

I can understand your frustration but that is expected behavior. While the FirePOWER service is still a separate application even though it runs on the same box that runs the ASA code. Traffic just gets steered from the ASA to flow through FirePOWER for inspection but ouside of that the two applications run independently. Even the hardware (CPU and RAM) gets split and dedicated between the two applications. 

With that said, you have a couple of options here:

1. Upgrade the appliance to FTD (FirePOWER Threat Defense) code which combines the ASA and Sourcefire code into a single/unified image. This requires a complete re-image of the box and a good chuck of ASA features are not supported. At the current version, there is 100% Sourcefire feature parity and about 20% ASA feature parity. 

2. Remove all ASA based ACLs and only use FirePOWER based rules. I have several customers that did that before FTD was available and worked fine for them.

Thank you for rating helpful posts!

cjvermeulen1
Level 1
Level 1

How is your firepower access control policy configured? Make sure you have it setup to log connections, else they won't show up in the analysis reports.

Yes it's configured to log connections but the connections are dropped by the implicit deny so they never make it to the SFR. To test, i removed the implicit deny it blocks port scans and telnet attempts about every 10 seconds. Obviously this is bad practice, so i put the implicit deny back on. I've concluded Firepower doesn't graph much data when primary ACL is setup securely. 

Review Cisco Networking for a $25 gift card