- Access exclusive content
- Connect with peers
- Share your expertise
- Find support resources
04-27-2023 10:48 PM - edited 04-28-2023 08:07 AM
This Nominated Discussion Article is based on the post "Generate cookie vs Accept Cookie" by @securehops and responded to by our Cyber Elite @TomYoung. Read on to see the discussion and solution! Check out the discussion to see all responses from Tom.
Hi All,
We currently have 2 Panoramas (virtual) managing different firewalls.. We'd like to move all firewalls to 1 pano, so we can retire the other one. What's the best/safest way to accomplish that? Is there a way to avoid having duplicate objects while migrating or would it be a cleanup effort after the fact. It's a mix of standalone firewalls and HA (active/passive) firewalls. These are all in production, so concerned about downtime.
I know there is a process to import standalone firewalls into panorama, but these firewalls are already managed by pano.
Response:
Let's talk about how to get the configurations from the old Panorama to the new one. I can think of 2 ways:
- If you have Expedition, you can use it to merge the configurations and clean up duplicates. Then you can import the configuration into the new Panorama.
- If you do not have Expedition, you can use the "load config partial mode merge" command to import the device group and templates into the new Panorama. If you have duplicate names in the Shared device group, you will get errors. If the duplicates also have the same value, you do not need to fix anything. They are already there. If they have the same name and a different value (which seems doubtful), you will need to fix it. Items with duplicate values will need to be cleaned up afterwards. Duplicate rules will need to be cleaned up afterwards. https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g000000ClbLCAS
Any time that you import configurations into Panorama as opposed to building them from scratch, you will need to do some cleanup/restructuring. Thankfully, the Move button on the bottom of Policies and Objects makes that easier.
- You do not have to move all of the config locally. You can import the device configuration (including Shared) and templates into the new Panorama using "load config partial mode merge". This would be preferred because moving all the config locally can make it difficult to move partial Network and Device configuration to Panorama.
- It can definitely be phased over 1 NGFW at a time. If you are using template variables, make sure you manually configure those after the NGFWs are moved to Panorama.
Expedition makes some things easier, but it does take time to install and learn. Unless you have a LOT of objects, I probably would not. Instead, I would do the following:
- As much as possible, I would change the object names on the old to match the new. Definitely have Automated Commit Recovery enabled before you do this. Make sure the device group and template names are different!
- Rename your zones on the old Panorama to match the new. This is tricky. After the rename, create the old zones again in the templates so that the push does not fail on the managed device. After the push is successful, delete the old zones.
- Rename your shared objects before the migration. It will be easier to standardize the names before the migration because you can just rename and not have to swap objects inside the policies. Otherwise, Expedition makes the rename/swap easier.
- When you migrate a NGFW, aim for a like-for-like configuration. Don't adjust the templates or device groups on the new Panorama until all the devices are moved.
Thanks,
Tom