10-15-2021 12:09 AM
Thank you for posting question @TonyTam
Regarding the error you posted, you will have to resolve it first before you can push the configuration back to Firewall. Unfortunately there is no other way around except deleting it or renaming.
I can't really say what the best practice is, but there are only 2 options.
Either onboard new Firewall. Here is corresponding Best Practice Link: https://docs.paloaltonetworks.com/best-practices/10-1/best-practices-for-managing-firewalls-with-pan...
Or migrate existing Firewall by importing configuration to Panorama and pushing it back to Firewall. Here is corresponding Best Practice: https://docs.paloaltonetworks.com/best-practices/10-1/best-practices-for-managing-firewalls-with-pan...
In my case when we deployed Panorama we already had several Firewalls deployed in production and despite the fact there was an option to migrate Firewall to Panorama by importing configuration, I opted for onboarding it as a new Firewall then I pushed all the configuration from Device Group and Template Stack and deleted all local configuration as far as I could. What I personally did not like about importing existing configuration were 2 things:
- Local configuration was already messy and not following any convention, so I did not want to import messy configuration and turn it into Device Group/Template.
- I wanted to avoid issue you posted here that by importing I need to resolve several issue first. Also, I was afraid of merging of config and forcing of Template Values especially for critical Firewalls.
By pushing new configuration by Panorama with different naming convention than local configuration has avoided any configuration duplication. This approach has still several disadvantages. It is time consuming to clean up all local configuration and unless I select: "Force Template Values" most of the configuration is pushed but not applied unless I override it and commit it locally. At this moment I have under Panorama over 150+ Firewalls and I used the same approach regardless it is brand new device or existing one that I turned into Panorama managed. We have decided not to use Panorama for interface configuration and routing. This is what we manage locally as we would like to have more control and avoid operational mistakes by pushing something centrally that will break control plane.
If you have greenfield deployment I would leverage Panorama as much as you can. Unless you are concerned about some of the points I mentioned I do not discourage you to use import of local configuration to Panorama and pushing it back. I know many admins that use it successfully in their deployments.
Kind Regards
Pavel
