cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Announcements

1058
Views
5
Helpful
7
Replies
Highlighted
Not applicable

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

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

7 REPLIES 7
Highlighted
Hall of Fame Guru

Igor,

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.

Highlighted
Not applicable

Thank you for the reply.

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

Highlighted
Hall of Fame Guru

Your thought are along the

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.

Highlighted
Not applicable

Any news on this topic? It

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?

Highlighted
Contributor

Did you use Security over

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

Highlighted
Not applicable

Yes I used Security over

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.

Highlighted
Not applicable

I have used "Balanced

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