Updatable objects with geo policy

[nirmesika]

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 ?

[PhoneBoy]

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.

[Danny]

Also Geo Policy is hidden starting from R81 > see sk126172

[Timothy_Hall]

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

[nirmesika]

can you please elaborate on "dfferent geographies in the Access Policy" ? how do we implement this ?

[Timothy_Hall]

Here are some screenshots from my book showing how to utilize Geo Updatable Objects in R80.20+:

[Danny]

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

[_Val_]

@Danny, did you actually catch any mismatch?  Just to make sure your distrust is justifiable 🙂

[Danny]

@_Val_ sure, here is one recent example: Our security gateways as well as MaxMind locate 114.119.152.204 to be in Singapore while all SmartCenters that haven't manually been updated locate it in China.

[_Val_]

Fair enough. Please raise it to TAC, thanks

[Danny]

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.

[_Val_]

Sorry to hear that. I will check internally and let you know

[_Val_]

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

[Tomer_Sole]

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.

[nirmesika]

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 ?

[PhoneBoy]

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.

[Tomer_Noy]

I wanted to share a bit more on this topic:

1. It's important to emphasize that the flags that you see on the logs are cosmetic information and do not affect the enforcement. They are calculated according to the csv (mentioned in other comments) during the log query.
2. We do understand that it's confusing to see a flag that is not updated to the latest categorization of an IP. Even more so, if that IP was blocked on a geo rule. As stated, we don't yet update the flag csv file automatically, but following the feedback in the thread, we will make sure to update it more regularly in JHFs.
3. If you are using updatable objects for geo-blocking in your policy (which is a good way to do it), then inside the log details (double click the log), you will also see the exact updatable object that was matched. This will include its name and icon. In case of a geo updatable object, that will include the country name and flag. That is the most accurate way to see which country was matched in the rule, especially since that value is attached during enforcement and not calculated later during the query.

[Evan_Gillette]

Is it possible to add an "exception" to the country objects? How do I allow an IP to connect from an otherwise blocked country?

[Timothy_Hall]

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.

[Evan_Gillette]

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.

[nirmesika]

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 !