- CheckMates
- :
- Products
- :
- Quantum
- :
- Threat Prevention
- :
- Re: GeoProtection daily update problem today
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Mute
- Printer Friendly Page
Are you a member of CheckMates?
×- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
GeoProtection daily update problem today
Hello,
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 35.194.149.96-35.195.255.255, 35.240.238.112-35.241.51.173, and 93.184.215.212-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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Yes, what "fun" this morning. We had the same issue, were pretty much all inbound traffic started to be blocked by GeoProtection. I changed the activation mode to monitor only and the issue went away.
Curious if anyone from Check Point can chime in and let us know what happen?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Yeah...I'll post an update when I hear from support.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Our file got pushed around 2pm Central yesterday. We were told about 30 mins ago they still don't have a solution or ETR. I hope they have a fix soon, but just trying to give you realistic expectations as this has been a known issue for a lot longer than just this morning. 😕
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
And, now I notice this post was indeed from yesterday. I guess I missed it yesterday when looking to see if anyone else was having the problem or just us.
Not that it help any of us get a resolution any quicker, lol
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thanks for posting this. I encountered the same issue this morning. Lucky for me it only affected my Stage environment and not Production. After comparing the IpToCountry files on the primary and secondary there was a significant difference in size. I was able to grab a copy from a working gateway and overwrite the bad file, pushed policy and all is now working. I did contact Diamond support and they were going to take the issue up chain to get it fixed quickly.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
These should have been fixed on Friday.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thanks for the update. I did re-enable it yesterday, no more issues.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
I've just shared our RCA in this post: https://community.checkpoint.com/t5/IPS-Anti-Virus-Anti-Bot-Anti/GeoProtection-daily-update-issue-fr...
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thanks @TP_Master
