in line layer without cleanup

[Maarten_Sjouw]

Ok, here is my understanding of inline layers and I really doubt in the mean time if this is correct.

I have a number of /29 networks that are part of a /24 and all need access to some specified services.

Each of these /29's has it's own specific access in-line layer with in and outbound cleanup rules.

Now I added a access rule with in-line layer to allow the centralized services of which a part is based on URLs and part on specific IP's.

Now my assumption was, that when you do NOT add a cleanup rule in the /24 in-line layer, the matching will continue thru the rest of the rulebase, thus hitting the specific rules for the /29. Today someone told me that traffic was allowed that should not be allowed, all I can think of is that the message on the /24 in-line layer that says:

"Missing Cleanup-rule - Unmatched traffic will be accepted and not logged"

So the main question here is, is this really true?

[Peter_Lyndley]

Hi Maarten,

If it my understanding that if you match the parent rule - say rule 2, then you will never get beyond the rule checking in the in-line layer below rule 2.

I.e rule 3 and below will never be checked if rule2 parent was matched

The Inline Layer has a parent rule (Rule 2 in the example), and sub rules (Rules 2.1 and 2.2). The Action of the parent rule is the name of the Inline Layer.

If the packet does not match the parent rule of the Inline Layer, the matching continues to the next rule of the Ordered Layer (Rule 3).

If a packet matches the parent rule of the Inline Layer (Rule 2), the Firewall checks it against the sub rules:

• If the packet matches a sub rule in the Inline Layer (Rule 2.1), no more rule matching is done.
• If none of the higher rules in the Ordered Layer match the packet, the explicit Cleanup Rule is applied (Rule 2.2). If this rule is missing, the Implicit Cleanup Rule is applied. No more rule matching is done.

Important - Always add an explicit Cleanup Rule at the end of each Inline Layer, and make sure that its Action is the same as the Actionof the Implicit Cleanup Rule.

Does that answer the question?

thanks

Peter

[Timothy_Hall]

Once a match occurs on the parent rule (rule 6 let's say) and evaluation descends into the sub-rules beneath that parent (6.1-6.X), a match with action will happen in those sub-rules one way or the other and evaluation will not continue past that matched parent's sub-rules.  Each layer or set of sub-rules has its own implicit cleanup rule if you don't create one yourself that will be matched.

Once evaluation descends into a set of sub-rules there is no circumstance where evaluation comes back out of the sub-rules and continues past the matched parent rule (i.e. rule 7+).  However once evaluating in a set of sub-rules it is possible to branch into yet another layer with its own set of sub-rules (i.e. rules 6.2.X) but one way or the other a match with action will happen at some point somewhere under 6.X(.X) and evaluation is complete.

[Maarten_Sjouw]

So as usual assumption is the mother of all mess ups. (to use the nice word)
Which means I will have to create a sublayer in each of the /29 layers.
**bleep**.

[Maik]

😕 can be quite annoying if you have lots of layers.

Still, the managament API could save you lots of time in this case

Use the "add access-rule" statement with the "position bottom" argument. the rule is the same for all layers, so you would just need to parse in all the layers via a csv and the batch option.

"show access-layers" should give you the list that you need to specify within the csv 🙂

Hope it helps

[Maarten_Sjouw]

Understand the trick however, I'm not that clever with the PAI and have run into a real snag there as well with R80.30, it just does not accept the -s id.txt flag when using mgmt_cli anymore.
But again that is another issue all together.

[Maik]

Did you redirect the output of the "mgmt_cli login" statement to the correct file name?

If yes and this is a real issue with R80.30, meaning bug related, you can still do it the way that I described.

Once you make an API call, like "add access-rule", and do not specify a session the "mgmt_cli" command will ask you to log in.

As the described way is just one execution of the api its fine like that and also works (you just call it once, with all the required information, meaning the layer names, within a csv).

[Maarten_Sjouw]

Script that was running fine on R80.10 just does not want to work on R80.30
Only when using the -r true flag it works, however that contains these steps:
login, execute the script step, pulish, logout
For some quick steps no problem but the wait time per line of script is way to much to be useful.

[PhoneBoy]

Did you start a separate thread on the mgmt_cli command not working as it did in R80.10?

[Maarten_Sjouw]

Nope, did not have the time to do so.

[Amiad_Stern]

Hi @Maarten_Sjouw  , my name is Amiad Stern and I'm the team leader of the Management APIs.

I would like to understand what worked on R80.10 which doesn't work on R80.30.

Can you please share your script, my mail is amiads@checkpoint.com.

Regards,

Amiad.

[Maarten_Sjouw]

Amiad,
Tomorrow morning back in the office I will send it to you.
Simply put it comes down to the Authentication part where after you login with "> id.txt" and on the next line you end with the "-s id.txt" it just comes back with an error, sorry cannot give you the error, but when you check with your colleague A. Chuklov, he has a copy of my MDS running.

I knew I posted it here as well, have a look in this post

[Maarten_Sjouw]

Last weekend we resolved a lot of problems that were still pending a SR that we had open for validation errors. It seems this also resolved the problems I had with the scripts as the same script is now running again.