Panorama import local managed device issue

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

Panorama import local managed device issue

L1 Bithead

 

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
 

1 accepted solution

Accepted Solutions

Cyber Elite
Cyber Elite

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

Help the community: Like helpful comments and mark solutions.

View solution in original post

4 REPLIES 4

Cyber Elite
Cyber Elite

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

Help the community: Like helpful comments and mark solutions.

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

  1. Push the device configuration bundle to the firewall to remove all policies and objects from the local configuration. Go to Panorama > Setup > Operations and click 'Export or push device config bundle'Select the Device from which you imported the configuration, click OK, and click Push & Commit.

Cyber Elite
Cyber Elite

@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.

Help the community: Like helpful comments and mark solutions.

L2 Linker

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.

Roderick De La Rosa
Information Security Analyst
Palo Alto NGFW Apasionado
AiOPs for NGFW Biggest Fan
Expedition Migration Tool Wizard
  • 1 accepted solution
  • 7627 Views
  • 4 replies
  • 0 Likes
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!