About fw_light_verify

[todd]

Hi,

Has anyone encountered this situation: even with fw_light_verify=true, the policy still conflicts and installation fails?

My customer had this problem before. Sometimes I can reproduce this situation in the lab environment, and sometimes I can't.

Is there any fw_light_verify usage limitation ?

Thanks,

[PhoneBoy · Accepted solution]

fw_light_verify goes back to the earliest days of the product.
We do not recommend using fw_light_verify unless we explicitly recommended it to you (e.g. through a TAC case).
Not even sure it works with the current policy construct.

What are the exact error(s) you're seeing?
Also, please include version/JHF information.

[Gennady]

Hi!

As far as I remember the feature "fw_light_verify" was not designed to prevent "policy still conflicts and installation fails". It aims to optimize verification process and avoid FWM to get out_of_memory (4GB limit). The way to achieve this is to avoid recursive object-group verification and overall decrease object-related checks. 

If you have conflicts, then the policy should be checked to resolve it. As PhoneBoy mentioned, it is better to investigate the errors rather than try fw_light_verify.

[todd]

Thank you for your information. Customer is running R81.10 JHF 109( will upgrade soon).

The customer is conducting a disaster recovery drill and needs to insert some temporary policies into the existing policy set.

These temporary policies caused policy conflicts during installation. Therefore, we are using "fw_light_verify" to skip the regular policy check.

two conflicting policies can be created by the same the source address, destination address, and service object are the same.
One policy allows access, and the other denies access.
Sometimes "fw_light_verify=true" works, and sometimes it doesn't.

I would inform the customer that in this case, "fw_light_verify" is not a good option.

Thanks,

Todd

[Gennady]

Hi!

I would attribute "Sometimes "fw_light_verify=true" works, and sometimes it doesn't." to a possibility in which fw_light_verify "works" for rules with address-ranges and group (groups with inserted groups). And the same doesn't work for firewall rules with just objects without groups or ranges.

It is definitely better to resolve the conflicts rather than rely on fw_light_verify.