ABOUT Expedition is the fourth evolution of the Palo Alto Networks Migration Tool. The purpose of this tool is to help reduce the time and efforts of migrating a configuration from a supported vendor to Palo Alto Networks. By using Expedition (Migration Tool), everyone can convert a configuration from Checkpoint, Cisco, or any other vendor to a PAN-OS and give you more time to improve the results. Expedition (Migration Tool) 3 added some functionalities to allow our customers to enforce security policies based on App-ID and User-ID as well.   READ MORE    NOTE: Expedition is supported by the community as best effort. The Palo Alto Networks TAC does not provide support, so please post your questions in the community by clicking "Ask Questions" below.   Get the Expedition Installer   Expedition Installation This video provides a quick tutorial on installing Expedition on Ubuntu Server 16.04.   Get the Legacy Expedition OVA   Get the Legacy Expedition VM   Ask Questions   Get the Guides   Tutorial Videos  

    Expedition (updated to version 1.1.11) User Guide Version 1.2 What is Expedition?   Expedition is the fourth evolution of the Palo Alto Networks Migration Tool. The original main purpose of this tool was to help reduce the time and effort to migrate a configuration from one of the supported vendors to Palo Alto Networks. By using the Migration Tool, everyone can convert a configuration from Checkpoint or Cisco or any other vendor to a PAN-OS and give you more time to improve the results. Migration Tool 3 added some functionalities to allow our customers to enforce security policies based on App-ID and User-ID as well. With Expedition, we have gone one step further, not only because we want to continue helping to facilitate the transition of a security policy from others vendors to PAN-OS but we want to ensure the outcome makes use of the most advanced features of the platform to get you closer to the best of the possible configurations. For this reason, we added a Machine Learning module, which can help you to generate new security policies based on real log traffic, and we have introduced the Best Practices Assessment Tool, which checks whether the configuration complies with the Best Practices recommended by our security experts. With all these huge improvements, we expect the next time you use Expedition the journey to excellence will be easier.   Login   Login From the Web Interface   Web Interface Login   This is only referencing the access via web interface Username admin Password paloalto   SECURITY WARNING: We encourage you to change the username and password after your first login.   Changing default credentials   As a best practice, we recommend that you change the default credentials as soon as possible (DP – upon first log in)   Web Interface Login   After you log in via the web browser, follow these instructions to change the password for the “admin” user.   A new window to change the password will be shown: Type the current password Type NEW password Re-type NEW password Click on Save Remember the password length has to be at least 10 characters long.       Let’s Migrate   Expedition can help you migrate pieces of configuration from other security vendors and import them into a Palo Alto Networks configuration. The goal is to reduce time and mistakes. Expedition results always need to be reviewed by a professional with knowledge of the vendor that has been migrated and with Palo Alto Networks technologies as well.   There is no easy button that magically converts a configuration from any vendor to Palo Alto Networks without applying the right methodologies and using qualified people.   Migration Workflow   The migration workflow applies to all the vendors we support: Import a Configuration (from a supported vendor) Export Unused Objects Report Remove Unused Clean Invalid Objects Rename, Remap Interfaces to PAN-OS Naming Convention Import a Base Configuration (Palo Alto Networks configuration from the device that you are migrating to) Move Objects From the Configuration Migrated to the Base Configuration. Merge Remove Duplicates (if any) Generate the Output (XML, SET Commands, API Calls) First step will be always creating a Project, then enter the project by double-click on it.   Importing a configuration into the project     Expedition can read from different sources. For more specific insights on each vendor, go to the Appendix at the end of this document. Here we will describe the common procedure to migrate any configuration.   Navigate to the Import Tab and select from what vendor you want to migrate. After the configuration has been imported to Expedition, check for invalid objects and clean them before you move forward.   Project Dashboard   As a good starting point, it’s recommended to take a look at the Project Statistics panel. We can search here for invalid, unused, and duplicate objects. We can go straight to review the invalid services by clicking on the number shown under the invalid column for the Services Row. That will move the view to Services, which is located under Objects and will apply a predefined filter to show only the Invalid Services.     Remove Unused Objects   Before searching how to fix those invalid services, it’s important to remove what was imported but not used in any security or NAT policy. Let's call them unused objects. To remove the unused objects, you have to navigate to the Objects Tab and look at the bottom right bar.     At the very end, you will find three buttons. The green button will recalculate the objects that are defined as used or not used. This should be used after changes have been made on the configuration, so Expedition can recalculate the used objects. The red button is will remove the unused objects from the configuration. The third button with the "X" on it will export a report with all the unused objects.   We recommend exporting the Excel file to track which objects will be removed from the configuration when you click on the red button, and it’s good to keep it for your migration records.   After export the Excel file, click the red button to remove all the unused, and recheck your dashboard to see if you reduced the number of fixes you have to make.   Fixing Invalid Services   Every time you import a configuration from a vendor other than Palo Alto Networks, it's common to have what we call invalid services. We consider invalid services all of those who were based on IP protocols other than TCP or UDP. For example, you can find ICMP services related or IPSec, GRE.     After we have removed the Unused Objects, only the used ones will be kept for remediation. In the case of invalid services, the only way to fix it, in case the original service was not TCP or UDP, is change it to an App-ID from Palo Alto Networks.     To update the App-IDs, just right-click on the invalid service and click Search and Replace from the advanced menu.     This will open up the Tools Tab and show you the Search & Replace Tab. The view is divided in two panels: the left panel shows the output of the applied filters and the right panel will show you where the selected items from the left panel are used.     Replace Services by App-ID   Select the service to be replaced. For instance, in our example, we will select the Group where ICMP was a member and clicked the Replace button located on the bottom bar.   Click Security Policy (1) then select the rule where the service is used and click Replace again.     If you want to see the rule(s) that use this object, just double-click on the rule and you will be redirected to the Policy Tab and a filter by that rule will be applied.   After review, move back to the Tools Tab, click the Search & Replace Tab, and click on Replace. In this example, we are replacing a service by an App-ID, so select Replace by “Applications” and then to “ICMP” and click Replace All.   There are a couple options enabled by default: Split rules when needed – In case we are replacing services by App-ID, check if the rule where the invalid service is in use has more services defined. In that situation, the rule will be cloned to allow the new App-ID but removing all the other services from the cloned rule, and then the invalid service will be removed from the original rule. By doing this, we don’t mix services with apps in the same rule which can lead to change the original behavior of the rule. Remove Service from Group – In case the invalid service was a member of a group, it will be removed after the replace as a member.   This procedure can be used in many other ways. For example, if we want to filter by a service or address and remove that object from the configuration, just select the object from the Search Results panel then add to Replace from where it was being used. To replace, select Replace by combo “Remove.” That will remove the object from where it was used, or if you have an address-group or service-group and you want to replace it by the members instead, you will do the same but in the Replace and select “Members” then click Replace All.   After replacement of the invalid objects, you can repeat the step for removing the unused objects since they will not be used anymore.   Remapping Interface Names   Expedition, when imports configurations from other vendors, keeps the original interface names to make the validation process easier after the import. The problem with that is naming usually doesn’t match the one that Palo Alto Networks expects, so we have to rename them to ensure the changes will be captured by our Palo Alto Networks configuration.   For example, we import a configuration from Cisco, and the interface names are “Ethernet1/1” which is very similar to a Palo Alto Networks naming convention, but, in our case, it must be all in lowercase.   To convert it to the proper naming convention, you can select the Ethernet1/1 that is parent for more sub-interfaces (vlan tags) and click on the Remap Interface Name located at the bottom left-side bar. From there, select Slot 1 and ethernet1/1.     After clicking the Remap button, the Expedition tool will replace the name of the interface in the whole configuration, including any references to it and any subinterfaces.     You will have to repeat the process to adapt all the interfaces that you want to migrate.   Import Your Base Configuration   What is the Base Configuration?   Base Configuration is a device's specific configuration that is usually taken from the Palo Alto Networks device that you are migrating to. The base configuration should be used, as the name suggests, as a base and should be merged with the imported third-party vendor configuration that you have imported and manipulated. The result of the merge should be a working and migrated Palo Alto Networks configuration.   The first PAN-OS configuration imported into the project will be assigned as Base Configuration. The Base Configuration is the one that will be used at the time to export the configuration out of Expedition or by generating an XML file or API calls. Any changes made to the Base Configuration will be applied to the output.   To import a Base Configuration, click the Import Tab from the PALO ALTO Tab and enter a link to your XML file that you previously exported from your PAN-OS device or just double click on one of the devices added to the project (if any) to import the config from the snapshot stored in Expedition.     After that, you can check from the Export Tab that the config has been set as Base Config by seeing if it has been placed in the right panel.     From there, you can select what objects we want to move from the left panel to the Base Configuration (right panel) by using drag and drop.   In case you want to move the objects from the left panel and convert them as shared objects, drop them into the Shared vsys/DG. After the merge, they will be transformed into shared objects, and all the references to them will point to the new shared objects (from policies, groups, etc).   Merge Objects to your Base Configuration   All migrated objects should be visible on the left panel under the Export Tab. The right panel should have your Base Configuration that you previously imported. You just need to drag and drop the migrated objects and policies from the left to the right. You can select certain parts of the migrated configuration to be moved to the final configuration or all of them.   Please make sure you place the objects and policies into the desired vsys configuration.     Repeat the same procedure with the Zones, Interfaces, Virtual Router(s) and drop them into the correct vsys.     The final step is to merge the migrated configuration and your base configuration and create you final configuration. To do this, click the MERGE button.   After this action, all the selected objects will be transferred from one configuration to the Base Configuration. If you want to see how it looks, you need to change the selected configuration and the vsys to the Base Configuration from the bottom bar by going to the Objects Tab. This will filter and show you the objects and rules on the Base Configuration.     After you have created the final configuration, you have two options to deploy it. One option is a manual XML file export that can be deployed on the Palo Alto Networks device to which you are migrating, and the other option is to use API calls to send parts of the configuration or the whole configuration to the device if that Palo Alto Networks device is already connected to Expedition.   Find Duplicates After the Merge and Removing Them   It is recommended that you run another check for duplicates and remove or merge them after a configuration migration. A common scenario is to have duplicates amongst objects, services, and/or interfaces.   Using the dashboard from within the project, it will tell you how many duplicated objects you have in your current configuration. You can click on the duplicate object to go to the object view, and Expedition will filter by duplicate and by name predefined filter.     Next, check the duplicated services to demonstrate the workflow to follow and get rid of them.     The object in Pink is a Shared object, so that means you have selected the vsys equal to all from the bottom bar. This will do a search across all the vsys/DG to find objects seen more than once. In our example, we want to keep the object that already exists as Shared and make all the references within the vsys/DG points after the merge to the Shared object only and finally the duplicated object out from the Shared will be removed.   First, select the duplicated objects you want to keep and then right-click and select Merge Options and “Set as Primary.” That will tell Expedition to keep the one we set as Primary after Merging the duplicated objects.     When the object has been set as Primary, you will notice a new icon appear.     Now you can apply the Merge type. In our case, we will use Merge by Name and Value to validate only the same duplicated object is merged. Right-click and select “Merge” then click “By Name & Value.” This will be applied to the selected objects or, in case you didn’t select any, it will be applied to all the results from the filter applied.   You can change the filter and add a predefined filter to show only the duplicated services by name only and then apply the merge by the same concept, only by name as well.   All this can be done with the right-click “Select predefined filter.”   Generating the Output When you are finished cleaning your configuration, it’s time to get the results and export from Expedition and import into your Palo Alto Networks device (Firewall or Panorama).   Navigate to the Export TAB.   Under the Mapping Tab, there is a button at the bottom bar-left titled “Generate XML & SET Output.” By pressing this button, Expedition will generate a XML configuration file and based on that configuration (and using a script called Pan-Python made by Kevin Steves https://github.com/kevinsteves/pan-python) it will generate the Set commands as well. After the generation, a new window with the download links will appear. Click the Downloads button to get access to that window as well.     You can generate API Calls to be sent to your devices in case you created them before and you added to the project you are working on. In that case, you will need to go under the tab titled, “API Output Manager.”   Here, you have several options. We will start covering Atomic and Subatomic.   Atomic calls will be API calls where with a single API call will add all the address, for instance, to a specific vsys/DG. If you select subatomic, you will get one API call by element you have. If you have 500 addresses, you will get 500 API calls, one for each address. With Atomic, you will get just one API call containing the 500 addresses inside.   Step One: Click on “Atomic” or “Subatomic” and click the “Step 1” button to create all the API calls. After that, the ID of each API call will tell you the order in which you have to send the API call. Yes, order matters. If you don’t select any, all API calls will be sent in the proper order.   Step Two: Click “Step 2” button and select the DEVICE where you want to send the API calls and send them all.     After the API call is sent, you will get the response from the device itself. If it was successful, you will see in the output.       Appendix A: Import   Importing CSV files   From within a project, it's possible to import CSV files containing objects that you want to add to you current configuration.   Requirements   You must have a configuration previously loaded in order to import something else on top by using CSV files.   How the CSV file must be created: The character used to split by columns is the semi-colon “;” The character used to split members inside a column is the comma “,”   Process   Select the object type you want to import. Example: Static Routes Select the CSV file from your laptop Map your columns with the predefined fields from the right panel Select where to import the new data loaded from the CSV and mapped In this example, routes are part of Templates and need to be imported into a Virtual-Router. Plus, select the virtual-system where your VR is located. Then click Import Data.   Order matters! If want to import Service Groups, you need to first import the services used on those Groups or the import will not be successful.   Importing an IronSkillet Day1 Configuration   IronSkillet is a project made by Palo Alto Networks to create a configuration that is already configured with some of the best practices recommended by our security experts. If you need to add a Base Configuration into Expedition to use it as a base to migrate something else, it's very simple now with the integration built in Expedition.   Process   Create a project and click to get in. After you enter the project, go to IMPORT. Then click the Tab title "Iron-Skillet."     From here, you can configure some parameters before the configuration is created. You can modify the parameters by hand, or, if you have an IronSkillet configuration file, you can load it to automatically fill the fields. Select the Configuration Type (Firewall or Panorama) this will generate the type of configuration selected. PAN-OS Version. You can select if the configuration you need but it must be 8.0 or 8.1 or X.X If you have an IronSkillet configuration, you can click LOAD FROM CLIPBOARD and paste the content from the file and then click SAVE. That will automatically fill the fields configured. Example: https://raw.githubusercontent.com/PaloAltoNetworks/iron-skillet/panos_v8.0/my_configs/sample-mgmt-dhcp/my_variables.py     After the changes are made, you have to click on GENERATE CONFIG AND IMPORT. This will create a Palo Alto Networks configuration file based on your selection (Firewall or Panorama) and with the selected version and all the changes made in the parameters will be applied to it. After IronSkillet generates the new configuration, Expedition will Encrypt it and automatically imported into the Project. If this is the first Palo Alto Networks configuration loaded on the Project, Expedition will set it as the Base Configuration.     Revision History Date Revision Comment June 22, 2018 A First release of this document. October 16,2018 B Added Appendix A April 1,2019 C Updated Screenshots August 27, 2019 D Created LIVEcommunity Article and Editorial Revisions