- Products
- Learn
- Local User Groups
- Partners
- More
Firewall Uptime, Reimagined
How AIOps Simplifies Operations and Prevents Outages
Introduction to Lakera:
Securing the AI Frontier!
Check Point Named Leader
2025 Gartner® Magic Quadrant™ for Hybrid Mesh Firewall
HTTPS Inspection
Help us to understand your needs better
CheckMates Go:
SharePoint CVEs and More!
Hi,
We have an R80.30 Gateway and management, we apply a geo policy to allow only specific countries to our org.
now we transfer our mail service to 365 cloud and keep our on-perm mail relay and we want all outgoing emails to continue going through the on-prem mail relay.
the issue is geo policy does not support the updateable objects and we cant update the 365 cloud ip addresses every other day.
any solution ?
The traditional Geo Policy does not support Updatable Objects, nor is this planned.
You can use Updatable Objects for different geographies in the Access Policy, however.
And, in fact, this is the approach we recommend for implementing Geo Policy in general in R80.20+ as it permits far more flexibility than the traditional Geo Policy provides.
Also Geo Policy is hidden starting from R81 > see sk126172
Geo Policy is still supported in R81, but it will be hidden in the SmartConsole if nothing has been changed in Geo Policy from the default settings "out of the box".
can you please elaborate on "dfferent geographies in the Access Policy" ? how do we implement this ?
Here are some screenshots from my book showing how to utilize Geo Updatable Objects in R80.20+:
The issue with these objects is that you can not fully trust your log files. This is because security gateways update their GeoIP database automatically (sk126172) while security managements don't (sk120261). Checking to which region a security gateway actually resolves an IP address also is a manual process that includes some calculation and range checking and CLI command handling (sk94364).
@Danny, did you actually catch any mismatch? Just to make sure your distrust is justifiable 🙂
Fair enough. Please raise it to TAC, thanks
Done. SR closed. Reason: That's the design of the product. Security Managements don't update their GeoIP database by themself. Workaround: Manual via sk120261 as I mentioned above or via my One-liner to update IpToCountry data on Security Managements.
Sorry to hear that. I will check internally and let you know
@Danny I have spoken to the product owners. We do have dynamic update of Geo IPs on MGMT side on the road map, but the exact time frame is not clear. I hope it will be done soon.
To add to Tim's message -
The R80.20 way of updateable objects is the most recommended solution.
In order to migrate from the geo policy to this new way, simply create an ordered layer prior to your firewall layer at the access control policy, and recreate the country rules. This will basically keep the same logics as the geo policy, only with up to date IP address ranges for the countries.
Hi Tomer_Sole,
We want to allow only connections from Israel to our org and allow our org to all countries.
I have created a new access Policy layer beforce our default FW policy with these two rules attached, will these be OK ? the traffic will continue to the second access layer and will be processed according to our default policy ?
A connection must match an Accept rule in each ordered layer.
If the connection doesn't get blocked by your first rule as shown, then it hits an Accept rule and must hit an Accept rule in subsequent layers.
I wanted to share a bit more on this topic:
Is it possible to add an "exception" to the country objects? How do I allow an IP to connect from an otherwise blocked country?
There aren't really true exceptions in an Access Control policy. In that case just add a separate Accept rule for the permitted IP, somewhere above the rule using the Geo Updatable Object to block that country.
That's what I suspected. It's kind of a bummer because an exception in the geo policy meant that the IP could come from the blocked country but still had to traverse the rule base as it's laid out.
I can overcome this with layers where the the "entrance criteria" for the inline layer rule allows the exceptions to enter the layer. Below that rule is the country block rule. Then below that rule is another inline layer rule where the entrance criteria is all internet.
Using the layers like this allows me to simulate the traversing of the rule base for exceptions but it makes things a little ugly.
Thank you everyone, the issue is resolved.
the old GEO policy was changed to inactive and the new GEO policy is applied by a new ordered layer before the access control policy !
Leaderboard
Epsum factorial non deposit quid pro quo hic escorol.
User | Count |
---|---|
14 | |
11 | |
11 | |
9 | |
9 | |
7 | |
6 | |
5 | |
5 | |
5 |
Tue 07 Oct 2025 @ 10:00 AM (CEST)
Cloud Architect Series: AI-Powered API Security with CloudGuard WAFThu 09 Oct 2025 @ 10:00 AM (CEST)
CheckMates Live BeLux: Discover How to Stop Data Leaks in GenAI Tools: Live Demo You Can’t Miss!Thu 09 Oct 2025 @ 10:00 AM (CEST)
CheckMates Live BeLux: Discover How to Stop Data Leaks in GenAI Tools: Live Demo You Can’t Miss!Wed 22 Oct 2025 @ 11:00 AM (EDT)
Firewall Uptime, Reimagined: How AIOps Simplifies Operations and Prevents OutagesAbout CheckMates
Learn Check Point
Advanced Learning
YOU DESERVE THE BEST SECURITY