You are on page 1of 130


Palo Alto Networks

Migration Tool Version 3.3

Users Guide

Contact Information
Corporate Headquarters:
Palo Alto Networks
4401 Great America Parkway
Santa Clara, CA 95054

About this Guide

This guide takes you through the utilization of the new Palo Alto Networks Migration Tool 3. This guide is
designed for users with previous knowledge of the PAN-OS platform.
The Palo Alto Networks Migration Tool 3 replaces previous versions of the Migration Tool. Refer to the following
resources for additional information:
• For information on the additional capabilities of Palo Alto Networks firewalls and for instructions
on configuring the features on the firewall, refer to
• To provide feedback on the documentation, please write to us at:
• To access to the Community, which includes the knowledge base, discussion forums, and videos,
refer to
• To contact the migration team, refer to
• To manage your account or devices go to the support portal:
• For the latest release notes, go to the software downloads page at © 2015 Palo Alto Networks. All rights reserved.

Palo Alto Networks and Palo Alto Networks Migration Tool 3 are registered trademarks of Palo Alto Networks, Inc
Revision Date: Feb 10, 2016
Table of Contents

Overview.................................................................................... 1
How the System Works ............................................................. 2
How to Install ............................................................................. 3
Configure static IP-Address ....................................................... 3
The Login Window ..................................................................... 4
The Main Dashboard ................................................................. 5
Dashboard Elements ................................................................. 5
System Commands ..........................................................................5
System Resources (Usage) .............................................................6
Projects ............................................................................................7
Add New Projects ..................................................................................... 7
Load Selected ........................................................................................... 8
Filter by Tag .............................................................................................. 8
Remove .................................................................................................... 8
Remove All ............................................................................................... 9
Devices ..........................................................................................10
Snippets .........................................................................................10
Updates ..........................................................................................12
Settings ..........................................................................................14
Help ................................................................................................16
Supported Vendors.................................................................. 17
Checkpoint .....................................................................................17
Cisco ..............................................................................................18
McAfee: Sidewinder .......................................................................19
Juniper: ScreenOS .........................................................................19
Juniper: SRX ..................................................................................20
Fortinet ...........................................................................................20
Forcepoint Stonesoft ......................................................................20
Universal (CSV Files) .....................................................................21
Palo Alto Networks .........................................................................23
The Project .............................................................................. 24
Dashboard ......................................................................................26 © 2015 Palo Alto Networks. All rights reserved.

Palo Alto Networks and Palo Alto Networks Migration Tool 3 are registered trademarks of Palo Alto Networks, Inc
Revision Date: Feb 10, 2016
Plugins ...........................................................................................27
Log Connector ........................................................................................ 27
User-ID Connector .................................................................................. 28
Monitor ...........................................................................................29
Policies ...........................................................................................31
The Security Policy Editor:....................................................................... 32
The Advanced Options:............................................................................ 33
Policy Filters ...................................................................................35
Objects ...........................................................................................38
IPSec Tunnels and Network Profiles ..............................................56
Device ............................................................................................62
Snapshots ......................................................................................73
Debug .............................................................................................74
The Workflow........................................................................... 76
Migration Projects ..........................................................................76
Optimization Projects .....................................................................77
Sample Project – Step-by-step guide. ..................................... 78
App-ID Adoption – Step-by-step guide. ................................. 102
User-ID Adoption – Step-by-step guide. ................................ 116
Migrating Cisco ASA VPN (Lan-2-Lan) ................................. 121
Workflow ......................................................................................121
P A L O A L T O N E T W O R K S M I G R A T I O N T O O L 3 . 3

he main objective of the Palo Alto Networks Migration Tool 3 is to assist

T network security administrators, professional consultants, or anyone working

on migration, rules optimization, security controls validation, App-ID and
User-ID implementation, or deployment of converted or new configurations
to devices directly connected to the Palo Alto Networks Migration Tool 3 or
using exported XML files as needed.

The Palo Alto Networks Migration Tool 3 is derived from the successful Migration
Tool used by the Palo Alto Networks Professional Services Organization and Channel
Partners. It’s an evolution of the Migration Tool into a configuration platform that
allows you to, not only migrate configurations, but enhance, optimize, add, remove or
edit elements, ultimately converting the legacy device rules into a next-generation
model by creating App-IDs and User-ID based on real traffic acquired from devices
being installed or already in production. The Palo Alto Networks Migration Tool 3 is a
valuable asset for network security administrators who need or want to keep their rule-
bases in a pristine state.


How the System Works
he Palo Alto Networks Migration Tool 3 (a.k.a MT3.x) has a database that

T tracks each task you are doing and also contains the data you would find
within any Palo Alto Networks device. The new migration tool is delivered as
part of a package in a Virtual Machine; you need a Virtual Environment to run
the Palo Alto Networks Migration Tool 3 either in MS Windows, Mac OS X,
or Linux.

Your entire interaction with the tool will take place via a web interface where you are
able to restart, shutdown, clear your log settings, and restart your database.
A constant resource meter will display the CPU, RAM, and disk space utilized within
the Virtual Machine. Also the version and patches will be visible from this main panel
when you start the Palo Alto Networks Migration Tool 3.

You can load several configurations, merge them into different configuration
candidates, and then release these new configurations into the PAN-OS (5.x, 6.x, 7.0)
using API calls or by exporting them into a common XML file. You will be able to
merge one or more candidate configurations into a new or existing PAN-OS

You will be able to import active PAN-OS configurations, and tweak, edit, cut or
manipulate the elements, perform a multi-edit throughout the XML elements in your
present (imported) configuration file without the need to edit any code.

From the CLI (Command Line Interface), which is available within the MT3.1 and
later versions, you may find several commands to help with the VM configuration, Fix
IP configuration, other network configurations, and some database access as well.

You will be required to enter a username and a password once you load the VM. The
correct credentials to initiate a session in the Migration Tool are:

user: admin,
password: paloalto (as of this version 3.3).

How to Install
The Migration Tool can be downloaded from the migrate community at

! Note

The Migration Tool can be found as a TAR and GZIP packaged file (in which case it
will be available as with “.tgz” file extension), and as a ZIP packaged file (“.zip” file
extension). TZG files are well-known in multiple OS, such as Linux or Mac but not
supported by default in Windows platforms.

! Note
Windows Users: You can unpack the “.tgz” files with tools
such as 7-zip, which you can download from http://www.7- . You need first uncompressing the GZIP and after that
unpack the TAR file. At the end you will see a new folder called:

Linux or Mac Users: You can execute the following command form the cli:

tar -zxvpf PanMigrationTool3i.tgz Or double-click from your X window system.

Now you can open the VM using a VMware Player version 6 or higher or VM
Workstation 10 or higher.

Minimum requirements are 1GB of RAM and one VCPU. But you can assign more
RAM or VCPU depending on how big will be the configuration you are trying to

The performance will be highly increased if the physical disk where is placed the tool is

More information related to the installation can be found in our community at:

Configure static IP-Address

The MT comes configured in DHCP-client mode. If you want to change to a static IP-
address, please run the following command (after login in the cli using the VM

sudo nmtui

In case you were not familiar with “nmtui”, you may follow the instructions available at

The Login Window

With the Virtual Machine running, pointing your browser to the VM’s IP address will
bring you to the following screen: The Login Window.

Now, to get access to the tool you need to authenticate first against the local database.

! Note Default username and password are admin / paloalto. This can
be changed from the GUI.

This new mechanism provides a new layer of security to prevent the access to
everybody to the tool since the tool now can be installed on a network and stay longer
because the App-Id adoption features.

We are using PHP sessions and there is a disconnection Time-out after 60 minutes of
inactivity. All the PHP code will stop to work if there is no session active. You have to
re-authenticate again to create a new Session.

This new feature only provides by now a Local Database Authentication, there is no
integration with AD or LDAP yet.

This function has the unique goal of provide authentication to get access to the tool,
but will not provide any group categorization or Role based access. All the users are
admin, even if you create new users.

The access to the tool will generate Audit Logs to know who was logged in and when.

The Main Dashboard

The Main Dashboard provides access to your Projects, Devices, Updates, Snippets and

The MT3.1 and above include a new Section for Settings.

Dashboard Elements
System Commands
System commands are split in two categories: Operations and System.

The Operations commands control system variables such as the logs and database.
There are two functions: Clear System Logs, and Restart Database.
Clear System Logs resets the application logs, as well as the local system logs (not the
devices logs). The same happens every time you restart your MT.
Restart Database reinitiates the database engine without requiring a reboot of the entire
system. This may be useful when a table re-indexes or reset is needed.

The System commands control the functionality of the Palo Alto Networks Migration
Tool 3 and offer three functions: Restart, Shutdown and Logout. These functions
control the application hosted by the Virtual Machine, and it sometimes might be
useful to restart the application state when you import or create a new project, or to
refresh system resources if needed. The Logout option will close your current Session,
and you will be redirected to the Login Window again.

System Resources (Usage)

Usage displays the usage of resources within the Virtual Environment.

CPU displays the average system load. This value should be taken as a reference of the
CPU usage, but not as a real-time CPU read.

RAM shows the used memory. It is important to notice that it is a normal tool
behavior to consume high RAM resources, because there we cache multiple objects
and data structures in the memory to improve performance. Therefore, do not worry if
your used RAM consumption is high.

DISK shows you the used HD space. In case you may require freeing DISK space,
you can clean it by rebooting the Virtual Machine, which would clean system logs plus
the logs generated by the MT.

! Note Use the refresh icon for updated statistics.

The Projects tab is where you create or remove projects.

If you have a large number of projects in the Palo Alto Networks Migration Tool 3,
you can filter projects by Tags (customer name if applicable).

If the project was made to run an App-ID adoption process there is a progress bar that
will recall you in what step of the process is the project right now. 1 is you have
retrieved the apps from the Firewall, 2 is we have split the rules in Known and
Unknown apps, 3 is we have used the option to override some traffic and 4 is we have
used the reconciliation option.

! Note When creating or deleting filters, use the refresh button next the
Filter field to ensure that you are seeing the most up-to-date
project list.

Add New Projects

Click Add New Project and then enter a Name for the project. Optionally add a Tag
to be used as an easy search key in the future (i.e. Customer Name).
You can also import any existing App-IDs, threats signatures, URL Categories, or
regions from registered devices (Devices Tab). Default option will load a default list
inclided into the tool.

We recommend always importing your Firewall or Panorama into the tool to get the
exact same version of applications in the new project and what you have in your

When clicking on Initialize Database, a new Database will be create to store the new
Project and the Applications, Url Categories, Regions will be loaded into the new
project from the Firewall selected as a Source. In case a Firewall is not selected, a list of
predefined Applications, Url Categories and Regions will be loaded from an internal
copy provided by the Migration Tool 3.
Load Selected

Click Load Selected to load the selected project into the system; at this point you may
start using the Migration Tool 3 functionalities within the selected project. It is also
possible to load a project by double-clicking on a project.

Filter by Tag

The filter by tag feature can assist you in finding, among several projects created, the
one you want to load into your system. It will filter by project Tag previously created
on each project.

Click Remove to remove a selected project. Using a filter here will group your query.
Notice that this action cannot be undone.

Remove All

Click Remove All to delete all projects you have in the system independently of any
filters you have selected at the moment. To avoid unintentional deletes, you will be
prompted to enter the Yes string and Confirm to perform this action.
Notice that this action cannot be undone.

Use the Devices tab to add devices, including firewalls and Panorama, to (1) target for
migration, (2) to use as a data source in a “Connector,” or (3) to import application
signatures, threat signatures, URL Categories, and regions when creating a new project.

When you import a Firewall, the tool will try to generate an API key based on the
information you have provided as IP address, Username and Password.

Once the API key is generated the tool will retrieve the Applications, Regions, Url
Categories and a Full configuration Backup from the Running Configuration.

! Note Importing a Panorama (physical or virtual) into the tool will

automatically import all the Connected Devices to this
Panorama and will create as Devices as well.

It is possible to Edit the Devices by double-click or selecting one and click on Edit
Selected. If you had modified the running configuration in our firewall, you can edit the
device and click on Retrieve Configuration to get the latest Running configuration
from the target device.

Snippets are a new and powerful feature to enable you to keep and save XML code for
reuse by the Palo Alto Networks Migration Tool 3. You will be able to create App-ID
signatures by copying them from a running device and then saving them on the system
to be reused in other projects in the future.

Use the Snippets tab on the main Dashboard to create snippets to be used throughout
the Palo Alto Networks Migration Tool 3. You can create specific Snippets for specific
PAN-OS versions from 4.0 up to 7, which will be updated as new feature releases are
added. You can create the following categories of Snippets:

• Addresses, App-ID, AV_Profile, File_Profile, IPS_Profile, Log-Profile,

URL_Profile, Services, Application Groups, Management Profiles, Profiles
Groups, Custom_Reports and Wildfire Profile.

You can apply Snippets to a single policy or a group of policies.

To maintain the list of Snippets, use the Add, Remove (selected) or Remove All
buttons on the bottom bar. You can also select the Type of Snippet to filter on by
selecting a value from the drop-down and search for a text within the filter. If you want
to search for all Snippets, simply use All as your filter selection.

It is possible to create more than one entry for Address, Services, Application Groups
and Wildfire Profiles in order to allow importing several objects in one single Snippet.
See the image below as an example of multiple Addresses in one single Snippet called

The Updates tab allows you to Upgrade the version in your Migration Tool 3. There
are 3 different ways to achieve that:

1. Direct Internet access: connects your Palo Alto Networks Migration Tool 3
directly to To do this, the Virtual
Machine must able to resolve this name over the Internet (proper DNS
configuration). The connection is established matching the App-ID “paloalto-
updates”, and the service used is “443/tcp”.

2. Proxy Settings: You can configure Proxy

Settings if you are behind one by selecting
on “Set Proxy Settings”

3. Off-line Updates: The Migration Tool 3 can be updated using bundle files
provided from our Community at . To use this capability a
minimum version 3.0.2 of the Migration Tool is required. The instructions are
simple, just download the bundle for the version you want to upgrade, unzip
and load it into the tool by selecting the option “import bundle (offline)”.

! Note Every time you click on the tab “Updates” the tool checks for
the proper DNS resolution and whether a connection to the
port 443 at the address can be established. If
one of these checks fail the Update button will remain disabled.

! Note To keep informed when a new release is available you can

“follow” the document, so you will get notified by email
each time a new fix is released.

There are three Options here:

Users: This area allows us to change the password for the user admin and to create
new users. All these users can used to login into the Tool using the WebUI.

Double-Click to Edit an existing User. It is possible to disable or change the password

for all the users, with the exception of the admin, that only allows password changes.

System: By now this option is used to Setup the Data and Time in our VM. We can
assign our Time zone as well. This will be key in order to use the Cron jobs.

Click on Edit to configure the Time and the Time zone.

Cron Jobs: Tasks can be scheduled to be executed periodically or just once based on
date and time. There are different types of tasks that can be created from the Migration
Tool 3.

Task Type: App-id Adoption

The schedule of this type of tasks will help us in the App-ID adoption process to
retrieve the applications for example every Sunday night at 00:00 for the last week.
With this when we arrive on Monday we have to work only with the output without to
waste time generating all this reports because they are already created at night.

The Task needs to know the Project, the Log Connector, when we want to execute the
task and we can configure if we want to create the reports only for the selected rules.

The changes are applied as soon we save the Task. Only if the task is disabled will not
be applied.

Task Type: User-id Adoption

The schedule of this type of tasks resembles the process applied for App-id Adoption.

The Help tab displays the URL for the online Community.


Supported Vendors
he Palo Alto Networks Migration Tool 3 provides a list of supported vendors

T from where we can migrate to our Next-Gen configurations. The current list
of these vendors is:

1. Checkpoint
2. Cisco ASA / FWSM
3. Mcafee Sidewinder
4. Juniper ScreenOS
5. Juniper SRX
6. Fortinet
7. Stonesoft
8. Palo Alto Networks
9. Universal (CSV files)
10. AlgoSec (explanation here
9578 )

Supported Versions Supported Objects Not Supported yet

From 4.1 to R77 þ Services ý IPSEC VPN

þ Services Groups ý Dynamic Obj. Nat
þ Address ý Schedules
þ Address Groups ý Application Blade
þ Security Rules
þ Nat Rules
þ Exclusion Groups
þ Zones
þ Interfaces
þ Static Routes

To understand the options to active when migrating from Checkpoint, please read the
following document first:

Exclusion groups will be replaced by a group containing the IP-Ranges that covers
the objects included less the objects excluded.

Show the Checkpoint Configuration as is shown in the Smart-GUI:

From any Security Rule right-click with your mouse to see an Advanced Menu then
select 3rd Party → Checkpoint → Open Viewer. This will open a new window
containing the checkpoint configuration useful if you want to compare with 2 screens
the original configuration and what you got loaded into the Migration Tool 3.

It is important to import a routes.txt file, which should contain the output from the
command “netstat –nr” executed in the firewall that we are trying to migrate. This will
help the Migration Tool to calculate the zones.

Supported Versions Supported Objects Not Supported yet

ASA up to 8.2 þ Services ý Schedules

þ Services Groups
þ Address
þ Address Groups
þ Security Rules
þ Zones
þ Interfaces
þ Static Routes
þ Nat Rules
ASA 8.3 and higher þ Services ý Schedules
þ Services Groups
þ Address
þ Address Groups
þ Security Rules

þ Nat Rules
þ Zones
þ Interfaces
þ Static Routes

Only access-lists with an access-group associated in the config will be migrated. The
tool will calculate the zones based on how the access-groups were applied to the
interface or IN or OUT.

If your configuration has groups called DM_INLINE there is an option in the

Advanced Menu (right click on a Security Rule) to replace those Objects by the

McAfee: Sidewinder
Supported Versions Supported Objects Not Supported yet

From 7 to 8 þ Services ý IPSEC VPN

þ Services Groups ý Nat Rules
þ Address ý Schedules
þ Address Groups
þ Security Rules
þ Applications
þ Zones
þ Interfaces
þ Static Routes

Juniper: ScreenOS
Supported Versions Supported Objects Not Supported yet

Up to 6.3 þ Services ý IPSEC VPN

þ Services Groups ý Schedules
þ Address
þ Address Groups
þ Security Rules
þ Nat Rules
þ Zones
þ Interfaces
þ Static Routes

Juniper: SRX
Supported Versions Supported Objects Not Supported yet

Junos 12 þ Services ý IPSEC VPN

þ Services Groups ý Schedules
þ Address
þ Address Groups
þ Security Rules
þ Zones
þ Interfaces
þ Static Routes
þ Nat Rules

Supported Versions Supported Objects Not Supported yet

From 3 to 5 þ Services ý IPSEC VPN

þ Services Groups ý Schedules
þ Address ý Apps
þ Address Groups
þ Security Rules
þ Nat Rules
þ Vdoms
þ Zones
þ Interfaces
þ Static Routes

Forcepoint Stonesoft
Before known as McAfee Stonesoft.

Supported Versions Supported Objects Not Supported yet

From 5.3 to 5.9.4 þ Services ý IPSEC VPN

þ Services Groups ý Schedules
þ Address
þ Address Groups
þ Security Rules
þ Sub-Security Rules

þ Nat Rules
þ Zones
þ Interfaces
þ Static Routes

A configuration file may contain multiple firewall policies. Select one or more firewall
policies to be imported in the Migration Tool 3. Each one of them will be imported as
read from different sources.

Universal (CSV Files)

Supported Versions Supported Objects Not Supported yet

Semi-colon delimited þ Services

fields, support for þ Services Groups
fields with multiple þ Address
values delimited by þ Address Groups
comma. þ Security Rules
þ Interfaces
þ Static Routes
þ Zones
þ Regions

This option allows you to import objects from other sources. If you have a legacy
firewall not supported by the current Migration Tool 3 and you are able to export the
configuration in CSV files, then the Universal CSV option will let you import those

Once you have imported one of the supported object types, then you can map the
columns with the field type.


Address CSV File

Addr1000;host;;;forest green;;;;"admin server "

gated_224;net;;;sienna;;;;"Required for GateD to Operate"

! Note Remember to load a configuration into the Migration Tool 3

before importing anything using the Universal CSV importer,

as this is required in advance.

Import Address CSV File Steps:

1. From your project, go to the Import Tab (green) and click on CSV (right)

2. Select Address in “Object To Import”. Upload the file by clicking on


3. If the file has been uploaded correctly, you will see the content under Data

4. Afterwards, you are required to Map the Field type with the columns loaded.
From the right Panel Column Mapping, double-click on each column to map
the type.

Below you can see and example of a field mapping.

5. Finally, click on Import Data. You will see the results of this Address import
by going to the Objects Tab

The Tags have been created and attached to each Address.


Importing Security Rules: If you want to import zones and they are not already
created in the Migration Tool 3 they will automatically created. This also applies to

Importing Static Routes / Interfaces: We need to select the proper Template and
Virtual Router before Importing the routes.

Always Import in the proper Order: Objects have dependencies that need to be
fulfilled. Therefore, it is important to import each configuration part in the correct
order. First import the Address and Services, then the Groups (services and address),
Zones, Interfaces, Static Routes and finally the Security Policy.

Palo Alto Networks

Starting from the Migration Tool 3.2, the tool supports PanOS version from 4.1 to 7.0.
The Tool can generate configurations in any version from 4 to 7 based on the version
of the Base Config.


The Project
fter we create a new project the tool, we are redirected inside this project for

A its management. From here a new set of Panels are presented. Let’s describe
it first to get more familiar with the Tool.

The tab presented on the top left side has been designed following the structure that
we have in our Firewalls or Panorama. However, minor details may differ.

From Left to right:

• Dashboard : Provides some information regarding the projects. This is useful
to see the existence of Invalid Objects, Duplicated Names, Unused Objects
and how many Security Rules are currently using App-ID functionalities. This
panel can also support us to identify the minimum Platform required to fit the
amount of Rules and Objects existing in our policy.

• Import: This tab contains the List of Vendors from where we can import. We
will find here the Snippets as well to be imported into our project.
• Plugins: From here we can add the Log Connectors to be used in the App-ID
adoption Process
• Monitor (from this tabs onwards, we find the same options that we have in
PanOS): Logs generated in the importation process and the Audit Logs
generated by the login window. We can generate PDF reports from here.
• Policies.
• Objects.
• Network.
• IPSec Tunnels and Networks Profiles.
• Device.
• Device Group (Hidden only shown when a Panorama is loaded and selected
as a Base Configuration)
• Export: This tab contains functionalities to generate the XML configuration or
the proper API calls. Please, refer to this tab when finishing the migration
• Diskette or Save: Take a Full Project snapshot. The Snapshot will be stored
with the date and time as a file name in the case a specific snapshot-name is
not provided. We can reload Snapshots when needed.
• Reload: This will reload the whole database.
• Warning or UNDO button: Undo the last change.
• Logout or Exit: This will exit from the current Project and direct us back to the
Main Window.

The tab presented on the top right side presents information related to Source and
Vsys/Device Group.

The First Combo, where the devices icon is displayed, identifies the Virtual System or
the Device Group that is currently selected. The next combo box shows the SOURCE
or configuration where we want to apply the changes.

Having presented the different icons and combo-boxes present in the top bar, we will
follow with a deeper description of their functionalities. First we need to import a Base
Configuration into our project to have data inside.


The Dashboard is compound by different elements, Applications Statistics, Project

Statistics, App-id Adoption (how many rules we have in App-ID instead of only ports)
and Recommended Platform.

All the information shown here is based on what we have selected from the Source
and Vsys. If we select Source equal “all” and Vsys equal “all” we will see the whole
database aggregated, but we can select only one Source and all the VSYS to see only
the statistics for that configuration only.

Application Statistics: Those counters can give you an idea about how many Rules
we need to review to improve our security policies. For instance, we can identify the
number of rules with application but without the application-default port associated in
order to reduce it.

Project Statistics: It is important to review that there are no Duplicated on Invalids

here. We can click in one of the counters to go directly to the right section.

Ex: If we click on Invalid Services the tool will redirect us to the Services Panel and it
will activate the filter “invalid” for us. All the bold indicators can be selected.


This area is used to add Connector. We have two types of Connectors right now:
1. Log Connectors (Used for App-ID and User-ID Adoption process)
2. User-ID Connectors (Used to retrieve Groups and Users from a Device)

Log Connector

When we create a Log Connector we specify to the MT3 from where we have to
retrieve the dynamic custom reports and the period of time we will use to analyze the

If we would like to retrieve the reports

from a PanOS device (firewall) we
have to import that firewall into our
Project first before using it in one Log

During the process of importing the

firewall into our project, the tool then
can read the number of VSYS this
device has in order to be able to show
them at the time to create the Log

1) Assign a Name to the new Connector.

2) Select the firewall from where we need to retrieve the Reports through the API
3) Select the VSYS from where we want to collect the logs.
4) Select the Period of time to analyze the logs.

5) Click on Save. This will automatically attach the connector with the Security

In the case we have Panorama in place and all our firewalls are sending the logs to
Panorama, is much better to retrieve the dynamic custom reports from Panorama
instead from the Firewall.

The procedure it’s a little bit different when

collecting data from Panorama. All the firewalls are
sending the logs to Panorama, therefore we need to
know from which Device-Group we should filter
the data and then we can specify the firewalls inside
each Device-Group. This let’s us be more
restrictive in selecting the logs that will be used to
generate the Reports.

1) Assign a Name to the New Connector

2) Select your Panorama (already imported to
your project in order to read the Device-Group
3) Select the Device-Group
4) Filter by firewalls inside the Device-Group
to reduce the logs used in the report generation or just select them all.
5) Click on Save. This will automatically attach the connector with the Security

User-ID Connector

The User-ID Connector will Import the Groups

and Users from one of our Devices. This will be
used to calculate the minimum number of groups
we need to add to a rule after we import the users
with the User-ID Adoption process and to be
able to use the users in new Security Rules when
we want to add a new user to a rule we can search
by our users and groups from the Security Rule
Edit Window.

When we add a new User-ID Connector we need

to replace the default name <NEW> by a new
one, then select from which Device we will
retrieve the User Group list by clicking on
“Retrieve Groups”.

By default all the Groups imported will be disabled. Enable the groups you want to
show into your migration tool.

Only the Enabled groups will be eligible to import the Users inside.

After Enabling the groups, click on “Retrieve Users” in order to import the users for
the enabled Groups. This process can take some time. A new API call will be
generated for each Group.

At the end of the process you have to Attach the User-ID Connector in the bottom
bar under your Security Rules to apply this Users and Groups to your Project.

From this moment if we open a Rule to edit, we can add a new user and type to search
a user or a group, we need to type minimum 2 characters to start the search


The Monitor tab let us review two types of logs, namely Migration Logs and Audit

The Migration Logs are generated at the importation time, or when we execute some
tasks within the tool. Some logs entries may suggest some actions to be taken, so under
the condition that you had manually fixed some of these tasks, it is possible to select
that entry and click on Fixed. The task will be shown with a strikethrough text.

We can generate PDF Reports by selecting the “Generate Report” button with the
whole list of logs from the Migration and a chart with the recommended Platform as
well like in this example:


This Tab will show us the 3 different policies that we can see and modify from the
Migration Tool 3. The security rules can be modified. The Nat Rules can be modified.
The application Override rules cannot be modified. The other kind of rules if you
are importing a configuration from a Palo Alto Networks Firewall are stored in the
database, but not shown from the GUI.

When selecting the tab Policies, the Security rules are automatically shown and the
bottom bar is updated to display only the options regarding the Security Rules. If we
select the Nat rules, the bottom bar will change as well to reflect the new options. This
behavior is implemented across all the different tabs in the Migration Tool 3.

The default Rules introduced in PanOS 7.0 are stored in the database, but are not
shown in the GUI. Those rules cannot be modified from the Migration Tool but can
be migrated from one configuration to another.

The Security Policy Editor:
The bottom bar shown when the Security Rules are selected is the following:

• The Plus button. Allows us to add a new Rule.

• The Clone button. It is possible to determine whether we want to clone the
selected rules above or below each one.
• Remove the selected rules.
• Enable the selected rules.
• Disable the selected rules.
• Run the Auto-Zone Assign Function.
• Lock the selected rules. This prevents any change in the zones by the Auto-
Zone assign function.
• Unlock selected rules. Allow to the Auto-Zone assign to change the Zones.
• Multi Edit opens the Policy Editor window and all the changes made in the
editor will be applied to all the selected rules.
• Convert to Shared Rule. Transform the rule as a SHARED rule when we are
in a Panorama configuration and migrate all the objects in the rule to the
SHARED space as well, address, services, etc.
• Combine Rules. This will combine the selected rules in only one. The
parameters for the new rule will be captured from the first selected rule (action,
log settings, negated source or destination, name, etc. All the other objects like
source, destination and applications will be combined to capture them all
without duplicates.
• Convert to PRE-Rule (Applies when the configuration is from Panorama).
• Convert to POST-Rule (Applies when the configuration is from Panorama).

• The Log Connector assignment. This is used to bind a Security Policy with a
Log Connector to retrieve App-ID and User-ID.

The Advanced Options:
By right-clicking over one Security rule a new menu will show up.

• Add to Filters: Add the selected name to the Filter’s

• Search & Replace: Open the Window to search and
check where an object is used.
• Rule Actions: Here there is another menu to Combine
the selected rules and enable or disable the properties
“Log Start” and “Log End”
• Rule Names: Options to Remove the Rule Names,
rename the empty rule names with Rule X and in case of duplicated Rule
Names fix it adding a prefix at the end.
• App-ID Adoption: All the options we need to retrieve the applications from
the logs using the Palo Alto Networks APIs. This requires a Log Connector
assigned to the Security rule.
• User-ID Adoption: All the options needed to retrieve the Users from the logs
using the Palo Alto Networks APIs. This requires a Log Connector assigned to
the Security rule.
• Replace (In Rule): We can replace inside the selected rules:
o Service Groups by the Members
o DM_INLINE by Members: This useful when we import a CISCO
ASA config where are used some groups named like DM_INLINE,
this function will replace from the services, source and destination the
groups by the members.
• 3 Party Options:
o AlgoSec: Features that will help to retrieve the Documentation fields
from AlgoSec Firewall Analyzer.
o Checkpoint: From here we can open a Checkpoint viewer for the
objects and security policies based in web.
• Add to Cron Jobs: Add the Selected Rules to one Cron Job to reduce the
scope of the reports generation to only the selected rules instead of All Rules.

Hidden Columns: We can add more columns to the Security Policy Grid by clicking on
the column headers as shown in the picture below.

Edit a Security Rule: Double Click in one Rule to Edit or select some rules and click on
“Multi Edit” to edit them all.

There are two panels collapsed by default. The first is on the left and expands by
clicking on the warning icon. The second shows up by clicking on “Next-Gen

The information panel contains warnings or errors we found in the migration process.
A warning is displayed from the Security Rules view.

Combining NAT Rules

Rules that have the same translation parameters and have the same destination
Zone can be combined. This is useful when you have some Nat rules where the
Source is different from another rule but they share the rest of the parameters for
example. The first rule selected will be the one from we will merge the others on
that position.

Policy Filters

There is a hidden Panel at the right side in the Security Rules tab called Policy Filters.
Click on that panel to show all the filtering options to assist the location of desired
Security Rules.

The first Option inside the Panel is the Filters: We can add filters to reduce the
number of Rules or search for elements inside rules to reduce the scope of the rules

The second Option is the Consolidation: Useful to search by rules that are seen
more than once based on custom parameters, like show the rules that have the same
destination and service or the same source and destination for example.

We can chain the two options, first we can filter the rules and then search by rules that
can be combined because they share

1. Select the name from the Security

Rule to add the Filter.

Filters can be created directly from the

Security Rules grid planel, via right-
click (as shown in the image on the
right), or by filling the filtering criteria

2. Select Consolidation and search rules that shared the same source and

3. Click in Case 1 to see the 2 rules. Now Select the first Rule and then select the
second rule, click in the bottom bar the button for combine and combine the 2

This is the new rule after combine that has everything from both rules, in this case
we have merged the services.

If a Filter is Active you will see it displayed with the text

“Activated” on the top bar of the Policy Filter Panel.

From the Migration Tool 3.3 and onwards, it is possible to

activate and deactivate selected Policy Filters. This can be done
by double-clicking the selected filter (to toggle the filter state) or
by clicking on the Enable and Disable buttons below. Active
Filters are marked with a green check tag.

Policy Filters can be created globally for all Vsys, or individually

for specific Vsys. The former are presented in a light blue color.
The latter are presented in black color.

To Delete the filters by selecting them and click on Clean at the

bottom bar inside the Filter’s Panel. Notice that it is possible to
Delete global filters (in which Vsys is “all”) from any selected

Notice that you may now filter by Invalid Rules, Disabled Rules, duplicated Rule
Names, Description, and some additional filtering criteria.

Combine them in order to enrich your filtering queries.

There are independent Filters for Security Rules and for Nat Rules.


From this panel we can manage the Address, Services, Applications, Regions, Tags,
Security Profiles, Users and other Objects.

On the Top Bar we have the option to Filter the Objects by a predefined set of
functions like: Invalid, Used, Unused…

We can search objects by name / IP address in the address objects but by name / port
/ protocol in the case of services.

The tab offers an Address and Address Groups bottom bar.

The objects located at the left side are related to the Address. The middle ones are
common for all the Objects and the right side objects are related to the Address

Let’s start describing the functionalities in the Common Buttons:

• The Green Balloon: This button starts the process to re-calculate all the Used
Objects. What does “Used Objects” mean in the Migration Tool 3? The tool
will search whether Objects are used in any of the following policies:

o Security Rules
o Nat Rules
o Application Override Rules

From version 3.2 onwards, the Migration Tool searches additionally in the
following areas:

o Other Rules (QoS, Pbf, Decryption, Captive Portal, DoS Protection)

o Inside the Interfaces IP address.
o Inside the zones (exclude and include lists)

The process affects as well to the groups and their members. In this case, a
search for duplicate groups will consider its members recursively, meaning that
it will inspect the content of groups inside groups.

We suggest using this functionality after applying the Search & Replace
function, in order to recalculate if the replaced objects now are Unused.

! Note Try to keep in mind that this feature is really useful when you
migrate from other vendors.

• The Red Balloon: This will remove all the Unused Objects (Address, Services
and Groups). The unused objects have the red balloon assigned like in the
picture below.

Address and Address Groups Common Buttons:

• Add a New Address. It will be placed as a first Object. Double click on it to


• Clone Address: This will clone the selected Address into the Selected

! Note If we select “shared” ad the target Vsys in which to clone the

Address object (as displayed in the image above), the objects
will be cloned and moved to the Shared. In this case, the cloned objects will
labeled with their original names. If we select to clone them into in the same
Vsys, the object will be cloned with the prefix “Cl-” at the beginning in order
to avoid name duplicates.

• Remove Selected Objects. Only Unused objects can be removed to avoid

unexpected changes in the configuration.

• Convert the Selected Address as a Shared Address. This will update all
the Rules and Groups with the new Shared Object.

! Note If you try to convert and address to shared address and the
shared address is already existing with the same name and
different value, a new object will be created. Thus, the process will result in
two shared objects with the same name but different values. Keep in mind that
this will have to be manually fixed.

• Merge: We can Merge automatically Objects by:

o Name
o Name, IP and Cidr
o IP and Cidr

To preview which objects are Duplicated, we can use the Filters first:

! Note If we want to reduce the scope of the Merge function, we can

search by any specific text in the search textbox. The Merge will
act only in the objects affected by the search. Selecting the objects via Checkbox does
not have any effect in this case. The checkboxes are only required to Remove or Clone

Specific Address Groups Buttons:

• Transform: We can do some actions within Address Groups:

o Static To Dynamic: This will convert a regular static group as a
Dynamic Address Group. The process will create a new TAG with the
group name and automatically will TAG all the members with the new
TAG. Then the group will look for objects with that given TAG. (This
is useful to transform something static into a dynamic thing, for instance
for replacing objects that contain more than 500 members).

o Fix >500 Members: There is a limitation in PanOS that does not allow
to have more than 500 members in one group. But we can nest (child)
groups within a (parent) group, letting the child groups contain 500
members each. For example if we have 600 members in GroupMain the
function will remove the 600 members and start to create groups of 500
members each until we reach the 600. As a result, we will have under the
GroupMain 2 other groups Group1 with the first 500 members and a
second group Group2 with the remaining 100, and a GroupMain with
only 2 members inside; which fulfills the PanOS requirements.

o Group To address: Using the new Filter “Groups with one member”
we can see the groups with a unique member inside. This new feature
can replace the Group by the member everywhere. We can select the
groups we want to replace or just unselect them all to apply to all the
groups that have this unique member inside.

! The same functionalities described for Address objects

apply to Services, Services Groups and Regions.

Extra Features:
Starting from the Migration Tool 3.2, it is possible to do batch modifications on
Address and Service names. For instance, it is possible to apply Prefixes and Suffixes to
their names. This functionality can be found in the Tools button presented on the top
right area.


If you want to apply the Prefix/Suffix to all the objects on a Vsys just leave the search
field empty and then select All Results. It is possible to add a prefix, a suffix or both at
the same time. If you choose Selection you have to select from the panels the objects
you want.

On the left side, we can see an example
applying both a prefix and suffix on
Address objects that satisfy the criteria of
having “Barcelona” in their name.

Keep on mind that the searches are case


Below we can see the result of applying
the Prefix and Suffix actions.

We can now do a string replace on selected Objects. First search by a pattern string,
this can be a name or IP address for the address and then replace by a new pattern.

In the example below, we show how we can transfer Address objects between
networks by replacing part of their IP addresses. Replacing “172.1.2.” in IP Address in
Objects Address to become “195.5.5.” in Selection Address can easily performed via
the Replace option and by selecting the IP Address option.


Notice that it is possible to prior delimit the batch change on a set of selected objects.
By specifying that the modifications will be applied only on objects under the
“Selection” (see the “Where?” area at the bottom of the window), we will apply the
modifications only on selected objects that also satisfy the filtering criteria. Below we
can see the result of performing such replacement.

Replace Members
It is also possible to replace specific members in multiple groups in one simple set of
steps. This does not only limit to replacement, but we can also add and remove
members following the same process.

The following example illustrates how to replace the member “host_corpdc1” for the
member “host_corpdevcamelot1” in all the Address groups where the first may be

The first step is to open the “Replace Members” window by clicking on the “Tools”
button. Once inside, we are requested to enter the name of the member we are willing
to substitute. In our case, we will type “host_corpdc1” and press the Intro key.
This will search for groups that contain the selected member. Notice that we can also
search in nested groups by selecting the “Search in Members” option.

Given the groups in which this member is

found, the tool will present a list of members
that may be candidate for substitution. On the
bottom-half part of the Replace Members
window, we will find our searched host
“host_corpdc1” together with the rest of hosts
that shared groups.

! Note Notice that you have also

the chance to modify,
not only the search host, but also some other
hosts that maybe found together in the same

Now we can double-click on the desired

members to be replaced (selecting from the
combobox that will raise up). You are also
offered to delete selected members or to add
new members to the affected groups. This can
be handful to include new members in groups to
offer equivalent privileges as a given member. In

our scenario, we took the opportunity to include the member acct_vlan into the groups
that contained the “host_corpdc1” member.

The resulting groups can later be revised filtering by the new substituting member

Add Members to a Group directly from the grid

The Migration Tool 3 allows you to dynamically add members in groups by selecting
them through the search grid and right-clicking on them. This function applies both to
Address and Service objects.


From this section, it is possible to create and modify Custom Applications, Filters and

From the Migration Tool 3.2 onwards, the tool emulates the same behavior than we
can experience in PanOS GUI while creating filters and groups and while adding
Custom Applications. It is possible to import these as Snippets as well.
Via the bottom bar, we can Merge Applications by Name, convert them as Shared and
Clone them. This applies to all the elements (including filters and groups).

Since the Migration

Tool 3.2 and
further versions, the
tool can natively
read the application
filters and groups.
This extends the
prior options of
reading the
applications’ names
and storing the xml
content. Now,
applications and
filters can be
merged, cloned and

The image on the left side shows the application of a filter to visualize a subset of

It is also possible to
convert a set of selected
applications into Shared
Applications. To do so,
select the set of
applications that you would
like to convert and click on
the “Shared” button at the
bottom, represented by a
hand holding a list.

Also, notice that you can

filter the list of applications
by Custom applications by
selecting the checkbox at
the bottom of the view.

The image on the left side
illustrates how
Applications can now be
managed in groups, the
same way you have been
doing with Address objects
and Service objects.


From the version Migration Tool 3.2, the tool includes a new “User-ID” section in
Objects. This allows visualizing relationships between groups and users. In order to
take advantage of this feature, you should create a User-Id connector and retrieve the
groups and users in advance.

This feature allows finding “Groups without Members”, as presented in the image

In the case we would select a group with user members inside (left side panel), these
will be shown on the right side panel.

From the Manage Networks Control tab on the main control bar, it is possible to
prepare physical and logical network connections, focusing on a single virtual system or
multiple virtual systems, depending on what type of Migration/Optimization project
you may be working on.

The Left tab (rotated in the image below) let us navigate between the different network

Interfaces may be created and edited. They contain all the options necessary for each
interface to operate.

You may now edit the interface names, which are inherited from imported
configuration files, to valid interface names (for instance, “ethernet1/1”), and leave
these names only to the zones to be later applied to each interface.

You may now add a sub-interface by selecting representation next to the new name
(for example, ethernet1/1.X), set a Tag, assign a Virtual Router, Virtual System and
Security Zone (if already defined), along with a full set of interface attributes.

It is also possible to rename one or all interfaces from the imported candidate
configuration. If you are planning to send the modified interfaces into the selected
device as the output, keep in mind that the renamed interfaces here must be available
on the target device, for example interfaces inside on the original configuration
renamed to “ethernet1/1”. The destination device has no interfaces yet configured.

If you have a “target” interface already configured on the “target” device you should
rename the original interface to an available interface, or remove the target interface on
the “target” device if possible.

You may rename interfaces by double-clicking them and, from the Interface Name
drop-down area, select an interface name. See the image below as an illustration in how
to rename an interface.

! Note There is another button called “remap” inside the bottom bar,
which can be used to remap all the interfaces and subinterfaces
with a single change. If we remap an Ethernet interface by the name of ae1 for
example the tool will change the media for the interface from the Ethernet to

Zones can be created, edited, or removed with the real interface names, for example,

Naming a zone, configuring its type and assigning it to one or more defined interface(s)
are part of the Zone window. The same settings from the PAN-OS devices can be
added here.

Virtual Routers can be added, edited, or removed following the same steps and
selections you would perform in a PAN-OS device.

The Virtual Router Editor allows the definition of participating interfaces, static routes,
and administrative distances.

If dynamic routing protocols are needed, you will be able to configure them on a PAN-
OS device, export the configuration to an XML file and pass the configured selection
in the Protocol tab.

Virtual Wires are also created, edited, and removed from the Virtual Wires tab.

Creating a Virtual Wire requires setting the Interface Type of the interfaces
participating in this Virtual Wire to Virtual Wire. Only then the interfaces will be
available on the Virtual Wire Editor.

VLANs can be added, edited, or removed following the same steps and selections you
would perform in a PAN-OS device.

Creating a VLAN requires that you set the Interface Type Layer 3. Only then the
interfaces will be available on the VLANs Editor.

IPSec Tunnels and Network Profiles

From the Manage Networks Profiles Control on the main control bar, it is possible to
configure your VPN and Palo Alto Networks IPSec support (IPSec Tunnels, IKE
Crypto, IKE Gateways, IPSec Crypto, GlobalProtect IPSec Crypto, Monitor and
Interface Mgmt).

IPSec Tunnels:

In order to create an IPSec Tunnel, it is required to set the Tunnel Interface, IKE
Gateways and IPSec Crypto Profile.

Network Profiles:

The Network Profiles are composed by IKE Crypto Profile, IKE Gateway Profiles,
IPSec Crypto Profiles, GlobalProtect IPSec Crypto Profile (only available from
PANOS v7 onwards), Monitor Profile and Interface Management Profile.

The process of creating an IKE Crypto Profile requires setting the related DH Group,
Encryption and Authentication. It is also required to define the related Timers:

Creating a IKE Gateway requires that you set Interface, Local IP Address, Peer IP
Type, Peer IP Address and Authentication:

In order to create an IPSec Crypto Profile, it is required to set the IPSec Protocol
(ESP or AH), DH Group, Encryption and Authentication. It is also required to define
the related Timers, and related Lifesize if applies.

Creating a GlobalProtect IPSec Crypto Profile requires that you set Encryption and
Authentication (only available from PANOS v7 onwards):

Double-clicking on a GlobalProtect IPSec
Crypto Profile entry, we can edit it as
shown in the image on the left.

In order to create a Monitor Profile, it is required to set the specific Action (Wait
Recover or Fail Over), Interval in seconds and Threshold.

Double-Clicking on a
Monitor Profile entry, we
can edit it as shown in the
image on the left.

In order to create an Interface Management Profile, it is required to select the

Permitted Services and to define the Permitted IP Address if necessary.

Use the Virtual Systems tab to add, edit, or remove virtual systems.

The Left tab (rotated in the image below) let us navigate between the different

Virtual Systems can be added, edited, or deleted.

Defining a VSYS (Virtual System) will depend on existing objects such as interfaces,
VLANs, virtual wires, virtual routers, and visible Vsys names.

Use the Virtual System Editor to create or edit new virtual system.

Use the General tab to define the participating interfaces, VLANs, virtual wires, virtual
routers, and visible virtual systems. These objects have to be previously configured on
their sections or editors. These fields are “drop-down” controls that need to be pre-
filled with the referred object in order for you to add any of these elements to a new or
existing virtual system.

The second tab allows you to add or edit Resource (limits) as you would on a regular
PAN-OS device.

Use the Response Pages tab to edit the device response pages.

Only configuration files, pre-configured devices, or base configuration files loaded into
the Palo Alto Networks Migration Tool can be edited. Any other configurations
imported into the tool won’t have any existing response pages and therefore no
information will be displayed on this tab.

You must select the file you want to work

on, once imported or loaded on the

Make sure you are working on the proper configuration file before trying to edit the
Response Pages.

You may select the pages inherited by the configuration file you brought in and use the
HTML editor to customize your pages.

On these HTML pages, besides the text and images, you must be aware of the
variables that are brought in as part of the code. For instance, if you are editing the
Certificate Error page, which has several variables, keep in mind that you are not seeing
them—they are embedded on the HTML source code. If you need to move these
variables around click on the “Source Edit” button at the top bar of the HTML editor
If you look at the HTML editor, the code exposed is the final HTML as clients will be
able to visualize the page.

Using the Source Edit button you can find the equivalent variable or XML node,
which is used to bring that information dynamically from the PAN-OS device.

<div id="content">
<h1>Certificate Error</h1>
<p>There is an issue with the SSL certificate of the
server you are trying to contact.</p>
<p><b>Certificate Name:</b> <certname> </certname></p>
<p><b>IP:</b> <url> </url></p>
<p><b>Issuer:</b> <issuer> </issuer></p>
<p><b>Status:</b> <status> </status></p>
<p><b>Reason:</b> <reason> </reason></p>

You may move these XML nodes around, but if you remove them, no
information will be presented from the page you are creating. Keep in mind that
these nodes need to be represented as: <nodename> </nodename> for the
proper XML parsing to take place.

This control was created to stage the elements you have been working on to this point,
and map the content of your Source Configuration [INPUTS], which may comprise
more than one file if needed, to your Base Configuration [OUTPUT].

2 1

4 5

6 7
8 9

The Left tab (rotated in the image below) let us navigate between the different export
options and tools.

Mappings are done based on the contents of the imported or base configuration files
imported from configured devices. If you don’t see a tree structure on the INPUTS
side of the screen, select a configuration file to use as the Source for your mappings
from command 1 (VSYS & Active Selection).

If no configuration files are set as your Base Config click Set Base Config to set one.
You can also Deactivate or Remove the selected base configuration file.

By deactivating the Source Configuration file, you won’t be able to move the elements
(the configuration you’ve already worked on in the Output.

If you remove the Source Configuration file, use the Import configuration files
command on the top menu 2 Main tabs control and import a new Source
Configuration file.

Use the API Output Manager tab to generate Atomic and Sub-Atomic API calls to
send to connected devices.

Atomic API Calls send the entire configuration generated by merging the source
configuration into the candidate configuration (OUTPUT). The Atomic calls are sent
to the connected device by “groups.” This action mimics the “load config partial”
command from the CLI configure mode. These API calls send the candidate
configuration to the targeted device, including all the address objects, address groups,
interfaces, shared log settings, NAT policies, PBF polices, shared response pages,
security policies, service objects, services groups, tags, virtual routers, virtual systems,
and zones in this order to maintain consistency through the process and to avoid
missing elements during the process. If you do not select an object group, the Palo
Alto Networks Migration Tool sends all object groups (in order) to the connected
device. If you want to send just part of the configuration, select the desired object
group and send the selected API calls.

Note: Some objects are dependent on others. For example, security policies require
that you add addresses and/or addresses groups first in order to avoid errors during
the process.

The Sub-Atomic API calls perform the same task as the Atomic selection and will be
bound to the same rules. However, instead of groups you must prepare all API calls
individually. If you do not select a specific call, the system sends all calls, one by one,
following the same group order as with Atomic calls.

We will have a more detailed description about API Calls in the next chapter.

The last tab on the left of this screen displays Device Usage. This is extremely valuable
when you are creating, migrating or optimizing the configuration on an existing device.
Based on the selected configuration you will see all the variables brought in from the
source configuration, the legacy device being migrated, or the new rules created for an
existing device in a report screen. This report will show you the recommended
platform at the bottom that would best run the candidate configuration file and it
compares this file to all Palo Alto Networks devices. Select the Platform and PAN-
OS version then click Calculate to see the candidate configuration in comparison to
the selected Platform. It will also show if you are over the default specification for each
element being used on your configuration.

This is very helpful when you need to make sure that the device you are migrating to is
capable of handling the resource consumption of the selected platform.

You may choose whether or not to deploy this configuration to the selected platform
knowing that you may have resource exhaustion if the elements are counted over the
limit for the selected platform. You may also perform an optimization and reduce the
number of elements used according to the selected (target) platform.

! Note The Palo Alto Networks Migration Tool will account 25%
more for each resource calculated giving you room to
accommodate resources more efficiently and leaving some room for the new
configuration file.

In the example above, notice that under Rules Consumption there are 295 security
rules, for the platform selected, the desired capacity is 250 rules. The System indicates
that there are 11 disabled rules and all others are enabled. With this information you
can see that the PA-200 firewall is not going to accommodate these rules, but that the
suggested VM-200 platform will.

This feature will help you resolve and avoid performance issues, and still leave room to
grow on the device.

4 Left Panel [INPUTS]

The left panel on this tab displays the file or files you imported into the Palo Alto
Networks Migration Tool, with all the modifications up to this point.

Expand the tree-based objects to see where the objects, policies, zones, virtual routers,
and virtual systems are stored.

5 Right Panel [OUTPUT]

To export the source configuration, expand the tree-based object then drag and drop
from the INPUTS panel to the OUTPUT (right side), into each correspondent sub-
node on the right panel (Base Configuration [OUTPUT]).

Expand each main Node on each side to drag and drop each part of the configuration
from the left to the right panel.

By expanding Network you can see the child nodes (Interfaces, Virtual Routers), which
contain the entire configuration changes you made on the Palo Alto Networks
Migration Tool to this point. Select it, and with the node still selected, drag and drop it
into the corresponding section in the right panel (the output).

You may have cases where you imported more than one configuration file into the
Palo Alto Networks Migration Tool and you want to bring the objects, object groups,
and services into the same destination file (OUTPUT) on the right.

From your INPUTS, Network Node drag Interfaces, Virtual Routers, and from the
vsys1 Node drag Objects, Policies, and Zones into the corresponding nodes in the

Network contains Interfaces and Virtual Routers.

Virtual systems will be numbered as they have been imported from a base
configuration file or loaded into the system by a connected device. If you are working
on Panorama configurations, a valid Device Group, and Template will be listed instead.

From your INPUTS vsys1 (or any other vsys you are working with or from a shared
child node if you are migrating from Panorama), drag Objects, and Policies, then drop
on the destination VSYS or shared Node on your OUTPUT panel.

As you may have noticed, the elements brought from the source configuration /
OUTPUT section are now “pending” actions waiting for your approval in order to
generate a final configuration file or to create the necessary API calls to send into any

connected Palo Alto Networks device. The target Palo Alto Networks devices should
be previously configured in the Palo Alto Networks Migration Tool.

6 INPUTS controls
The buttons Remove and Deactivate will allow you to remove
(or deactivate) the selected Source Configurations from the left
panel (INPUTS).
If you have multiple configuration files imported into the Palo Alto Networks
Migration Tool, you will be able to remove one or more files from the INPUTS.

Use the Set Base Config button when you have more than one
INPUT / source configuration and select the configuration to
switch to as your base.

7 OUTPUT controls
These buttons unset whichever base configuration file you
have selected in the left pane (Source Configuration /
INPUTS) and reset the object migration to the starting point giving you a chance to
restart dragging & dropping objects into the OUTPUT panel.

This allows you to go back and edit objects, policies or any elements in your source
configuration files, and return to this screen to finalize the process.

Part of the OUTPUT Controls, the MERGE button is your goal.

MERGE will run all the necessary scripts within the Palo Alto
Networks Migration Tool. MERGE will prepare the proper configuration to be either
exported to a XML file for import into a Palo Alto Networks device, or to generate
API calls to send to the connected devices within the project and imported as the
“targeted” device to receive these commands.

8 Generate XML and Set Output

Until now this would be the ultimate goal of a migration,
after all reviews and configuration changes. You would
generate an XML file to import into a Palo Alto Networks device. By using the
Generate XML Output button, your final configuration will generate the final XML
configuration file.

The Generate XML Output will create 3 files: the XML, SET commands, and a ZIP
file containing one or more copies of XML files for the selected project.

As a singular funcion button will list the file(s) generated
from the Generate XML and SET commands Output. The

files containing a ZIP with all files, a SET commands text file, and the XML with the
merged configuration file.

Starting with the Migration Tool 3.2, we now support taking Configuration Snaptshots.
This new feature will allow you to make recovery points to restore them at any
particular point in time.

To create a new Snapshot, click on the “Take a Config Snapshot” on the top bar and
proceed to label the snapshot by giving it a name.

To create and label the snapshot, click on the bottom bar button “Save Named
Configuration Snapshot”. You can assign a new name for your snapshot or select
one from the list. Mind that if you select one previously created this will be
overwritten. If you leave the name in blank the system will automatically generate
one based on the Project name and the current date time.

To recover a snapshot, simply click on “Load Named Configuration Snapshot”
from the bottom bar. Select the snapshot you want to recover and click on

Besides the Monitor Logs and Reports, where you may find detailed logs and
recommendation on actions, the new Palo Alto Networks Migration Tool 3.0 offers a
debug screen where you may take a look in-depth the tool’s logs, for debugging issues
related to your migration or to the Migration Tool 3 itself.

The Logs generated by the Web Server show the errors found on the php scripts, to
see those logs just point web browser to https://<migrationtool>/debug

Another Debug Window for the API calls has been introduced in Migration Tool 3.1
To Get access point your browser to https://<mtipaddress>/debug/api.php

The Api calls are shown in the debug window without the parameter Key to avoid to
show the API key to everyone.

The API calls are actionable (html links) so if you click in one call and add the
parameter “key=asdasdasdas” and your key you be able to see the same output that the
tool is trying to get.


The Workflow
he Palo Alto Networks Migration Tool 3 provides a simplified migration

T workflow.
In addition, the Palo Alto Networks Migration Tool 3 now also enables you to
perform configuration changes, App-ID migration, profile distribution,
response pages customization, firewall policy optimization, NAT rule creation,
and much more. Let’s divide our workflow in two primary categories:
• Migration Projects
• Optimization Projects

Migration Projects

1. Create a new project.

2. Configure a device (when possible).
3. Import the source firewall configuration file. You can import a configuration
from a PAN-OS, Cisco, Check Point, Juniper SRX, ScreenOS, Stonesoft,
Fortinet, Sidewinder or CSV file.
4. Import a clean base configuration (either from a firewall or from Panorama).
Note: If you select a configured device for your base configuration you do not
need to load a base configuration file.
5. Manage objects, services, applications, and profiles.
6. Configure and name the interfaces for the candidate configuration.
7. Manage zones, virtual routers, and virtual wires when available.
8. Manage virtual systems.
9. Prepare a final, and clean configuration to be sent to your devices, via API calls
when devices are configured or by exporting the XML.
10. Send to the device your base configuration by merging the imported
configuration from a legacy vendor, and either use API calls or regular XML

Migration in the new tool is similar to how it was done in previous versions of the
Migration Tool. Although the base task is the same, new logical workflows provide
more efficient way of handling the data from one device to another. Now you can
migrate from a single device to a single target (one to one), from multiple configuration
files to a single destination (many to one), or multiple Device Groups and Templates
on a Panorama base configuration (many to many).
For Migration projects you can now merge configurations into one or multiple virtual
systems, or simply merge the new configuration with an existing PAN-OS
configuration and optimize the duplicated objects (different name same IP address),
services, groups, split groups with more than 500 objects into a new dynamic object,
and update all the security policies and NAT rules affected. You will be able to lock a
specific rule (or a group of rules) to avoid grouped changes that affect them. You also
have the flexibility to update one, a selected group, or all security policy rules with a
new log forwarding profile or security profiles, which improves your work efficiency
and enriches the migration task.

Optimization Projects
1. Create a new Project or load an existing one.
2. Configure a device (when possible).
3. Load the offline XML or load the device configuration from the Devices tab.
4. Manage objects, services, applications, and profiles, and remove any incorrect
5. Organize the security policy and NAT rules in the most efficient way.
6. Validate all the warnings displayed on specific rules.
7. Create a Collector and associate it with a device for log reading and
App-ID creation.
8. Check for all App-IDs that have been created and analyze the unknown traffic.
If possible create new App-IDs from the unknown traffic.
9. Send your base configuration to the device by merging the imported config
(from a legacy vendor), and either use API calls or regular XML files.

Following the same basic workflow of a migration project, create an optimization

project to help you clean up the security policy, make the NAT policy more efficient,
and eliminate duplicated objects.

After completing a migration project, you can still go back and create a Collector that
will use the Devices you defined on the main Dashboard. With that in place you can
collect traffic data from up to seven days ago and use the App-ID Reconciliation
option to generate Layer 7 rules for you based on real data from the logs. For the
unknown traffic you can still analyze and generate a new App-ID for each one of

You can repeat this process as often as necessary to validate traffic and migrate rules into the next-generation firewall by
protecting your established security policies into
App-ID rules.


Sample Project – Step-by-step guide.

n this chapter we will dive into the mechanics of the Palo Alto Networks
Migration Tool. You should have all the basic information about the tool and
its components.

By now, you know what you can do with the tool; it’s time to practice with and
test the new Palo Alto Networks Migration Tool 3.

If you have downloaded the Virtual Machine for the tool you should be able to access
it via web-browser using a HTTPS connection. For instance:
as presented in the image below.

These are the requirements for this project:

1. Migrate all interfaces, except the one for management from a Cisco ASA
Version 9.1(5).
2. Migrate all ACLs and NAT Policies.
3. Clean up unused Addresses and Service objects from the legacy configuration
4. Create and apply a Security Profiles (AV, AS, Threat Prevention, and URL
5. Prepare an XML file as the candidate configuration file for PAN-OS 6.1.X
6. Connect a target device (PA-200 firewall). Analyze and optimize objects
accordant to PA-200 firewall capacity.
7. After the migration connected the to the target device as a Connector and
capture traffic related to each new Security Policy and create App-IDs for
these rules, leaving a copy of the rule above the current one for further analyze
separating unknown traffic.

Now that we have our requirements, let’s get the Cisco ASA Configuration file from
our fictitious Customer (ACME) that was named as MyCiscoConfig.txt. This was
provided by the ACME’s network security team by issuing the ‘show run’ command at

the Cisco ASA prompt and exporting the logs from the Terminal tool used to SSH
into the device (usually via Putty).

Start the tool and access it via our web browser pointing to the IP address described in
the Virtual Machine

In this case, the address is You my find your Migration Tool 3 in a
different subnet depending on your Virtual Machine’s network settings.

After read the disclaimer, click I Accept at the bottom of the screen.
You may start your new project from here. However, because we are migrating from a
Cisco ASA device from our PAN-OS PA-200 device, we will first configure a device
before we define our project.

From the Projects tab click Add New Project on the lower left bar. We could
search/filter for other existing projects from here if we have created and saved multiple
projects. The suggested search term would be the TAG name for each project, and the
recommended value for this field should be the Company’s name, in our case ACME.
After we create a new project with the name value of “MyProject” and TAG value of
ACME, let’s configure our device since we are already here and the Devices tab will
keep all devices you’ve configured.

In our requirements we learned that we would be migrating this Cisco ASA

configuration to a PA-200 device, so let’s create a connection to that device from our
Devices tab in the same screen.

You could import applications, threat signatures, URL categories, and regions from an
existing source into your project. A source here would be a pre-defined device from
the Devices tab. This would bring all these elements into your project for further
tweaking and use for creating the new configuration file.

After creating the project, click the Power icon at the top-most bar in the tool. That
will close the project (not delete it) and allow us to continue with our settings.
In this example, we will connect to a device named JOTUNHEM, with the IP address
of, using the port 443, which is the default port. If you don’t enter anything
on the Port field it will use the value of 443. Next I will select PA-200 as the model.

After a successful connection you can select the created device and check if the
connection acquired an API KEY, which will be necessary for all interaction we will
have with this device.

By clicking the Configuration, Applications, and/or Threats buttons, you will

generate an XML file containing each of these elements. The XML will be opened on a
second tab in your browser and you may download it as a file if needed. That may be
handy for later parts of the project where you want/need to create a new part of your
configuration and add it as an XML snippet on your base configuration file (Output).

! Note If you make any changes to the connected device you must
select it from the Device tab in order to reload its configuration
file and objects.
As a good practice, check for new updates from the Updates tab frequently because
the Palo Alto Networks Migration Tool 3 is a live project that is under continuous
improvement, and we strive to improve in all aspects of the tool.

After we create our project and set up our environment we are ready to select our
project by double clicking on it from the Projects tab.

Following our requirements, we should import a Cisco ASA Configuration file. Open
the Import Configuration from other vendors or from Palo Alto Networks icon
from the top bar (the second icon from left to right).

We can see our configured devices and a series of tabs for each device from where the
Palo Alto Networks Migration Tool 3 is able to import configuration.

Let’s select the Cisco tab, and from the Upload File / Configuration field. We will
browse to our local machine for the MyCiscoConfig.txt provided by ACME.

After selecting the file, notice that the Palo Alto Networks Migration Tool 3 starts the
import process automatically. During this process, the system goes through the loaded
configuration file and interprets each ACL, NAT policies (including NATs for versions
over Cisco IOS 8.3 and Cisco Twice NATs), its configured interfaces, address objects
and groups, and service objects and groups.

After the porting process is done you will see the loaded configuration file listed in the
top right drop-down with a “vsys1” in its left.

At this point the migration is done. Note that the Palo Alto Networks Migration Tool
3 is a migration tool not a translation tool.

Although most of the work has been done by the tool, professional and qualified
resources are still necessary to go over the problems inherited from the old
configuration file, or for problems introduced by the Palo Alto Networks Migration
Tool 3, such as unsupported protocols (i.e. ICMP) that need to be translated into App-
IDs manually by the person doing the migration.

After the system finishes the migration process, it loads the migrated legacy config, and
the first screen you will see is the Security Policies. Check also if the NATs were
imported correctly.

By analyzing the Secutiry Policy you will see there is a warning on rule 15. By clicking
on the rule we can see the Information tab hidden on the left side of each selected
rule, which shows what was done on that rule. In this case there are two warnings: one
being “Security RuleID [15] is using the Protocol Name [icmp]”, and the second being
“Security RuleID [15] is using a ICMP-Protocol Group [AllowedICMP].”

These two warning messages help identify potential problems. In this case, the Palo
Alto Networks Mitration Tool 3 converted the icmp group into the App-ID “icmp”
and the group is no longer being used. By converting the services from a protocol like
icmp the system will always warn you to validate if that convertion was done properly
for each rule, hence the need of a professional resource capable to identify these
changes coming from a legacy vendor to PAN-OS.

Now check the security policies and NAT policies for warning signs/icons or by going
to the Monitor Logs and Reports icon from the top most bar (the 4th icon from the

Next check Addresses and Services as well as their groups, and clean the legacy
configuration file of unused objects and groups. If you want to continue the migration
without cleaning these objects you should consider a more “like-for-like” approach,
which consists of simply migrating whatever came from the legacy configuration file.
You still need to go through warnings in order to fix inhereted mistakes or problems
from the legacy configuration.

At this point we could fix zones, multi-edit several rules or simply lock unlocked rules
to prevent other changes from affecting these selected and locked policies.

There are some new mechanisms that will help on the optimization part of the security
policy, such as Combine the selected rules into the first one where you can select
one or more rules, and combine their contents into the first rule (the top most rule).
This may be useful for projects where we have target devices with limited resources,
however you must be careful combining valid traffic such as same source, and same

Use the controls at the bottom bar (the last 3 from left to right) to prepare this
candidate configuration to be used as part of a Panorama Device Group and convert
selected rules into Pre or Post-rules.

Let’s choose to clean the object and services groups.

The objects not in use have a red bullet (icon) next to them. Clear the configuration file
by clicking on the red bullet at the bottom bar where it says “Common.” Do this for all
addresses and addresses groups, as well as for services and services groups.

When you select the Common Red icon with the Address bar selected it will remove all
unused objects for both addresses and addresses groups.

Confirm the removal for each type of objects.

Besides removing unused objects, you may also want to do some research into the
legacy configuration file and search or filter on services and addresses objects by:
Name, Invalid objects, Duplicated Names, Duplicated Names & Values, or
Duplicate Value.

This is a powerful feature that allows you to easily spot addresses and address groups
that have the same value but different names. You can then merge all duplicated
values, for instance into a single object, and then replace the security policies or NAT
policies using these duplicates with a new system-generated one for a leaner
configuration file.

After you select filter criteria, click the icon to merge the results of your filter.

You may merge by Name, by Name & IP

& CIDR, or By IP & CIDR.

These options merge the objects into one

object and update the security and NAT
policies accordingly.

On the Group Objects (right pane of

Addresses tab), you will find the same action
(merge) but with different options. You can
merge address groups by Name, by Name
& Value, or by Value (Members). That
will also update any reference of these
groups with the new one created from the
merge, for both, security and NAT policies.

Still in the Address Groups panel (right)

you will find another icon right before the
Merge icon. The Group Handler will
transform Static groups into dynamic
address groups, or will convert groups to
addresses only.

Note that as we move along you are cleaning, organizing or re-shaping the legacy
configuration file already using PAN-OS features.

The same behavior is true for the Services tab. You will also clean the unused service
objects and unused Service Groups. After that’s clean you will again start filtering by

the criteria you prefer. Usually you will filter for “Invalids” first and adjust any invalid
service objects such as services with ICMP as the protocol. Change it to TCP and later
convert it to an App-ID manually as needed.

After fixing or taking notes for posterior fixing on the invalid services search for
“Duplicate Value,” which are very common on Cisco configurations. The bottom
icons, again, will assist you with merging.
From the Service tab bottom icons on
the Services panel (left) merge the
resulting filter by Name, by Name &
Proto & Dport, or by Protocol &

Again the action is immediate and the merge will change the name of the service
objects in all securities or NAT policies if they are present.

From the Service Object Groups (right pane), merge by

Name, by Name & Value, or by Value (Members).

By this point you have already removed unused objects, and merged duplicates by your
selection criteria. At this point, we are still working on the legacy configuration file, but
operating with the PAN-OS resources.

Because we have traffic logs that are based on the ACC information captured by these
logs and registered by the Palo Alto Networks device, we need to create a “Connector”
that will be responsible for looking into the device logs for a period of time, usually
from the last 60 seconds to the last 30 days. We will select the last 7 days to meet our

! Note
Set up the collectors and check for traffic on a weekly basis to
create new App-ID rules as necessary or identify unknown

The connector will have a Name value (here MyConnector). From the drop-down field
we will select the JOTUNHEM, which is the already configured device, from which
we want to extract traffic after we migrate over the new configuration.

That may happen immediately after the cutover, or a week from now. It’s up to the
engineer in charge and the scope of the project. In our case, we were required to
migrate L3/L4 rules into App-IDs, so we will migrate the configuration and come back
for logs in order to achieve that. For now we will just create the Connector, which is an
important part of our project.

Our next step will be to configure the interfaces from the legacy configuration.

Normally when the Palo Alto Networks Migration Tool 3 migrates a Cisco
configuration, it will use their “interface” values as the Interface name, and will do the
same for the zones.

We can now remap the interfaces to existing interfaces in our target device.

Remember that, in case you would rename an interface, that name must be available in
the target devices. For greenfield projects you would not have any problems, however
if we are bringing an existing candidate configuration file into an existing PAN-OS
device, you must be mindful of the interface names to avoid duplicates and the
consequential commit fails in your target device.

In our case, we have a greenfield project and all interfaces on our Palo Alto Networks
device are empty. We will remap them to existing interfaces in our PAN-OS device and
remove the Management interface.
From the “Manage Networks, Virtual Routers, …” tab, select the first interface to
be mapped “Ethernet0/1” and click on the Remap button at the bottom bar. This will
open a new window to let you specify an interface from the exiting on your selected
PAN-OS device. From the available combo-boxes, select the slot “Slot 1” and name

After remapping all the interfaces, the configuration should contain: inside =
ethernet1/1, DMZ = ethernet1/2, outside = ethernet1/3, and the management
interface should have been deleted.

Once we have remapped the interfaces, we may double-click on them to edit their
settings. You may change all PAN-OS aspects of an interface from here; you may even
define sub-interfaces, add Tags, determine Speed / Duplex values, but for our scenario
you will simply map each interface from the legacy configuration file accordingly.

We will now move to the Zones tab. Remove the management zone because we no
longer have that interface configured. Select the zone you want to delete and use the
delete button on the lower most bar at the left side.

You may be required to select the Virtual system before deleting a Zone. Please select
the current vsys1, switching from “all” to “vsys1”.

Note that the zones are also editable from here. You may set Protection Profiles if
connected to a PAN-OS device or importing a PAN-OS configuration file, add
participating interfaces for your zoning design and other common functions to Palo
Alto Networks devices.

We have what we need for now. Let’s take a configuration snapshot at the top most
bar (third icon from right to left).

Our next steps are to start the process of generating the candidate configuration file or
sending the API calls to the connected device. We can reach the section to generate a
candidate configuration via the “Create the Output, …” button on the top bar.

As you may have noticed, there is only an INPUT file, but no OUTPUT. We must
have a base configuration file loaded or a connected device loaded in the Migration
Tool 3 in order to proceed. Go to the Import Configurations from other vendors
or Palo Alto Networks from our top most bar (second icon from left to right).

We may choose to load a “clean” PAN-OS base configuration file or double click on
the connected device (JOTUNHEM) and load its configuration into the Migration
Tool 3.

After you double-click the device or load a base configuration into your project, the
Palo Alto Networks Migration Tool 3 will import the configuration file, and take you
directly to the Manage Policies screen.

You now have two configuration files loaded into your system. Our device should be
empty and neither policies nor interfaces configured, but there will be cases where the
MERGE of configuration files will be required.

Be mindful of the interface names, virtual routers (if more than one) and policies in
general. You may merge the configuration files and bring only the objects from the
legacy into the current configuration.
You will be able to send these new elements into the current PAN-OS device via API

For now let’s use our clean device as our target migration.

At this point we have our INPUT (Cisco Configuration file), and our OUTPUT set.
However no migration has been done yet. Let’s start by dragging and dropping from
the left panel (INPUTS), each node and its child nodes to the corresponding nodes on
the right panel (OUTPUT).

! Note Make sure all child nodes were moved to the OUTPUT. Pay
attention to the zones that are part of VSYS1 in this example.

As you move the objects to the OUTPUT on our target device, all these elements will
be displayed as “(pending),” and a new configuration will be created after you click the
MERGE button in the lower right.

The MERGE function will bring all the changes made to the candidate configuration
file (Cisco ASA in this case) into the PAN-OS device.

After the MERGE is done, both panels (INPUTS & OUTPUT) will be empty.

After clicking MERGE your options are
to Generate XML & SET Output,
which will load the Downloads window
containing your merged configuration
file into PAN-OS in an XML version to
be imported, loaded, and committed
into the target PAN-OS device, a SET
commands file with all the commands in
SET format, which you may use to load
by copy and pasting (small parts at a
time) into the device while in
configuration mode, or send these
commands from a SSH connection
using a bash script for instance, and a
third file, a .ZIP file containing all the above plus all the configuration files contained
on a Panorama if that was a Panorama migration project.

The second and recommended choice would be the API Output Manager tab.

From here, you have two steps to finalize the migration. For the first step, two choices
to interact with the target device via API Calls: Atomic, or Subatomic API calls

The Atomic API calls will include all the API calls into groups ordered for you. If you
don’t click any of the groups, the system will send each group in the proper order to
the target device selected from the left drop-down (JOTUNHEM). These API calls
need to be sent in the proper order, for example objects, services before security
policies. You may select the ones you would like to send separately, and send just the
new address objects for instance.

The Subatomic API calls are generated in the same way but are more granular than
Atomic API calls. In this case, you are offered one API call for each single element
created or modified in the system, which gives you the granularity needed to send
single address objects, security policy rules, tags, or any element individually.

On both Atomic and Subatomic API calls you will find at the bottom left, a filter that
will let you select a group and search within that group for easy object manipulation
and submission to devices.

Now that we have generated our API calls (either Atomic or Subatomic) we may
proceed to Step 2. Here is where you will send all your work to the target device
(JOTUNHEM). Select the target device from the left most drop-down.

Clicking the [Step 2] Send API Requests button to enable communication with the
target device and send the API requests and receive a response from the device. If any
error occurs during this process you will receive the same error message generated at
the PAN-OS level, giving you an opportunity to correct that group when sending
Atomic calls or specific elements when sending Subatomic ones.

While submitting the API requests to the device, the expected return message from the
device is “command successful.” If this is not the message you see, you must to go
back to the element corresponding to the response error and correct it. You can then
go back to the API Output Manager tab and resubmit Steps 1 and 2 until all
elements return the “command successful” response from the target device.

Our goal is to have a clean set of API calls sent to the device with no errors.
If errors are found, that group of API requests will not be sent to your target device
and you will have a broken migration.

Now that we have fixed, prepared, and sent all our new elements via API calls to the
target device, let’s try a commit on that device.

Not what you expected right?

The reason for the main commit error is bad planning. We went through all the formal
parts, checked all the elements, and created all the objects correctly, but we forgot a
very basic concept: capacity. Up to now we could be taken by surprise in situations like
that, but with the new Palo Alto Networks Migration Tool 3 you can check the target
device’s capacity ahead of time and work around its capacity as needed or recommend
another device.

In our example, a PA-200 firewall running PAN-OS 7.1 would not support more than
250 security policies, and our Cisco ASA configuration file has 284, putting us 34 over
the device’s capacity.

Unfortunately, after we send the configuration to the device we cannot go back to the
Device Usage tab because the configuration files have been already merged.
Therefore, we will not be able to take advantage of this powerful new feature.

As a recommendation, always load both the legacy configuration file and target device
or base configuration file in the Palo Alto Networks Migration Tool 3, and select from
the platform drop-down on the top right of this screen, then select your target, or
intended target platform (hardware platform or VM-Series platform). The system will
display the “Recommended Platform” on the bottom right +25% capacity, in
comparison to your candidate configuration. The 25% extra is placed here to add some
cushion in your projects for future objects, but you should consider a proper capacity
size depending on your project and customer needs.

As for our example you can see clearly that we have a problem, which I will solve here
by simply optimizing the rulebase and trying to reduce our rule base by 40 security
policy rules. Note that, in case we did not remove unused objects, we will be running
out of address groups shortly (98 out of 125 max.). Removing unused objects can
provide some extra flexibility to our device.

Keep in mind the proper amount of resources based on your customer environment
and make sure this is the proper device for them.

Now that we optimized the rulebase and reduced the number of security policy rules
by at least 40 rules, generate the API calls and send them to the target device.
You may find some rules shadowing each other, but that will be another step on the

Check if the commit was successful.

As you can see, the policies (after proper optimization) were brought into the target
device successfully.

For validation purposes, you should check if all the elements were also brought into
the target device such as service objects, addresses, and object groups.

That would conclude your migration but you still have one requirement left: to capture
traffic from the “like for like” migration and generate App-IDs for the new security


App-ID Adoption – Step-by-step guide.

ince the Migration Tool 3.1, the App-ID Adoption process has been
enhanced and substantially enriched. One of the improvements is that now
this process can be scheduled in order to be executed when the workload of
either the firewall or Panorama is low.

Before starting with the App-ID Adoption analysis process, check that both the Date
and Time in your Migration Tool 3 are correct set up. If not, please fix them from the
Main Panel under Settings and then in System.

Our goal with the App-ID Adoption process is improve an existing and running
configuration on a Palo Alto Networks firewall if this has been defined running in
Layer4 (with services and without Applications in the Security Rules). This
improvement consists on replacing the maximum number of Services into
Applications, while verifying that the change will not result in undesirably allowing or
denying network traffic.

The Base of this process relays on the Firewall or Panorama Logs. Our Palo Alto
Networks’ Next-Gen Firewalls are classifying the traffic seen in the network based on
the seen Applications, even in the case that a running configuration has its Policy Rules
based on Services. This feature is the key to help you migrating your policies from
Services to Applications and benefits from the new opportunities it brings.

! Note This procedure applies only to Palo Alto Networks devices.

We will focus now to Migrate to Layer7 a configuration from a Firewall:

1. The first step is to import your production firewall configuration into the
Migration Tool 3.

• From the Main Panel go to

Devices and click “Add Device”
• Add a name for your Firewall,
IP-Address, port, model and
username and password (admin
rights to execute operational
commands as well).
• Click on Save and wait until the
message “The Device has been
added” shows up.
• If you cannot see this message,
please double check your IP-
address and port or open the
debug window for the API at

2. Create a new Project and assign your firewall in the source combo box. This
will create a new empty database with the same App-ID version and url
categories you have in the firewall. Click on Initialize Database.

3. Now we are in our Project we have to import the Configuration. Let’s go to

the green Tab (Import) and double click over the Firewall located under the
Device List view.

4. From the “Manage Policies” tab, select the Rules from your Security Policy
that you want to convert into Applications. After select them click on “Clone”
and select “Below”. This will create a new rule with the name “cl-“ and the
original Rule name. We have to keep these names without to change them
until we finish the whole process.

5. Time to Create the Log Connector. From the bottom bar (right side) click on
the plus button and create a new one. Assign a Name, Select the Firewall and
the Time period to analyze.

! Note It is important that the first

time we run the process we use
the longest time period possible in order to increase
the observed traffic and increase our chances to
capture all seen Applications. Use custom to select
more time.

In the case that the logs were stored in Panorama, we

need to Add Panorama first as a Device and then
attach it in the combo box where says “Uses Panorama
for Reporting?”. In this case, the API calls will be
generated against the Panorama, but the tool will use
the serial number from the selected firewall to filter
only the logs generated by the desired firewall,
discarding other firewalls on the same Device Group.

At the time to save the Log Connector, the tool will automatically assign this Log
Connector to the Security Policy. You can see in the bottom bar (right side).

6. Select the Rules from where we want to retrieve the Applications seen by our
firewall. Right click with your mouse over one Security rule to show the
Advanced Menu. Select App-ID Adoption, enter inside and select the Retrieve
Apps (Selection)

! Note With this step, we have retrieved all the applications seen by
each Rule. It is also possible to find some Unknown Traffic.
Let’s get the Unknown traffic on a separate rule.

7. From the Advanced Options menu in App-ID Adoption, select Split Rules
Known | Unknown. This will create new Rules above the Rules from where

we found unknown. We can do 2 things with the unknown, Create
Application Overrides Rules or remove it, if we remove it we will not migrate
this traffic at the end of the process. The new Rule comes with the TAG
“Unknown Traffic”

8. We want to Override one of the Unknown-tcp we have found because is our

Internal Application “app1”. Click on the Unknown-tcp Application. A new
window will show up. To Understand which are the Server where the
unknown traffic was generated click on “Analyze Unknown”. This will
generate API Calls to retrieve it from the Log Connector.

9. Select the unknown Application by the port that we want to Override. And
select the Servers you know are the ones that are hosting the “app1”. Click on
“Create App-Override Rule”. In the new window opened, assign a name for
the Application Override Rule. Then if “app1” is not defined in the tool, click

on NEW to create a new Application. Be noticed that in the Advanced tab
when we create the new application the default port has been filled
automatically. Click Save when finished. Select the “app1” from the list.
Choose between (1) to create a new Rule to manage the new App1 or (2) to
add App1 to our original Rule. Click on Add to finish

If you select the option (1) to create a new rule this will be the result:

A new Application Override has been created:

A new Security Rule has been created:

Both with the TAG “App Override”.

10. We can now select the rule with the unknown and remove it if we don’t want
to override anything else.

Let’s Work with the Rules with Known Traffic now

11. Click in one of the Applications from the Column App-ID via LOG. A new
window will open providing graphical information regarding the traffic

! Note This new Window will helps us to identify similar applications,

by technology, subcategory or by the port in the case we found
too many applications in the same rule and want to split this rules in others with less
rules inside.

The Left Panel called “Applications” shows the unique applications and when was
the first time we seen it. In this example we have only one based on Date and Time.

If we run the process “Retrieve Apps” again and we find the same applications, no
applications will be shown under the new Data Time. Only the new applications found
in this last search will be shown.

All the Charts will be recalculated as soon we start to select applications or if we start to
Filter from the Filters located at the Top.

12. Let’s create a new Rule to have only the Rules where the Subcategory is
“Software-Updates”. Filter form Subcategory and Select it. The charts will be

updated. And the Applications list as well. Select them all and click on “Create
Security Rule”

13. Assign a name for the new Rule “Software Updates” and put the Action to
Allow. Select all the Applications and click on Recommended and then click
on Add to the Rule. Click on Add and Save.

! Note The new rule has been created and added to your rule-set and
the applications have been removed from the list. So we can
continue creating new rules from the one we have retrieved the apps until the
applications that remain in the green column are the ones we want to keep in the
existing rule.

14. To finish the process click on “App-ID Reconciliation (Selection) to move all
the applications from the green column to the Applications column.

! Note In the case you have services in the rule, the Reconciliation
process will try to see if we found applications in all the ports
opened by your services. If some of those ports were not used by any of the seen
applications, a new rule with the used ports and applications will be created and the
original rule will remain with the unused ports (no applications seen through them).

Now we have to go to the red tab (Export) and generate the XML configuration file to
get the changes or use the API Output Manager to send only the new Rules, Address,
Custom Applications and Tags to our Firewall.

Let’s use the API Output Manager. Generate Atomic Calls by clicking on “[step 1]
Generate API Requests”, select the Firewall at the bottom bar, Select Address (because

we added to override the app1), Security Rules, Applications and Tags. Click on “[step
2] Send API Requests”. Check that the output from the Firewall is all “command

If you do not want to replace the whole Rule-set, we can send only the new added and
modified rules. Select SubAtomic and click on Step 1 to generate again the API calls.
In this case select the rules and the Order since the new rules by default will be
stored at the end of your current rule-set.

15. If you feel confident with the new configuration present in the firewall, click
on Commit to apply the changes.

Now we start to cover almost the 60-70% of the applications you currently use in your
network (if the time frame analyzed was long enough), but probably there is a set of

applications that we did not have a chance to analyze because they have not been used
by users yet, and no traffic has been generated to allow collecting them.

As we would like to score a 100% of adopted applications, we have to run the AppID
adoption process again. This process could be executed on a weekly frequency manner,
for instance.

Scheduling the App-ID retrieve Applications by using Cron Jobs.

From the Main Panel we can go to Settings and then click on the tab “CronJobs”.
Create a new Job “App-ID Adoption”.

Edit and fill

the form:

We can run the reports only for a selection of rules. Enter in Selected Rules and add
the ones you require.
It is also possible to add a CronJob directly from the same Rule, by right-clicking on
the rule, opening the Advanced Options and selecting the Add to CronJobs and your
Job. Click on “Save” to activate the job (Remember to setup the date and time
properly first)

We cloned the Rules at the beginning of the process and ended with the reconciliation.
Therefore, the rules that are still in layer4 are the Cloned rules. It is really important to
keep the same names until we completely finish the AppID adoption process.

When the process automatically starts, the tool collects again the reports and stores
them in the database. When you open the project again, the applications newly seen in
the layer4 rule will appear:

! Note In the example above, we see the application “ssl” running in a

non-default port in a layer4 rule. In this case, we would like to
create a new rule to allow the “ssl” on that specific port. That is because our rule is
now working with the service “application-default” and the reconciliation process will
move the new applications from the Rule called “Cl-xxx” (“CL-Outbound” in the
example) to the rule called exactly the same but without the “Cl-” (“Outbound” in the
example). Performing these steps will speed up the process of AppID identification,
but it is important to keep track of these changes and verify their correctness.

The application has been found and we want it added to our list of accepted
applications in the rule “Outbound”. We can take a look into the traffic that this
application has associated in our network by clicking in one. Enjoy having a deeper
view and understanding on the behavior these applications have in your network.

Select the SSL port, click on “Create Security Rule”, assign a name for the new rule,
allow its traffic, click on recommended and add to the rule.

Then Save the Rule and create the service port (here was tcp/5228) and assign it to the
A new rule7 “SSL on non standard port” will be created on top of the treated rule.

Last step is again to click form the Advanced Options menu to App-ID Reconciliation
(Selection) and the app will be automatically imported into the “Outbound”
rule. This action will leave the “Cl-Outbound” rule without any application, and it will
be ready to continue capturing the missing applications.

! Note After the reconciliation process, the logs from the table App-Id
via log can be removed. You can remove those logs by

selection or all by selecting them in Advanced Options menu the “Remove App-ID via

The report Generation from the Advanced Options menu only will generate reports
when you have something in the column “APP-ID via LOG”
Report Example:


User-ID Adoption – Step-by-step guide.

ince the Migration Tool 3.1, we are able to assist you in the User-ID
Adoption process. This process can be scheduled as well as the App-ID
Adoption tasks as well.

Before starting with the User-ID Adoption analysis process, check that both the Date
and Time in your Migration Tool 3 are correct set up. If not, please fix them from the
Main Panel under Settings and then in System.

Our goal with the App-ID Adoption process is improve an existing and running
configuration on a Palo Alto Networks firewall if this has been defined running
without User-ID in the Security Rules. This improvement consists on identifying the
users that have been seen in the logs and specifying them in the Security Rules, while
verifying that the change will not result in undesirably allowing or denying network

This procedure applies only to Palo Alto Networks devices.

! Note
We will focus now to Migrate our Security Rules with

1. The first step is to import your production firewall configuration into the
Migration Tool 3.

• From the Main Panel go to Devices and click “Add Device”

• Add a name for your Firewall, IP-Address, port, model and username and
password (admin rights to execute operational commands as well).
• Click on Save. After a short time you will get the confirmation the message
“The Device has been added”.

• If you cannot see this message, please double check your ip-address and
port or open the debug window for the API at

2. Create a new Project and assign your firewall in the source combo box. This
will create a new empty database with the same App-ID version and url
categories you have in the firewall. Click on “Initialize Database”.

3. From this new project, we have to import the firewall’s configuration. Let’s go
to the green Tab (Import) and double click over the Firewall located under the
Device List view.

4. Select the Rules from your Security Policy in which we would like to activate
the User-ID. After selecting the rules, click on “Clone” and select “Below”.
This will create a new set of rules with the name “Cl-“ and the original Rule
name. For instance, in the example below, the urle “Outbound” has been
cloned as “Cl-Outbound”. We have to maintain these names them until we
finish the whole process, as the names are used to define the relationships
between original and cloned rules.

5. Time to Create the Log Connector. From the bottom bar (right side), click on
the plus button and create a new one. Assign it a Name, select the Firewall
from which we will collect the logs and the Time period used for the analysis.

! Note It is important that the first time we run the process we use the
longest time period possible in order to increase the observed
traffic and increase our chances to capture all seen Users. Use custom to select more

If the logs were stored in Panorama, we need to Add

Panorama first as a Device and then attach it in the
combo box ideitified by “Uses Panorama for
Reporting?”. In this case, the API calls will be
generated against the Panorama, but the tool will use
the serial number from the selected firewall to filter
only the logs generated by the desired firewall,
discarding other firewalls on the same Device Group.

At the time to save the Log Connector, the tool will

automatically assign this Log Connector to the Security
Policy. You can see in the bottom bar (right side).

Let’s Import the Groups and Users from your firewalls by creating a new User-ID
connector. Enable the Groups we want to use from the Migration Tool 3 and then
retrieve the Users for those Groups. After
this process, attach the User-ID
connector to your Security Rules.

This process is not mandatory, but will help a lot to reduce the number of found users
and possible to replaced them by user groups. No one wants to manage a Security Rule
with 200 users inside. It is much better to work with Groups instead.

6. Select the Rules that we would like to define with User-IDs and right click in
one of them to show the Advanced Options Menu. Then click on User-ID
Adoption -> Retrieve Users (Selection)

The Users can be seen in the new column named “User-ID via LOG”.

7. Click on one of the users from the new column “User-ID via LOG” to see
deeper information. From this new window we can work with the new User-
ID information.

The Left Panel shows the list of Users seen in the logs. You can select those users
you want to use in the Rule.
The Recommended Panel will calculate, based in the selected users, the minimum
number of groups and users required that would cover users we have selected on
the left panel. We can select here the recommended Users and Groups that we
want to use in the Rule.

There is a combo-box called “Add Selection to the Rule”. In it, we will select if the
users we want to add to the Rule will be taken from the left Panel “users selection”
or the “recommended” groups and users. You have to select one of these options
before clicking on the “Add” button.

There is another option that we can use here under the caption “Export Groups
via API”. Using the same process we have followed to select the users or the
recommended users and groups, we can assign a Name to a New group click on
the refresh button. This action will generate a User-ID API call to create this group
in the Firewall (selected from the device combo-box, below the API Call section).

We can then replace in our Rule the users by the new Group created using the API
Call. We do this by selecting the checkbox “Replace Retrieved users by”. You can
keep the API Call for the future. We do not recommend using this in Production,
but at some point could be useful to create a TEMP group in our Firewall using
the APIs, while we create the final group in our Active Directory or Ldap.

Click on “Send API Call & Update Groups DB” to send the group to the selected
firewall and to add the group in our Database inside the Migration Tool 3.


Migrating Cisco ASA VPN (Lan-2-Lan)
In this chapter we will explain the process of migrating a Cisco ASA VPN
configuration to Palo Alto Networks devices. The feature of assisting in this type
of migrations has been recently introduced in the Migration Tool and the
following are the supported objects that can be migrated.

Only lan-2-lan IPSEC tunnels will be migrated.
Only tunnels with pre-shared-key will be migrated.
Pre-shared-keys from ikev2 are not read
In order to read the configuration with the Pre-shared-keys, we have to run the
command “more system:running-config” from our ASA device. This will bring the
passwords in clear.

Step 1)
Import your Base Configuration file in your new project. This will help the Migration
Tool 3.3 to identify the PAN-OS version you will use in the project, and consequently,
it will be able to perform better mappings from the ASA side to Palo Alto Networks
side. There are many aspects, such as Authentication or DHgroups, that change
between PAN-OS versions and the tool will adjust those parameters based on your
Base Configuration File (PAN-OS File).

Import your ASA configuration file.

Commands supported:

crypto isakmp enable

crypto isakmp enable
crypto ipsec transform-set
crypto ipsec security-association lifetime seconds

crypto ipsec security-association lifetime kilobytes
crypto map match address
crypto map set peer
crypto map set transform-set
crypto map set security-association lifetime
crypto map set pfs
crypto map set phase1-mode
crypto map nat-t-disable
no crypto isakmp nat-traversal
crypto ikev1 am-disable
crypto isakmp am-disable
tunnel-group [ikev1 pre-shared-key | pre-shared-key]
crypto isakmp policy
crypto ikev1 policy
crypto ikev2 policy

The Migration Tool 3.3 will automatically create the IKE Gateways and IKE Crypto
Profiles. However, it is your task to manually assign each IKE Crypto Profile to each
IKE Gateway.

The IKE Gateway name is based on the crypto map name plus the priority.

There is a new function that would allow you to select a desired list of IKE Gateways
and attach an ikev1 and/or ikev2 IKE Crypto Profile to them with only one single

The IPSEC tunnel will automatically get the proper IKE Gateway and the proper
IPSEC Crypto Profile. A new tunnel Interface will be created for each IPSEC Tunnel
and a new Zone, named like the corresponding IPSEC Tunnel, will be used on that
Tunnel Interface.

The Migration Tool 3.3 will read all the Access-lists used in the Crypto Map and the
Destination zone will be changed by the new one created.

A static route will be created for each destination address found on the Crypto Map
access-list. Also, the tool will create the PROXY-IDs inside the Tunnel following the
same approach.

The Migration Tool 3.3 will try to reduce the number of Crypto IPSec Profiles by
discarding potential duplicated ones.

Notice that the new created Zone, the IKE Gateway and the IPSEC Tunnel share the
same name. We took this decision to promote simplicity in reviewing the
configuration. You can rename everything at the same time by clicking under IPSEC
Tunnels and select the option “rename”.

First Select the Tunnel you want to rename and then select as many parameters as
you would like to be renamed (only if they keep the same name). If you select the
Zones and IKE Gateways, as shown in the image below, they will be renamed as
well. All the Rules will be updated with the new Zone name.

To easily review the Security Rules, feel free to create a filter by tag equal to
“VPN-l2l” as seen in the following image.

Always remember to check the logs in order to see if there was any error regarding
the cyphers used or anything related with this process. You may find the logs
under the logs’ Tab.

The Dashboard will show the summary for the number of tunnels created.

Device Usage will reflect as well those numbers. Also, based on the configuration
requirements, the tool will take the numbers into consideration to recommend the
most adequate platform that should be selected to satisfy the configuration.

! Note When a crypto map is defined to use ikev1 and ikev2 the tool
will only keep the ikev1 Ipsec Crypto Profile. You can change
that manually after import.

When a ipsec-proposal for ikev2 is defined the tool will only pick the first proposal.