How to import configuration file containing Prisma access Multi-tenant into panorama.
Objective
There are some additional steps required when importing the configuration from an old Panorama to a new Panorama when both the below conditions are true
- The Panorama is used to manage Prisma Access with multi-tenancy enabled.
- The Prisma Access contains "Mobile Users" configuration in one or more Sub-Tenants.
- When an old panorama needs to be replaced with a new one like Eval to Prod migration.
- For disaster recovery where the old panorama has failed a new one is being provisioned.
Environment
- Panorama running 9.1.x or above with
- Cloud services plugin 1.7.x or above.
- The Prisma Access is licensed and running Multi-Tenant configuration with "Mobile Users" configured for one or more sub-tenants.
These steps are Not required when Multi-Tenancy is NOT enabled.
Procedure
Listed below are the steps. For detailed information about each step, refer to the documentation.
1. Follow the basic initial steps to bring up the new panorama and network connectivity. Refer "Setup Panorama " for detailed steps.
2. Perform necessary upgrades to make sure the new panorama is exactly on same PanOS version and same cloud service plugin .
3. Transfer the licenses and make sure new panorama has correct/same licenses as the old one.
Once done, follow these steps to correct the validation errors
- On the new panorama, fetch the licenses from update server and keep it ready with cloud_service plugin installed and OTP verification already processed.
- If the production Panorama appliance is completely new, export the configuration from the old panorama appliance (if you have not done so already) and import it to the new Panorama appliance. (The assumption here is that full config is exported and full config will be imported to the New Panorama Appliance. Partial export of config (only Prisma Access) or Partial load of config (only Prisma Access templates/DG), is Not supported for Multi-tenant Prisma Access. )
- Load saved config. At this stage if we do local commit or commit validate few errors can be noticed if configuration has mobile onboarding for sub tenants.
- To avoid commit errors , remove mobile users onboarding configuration for all sub tenants and also both Global Protect portal and gateway config under Prisma Access Mobile user templates. (Check the addition information section if the commit validation still fails with errors for global protect related configuration)
- The mobile user onboarding configuration needs to be deleted from Panorama>Cloud services> Configuration >Select respective tenant >Mobile users >Click on remove at the bottom.
- Validate commit again and make sure no validation errors. (Do not proceed further if there are validation errors with respect to mobile users/global protect config)
- Please execute "debug md5sum_cache clear" on panorama CLI before doing local commit.
admin@Panorama> debug md5sum_cache clear md5sum cache entries cleared admin@Panorama> - Do local commit to panorama
- Run this command to avoid an issue where the plugin config might be lost. (Applicable only on Panorama PanOS 10.1.8/10.2.3 or below)
> request clean-replay entries all - Once commit is successful, load config one more time and perform local commit again on panorama. This step is necessary to bring back the deleted mobile users configuration.
- Perform sanity checks to make sure the configuration for Prisma access is similar to the configuration on an old appliance or as desired.
New panorama is now ready to push configuration to the cloud firewalls.
Additional Information
Some caveats:
With the step 4: The primary objective is to remove all the mobile users aka GlobalProtect configuration from the Panorama to avoid any errors. If for some reason, This is not done, please follow steps below.- Delete the Mobile user onboarding config from Cloud services>Configuration>Select the tenant with MU config> Mobile users and remove the config. (Confirm this step is done)
- If that is done, manually select the respective template and template stack and delete any remaining portal or gateway config.
- If the commit validation still fails with GlobalProtect related errors but the configuration is not available in the GUI, more steps are needed to be done manually. Here is an snippet of such validation error.
Validation Error:
devices -> localhost.localdomain -> template-stack -> mu-stk-tenant1 -> config -> localhost.localdomain -> network -> tunnel ->
global-protect-gateway -> GlobalProtect_External_Gateway-N -> local-address is missing 'interface'
- Export the current candidate-config.xml file from new panorama.
- Edit the file and find the problematic config and remove it. In this case, the config was related to "GlobalProtect_External_Gateway-N"
- In this example, following config parameters would need to be removed to fix the errors.
<global-protect-portal/>
<global-protect-gateway/>
</global-protect>
</entry>
</vsys>
<network>
<tunnel>
<global-protect-gateway>
<entry name="GlobalProtect_External_Gateway-N">
<local-address>
<ip/>
</local-address>
<client>
<exclude-video-traffic>
<applications/>
<enabled>no</enabled>
</exclude-video-traffic>
</client>
<ipsec>
<third-party-client>
<enable>no</enable>
</third-party-client>
</ipsec>
<ip-pool/>
</entry>
</global-protect-gateway>
</tunnel>
To
<global-protect-portal/>
<global-protect-gateway/>
</global-protect>
</entry>
</vsys>
<network>
<tunnel>
<global-protect-gateway/>
</tunnel>
- Change the name of this file and import it again on panorama and perform validation.
- If there are no validation errors, proceed to step 6 from above before doing commit.
Note: The error above is one example and other errors may also be present. For any Non-Prisma validation error, continue to troubleshoot based on error or contact support for guidance.
For example, if the validation errors are related to GlobalProtect configured for a template which is targeting an on prem firewall, the steps in the article are not applicable.
Additional Notes:
Commit errors can also be given if the Panorama sourcing the original config is on Panorama mode and the Panorama receiving the config is on Management-Only mode. This happens due to the Local Logging settings on the Panorama mode firewall which will not be applicable to the Management-Only mode Panorama. If the two Panoramas are on the modes mentioned and you are seeing commit errors even after performing all steps in this document, then perform the following.
- Check for any logging based configurations under the Panorama tab of the original Panorama.
- Remove all of the logging configurations you find under that tab.
- Perform the process mentioned in this document with these changes committed.