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
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.
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:
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.
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.
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?
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".
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.
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