Rogue shared Objects following import - Panorama 10.2.4

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Rogue shared Objects following import - Panorama 10.2.4

L1 Bithead

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. 

 

 

 

 

 

 

 

 

1 accepted solution

Accepted Solutions

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

PCSNE - CISSP

Best Effort contributor

Check out our PANCast Channel

Disclaimer : All messages are my personal ones and do not represent my company's view in any way.

View solution in original post

6 REPLIES 6

L4 Transporter

Hello Jbusby,

 

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

Thank you.

Olivier

PCSNE - CISSP

Best Effort contributor

Check out our PANCast Channel

Disclaimer : All messages are my personal ones and do not represent my company's view in any way.

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.

L1 Bithead

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.

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

PCSNE - CISSP

Best Effort contributor

Check out our PANCast Channel

Disclaimer : All messages are my personal ones and do not represent my company's view in any way.

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. 

Thank you Jbusty, glad my answer helped you 🙂

PCSNE - CISSP

Best Effort contributor

Check out our PANCast Channel

Disclaimer : All messages are my personal ones and do not represent my company's view in any way.

  • 1 accepted solution
  • 2177 Views
  • 6 replies
  • 0 Likes
  • 29 Subscriptions
Like what you see?

Show your appreciation!

Click Like if a post is helpful to you or if you just want to show your support.

Click Accept as Solution to acknowledge that the answer to your question has been provided.

The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!

These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the LIVEcommunity as a whole!

The LIVEcommunity thanks you for your participation!