Inline layer question

[Ted_Hotchkiss]

We are beginning to implement additional features with R80.10 since upgrading a couple months back, and I am attempting to construct an Inline Layer to address a specific source (domain), destination internal server, and to the smtp service only. In the first screenshot we see the existing and partially redacted rule. Rule 46 was initially constructed to audit the wide-open 'Any' source in Rule 47, and we are creating the Inline layer with Rule 46. The native unmodified rules:

So modifying Rule 46 we have constructed the inline layer thusly:

Several questions immediately come to mind, and I cannot wrap my brain around it fully enough. In no particular order:

1. When I have the cleanup rule (46.3 above) in a different capacity other than "Any/Any/Drop(Allow)" and on "Policy Targets", I get the message about the missing cleanup rule. I'm real close to grasping the Any/Any in later questions, but the policy targets still leaves me wondering. The policy is already defined/associated with this specific cluster, but we still employ the manual method of specifying the cluster on the 'Install On' field as a safeguard. When doing so, we are alerted with the "missing cleanup rule...." message. Wondering why, and whats the impact either way?

2. I thought the point of creating the inline layer was to segment a specific traffic flow to allow/deny it accordingly. Since creating a specific src/dst/svc inline layer, why must there be a broader 'any/any' cleanup rule? A certain type of logic would indicate that after allowing a specific src/dst/svc, at some point we should deny remaining sources (Any) to the same dest and service.

3. In another thread on CheckMates, it is stated:

"The way that inline layers work is the following: When the connection matches a parent rule that its action is an inline layer, the inline layer rules get evaluated.

Every inline layer (and also every layer) has an implicit cleanup rule that is either "any any accept" or "any any drop" set in its properties under "advanced". This means that once you go inside an inline layer, you cannot go outside back to the main layer, therefore rules in the inline layer cannot block rules that reside below the parent rule that holds them. Giving an admin the permission to only edit an inline layer will not affect the main layer that holds it."

I posit #3 and equate it to a roach motel...once the packet checks in (matching the parent rule) it cannot check out (inline layer cleanup rule). It is in essence a mini-policy within the main policy. Again I cycle back to why the any/any broad cleanup rule.

#Headache

This last screenshot leaves me with no "missing cleanup rule" errors, but also brings me back to the questions above and my cyclical head-scratching....

Long post short...why is this last screenshot correct, and what impact if any is there for the 250+ rules in the rest of this policy if we leave it in this last incarnation?

Many many thanks!

‌

‌

‌

[PhoneBoy]

Every layer needs a cleanup rule by design, including the main one.

This is because it is possible to reuse layers in multiple policies, including as a "main" policy for a given gateway.

This does mean if your connection is targeted to go into an inline layer (e.g. ones that match your rule 46), that inline layer is a "roach motel."

If you have not defined a cleanup rule in a given layer, a "default" is applied, which will depend on what you've set in the specific layer in question (either accept or drop without logging).

I suppose there is a use case where if a packet doesn't match an inline layer that it should return to the main policy for further evaluation.

However, this is not done today.

[Tomer_Sole · Accepted solution]

When I have the cleanup rule (46.3 above) in a different capacity other than "Any/Any/Drop(Allow)" and on "Policy Targets", I get the message about the missing cleanup rule. I'm real close to grasping the Any/Any in later questions, but the policy targets still leaves me wondering. The policy is already defined/associated with this specific cluster, but we still employ the manual method of specifying the cluster on the 'Install On' field as a safeguard. When doing so, we are alerted with the "missing cleanup rule...." message. Wondering why, and whats the impact either way?

That is a display bug due to not using Policy Targets. Given you will only install this policy on that particular cluster and nothing else, it is safe to assume no unmatched traffic will happen.

2. I thought the point of creating the inline layer was to segment a specific traffic flow to allow/deny it accordingly. Since creating a specific src/dst/svc inline layer, why must there be a broader 'any/any' cleanup rule? A certain type of logic would indicate that after allowing a specific src/dst/svc, at some point we should deny remaining sources (Any) to the same dest and service.

If the parent rule is src:A, then each of the inline layer rules can be either with src:A or src:Any, and that would be the same result, since no other traffic gets in anyway. The last rule can be either src:A , any, any.. accept/drop, or src:Any, any, any, accept/drop and both mean the same - match on all traffic that enters the inline layer. Visually, there is a bug which will show "missing cleanup rule" on the scenario of the last rule being src:A , any, any.. accept/drop. 

I'm not sure about your other questions, can you please elaborate? Or did my answer already clear the rest of them for you?

[Ted_Hotchkiss]

I think I understand it now, definitely much better than before. Essentially what is being said here is that when a packet matches the Inline Layer (the tuple), then the subordinate rules in the layer process this packet to the eventuality of having to drop whatever remaining possible combinations at its own cleanup rule, and independent of the main policy.

Using the screenshots above, traffic not explicitly matching the src/dst/svc will proceed to the next rule in the main policy, downward through to either another rule match or the explicit/implicit cleanup rule.

Traffic that does match the tuple will be processed in the Inline Layer in accordance with the Layer rules, and must also logically end with an explicit/implicit cleanup rule within this Inline Layer, which only affects traffic initially matching the parent rule tuple, and has no effect on all other traffic.

Lastly, the "missing cleanup rule" is cosmetic only, which admittedly is a bit of relief to hear, and hopefully gets patched for future releases.

Gentlemen, I think this puts all my concerns to rest, thank you very much for the clarifications and insights.

Now armed with greater knowledge, at second glance this Inline Layer we have constructed will need to be tweaked some (it's a good thing) and broaden the parent rule to more effectively implement the desired goal of explicit access to the servers.

Many thanks again for the input!

[Tomer_Sole]

Glad we could help. Looking forward for additional feedback once your “layerify” your policy 

[Ted_Hotchkiss]

Well the best laid plans of mice and men...

Seems we have a client auth rule at the tail end of the policy, which according to sk115961 is a no-go. It's the 11th commandment, thou shalt not place Legacy objects below Inline Layers.

Our Client Auth is going nowhere any time soon, and it's not feasible at this time to move those 20-ish rules to the top of the policy to accommodate the Inline Layer. We backed out of the Inline Layer implementation and just constructed an extra rule or two. A bit of a pity, but now's not the time to reinvent the wheel.

I am a bit surprised that manual policy verifications never flagged this as an issue, only throwing the verify error during policy installation. Regardless, learned a bunch in the process, and again my hat's off to you both for the help.

Cheers,

[Tomer_Sole]

Indeed, some types of objects aren't "layerable" at the moment. For R80.10 with Client Auth action though, a solution could be switching to Access Role Objects. Do you think that this could be feasible in this case?

[Ted_Hotchkiss]

Hi Tomer,

At this time we are not touching the Client Auth rules/configuration, and it would be an uphill battle to justify either way. Our revised approach seems to be working well, and we have other areas to implement a similar layered solution.

There are plans to improve our idAM solutions which may or may not affect existing Client Auth deployments, we shall cross that bridge when it's time.

For now, we plan and scheme...

[fw-admin_The_Li]

For many layers I would rather have reject than drop as default behaviour because of timeouts. But when I set it to reject it says "missing cleanup rule". Is this intended?

[_Val_]

It is assumed that inline layer cleanup rule has either accept or drop. Are you using reject action instead?

[fw-admin_The_Li]

Yes, I set it manually to reject and then the missing cleanup rule message appears.

It makes no sense for me that accept or drop are OK for a cleanup rule but reject is not.

[_Val_]

Tomer Sole‌, could you please check if this is intentional behavior?