Migrating ASA to an Existing PA820 Managed by Panorama

[NguyenJimmy]

I am running Expedition version 1.2.78.  Currently, I have a PA820 up and running in production.  This PA820 is managed by Panorama.  I also have an ASA that I want to migrate to PA820.  I am very new to Expedition so I am asking for step-by step instructions on how to:

-Convert ASA objects and policies, export to xml files and then import them into Panorama and push to PA820.  There are existing objects and policies on PA820 that I don't want to be overwritten.

Since there are many hosts use PA820 as gateways, I plan to add IP address to PA820 as secondary.  I wonder if I can  merge the ASA interface IP to PA820 and then make existing PA820 IP addresses on its interfaces to be secondary.

The PA820 was meant to replace ASA but due to lack of knowledge on migration, it was running parallel to ASA since.

Your help is greatly appreciated.

[sanandh]

Expedition Documentation is available here

For Migration, please refer to the User Guide from this list. Let us know if you need any additional details.
Regarding the question on interface IP, I  recommend working with your palo alto networks account team.

[mnagel-wm]

I've done this several times and I personally would not recommend any scenario where Expedition is merging your configuration directly into the firewall or Panorama as the software is decent, but too unreliable to directly touch production IMO.  What I did with my migrations was to leverage the set commands with some manipulation to match Panorama device groups and templates where needed, then deployed the changes in sections (objects first then policies and so forth) via the Panorama CLI.  It is extra effort, but you control things much more than I'd feel comfortable allowing Expedition to do. The glitch here is that Expedition frequently fails to generate the full set-format configuration (happening to me right now for an ASA migration on the latest 1.2.78 release). Presumably this is due to something that Expedition permitted to be imported or configured in the UI that triggers an error internally and set command generation just silently fails.

[NguyenJimmy]

Hi Mnagel-Wm,

Thank you for your sharing.  You are right.  Having Expedition sending converted XML files to production PA is not favorable.  My question is what is your process to create a script from converted XML so you can run it at Panorama CLI?

[mnagel-wm]

The specifics depend on your situation, but here is a sample of how I converted rules into the right format using the input file with set commands:

#! /bin/bash

PAT=$1; shift

INPUTFILE=set-commands.txt
DEVICEGROUP=MyDeviceGroup

for tag in $(grep -E "set tag $PAT" $INPUTFILE | awk '{print $3}'); do

 for rule in $(grep "^set rulebase .* tag " $INPUTFILE | grep -w $tag | awk '{print $5}'); do
  grep -w "$rule" $INPUTFILE | sed 's/^set rulebase/set device-group $DEVICEGROUP pre-rulebase/'
 done

done

Just some preprocessing to allow the single converted firewall results to import correctly into the target device group.  You will almost certainly need to move a few things around, but still much more production-friendly.  Note that this example allows you to extract the rules based on tags, but you could skip that part. You also have an opportunity before sending these commands to review everything and be sure it is exactly what you want.

[dpuigdomenec · Accepted solution]

Hi @NguyenJimmy 

For ASA to PA migration here you have a set of videos that will show the migration steps workflow making sure you remove unused objects and avoid having duplicates / invalids. https://www.youtube.com/playlist?list=PLD6FJ8WNiIqVez8EBeoyRsnQcKTA5FuZ-

When you have the migrated configuration ready to merge, another option is to add it into a new DG/Template within your Panorama. Then download the output XML and do a load partial mode [merge] to the desired DG/Template.

One challenge in your scenario is to set proper the order of the rules (as you are merging current rules and new rules coming from the ASA) so a recommendation to minimise the risk and post-validations, if possible, is to split/define different zones so rules are properly using them.

After the merge Expedition can help on the cleanup and rules reordering if needed. Also you can use the Analyse rules to look for potential rules that can be merged based on same attributes.

@mnagel-wm please could you share your issues with fwmigrate@paloaltonetworks.com so we can have a look at them.

Thanks in advance and hope this helps,

David

[mnagel-wm]

Importing that XML into a new DG/template would at least be safer.  In my case, I needed to merge multiple firewalls into a single existing target so I could not do that (reconciling multiple firewalls was challenging and greatly helped by Expedition). 

As far as my issues, we've already discussed this at least somewhat.  I think in my current ASA migration the broken IP Wildcard objects are breaking the set export (I think last attempt I tried putting masks into regular address objects and Expedition allowed it, but then failed later). It is hard to tell for sure since there just aren't any objects at all in the results and no errors. Given the silent failure behavior, it is hard to trust that Expedition output is correct for either XML or set to the point that I would be comfortable loading it into a production environment, but at least I can eyeball set commands to see if they appear complete and correct.

[NguyenJimmy]

Hi mnagel-wm,

Thank again for your response.  I am not good with PA CLI so I found it is little intimidated for using your suggestions.  I think I will spend more time learning how to use Expedition and use merge features to come up with exported XML files.

Preview

mnagel-wm

Preview

[NguyenJimmy]

Thank you for your suggestion.  I saw the video more than once.  I guess I still not fully understand how to use Expedition.  It is indeed a very good tools.  I will stick with Expedition since I can always review the final product before I import and commit to PA.

On another note, can you merge the virtual routers.  My project ended with another virtual router that I want to merge into the existing default router.  Is that possible?

Thanks, JN

[dpuigdomenec]

Hi @mnagel-wm 

The merge output is generating the file /tmp/error in case it throws any. 

Please check it and let me know the content.

Thanks for your help,

David

[dpuigdomenec]

Hi @NguyenJimmy 

I'm sorry but Expedition does not support to merge virtual routers.

If you have any particular doubt or concern on the workflow we can set up a call to go over them.

Please send an email to  fwmigrate@paloaltonetworks.com.

Thanks,

David