Rogue shared Objects following import - Panorama 10.2.4

[jbusby]

We are in the process of importing our locally managed firewalls (PA-440s) into our panorama instance. We've got to the point where were have imported all the devices and committed to panorama. We were about to push the device config bundles back to the devices but then realised some unexpected "shared objects" had been created in Panorama and subsequently modified our template values. 

Our main aim initially is to be able to managed the policies and device configuration on a per device basis from panorama, with the intention to move to shared objects and standardised policies using variables in the future . But right now all objects should be at the device group level , with one device group per site. 

As an example one of the shared objects causing trouble is called "public-gateway" with an IP address value of one of the sites. Obviously this particular value is unique to each office and should not be a shared object  and so because it's in the shared context it shows that in all device templates that it will use that same value. To explain further each site also has the public-gateway object at the device group level with it's unique IP but the shared one in the template appears to take precedence. We cannot delete the shared object because they are now "in use" in virtual router configs. Again we've not pushed the bundles back or subsequently pushed to devices, we've only committed to Panorama. 

We don't understand why any shared objects could be created during an import , multi-vsys isn't supported on our branch devices. There is this option (below) which was deselected , but actually I don't think is relevant because there aren't shared objects on the branch devices. 

Import devices' shared objects into Panorama's shared context is enabled by default

 I also verified they weren't manually created. We've also opened a ticket with PA support send the various support files and are awaiting feedback but seeing if the community had any experience of this problem, seems like a weird bug. 

Thanks for looking. 

[ozheng]

Hello Jbusby,

Can you attach a screenshot of the issue (sorry I don't visualise the behavior with the description)?

Thank you.

Olivier

[jbusby]

Hi Oliver,   Thanks .  Screenshots showing the shared object in the Branch-Office device group. Screenshot showing a child device group containing both the shared object "public-gateway" and the "public-gateway" object local to the device group with the different values. The third screenshot showing an attempt to delete the shared object which fails because it's being used in the various virtual router templates rather than device group object.

[jbusby]

I've been able to reproduce this issue. It actually has nothing to do with the initial import. When you import the device , creates a specific device group e.g. TEST-FW-01 , no shared objects are created and everything is as expected. 

However after then changing the parent device group from shared to "Branch-office" a bunch of shared objects are created. Before making this change there are no shared objects at all so I know it's this action that creates them. 

This was incorrect but I have a more concise description , the problem items are always imported to shared context in panorama but only those particular items that are referenced in the virtual router configuration of that device.

[ozheng · Accepted solution]

Hello Jbusty,

Sorry I did not see the screenshots (currently at home, my firewall is stricter than in office).

Based on your last message:
- don't use address objects for Template configuration (interface / VR...) : that creates dependencies between Device Group and Templates, and you will understand why it is not good the day you need to restore a firewall 😄
Also generally speaking, I don't think this is a best (not even a good) practice, but that's only my feedback.

- maybe you can open a case to the TAC, to check this behavior (maybe an expected behavior).

I think it may be a expected one, and you will probably not see this if you are on multi-vsys settings, as the address object will probably be in vsys1.

Olivier

[jbusby]

Thanks very much Oliver, this is the exact answer and guidance I was looking for.  We already started replacing these address objects instead specifying IP addresses / ranges and reimporting the devices. 

[ozheng]

Thank you Jbusty, glad my answer helped you 🙂