I'm writing this post to let other Check Point customers know that their iptocountry.csv file used in GeoProtection may be corrupt, to confirm if others have experienced a similar problem today, as well as to vent 🙂
We are running R80.30 and heavily utilize the GeoProtection feature of Threat Prevention (block about 180 of the 195 countries for To/From). We utilize a whitelist policy such that if a country isn't explicitly allowed, we drop/log the packet.
This morning we were receiving complaints that uses' internet connection wasn't working. Upon inspection of our firewall logs, we noticed that 99% of traffic was being blocked due to GeoProtection. To get things up and running (as our risk tolerance leans heavily towards usability) we disabled GeoProtection prior to performing an RCA.
As every block was related to GeoProtection, I theorized that the GeoProtection update (which occurs in the morning of every day) was a possible root cause. Sure enough, upon inspection of the iptocountry.csv file located at $FWDIR/tmp/geo_location_tmp/updates/, the timestamp of the file matched the first report of a user's inability to connect to the internet.
Prior to contacting Check Point support, I pulled the file from the gateway in case they needed a copy for troubleshooting. But when I opened the file I noticed that it was much smaller than previous examinations. Indeed, the size of the file was only 22KB, whereas other times it's been closer to 7MB.
Additionally, I examined a specific log entry for a blocked session destined to one of Apple's public IP addresses, 17.x.x.x, and using Check Point's conversion method (sk94364), I confirmed that the IP was not in the .csv file and by extension not identified as belonging to any particular country.
Sidenote about GeoProtection up to R80.30; if an IP range is not included in the iptocountry.csv file (of which there are a handful, including 188.8.131.52-184.108.40.206, 220.127.116.11-18.104.22.168, and 22.214.171.124-255), SmartConsole will cosmetically identify the country as the United States but behaviorally treat the packet as belonging to an unknown country.
So if a packet has an IP whose range is not in the iptocountry.csv file, then depending on your GeoPolicy being whitelist or blacklist two different things will happen.
If your GeoPolicy is whitelist (and logically your action for 'other countries' would be to drop), then the packet would be dropped.
If your GeoPolicy is blacklist (and logically your action for 'other countries' would be to allow), then the packet would be allowed.
When I got on the phone with support, they were doing their traditional troubleshooting of break/fix by replacing the iptocountry.csv file on the gateway. However after mentioning that when attempting to download the same .csv file from Check Point's website (from this URL: https://sc1.checkpoint.com/freud/IpToCountry.csv.gz, as mentioned in this Checkmates post: https://community.checkpoint.com/t5/IPS-Anti-Virus-Anti-Bot-Anti/IPS-Geoblocking/td-p/34185), it's the same 22KB sized file that was synced to our gateway.
He reached out to his escalation team and they mentioned that other tickets were appearing for the same symptom.
So heads up Checkmates!
Fun morning 🙂
Edit regarding blacklist vs whitelist: a few months ago we had a ticket open with Check Point support regarding GeoProtection, and were told that the best practice is to implement a whitelist, despite the fact that sk112249 mentions that Blacklisting (at least Application Control as mentioned in that article) is 'by far more common'.
Update: CP support responded with this post about their RCA (https://community.checkpoint.com/t5/IPS-Anti-Virus-Anti-Bot-Anti/GeoProtection-daily-update-issue-fr...).
I also received an email on July 11 from the TAC engineer assigned to the case saying that their CFG team has confirmed the issue has been resolved in the most recent Geo Protection update file. However, the URL for which I was downloading a copy of the iptocountry.csv file (https://sc1.checkpoint.com/freud/IpToCountry.csv.gz) still only has the 22KB file, but I'm wondering if this is only the monthly update (not daily) as support wrote about in their aforementioned RCA post.