12-29-2016 01:51 PM - edited 03-12-2019 06:14 AM
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.
Solved! Go to Solution.
01-01-2017 11:57 PM
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!
12-30-2016 05:49 PM
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!
01-01-2017 04:52 PM
Yeah that's a shame Firepower doesn't graph the data the primary ACL is dropping.
01-01-2017 11:57 PM
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!
12-31-2016 09:02 AM
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.
01-01-2017 04:48 PM
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.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide