topic I have used "Balanced in Network Security

How to exclude network monitoring system IP in SFR configuration/rules?

Tue, 12 Mar 2019 13:23:46 GMT

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:

Cisco ASA 5516 (9.6.1)
SFR module 6.2.0.1
Firepower Center 6.2.0.1
Firepower Center policy: We have configured Allow action in the first rule in Access Control policy to allow ICMP Application (without Intrusion policy).
Logging is turned on for all rules (including Default action), however we cannot see any related Blocked log message in FirePower Center. Apparently there are some mechanisms which are in place which blocks our monitoring system, which I cannot find it.

Questions:

How/where (in FirePower config) we can exclude our network monitoring system from being blocked?
How to turn additional logging/debugging in FirePower center so to be able to see and trace such blocked connections?

Many thanks,

Igor VITORAC

Igor,

Marvin Rhoads — Fri, 12 May 2017 13:20:41 GMT

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.

Thank you for the reply.

Fri, 12 May 2017 14:33:58 GMT

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

Your thought are along the

Marvin Rhoads — Fri, 12 May 2017 15:00:17 GMT

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

Mon, 26 Jun 2017 13:25:53 GMT

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

Dennis Perto — Tue, 27 Jun 2017 17:53:33 GMT

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

Wed, 28 Jun 2017 06:51:15 GMT

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

Fri, 30 Jun 2017 11:51:01 GMT

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