- Access exclusive content
- Connect with peers
- Share your expertise
- Find support resources
Enhanced Security Measures in Place: To ensure a safer experience, we’ve implemented additional, temporary security measures for all users.
10-14-2021 10:41 PM
I added a PA to panorama test lab with version 9.1.11 them import configuration. However I am unable to push config from panorama to PA and I found below errors which showing customized application is in use, then I need to delete many objects and policies on PA firewall to push configuration. I want to know is it a normal practice for Panorama to manage production PA in the first time? Many thanks!
Details:
. Validation Error:
. application -> Custom-IE 'Custom-IE' is already in use
. application is invalid
. Error: Profile compile error, duplicated name Block files
. Error: Profile compiler : Block files invalid type 5
. Error: Profile compiler : invalid profile name Block files
. Error: Profile compiler : Vsys section error
. Error: Profile compiler : parsing config error
. (Module: device)
. Commit failed
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
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
10-15-2021 01:12 AM
Thanks for your suggestion.
According to below KB, I found that I miss the important part "Export or push device config bundle".
Seems the most convenient method to delete all local configuration when pushing.
https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g000000CloRCAS
11-09-2021 09:17 AM
@TonyTam is correct. When you initially import a firewall configuration into Panorama, you need to "Export or push device config bundle" to remove the local configuration and replace with Panorama configuration. If you try Commit > Push to Devices you will get the "already in use" or "duplicated name" errors. You only have to do it once, and then you can manage from Panorama normally.
04-23-2024 01:25 PM
Thank you for the detailed explanations, @PavelK and @TomYoung we ran into plenty of conflicts onboarding firewalls that were already part of our infrastructure. I have found that not moving the firewall from the DG and Template it creates until the config package has been successfully pushed helps minimize conflicts. I also found that sometimes the error output will flag items that are clearly in the configuration in Panorama but are not being recognized by the firewall during the push. No other solution has worked besides re-adding the object locally on the firewall and then committing the config locally as well. After that the commit succeeds and the device can be moved to the preferred DG and template stack. Hope this helps anyone else who runs into this.
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!