topic Re: Panorama shared object rename bug? in General Topics

Panorama shared object rename bug?

mb_equate — Mon, 07 Sep 2020 08:39:20 GMT

Panorama 9.1.4. I'm sure this is a bug...

When a shared and device-group specific object with the same name exist, renaming the shared object updates references in the child device-group resulting in those objects (policies, profiles, address-groups, whatever) inheriting the shared object value instead of the DG-specific one. This should not happen - only references to the shared object should change.

Example:
Shared object: foo (1.1.1.1)
DG1 object: foo (2.2.2.2)

DG1 object: bar (3.3.3.3)
DG1 rule: foo (2.2.2.2) -> bar (3.3.3.3)

Renaming shared object "foo" to "foo-a" will result in the following:

DG1 rule: foo-a (1.1.1.1) -> bar (3.3.3.3)

If you rename the shared object to something else that exists in a child DG e.g. "bar":

DG1 rule: bar (3.3.3.3) -> bar (3.3.3.3)

Same applies to other object references - custom URL cats in URLF profiles, addresses in groups, profiles in profile groups etc.

The reason this should not happen is that any device-group specific object, if overriding a shared object, is there for a reason. No edits to the shared object should modify the child references IF an object with the same name exists in the child group.

Re: Panorama shared object rename bug?

kiwi — Thu, 10 Sep 2020 10:54:35 GMT

Hi @mb_equate ,

I haven't had the opportunity to test it myself but it sounds indeed buggy.

Have you reported this to TAC to have this confirmed ?

Cheers,

-Kiwi.

Re: Panorama shared object rename bug?

mb_equate — Thu, 10 Sep 2020 23:34:30 GMT

TAC just pointed me to an article on how to override an ancestor object value in a child DG so I've asked them to replicate 🙂

It's a valid use case especially when importing multiple devices and those with objects in a vsys - for a customer with lots of firewalls you're bound to run into this issue.

Assuming you're in NZ, say hi to Mum for me!