Create a Post
cancel
Showing results for 
Search instead for 
Did you mean: 
Dawei_Ye
Collaborator
Jump to solution

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

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

0 Kudos
1 Solution

Accepted Solutions
Ofer_Barzvi
Employee
Employee

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.

View solution in original post

22 Replies
PhoneBoy
Admin
Admin

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.

0 Kudos
Dawei_Ye
Collaborator

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.

0 Kudos
PhoneBoy
Admin
Admin

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. 

0 Kudos
14KME
Participant

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).

0 Kudos
Dawei_Ye
Collaborator

Sorry I did a mistake .

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

0 Kudos
Jason_Dance
Collaborator

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
Admin
Admin

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.

0 Kudos
Dawei_Ye
Collaborator

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?

0 Kudos
PhoneBoy
Admin
Admin

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.

0 Kudos
Dawei_Ye
Collaborator

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.

0 Kudos
PhoneBoy
Admin
Admin

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.

0 Kudos
Hugo_vd_Kooij
Advisor

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.

<< We make miracles happen while you wait. The impossible jobs take just a wee bit longer. >>
0 Kudos
Dawei_Ye
Collaborator

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.

0 Kudos
Dawei_Ye
Collaborator

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.

0 Kudos
Joachim_Zint
Participant

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.

0 Kudos
Dawei_Ye
Collaborator

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

I have correct manually the packages for about 3 days .

0 Kudos
Anthony_Kwang
Contributor

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

0 Kudos
PhoneBoy
Admin
Admin

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

0 Kudos
Anthony_Kwang
Contributor

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.

0 Kudos
Hugo_vd_Kooij
Advisor

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.

<< We make miracles happen while you wait. The impossible jobs take just a wee bit longer. >>
0 Kudos
Ofer_Barzvi
Employee
Employee

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
Contributor

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

0 Kudos

Leaderboard

Epsum factorial non deposit quid pro quo hic escorol.

Upcoming Events

    CheckMates Events