Verification succeeds for two same sequential rules

[Bob_Zimmerman]

At a guess, that seems like something the zone might cause. Zones are complicated to resolve to specific addresses, so I wouldn't be surprised if the verification process treats them as not matching anything, or simply skips rules which use them.

[Bob_Zimmerman]

At a guess, that seems like something the zone might cause. Zones are complicated to resolve to specific addresses, so I wouldn't be surprised if the verification process treats them as not matching anything, or simply skips rules which use them.

[PhoneBoy · Accepted solution]

Actually, this is expected behavior from R80.40.
See: https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solut...

[PhoneBoy · Accepted solution]

Actually, this is expected behavior from R80.40.
See: https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solut...

[Bob_Zimmerman]

Wow. That's good to know. I have a few policies in my managements which I don't want anybody pushing (one with QoS, and a few are migrations in progress), so I intentionally break them with overlapping rules at the end. I'll have to confirm they have different actions. They might just be two drop rules in some.

[Bob_Zimmerman]

Wow. That's good to know. I have a few policies in my managements which I don't want anybody pushing (one with QoS, and a few are migrations in progress), so I intentionally break them with overlapping rules at the end. I'll have to confirm they have different actions. They might just be two drop rules in some.

[LaRockas]

Hi PhoneBoy ,

The feature with the overlapping rules and the verification was very useful for large environments with many may rules . It was helping to housekeep the rules . Also it was an extra for our environment when we migrate from Cisco ASA , to help us reduce the rules . I understand the need for others to have overlapping rules , but it would be better to be able to change it with some change to the GUI , and not all the procedure that the SK161574 (Advanced Technical Level)  describes .

[LaRockas]

Hi PhoneBoy ,

The feature with the overlapping rules and the verification was very useful for large environments with many may rules . It was helping to housekeep the rules . Also it was an extra for our environment when we migrate from Cisco ASA , to help us reduce the rules . I understand the need for others to have overlapping rules , but it would be better to be able to change it with some change to the GUI , and not all the procedure that the SK161574 (Advanced Technical Level)  describes .

[PhoneBoy]

I believe the primary reason this was done was to reduce the overall policy compilation/installation time, also an issue in environments with many, many rules.
I would expect this process to take more time if this check is re-enabled.
Moving the setting to the UI would have to be addressed as an RFE.

[PhoneBoy]

I believe the primary reason this was done was to reduce the overall policy compilation/installation time, also an issue in environments with many, many rules.
I would expect this process to take more time if this check is re-enabled.
Moving the setting to the UI would have to be addressed as an RFE.

[abihsot__]

I feel your frustration. I was thinking the same and policy verification for hide rules is very useful to prevent rulebase from growing unnecessary. In my opinion it is a shady way of speeding up policy installation time.

[abihsot__]

I feel your frustration. I was thinking the same and policy verification for hide rules is very useful to prevent rulebase from growing unnecessary. In my opinion it is a shady way of speeding up policy installation time.