Upgrade from R77.20 to R80.10,and failed to verify policy.

[Dawei_Ye]

Have you guys meet this  situation?

The policy packages could install successfully.

But when I verify policies after upgrading to R80.10 ,I get a failure errors.

There are so many hide policy in R80.10.It could be about more than one thousands policies to be reported hide another policy.

Are there any methods to solve the problem?

Thanks&Regards,

Dawei Ye

[PhoneBoy]

I do know the rule validation logic changed somewhat in R80.

Can you confirm this EXACT policy installed successfully with no errors prior to upgrading to R80.10?

Can you also confirm this policy installed successfully in R80.10 and did you see errors in this case? 

It would be helpful if you could post the exact error messages you saw.

A screenshot of a couple of the rules in question might also be helpful.

[Dawei_Ye]

Hello Dameon,

this is the errors from two versions.It's from a same package.

I can't install policy in R80.10 due to the errors above.

and this is rules according to the first error.

the source and destination is the same.and only one service port hide.

[PhoneBoy]

To me, at least, this shouldn't trigger a verification failure.

It might be worth a TAC case.

That said, it looks like there is some opportunity for optimization, either using an inline layer and/or consolidating rules.

I also agree with https://community.checkpoint.com/people/jdanc6ca94357-c3d4-325b-9d5c-a8a71c5d2e9c‌ that it's probably a good idea to look through the R80.x Upgrade Verification service to make sure there are no other issues. 

[14KME]

For me it looks like, rule 119 hides rule 200 - because for the same ip-ranges (for source and target) the SAME port-range is again - even if the names are different.

tcp_31000-310100 in rule 119

and

tcp31001to31010 in rule 200

And with the same name of the port for the "Bionet-Setup".

Delete this port range in rule 200 rule (because this port-range seems to be a subset of the port-range in rule 119) and verifiy again. Let us know the result.

P.S.: Normally by defining a port-range (or single ports) it will be checked that the same range will not exists before, but it maybe that what was defined here was changed later (or because the range of rule 200 is a subset of the range in rule 119).

[Dawei_Ye]

Sorry I did a mistake .

the policy can only install in R77.20.And failed in R80.10.

[Jason_Dance]

Hi Dawei.

By chance did you use the R80 Upgrade Verification service to see if there would be any issues with porting your config into R80.x?  If not, you might want to consider it because there are other hidden items that you might not know about.

https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solut...

[PhoneBoy]

Turns out rule matching logic isn't run as part of the Pre-Upgrade Verifier. 

Further, I'm told the reason these rules validated in R77.20 at all is due to bugs that were fixed in R77.30 and R80.10.

In other words, this is working as designed.

[Dawei_Ye]

oh……

I found it could be a bug yet.

even the exactly the same rule could install in R77.20.

And Dameon, could you offer me some docs about the rule matching logic changing in R80.10?

[PhoneBoy]

The actual logic should be the same, what's improved is the efficiency of validating that logic.

Two (or more) rules with the same source, destination, and service are not allowed and should cause a validation error.

The fact it did not do this in R77.20 was a defect corrected in R77.30 and R80.10.

Which explains why you are seeing those errors after upgrading to R80.10.

[Dawei_Ye]

So there is no any way to correct the errors ?

I can just correct the validation error by hands?

anyway,Demeon, thanks for your help.

[PhoneBoy]

As far as I know there is no automated way to correct the issue.

They will need to be modified by hand.

Personally, I would take the opportunity to cleanup the policy.

[Hugo_vd_Kooij]

Which pretty much seems to support the idea of gettings things stable in R77.30 first before you considere migrating to higher versions.

You would have caught the issues in that stage.

[Dawei_Ye]

Hi Hugo,

woo……but for now ,if I upgrade to R77.30 first,I would still catch up with this issue.

I'd prefer to correct it in R80.10 directly.

[Dawei_Ye]

Jason,

I ran some times in R77.20 with Pre-Upgrade Verifier(did R80 Upgrade Verification service means this? ).

It only some warning about non-English characters.

[Joachim_Zint]

From my prospective the upgrade verifier didn´t solve the issue. it is "just" a engine improvement of the rule verifier.

There is no automatic way to solve it as far as I know. Just correct manually and use the opportunity to clean-up.

This is the way we did it too.

Honestly this should been announced in the upgrade documents to be aware of and plan time for it.

Depends on the size of your Management area.

[Dawei_Ye]

Yes.It should be announced in docs or some kind of SKs.

I have correct manually the packages for about 3 days .

[Anthony_Kwang]

Faced similar but this time MDM is running R77.30 Gaia. Is there any other possible way except manually fix the issue?

[PhoneBoy]

If you have this sort of issue (specifically "rule hiding" issues) the only way to fix them is manually. 

[Anthony_Kwang]

Found out that R77.30 Gaia which does not include JHF faced issue with verifying the policy. Once jumbo hotfix installed, faced a lot of hiding rules even before moving to R80.10.

Sadly need to fix it manually which may takes days.

[Hugo_vd_Kooij]

Dawei,

Have you considered that the amount of hidden rules might be an indication of making the policy too specific?

I tend to go to the situation where you need less rules and don't be go with rules like:

Src: Server-A, Dst: Server-B, Service: Port-C

Specifically with R80.10 I would considere to scratch such a polciy and rebuild your policy from the ground up.

Layered approach as a starting point. and try to keep away from micro management. Most certainly if you have to do it by hand.

Let IPS and such take care of part of the management.

I would like to see examples of how you can automate this with the API in a large network. It may still rresult in micro management but don't do this by hand.

Having worked with Telco solutions where no-one even actually configures every device by hand to define a Path from A to B for a service has shown me that we have a long way to go befor we see this in computer networks for most companies.

[Ofer_Barzvi · Accepted solution]

I would like to update that sk120714 was created about the changes done in R77.30 and R80.10 regarding the "Rule Hiding Rule" logic that require a manual fix of of the rules mentioned in the verification error message.

This change will be documented also in the Behavior Change section of the CP_R80.10_ReleaseNotes.pdf document .

Thank you for your meaningful feedback and comments.

[Anthony_Kwang]

This behaviour also applicable to R77.30 without Jumbo hotfix.