cancel
Showing results for 
Search instead for 
Did you mean: 
Post a Question
Employee
Employee

How do I create an Access Policy for Pre-R80 GWs?

Jump to solution


Since unified polices are not supported on pre-R80 GWs, can you provide best practices for creating pre-R80 gateway policy packages?

1 Solution

Accepted Solutions

Re: How do I create an Access Policy for Pre-R80 GWs?

Jump to solution

In addition to Layers in R80 , I would like to clarify the limitations with layers for pre-R80 policies:

- An Access Control Policy can have up to 2 ordered layers: the first one must be with the Firewall layer, and the second one (if exists) must be with the Applications layer.

access-layers.png

- Layer editor: Under "advanced", the "Implicit Cleanup Rule" must be Drop for the first layer, and Accept for the second layer.

implicit-cleanup.png

- Setting an inline layer to a rule is not possible.

inline.png

Failing to do any of the above will result in policy installation failure.

The best practices for organizing your current rulebase/s can vary. Many experts recommend to prioritize rule ordering by security first, then performance, then ease of maintenance.

There is also the topic of policy per gateway vs. using the Install On column. The best answer here will probably be that if you have gateways with very high overlap of the policy (over 90%), perhaps it's better to use the same policy and select specific gateways in Install On in the rules that vary, instead of copy+paste your rules between them. Hopefully with the new inline layers in R80.10 Gateways we could have better practices here.

One thing that I'd like to add to the recommendations, especially with R80 is to use section titles. Section titles are not sent to the Gateway-side, and are a pure security management feature. In the new R80 SmartConsole they help with navigating between large rulebases - see What are some of the tips and tricks for jumping between rules in the rulebase? . Unlike previous releases, the GUI does not load all the rules from the server in advance, but it uses pages of rules and sections. Therefore, scrolling the rulebase could trigger a round-trip to the Management server. You may find using the section navigation more handy. Custom section titles are now available for all Access Control layers as well as NAT.

Lastly, the R80 log server has stronger back-end, and is capable to handling larger traffic. Unless you use the log server in non-indexing-mode due to limited hardware, it is recommended to set the "track" option to "log" at least in most of the drop rules, if not in more rules.

2 Replies
Employee
Employee

Re: How do I create an Access Policy for Pre-R80 GWs?

Jump to solution

Finding more and answering my own question. Reading up on Ordered Layers now. Layers in R80

Re: How do I create an Access Policy for Pre-R80 GWs?

Jump to solution

In addition to Layers in R80 , I would like to clarify the limitations with layers for pre-R80 policies:

- An Access Control Policy can have up to 2 ordered layers: the first one must be with the Firewall layer, and the second one (if exists) must be with the Applications layer.

access-layers.png

- Layer editor: Under "advanced", the "Implicit Cleanup Rule" must be Drop for the first layer, and Accept for the second layer.

implicit-cleanup.png

- Setting an inline layer to a rule is not possible.

inline.png

Failing to do any of the above will result in policy installation failure.

The best practices for organizing your current rulebase/s can vary. Many experts recommend to prioritize rule ordering by security first, then performance, then ease of maintenance.

There is also the topic of policy per gateway vs. using the Install On column. The best answer here will probably be that if you have gateways with very high overlap of the policy (over 90%), perhaps it's better to use the same policy and select specific gateways in Install On in the rules that vary, instead of copy+paste your rules between them. Hopefully with the new inline layers in R80.10 Gateways we could have better practices here.

One thing that I'd like to add to the recommendations, especially with R80 is to use section titles. Section titles are not sent to the Gateway-side, and are a pure security management feature. In the new R80 SmartConsole they help with navigating between large rulebases - see What are some of the tips and tricks for jumping between rules in the rulebase? . Unlike previous releases, the GUI does not load all the rules from the server in advance, but it uses pages of rules and sections. Therefore, scrolling the rulebase could trigger a round-trip to the Management server. You may find using the section navigation more handy. Custom section titles are now available for all Access Control layers as well as NAT.

Lastly, the R80 log server has stronger back-end, and is capable to handling larger traffic. Unless you use the log server in non-indexing-mode due to limited hardware, it is recommended to set the "track" option to "log" at least in most of the drop rules, if not in more rules.