FTD Geolocation Question

[dcanady55]

FTD 2110 on 7.4 Geolocation 2024-12-14-066

I have an Access Control Policy (ACP) rule configured to block access from our internal network to several foreign countries using Cisco’s Geolocation feature. However, I’m still observing traffic to these blocked countries. I’ve verified through the geo tab within the Firepower Threat Defense (FTD) that the IP address in question is indeed Russian, and my Umbrella search confirms this as well. The ACL rule is positioned near the top of my rule set, and packet tracer indicates that the traffic is being allowed. Is there a specific aspect I should investigate to understand why this traffic is not being blocked?

Thanks

[MHM Cisco World]

the ACP with Geo Allow some packet, these packet send to snort for deep inspection and after Geo resolve the snort will block the traffic 

so it normal to see some packet allow

MHM

[Rob Ingram · Accepted solution]

@dcanady55 is the Geo database up to date? https://www.cisco.com/c/en/us/td/docs/security/secure-firewall/management-center/admin/710/management-center-admin-71/system-updates.html#ID-2259-0000066f You can also check the GeoDB file, this is located /var/sf/geodb/ipv4_country_code_map

Run system support firewall-engine-debug and simulate the traffic, confirm which rule it matches.

More information about Geolocation - https://integrate.uk.com/ftd-geolocation/

[dcanady55]

Hey Rob,

Thanks for the additional information! I was able to simulate the traffic and confirmed it was being blocked. Initially, I was looking for Syslog ID 430003, but it turns out the logs were under 430002.

Why wouldn’t packet tracer show that this would be blocked by Snort? Besides attempting to access the actual IP address and service I’m trying to block, which seems risky, how else can one confirm that the rules they are building are effective if packet tracer doesn’t provide accurate results?

Thanks again to MHM and you for the quick responses!

[dcanady55]

Thanks for the additional information! I was able to simulate the traffic and confirmed it was being blocked. Initially, I was looking for Syslog ID 430003, but it turns out the logs were under 430002.

Why wouldn’t packet tracer show that this would be blocked by Snort? Besides attempting to access the actual IP address and service I’m trying to block, which seems risky, how else can one confirm that the rules they are building are effective if packet tracer doesn’t provide accurate results?

Thanks again to MHM and you for the quick responses!

[MHM Cisco World]

First 

Happy new year' 

Second 

You are so welcome 

Third  packet tracer will show block but you need to do it packet-tracer three times then check BLK.

Goodluck 

MHM