Move firewall to new Panorama

[securehops]

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.

[JayGolf]

Hi @securehops ,

Here is a link to a similar thread answered by our CE @TomYoung . As far as duplicating objects, you can import them into their own device groups and not have them at the shared level. 

[securehops]

@JayGolf 

Thanks but I don't see a link.   

As far as the duplicates, sure can do that but then you have a device group for every firewall you bring in and then won't have a consistent security policy.  Many of the firewalls are all currently in the same device group to have a consistent policy

[TomYoung]

Hi @securehops ,

I think @JayGolf 's point was that keeping them in their own device groups avoids duplicate errors when you import the configuration into Panorama.  Before we discuss duplicates, let's talk about how to get the configurations from the old Panorama to the new one.  I can think of 2 ways:

1. 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.
2. 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.

We can discuss either option in more detail on this thread.

Thanks,

Tom

[securehops]

Hi @TomYoung 

Agree completely on @JayGolf point.  This was my original thought too but since I'll be bringing a number of firewalls, for each of them to have their own device group (policy set) decided that would not be ideal

I do have some follow up questions but wanted to provide some info on the current environment 

On the source side (panorama to be retired/fws to be imported)

1. All firewalls that we want to migrate to our main Panorama are currently being managed by the soon-to-be retired Panorama but may or may not have some local configuration
2. Multiple templates.  A majority of the firewalls are in a single template, but some are in their own templates
3. 2 device groups -  All but a pair of HA fws are part of a single device group.  The other HA pair has its own device group
4.  All objects in that Panorama are in location shared, none are device group specific
5. For internal/external traffic the zone names are internal/external (additional zones exist that don't exist on other panorama)

On the destination side (main Panorama)

1. Multiple templates.  A majority of the firewalls are in a single template, but some are in their own template
2. Multiple device groups -  Majority of the firewalls belong to a specific device group and this is the device group I'd like to bring these firewalls into
3. 98% of objects  are in location shared
4. For internal/external traffic the zone names are trust/untrust

My questions are

1. To move this over, would I have to first remove the firewalls from their current Panorama and make their entire config local (and temporarily unmanaged).  If so, how does this impact the firewalls in HA pairs?
2.  Since it's Panorama to Panorama, is it done all at one time, or can it be phased and move firewall by firewall over?

I currently do not have expedition, would you recommend using it for this scenario?

Thanks!

[TomYoung · Accepted solution]

Hi @securehops ,

Thank you for the excellent info.  Let me answer your 2 questions 1st:

1. 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.
2. 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:

1. 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!
2. 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.
3. 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.
4. 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

[TomYoung]

Well, this is interesting.  https://docs.paloaltonetworks.com/panorama/panorama-interconnect/1-0/panorama-interconnect-admin

Has anyone used Panorama Interconnect?  I wonder if @securehops could use it to pull the configs from the old Panorama to the new?  I looked through the docs and did not find anything.  Once done, you could remove the plugin.

[securehops]

@TomYoung 

Firstly, thanks for the info on this.  It's very helpful not only for me but also for the entire community.

For the address objects, not a lot, I believe its somewhere between 250 - 300.  So that sounds like no real need for Expedition.  I've never used it personally, I've only watched the youtube series on it, in the past

I have some follow up questions, based on your reply. I'm a little confused

1. 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!
   Just to confirm that I'm understanding what you mean here...are you saying if on old pano, I have an object named "Object-A" with IP of 1.1.1.1 and on new Pano, I have an object named  "Object-B" with IP 1.1.1.1,  I should rename Object-A to Object-B on the old pano first?    Also, are you saying the device group and template names on the old Pano should NOT be the same as they are on the new pano?
2. 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.
   Thanks for confirming this step.  This is exactly what I was planning to do.  
3. 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.
   Not sure I understand this one, is this different from #1 above?
4. 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.
   If on the old pano, I have 2 device groups and 4 templates,  after the migration, does this mean I'll have 2 additional device groups and 4 additional templates on the new pano?   If so, after I migrate the FWs into the new pano, can I then safely move those FWs into the one existing device groups that was already on the new pano ?    The goal here is to have all of the firewalls in our current branch office device group.  This way all the security policies/decryption/etc policies are consistent.   

I think the one area I may have some issues is with the custom URL objects.  I'm certain there will be objects there with same name but different values.  Will look to match them up prior

Edit: forgot to add that in the old panorama, no template variables are used.  So for the firewalls that belong to a single template,  the values  (such as interface IP addresses) are configured locally with an override

[TomYoung]

Hi @securehops ,

Just to confirm that I'm understanding what you mean here...are you saying if on old pano, I have an object named "Object-A" with IP of 1.1.1.1 and on new Pano, I have an object named  "Object-B" with IP 1.1.1.1,  I should rename Object-A to Object-B on the old pano first?  Yes.  If you rename them on the old Pano, all the polices will have matching objects on the new Pano.  If you wait to do it after the merge, then you have to go through every rule with Object-B and change it to Object-A.  That is, of course, if you want all the objects to be consistent.

Also, are you saying the device group and template names on the old Pano should NOT be the same as they are on the new pano?  Yes.  I would keep them separate initially so that you have a like-for-like migration.  In that way you are reducing the number of changes during the maintenance window.  The #1 goal is to move the NGFW and everything work.

Not sure I understand this one, is this different from #1 above?  Good catch.  It is not different.  I was emphasizing that Shared objects are the most important since they will be merged with Shared on the new Pano.

If on the old pano, I have 2 device groups and 4 templates,  after the migration, does this mean I'll have 2 additional device groups and 4 additional templates on the new pano?  Yes, for the purpose of a like-for-like migration.  We don't want to break anything.

If so, after I migrate the FWs into the new pano, can I then safely move those FWs into the one existing device groups that was already on the new pano?  Yes.  I would standardize device groups and templates after the move.  As you know, this will take a lot of work to ensure the configs stay the same.

The goal here is to have all of the firewalls in our current branch office device group.  This way all the security policies/decryption/etc policies are consistent.  Exactly.  You could also consider moving templates also so that you can change something once for all devices.  I had to install Panorama in my company after I had a few NGFWs setup.  It took some time to import the configurations and move things around.  It's done now, and very easy to make changes.

Thanks,

Tom

[securehops]

Thanks @TomYoung 

Appreciate it.   If I take care of all the shared objects up front, to make sure they match on old and new panorama , do I still do a partial import or can I just do a full import at that point, since they'll be going into their own DG?

I read through the link you posted about the partial import, but it's not fully clear in my brain how I'd do that.   I'm also a little worried about the HA firewalls that need to be added to the new Pano, since even though they are managed by the old Panorama, all of their HA settings are currently locally configured.   When I import those FWs into my panorama, I think that config will come too and potentially break

I eventually will want to make use of template variables and have fewer templates.  Create some templates for common settings and use template stacks but that can be done as a different phase.   For now, I'm okay with having multiple templates, I'm more bothered by multiple device groups.  It's easy to clone rules from 1 DG to another, but it's extra effort 🙂

[TomYoung]

Hi @securehops ,

You will not import the NGFW configuration into Panorama at all.  You export and import the old Pano configuration onto the new Pano.  Do not load it.  Reference that file in the "load config partial" command.  Basically, you will copy just the device group or template configuration from the old to the new.  You can use the API Browser to confirm the XPaths (XML Paths).  All the local settings will stay local.  We can do a phone call or screen share if needed to further explain.

Don't forget you can use the Move button on the bottom of Policies to move rules.

Thanks,

Tom

[securehops]

Thanks @TomYoung , I totally missed that part.  So really, by importing the Pano config, it very low risk, since once it's added, then I can just add the NGFW serial number to the new panorama, change IP on NGFW to point to new Pano, add to the template/dg and push.  Since it's one-for-one, like you've mentioned, should just work fine.   I guess the only consideration is once I start the process, I should move the NGFW's over relatively quickly, otherwise I'll have to manually keep them up to date.

I appreciate the offer for screen share call, might take you up on that.  In the meantime, I will work on renaming zones, renaming/cleaning up shared objects on old Pano and add any objects that don't exist to new pano

Should it matter that old Pano is 9.1 and new Pano is 10.1?

[TomYoung]

Hi @securehops ,

Yes!  That's it.

You don't have to add new objects to the new Pano.  The "load config partial" will do that.

I would upgrade your old Pano and NGFWs to 10.1 so that the config is exactly the same.  Technically, Pano can manage older versions but sometimes there are errors.  Trying to make everything like-for-like reduces errors.

Thanks,

Tom

[securehops]

Thank you very much, @TomYoung 

New pano is 10.1 (panorama mode) with a mix of 10.1.x and 9.1.x NGFWs (upgrade planned for this year).  Old pano is 9.1.x (legacy mode), managing all 9.1.x NGFWs.  I think at minimum, I'll try to get that Pano to 10.1 panorama mode first, if possible.  I know that location is doesn't have much storage capacity left.  

[securehops]

Hi @TomYoung ,

Finally ready to test importing the old panorama config into our main panorama but can't seem to figure out how to import only the device group/template configuration.  Any pointers?