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

Updatable objects with geo policy

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 ?

 

20 Replies
PhoneBoy
Admin
Admin

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
Champion Champion
Champion

Also Geo Policy is hidden starting from R81 > see sk126172

Timothy_Hall
Champion
Champion

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

Gateway Performance Optimization R81.20 Course
now available at maxpowerfirewalls.com
nirmesika
Participant

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

0 Kudos
Timothy_Hall
Champion
Champion

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

geo_objects2.png

 

geo_objects1.png

Gateway Performance Optimization R81.20 Course
now available at maxpowerfirewalls.com
Danny
Champion Champion
Champion

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

0 Kudos
_Val_
Admin
Admin

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

0 Kudos
Danny
Champion Champion
Champion

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

image.png

0 Kudos
_Val_
Admin
Admin

Fair enough. Please raise it to TAC, thanks

0 Kudos
Danny
Champion Champion
Champion

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.

0 Kudos
_Val_
Admin
Admin

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

0 Kudos
_Val_
Admin
Admin

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

0 Kudos
Tomer_Sole
Mentor
Mentor

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
Participant

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 ?

0 Kudos
PhoneBoy
Admin
Admin

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
Employee
Employee

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
Explorer

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

0 Kudos
Timothy_Hall
Champion
Champion

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.

Gateway Performance Optimization R81.20 Course
now available at maxpowerfirewalls.com
0 Kudos
Evan_Gillette
Explorer

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.

0 Kudos
nirmesika
Participant

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.

Upcoming Events

    CheckMates Events