- CheckMates
- :
- Products
- :
- Quantum
- :
- Security Gateways
- :
- Geolocation in access rules
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Mute
- Printer Friendly Page
Are you a member of CheckMates?
×- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Tags:
- geolocation
- r81.10
Accepted Solutions
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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...
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
See sk126172: Configuring Geo Policy using Updatable Objects in R80.20 and higher
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Please explain the bypass - usually we have accept or drop. Geo Policy is a pre-selection of possible connections, so why bypass ?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Yes, if you know the IPs you can let it pass in the rulebase.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I do not see that you must do that - just define appropriate rules to handle the IPs you know should be accepted.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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...
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi PhoneBoy,
So just to see I understand your suggestion, I would create something like this?:
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?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
