cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
585
Views
3
Helpful
4
Replies

FDM GUI Block Rule Shows Permit IP Any Any in CLI

TerenceLockette
Level 1
Level 1

Hello,

I am extremely irritated and frustrated with FDM and have no idea why anyone would want to manage the FTDs locally (I do know why but that's beyond the point). I am in the process of going through ACL rules in order to migrate away from the FDM FTDs to FTDs that are managed by FMC just like the rest of our NGFWs in our environment. As I am going through the ruleset, I noticed that 99% of the rules have a zero hit count which doesn't make sense to me. I also checked the secondary firewall in the HA pair in case some of those hit counts are there due to any failover scenarios and it's much the same. Upon further inspection, I noticed a GeoBlock rule in the CLI that is listed as a 'permit ip any any' listed right above the remaining rules that have zero hit counts. However, when I review the GeoBlock rule in the GUI, it shows the action as block and has a list of geographic regions we configured to be blocked. Perhaps I'm missing something but I don't have any other 'permit ip any any' rules explicitly defined on this firewall and what's even more confusing is why is this rule listed as a 'permit ip any any' rule? It makes all remaining rules obsolete and provides a false log of whether those rules are actually needed for my migration and puts me in the predicament of having to add rules that may not be needed any longer. Has anyone else seen this or have an answer as to why this is?

I'm attaching screen shots for your review and can clearly see, in the CLI output below, that the rule remark and actual rule share the same rule-id and the GUI image contains the same name as the rule in the CLI output. This makes absolutely no sense to me.

 

TerenceLockette_0-1729180988620.png

 

TerenceLockette_1-1729181017105.png

 

Thanks.

4 Replies 4

balaji.bandi
Hall of Fame
Hall of Fame
It makes all remaining rules obsolete and provides a false log of whether those rules are actually needed for my migration and puts me in the predicament of having to add rules that may not be needed any longer

as per the information, Looks for me someone did misconfiguraiton.

you only showing part of the configuration so i can not fully confident to comment on that.

Order of ACP Top to down

we list all allowed on the Top end with deny any any to block.

 

BB

***** Rate All Helpful Responses *****

How to Ask The Cisco Community for Help

Here is the rule order from rule 1 to the GeoBlock rule. No misconfiguration based on what's shown here. Any rules that may be any any specifies a source and destination zone. The CLI output doesn't even list source/dest zone which makes sense because the config from the GUI doesn't specify a zone:

TerenceLockette_0-1729183110292.png

 

@TerenceLockette 

Rules with Snort Features Are Deployed As Permit Any Any

When you create a rule with features that are run by Snort side, like Geolocation, URL (Universal Resource Locator) filter, Application detection, etc, they are deployed on Lina side as a permit any any rule.

https://www.cisco.com/c/en/us/support/docs/security/secure-firewall-threat-defense/218196-understand-how-lina-rules-configured-wit.html

 

So based on the URL referenced above, the appliance is indeed blocking this traffic so all other rules below with a zero hit count are not being matched against that 'permit ip any any' and are legit zero hit as the firewall has not matched any traffic against it; regardless of the GeoBlock 'permit ip any any'. Is this correct?

Review Cisco Networking for a $25 gift card