Ordered Layers vs In-Line Layers

[Cypress]

Hello.  This is more of a philosophy question around the design of Check Point Security Policy.  We have Ordered Layers, where one Layer is handling basic Firewall Rules, and a separate layer is handling Application Control (and URL Filtering) rules.  This took a little getting used to as a newcomer to Check Point, but once one understand how the matching works, it's really not that difficult to manage.  We even introduced a 3rd Layer above these for Geo Policy enforcement, using updatable objects.

However, in many conversations with consultants or annual/semi-annual review with our accounts team, it was suggested to work towards collapsing into a single layer, using all In-Line layers.  This would achieve a "Unified Access Control Policy."  Is this how Check Point is building out new customers generally?

It seems like you might lose a little bit of flexibility trying to do it all with in-line layers, but it might carry the advantages of better performance, since most of the rules will not be processed for various flows, in theory with In-Line layers, a flow will only hit one section and then the rest is not touched, whereas with Ordered Layers, you have to process rules in all three layers which might add (extremely small) latency.

Is performance the biggest advantage to using a Unified policy?   Or is it more about ease of management and visualization of the policy rules?  Is it worth putting in the time and effort to configure a new policy to "get with the times" or do many customers stick with Ordered Layers?  Just curious on some opinions.

[Timothy_Hall · Accepted solution]

In my opinion, inline is more about ease of management in the long run.  When researching my last book, I prepared two different policy packages that accomplished exactly the same goals.  One was ordered (one feature per layer), and the other was inline with sub-rules.  I examined the compiled Unified Policy INSPECT code for both, and there were only minor, cosmetic differences. 

So, I doubt there is much of a rulebase lookup performance difference between inline and unified, with one big exception: the key thing to watch out for, regardless of ordered vs. inline, is ensuring that you only have the Firewall blade enabled in the top or first layer.  So, for inline the top/parent rules are Firewall blade only, and only match simple services (port numbers), then in the sub-rules (or second separate layer in the case of ordered) is where you enable APCL/URLF and call for applications and categories.  This will help SecureXL accept templating optimize the overhead of rule base lookups.  See the following thread for my explanation of this: 

https://community.checkpoint.com/t5/General-Topics/Clarification-Needed-on-fwaccel-stat/m-p/252954/h...

As long as you adhere to this recommendation, the difference in rulebase lookup performance on the gateway for ordered vs. inline seems to be negligible, at least as far as I can tell.

If you have a very large ordered policy, it was likely upgraded from an earlier release to R80+, as only the equivalent of ordered layers was possible prior to R80.  So, if that existing large ordered policy is working well and you understand it thoroughly, is there some burning, urgent need to convert it to inline?  I would personally say NO there is not, as doing so is a manual process and you will probably hit some bumps along the way.

However, if you are implementing a brand new policy package for a new firewall or site, ABSOLUTELY start from the beginning with inline.  In the long run your policy will be shorter and easier to understand.  This is also a great time to look at using Security Zones instead of big groups of networks for rule matching, and the use of "network defined by routes" for the new gateway anti-spoofing configuration.  

[Cypress]

Thanks for the detailed write up!

[the_rock · Accepted solution]

I cant speak for anyone else, but I can tell you, from my own experience in the lab and having set this up for many customers, way to go is having ORDERED layers (I attached doc I put together while back), where say on network layer you have only fw enabled, then on next one appc and urlf, and so on, depending on the need. Thing to remember is that traffic has to be ACCEPTED on every ordered layer for it to work, so its totally fine to have any any accept at the bottom of every layer, apart from default network layer.

Inline layers are totally fine as well, but again, it depends on the need, but in my personal opinion, allows for way better segmentation, specially when using designated zones.

Andy

[Cypress]

Thanks for sharing this doc

[the_rock]

No problem! Happy to show you my lab where I have this set up, not an issue. Just remember what I said about traffic having to be accepted on EVERY ordered layer, super important. As far as drops, if its dropped on first ordered (network) layer, then it wont do any further matching. I attached a video, hope it helps. Though in my case, I also enabled urlf and appc on network layer, since I did some inline layers with win11 test machine.

Andy

[the_rock]

I should probably get way better one, but you know how it is with us IT folks, we get lazy sometimes, haha. Anywho, I have very good lab where I can demonstrate this, so be free to message me any time if you have additional questions.

Andy

[PhoneBoy · Accepted solution]

Any customer that upgraded from a release prior to R80 most likely have an Application layer (in addition to the Network one).
This is because of how App Control was handled prior to R80...with a separate policy.
You also still need this configuration if you are managing App Control on a pre-R80 gateways.

From a performance perspective, I don't think it makes a difference whether you use Ordered Layers or Inline Layers.
Where it does make a difference is logging, specifically when using multiple Ordered Layers.
For the relevant discussion, see: https://community.checkpoint.com/t5/Management/Inconsistent-behavior-in-SmartConsole-Not-showing-las... 
The overall rulebase construction matters a whole lot more.

From my perspective, whether you use Ordered layers, Inline layers, or both, it's largely a horses for courses discussion.

[Bob_Zimmerman]

Ordered can be nice for delegating control to different parallel teams. For example, an incident response team can have a layer for country-based blocking and blocking specific attackers, then the firewall team can control normal firewall rules, then the web filtering team can control Application Control/URL Filtering.

In my experience, inline layers are a headache. Every deployment I've ever seen results in weird drops which the admins don't understand (once traffic is sent to an inline layer, it can't go back up, and cleanup drops get a weird message). Rules wind up in the wrong places (e.g, below a rule which sends the traffic to another layer), and when the problem is identified, the rule gets added in the right place but the incorrect rule is left because getting permission to delete a rule is so painful. Additionally, most policy analysis tools I've tried don't handle inline layers very well.

My company is in the process of flattening our inline layers across the board.

[Cypress]

Thank you for the additional input.  I am definitely leaning more towards sticking with our Ordered Layers the way we have it now after going thru this thread