Create a Post
cancel
Showing results for 
Search instead for 
Did you mean: 
Jonathan
Collaborator
Jump to solution

Geolocation in access rules

Hi,

We're on R81.10 and planning on migrating our old Geolocation policy, under the IPS, to the new version under the access rules.

I have a question regarding how to implement exceptions.

1. The block rule is with destination "any" and in the beginning of the policy. In order to bypass the block rule I need to put the allow rule above it, but since the destination is "any", it will actually bypass the entire policy for these IPs.

How do I make the policy bypass these IPs only in the context of the geopolicy rule?

2. First of all, I guess there's no way around of creating objects for every IP we want to bypass?

 

Thanks

 

0 Kudos
1 Solution

Accepted Solutions
PhoneBoy
Admin
Admin

For this to work the way you want, I believe you will need a separate, ordered layer for your GeoProtection rules.
When ordered layers are used, an allowed packet must match an Accept rule in each layer.
This means you could create a bypass rule for specific IPs in your GeoProtection layer.
Traffic would still have to match an Aceept rule in your other, ordered layer.
Whether the GeoProtection layer is first or second, it shouldn’t matter, but having it second might be better because of how things are logged.
See also: https://community.checkpoint.com/t5/Management/Rule-set-with-track-none-but-still-logging-2/m-p/1277...

View solution in original post

0 Kudos
11 Replies
Jonathan
Collaborator

Hi G_W_Albrecht,

The SK doesn't mention bypassing issues at all.

The other article talk about inline layers which I'm not familiar with, but if I understand correctly that's exactly what I need.

Just create my geolocation rules inside an inline layer at the beginning of the policy, with the block rule as "cleanup rule".

IP address which we bypass will only bypass the geopolicy rule, but will still be processed by the rest of the rulebase?

0 Kudos
G_W_Albrecht
Legend
Legend

Please explain the bypass - usually we have accept or drop. Geo Policy is a pre-selection of possible connections, so why bypass ?

CCSE CCTE CCSM SMB Specialist
0 Kudos
Jonathan
Collaborator

OK, so say we want to block all traffic coming from a set of countries, EXCEPT from specific IPs of our clients abroad which are situated in these countries.

So I want to bypass only the geolocation block rule for these IPs.

But I  still need these IPs to be processed by the rest of the rulebase.

Hope it's clearer

0 Kudos
G_W_Albrecht
Legend
Legend

Yes, if you know the IPs you can let it pass in the rulebase.

CCSE CCTE CCSM SMB Specialist
0 Kudos
Jonathan
Collaborator

But here lies my problem/question - 

I must put all the geolocation related rules in an inline layer in order for the IPs bypass to only relate to the geolocation?

0 Kudos
G_W_Albrecht
Legend
Legend

I do not see that you must do that - just define appropriate rules to handle the IPs you know should be accepted.

CCSE CCTE CCSM SMB Specialist
0 Kudos
Jonathan
Collaborator

Surely I'm missing out on something here...

I have a huge rulebase with many rules for traffic coming from the internet to resources in our network.

Up until now, the GEO policy was handled seperately, meaning that traffic would first be checked by the GEO policy and then by the rulebase.

Now, if I put the GEO rules at the top of my access policy in the format of let's say:

Source: USA

Destination: ANY

Action: Block

and I'll bypass some specific IPs from USA, they would just bypass the ENTIRE rulebase and won't be assessed anymore. isn't that so?

I mean, I DO want them not to be blocked by the GEO rules, but I still want them to be assesed and blocked/allow by the rest of the rulebase

0 Kudos
PhoneBoy
Admin
Admin

For this to work the way you want, I believe you will need a separate, ordered layer for your GeoProtection rules.
When ordered layers are used, an allowed packet must match an Accept rule in each layer.
This means you could create a bypass rule for specific IPs in your GeoProtection layer.
Traffic would still have to match an Aceept rule in your other, ordered layer.
Whether the GeoProtection layer is first or second, it shouldn’t matter, but having it second might be better because of how things are logged.
See also: https://community.checkpoint.com/t5/Management/Rule-set-with-track-none-but-still-logging-2/m-p/1277...

0 Kudos
Jonathan
Collaborator

Hi PhoneBoy,

So just to see I understand your suggestion, I would create something like this?:

orderedlayer.JPG

This would block all countries in rule 2, but still allow certain IPs from these countries, based on rule 1. and after all that will go on to continue assessing the main rule base in the "Security" layer?

Regarding the order, you said it's better to put the "Geo" layer second. But doesn't that mean the traffic would first be assessed by the "Security" layer and traffic won't be blocked geographically? 

 

 

 

0 Kudos
PhoneBoy
Admin
Admin

Yes, you've got it.

Based on the the layers shown, traffic must hit an Accept rule in the geo, Security, and Application layers.
If a drop rule is matched in any of the layers, traffic will be blocked.
To understand how rulebase matching works, see: https://community.checkpoint.com/t5/Management/Unified-Policy-Column-based-Rule-Matching/m-p/9888#M1... 
You could put the geo layer last and it would still work the same.

0 Kudos

Leaderboard

Epsum factorial non deposit quid pro quo hic escorol.

Upcoming Events

    CheckMates Events