05-12-2017 02:21 AM - last edited on 03-12-2019 06:23 AM by NikolaIvanov
Hello experts,
We have a network monitoring system (PRTG) in our network, which is using pings and other protocols to check some external IPs.
Till now, we have used FirePower module in monitor mode only. As soon as we try to pass traffic to SFR module, SFR module blocks some (not all) connections from monitoring system. Following could be seen in ASDM log:
4 May 10 2017 13:03:24 434002 SFR requested to drop ICMP packet from inside:10.x.x.x/2048 to outside:196.x.x.x/0
4 May 10 2017 13:03:25 434002 SFR requested to drop ICMP packet from inside:10.x.x.x/2048 to outside:77.x.x.x/0
Environment:
Questions:
Many thanks,
Igor VITORAC
05-12-2017 06:20 AM
Igor,
The method you have tried would appear to be correct. It's odd the the policy is causing a block action. Did you check both Connection events and Security Intelligence events in your FirePOWER Management Center to look for the block actions?
As a work around, you could simply modify your access-list referenced in the ASA class-map to not send the PRTG traffic to FirePOWER for inspection.
You might also try putting an "allow PRTG-any" ACP rule into FirePOWER to see if that changes the behavior at all.
05-12-2017 07:33 AM
Thank you for the reply.
I have tried again and nothing related to the IP of the PRTG IP in the Connection events and Security Intelligence events.
I have tried to put allow PRTG any ACP rule into FirePOWER (and re-deployed new policy), and I still receive in ASDM log:
34002 SFR requested to drop ICMP packet from inside:10.x.x.x/2048 to outside:196.x.x.x/0
but without anything in the FirePower events.
The workaround with ACL that excludes PRTG IP is working but in that case nothing is inspected related to PRTG host.
I have impression that it is somehow related to detection of Rate-Based Attack Prevention:
http://www.cisco.com/c/en/us/td/docs/security/firepower/620/configuration/guide/fpmc-config-guide-v62/detecting_specific_threats.html
I've tried to make my custom Network Analysis Policy (and linked to Access Policy) where I can exclude PRTG host from port scanning and rate-based attach prevention, but it did not help. Seems that SFR is doing rate-based detection on its own and perform actions on its own without possibility to affect its behavior.
Many thanks,
Igor Vitorac
05-12-2017 08:00 AM
Your thought are along the same lines as mine. I also thought about a prefilter policy but that would have the same effect as excluding it in the ASA ACL.
Perhaps TAC would be able to figure out why the Network Analysis Policy isn't working as intended.
06-26-2017 06:25 AM
Any news on this topic? It looks like I'm running into the same problem.
Fixed it by changing the Default Network Analysis policy to "Balanced Security and Connectivity", but this is not a real fix.
Just wondering if there was a real solution?
06-27-2017 10:53 AM
Did you use Security over Connectivity before this?
You should take notes of what changes, when you choose a new Network Analysis Policy, to learn why it is behaving like this. I figure it is "normalisation".
06-27-2017 11:51 PM
Yes I used Security over Connectivity.
I ran a compare between the two Nework Analysis Policies and I think it has something to do with Consecutive Small Segments.
Didn't test this yet, but I found this article and hoped that there were some results.
06-30-2017 04:51 AM
I have used "Balanced Security and Connectivity" only and I have still faced that problem.
In order avoid complete exclusion of monitoring system's IP, I have excluded only icmp related to the monitoring host.
In this way, I am still protecting monitoring host i.e. its traffic.
access-list acl_sfr_traffic extended deny icmp object PRTG any
access-list acl_sfr_traffic extended deny icmp any object PRTG
access-list acl_sfr_traffic extended permit ip any any
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