Issues with Geolocation Rules

[CJ Bird]

We are experiencing some odd issues with our geolocation feature in FMC/FTD environment.  We have about 150 remote end users based in the US, metro Atlanta specifically, and an overwhelming majority of them have no issue connecting over our Citrix/VPN.  However a handful of end users, four in this case, all in Atlanta, are being blocked.  Manually applying their outside-facing ISP addresses of these four end users to the firewall rule that also included the geolocation rule corrected the issue.  We're stumped as to why only these four end users are being impacted.  We did note they use AT&T Uverse as their service provider, but so do many of the other end users who are not impacted by this issue.  All four end user's each have the same first octet of 99.x.x.x, again, like many other unaffected end users.  We're running IOS Version 7.0.4 on each of our 2110 FTD appliances as well as our FMC VM.  All geolocation files are regularly updated, and we run the most recent Snort3 rules, which are configured to manually update.  We just can't quite figure out why these four end users are being blocked.  The only thing we can relate it to is that it began after a geolocation update was pushed in late January.  The problem began immediately following that update.  Has anyone else experienced this?  Thanks in advance.

[Cisco_Virtual_Engineer]

It seems like the issue started after a geolocation update, which might have caused some changes in the geolocation database leading to these four end users being incorrectly identified based on their IP addresses.

To diagnose and troubleshoot this issue, you can follow these steps:

1. Verify the geolocation configuration: Double-check the geolocation settings in FMC, specifically the settings related to blocking or allowing traffic based on geolocation. Make sure that the United States, and more specifically, metro Atlanta, is allowed in your geolocation policy.

2. Check for geolocation database discrepancies: There might be a discrepancy in the geolocation database that's causing these four IP addresses to be incorrectly identified. You can use online geolocation lookup services to double-check the location of these IP addresses and compare it with what's being shown in FMC.

3. Review logs and events: Analyze the logs and events in FMC related to these four end users being blocked. Look for any specific indicators or reasons for the block, such as a specific rule or policy being triggered.

4. Test with different geolocation databases: If possible, try rolling back to a previous geolocation database version to see if the issue persists. If the issue is resolved, you can consider reaching out to Cisco TAC to report the problem with the latest geolocation update.

5. Check for other possible issues: Although the issue seems to be related to geolocation, it's still worth checking other possible causes, such as incorrect IP address ranges, overlapping rules, or issues with the ISP.

If the issue persists after trying these steps, it's recommended to open a case with Cisco TAC for further investigation and assistance. They can help you identify the root cause and provide a solution for the issue.

[Divya Jain]

Hi,
i would also say that for starters a quick look at unified events will let you identify whats dropping the connection - ACL, Security intelligence, Malware/file policy etc.
If it is because of geolocation update, you can probably reach out to Cisco TAC and get it checked / fixed.
 

-----------------------------------------
If you find my reply solved your question or issue, kindly click the 'Accept as Solution' button and vote it as helpful.

You can also learn more about Secure Firewall (formerly known as NGFW) through our live Ask the Experts (ATXs) session. Check out Cisco Network Security ATXs Resources [https://community.cisco.com/t5/security-knowledge-base/cisco-network-security-ask-the-experts-resources/ta-p/4416493] to view the latest schedule for upcoming sessions, as well as the useful references, e.g. online guides, FAQs.
-----------------------------------------

Regards,

Divya Jain