Recommendation for GeoIP Blocking for H Series devices in Nebula.

Ratsnackbar

I'm not seeing where you can implement GeoIP Blocking for H series devices within Nebula. I am assuming this is one of the many features the older Flex series has available to it in Nebula which has not yet been implemented for the H Series.

When you do implement GeoIP blocking, I suggest you do so using a Profile based methodology similar to your Application and Content filtering policies.

I would suggest allowing an admin to create a new GeoIP policy and in it's creation screen you'd have at a minimum these fields:

1. A Policy name.
2. A drop down where you can select Allow, Block or which can be left blank.
3. A grid of every country name and a checkbox to either select it or deselect it.
4. An option button to select all or deselect all.
5. Date created field which is auto filled.
6. A created by field which shows the admin name whom created the policy. (I'd suggest adding this field to the Application and Content filter policies while you are at it.)
7. A Notes field where the creator can add notes such as what the policies intended to be used with.

In the Security Policy Section I would then suggest applying these policies using the same field and general mechanism that is used to apply an App or Contend Filter policy.

If the GeoIP policy were set to Allow then all of the countries that were checked in the policy would be allowed and all of those not checked would be denied by default.

If the GeoIP Policy were set to Deny then all of the countries checked would be denied and those not checked would be allowed.

In either of the above cases the Allow/Deny option in the Security Policy rules would be grayed out and set to the policy's setting.

If the GeoIP Policy's Allow/Deny were left blank, the Allow/Deny in the Security Policy page would be selectable and a required field.

This would be a much simpler methodology than having to create dozens of rules and applying 30 countries at a time to each as is how it's done in the older Flex/Nebula solution.

Because this solution would allow the application of GeoIP filtering rules at the specific security policy rule level it also has the potential of saving space in the security policy section over the older Flex/Nebula method.

Zyxel_Melen

Hi @Ratsnackbar

H series on Nebula supports to set GeoIP as an object and applied in security policy.

Please reference these two videos for configuration it.

https://jam.dev/c/58a5ee3a-42f1-4d51-9761-26c0fcb6d40e

https://jam.dev/c/9be5fcf1-ea60-4caf-b198-187f71684584

About the input you mentioned,

If the GeoIP policy were set to Allow then all of the countries that were checked in the policy would be allowed and all of those not checked would be denied by default.

If the GeoIP Policy were set to Deny then all of the countries checked would be denied and those not checked would be allowed.

In either of the above cases the Allow/Deny option in the Security Policy rules would be grayed out and set to the policy's setting.

If the GeoIP Policy's Allow/Deny were left blank, the Allow/Deny in the Security Policy page would be selectable and a required field.

Could I clarify with you that the GeoIP policy has a higher level than the security policy? Once the GeoIP policy is enabled, whether to allow or deny, the security policy will gray out and not work?

Ratsnackbar

Hi Melen, thanks for the reply.

I figured out how to set the GeoIP policy in an H Series in Nebula soon after I posted this recommendation. Thanks for those links regardless, those will be useful to provide Jr. Admins whom are just learning.

A general rule of thumb for GeoIP blocking is to block every country where your organization does not do business or have cloud services hosted from. The cloud services part can become a bit tricky but this is still a good general rule.

To make defining GeoIP filtering policies simpler for the user I'd add a section under the Security Services screen of Nebula that allows for an admin to GeoIP Policies similar to Content Filtering policies.

For the policy itself you'd really only need a Policy Name, and a mechanism to includ a list of countries and then a field that toggles between Allowed and Blocked.

It's likely that there will be fewer countries allowed then blocked in nearly every use case. Therefor it may be best to not have an Allowed/Blocked toggle and just instruct users to add every country they would like to allow.

Then in the Security Policy, you'd want to allow the attchment of the GeoIP policy to a specific network rule in the same way that you would a Content filter.

The results being I'd need 1 x GeoIP filter and 2 x Security Policy records to block all but the countries I'd like to allow. One Security Policy for inbound and 1 for outbound each referencing the same GeoIP Policy.

(I'd suggest using Bloom Filters as the method to analyze traffic against the GeoIP rules as they are super fast if implemented properly.)

In the current method, if I wanted to block all countries but my own, I would be required to enter ~194-195 Address Objects (one for every country) and then 2 Address Groups (because you can only include 128 objects in an Object group) and then I'd need to create a minimum of 4 security Policy records. Two each for inbound and outbound traffice in the Security Policy in order to reference both of those Address Groups in a firewall rule. (2 inbound, 2 outbound)

That's over 200 objects I'd need to create vs 3 in the method I describe.

Sorry for the wall of text. I hope that helps to clarify.