Create a Post
cancel
Showing results for 
Search instead for 
Did you mean: 
Joshua_Snider
Participant

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.

9 Replies
Josh_B
Contributor

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? 

0 Kudos
Joshua_Snider
Participant

Yeah...I'll post an update when I hear from support.

0 Kudos
WR
Explorer

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. 😕

WR
Explorer

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

0 Kudos
Paul_Rutkowski
Participant

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.

PhoneBoy
Admin
Admin

There was indeed a bad Geo Protection update...a couple of them.
These should have been fixed on Friday.
0 Kudos
Josh_B
Contributor

Thanks for the update. I did re-enable it yesterday, no more issues. 

0 Kudos
TP_Master
Employee
Employee

Joshua_Snider
Participant

Thanks @TP_Master 

0 Kudos

Leaderboard

Epsum factorial non deposit quid pro quo hic escorol.

Upcoming Events

    CheckMates Events