Panorama Create FW Rule - Always moves

[RyanMBess]

I'm leveraging a json file to iterate through to make FW rules.
rules.txt

The first rule is the default deny rule from a zone called scientific. Thus any rule above it permits traffic from that zone to whatever is needed. The two next rules use that rule name for the automation to appropriately place those allow rules. Each time you run the playbook even if nothing changes, ansible issues a move command and thus a new commit is needed even though nothing changed.

I'm using 2.12.0 of the Ansible Palo Collection. Shouldn't ansible check that the rules are already ahead of the deny rule and do nothing?

I get what the palo module is trying to do, it's ensuring that the rule is DIRECTLY before the deny rule (in my case). Thus as it's looping through the ruleset (see txt file attached), it moves rule 1 above the deny, then iterates through the next rule in the text file and moves rule 2 directly above the deny.

Perhaps a new value could be added of "above" and then the module would check to see "Is the rule above" the Deny rule (in my case). As long as it's higher (above) in the ruleset, no move is needed. The same could be said for if you wanted to ensure a rule is lower in the ruleset and you don't care where. A value of "below" could be used.

Thoughts?

[RyanMBess]

Evening all,
Can someone please look at this request.

[shinmog]

@RyanMBess

Your playbook essentially looks like this right now:

1. create rule1 at the bottom
2. create rule2 above rule1
3. create rule3 above rule1

The location before means "directly before (this other rule)", not "somewhere before (this other rule)". Because of this, re-running the above three steps as a playbook repeatedly will always see that steps 2 and 3 will report a change since they're both jockeying to be directly before rule1.

So, I can see two solutions.

1. New enhancement to the collection, we could implement new keywords for the location. Specifically, "somewhere before" and "somewhere after". There's value to adding this and I think it should be done (as it already exists in our Terraform provider), but it likely won't get addressed until sometime next year.
2. Adapt your playbook to reference the previous rule in the stack; this should be possible using the jinja2 functions. You should be able to get RedHat to help you craft this if you get stuck.

[ai-ryanbess]

HI @shinmog
Yes you understand correctly. I thought about retaining the previous rule and using that as the place holder for where to move the next. The problem with that approach is the json file will be ever growing and the source zones and destination zones of new rules may/will be different from the previous rule. We want all rules in a specific directionality to be all together. So given the json file is just a list of rules that are managed via ansible, simply iterating through those rules and slapping them one by one on top of each other isn't going to work. What we are trying to do is for a given directionality, lets say inside zone to outside zone, we first put a default deny to deny all traffic from inside to outside. Then all permit rules in that direction would be before the default deny. We have some thoughts on how to address this via some additional code but yes, having the somewhere before or somewhere after would really help and would allow the code to check rules and not have it jockey the rules around.

Happy to work with you in any way.

[shinmog]

What I was suggesting with my "reference the previous rule in the stack" commend is this python pseudo-code:

for num, item in enumerate(list_of_json_dicts):
  if num == 0:
    position = ""
    existing_rule = ""
  elif num == len(list_of_json_dicts)-1:
    position = "bottom"
    existing_rule = ""
  else:
    position = "below"
    existing_rule = list_of_json_dicts[num-1].name

So, since the first rule doesn't have a specific position mentioned, it will just be wherever. All rules leading up to the last rule will place themselves below the previous rule, thus maintaining their linked order you want. Finally, the last rule will be at the bottom of the policy.

If the last rule in your list_of_json_dicts didn't need to be at the absolute bottom of every security rule, just at the bottom of the other n-1 rules before, then you can remove that "elif ..." section.

There is most likely a way to accomplish the above using jinja2 templating functions. While diving into what that looks like is outside the scope of the collection, it could be something RedHat would help with if you get stuck..?

[ai-ryanbess]

Yes Redhat will help. Appreciate your feedback.

[shinmog]

👍