topic Re: Upgrade from R77.20 to R80.10,and failed to verify policy. in Firewall and Security Management

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

Dawei_Ye — Mon, 11 Sep 2017 05:18:45 GMT

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

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

PhoneBoy — Mon, 11 Sep 2017 06:01:31 GMT

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.

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

Dawei_Ye — Mon, 11 Sep 2017 06:37:44 GMT

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.

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

Dawei_Ye — Mon, 11 Sep 2017 06:39:12 GMT

Sorry I did a mistake .

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

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

Jason_Dance — Mon, 11 Sep 2017 16:50:20 GMT

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=&solutionid=sk110267

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

PhoneBoy — Mon, 11 Sep 2017 17:02:08 GMT

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.

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

PhoneBoy — Tue, 12 Sep 2017 06:27:58 GMT

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.

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

Dawei_Ye — Tue, 12 Sep 2017 07:03:38 GMT

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?

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

Dawei_Ye — Tue, 12 Sep 2017 07:05:35 GMT

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.

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

Hugo_vd_Kooij — Tue, 12 Sep 2017 07:09:20 GMT

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.

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

PhoneBoy — Tue, 12 Sep 2017 07:20:40 GMT

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.

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

Dawei_Ye — Tue, 12 Sep 2017 07:35:29 GMT

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.

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

Dawei_Ye — Tue, 12 Sep 2017 07:37:00 GMT

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.

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

PhoneBoy — Tue, 12 Sep 2017 14:39:58 GMT

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.

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

14KME — Fri, 15 Sep 2017 04:20:31 GMT

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

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

Joachim_Zint — Fri, 15 Sep 2017 08:49:25 GMT

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.

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

Dawei_Ye — Wed, 20 Sep 2017 05:06:41 GMT

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

I have correct manually the packages for about 3 days .

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

Anthony_Kwang — Sun, 24 Sep 2017 14:57:15 GMT

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

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

PhoneBoy — Sun, 24 Sep 2017 15:57:10 GMT

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

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

Hugo_vd_Kooij — Mon, 25 Sep 2017 07:21:05 GMT

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.