Unified Policy from a upgraded R77.30

[MrSaintz]

Hi all,

Has anyone tried to setup a unified rule-base after upgrading from older version like R77.30?

Questions:

1. Shared IPS - How to remove it?

2. Where can I add QoS and Desktop Policy, in a new policy package?

Performance question? I was under the assumption that after having R80.10 for both gw and smc pushing policy would be a lot faster.

I would agree if we still used old rule-base the compilation process would be closen to legacy, but after unification a significant improvement could be noticed, and I'm not getting this, anyone having the same idea?

Thank you all,

Carlos Santos

[PhoneBoy]

The Shared IPS layer issue was discussed here (with a solution): Threat Prevention policies after R77.30 to R80.10 migration. Is it correct?‌

As for enabling QoS and Desktop Policy you have to enable QoS and Policy Server respectively on at least ONE gateway object:

Once you've done that, you can add it to an existing Policy.

[Tomer_Sole]

Hi,

Regarding the performance implications:

The benefit for moving to a unified policy is the ease of management, and the support for fast daily changes and decision-making. The big advantage would be seeing all your rule set in one place, without jumping between different modules (or in R80: ordered layers). 

Performance improvements during the policy verification part have been added to R80.10 regardless of layered policy or unified policy. And those improvements depend on your specific content - some policies see a double digit improvement, others see less than that. So that shouldn't be the driver for changing the policy architecture to a unified structure. R80.10 Gateways have performance improvements during enforcement such as more accelerated object types, again regardless of policy structure.

[MrSaintz]

Hi Tomer, 

Thank you for your feedback, although I do understand your point, and agree on it, changing to unified was more of a test on the fact that, after upgrading the gateway to R80.10 we couldn't see major difference while pushing the policy, actually it looked like it took more time to push policy.

With this evidence we assumed that maybe because we were using a rather "legacy" configuration, it would prevent management to perform better.

Building a new SMC from scratch, building a new policy and pushing it's policy on a new freshly installed R80.10 GW performs very well, hence my question around "upgrade". I admit my creativity on building a new policy just for kicks was rather simple, but I enabled all possible blades but Content and DLP, the same as with upgrade.

After I managed to finish Unifying and remove shared IPS configuration, I could manage to have push policy under a minute, though it's very close to what the customer experience was prior to the upgrade, and prior means R77.30.

Also, all the time I participated on EA about R80 SMC and R80.10, there was a big attention in timing push policy, so this kind of gets in your head, and we assume Check Point is actually trying to improve on this subject.

[Dor_Marcovitch]

I know the goal for r80.10 was inatall policy in less than 1 or 2 minutes. For r77.30 good timings was below 3 minutes. And depanding on the deployment and confoguration timing can reach to 8-15+ minutes.

By the way. How did you remove the shared ips layer ? From what i have been rold.you cannot do it.

[PhoneBoy · Accepted solution]

The removal of the shared IPS Layer is discussed here: https://community.checkpoint.com/thread/5701-threat-prevention-policies-after-r7730-to-r8010-migrati... 

[Tomer_Sole]

Dor Marcovitch wrote:

I know the goal for r80.10 was inatall policy in less than 1 or 2 minutes. For r77.30 good timings was below 3 minutes. And depanding on the deployment and confoguration timing can reach to 8-15+ minutes.

By the way. How did you remove the shared ips layer ? From what i have been rold.you cannot do it.

Hi Dor, I would like to clarify - there is not a targeted max time threshold for R80.10 policy installation time. There are improvements, but they depend on the customer's configuration - choice of Management hardware, spreading of objects in each rule, amount of changes between policy installation windows. 

Removal of IPS Shared layer is possible as mentioned by Dameon.

[Tomer_Sole]

Carlos Santos wrote:

Also, all the time I participated on EA about R80 SMC and R80.10, there was a big attention in timing push policy, so this kind of gets in your head, and we assume Check Point is actually trying to improve on this subject.

Hi Carlos,

Indeed, we take policy installation time as a target to improve in every release. It is not always easy - when you add new features, they take special handling, which contributes to longer policy installation times. And since R80.10 provides faster policy verification process, during the EA program we have instructed our engineers to track the policy installation time and measure the effectiveness of these improvements. And we will continue to improve these installation times in every release.

Would you mind if I ask you another thing?

With R80.10, changes are automatically stored on the server (no Save button), but remain "private" until a user hits the Publish button, which means they will not be collected for the next policy installation. With this in mind, we were hoping to improve the deployment throughput time - instead of "everybody save and install", you can now keep changes as "unpublished", and when the time comes, publish the specific sessions which should enter production, and then install the policy. You (or other admins) can also make changes while the policy is installing. 

With this in mind, do you find the time taken to install a policy as important as before?

[MrSaintz]

Hi Tomer,

I have to say, there is little difference, on that point in relation previous versions with respect to background policy installation.

While pushing policy, with previous versions we were already allowed some free roaming and changing of the policy.

I believe some work time improvement has been achieved with this setup I can agree on that.

However looking in perspective this was already a benefit from previous version, and the improvement in the ability to change configurations doesn't save you more time to work instead of waiting to finish push policy, and this is my single opinion, I do not know if there are more people around there sharing the same interest in seeing a significant improvement on that push policy performance.

I can enlist some options that would lower the need for a faster push policy:

- Diff policy push; Enable push policy to just push changes instead of full policy;

- Multiple push policy at same time; Allow admins to push their changes, if not conflicting with another, within the same policy package to the same gateway;

These would allow admins independent work and focusing on their agenda instead of having to wait for others.

I believe this ideas were inplace while R80/R80.10 where under development, maybe they are not priorities, or have been discarded along the way, but I believe it would decrease the need for better performance on push policy subject.

Best regards,

Carlos Santos

[PhoneBoy]

Differential policy push is still in the plans.

Not sure how it would work to push different parts of the same policy at the same time unless the changes were made in different layers.

[Tomer_Sole]

still in the works.

[MrSaintz]

Thank you  Tomer and Dameon, for the input, sorry I took so long to reply.

For the very least, if Check Point is willing to listen and create CheckMate, allowing us to talk with the experts and the Legends like PhoneBoy , we should as well be willing to finish proper feedback too, for the time and effort.

If Diff policy push is planned, then the next easy(I believe) step would be, multiple diff policy push option, if not exactly at the same time, queueing the push policy changes can make a lot of sense.

Thank you for all the feedback and help.

Carlos Santos

[Tomer_Sole]

If Diff Policy Push is expected to aggregate all publish actions since the last policy installations and push that delta at once, wouldn't that resolve the case for "multiple diff policy push"?

[MrSaintz]

Hi Tomer,

Yes, I believe it would make sense, I was talking about not yet published changes, once we allow publishing during push policy, there will be pending changes that need to wait to installed, while the previous policy changes are being installed.

These are not very common cases anyway, and even, this is not subject in my initial thread.

Pushing the delta is a very good improvement that will allow most of the customers a better experience than ever before, in my humble opinion, but when there's still room to more improvements, why not enlist them too, doesn't need to be top of the list.

Best regards,

Carlos Santos