VM-Series Deployment Guide
VM-Series Deployment Guide
Version 10.0
paloaltonetworks.com/documentation
Contact Information
Corporate Headquarters:
Palo Alto Networks
3000 Tannery Way
Santa Clara, CA 95054
www.paloaltonetworks.com/company/contact-support
Copyright
Palo Alto Networks, Inc.
www.paloaltonetworks.com
© 2020-2021 Palo Alto Networks, Inc. Palo Alto Networks is a registered trademark of Palo
Alto Networks. A list of our trademarks can be found at www.paloaltonetworks.com/company/
trademarks.html. All other marks mentioned herein may be trademarks of their respective companies.
Last Revised
March 24, 2021
iv TABLE OF CONTENTS
VM-Series Firewall for NSX-V Deployment Checklist......................................................166
Install the VMware NSX Plugin..............................................................................................169
Register the VM-Series Firewall as a Service on the NSX-V Manager......................... 169
Deploy the VM-Series Firewall.............................................................................................. 177
Create Security Groups and Steering Rules........................................................................ 185
Apply Security Policies to the VM-Series Firewall............................................................ 190
Steer Traffic from Guests that are not Running VMware Tools.................................... 194
What is Multi-NSX Manager Support on the VM-Series for NSX-V?........................... 195
Dynamically Quarantine Infected Guests............................................................................ 198
Migrate Operations-Centric Configuration to Security-Centric Configuration...........202
Add a New Host to Your NSX-V Deployment...................................................................205
Use Case: Shared Compute Infrastructure and Shared Security Policies..................... 206
Use Case: Shared Security Policies on Dedicated Compute Infrastructure................. 210
Dynamic Address Groups—Information Relay from NSX-V Manager to
Panorama..................................................................................................................................... 215
Set Up the VM-Series Firewall on VMware NSX-T (North-South)............................................ 220
Supported Deployments of the VM-Series Firewall on VMware NSX-T (North-
South)............................................................................................................................................ 220
Components of the VM-Series Firewall on NSX-T (North-South).................................220
Deploy the VM-Series Firewall on NSX-T (North-South)................................................ 221
Extend Security Policy from NSX-V to NSX-T................................................................... 232
Set Up the VM-Series Firewall on NSX-T (East-West)................................................................. 234
Components of the VM-Series Firewall on NSX-T (East-West)..................................... 234
VM-Series Firewall on NSX-T (East-West) Integration.................................................... 235
Supported Deployments of the VM-Series Firewall on VMware NSX-T (East-
West)............................................................................................................................................. 237
Deploy the VM-Series Firewall on NSX-T (East-West).................................................... 238
Extend Security Policy from NSX-V to NSX-T................................................................... 251
Use In-Place Migration to Move Your VM-Series from NSX-V to NSX-T................... 252
TABLE OF CONTENTS v
IAM Roles for HA...................................................................................................................... 320
HA Links....................................................................................................................................... 323
Heartbeat Polling and Hello Messages................................................................................ 323
Device Priority and Preemption.............................................................................................323
HA Timers....................................................................................................................................324
Configure Active/Passive HA on AWS Using a Secondary IP........................................ 324
Configure Active/Passive HA on AWS Using Interface Move....................................... 328
Migrate Active/Passive HA on AWS.................................................................................... 331
Use Case: Secure the EC2 Instances in the AWS Cloud.............................................................. 336
Use Case: Use Dynamic Address Groups to Secure New EC2 Instances within the VPC.....346
Use Case: VM-Series Firewalls as GlobalProtect Gateways on AWS........................................350
Components of the GlobalProtect Infrastructure..............................................................350
Deploy GlobalProtect Gateways on AWS...........................................................................351
VM Monitoring on AWS.......................................................................................................................353
VM Monitoring with the AWS Plugin on Panorama.........................................................354
Set Up the AWS Plugin for VM Monitoring on Panorama.............................................. 354
Auto Scaling VM-Series Firewalls with the Amazon ELB Service...............................................365
VM-Series Auto Scaling Templates for AWS Version 2.0............................................... 366
VM-Series Auto Scaling Templates for AWS Version 2.1............................................... 395
List of Attributes Monitored on the AWS VPC..............................................................................418
IAM Permissions Required for Monitoring the AWS VPC...............................................419
vi TABLE OF CONTENTS
Provision the VM-Series Firewall on a Hyper-V host with PowerShell........................ 461
Perform Initial Configuration on the VM-Series Firewall.................................................462
TABLE OF CONTENTS ix
Bootstrap Package Delivery....................................................................................................780
Bootstrap Configuration Files............................................................................................................. 782
init-cfg.txt.....................................................................................................................................782
bootstrap.xml.............................................................................................................................. 782
Generate the VM Auth Key on Panorama.......................................................................................783
Create the init-cfg.txt File.................................................................................................................... 785
init-cfg.txt File Components....................................................................................................786
Sample init-cfg.txt File..............................................................................................................788
Create the bootstrap.xml File..............................................................................................................790
Prepare the Licenses for Bootstrapping........................................................................................... 791
Prepare the Bootstrap Package.......................................................................................................... 792
Bootstrap the VM-Series Firewall on AWS..................................................................................... 794
Bootstrap the VM-Series Firewall on Azure....................................................................................798
Bootstrap the VM-Series Firewall on ESXi...................................................................................... 801
Bootstrap the VM-Series Firewall on ESXi with an ISO...................................................801
Bootstrap the VM-Series Firewall on ESXi with a Block Storage Device.....................801
Bootstrap the VM-Series Firewall on Google Cloud Platform.................................................... 803
Bootstrap the VM-Series Firewall on Hyper-V...............................................................................805
Bootstrap the VM-Series Firewall on Hyper-V with an ISO........................................... 805
Bootstrap the VM-Series Firewall on Hyper-V with a Block Storage Device..............805
Bootstrap the VM-Series Firewall on KVM..................................................................................... 807
Bootstrap the VM-Series Firewall on KVM with an ISO..................................................807
Bootstrap the VM-Series Firewall on KVM With a Block Storage Device...................807
Verify Bootstrap Completion...............................................................................................................809
Bootstrap Errors......................................................................................................................................810
x TABLE OF CONTENTS
About the VM-Series Firewall
The Palo Alto Networks VM-Series firewall is the virtualized form of the Palo Alto Networks
next-generation firewall. It is positioned for use in a virtualized or cloud environment where it
can protect and secure east-west and north-south traffic.
11
12 VM-SERIES DEPLOYMENT GUIDE | About the VM-Series Firewall
© 2021 Palo Alto Networks, Inc.
VM-Series Deployments
The VM-Series firewall can be deployed on the following platforms:
VM-Series for VMware vSphere Hypervisor (ESXi) and vCloud Air
You can deploy any VM-Series model as a guest virtual machine on VMware ESXi; ideal for cloud or
networks where virtual form factor is required.
For details, see Set Up a VM-Series Firewall on an ESXi Server and Set Up the VM-Series Firewall on
vCloud Air.
VM-Series on VMware NSX-V
The VM-100, VM-200, VM-300, VM-500, or VM-1000-HV is deployed as a network introspection
service with VMware NSX, and Panorama. This deployment is ideal for east-west traffic inspection, and
it also can secure north-south traffic.
Features/ Links Supported ESX KVM AWS NSX- NSX- Hyper-V Azure GCP OCI
V T
(N/
S)
HA2—(session synchronization and Yes Yes Yes No Yes Yes Yes Yes Yes
keepalive)
HA1 and HA2 support for the VM-Series on GCP requires PAN-OS 10.0x or later and VM-
Series plugin 2.0.5 or later.
High availability for the VM-Series firewall on NSX-T (E/W) is achieved through the NSX-T feature called
service health check. This NSX-T feature allows you to simulate high availability in the case of a service
instance failing. When configured with the VM-Series firewall, if a VM-Series service instance fails, any
traffic directed to that firewall is redirect to another firewall instance in the cluster (for service cluster
Verify the VM-Series System Requirements for your firewall model before you upgrade. If
your firewall has less than 5.5GB memory, the system capacity (number of sessions, rules,
security zones, address objects, etc) on the firewall will be limited to that of the VM-50 Lite.
To avoid impacting traffic, plan to upgrade within the outage window. Ensure the firewall
is connected to a reliable power source. A loss of power during an upgrade can make the
firewall unusable.
STEP 1 | Verify that enough hardware resources are available to the VM-Series firewall.
Refer to the VM-Series System Requirements to see the resource requirements for each VM-Series
model. Allocate additional hardware resources before continuing the upgrade process; the process for
assigning additional hardware resources differs on each hypervisor.
If the VM-Series firewall does not have the required resources for the model, it defaults to the capacity
associated with the VM-50.
STEP 2 | From the web interface, navigate to Device > Licenses and make sure you have the correct
VM-Series firewall license and that the license is activated.
On the VM-Series firewall standalone version, navigate to Device > Support and make sure that you
have activated the support license.
1. Select Device > Setup > Operations and click Export named configuration snapshot.
2. Select the XML file that contains your running configuration (for example, running-config.xml) and
click OK to export the configuration file.
3. Save the exported file to a location external to the firewall. You can use this backup to restore the
configuration if you have problems with the upgrade.
STEP 4 | If you have enabled User-ID, after you upgrade, the firewall clears the current IP address-
to-username and group mappings so that they can be repopulated with the attributes from
the User-ID sources. To estimate the time required for your environment to repopulate the
mappings, run the following CLI commands on the firewall.
• For IP address-to-username mappings:
• show user user-id-agent state all
• show user server-monitor state all
• For group mappings: show user group-mapping statistics
STEP 5 | Ensure that the firewall is running the latest content release version.
1. Select Device > Dynamic Updates and see which Applications or Applications and Threats content
release version is Currently Installed.
2. If the firewall is not running the minimum required content release version or a later version required
for PAN-OS, Check Now to retrieve a list of available updates.
3. Locate and Download the desired content release version.
After you successfully download a content update file, the link in the Action column changes from
Download to Install for that content release version.
4. Install the update.
2. Log in to the VM-Series firewall and check the dashboard to view the plugin version.
3. Select Device > Plugins to view the plugin version. Use Check Now to check for updates.
4. Select the version of the plugin and click Install in the Action column to install the plugin.
If your firewall does not have internet access from the management port, you can
download the software image from the Palo Alto Networks Customer Support Portal and
then manually Upload it to your firewall.
1. Select Device > Software and click Check Now to display the latest PAN-OS updates.
2. Locate and Download the target PAN-OS version.
At this point, the firewall clears the User-ID mappings, then connects to the User-ID
sources to repopulate the mappings.
5. If you have enabled User-ID, use the following CLI commands to verify that the firewall has
repopulated the IP address-to-username and group mappings before allowing traffic.
• show user ip-user-mapping all
• show user group list
6. If you are upgrading to an XFR release for the first time, repeat this step to upgrade to the
corresponding XFR release.
To avoid impacting traffic, plan to upgrade within the outage window. Ensure the firewalls are
connected to a reliable power source. A loss of power during an upgrade can make firewalls
unusable.
STEP 1 | Verify that enough hardware resources are available to the VM-Series firewall.
Refer to the VM-Series System Requirements to see the resource requirements for each VM-Series
model. Allocate additional hardware resources before continuing the upgrade process; the process for
assigning additional hardware resources differs on each hypervisor.
If the VM-Series firewall does not have the required resources for the model, it defaults to the capacity
associated with the VM-50.
STEP 2 | From the web interface, navigate to Device > Licenses and make sure you have the correct
VM-Series firewall license and that the license is activated.
On the VM-Series firewall standalone version, navigate to Device > Support and make sure that you
have activated the support license.
STEP 4 | If you have enabled User-ID, after you upgrade, the firewall clears the current IP address-
to-username and group mappings so that they can be repopulated with the attributes from
the User-ID sources. To estimate the time required for your environment to repopulate the
mappings, run the following CLI commands on the firewall.
• For IP address-to-username mappings:
• show user user-id-agent state all
• show user server-monitor state all
• For group mappings: show user group-mapping statistics
STEP 5 | Ensure that each firewall in the HA pair is running the latest content release version.
Refer to the release notes for the minimum content release version you must install for a PAN-OS 9.1
release. Make sure to follow the Best Practices for Application and Threat Updates.
1. Select Device > Dynamic Updates and check which Applications or Applications and Threats to
determine which update is Currently Installed.
2. If the firewalls are not running the minimum required content release version or a later version
required for the software version you are installing, Check Now to retrieve a list of available updates.
3. Locate and Download the desired content release version.
After you successfully download a content update file, the link in the Action column changes from
Download to Install for that content release version.
4. Install the update. You must install the update on both peers.
2. Log in to the VM-Series firewall and check the dashboard to view the plugin version.
3. Select Device > Plugins to view the plugin version. Use Check Now to check for updates.
4. Select the version of the plugin and click Install in the Action column to install the plugin.
When installing the plugin on VM-Series firewalls in an HA pair, install the plugin on the passive
peer before the active peer. After installing the plugin on the passive peer, it will transition to a non-
functional state. Installing the plugin on the active peer returns the passive peer to a functional state.
STEP 8 | Install the PAN-OS release on the first peer. If you are upgrading to an XFR release, install the
version that corresponds to the XFR release.
To minimize downtime in an active/passive configuration, upgrade the passive peer first. For an active/
active configuration, upgrade the secondary peer first. As a best practice, if you are using an active/
active configuration, we recommend upgrading both peers during the same maintenance window.
If you want to test that HA is functioning properly before the upgrade, consider upgrading
the active peer in an active/passive configuration first to ensure that failover occurs
without incident.
1. On the first peer, select Device > Software and click Check Now for the latest updates.
2. Locate and Download the target PAN-OS version.
If your firewall does not have internet access from the management port, you can
download the software image from the Palo Alto Networks Support Portal and then
manually Upload it to your firewall.
3. After you download the image (or, for a manual upgrade, after you upload the image), Install the
image.
4. After the installation completes successfully, reboot using one of the following methods:
• If you are prompted to reboot, click Yes.
• If you are not prompted to reboot, select Device > Setup > Operations and Reboot Device.
5. After the device finishes rebooting, view the High Availability widget on the Dashboard and
verify that the device you just upgraded is still the passive or active-secondary peer in the HA
configuration.
STEP 9 | Install the PAN-OS release on the second peer. If you are upgrading to an XFR release, install
the version that corresponds to the XFR release.
1. (Active/passive configurations only) Suspend the active peer so that HA fails over to the peer you
just upgraded.
1. On the active peer, select Device > High Availability > Operational Commands and click Suspend
local device.
2. View the High Availability widget on the Dashboard and verify that the state changes to Passive.
3. On the other peer, verify that it is active and is passing traffic (Monitor > Session Browser).
2. On the second peer, select Device > Software and click Check Now for the latest updates.
3. Locate and Download the target PAN-OS version.
4. After you download the image, Install it.
5. After the installation completes successfully, reboot using one of the following methods:
• If you are prompted to reboot, click Yes.
• If you are not prompted to reboot, select Device > Setup > Operations and Reboot Device.
6. (Active/passive configurations only) From the CLI of the peer you just upgraded, run the following
command to make the firewall functional again:
request high-availability state functional
If you enabled HA2 keep-alive, the hardware interface counters on the passive
peer will show both transmit and receive packets. This occurs because HA2
keep-alive is bi-directional, which means that both peers transmit HA2 keep-alive
packets.
• In an active/active configuration, you will see packets received and packets transmitted on both
peers.
If Panorama is unable to connect directly to the update server, follow the procedure for
deploying updates to firewalls when Panorama is not internet-connected so that you can
manually download images to Panorama and then distribute the images to firewalls.
STEP 1 | After upgrading Panorama, commit and push the configuration to the firewalls you are planning
to upgrade.
STEP 3 | From the web interface, navigate to Device > Licenses and make sure you have the correct
VM-Series firewall license and that the license is activated.
On the VM-Series firewall standalone version, navigate to Device > Support and make sure that you
have activated the support license.
STEP 4 | Save a backup of the current configuration file on each managed firewall you plan to upgrade.
1. From the Panorama web interface, select Panorama > Setup > Operations and click Export
Panorama and devices config bundle to generate and export the latest configuration backup of
Panorama and of each managed appliance.
2. Save the exported file to a location external to the firewall. You can use this backup to restore the
configuration if you have problems with the upgrade.
STEP 5 | Update the content release version on the firewalls you plan to upgrade.
Refer to the Release Notes for the minimum content release version required for PAN-OS 9.1. Make
sure to follow the Best Practices for Application and Threat Updates when deploying content updates to
Panorama and managed firewalls.
1. Select Panorama > Device Deployment > Dynamic Updates and Check Now for the latest updates. If
an update is available, the Action column displays a Download link.
2. If not already installed, Download the latest content release version.
3. Click Install, select the firewalls on which you want to install the update, and click OK. If you are
upgrading HA firewalls, you must update content on both peers.
STEP 6 | (HA firewall upgrades only) If you will be upgrading firewalls that are part of an HA pair, disable
preemption. You need only disable this setting on one firewall in each HA pair.
1. Select Device > High Availability and edit the Election Settings.
2. If enabled, disable (clear) the Preemptive setting and click OK.
3. Commit your change. Make sure the commit is successful before you proceed with the upgrade.
STEP 9 | (HA firewall upgrades only) Upgrade the second HA peer in each HA pair.
1. (Active/passive upgrades only) Suspend the active device in each active/passive pair you are
upgrading.
1. Switch context to the active firewall.
2. In the High Availability widget on the Dashboard, verify that Local firewall state is Active and the
Peer is Passive).
3. Select Device > High Availability > Operational Commands > Suspend local device.
4. Go back to the High Availability widget on the Dashboard and verify that Local changed to
Passive and Peer changed to Active.
2. Go back to the Panorama context and select Panorama > Device Deployment > Software.
3. Click Install in the Action column that corresponds to the firewall models of the HA pairs you are
upgrading.
4. In the Deploy Software file dialog, select all firewalls that you want to upgrade. This time, select only
the peers of the HA firewalls you just upgraded.
5. Make sure Group HA Peers is not selected.
6. Select Reboot device after install.
7. To begin the upgrade, click OK.
8. After the installation completes successfully, reboot using one of the following methods:
• If you are prompted to reboot, click Yes.
• If you are not prompted to reboot, select Device > Setup > Operations and Reboot Device.
9. (Active/passive upgrades only) From the CLI of the peer you just upgraded, run the following
command to make the firewall functional again:
request high-availability state functional
STEP 10 | (PAN-OS XFR upgrade only) Upgrade the first peer and second peer to PAN-OS XFR by
repeating Step 8 and Step 9.
STEP 11 | Verify the software and content release version running on each managed firewall.
1. On Panorama, select Panorama > Managed Devices.
2. Locate the firewalls and review the content and software versions in the table.
For HA firewalls, you can also verify that the HA Status of each peer is as expected.
STEP 12 | (HA firewall upgrades only) If you disabled preemption on one of your HA firewalls before
you upgraded, then edit the Election Settings (Device > High Availability) and re-enable the
Preemptive setting for that firewall and then Commit the change.
STEP 3 | Save a backup of the current configuration file on each managed firewall that you plan to
upgrade.
Although the firewall will automatically create a backup of the configuration, it is a best
practice to create a backup prior to upgrade and store it externally.
1. Select Device > Setup > Operations and click Export Panorama and devices config bundle. This
option is used to manually generate and export the latest version of the configuration backup of
Panorama and of each managed device.
2. Save the exported file to a location external to the firewall. You can use this backup to restore the
configuration if you have problems with the upgrade.
STEP 4 | Check the Release Notes to verify the Content Release version required for the PAN-OS
version.
The firewalls you plan to upgrade must be running the Content Release version required for the PAN-OS
version.
1. Select Panorama > Device Deployment > Dynamic Updates.
2. Check for the latest updates. Click Check Now (located in the lower left-hand corner of the window)
to check for the latest updates. The link in the Action column indicates whether an update is
available. If a version is available, the Download link displays.
3. Click Download to download a selected version. After successful download, the link in the Action
column changes from Download to Install.
4. Click Install and select the devices on which you want to install the update. When the installation
completes, a check mark displays in the Currently Installed column.
If your firewalls are configured in HA, make sure to clear the Group HA Peers check box
and upgrade one HA peer at a time.
STEP 6 | Verify the software and Content Release version running on each managed device.
1. Select Panorama > Managed Devices.
2. Locate the device(s) and review the content and software versions on the table.
STEP 2 | Save a backup of the current configuration file on each managed firewall that you plan to
upgrade.
Although the firewall will automatically create a backup of the configuration, it is a best
practice to create a backup prior to upgrade and store it externally.
1. Select Device > Setup > Operations and click Export Panorama and devices config bundle. This
option is used to manually generate and export the latest version of the configuration backup of
Panorama and of each managed device.
2. Save the exported file to a location external to the firewall. You can use this backup to restore the
configuration if you have problems with the upgrade.
STEP 3 | Check the Release Notes to verify the Content Release version required for the PAN-OS
version.
The firewalls you plan to upgrade must be running the Content Release version required for the PAN-OS
version.
1. Select Panorama > Device Deployment > Dynamic Updates.
2. Check for the latest updates. Click Check Now (located in the lower left-hand corner of the window)
to check for the latest updates. The link in the Action column indicates whether an update is
available. If a version is available, the Download link displays.
3. Click Download to download a selected version. After successful download, the link in the Action
column changes from Download to Install.
4. Click Install and select the devices on which you want to install the update. When the installation
completes, a check mark displays in the Currently Installed column.
STEP 4 | Download the PAN-OS image to all VM-Series firewalls in the cluster.
1. Login to Panorama.
2. Select Panorama > Device Deployment > Software.
3. Click Refresh to view the latest software release and also review the Release Notes to view a
description of the changes in a release and to view the migration path to install the software.
4. Click Download to retrieve the software then click Install.
Do not reboot the VM-Series firewalls after installing the new software image.
STEP 5 | Upgrade the VM-Series firewall on the first ESXi host in the cluster.
1. Login to vCenter.
2. Select Hosts and Clusters.
3. Right-click the host and select Maintenance Mode > Enter Maintenance Mode.
4. Migrate (automatically or manually) all VMs, except the VM-Series firewall, off of the host.
5. Power off the VM-Series firewall. This should happen automatically upon entering maintenance
mode on the host.
6. (Optional) Assign additional CPUs or memory to the VM-Series firewall before continuing with the
upgrade process.
Verify that enough hardware resources are available to the VM-Series firewall. Refer to the VM-
Series System Requirements to see the new resource requirements for each VM-Series model.
7. Right-click the host and select Maintenance Mode > Exit Maintenance Mode. Exiting maintenance
mode causes the NSX ESX Agent Manager (EAM) to power on the VM-Series firewall. The firewall
reboots with the new PAN-OS version.
8. Migrate (automatically or manually) all VMs back to the original host.
STEP 6 | Repeat this process for each VM-Series firewall on each ESXi host.
STEP 7 | Verify the software and Content Release version running on each managed device.
1. Select Panorama > Managed Devices.
2. Locate the device(s) and review the content and software versions on the table.
STEP 2 | Retrieve the license deactivation API key from the Customer Support Portal.
1. Log in to the Customer Support Portal.
2. From the Go To drop-down, select License API.
3. Copy the API key.
Make sure that you are using the same account that you used to register the initial
license.
STEP 3 | On the firewall, use the CLI to install the API key copied in the previous step.
request license api-key set key <key>
STEP 4 | Enable the firewall to Verify Update Server identity on Device > Setup > Service.
STEP 5 | Commit your changes. Ensure that you have a locally-configured user on the firewall.
Panorama pushed users might not be available after the deactivation if the configuration
exceeds the non-licensed PA-VM objects limit.
Verify the VM-Series System Requirements for your firewall model before you upgrade. If
your firewall has less than 5.5GB memory, the capacity (number of sessions, rules, security
zones, address objects, etc) on the firewall will be limited to that of the VM-50 Lite.
This process is similar to that of upgrading a pair of hardware-based firewalls that are in an HA
configuration. During the capacity upgrade process, session synchronization continues, if you have it
enabled. To avoid downtime when upgrading firewalls that are in a high availability (HA) configuration,
update one HA peer at a time.
Do not make configuration change to the firewalls during the upgrade process. During the
upgrade process, configuration sync is automatically disabled when a capacity mismatch is
detected and is then re-enabled when both HA peers have matching capacity licenses.
If the firewalls in the HA pair have different major software versions (such as 9.1 and 9.0)
and different capacities, both devices will enter the Suspended HA state. Therefore, it is
recommended that you make sure both firewalls are running the same version of PAN-OS
before upgrading capacity.
The VM-Series plugin does not manage capabilities that are common to both VM-Series
firewalls and hardware-based firewalls. For example, VM Monitoring is not part of the VM-
Series plugin because it is a core PAN-OS feature that helps you enforce policy consistently
on your virtual machine workloads from both VM-Series firewalls and hardware-based
firewalls.
The VM-Series plugin does not manage Panorama plugins. For the difference between the
VM-Series plugin and Panorama plugins, see VM-Series Plugin and Panorama Plugins.
The VM-Series plugin is a built-in component that can be upgraded or downgraded, but not removed. Each
PAN-OS release includes a specific VM-Series plugin version that corresponds to the PAN-OS software
version. When you downgrade to an earlier PAN-OS software version, the plugin version is downgraded
to the version compatible with the PAN-OS version. You can upgrade or downgrade the VM-Series plugin
locally on the virtual firewall, or manage the plugin version centrally from Panorama.
To enable Panorama to manage the VM-Series plugin version itself, or cloud-specific metrics publishing
your managed firewalls, you must manually install the VM-Series plugin on Panorama as described in
Panorama Plugins.
• Configure the VM-Series Plugin on the Firewall
• Upgrade the VM-Series Plugin
STEP 1 | Before upgrading, check the latest Release Notes for details on whether a new VM-Series
plugin affects your environment.
For example, suppose a new VM-Series plugin version only includes AWS features. To take advantage of
the new features, you must update the plugin on your VM-Series firewall instances on AWS.
STEP 2 | Log in to the VM-Series firewall and check the dashboard to view the plugin version.
STEP 5 | When the download finishes, click Install in the Actions column.
The firewall automatically uninstalls the previously installed version of the plugin.
STEP 6 | View the Dashboard to verify that the plugin upgraded successfully.
VM-Series firewall instances deployed with multiple NUMA nodes, come up in packet MMAP
mode when jumbo frame support is enabled. You must disable jumbo frame support to use
DPDK on VM-Series firewall instance deployed with multiple NUMA nodes.
STEP 1 | Enable jumbo frames and set a default global MTU value.
1. Select Device > Setup > Session and edit the Session Settings section.
2. Select Enable Jumbo Frame.
3. Enter a value for Global MTU.
The default value is 9192. The range of acceptable values is: 512 - 9216.
4. Click OK.
A message is displayed that informs you that enabling or disabling Jumbo Frame mode requires a
reboot and that Layer 3 interfaces inherit the Global MTU value.
5. Click Yes.
A message is displayed to inform you that Jumbo Frame support has been enabled and reminds you
that a device reboot is required for this change to be activated.
6. Click OK.
7. Click Commit.
STEP 2 | Set the MTU value for a Layer 3 interface and reboot the firewall.
The value set for the interface overrides the global MTU value.
There is no option to enable or disable the use of hypervisor assigned MAC addresses on
AWS and Azure. It is enabled by default for both platforms and cannot be disabled.
If you are deploying the VM-Series firewall in Layer 2, virtual wire, or tap interface modes, you must enable
promiscuous mode on the virtual switch to which the firewall is connected. The use of hypervisor assigned
MAC address is only relevant for Layer 3 deployments where the firewall is typically the default gateway for
the guest virtual machines.
When hypervisor assigned MAC address functionality is enabled on the VM-Series firewall, make note of
the following requirements:
• IPv6 Address on an Interface—In an active/passive HA configuration (see VM-Series in High
Availability), Layer 3 interfaces using IPv6 addresses must not use the EUI-64 generated address as the
interface identifier (Interface ID). Because the EUI-64 uses the 48-bit MAC address of the interface to
derive the IPv6 address for the interface, the IP address is not static. This results in a change in the IP
address for the HA peer when the hardware hosting the VM-Series firewall changes on failover, and
leads to an HA failure.
• Lease on an IP Address—When the MAC address changes, DHCP client, DHCP relay and PPPoE
interfaces might release the IP address because the original IP address lease could terminate.
• MAC address and Gratuitous ARP—VM-Series firewalls with hypervisor assigned MAC addresses in a
high-availability configuration behave differently than the hardware appliances with respect to MAC
addressing. Hardware firewalls use self-generated floating MAC addresses between devices in an HA
pair, and the unique MAC address used on each dataplane interface (say eth 1/1) is replaced with a
virtual MAC address that is common to the dataplane interface on both HA peers. When you enable the
use of the hypervisor assigned MAC address on the VM-Series firewall in HA, the virtual MAC address is
not used. The dataplane interface on each HA peer is unique and as specified by the hypervisor.
Because each dataplane interface has a unique MAC address, when a failover occurs, the now active
VM-Series firewall must send a gratuitous ARP so that neighboring devices can learn the updated MAC/
IP address pairing. Hence, to enable a stateful failover, the internetworking devices must not block or
ignore gratuitous ARPs; make sure to disable the anti-ARP poisoning feature on the internetworking
devices, if required.
Perform the following steps to configure the VM-Series firewall to use the interface MAC addresses
provided by the host/hypervisor.
STEP 2 | Disable (clear) the option to Use Hypervisor Assigned MAC Address.
When the MAC address change occurs, the firewall generates a system log to record this transition and
the interface generates a gratuitous ARP.
Metric Description
Dataplane CPU Utilization (%) Monitors dataplane CPU usage and measures the traffic load on
the firewall.
Dataplane Packet Buffer Utilization Monitors dataplane buffer usage and measures buffer utilization.
(%) If you have a sudden burst in traffic, monitoring your buffer
utilization allows you to ensure that the firewall does not deplete
the dataplane buffer, which results in dropped packets.
GlobalProtect Gateway Tunnel Monitors the active GlobalProtect tunnels on a gateway and
Utilization (%) measures tunnel utilization. Use this metric if you use this VM-
Series firewall as a VPN gateway to secure remote users.
Sessions Active Monitors the total number of sessions that are active on the
firewall. An active session is a session that is in the flow lookup
table for which packets will be inspected and forwarded, as
required by policy.
Session Utilization (%) Monitors the TCP, UDP, ICMP and SSL sessions that are
currently active and the packet rate, new connection establish
rate, and firewall throughput to determine session utilization.
SSLProxyUtilization (%) Monitors the percentage of SSL forward proxy sessions with
clients for SSL/TLS decryption.
Bootstrapping from a cloud storage location Management interface only, including when interfaces
such as AWS S3 bucket, Azure storage file are swapped
service, or Google storage bucket
If your bootstrap.xml file includes
license authcodes, you cannot use a
service route. To license the firewall,
the management interface must be
used.
Publishing PAN-OS metrics to a cloud Management interface only, including when interfaces
monitoring service such as AWS CloudWatch, are swapped
Azure Application Insights or Google
Stackdriver
SR-IOV
Why use SR-IOV? SR-IOV is a packet acceleration technology that allows a virtual machine to directly
access packets from the NIC. In contrast, when using a virtual switch, the host processes the packets, send
the packets through a virtual switch, and then the virtual machine receives its packets.
In the Compatibility Matrix, PacketMMAP Driver Versions lists both the host version and the native
driver version on the VM-Series firewall. For example, i40e on the host, and on the firewall, i40e (for PCI-
passthrough) and i40evf (for SR-IOV).
For SR-IOV, let's consider a NIC that uses the i40e PF driver. The host communicates with the NIC via the
i40e driver. The VM-Series firewall can use its VF driver (i40evf) to directly communicate with the host's
PF driver. This allows VM-Series firewall direct access, which improves packet processing speed. To ensure
compatibility, install a host PF driver version that is later than the native PF driver version.
DPDK
PAN-OS has two packet processing modes—DPDK (default) and MMAP—and each mode has a
corresponding native driver on the VM-Series firewall. For example, if the firewall is in DPDK mode, the
firewall uses the DPDK i40evf driver version to communicate with the host's i40e driver (when using
SR-IOV). Alternatively, when the firewall is Packet MMAP, it will use a different i40evf driver version to
communicate with the host's i40e driver.
You can enable DPDK on the host (the hypervisor), or on the guest (the VM-Series firewall). Enabling both
yields the best results.
• Compiling OVS with DPDK is part of enabling DPDK on the host.
Refer to Configure OVS and DPDK on the Host.
• VM-Series DPDK enables the native DPDK driver on the VM-Series firewall, so DPDK does not need to
be enabled on the host, but it is recommended for best performance.
45
46 VM-SERIES DEPLOYMENT GUIDE | License the VM-Series Firewall
© 2021 Palo Alto Networks, Inc.
VM-Series Firewall Licensing
Palo Alto Networks currently supports two consumption models: Bring Your Own License (BYOL) and
PAYG (Pay-As-You-Go, also called PayGo).
BYOL PAYG
Software NGFW Credits—Available on all PAN-OS releases. Purchased from a public cloud
PAN-OS 10.0.4 and later versions offer advanced features marketplace (such as AWS, Azure,
and more flexibility. or GCP), or a Cloud Security Service
Provider (CSSP).
The cost for a VM-Series firewall is based on the number of
vCPUs, the security services you have enabled, and whether Available on the PAN-OS version your
you choose to provision Panorama to manage the firewall or provider supports.
act as a log collector.
See Software NGFW Credits for a detailed explanation.
What is the difference between the BYOL Software NGFW credits and VM-Series Model license types?
The following tables provide a quick comparison, and links to greater details.
Here is a quick overview of Software NGFW Credits characteristics.
PAN-OS version Available for all PAN-OS releases. With advanced and more flexible consumption
options from PAN-OS 10.0.4 and later
Default Credit When you purchase the VM-Series or CN-Series firewall, activating your credits
Pools creates a credit pool.
Description The most flexible BYOL offering, Software Next Generation Firewall credits let
you consume Palo Alto Networks firewall-as-a-platform components: VM-Series,
CN-Series, Security Services, Virtual Panorama for Management or Dedicated Log
Collection, and a support entitlement.
Cost is based on the number of vCPUs.
Deployment You create a deployment profile for a specific environment or use case (such as
“AWS Deployment of VM-Series”, “Protect my NSX Environment”) and configure
firewall vCPUs, security services, and VM Panorama. You can create any number
of deployment profiles and customize them at any point in time.To create a
deployment profile, you allocate credits from your credit pool.
Must have the CSP role Credit Administrator to activate and manage Software
NGFW credits.
Security services Threat Prevention, DNS Security, GlobalProtect, WildFire, URL Filtering, SD-
WAN, DLP, and other services as they become available.
You can choose any combination of security services in your Deployment Profile,
and you can add or remove security services from your profile at any time.
Upgrade or if the VM-Series firewall has an internet connection, changes to your deployment
Downgrade profile are automatically applied.
If the firewall does not have an internet connection, you must manually stop the
VM, upload the new deployment profile, and restart the VM.
You do not have to reboot the firewall in either case.
CN-Series Like the VM-Series firewall, the CN-Series licensing differs depending on the
Software NGFW PAN-OS version. See the CN-Series Deployment Guide.
Credits Licensing
1. Create a Support Account
Checklist
2. Activate Credits
3. Create a Deployment Profile (CN-Series)
4. Deploy the CN-Series Firewalls
5. Register the CN-Series Firewall (Software NGFW Credits)
6. Install a Device Certificate on the VM-Series Firewall (for site licenses such as
Cortex Data Lake and Auto Focus.)
See the following table to compare VM-Series Model license characteristics with Software NGFW credits
vCPU-based firewalls.
VM-Series Model
Description The VM-Series model perpetual license (capacity only), or term-based capacity
and security subscriptions. You must estimate your needs and design your
configuration before your purchase. Cost is based on the VM-Series model, device
memory, and storage.
Deployment The VM-Series Enterprise License Agreement (Multi-Model ELA) capacity license,
support entitlement, and security bundles are allocated from a token pool.
Must have the CSP role ELA Administrator.
CN-Series Model Like the VM-Series firewall, the CN-Series licensing differs depending on the
Licensing Checklist PAN-OS version. See the CN-Series Deployment Guide.
1. Create a Support Account
2. Activate Credits
3. Create a Deployment Profile (CN-Series)
4. Deploy the CN-Series Firewalls
5. Register the CN-Series Firewall (Software NGFW Credits)
6. Install a Device Certificate on the VM-Series Firewall (for site licenses such as
Cortex Data Lake and Auto Focus.)
STEP 1 | Go to https://support.paloaltonetworks.com/UserAccount/PreRegister.
STEP 2 | Enter the corporate email address to associate with the support account.
STEP 3 | Choose one of the following options and fill in the details in the user registration form:
For a usage-based license in AWS
1. Click Register your Amazon Web Services VM-Series Instance.
2. On the AWS Management Console, find the AWS Instance ID, AWS Product Code, and the AWS
Zone in which you deployed the firewall.
3. Fill in the other details.
For all other licenses
1. Click Register device using Serial Number or Authorization Code.
2. Enter the capacity auth code and the sales order number or customer ID.
3. Fill in the other details.
STEP 4 | Submit the form. You will receive an email with a link to activate your user account.
Complete the steps to activate the account. After your account is verified and the registration is
complete, you can log in to the support portal.
6.5GB AWS, Azure, ESXi, Google Cloud Platform, Hyper-V, KVM, NSX-V, OCI, 60GB
Alibaba Cloud, Cisco ACI, Cisco CSP, Cisco ENCS, NSX-T
9GB AWS, Azure, ESXi, Google Cloud Platform, Hyper-V, KVM, NSX-V, OCI, 60GB
Alibaba Cloud, Cisco ACI, Cisco CSP, Cisco ENCS, NSX-T
16GB AWS, Azure, ESXi, Google Cloud Platform, Hyper-V, KVM, NSX-V, OCI, 60GB
Alibaba Cloud, Cisco ACI, Cisco CSP, NSX-T
56GB AWS, Azure, ESXi, Google Cloud Platform, Hyper-V, KVM, OCI, Alibaba 60GB
Cloud, Cisco ACI, Cisco CSP, NSX-T
For all memory profiles listed above, the minimum vCPUs is 2. You can enable Lite mode if you choose
4.5GB. Lite mode is an alternative operating mode for environments where resources are limited. See Lite
Mode for more information.
Lite mode requires minimum 32GB of hard drive space. However, because the VM-Series
base image is common for all vCPU combinations, you must allocate 60GB of hard drive
space until you license a VM-Series firewall with 4.5GB memory.
The number of vCPUs assigned to the management plane and those assigned to the dataplane differs
depending on the total number of vCPUs assigned to the VM-Series firewall. Refer to the following table
to find out the number of data plane vCPUs allocated for a given combination of memory profile and total
vCPUs.
4.5GB 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1
5.5GB 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1
6.5GB 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1
9GB 1 1 2 2 2 2 2 2 2 2 2 2 2 2 2
16GB 1 1 2 2 2 2 6 6 6 6 6 6 6 6 6
56GB 1 1 2 2 2 2 6 6 6 6 6 6 6 6 12
The following table shows the firewall capacity for each memory profile. Unlike VM-series models, Software
NGFW Credits from PAN-OS 10.0.4 onwards allows you to choose the memory profile that best fits your
environment without consuming any additional credits.
• Activate Credits
• Transfer Credits
• Create a Deployment Profile (VM-Series),Create a Deployment Profile (CN-Series)
• Edit a Deployment Profile
• Clone a Deployment Profile
• Provision Panorama
• Deactivate a Firewall
Activate Credits
Within your organization you can create many accounts, each with a different purpose. During activation
you can choose only one account per default credit pool. Once you the credit pool is active, users granted
the credit administrator role can allocate the credits for deployments, and even transfer credits to other
pools.
If you have an existing CSP account and are a superuser or an admin, the system automatically adds the
credit admin role to your profile. If you do not have an existing account, the CSP automatically creates an
account for you and adds the credit admin role to your profile.
You (the purchaser) receive an email detailing the subscription, the credit pool ID, the subscription start and
end date, the amount of credits purchased, and the description of the default credit pool (see “default credit
pools” in VM-Series Firewall Licensing).
STEP 1 | In the email, click Start Activation to view your available credit pools.
STEP 2 | Select the credit pool you want to activate. You can use the search field to filter your account
list by number or name.
If you have purchased multiple credit pools (see Software NGFW Credits), both of them are
automatically selected. The check marks represent activation links for onboarding credits.
You are prompted to authenticate or sign in.
If you deselect a credit pool, you see a reminder that if you want to activate those credits,
you must return to the email and click the Start Activation link.
STEP 4 | Select the support account (you can search by account number or name).
STEP 7 | (optional) If this is your first credit activation, you see the Create Deployment Profile dialog.
Continue to Create a Deployment Profile (VM-Series) or Create a Deployment Profile (CN-Series).
Transfer Credits
You can transfer credits to a credit pool in the same account, or to a credit pool in a different account that
you can access.
• Different CSP Account
• Different Pool in this Account
STEP 3 | Go to the source credit pool and click Transfer Credits on the bottom left.
STEP 3 | Go to the source credit pool and select Transfer Credits on the bottom left.
STEP 1 | If you already have credit pool, log into the account, and from the dashboard, select Assets >
Software NGFW Credits > Create New Profile.
If you have just activated a credit pool you see the Create Deployment Profile form.
STEP 3 | (optional) Hover over the question mark following Protect more, save more to see how your
credit allocation affects savings.
STEP 4 | Click Calculate Estimated Cost to view the credit total, and the number of credits available
before the deployment.
(optional) Hover over the question mark following the estimate to view the credit breakdown for each
component.
STEP 1 | If you already have credit pool, log into the account, and from the dashboard, select Assets >
Software NGFW Credits > Create New Profile.
If you have just activated a credit pool you see the Create Deployment Profile form.
1. Select the CN-Series firewall type.
2. Select the PAN-OS version.
STEP 3 | (optional) Hover over the question mark following Protect more, save more to see how your
credit allocation affects savings.
STEP 4 | Click Calculate Estimated Cost to view the credit total, and the number of credits available
before the deployment.
(optional) Hover over the question mark following the estimate to view the credit breakdown for each
component.
STEP 2 | On the far right, select the vertical ellipsis (More Options) and select Edit Profile.
STEP 2 | On the far right, select the vertical ellipsis (More Options) and select Clone Profile.
STEP 3 | Change the profile name, make any other changes, and select Create Deployment Profile.
Provision Panorama
This option is only visible if you selected Panorama when the deployment profile was created.
STEP 1 | Go to Assets > Software NGFW Credits and select a profile (select a row).
STEP 2 | On the far right, select the vertical ellipsis (More Options) and select Provision Panorama.
STEP 3 | Choose the Panorama you want to manage your firewalls or act as a log collector, and click
Provision.
Deactivate a Firewall
STEP 1 | In the CSP, select Assets > Software NGFW Credits and select a profile (select a row).
STEP 1 | In the CSP, select Assets > Software NGFW Credits and select a profile (select a row).
STEP 2 | On the far right, select the vertical ellipsis (More Options) and select Delete.
The SD-WAN capabilities are supported on all VM-Series models, except the VM-50 and
VM-100.
For information on the platforms on which you can deploy the VM-Series firewall, see VM-Series
Deployments. For more information about the VM-Series firewall models, see the Palo Alto Networks
Firewall comparison tool. You can also review general information About the VM-Series Firewall.
• VM-Series System Requirements
• CPU Oversubscription
• VM-50 Lite Mode
You can enable Lite mode on the VM-50. Lite mode is an alternative operating mode for environments
where resources are limited. See VM-50 Lite Mode for more information.
To achieve the best performance, all of the needed cores should be available on a single
CPU socket.
For operation, the VM-50 firewall requires minimum 32GB of hard drive space. However,
because the VM-Series base image is common to all models, you must allocate 60GB of
hard drive space until you license the VM-50.
The number of vCPUs assigned to the management plane and those assigned to the dataplane differs
depending on the total number of vCPUs assigned to the VM-Series firewall. If you assign more vCPUs than
those officially supported by the license, any additional vCPUs are assigned to the management plane.
2 1 1
4 2 2
8 2 6
16 4 12
CPU Oversubscription
The VM-Series firewall supports CPU oversubscription on all models. CPU oversubscription allows you
deploy a higher density of VM-Series firewalls on hypervisors running on x86 architecture. You can deploy
two (2:1) to five (5:1) VM-Series firewalls per required allocation of CPUs. When planning your deployment,
use the following formula to calculate the number of VM-Series firewalls your hardware can support.
(Total CPUs x Oversub Ratio)/CPUs per firewall = total number of VM-Series firewalls
For example, at a 5:1 ratio, a host machine with 16 physical CPU and at least 180GB of memory (40 ×
4.5GB) can support up to 40 instances to the VM-50. Each VM-50 requires two vCPUs and five VM-50s
can be associated to each pair of vCPUs.
(16 CPUs x 5)/2 = 40 VM-50 firewalls
Beyond meeting the minimum VM-Series System Requirements, no additional configuration is required to
take advantage of oversubscription. Deploy VM-Series firewalls normally and resource oversubscription
occurs automatically. When planning your deployment, consider other functions, such as virtual switches,
and guest machines on the host that require hardware resources of their own.
The VM-Series on OCI PAYG license does not support the VM-100.
With the PAYG license bundles, the firewall is prelicensed and ready for use as soon as you deploy it;
you do not receive an auth code. When you stop or terminate the firewall from your Cloud console,
PAYG licenses are suspended or terminated.
A PAYG license applies a VM-Series capacity license based on the hardware allocated to the instance.
the PAYG instance checks the amount of hardware resources available to the instance and applies
the largest VM-Series firewall capacity license allowed for the resources available. For example, if the
instance has 2 vCPUs and 16GB of memory, a VM-100 capacity license is applied based on the number
of vCPUs. However, if the instance has 16 vCPUs and 16GB of memory, a VM-500 license is applied
based on the amount of memory. For more information about VM-Series model resource requirements,
see VM-Series System Requirements.
Premium Support
GlobalProtect
WildFire
DNS Security
When using the VM-Series firewall CLI to view your applied PAYG license, the command
show system info displays a different value from the output displayed for the command
request license info. The command request license info always displays the license as a
VM-300, regardless of the actual VM-Series model. However, request license info
You cannot switch between the PAYG and the BYOL licenses. To move from PAYG to BYOL, contact your
Palo Alto Networks channel partner or sales representative to purchase a BYOL license and get a BYOL
auth code that you can use to license your firewall. If you have deployed your firewall and want to switch
the license, see Switch Between the BYOL and the PAYG Licenses.
If you have an evaluation copy of the VM-Series firewall and would like to convert it to a fully
licensed (purchased) copy for the same license type (BYOL to BYOL), you can deactivate
the evaluation license and activate the purchased license in its place. See Upgrade the VM-
Series Firewall for instructions.
Additional purchases and grants do not directly add to the number of available VM-Series
firewalls in a CSP account; instead, ELA license tokens are added to the VM-Series ELA
token pool. The ELA license tokens can subsequently be allocated by the ELA administrator
to a given CSP account to increase the number of available VM-Series firewalls.
STEP 1 | (Legacy VM-Series ELA Customers only) Designate an ELA administrator to manage tokens.
Existing enterprise license customers who have been migrated to the Multi-Model ELA must designate
an ELA administrator to manage VM-Series ELA license tokens. Upon conversion, no other action is
necessary for continued operation of your firewalls, however, you will not be able to (re)allocate tokens
for deploying firewalls until an ELA administrator has been assigned. Only an administrator with a super
user role on the CSP has the ability to designate an ELA administrator, who in turn, can manage tokens
or grant tokens to other administrators.
1. Log in to the Palo Alto Networks CSP.
4. Select Assets > VM-Series Auth-Codes to view the authorization codes for deploying each model of
the VM-Series firewall and associated subscriptions included with the ELA.
2. Verify that the accurate number of firewall instances are deposited in the account.
Select Assets > VM-Series Auth-Code to confirm the auth codes you allotted. In this example,
the account has the ability to provision 10 instances each of the VM-50 and the VM-500. As the
recipients deploy firewalls, the number of tokens are deducted from the total available pool, and
you can view the number of firewall instances that they have provisioned as a ratio of the total
quantity you allocated for them. As your security needs evolve, you have the flexibility to allocate
more quantity and allow access to a different VM-Series firewall model as long as you have tokens
available.
You cannot reclaim a portion of the tokens allocated to a CSP account. By reclaiming
tokens, you are removing the entirety of the CSP account from the VM-Series ELA and
reallocating all associated tokens to the token pool.
1. Verify that all tokens associated with the CSP account that you want to remove are not being utilized
by the VM-Series firewalls. Deactivate the VM-Series firewalls as necessary to provision tokens for
removal.
2. Select Assets > Enterprise Agreements > Manage VM-Series Token.
Select the account ID from whom you want to reclaim tokens from and click Reclaim Token. If tokens
are available for reclamation, you will receive a confirmation of a successful removal.
STEP 3 | Verify which VM-Series models and how many are allocated for you.
After the ELA administrator allocates the VM-Series firewall models and number of instances you can
provision, you can select Assets > VM-Series Auth Codes to view which models and how many of each
are allocated for you. For example, the grant in the following screenshot displays the auth codes that
enable you to deploy 10 instances each of the VM-50 and the VM-500.
As you deploy firewalls and register them to the CSP, the number of provisioned firewalls is
incremented. The Quantity of VM Provisioned displays the ratio of provisioned to total available for
each model.
For usage-based models of the VM-Series firewall in the AWS Marketplace, instances with
short and long AWS instance IDs are supported.
Until you activate the license on the VM-Series firewall, the firewall does not have a serial number, the
MAC address of the dataplane interfaces are not unique, and only a minimal number of sessions are
supported. Because the MAC addresses are not unique until the firewall is licensed, to prevent issues
caused by overlapping MAC addresses, make sure that you do not have multiple, unlicensed VM-Series
firewalls.
When you activate the license, the licensing server uses the UUID and the CPU ID of the virtual machine to
generate a unique serial number for the VM-Series firewall. The capacity auth code in conjunction with the
serial number is used to validate your entitlement.
After you license a VM-Series firewall, if you need to delete and redeploy the VM-Series
firewall, make sure to Deactivate the License(s) on the firewall. Deactivating the license
allows you to transfer the active licenses to a new instance of the VM-Series firewall without
help from technical support.
5. Navigate to Assets > My Devices and search for the VM-Series device just registered and click the
PA-VM link. This will download the VM-Series license key to the client machine.
6. Copy the license key to the machine that can access the web interface of the VM-Series firewall and
navigate to Device > Licenses.
License keys must be installed through the web interface. The firewall does not
support license key installation through SCP or FTP.
7. Click Manually Upload License link and enter the license key. When the capacity license is activated
on the firewall, a reboot occurs.
8. Log in to the device and confirm that the Dashboard displays a valid serial number and that the PA-
VM license displays in the Device > Licenses tab.
Activate the License for the VM-Series Firewall for VMware NSX
Panorama serves as the central point of administration for the VM-Series firewalls for VMware NSX and
the license activation process is automated when Panorama has direct internet access. Panorama connects
to the Palo Alto Networks update server to retrieve the licenses, and when a new VM-Series firewall for
NSX is deployed, it communicates with Panorama to obtain the license. If Panorama is not connected to
the internet, you need to manually license each instance of the VM-Series firewall so that the firewall can
connect to Panorama. For an overview of the components and requirements for deploying the VM-Series
firewall for NSX, see VM-Series for NSX Firewall Overview.
For this integrated solution, the auth code (for example, PAN-VM-1000-HV-SUB-BND-NSX2) includes
licenses for threat prevention, URL filtering and WildFire subscriptions and premium support for the
requested period.
In order to activate the license, you must have completed the following tasks:
• Registered the auth code to the support account. If you don’t register the auth code, the licensing server
will fail to create a license.
• Entered the auth code in the Service Definition on Panorama. On Panorama, select VMware Service
Manager to add the Authorization Code to the VMware Service Definition.
If you have purchased an evaluation auth code, you can license up to 5 VM-Series
firewalls with the VM-1000-HV capacity license for a period of 30 or 60 days. Because
Activate Licenses on VM-Series Firewalls on NSX When Panorama has No Internet Access
Complete the following procedure to activate the VM-Series firewall for NSX when Panorama does not
have access to the internet.
STEP 2 | Activate the auth code and generate the license keys.
1. Log in to the Palo Alto Networks Customer Support website with your account credentials. If you
need a new account, see Create a Support Account.
2. Select Assets > VM-Series Auth Codes, click Add VM-Series Auth Codes to enter the auth code.
3. Select Register VM in the row that corresponds to the auth code that you just registered, enter the
CPU ID and the UUID of the firewall and click Submit. The portal will generate a serial number for
the firewall.
4. Select Assets > Devices and search for the serial number.
5. Click the link the Actions column to download each key locally to your laptop. In addition to the
subscription license key, you must get the capacity license and the support license keys.
Install the capacity license key file (pa-vm.key) first. When you apply the capacity
license key, the VM-Series firewall will reboot. On reboot, the firewall will have a serial
number that you can use to register the firewall as a managed device on Panorama.
• If you see an error that reads Failed to fetch licenses. Failed to get license info. Please try
again lateror a generic communications error message displays.
• Is routing over the internet working? SSH into the firewall and ping an publicly accessible IP address
such as 4.2.2.2. Be sure to use the source option if you are using a dataplane interface. For example:
ping count 3 source 10.0.1.1 host 4.2.2.2.
• Is DNS set up correctly? SSH into the firewall and ping a DNS name such as google.com. For example:
STEP 1 | Save a backup of the current configuration file and store it to an external server.
1. Select Device > Setup > Operations and Export named configuration snapshot.
2. Select the XML file that contains your running configuration (for example, running-config.xml) and
click OK to export the configuration file.
3. Save the exported file to a location external to the firewall.
STEP 2 | Deploy a new firewall and register or activate the license, as appropriate.
STEP 3 | On the newly deployed firewall, restore the configuration that you exported.
1. Access the web interface of the newly deployed firewall.
2. Select Device > Setup > Operations, click Import named configuration snapshot, Browse to the
configuration file on the external host, and click OK.
3. Click Load named configuration snapshot, select the Name of the configuration file you just
imported, and click OK.
4. Click Commit to overwrite the running configuration with the snapshot you just imported.
5. Verify that the configuration on the new firewall matches the firewall that you are replacing, before
you delete the firewall or deactivate the licenses on the replaced firewall.
Do not use this procedure for switching between PAYG and BYOL. See Switch Between the
BYOL and the PAYG Licenses for more information.
Before switching to an ELA license, you must allocate enough tokens equal the number of currently-
deployed VM-Series firewalls. See VM-Series Enterprise License Agreement (Multi-Model ELA) for more
information about the tokens required for each VM-Series model.
1. Select Device > Licenses and select the Activate feature using authorization code link.
2. Enter your VM-Series authorization code.
3. Click OK to confirm the license upgrade.The firewall contacts the Palo Alto Networks update
server and consume the tokens required for your firewall based on the VM-Series model.
4. Verify the license updated successfully by checking the license expiration date.
5. Repeat this process for each VM-Series firewall in your deployment.
Do not use the ELA authorization code to activate individual VM-Series firewalls.
After registering your ELA, use the VM-Series model authorization codes to
activate individual firewalls. You can find these authorization codes on the
Customer Support Portal under Assets > VM-Series Auth-Codes.
2. Log in to the Panorama web interface.
3. Verify the Palo Alto Networks update server configuration for the firewalls.
1. Select Device > Setup > Services.
2. Confirm that Update Server is set to updates.paloaltonetworks.com.
3. Confirm that Update Server Identity is selected.
4. Apply a VM-Series authorization code. A firewall authorization code for an ELA begins with the letter
A, as shown below.
6. Verify the license updated successfully by checking the license expiration date.
STEP 1 | Log in to the Palo Alto Networks Customer Support Portal with your account credentials.
STEP 3 | Click the Renew link to select the serial numbers to Renew, Change to Basic Bundle, or Forfeit.
If you have provisioned the firewall, select the appropriate option in the row that corresponds to the
Serial Number. If you have unprovisioned instances of the firewall, select the quantity for each renewal
option you choose under Unprovisioned VM Renewal Settings.
STEP 1 | Log in to the Palo Alto Networks Customer Support website with your account credentials.
Select Assets > Software NFGW credits, find the deployment profile, and make note of the Auth Code.l
STEP 2 | Select Assets > VM-Series Auth-Codes > Add VM-Series Auth-Code.
STEP 3 | In the Add VM-Series Auth-Code field, enter the Software NGFW Credits authcode for the
deployment profile used to create the firewall.
View the credit pool details to see the number of VM-Series firewalls that have been deployed and the
number of credits available for use against each auth code. When all the available licenses are used, the
auth code does not display on the VM-Series Auth-Codes page. To view all the assets that are deployed,
select Assets > Devices.
STEP 3 | In the Add CN-Series Auth-Code field, enter the Software NGFW Credits authcode for the
deployment profile used to create the Kubernetes cluster.
View the credit pool details to see the number of VM-Series firewalls that have been deployed and the
number of credits available for use against each auth code. When all the available licenses are used, the
auth code does not display on the VM-Series Auth-Codes page. To view all the assets that are deployed,
select Assets > Devices.
STEP 1 | Log in to the Palo Alto Networks Customer Support website with your account credentials. If
you need a new account, see Create a Support Account.
STEP 2 | Select Assets > VM-Series Auth-Codes > Add VM-Series Auth-Code.
STEP 3 | In the Add VM-Series Auth-Code field, enter the capacity auth code you received by email,
and click the checkmark on the far right to save your input. The page will display the list of auth
codes registered to your support account.
You can track the number of VM-Series firewalls that have been deployed and the number of licenses
that are still available for use against each auth code. When all the available licenses are used, the auth
code does not display on the VM-Series Auth-Codes page. To view all the assets that are deployed,
select Assets > Devices.
STEP 1 | Log in to the Palo Alto Networks Customer Support website, and click Register a Device.
1. Select Register usage-based VM-Series models (hourly/annual) purchased from public cloud
Marketplace or Cloud Security Service Provider (CSSP).
2. Select your Cloud Marketplace vendor and click Next.
STEP 2 | Enter the Serial #, the CPU ID, and the UUID of the VM-Series firewall.
For example, from the Dashboard of the VM-Series firewall on your VM you will see the following
information.
STEP 3 | Agree and Submit to accept the EULA and register the firewall.
STEP 4 | Verify that the details on the licenses you purchased are displayed on the CSP Assets page.
Pay-as-you-go (PAYG) licenses are not supported for use with this plugin.
Additionally, the Software Firewall License plugin simplifies the license activation and deactivation of VM-
Series firewalls in environments that use auto-scaling and automation to deploy and delete firewalls to
address changes in the cloud.
The Software Firewall License plugin does not support the VM-Series firewall for VMware
NSX. The Panorama plugin for VMware NSX automatically licenses VM-Series firewalls
deployed in NSX-V or NSX-T
Additionally, do not this plugin to license firewalls deployed in device groups that include
instances of the VM-Series firewall deployed in NSX-V or NSX-T.
When a Auto Deactivate interval, the plugin might deactivate the license of stopped
VM-Series firewalls that are managed by the same license manager of firewalls that
deactivate as expected.
8. Select a Bootstrap Definition from the drop-down. The selected bootstrap definition specifies the
auth code used by Panorama to license the VM-Series firewalls associated with the license manager.
9. Click OK.
10.Commit your changes.
STEP 4 | (Optional) Create an init-cfg.txt file for bootstrap the VM-Series firewall. After configuring a
license manager, you can copy and paste bootstrap parameters generated by Panorama when
deploy your VM-Series firewalls. Depending on your deployment, the parameters displayed
might be a subset of those shown in the image below. For example, if your Panorama appliance
If you use the auth key displayed here in your init-cfg.txt file, do not use a manually
generated VM auth key.
STEP 5 | (Optional) View and deactivate a managed VM-Series firewall. From the Show Devices dialogue,
you can view the devices associated with a given license manager. You can view the name,
serial number, management IP address, connection status, and amount of time Panorama waits
to deactivate a disconnected firewall. Additionally, you can manually deactivate the license of
managed VM-Series firewall.
1. Select Panorama > SW Firewall License > License Managers.
2. In the Action column of a given license manager, click Show Devices.
3. To manually deactivate a connected or disconnected (but not yet deactivated) managed VM-Series
firewall, select a one or more listed VM-Series firewalls and click Deactivate.
STEP 6 | (Optional) Verify that Panorama has completed the necessary API calls to license connected
firewalls.
vm-series-auto-registration-pin-id=
vm-series-auto-registration-pin-value=
4. Log in to the firewall and verify that you can see the site license on the firewall.
• Generate the one-time password (OTP) and manually retrieve the device certificate on the
firewall.
The firewall requires this device certificate to get the site license entitlements and securely access the
cloud services.
1. Log in to the Customer Support Portal.
Register your VM-Series firewall, if you have not already.
2. Select Assets > Device Certificates > Generate OTP.
5. Verify that the device certificate is fetched and that you can see the site license on the firewall.
• If using Panorama to manage the VM-Series firewall, see Install the device certificate on a
managed firewall.
STEP 1 | Retrieve the license deactivation API key from the Customer Support Portal.
1. Log in to the Customer Support Portal.
2. Select Assets > Licensing API.
3. Copy the API key.
STEP 2 | Use the CLI to install the API key copied in the previous step.
request license api-key set key <key>
STEP 4 | To replace a license deactivation API key, use the following CLI command to delete an installed
API key.
request license api-key delete
To deactivate a VM-Series firewall after deleting the API key, you must install a new one.
STEP 2 | (Direct internet access only) View the name of the license key file for the feature you want to
deactivate.
request license deactivate key features ?
STEP 4 | (When there is no direct internet access) View the name of the license key file for the feature you
want to deactivate.
request license deactivate key features
STEP 5 | (When there is no direct internet access) Deactivate the license manually.
request license deactivate key features <name> mode manual
For example:
STEP 7 | Export the token file to an SCP or TFTP server and save it to your computer.
scp export license-token-file to <username@serverIP> from <token_filename>
For example:
scp export license-token-file to [email protected]:/tmp/ from
dact_lic.01282015.100502.tok
STEP 8 | Log into the Palo Alto Networks Customer Support website.
STEP 11 | While logged in to the Palo Alto Networks Customer Support website, upload the token file
to complete the deactivation.
Deactivate VM
When you no longer need a BYOL instance of the VM-Series firewall, you can free up all active licenses—
subscription licenses, VM-Capacity licenses, and support entitlements— using the web interface, CLI, or the
XML API on the firewall or Panorama. The licenses are credited back to your account and you can use the
same authorization codes on a different instance of the VM-Series firewall.
Deactivating a VM removes all the licenses/entitlements and places the VM-Series firewall in an unlicensed
state; the firewall will not have a serial number and can support only a minimal number of sessions. Because
the configuration on the firewall is left intact, you can re-apply a set of licenses and restore complete
functionality on the firewall, if needed.
STEP 1 | Log into the web interface and select Device > Licenses.
STEP 3 | Verify the list of licenses/entitlements that will be deactivated on the firewall.
STEP 4 | Pick one of the following options to start deactivating the VM:
• Click Continue, if the firewall can communicate directly with the Palo Alto Networks Licensing server.
You will be prompted to reboot the firewall; on reboot the licenses are deactivated.
• Click Complete Manually, if the firewall does not have internet access. Click the Export license
token link to save the token file to your local computer. For example, the token filename is
20150128_1307_dact_lic.01282015.130737.tok. You will be prompted to reboot the firewall; on
reboot the licenses are deactivated.
STEP 5 | (Manual process only) Complete the following tasks to register the changes with the Licensing
server:
1. Log into the Palo Alto Networks Customer Support website.
2. Select Assets > VM-Series Auth-Codes > Deactivate License(s).
3. While logged in to the Palo Alto Networks Customer Support website, upload the token file to
complete the deactivation.
STEP 1 | Log in to the Panorama web interface and select Panorama > Device Deployment > Licenses.
STEP 2 | Deactivate VMs and select the VM-Series firewall that you want to deactivate.
Instead of deleting the firewalls, if you prefer, you can create a separate device group
and assign the deactivated VM-Series firewalls to this device group.
The API also allows you to view the details of an auth code so that you can track the number of unused
licenses attached to an auth-code or auth-code bundle that enables you to license more than one instance
of the firewall. An auth-code bundle includes the VM-Series model, subscriptions and support in a single,
easy to order format; you can use this bundle multiple times to license VM-Series firewalls as you deploy
them.
To use the API, each support account is assigned a unique key. Each API call is a POST request, and the
request must include the API key to authenticate the request to the licensing server. When authenticated,
the licensing server sends the response in json (content-type application/json).
• Manage the Licensing API Key
• Use the Licensing API
• Licensing API Error Codes
Activate Licenses
URL: https://api.paloaltonetworks.com/api/license/activate
Parameters: uuid, cpuid, authCode, and serialNumber.
Use these parameters to accomplish the following:
• For first time or initial license activation, provide the cpuid, uuid, auth-code in the API request.
• If you did not save the license keys or had a network connection trouble during initial license activation,
to retrieve the license(s) again for a firewall that you have previously activated, you can either provide
the cpuid and uuid in the API request, or provide the serial number of the firewall in the API request.
Header: apikey
Sample request for initial license activation using Curl:
[{"lfidField":"13365773","partidField":"PAN-SVC-PREM-VM-300","featureFi--
eld":"Premium","feature_descField":"24 x 7 phone support;
advanced replacement hardware service","keyField":"m4iZEL1t3n6Oa
+6ll1L7itDZTphYw48N1AMOZXutDgExC5f5pOA52+Qg1jmAxanB
\nKOyat4FJI4k2hWiBYz9cONuKoiaNOtAGhJvAuZmYgqAZejKueWrTzCuLrwxI/iEw
\nkRGR3cYG+j6o84RitR937m2iOk2v9o8RSfLVilgX28nqmcO8LcAnTqbrRWdFtwVk
\nluz47AUMXauuqwpMipouQYjk0ZL7fTHHslhyL7yFjCyxBoYXOt3JiqQ0OCDdBdDI
\n91RkVPylEwTKgSXm3xpzbmC2ciUR5b235gyqdyW8eQXKvaThuR8YyHr1Pdw/lAjs
The feature_Field in the response indicates the type of key that follows in the keyField.
Copy each key to a text file and save it with the .key extension. Because the key is in json
format, it does not have newlines; make sure to convert it to newlines if needed for your
parser. Make sure to name each key appropriately and save it to the /license folder of the
bootstrap package. For example, include the authcode with the type of key to name it as
I3306691_1pa-vm.key (for the capacity license key), I3306691_1threat.key (for the Threat
Prevention license key), I3306691_1wildfire.key (for the WildFire subscription license key).
Sample API request for retrieving previously activated licenses using Curl:
[{"lfidField":"13365773","partidField":"PAN-SVC-PREM-
VM-300","featureField":"Premium","feature_descField":"24 x 7 phone
support; advanced replacement hardware service","keyField":"m4iZEL1t3n6Oa
+6ll1L7itDZTphYw48N1AMOZXutDgExC5f5pOA52+Qg1jmAxanB
\nKOyat4FJI4k2hWiBYz9cONuKoiaNOtAGhJvAuZmYgqAZejKueWrTzCuLrwxI/iEw
\nkRGR3cYG+j6o84RitR937m2iOk2v9o8RSfLVilgX28nqmcO8LcAnTqbrRWdFtwVk
\nluz47AUMXauuqwpMipouQYjk0ZL7fTHHslhyL7yFjCyxBoYXOt3JiqQ0OCDdBdDI
\n91RkVPylEwTKgSXm3xpzbmC2ciUR5b235gyqdyW8eQXKvaThuR8YyHr1Pdw/lAjs
\npyyIVFa6FufPacfB2RHApQ==
\n","auth_codeField":"","errmsgField":null,"typeField":"SUP","regDateField":"2016-06-03T
"expirationField":"8/29/2016 12:00:00 AM","PropertyChanged":null},
{"lfidField":"13365774","partidField":"PAN-VM-300-TP","featureField":"Threat
Prevention","feature_descField":"Threat Prevention","keyField":"NqaXoaFG
+9qj0t9Vu7FBMizDArj+pmFaQEd6I2OqfBfAibXrvuoFKeXX/K2yXtrl
\n2qJhNq3kwXBDxn181z3nrUOsQd/eW68dyp4jb1MfAwEM8mlnCyLhDRM3EE+umS4b
\ndZBRH5AQjPoaON7xZ46VMFovOR+asOUJXTptS/Eu1bLAI7PBp3+nm04dYTF9O50O
\ndey1jmGoiBZ9wBkesvukg3dVZ7gxppDvz14+wekYEJqPfM0NZyxsC5dnoxg9pciF
\ncFelhnTYlma1lXrCqjJcFdniHRwO0RE9CIKWe0g2HGo1uo2eq1XMxL9mE5t025im
\nblMnhL06smrCdtXmb4jjtg==
\n","auth_codeField":"","errmsgField":null,"typeField":"SUB","regDateField":"2016-06-03T
12:00:00 AM","PropertyChanged":null}
...<truncated>
Deactivate Licenses
URL: https://api.paloaltonetworks.com/api/license/deactivate
Parameters: encryptedToken
[{"serialNumField":"007200006150","featureNameField":"","issueDateField":"","successFiel
{"serialNumField":"007200006150","featureNameField":"","issueDateField":"","successField
{"serialNumField":"007200006150","featureNameField":"","issueDateField":"","successField
{"serialNumField":"007200006150","featureNameField":"","issueDateField":"","successField
{"serialNumField":"007200006150","featureNameField":"","issueDateField":"","successField
{"serialNumField":"007200006150","featureNameField":"","issueDateField":"","successField
HTTP/1.1 200 OK
Date: Thu, 05 May 2016 20:07:16 GMT
Content-Length: 182
{"AuthCode":"I9875031","UsedCount":4,"TotalVMCount":10,"UsedDeviceDetails":
[{"UUID":"420006BD-113D-081B-F500-2E7811BE80C
9","CPUID":"D7060200FFFBAB1F","SerialNumber":"007200006142"}]}.....
STEP 1 | Log in to the Palo Alto Networks Customer Support website with your account credentials. If
you need a new account, see Create a Support Account.
STEP 2 | Select CSSP > Order History, to view the list of auth codes registered to your support account.
As you deploy firewalls, you must register each instance of the firewall against an auth code.
STEP 1 | Log in to the Palo Alto Networks Customer Support website with your account credentials. If
you need a new account, see Create a Support Account.
STEP 2 | Select CSSP > Order History, to view the list of auth codes registered to your support account.
STEP 3 | Select CSSP > VM Provisioning Auth Codes, select an Authorization Code and click Register
VM.
STEP 4 | Enter the UUID and CPUID of the VM instance and click Submit. The portal will generate a
serial number for the firewall.
You can track the number of VM-Series firewalls that have been deployed and the
number of licenses that are still available for use against each auth code. To view all
the total number of firewalls registered against a specific auth code, select CSSP >
STEP 1 | Log in to the Palo Alto Networks Customer Support website with your account credentials.
STEP 3 | Select the Serial Number and click Add End User Info.
After you add account information, you can find all firewalls registered to a customer. In
Search Existing End User, enter the customer ID or customer name and click Search to
find all firewalls provisioned for the customer.
STEP 2 | Use the ReportEndUserInfo API to add end-user information for a VM-Series Firewall that is
registered to a CSSP.
URL: https://api.paloaltonetworks.com/api/license/ReportEndUserInfo
Headers:
• Content-Type: application/json
• apiKey: API Key
Parameters:
• SerialNumbers: Required, provide at least one valid firewall serial number
• CustomerReferenceId: Required
• CompanyName: Required, end-user company name
• DnBNumber: Data Universal Numbering System (D-U-N-S) number
• PhoneNumber: End-user phone number
• EndUserContactEmail: Required, end-user email address
• Address: Required, end-user address
• Country: Required, ISO 2-letter country code
• City: Required, end-user city name
109
110 VM-SERIES DEPLOYMENT GUIDE | Set Up a VM-Series Firewall on an ESXi Server
© 2021 Palo Alto Networks, Inc.
Supported Deployments on VMware vSphere
Hypervisor (ESXi)
You can deploy one or more instances of the VM-Series firewall on the ESXi server. Where you place the
VM-Series firewall on the network depends on your topology. Choose from the following options (for
environments that are not using VMware NSX):
• One VM-Series firewall per ESXi host—Every VM server on the ESXi host passes through the firewall
before exiting the host for the physical network. VM servers attach to the firewall via virtual standard
switches. The guest servers have no other network connectivity, therefore the firewall has visibility and
control over all traffic leaving the ESXi host. One variation of this use case is to also require all traffic to
flow through the firewall, including server to server (east-west) traffic on the same ESXi host.
• One VM-Series firewall per virtual network—Deploy a VM-Series firewall for every virtual network.
If you have designed your network such that one or more ESXi hosts has a group of virtual machines
that belong to the internal network, a group that belongs to the external network, and a group that
belongs to the DMZ, you can deploy a VM-Series firewall to safeguard the servers in each group. If a
group or virtual network does not share a virtual switch or port group with any other virtual network,
it is completely isolated from all other virtual networks within or across the host(s). Because there is no
other physical or virtual path to any other network, the servers on each virtual network must use the
firewall to talk to any other network. The firewall has visibility and control over all traffic leaving the
virtual (standard or distributed) switch attached to each virtual network.
• Hybrid environment—Both physical and virtual hosts are used. The VM-Series firewall can replace a
physical firewall appliance in a traditional aggregation location. A hybrid environment achieves the
benefits of a common server platform for all devices, and unlinks hardware and software upgrade
dependencies.
Continue with VM-Series on ESXi System Requirements and Limitations and Install a VM-Series firewall on
VMware vSphere Hypervisor (ESXi).
The mapping on the VM-Series Firewall remains the same no matter which vNICs you add on ESXi.
Interfaces you activate on the firewall always take the next available vNIC on ESXi.
To avoid the issues described in the preceding example, you can do the following:
• When provisioning your ESXi host for the first time, activate all nine vNICs beyond the first. Adding all
nine vNICs as placeholders before powering on the VM-Series Firewall allows you to use any VM-Series
interfaces regardless of order.
• If all vNICs are active, adding additional interfaces no longer requires a reboot. Because each vNIC on
ESXi requires that you choose a network, you can create an empty port group as a network placeholder.
• Do not remove VM-Series firewall vNICs to avoid mapping mismatches.
The OVA file contains the base installation. After the base installation is complete, you
must download and install the latest PAN-OS version from the support portal. This
ensures that you have the latest fixes implemented since the base image was created.
For instructions, see Upgrade the PAN-OS Software Version (Standalone Version).
STEP 2 | Before deploying the OVA file, set up virtual standard switch(es) or virtual distributed
switch(es) that you need for the VM-Series firewall.
If you are deploying the VM-Series firewall with Layer 3 interfaces, your firewall uses
Hypervisor Assigned MAC Addresses by default. If you choose to disable hypervisor
assigned MAC address, or if you are deploying the firewall with Layer 2, virtual wire, or
tap interfaces, you must configure (set to Accept) any virtual switch attached to the VM-
Configure a virtual standard switch or a virtual distributed switch to receive frames for the VM-Series
firewall.
Virtual Standard Switch
1. Navigate to Home > Hosts and Clusters and select a host.
2. Click the Configure tab and view Virtual Switches. For each VM-Series firewall attached a virtual
switch, click on Properties.
3. Highlight a port group corresponding to a virtual switch and click Edit Settings. In the vSwitch
properties, click the Security tab and set Promiscuous Mode, MAC Address Changes and Forged
Transmits to Accept and then click OK. This change propagates to all port groups on the virtual
switch.
Virtual Distributed Switch
1. Select Home > Networking. Select your virtual distributed switch and highlight the Distributed Port
Group you want to edit.
2. Click Edit Settings, select Policies > Security, and set Promiscuous Mode, MAC Address Changes and
Forged Transmits to Accept and click OK.
If you add additional interfaces (vNICs) to the VM-Series firewall, you must reboot
(because new interfaces are detected during the boot cycle). To minimize the need to
reboot the firewall, activate the interfaces at initial deployment or during a maintenance
window.
To view the progress of the installation, monitor the Recent Tasks list.
1. Log in to vCenter using the vSphere client. You can also go directly to the target ESXi host if needed.
2. From the vSphere web client, go to Hosts and Clusters, right-click your host, and select Deploy OVF
Template.
3. Browse to the OVA file that you downloaded in 1 Select the file, and click Next. Review the
template’s details and click Next.
4. Name the VM-Series firewall instance, and in the Inventory Location window, select a Data Center
and Folder, and click Next.
5. Select an ESXi host for the VM-Series firewall, and click Next.
6. Select the datastore to use for the VM-Series firewall, and click Next.
7. Leave the default settings for the datastore provisioning, and click Next. The default is Thick
Provision Lazy Zeroed.
9. Review the details, select Power on after deployment, and click Next.
10.When the deployment is complete, click the Summary tab to review the current status.
STEP 3 | Configure the network access settings for the management interface.
Enter the following commands:
STEP 5 | Verify network access to external services required for firewall management, such as the Palo
Alto Networks Update Server.
1. Use the ping utility to verify network connectivity to the Palo Alto Networks Update server as shown
in the following example. Verify that DNS resolution occurs and the response includes the IP address
for the Update server (the Update server does not respond to ping requests.) After verifying DNS
resolution, press Ctrl+C to stop the ping request.
When the virtual appliance is configured to use a virtual disk, the VM-Series firewall
no longer stores logs. If the appliance loses connectivity to the virtual disk, logs can be
lost during the failure interval. If necessary, place the newly created virtual disk on a
datastore that provides RAID redundancy. RAID10 provides the best write performance
for applications with high logging characteristics.
STEP 2 | On the ESXi server, add the virtual disk to the firewall.
1. Select the VM-Series firewall on the ESXi server.
2. Click Edit Settings.
3. Click Add to launch the Add Hardware wizard, and select the following options when prompted:
1. Select Hard Disk for the hardware type.
2. Select Create a new virtual disk.
3. Select SCSI as the virtual disk type.
4. Select the Thick provisioning disk format.
5. In the location field, select Store with the virtual machine option. The datastore does not have to
reside on the ESXi server.
6. Verify that the settings look correct and click Finish to exit the wizard. The new disk is added to
the list of devices for the virtual appliance.
If you reuse a virtual disk that was previously used for storing PAN-OS logs, all logs from
the existing disk are overwritten.
• View the IP address(es) on the management interface and the software version on the firewall
and Panorama.
In the Hosts and Cluster section on the vCenter server, select the firewall or Panorama and view the
Summary tab for information on the IP address(es) assigned to the management interface and the
software version currently installed.
• View resource utilization metrics on hard disk, memory, and CPU. Use these metrics to enable
alarms on the vCenter server.
In the Hosts and Cluster section on the vCenter server, select the firewall or Panorama and view the
Monitor > Utilization tab for information on hard disk, memory, and CPU usage.
• Gracefully shutdown or restart the firewall and Panorama from the vCenter server.
• Create alarm definitions for events you want to be notified about, or events for which you
want to specify an automated action.
Refer to the VMware documentation for details on creating alarm definitions.
In the Hosts and Cluster section on the vCenter server, select the firewall or Panorama and select
the Manage > Alarm Definitions to add a new trigger and specify an action when a threshold is met.
For example, missing heartbeats for a specified duration, or when memory resource usage exceeds a
threshold. The following screenshot shows you how to use notifications for heartbeat monitoring on the
firewall or Panorama.
These commands are not required when using vMotion if you are running vSphere 7.0 or
later.
STEP 3 | (Optional) If you complete vMotion before the pause interval has elapsed, you can end the
pause by setting the interval to zero (0).
request system heartbeat-pause set interval 0
The Panorama plugin for VMware vCenter does not support proxy servers.
The Panorama plugin for VMware vCenter does not support tags associated to vApps or
resource pools.
The plugin supports a maximum of 16 user-defined tags per VM. Any user-defined tags
beyond 16 are not processed.
The Panorama plugin for vCenter cannot process tags that are longer than 128 characters; this includes
letters, numbers, and special characters. Whitespace in vCenter object names is replaced with forward
slashes. Additionally, Panorama does not support non-ASCII special characters or the following special
characters—’<>&” in vCenter VM names and annotations. Panorama drops tags containing unsupported
characters.
To retrieve endpoint IP-address-to-tag mapping information, you must configure a Monitoring Definition
for each vCenter in your virtual environment. The Monitoring Definition specifies the username
and password that allows Panorama to connect to vCenter. It also specifies the device groups and
corresponding notify groups containing the firewalls to which Panorama pushes the tags. After you
configure the Monitoring Definition and the Panorama plugin for VMware vCenter retrieves the tags, you
can create DAGs and add the tags as match criteria.
STEP 2 | Select Upload and click Browse to locate the plugin file.
STEP 4 | Select the version of the plugin and click Install in the Action column to install the plugin.
Panorama will alert you when the installation is complete.
STEP 4 | Add vCenter information. The Panorama plugin for VMware vCenter supports up to 16
vCenter instances.
1. Select Panorama > VMware vCenter > Setup > vCenter.
2. Enter a descriptive Name for your vCenter.
3. Enter the IP address or FQDN for vCenter and port, if applicable.
4. Enter your vCenter username.
5. Enter and confirm your vCenter password.
6. Click Validate to verify that Panorama can connect to vCenter using the login credentials you
entered.
7. Click OK.
1. Select Panorama > VMware vCenter > Monitoring Definition and click Add.
2. Enter a descriptive Name and optionally a description to identify the vCenter for which you use this
definition.
3. Select the vCenter and Notify Group.
4. Click OK.
STEP 7 | Verify that you can view the VM information on Panorama, and define the match criteria for
Dynamic Address Groups.
You must use the OR operator when using more than one tag in the match criteria; using
the AND operator does not work.
Some browser extensions may block API calls between Panorama and vCenter which
prevents Panorama from receiving match criteria. If Panorama displays no match criteria
and you are using browser extensions, disable the extensions and Synchronize Dynamic
Objects to populate the tags available to Panorama.
STEP 10 | You can update the dynamic objects from vCenter at any time by synchronizing dynamic
objects. Synchronizing dynamic objects enables you to maintain context on changes in the
virtual environment and allows you to enable applications by automatically updating the
Dynamic Address Groups used in policy rules.
1. Select Panorama > VMware vCenter > Monitoring Definition.
2. Click Synchronize Dynamic Objects.
STEP 11 | If a firewall in your vCenter deployment restarts or disconnects from Panorama, that firewall
goes out of sync with the Panorama plugin for vCenter and no receive updates. After the
firewall reconnects with Panorama, you must manually synchronize Panorama and the
firewall.
1. Log in to the Panorama CLI.
2. Execute the following command.
admin@Panorama> request plugins vmware_vcenter sync
Basic Troubleshooting
Recommendation for Network Troubleshooting Tools
It is useful to have a separate troubleshooting station to capture traffic or inject test packets
in the virtualized environment. It can be helpful to build a fresh OS from scratch with common
troubleshooting tools installed such as tcpdump, nmap, hping, traceroute, iperf, tcpedit,
netcat, etc. This machine can then be powered down and converted to a template. Each time
the tools are needed, the troubleshooting client (virtual machine) can be quickly deployed to
the virtual switch(es) in question and used to isolate networking problems. When the testing
is complete, the instance can simply be discarded and the template used again the next time
it is required.
For performance related issues on the firewall, first check the Dashboard from the firewall web interface.
To view alerts or create a tech support or stats dump files navigate to Device > Support.
For information in the vSphere client go to Home > Inventory > VMs and Templates, select the VM-Series
firewall instance and click the Summary tab. Under Resources, check the statistics for consumed memory,
CPU and storage. For resource history, click the Performance tab and monitor resource consumption over
time.
Installation Issues
• Issues with Deploying the OVA
• Why does the firewall boot into maintenance mode?
• How do I modify the base image file for the VM-1000-HV license?
How do I modify the base image file for the VM-1000-HV license?
If you have purchased the VM-1000-HV license and are deploying the VM-Series firewall in standalone
mode on a VMware ESXi server, use these instructions to modify the following attributes that are defined in
the base image file (.ova or .xva) of the VM-Series firewall.
Important: Modifying values other than those listed here invalidates the base image file.
STEP 1 | Open the base image file, for example 7.0.0, with a text editing tool such as notepad.
STEP 2 | Search for 4096 and change the memory allocated to 5012 (that is 5 GB) as follows:
<Item>
<rasd:AllocationUnits>byte * 2^20</rasd:AllocationUnits>
<rasd:Description>Memory Size</rasd:Description>
<rasd:ElementName>4096MB of memory</rasd:ElementName>
<rasd:InstanceID>2</rasd:InstanceID>
<rasd:ResourceType>4</rasd:ResourceType>
<rasd:VirtualQuantity>4096</rasd:VirtualQuantity>
<Item>
<rasd:AllocationUnits>byte * 2^20</rasd:AllocationUnits>
<rasd:Description>Memory Size</rasd:Description>
<rasd:ElementName>5120MB of memory</rasd:ElementName>
<rasd:InstanceID>2</rasd:InstanceID>
<rasd:ResourceType>5</rasd:ResourceType>
<rasd:VirtualQuantity>5120</rasd:VirtualQuantity>
STEP 3 | Change the number of virtual CPU cores allotted from 2 to 4 or 8 as desired for your
deployment:
<Item>
<rasd:AllocationUnits>hertz * 10^6</rasd:AllocationUnits>
<rasd:Description>Number of Virtual CPUs</rasd:Description>
<rasd:ElementName>2 virtual CPU(s)</rasd:ElementName>
<rasd:InstanceID>1</rasd:InstanceID>
<rasd:ResourceType>3</rasd:ResourceType>
Alternatively, you can deploy the firewall, and before you power on the VM-Series firewall, edit the
memory and virtual CPU allocation directly on the ESXi host or the vCenter server.
Licensing Issues
• Why am I unable to apply the support or feature license?
• Why does my cloned VM-Series firewall not have a valid license?
• Does moving the VM-Series firewall cause license invalidation?
Connectivity Issues
• Why is the VM-Series firewall not receiving any network traffic?
$ ethtool -I vNIC4
driver: ixgbe
version: 3.21.6iov
firmware-version: 0x80000389
bus-info: 0000:04:00.0
• esxcli—esxcli network nic get -n <nic-name>
You must specify the absolute path to the .zip or .vib file. For example:
To support DPDK, all data interfaces must be using the same driver.
To take advantage of DPDK, you must use a NIC with one of the supported DPDK drivers mentioned in
DPDK Driver Versions:
If you disable DPDK, the NIC uses PacketMMap instead of DPDK. You can disable DPDK using the
command set system setting dpdk-pkt-io off.
See the Compatibility Matrix for ESXi hypervisor support and PacketMMAP and DPDK driver support by
PAN-OS version.
STEP 1 | On the host system, set up the physical and virtual function to operate in VLAN access mode.
1. Click Networking in the VMware Host Client inventory and click Port groups.
2. In the list that you want to edit, right-click the port group and select Edit settings.Enter a new port
group Name.Enter a new value for the VLAN ID.
ethernetX.pnicFeatures = “4”
$ vmkload_mod -u ixgbe
$ vmkload_mod ixgbe RSS=”4,4,4,4,4,4”
STEP 3 | For the best performance, allocate additional CPU threads per ethernet/vSwitch device. This is
limited by the amount of spare CPU resources available on the ESXi host.
1. Open the .vmx file.
2. Add the following parameter:
ethernetX.ctxPerDev = “1”
This guidance might not apply to VM-Series deployments on top of white-box or grey-box
environments targeting SD-WAN, MSSP, or CSSP use-cases.
• BIOS Settings
• Physical Settings
• Virtual NIC Settings
• NUMA and Resource Considerations
BIOS Settings
This section recommends BIOS Power Management, Hyperthreading, and Intel VT-D settings that can
enhance VM-Series firewall performance, and concludes with a sample BIOS configuration.
• Power Management
• Hyperthreading
• Intel Virtualization Technology for Directed I/O
Power Management
For latency-sensitive applications, any form of power management adds latency to the path where an idle
system (in one of several power-saving modes) responds to an external event. VMware recommends setting
the BIOS power management setting to “static high performance” (no OS-controlled power management),
effectively disabling any form of active power management. Servers with Intel Nehalem class and later
CPUs (Intel Xeon 55xx and later) offer two other power management options: C-states and Intel Turbo
Boost.
Leaving C-states enabled can increase memory latency and is therefore not recommended for low-latency
workloads. Even the enhanced C-state, known as C1E, introduces longer latencies to wake up the CPUs
from halt (idle) states to full-power. VMware recommends disabling C1E in the BIOS to further lower
latencies.
• For HP, set Power Regulator Mode to Static High Mode and disable QPI Processor, C-state support, and
C1E Support.
• For Dell, set Power Management Mode, CPU power, and Performance Management to Maximum
Performance.
Another parameter to consider is P-states. For outright performance considerations, disable P-state settings
on BIOS.
Intel Turbo Boost can lead to performance variations over a period of time. For consistent and deterministic
performance, disable Turbo Boost.
Hyperthreading
If the hardware and BIOS support hyperthreading, ESXi automatically enables hyperthreading on hosts. For
the best performance from VM series firewalls, disable hyperthreading on ESXi hosts.
If the deployment environment warrants enabling hyperthreading, then ensure that all CPU resources for
the VM-Series firewall are reserved from the same NUMA/Socket node that has access to the PCI devices.
In general, configure the PA-VM as a single NUMA VM. See NUMA and Resource Considerations for more
details.
• Transmit Queue
• Queue Pairing
Transmit Queue
The ESXi uplink pNIC layer also maintains a software Tx queue of packets queued for transmission, which
by default holds 500 packets. If the workload is I/O intensive with large bursts of transmit packets, this
queue can overflow, leading to packets being dropped in the uplink layer. The Tx queue size can be
increased up to 10,000 packets with the following ESXi command:
Depending on the physical NIC and the specific version of the ESXi driver being used on the ESXi host,
sometimes packets can be dropped in the pNIC driver because the transmit ring on the pNIC is too small
This command increases the Tx ring size to 4096 entries. The maximum size you can set for a specific pNIC
driver, as well as the current Tx ring size in effect, can be determined using the following command:
# ethtool -g vmnic0
Pre-set maximums:
RX: 4096
RX Mini: 0
RX Jumbo: 0
TX: 4096
Current hardware settings:
RX: 512
RX Mini: 0
RX Jumbo: 0
TX: 4096
Queue Pairing
Some pNIC drivers, such as Intel’s ixgbe and Broadcom’s bnx2x, also support “queue pairing”, which
indicates to the ESXi uplink layer that the receive thread (NetPoll) will also process completion of
transmitted packets on a paired transmit queue. For certain transmit-heavy workloads, this can cause
delays in processing transmit completions, causing the transmit ring for the vNIC to run out of room for
transmitting additional packets, and forcing the vNIC driver in the guest OS to drop packets.
Disabling queue pairing for all pNICs on an ESXi host creates a separate thread for processing pNIC transmit
completions. As a result, completions are processed in a timely manner, freeing space in the vNIC’s transmit
ring to transmit additional packets.
The ESXi command to disable queue pairing is:
For this to take effect, you must reboot the ESXi host.
ethernetX.pnicFeatures = “4”
Setting ethernetX.ctxPerDev = “1”, is like a binary flag (set to 1 to enable). This binary flag adds a
CPU thread to process traffic only from the port ethernetX. This leads to improved traffic scheduling
performance.
NUMA and Resource Considerations
NUMA is Non-Uniform Memory Access. Multi-Core processors have complicated designs. To tackle
performance issues in such systems, you need to be aware of all NUMA and CPU Pinning nuances. Vital
aspects to look for:
• Which cores are our threads are running on? (if hyperthreading is enabled, check Hyperthreading)
• Which cores are our vCPUs are running on? (affinity)
• In which NUMA socket is the physical NIC card installed?
• Where has memory been allocated? (NUMA effects)
Threads running on any socket see one unified memory space – therefore they can read/write to
memory that is local to other Sockets.
• Is memory shared between different sockets on a node?
• It takes more time to access memory on different sockets than it takes to access local memory.
NUMA effects occur when threads excessively access memory on a different NUMA domain. To avoid
cross-NUMA issues, avoid Quick Path Interconnect (QPi) between Socket 0 communication and Socket
1.
For latency-sensitive VMs like PA-VM, VMware recommends that you do not over-commit vCPUs as
compared to the number of physical CPUs (processors) on the ESXi host. For example, if the host has 8 CPU
cores, limit the number of vCPUs for your VM to 7. This ensures that the ESXi VMkernel scheduler has a
better chance of placing the vCPUs on pCPUs that won’t contend with other scheduling contexts, such as
vCPUs from other VMs or ESXi helper worlds. It is a good practice to ensure that the number of vCPUs you
allocate to the VM does not exceed the number of active CPU-consuming processes or threads in the VM.
For best performance, all vCPUs should be scheduled on the same NUMA node and all VM memory should
fit and be allocated out of the local physical memory attached to that NUMA node. This can be changed
using the VM setting numa.nodeAffinity=0, 1, … where 0, 1, and so forth, are the socket numbers.
To ensure that the VM gets exclusive access to the CPU resources, set Latency Sensitivity to High. For the
new setting to take effect, the VM CPU reservation must be set to maximum, Memory should be reserved,
and the CPU limit must be set to unlimited.
• In newer versions, use the vSphere Web Client to set the VM Latency Sensitivity option to High (the
default is Normal).
• In older versions, set sched.cpu.latencySensitivity to High.
Use Cases
Use Case 1: vSwitch Deployment
The figure below shows a deployment of a PA-VM on an ESXi host where the data ports “Port 1” and “Port
2” are linked to eth1 and eth2 of the PA-VM. Each port hosts two queue pairs (for example, Tx0/Rx0, and
Tx1/Rx1) or has multiqueue enabled.
In SR-IOV the compatible physical NIC port (manifests as a Physical Function) is essentially carved out
into multiple interfaces (manifests as Virtual Functions). The figure above shows that NIC1 Port1 has
a VF named VFX that is associated as one of the PAVM dataplane interfaces — eth1, for example. A
similar association is created for Port2 VF to PAVM eth2.The chain of packet processing is similar to
that of the deployment in the vSwitch environment. The only difference is that the SR-IOV VF drivers
should be compatible with those used in PAN-OS. Also, since there is no internal vSwitch (in the host)
switching traffic, there is no need to set a dedicated thread for traffic scheduling from a port (that is,
ethernetX.ctxPerDev = 1 is not required in this setting). Interfaces with SR-IOV and DPDK will yield
even higher packet processing performance than the vSwitch use case.
References
• Tuning VMware vCloud NFV for Data-Intensive Workloads
• Best Practices for Performance Tuning of Telco and NFV Workloads in vSphere
• Potential Issues with CPU Affinity
• Interpreting esxtop Statistics
147
148 VM-SERIES DEPLOYMENT GUIDE | Set Up the VM-Series Firewall on vCloud Air
© 2021 Palo Alto Networks, Inc.
About the VM-Series Firewall on vCloud Air
You can deploy the VM-Series firewall in a virtual data center (vDC) on VMware vCloud Air using the
vCloud Air portal or from the vCloud Director portal. And to centrally manage all your physical and VM-
Series firewalls, you can use an existing Panorama or deploy a new Panorama on premise or on vCloud Air.
The VM-Series firewall on vCloud Air requires the following:
• ESXi version of the software image, an Open Virtualization Alliance (OVA) file, from the Palo Alto
Networks Customer Support web site. Currently, the vCloud Air Marketplace does not host the software
image.
In order to efficiently deploy the VM-Series firewall, include the firewall software image in a vApp. A
vApp is a container for preconfigured virtual appliances (virtual machines and operating system images)
that is managed as a single object. For example, if your vApp includes a set of multi-tiered applications
and the VM-Series firewall, each time you deploy the vApp, the VM-Series firewall automatically secures
the web server and database server that get deployed with the vApp.
• License and subscriptions purchased from a partner, reseller, or directly from Palo Alto Networks, in the
Bring Your Own License (BYOL) model; the usage-based licensing for the VM-Series on vCloud Air is not
available.
• Due to the security restrictions imposed on vCloud Air, the VM-Series firewall on vCloud Air is best
deployed with Layer 3 interfaces and the interfaces must be enabled to use the hypervisor assigned
MAC address. If you do not enable hypervisor assigned MAC address, the VMware vSwitch cannot
forward traffic to the dataplane interfaces on the VM-Series firewall because the vSwitch on vCloud
Air does not support promiscuous mode or MAC forged transmits. The VM-Series firewall cannot be
deployed with tap interfaces, Layer 2 interfaces, or virtual wire interfaces.
The VM-Series firewall on vCloud Air can be deployed in an active/passive high availability configuration.
However, the VM-Series firewall on vCloud Air does not support VM Monitoring capabilities for virtual
machines that are hosted on vCloud Air.
To learn all about vCloud Air, refer to the VMware vCloud Air documentation.
VM-SERIES DEPLOYMENT GUIDE | Set Up the VM-Series Firewall on vCloud Air 149
© 2021 Palo Alto Networks, Inc.
Deployments Supported on vCloud Air
To enable applications safely, block known and unknown threats, and to keep pace with changes in your
environment, you can deploy the VM-Series firewall on vCloud Air with Layer 3 interfaces in the following
ways:
• Secure the virtual data center perimeter—Deploy the VM-Series firewall as a virtual machine that
connects isolated and routed networks on vCloud Air. In this deployment the firewall secures all north-
south traffic traversing the infrastructure on vCloud Air.
• Set up a hybrid cloud—Extend your data center and private cloud into vCloud Air and use a VPN
connection to enable communication between the corporate network and the data center. In this
deployment, the VM-Series firewall uses IPSec to encrypt traffic and secure users accessing the cloud.
• Secure traffic between application subnets in the vDC—To improve security, segment your network
and isolate traffic by creating application tiers, and then deploy the VM-Series firewall to protect against
lateral threats between subnets and application tiers.
The following illustration combines all three deployments scenarios and includes Panorama. Panorama
streamlines policy updates, centralizes policy management, and provides centralized logging and reporting.
150 VM-SERIES DEPLOYMENT GUIDE | Set Up the VM-Series Firewall on vCloud Air
© 2021 Palo Alto Networks, Inc.
Deploy the VM-Series Firewall on vCloud Air
Use the instructions in this section to deploy your VM-Series firewall in an on-demand or dedicated vDC
on vCloud Air. This procedure assumes that you have set up your vDC, including the gateways required
to allow traffic in and out of the vDC, and the networks required for routing management traffic and data
traffic through the vDC.
STEP 1 | Obtain the VM-Series OVA image from the Palo Alto Networks Customer Support web site;
the vCloud Air Marketplace does not host the software image currently.
1. Go to: www.paloaltonetworks.com/services/support.html.
2. Filter by PAN-OS for VM-Series Base Images and download the OVA image. For example, PA-VM-
ESX-9.1.0.ova.
STEP 2 | Extract the Open Virtualization Format (OVF) file from the OVA image and import the OVF file
in to your vCloud Air catalog.
When extracting files from the OVA image, make sure to place all the files—.mf, .ovf, and .vmdk—within
the same directory.
For instructions to extract the OVF file from the OVA image, refer to the VMware documentation:
https://www.vmware.com/support/developer/ovf/#sthash.WUp55ZyE.dpuf
When you import the OVF file, the software image for the VM-Series firewall is listed in My
Organization’s Catalogs.
VM-SERIES DEPLOYMENT GUIDE | Set Up the VM-Series Firewall on vCloud Air 151
© 2021 Palo Alto Networks, Inc.
STEP 4 | Create a vDC and a vApp that includes the VM-Series firewall.
1. Log in to vCloud Air.
2. Select VPC OnDemand and select the location in which you want to deploy the VM-Series firewall.
3. Select Virtual Data Centers and click + to add a new Virtual Data Center.
4. Select the vDC, right click and select Manage Catalogs in vCloud Director. You will be redirected to
the vCloud Director web interface.
5. Create a new vApp that contains one or more virtual machines including the VM-Series firewall:
1. Select My Cloud > vApps, and click Build New vApp.
2. Select Name and Location, and the Virtual Datacenter in which this vApp will run. By default,
Leases for runtime and storage never expire and the vApp is not automatically stopped.
3. Add Virtual Machines. To add the VM-Series firewall image from the Look in: drop-down, select
My Organization’s Catalog, select the image and click Add. Click Next
4. Configure Resources to specify the Storage Policies for the virtual machines when deployed. The
VM-Series firewall uses the Standard option.
5. Configure the Virtual Machines. Name each virtual machine and select the network to which
you want it to connect. You must connect NIC 0 (for management access) to the default routed
network; NIC 1 is used for data traffic. You can add additional NICs later.
6. Verify the settings and click Finish.
7. Continue to step 6.
152 VM-SERIES DEPLOYMENT GUIDE | Set Up the VM-Series Firewall on vCloud Air
© 2021 Palo Alto Networks, Inc.
1. In the Look in: drop-down, choose My Organization’s Catalog, select the VM-Series firewall image
and click Add. Click Next.
2. Click Next to skip Configure Resources. The VM-Series firewall uses the Standard option and you
do not to modify the Storage Policy.
3. Enter a Name for the firewall and for management access (NIC 0), select the default routed
network and the IP Mode— Static or DHCP. You can configure NIC 1 and add additional NICs in
step 6. Click Next.
4. Verify how this vApp connects to the vDC— Gateway Address and Network Mask for the virtual
machines in this vApp.
5. Verify that you have added the VM-Series firewall and click Finish.
6. Continue to step 6.
STEP 6 | Connect the data interface(s) of the VM-Series firewall to an isolated or a routed network, as
required for your deployment.
1. In vCloud Director, select My Cloud > vApps and select the vApp you just created or edited.
2. Select Virtual Machines and select the VM-Series firewall. Then, right-click and select Properties.
3. Select Hardware, scroll to the NICs section and select NIC 1.
4. Attach the dataplane network interface to a vApp network or an organizational VDC network based
on your connectivity needs for data traffic to the VM-Series firewall. To create a new network:
1. In the Network drop-down, click Add Network.
2. Select the Network Type and give it a name and click OK.
3. Verify that the new network is attached to the interface.
5. To add additional NICs to the firewall, click Add and repeat step 4 above. You can attach a maximum
of seven dataplane interfaces to the VM-Series firewall.
6. Verify that the management interface of the VM-Series firewall is attached to the default routed
subnet on the vDC and at least one dataplane interface is connected to a routed or isolated network.
1. Select My Cloud > vApps and double-click the Name of the vApp you just edited.
2. Verify network connectivity in the vApp Diagram.
VM-SERIES DEPLOYMENT GUIDE | Set Up the VM-Series Firewall on vCloud Air 153
© 2021 Palo Alto Networks, Inc.
STEP 7 | (Optional) Edit the hardware resources allocated for the VM-Series firewall.
Required only if you need to allot additional CPU, memory, or hard disk to the firewall.
1. Select My Cloud > vApps and double-click the Name of the vApp you just deployed.
2. Select Virtual Machine and click on the Name of the VM-Series firewall to access the Virtual Machine
Properties.
STEP 10 | Define NAT rules on the vCloud Air Edge Gateway to enable Internet access for the VM-
Series firewall.
1. Select Virtual Data Centers > Gateways, select the gateway and double-click to add NAT Rules.
2. Create two DNAT rules. One for allowing SSH access and one for HTTPS access to the management
port’s IP address on the VM-Series firewall.
154 VM-SERIES DEPLOYMENT GUIDE | Set Up the VM-Series Firewall on vCloud Air
© 2021 Palo Alto Networks, Inc.
3. Create a SNAT rule for translating the internal source IP address for all traffic initiated from the
management port on the VM-Series firewall to an external IP address.
To send and receive traffic from the dataplane interfaces on the firewall, you must
create additional DNAT and SNAT rules on the vCloud Air Edge Gateway.
STEP 12 | Add the auth code(s) to activate the licenses on the firewall.
Activate the License.
STEP 13 | Configure the VM-Series firewall to use the hypervisor assigned MAC address.
Hypervisor Assigned MAC Addresses
VM-SERIES DEPLOYMENT GUIDE | Set Up the VM-Series Firewall on vCloud Air 155
© 2021 Palo Alto Networks, Inc.
156 VM-SERIES DEPLOYMENT GUIDE | Set Up the VM-Series Firewall on vCloud Air
Set Up the VM-Series Firewall on VMware
NSX
The VM-Series firewall can be deployed in both versions of VMware’s network virtualization
solution—NSX-V and NSX-T.
157
158 VM-SERIES DEPLOYMENT GUIDE | Set Up the VM-Series Firewall on VMware NSX
© 2021 Palo Alto Networks, Inc.
Set Up the VM-Series Firewall on VMware
NSX-V
The VM-Series firewall for VMware NSX-V is jointly developed by Palo Alto Networks and VMware. This
solution uses the NetX API to integrate the Palo Alto Networks next-generation firewalls and Panorama
with VMware ESXi servers to provide comprehensive visibility and safe application enablement of all data
center traffic including intra-host virtual machine communications.
The following topics provide information about the VM-Series for NSX-V:
• VM-Series for Firewall NSX-V Overview
• VM-Series Firewall for NSX-V Deployment Checklist
• Install the VMware NSX Plugin
• Register the VM-Series Firewall as a Service on the NSX-V Manager
• Deploy the VM-Series Firewall
• Create Security Groups and Steering Rules
• Apply Security Policies to the VM-Series Firewall
• Steer Traffic from Guests that are not Running VMware Tools
• What is Multi-NSX Manager Support on the VM-Series for NSX-V?
• Add a New Host to Your NSX-V Deployment
• Dynamically Quarantine Infected Guests
• Migrate Operations-Centric Configuration to Security-Centric Configuration
• Use Case: Shared Compute Infrastructure and Shared Security Policies
• Use Case: Shared Security Policies on Dedicated Compute Infrastructure
• Dynamic Address Groups—Information Relay from NSX-V Manager to Panorama
VM-SERIES DEPLOYMENT GUIDE | Set Up the VM-Series Firewall on VMware NSX 159
© 2021 Palo Alto Networks, Inc.
• Ports/Protocols used Network Communication
VMware Components
vCenter Server The vCenter server is the centralized management tool for the vSphere suite.
NSX-V Manager VMware's Networking and Security platform must be installed and registered
with the vCenter server. The NSX-V Manager is required to deploy the VM-
Series firewall on the ESXi hosts within a ESXi cluster.
See the Palo Alto Networks Compatibility Matrix for supported software versions.
PAN-OS The VM-Series base image (PA-VM-NSX-9.1.zip) is used for deploying the VM-
Series firewall for NSX-V with PAN-OS 9.1.
The minimum system requirement for deploying the VM-Series firewall for NSX-
V on the ESXi server depends on your VM-Series model. See VM-Series System
Requirements for the minimum hardware requirements for your VM-Series
model.
Panorama Panorama is the centralized management tool for the Palo Alto Networks next-
generation firewalls. In this solution, Panorama works with the NSX-V Manager
Panorama must be
to deploy, license, and centrally administer—configuration and policies—on the
running the same
VM-Series firewall for NSX-V.
release version or
later version that Panorama must be able to connect to the NSX-V Manager, the vCenter server,
the firewalls that it the VM-Series firewalls and the Palo Alto Networks update server.
will manage.
The resources required by Panorama depend on the mode Panorama will run in:
Panorama or Management Only. Panorama installations running in Legacy mode
prior to upgrade remain in Legacy mode after upgrading to 10.0.
See the Panorama Administrator’s Guide for information about deploying your
Panorama appliance.
VM-Series Firewall The VM-100, VM-200, VM-300, VM-500, and VM-1000-HV, support NSX-V.
for NSX-V
vCenter Server
The vCenter server is required to manage the NSX-V Manager and the ESXi hosts in your data center. This
joint solution requires that the ESXi hosts be organized into one or more clusters on the vCenter server and
must be connected to a distributed virtual switch.
For information on clusters, distributed virtual switch, DRS, and the vCenter server, refer to your VMware
documentation: http://www.vmware.com/support/vcenter-server.html
160 VM-SERIES DEPLOYMENT GUIDE | Set Up the VM-Series Firewall on VMware NSX
© 2021 Palo Alto Networks, Inc.
NSX-V Manager
NSX-V is VMware’s network virtualization platform that is completely integrated with vSphere. The NSX-
V Firewall and the Service Composer are key features of the NSX-V Manager. The NSX-V firewall is a
logical firewall that allows you to attach network and security services to the virtual machines, and the
Service Composer allows you to group virtual machines and create policy to redirect traffic to the VM-
Series firewall (called the Palo Alto Networks NGFW service on the NSX-V Manager).
Panorama
Panorama is used to register the VM-Series firewall for NSX-V as the Palo Alto Networks NGFW service on
the NSX-V Manager. Registering the Palo Alto Networks NGFW service on the NSX-V Manager allows the
NSX-V Manager to deploy the VM-Series firewall for NSX-V on each ESXi host in the ESXi cluster.
Panorama serves as the central point of administration for the VM-Series firewalls running on NSX-V.
When a new VM-Series firewall is deployed in NSX-V, it communicates with Panorama to obtain the license
and receives its configuration/policies from Panorama. All configuration elements, policies, and dynamic
address groups on the VM-Series firewalls can be centrally managed on Panorama using Device Groups and
Template Stacks. The REST-based XML API integration in this solution, enables Panorama to synchronize
with the NSX-V Manager and the VM-Series firewalls to allow the use of dynamic address groups and share
context between the virtualized environment and security enforcement. For more information, see Policy
Enforcement using Dynamic Address Groups.
VM-Series Firewall for NSX-V
The VM-Series firewall for NSX-V is the VM-Series firewall that is deployed on the ESXi hypervisor. The
integration with the NetX API makes it possible to automate the process of installing the VM-Series firewall
directly on the ESXi hypervisor, and allows the hypervisor to forward traffic to the VM-Series firewall
without using the vSwitch configuration; it therefore, requires no change to the virtual network topology.
The VM-Series firewall for NSX-V only supports virtual wire interfaces. On this firewall, ethernet 1/1 and
ethernet 1/2 are bound together through a virtual wire and use the NetX dataplane API to communicate
with the hypervisor. Layer 2 or Layer 3 interfaces are neither required nor supported on the VM-Series
firewall for NSX-V, and therefore no switching or routing actions can be performed by the firewall.
For enabling traffic separation in a multi-tenancy environment, you can create additional zones that
internally map to a pair of virtual wire subinterfaces on the parent virtual wire interfaces, ethernet 1/1 and
ethernet 1/2.
VM-SERIES DEPLOYMENT GUIDE | Set Up the VM-Series Firewall on VMware NSX 161
© 2021 Palo Alto Networks, Inc.
• vCenter Server The vCenter Server must be able to reach the deployment web server that is hosting the
VM-Series OVA. The port is TCP/80 by default or App-ID web-browsing.
1. Register the Palo Alto Networks NGFW service—The first step is to register the Palo Alto Networks
NGFW as a service on the NSX-V Manager. The registration process uses the NetX management plane
API to enable bi-directional communication between Panorama and the NSX-V Manager. Panorama
is configured with the IP address and access credentials to initiate a connection and register the Palo
Alto Networks NGFW service on the NSX-V Manager. The service definition includes the URL for
accessing the VM-Series base image that is required to deploy the VM-Series firewall for NSX-V, the
authorization code for retrieving the license and the device group and template stacks to which the
VM-Series firewalls will belong. The NSX-V manager uses this management plane connection to share
updates on the changes in the virtual environment with Panorama.
2. Deploy the VM-Series automatically from NSX-V—The NSX-V Manager collects the VM-Series base
image from the URL specified during registration and installs an instance of the VM-Series firewall
on each ESXi host in the ESXi cluster. From a static management IP pool or a DHCP service (that you
define on the NSX-V Manager), a management IP address is assigned to the VM-Series firewall and
the Panorama IP address is provided to the firewall. When the firewall boots up, the NetX dataplane
integration API connects the VM-Series firewall to the hypervisor so that it can receive traffic from the
vSwitch.
3. Establish communication between the VM-Series firewall and Panorama—The VM-Series firewall then
initiates a connection to Panorama to obtain its license. Panorama retrieves the license from the update
server and pushes it to the firewall. The VM-Series firewall receives the license and reboots with a valid
serial number.
If your Panorama is offline, which means that it does not have direct Internet access to
retrieve the licenses and push them to the firewalls, you must manually license each
firewall. If your VM-Series firewall does not have internet access, you must add the serial
number of the firewall to Panorama so that it is registered as a managed device, so that
you can push the appropriate template stacks and device group settings from Panorama.
4. Install configuration/policy from Panorama to the VM-Series firewall—The VM-Series firewall
reconnects with Panorama and provides its serial number. Panorama now adds the firewall to the device
group and template stack that was defined in the service definition and pushes the configuration and
162 VM-SERIES DEPLOYMENT GUIDE | Set Up the VM-Series Firewall on VMware NSX
© 2021 Palo Alto Networks, Inc.
policy rules to the firewall. The VM-Series firewall is now available as a security virtual machine that can
be further configured to safely enable applications on the network.
5. Push traffic redirection rules to NSX-V Manager—Create security groups and define network
introspection rules that specify the guests from which traffic will be steered to the VM-Series firewall.
See Integrated Policy Rules for details.
To ensure that traffic from the guests is steered to the VM-Series firewall, you must
have VMware Tools installed on each guest. If VMware Tools is not installed, the NSX-
V Manager does not know the IP address of the guest and therefore, the traffic cannot
be steered to the VM-Series firewall. For more information, see Steer Traffic from Guests
that are not Running VMware Tools. This is not required if you are running NSX-V
Manager 6.2.4 or later.
6. Receive real-time updates from NSX-V Manager—The NSX-V Manager sends real-time updates on the
changes in the virtual environment to Panorama. These updates include information on the security
groups and IP addresses of guests that are part of the security group from which traffic is redirected to
the VM-Series firewall. See Integrated Policy Rules for details.
7. Use dynamic address groups in policy and push dynamic updates from Panorama to the VM-Series
firewalls—On Panorama, use the real-time updates on security groups to create dynamic address groups,
bind them to security policies and then push these policies to the VM-Series firewalls. Every VM-Series
firewall in the device group will have the same set of policies and is now completely marshaled to secure
the SDDC. See Policy Enforcement using Dynamic Address Groups for details.
Integrated Policy Rules
Panorama serves as the single point of configuration that provides the NSX-V Manager with the contextual
information required to redirect traffic from the guest virtual machines to the VM-Series firewall. The traffic
steering rules are defined on Panorama and pushed to NSX-V Manager; these determine what traffic from
which guests in the cluster are steered to the Palo Alto Networks NGFW service. Security enforcement
rules are also defined on Panorama and pushed to the VM-Series firewalls for the traffic that is steered to
the Palo Alto Networks NGFW service.
• Steering Rules—The rules for directing traffic from the guests on each ESXi host are defined on
Panorama and applied by NSX-V Manager as partner security services rules.
For traffic that needs to be inspected and secured by the VM-Series firewall, the steering rules created
on Panorama allow you to redirect the traffic to the Palo Alto Networks NGFW service. This traffic is
then steered to the VM-Series firewall and is first processed by the VM-Series firewall before it goes to
the virtual switch.
Traffic that does not need to be inspected by the VM-Series firewall, for example network data backup
or traffic to an internal domain controller, does not need to be redirected to the VM-Series firewall and
can be sent to the virtual switch for onward processing.
• Rules centrally managed on Panorama and applied by the VM-Series firewall—The next- generation
firewall rules are applied by the VM-Series firewall. These rules are centrally defined and managed on
Panorama using template stacks and device groups and pushed to the VM-Series firewalls. The VM-
Series firewall then enforces security policy by matching on source or destination IP address—the use
of dynamic address groups allows the firewall to populate the members of the groups in real time—and
forwards the traffic to the filters on the NSX-V Firewall.
To understand how the NSX-V Manager and Panorama stay synchronized with the changes in the
SDDC and ensure that the VM-Series firewall consistently enforces policy, see Policy Enforcement using
Dynamic Address Groups.
VM-SERIES DEPLOYMENT GUIDE | Set Up the VM-Series Firewall on VMware NSX 163
© 2021 Palo Alto Networks, Inc.
Policy Enforcement using Dynamic Address Groups
Unlike the other versions of the VM-Series firewall, because both virtual wire interfaces (and subinterfaces)
belong to the same zone, the VM-Series firewall for NSX-V uses dynamic address groups as the traffic
segmentation mechanism. A security policy rule on the VM-Series firewall for NSX-V must have the same
source and destination zone, therefore to implement different treatment of traffic, you use dynamic address
groups as source or destination objects in security policy rules.
Dynamic address groups offer a way to automate the process of referencing source and/or destination
addresses within security policies because IP addresses are constantly changing in a data center
environment. Unlike static address objects that must be manually updated in configuration and committed
whenever there is an address change (addition, deletion, or move), dynamic address groups automatically
adapt to changes.
Any dynamic address groups created in a device group belonging to NSX-V configuration and configured
with the match criterion _nsx_<dynamic address group name> trigger the creation on corresponding
security groups on the NSX-V Manager. In an ESXi cluster with multiple customers or tenants, the ability to
filter security groups for a service profile (zone on Panorama) on the NSX-V Manager allows you to enforce
policy when you have overlapping IP addresses across different security groups in your virtual environment.
If, for example, you have a multi-tier architecture for web applications, on Panorama you create three
dynamic address groups for the WebFrontEnd servers, Application servers and the Database servers. When
you commit these changes on Panorama, it triggers the creation of three corresponding security groups on
NSX-V Manager.
On NSX-V Manager, you can then add individual guest VMs or IP sets (IP ranges or subnets) to the
appropriate security groups. Then, in security policy you can use the dynamic address groups as source or
destination objects, define the applications that are permitted to traverse these servers, and push the rules
to the VM-Series firewalls.
Each time a guest is added or modified in the ESXi cluster or a security group is updated or created, the
NSX-V Manager uses the PAN-OS REST-based XML API to update Panorama with the IP address, and the
security group to which the guest belongs. To trace the flow of information, see Dynamic Address Groups—
Information Relay from NSX Manager to Panorama.
To ensure that the name of each security group is unique, the vCenter server assigns
a Managed Object Reference (MOB) ID to the name you define for the security group.
The syntax used to display the name of a security group on Panorama is serviceprofileid-
specified_name-securitygroup-number; for example, serviceprofile13-WebFrontEnd-
securitygroup-47.
164 VM-SERIES DEPLOYMENT GUIDE | Set Up the VM-Series Firewall on VMware NSX
© 2021 Palo Alto Networks, Inc.
When Panorama receives the API notification, it verifies/updates the IP address of each guest and the
security group and the service profile to which that guest belongs. Then, Panorama pushes these real-time
updates to all the firewalls that are included in the device group and notifies device groups in the service
manager configuration on Panorama.
On each firewall, all policy rules that reference these dynamic address groups are updated at runtime.
Because the firewall matches on the security group tag to determine the members of a dynamic address
group, you do not need to modify or update the policy when you make changes in the virtual environment.
The firewall matches the tags to find the current members of each dynamic address group and applies the
security policy to the source/destination IP address that are included in the group.
What are the Benefits of the NSX-V VM-Series firewall for NSX-V
Solution?
The VM-Series firewall for VMware NSX-V is focused on securing east-west communication in the
software-defined data center. Deploying the firewall has the following benefits:
• Sturdier Centralized Management—The firewalls deployed using this solution are licensed and managed
by Panorama, the Palo Alto Networks central management tool. Panorama serves as a single point
of configuration for integration with NSX-V. It gives the NSX-V Manager the information is it needs
to steer redirect traffic to the VM-Series firewall for inspection and enforcement. Using Panorama
to manage both the perimeter and data center firewalls (the hardware-based and virtual firewalls)
allows you to centralize policy management and maintain agility and consistency in policy enforcement
throughout the network.
• Automated Deployment—The NSX-V Manager automates the process of delivering next-generation
firewall security services and the VM-Series firewall allows for transparent security enforcement. When
a new ESXi host is added to a cluster, a new VM-Series firewall is automatically deployed, provisioned
and available for immediate policy enforcement without any manual intervention. The automated
workflow allows you to keep pace with the virtual machine deployments in your data center. The
hypervisor mode on the firewall removes the need to reconfigure the ports/ vswitches/ network
topology; because each ESXi host has an instance of the firewall, the traffic does not need to traverse
the network or be backhauled for inspection and consistent enforcement of policies.
• Ease in Administering Tenants in Shared and Dedicated Compute Infrastructure —This integration
provides the flexibility in configuring the firewall to handle multiple zones for traffic segmentation,
defining shared or specific policy sets for each tenant or sub-tenant, and includes support for
overlapping IP addresses across tenants or sub-tenants. Whether you have a shared cluster and need
to define tenant specific policies and logically isolate traffic for each tenant (or sub-tenant), or you have
a dedicated cluster for each tenant, this solution enables you to configure the firewall for your needs.
And if you need a dedicated instance of the VM-Series firewall for each tenant in a cluster that hosts the
workloads for multiple tenants, you can deploy multiple instances of the VM-Series firewall on each host
in an ESXi cluster. For more information, see What is Multi-Tenant Support on the VM-Series Firewall
for NSX-V?
• Tighter Integration Between Virtual Environment and Security Enforcement for Dynamic Security—
Dynamic address groups maintain awareness of changes in the virtual machines/applications and ensure
that security policy stays in tandem with the changes in the network. This awareness provides visibility
and protection of applications in an agile environment.
In summary, this solution ensures that the dynamic nature of the virtual network is secured with minimal
administrative overhead. You can successfully deploy applications with greater speed, efficiency, and
security.
VM-SERIES DEPLOYMENT GUIDE | Set Up the VM-Series Firewall on VMware NSX 165
© 2021 Palo Alto Networks, Inc.
you to secure multiple tenants, Panorama provides the flexibility to create multiple sets of security policy
rules for each tenant, and multiple zones to isolate traffic from each sub-tenant and redirect traffic to the
appropriately configured VM-Series firewall. You can also deploy more than one instance of the VM-Series
firewall on each host within an ESXi cluster.
Panorama and managed VM-Series firewalls must be running PAN-OS 7.1 or greater to
support multi-tenancy.
To deploy a multi-tenant solution, create one or more service definition(s) and service profile zone(s) on
Panorama. A service definition on Panorama specifies the configuration of the VM-Series firewall using
one device group and one template stack. This means that each instance of the VM-Series firewalls that is
deployed using a service definition has one common set of policy rules for securing the tenants and sub-
tenants in the ESXi cluster.
A service profile zone within a Panorama template stack is used to segment traffic from each sub-tenant
using virtual wire subinterfaces. When you create a new service profile zone, Panorama pushes the zone
as a part of the template stack configuration to the firewall, and the firewall automatically creates a pair
of virtual wire subinterfaces, for example ethernet1/1.3 and ethernet 1/2.3 so that the firewall can isolate
traffic for a sub-tenant. Because a template stack supports up to 32 subinterface pairs, you can logically
isolate traffic and secure up to 32 sub-tenants.
Panorama registers each service definition as a service definition on the NSX-V Manager and each service
profile zone as a service profile within the corresponding service definition. And, when you deploy the
service definition from the NSX-V Manager, an instance of the VM-Series firewall is deployed on each host
in the ESXi cluster. And you can use the steering rules defined on Panorama and applied to the NSX-V
Manager to specify what traffic to redirect to the VM-Series firewall based on NSX-V security groups, and
to which tenant or sub-tenant based on the service profile.
Based on your requirements, you can choose from the following multi-tenancy options:
• Shared cluster with shared VM-Series firewalls- Multiple tenants share the cluster and the VM-
Series firewall. A single instance of the VM-Series firewall is deployed on each host in the cluster. In
order to separate traffic from each tenant, you create a zone for each tenant, and you define a single,
common set of policy rules to secure the virtual machines for all tenants. See Use Case: Shared Compute
Infrastructure and Shared Security Policies.
• Dedicated cluster with dedicated VM-Series firewalls- A single tenant occupies the cluster, and a
single instance of the VM-Series firewall is deployed on each host in the cluster. In this deployment,
the tenant can have a single zone and a single policy set, or the tenant can have multiple zones for sub-
tenants that require traffic separation (one zone per sub-tenant) and a single policy set with zone-based
rules to secure traffic for each sub-tenant. Use Case: Shared Security Policies on Dedicated Compute
Infrastructure.
• Shared cluster with dedicated VM-Series firewalls- Multiple tenants share the cluster and multiple
instances of the VM-Series firewalls are deployed on each host in a cluster so that each tenant can
have a dedicated instance of the VM-Series firewall. This deployment provides scalability and better
performance on shared infrastructure for each tenant. Based on each tenant’s needs, you will define two
or more service definitions for the cluster.
When deploying multiple instances of the VM-Series firewall, you must ensure that each ESXi host has
the sufficient CPU, memory and hard disk resources required to support the VM-Series firewalls and the
other virtual machines that will be running on it.
166 VM-SERIES DEPLOYMENT GUIDE | Set Up the VM-Series Firewall on VMware NSX
© 2021 Palo Alto Networks, Inc.
• Set up the vCenter server, install and register the NSX-V Manager with the vCenter server.
If you have not already set up the virtual switch(es) and grouped the ESXi hosts in to clusters, refer to
the VMware documentation for instructions on setting up the vSphere environment. This document
does not take you through the process of setting up the VMware components of this solution.
Unless you Enable Large Receive Offload, do not modify the default value (1500
bytes) of the MTU on the virtual Distributed Switch (vDS) in the vSphere infrastructure.
Modifying the MTU to any other value causes the VM-Series firewall for NSX-V to
discard packets.
• Upgrade Panorama. If you are new to Panorama, refer to the Panorama documentation for
instructions on setting up and upgrading Panorama. See Migrate Operations-Centric Configuration to
Security-Centric Configuration if you choose to migrate your Operations-Centric configuration to a
Security-Centric configuration format.
• Configure an SSL/TLS Service Profile. If you are running NSX-V Manager 6.2.3 or earlier, you must
configure an SSL/TLS Service profile that allows TLSv1.0 and apply it to the Panorama management
interface. If you are running NSX-V Manager 6.2.4 or later, an SSL/TLS Service profile is not required.
• Install the VMware NSX Plugin.
• Install a License Deactivation API Key. Deleting the Palo Alto Networks Service Deployment on NSX-
V Manager automatically triggers license deactivation. A license deactivation API key is required to
successfully deactivate the VM-Series license.
• Download and save the ovf template for the VM-Series firewall for NSX-V on a web server. The ovf
template must match your VM-Series model. If you are using the VM-200, select the VM-100 ovf. If
using the VM-1000-HV, select the VM-300 ovf.
The NSX-V Manager must have network access to this web server so that it can deploy the VM-
Series firewall as needed. You cannot host the ovf template on Panorama.
Give the ova filename a generic name that does not include a version number. Using
a generic naming convention, such as https://acme.com/software/PA-VM-NSX.ova
allows you to overwrite the ova each time a newer version becomes available.
• Register the capacity auth-code for the VM-Series firewall for NSX-V with your support account on
the Support Portal. For details, see Upgrade the VM-Series Firewall.
Step 2: Register—Configure Panorama to Register the VM-Series Firewall as a Service on the NSX-V
Manager. When registered, the VM-Series firewall is added to the list of network services that can be
transparently deployed as a service by the NSX-V Manager. The connection between Panorama and the
NSX-V Manager is also required for licensing and configuring the firewall.
• (On Panorama) Create a service manager to enable communication between Panorama and NSX-V
Manager.
• (On Panorama) Create the service definition. If you upgrade from an earlier version, your existing
service definition is automatically migrated for you.
Step 3: Deploy the VM-Series Firewall—Before you can deploy the VM-Series firewall in NSX-V, each
host in the cluster must have the necessary NSX-V components required to deploy the firewall.
• (On NSX-V Manager) Define the IP address pool. An IP address from the defined range is assigned to
the management interface of each instance of the VM-Series firewall.
The NSX-V Manager uses the IP address as a match criterion to steer traffic to the
VM-Series firewall. If VMware tools is not installed on the guest, see Steer Traffic from
Guests that are not Running VMware Tools. This is not required if you are running
NSX-V Manager 6.2.4 or later.
• (On NSX-V Manager) Prepare the ESXi host for the VM-Series firewall.
• (On NSX-V Manager) Deploy the VM-Series firewall. The NSX-V Manager automatically deploys an
instance of the VM-Series firewall on each ESXi host in the cluster.
VM-SERIES DEPLOYMENT GUIDE | Set Up the VM-Series Firewall on VMware NSX 167
© 2021 Palo Alto Networks, Inc.
• (On NSX-V Manager) Add VMs to the relevant security groups.
• (On Panorama) Apply policies to the VM-Series firewall. From Panorama, you define, push, and
administer policies centrally on all the VM-Series firewalls. This centralized administration mechanism
allows you to secure guests/applications with minimal administrative intervention.
Step 4: Create Security Groups and Steering Rules—How you choose to deploy the security groups and
steering rules depends on whether your deployment focus is Security Centric or Operations Centric.
In a Security Centric deployment, your security administrator creates the security group and steering
rules in Panorama. You might start with an existing set of security policies and a set of named source
and destination groups. Any new dynamically deployed applications fit into predefined security
policies defined on Panorama. Panorama pushes these named groups to NSX-V Manager, where the
virtualization administrator picks up the group names and defines which VMs go into them.
In an Operations Centric deployment, security groups are defined by a virtualization administrator based
upon the need to classify and categorize VM workloads. In this case, security groups are defined and
populated in the NSX-V Manager. Security groups created in NSX-V Manager must be associated with
dynamic address groups on Panorama, which is completed after the firewalls are deployed. In this case,
NSX-V base functionality is deployed first and the VM-Series firewalls are added later.
You must decide whether a Security Centric or an Operations Centric deployment is right for your
NSX-V environment before continuing. This document describes the procedure for a Security Centric
deployment.
Security Centric—Create the service definition(s) that specify the configuration for the VM-Series
firewall, create dynamic address groups, and create policies to redirect traffic to the VM-Series firewall.
See Create Security Groups and Steering Rules in a Security Centric Deployment.
• (On Panorama) Set up the dynamic address groups that map to security groups on NSX-V Manager. A
security group assembles the specified guests/applications so that you can apply policy to the group.
• (On Panorama) Create the security policy rules to redirect traffic to the Palo Alto Networks service
profile.
Operations Centric—On the NSX-V Manager, create security groups and policies to redirect traffic
to the VM-Series firewall. See Create Security Groups and Steering Rules in an Operations Centric
Deployment.
• (On NSX-V Manager) Set up the security groups. A security group assembles the specified guests/
applications so that you can apply policy to the group.
• (On NSX-V Manager) Create the NSX-V Firewall policies to redirect traffic to the Palo Alto Networks
service profile.
Step 5: Monitor and Maintain Network Security—Panorama provides a comprehensive, graphical view
of network traffic. Using the visibility tools on Panorama—the Application Command Center (ACC),
logs, and the report generation capabilities—you can centrally analyze, investigate and report on all
network activity, identify areas with potential security impact, and translate them into secure application
enablement policies. Refer to the Panorama Administrator’s Guide for more information.
The following additional tasks are not required parts of the main VM-Series for NSX-V deployment
procedure and should only be completed if and when necessary for your deployment.
• Upgrade the Software Version—When upgrading the VM-Series firewalls for NSX-V, you must first
upgrade Panorama before upgrading the firewalls. To upgrade the firewalls, see Upgrade the PAN-OS
Software Version (VM-Series for NSX).
• For upgrading the PAN-OS version on the firewall, do not modify the VM-Series OVA
URL in Panorama > VMware Service Manager.
• Do not use the VMware snapshots functionality on the VM-Series firewall for NSX-V.
Snapshots can impact performance and result in intermittent and inconsistent packet
loss. See VMware’s best practice recommendation with using snapshots. If you need
168 VM-SERIES DEPLOYMENT GUIDE | Set Up the VM-Series Firewall on VMware NSX
© 2021 Palo Alto Networks, Inc.
configuration backups, use Panorama or Export named configuration snapshot from
the firewall (Device > Set up > Operations). Using the Export named configuration
snapshot exports the active configuration (running-config.xml) on the firewall and
allows you to save it to any network location.
• Migrate from Operations-Centric configuration to Security-Centric configuration—If you upgrade your
existing Operations-Centric VM-Series firewall for NSX-V deployment and plan to use the Security
Centric workflow going forward, Migrate Operations-Centric Configuration to Security-Centric
Configuration.
If you need to reinstall or remove the VM-Series from your NSX-V deployment, see the How to Remove
VM-Series Integration from VMware NSX-V knowledge base article.
If another version of the plugin is currently installed, selecting Install removes it and installs
the selected version.
STEP 2 | If you are upgrading your version of the VMware NSX plugin, complete a manual configuration
sync.
1. Select Panorama > VMware > NSX-V > Service Managers.
2. Select NSX Config-Sync in the Action column.
3. Click Yes.
4. When the sync is complete, click OK.
VM-SERIES DEPLOYMENT GUIDE | Set Up the VM-Series Firewall on VMware NSX 169
© 2021 Palo Alto Networks, Inc.
STEP 1 | (Optional) Bypass proxy server settings, configured on Panorama under Panorama > Setup >
Services > Proxy Server, for communication between Panorama and NSX-V Manager. This
command allows Panorama to communicate directly with NSX-V Manager while maintaining
proxied communication for other services. This feature requires Panorama plugin for VMware
NSX 2.0.5.
1. Log in to the Panorama CLI.
2. Execute the following command to enable or disable proxy bypass.
admin@Panorama> request plugins vmware_nsx global proxy bypass {yes | no}
Select yes to enable proxy bypass and no to disable proxy bypass.
The ampersand (&) special character is not supported in the NSX-V manager account
password. If a password includes an ampersand, the connection between Panorama
and NSX-V manager fails.
If you change your NSX-V Manager login password, ensure that you update the
password on Panorama immediately. An incorrect password breaks the connection
between Panorama and NSX-V Manager. Panorama does not receive updates about
changes to your deployment while disconnected from NSX-V Manager.
6. Click OK.
To view the connection status between Panorama and the NSX-V Manager.
1. Select Panorama > VMware > NSX-V > Service Managers.
2. Verify the message in the Status column.
When the connection is successful, the status displays as Registered. This indicates that Panorama
and the NSX-V Manager are in sync and the VM-Series firewall is registered as a service on the NSX-
V Manager.
The unsuccessful status messages are:
170 VM-SERIES DEPLOYMENT GUIDE | Set Up the VM-Series Firewall on VMware NSX
© 2021 Palo Alto Networks, Inc.
• Not connected: Unable to reach/establish a network connection to the NSX-V Manager.
• Invalid Credentials: The access credentials (username and/or password) are incorrect.
• Out of sync: The configuration settings defined on Panorama are different from what is defined
on the NSX-V Manager.Click the link for details on the reasons for failure. For example, NSX-
V Manager may have a service definition with the same name as defined on Panorama. To fix
the error, use the service definition name listed in the error message to validate the service
definition on the NSX-V Manager. Until the configuration on Panorama and the NSX-V Manager is
synchronized, you cannot add a new service definition on Panorama.
• No service/ No service profile: Indicates an incomplete configuration on the NSX-V Manager.
STEP 6 | Verify that the firewall is registered as a service on the NSX-V Manager.
1. On the vSphere web client, select Networking & Security > Service Definitions > Service Managers.
2. Verify that Palo Alto Networks displays as a vendor in the list of services available for installation.
STEP 7 | If you are running VMware NSX plugin 2.0.4 or later, you can configure Panorama to
automatically synchronize dynamic objects with NSX-V manager as if you issued an
Synchronize Dynamic Objects. By default, the DAG Sync interval is disabled and the value
is set to zero (0). To enable the DAG Sync, set the interval between one hour and 72 hours.
Setting a value of zero hours disables the DAG sync. To configure or disable the interval,
complete the following procedure.
1. Log in to the Panorama CLI.
2. Execute the following command.
request plugins vmware_nsx nsx_v dag-sync-interval interval <interval-in-
hours>
You can view the configured value with the following show command.
show plugins vmware_nsx nsx_v dag-sync-interval
STEP 8 | (Optional) In large NSX-V environments with tens of thousands of IP addresses, allowing
Panorama enough time to retrieve IP address updates from NSX-V Manager is essential. You
can now configure the amount of time—up to 10 minutes—Panorama has to retrieve updates
from NSX-V Manager. By default, Panorama waits up to two minutes (120 seconds) to get
IP address updates from NSX-V Manager. However, if Panorama does not retrieve all the IP
address updates within the alloted two minutes, Panorama times out and the update fails.
You can determine if you are experiencing curl call failures through the Panorama error log. Curl call
failures return the following message.
VM-SERIES DEPLOYMENT GUIDE | Set Up the VM-Series Firewall on VMware NSX 171
© 2021 Palo Alto Networks, Inc.
2019-05-23 06:50:15.780 -0700 ERROR: Curl call to NSX Manager failed
Complete the following procedure to increase the amount of time Panorama has to process updates.
This feature requires Panorama plugin for VMware NSX 2.0.5.
1. Log in to the Panorama CLI.
2. Execute the following command to set the curl call timeout. You can set the time out from 30
seconds to 600 seconds (10 minutes).
admin@Panorama> request plugins vmware_nsx global curl-timeout timeout
<seconds>
If Panorama is part of an HA pair, configure the same timeout value on the active and
passive Panorama peers.
172 VM-SERIES DEPLOYMENT GUIDE | Set Up the VM-Series Firewall on VMware NSX
© 2021 Palo Alto Networks, Inc.
STEP 3 | Add a template stack.
1. Select Panorama > Templates, and click Add Stack.
2. Enter a unique Name and a Description to identify the template stack.
3. Click Add under Templates and select the template you created above.
4. Click OK.
5. Click Commit, and select Panorama as the Commit Type to save the changes to the running
configuration on Panorama.
For a single-tenant deployment, create one zone. If you have multi-tenant deployment,
create a zone for each sub-tenant.
VM-SERIES DEPLOYMENT GUIDE | Set Up the VM-Series Firewall on VMware NSX 173
© 2021 Palo Alto Networks, Inc.
3. Select the boxes of all devices groups that should be notified of changes to the virtual environment.
If a device group does not have a check box available, it means that the device group is automatically
included by virtue of the device group hierarchy.
4. Click OK.
STEP 3 | Assign a device group and a template stack to the service definition.
Make sure to Create the zone(s) for each template stack.
Because the firewalls deployed in this solution will be centrally administered from Panorama, you must
specify the Device Group and the Template Stack that the firewalls belong to. All the firewalls that are
deployed using this service definition belong to the specified template stack and device group.
1. Select the device group or device group hierarchy in the Device Group drop-down.
2. Select the template stack in the Template drop-down.
You cannot reuse a template stack or a device group assigned to one service
definition in another service definition.
Do not change the Panorama service definition OVF path after a successful NSX Service
Deployment of VM-Series firewalls. Changing the OVF path, after a successful VM-
Series firewall deployment, can result in a NSX Service Deployment failed state. You may
resolve this failure in NSX-V Manager, however this may cause all VM-Series firewalls to
redeploy.
It is recommended that you use an OVF path name that scales and allows you to change the base image
without impacting your deployed firewalls. Instead of a path such as https://acme.com/software/PA-
VM-NST.9.1.0.ovf, use something such as https://acme.com/software/PanoSvcDef1-Cluster1.ovf.
Using a static path reference will eliminate any future need to change the OVF path. It is recommended
to create a path for each Panorama service definition (vSphere cluster) in your deployment and change
the PAN-OS base images references on the web server as needed.
To use a different OVF for an existing Service Definition, change the reference link on the web server to
point to another OVF. Changing the web server OVF reference links will not impact existing NSX Service
174 VM-SERIES DEPLOYMENT GUIDE | Set Up the VM-Series Firewall on VMware NSX
© 2021 Palo Alto Networks, Inc.
Deployments. The new OVF path will take affect on new service deployments or any hosts introduced
into the vSphere Cluster.
In VM-Series OVF URL, add the location of the web server that hosts the ovf file. Both http and https
are supported protocols. For example, enter https://acme.com/software/PA-VM-NSX.9.1.0.ovf
Select the ovf file that matches the VM-Series model you plan to deploy. For the VM-200,
use vm100.ovf. For the VM-1000-HV, use vm300.ovf.
You can use the same ovf version or different versions across service definitions. Using different ovf
versions across service definitions allows you to vary the PAN-OS version on the VM-Series firewalls in
different ESXi clusters.
STEP 6 | To automatically retrieve a device certificate when the VM-Series firewall is deployed by NSX
Manager, configure the device certificate.
1. If you have not done so already, log in to the Customer Support Portal and generate a Registration
PIN and PIN ID.
2. Under Device Certificate, click Enable.
3. Copy the PIN ID and enter it into the Device Certificate PIN ID field.
4. Reenter the PIN ID into the Confirm Device Certificate PIN ID field.
5. Copy the Registration ID and enter it into the Device Certificate PIN Value field.
6. Reenter the Registration ID into the Confirm Device Certificate PIN Value field.
STEP 7 | Save the service definition and attach it to the service manager.
1. Click OK.
2. Select Panorama > VMware > NSX-V > Service Manager and click the link of the service manager
name.
VM-SERIES DEPLOYMENT GUIDE | Set Up the VM-Series Firewall on VMware NSX 175
© 2021 Palo Alto Networks, Inc.
3. Under Service Definitions, click Add and select your service definition from the drop-down.
4. Click OK.
5. Select Commit and Commit Type: Panorama.
Committing the changes triggers the process of registering each service definition as a security
service on the NSX-V Manager.
The auth-code must be for the VM-Series model NSX bundle; for example, PAN-VM-300-
PERP- BND-NSX.
Verify that the order quantity/ capacity is adequate to support the number of firewall you need to
deploy in your network.
1. Select Panorama > Device Groups and choose the device group you associated with the service
definition you just created.
2. Under Dynamically Added Device Properties, add the authorization code you received with your
order fulfillment email and select a PAN-OS software version from the SW Version drop-down.
When a new firewall is deployed under NSX-V and added to the selected device group, the
authorization code is applied and the firewall is upgraded to the select version of PAN-OS.
On the support portal, you can view the total number of firewalls that you are authorized to deploy
and the ratio of the number of licenses that have been used to the total number of licenses enabled
by your auth-code.
3. Synchronize the configuration between Panorama and the NSX-V Manager.
1. Select Panorama > VMware > NSX-V > Service Managers.
2. Select NSX Config-Sync under the Actions column.
3. Click Yes to confirm the sync.
STEP 9 | Verify that the service definition and the NSX-V service profile that you defined on Panorama
are registered on the NSX-V Manager.
1. On the NSX-V Manager, to verify that the service definition is available, select Networking &
Security > Service Definitions > Services. The service definition is listed as a Service on the NSX-V
Manager.
176 VM-SERIES DEPLOYMENT GUIDE | Set Up the VM-Series Firewall on VMware NSX
© 2021 Palo Alto Networks, Inc.
STEP 10 | (Optional) Synchronize the configuration between Panorama and the NSX-V Manager.
If you add or update the service definitions configured on Panorama, select NSX Config Sync in the
Action column under Panorama > VMware > NSX-V > Service Managers to synchronize the changes on
the NSX-V Manager.
This link is not available if you have any pending commits on Panorama.
If the synchronization fails, view the details to know whether to fix the error on Panorama or on the
NSX-V Manager. For example, if you delete a service definition on Panorama, but the service definition
cannot be deleted from the NSX-V Manager because it is referenced in a rule on the NSX-V Manager,
the synchronization will fail with an error message that indicates the reason for failure.
VM-SERIES DEPLOYMENT GUIDE | Set Up the VM-Series Firewall on VMware NSX 177
© 2021 Palo Alto Networks, Inc.
If you opt to use an IP pool, which is a range of (static) IP addresses that are reserved for establishing
management access to the VM-Series firewalls, when the NSX-V Manager deploys a new VM-Series
firewall, the first available IP address from this range is assigned to the management interface of the
firewall.
STEP 1 | In the Networking & Security Inventory, select the NSX Manager, and double click to open the
configuration details of the NSX-V Manager.
STEP 3 | Click Add IP Pool and specify the network access details requested in the screen including the
range of static IP addresses that you want to use for the Palo Alto Networks NGFW.
STEP 1 | On the NSX-V Manager, select Networking and Security > Installation > Host Preparation.
STEP 2 | Click Install and verify that the installation status is successful.
178 VM-SERIES DEPLOYMENT GUIDE | Set Up the VM-Series Firewall on VMware NSX
© 2021 Palo Alto Networks, Inc.
As new ESXi hosts are added to a cluster, this process is automated and the necessary
NSX-V components are automatically installed on each guest on the ESXi host.
STEP 3 | If the Installation Status is not ready or a warning displays on screen, click the Resolve link. To
monitor the progress of the re-installation attempt, click the More Tasks link and look for the
successful completion of the following tasks:
STEP 1 | Select Networking and Security > Installation > Service Deployments.
STEP 2 | Click New Service Deployment (green plus icon), and select the service definition for the Palo
Alto Networks next generation firewall you want to deploy, Palo Alto Networks NGFW service
in this example. Click Next.
VM-SERIES DEPLOYMENT GUIDE | Set Up the VM-Series Firewall on VMware NSX 179
© 2021 Palo Alto Networks, Inc.
STEP 3 | Select the Datacenter and the cluster(s) on which the service will be deployed. One instance of
the firewall will be deployed on each host in the selected cluster(s).
STEP 4 | Select the datastore from which to allocate disk space for the firewall. Select one of the
following options depending on your deployment:
• If you have allocated shared storage for the cluster, select an available shared datastore.
• If you have not allocated shared storage for the cluster, select the Specified-on-host option. Be sure
to select the storage on each ESXi host in the cluster. Also select the network that will be used for
the management traffic on the VM-Series firewall.
STEP 5 | Select the port group that provides management network traffic access to the firewall.
180 VM-SERIES DEPLOYMENT GUIDE | Set Up the VM-Series Firewall on VMware NSX
© 2021 Palo Alto Networks, Inc.
STEP 6 | Select the IP address pool assignment.
• Use IP Pool (Define an IP Address Pool) from which to assign a management IP address for each
firewall when it is being deployed.
• Use DHCP on the management interface.
If you use an IP pool, on deployment, the display name for the VM-Series firewall on
Panorama includes the hostname of the ESXi host. For example: PA-VM:10.5.1.120.
If you use DHCP, the display name for the VM-Series firewall does not include the name of the ESXi
host.
STEP 8 | Verify that the NSX-V Manager reports the Installation Status as Successful. This process can
take a while; click the More tasks link on vCenter to monitor the progress of the installation.
If the installation of VM-Series fails, the error message is displayed on the Installation
Status column. You can also use the Tasks tab and the Log Browser on the NSX-V
Manager to view the details for the failure and refer to the VMware documentation for
troubleshooting steps.
VM-SERIES DEPLOYMENT GUIDE | Set Up the VM-Series Firewall on VMware NSX 181
© 2021 Palo Alto Networks, Inc.
2. View the management IP address(es) and the PAN-OS version running on the firewall directly from
vCenter server. VMware Tools is bundled with the PAN-OS software image and is automatically
enabled when you launch the VM-Series firewall.
With VMware Tools, you can view resource utilization metrics on hard disk, memory, and CPU, and
use these metrics to enable alarms or actions on the vCenter server. The heartbeats allow you to
verify that the firewall is live and trigger actions to ensure high availability. You can also perform a
graceful shutdown and restart of the firewall using the power off function on vCenter.
STEP 10 | Access the Panorama web interface to make sure that the VM-Series firewalls are connected
and synchronized with Panorama.
1. Select Panorama > Managed Devices to verify that the firewalls are connected and synchronized.
If the firewall gets its IP address from an IP Pool, the Display Name for the firewall includes the
hostname of the ESXi server on which it is deployed, for example PA-VM:ESX1.Sydney. If the firewall
gets a DHCP assigned IP address, the hostname of the ESXi server does not display.
If the ESXi server hostname is longer than 32 characters, the hostname will not be
displayed in Panorama. Instead, only PA-VM is displayed.
A periodic Panorama commit is required to ensure that Panorama saves the device
serial numbers to configuration. If you reboot Panorama without committing the
changes, the managed devices will not connect back to Panorama; although the
Device Group will display the list of devices, the devices will not display in Panorama >
Managed Devices.
182 VM-SERIES DEPLOYMENT GUIDE | Set Up the VM-Series Firewall on VMware NSX
© 2021 Palo Alto Networks, Inc.
STEP 11 | Verify that the capacity license is applied and apply any additional licenses that you have
purchased. At a minimum, you must activate the support license on each firewall.
When Panorama does not have internet access (Offline), you must manually license each
firewall, and then add the serial number of the firewall to Panorama so that it is registered
as a managed device, and can receive the template stack and device group settings from
Panorama. See Activate the License for the VM-Series Firewall for VMware NSX for more
information.
1. Select Panorama > Device Deployment > Licenses to verify that the VM-Series capacity license is
applied.
3. Click Activate, and verify that the result of the license activation was successful.
STEP 12 | (Optional) Upgrade the PAN-OS version on the VM-Series firewalls, see Upgrade the PAN-OS
Software Version (VM-Series for NSX).
STEP 13 | Add guest VMs to the right security groups for traffic from those VMs to be redirected to the
VM-Series firewall.
1. Log in to vCenter.
2. Select Networking & Security > Service Composer > Security Groups.
3. Highlight the security group to which you want to assign guest VMs and click the Edit Security Group
icon.
4. Select Define dynamic membership and click the + icon.
5. Click Add.
6. Define the dynamic membership criteria that the guest VMs must meet to be part of the selected
security group. The criteria you use depends on your network deployment. For example, you might
choose to group VMs by an Entity such as Logical Switch or Distributed Port Group.
VM-SERIES DEPLOYMENT GUIDE | Set Up the VM-Series Firewall on VMware NSX 183
© 2021 Palo Alto Networks, Inc.
7. Click Finish.
8. Repeat this procedure for each security group that should have its traffic redirected to the VM-Series
firewall.
LRO is disabled by default on new NSX-V deployments and upon upgrade. You can enable or disable LRO
and view the LRO status on through the CLI. Enabling LRO on the VM-Series firewall automatically enables
jumbo frames. Additionally, LRO and TCP Segmentation Offload (TSO) must be enabled on VMXNET3
network adapter on the VM-Series firewall host machine.
184 VM-SERIES DEPLOYMENT GUIDE | Set Up the VM-Series Firewall on VMware NSX
© 2021 Palo Alto Networks, Inc.
STEP 1 | Verify that large receive offload and TCP segmentation offload is enabled on the host.
For information about LRO and TSO on the host machine, see theVMware vSphere documentation.
1. Log in to vSphere and navigate to your host machine.
2. Select Manage > Settings > System > Advanced System Settings.
3. Locate the following parameters and verify that their value is set 1. A 1 indicates that the parameter
is enabled on the VMXNET3 adapter.
• For LRO—Net.Vmxnet3HwLRO
• For TSO—Net.UseHwTSO and Net.UseHwTSO6
You can disable LRO using the command set system setting lro disable.
VM-SERIES DEPLOYMENT GUIDE | Set Up the VM-Series Firewall on VMware NSX 185
© 2021 Palo Alto Networks, Inc.
secure the guests; to understand how security groups enable policy enforcement, see Policy Enforcement
using Dynamic Address Groups.
STEP 1 | Configure a dynamic address group for each security group required for your deployment.
Shared dynamic address groups are not supported on the VM-Series for VMware NSX-V.
For the dynamic address group to become a security group in NSX-V Manager, the
match criteria string must be enclosed in single quotes with the prefix _nsx_ followed
by the exact name of the Address Group. For example, ‘_nsx_PAN_APP_NSX’.
6. Repeat this process for each security group you require.
STEP 2 | Verify that the corresponding security groups are created on the NSX-V Manager.
1. Select Network and Security > Service Composer > Security Groups.
2. Verify that your dynamic address groups appear as security groups on the Security Groups list. Each
security group is prefixed with your service definition followed by an underscore and the dynamic
address group name.
186 VM-SERIES DEPLOYMENT GUIDE | Set Up the VM-Series Firewall on VMware NSX
© 2021 Palo Alto Networks, Inc.
deny all traffic, which means that all traffic redirected to the VM-Series firewall will be dropped. To create
policies on Panorama and push them to the VM-Series firewall, see Apply Policies to the VM-Series Firewall.
Create security policy rules in the associated device group. For each security rule set the Rule Type to
Intrazone, select one zone in the associated template stack, and select the dynamic address groups as
the source and destination. Creating a qualifying security policy in Panorama helps in the creation of a
corresponding steering rule on NSX-V Manager upon steering rule generation and commit in Panorama.
3. (Optional) Modify the NSX Traffic Direction and add NSX-V Services to a Steering Rule.
By default, the NSX Traffic Direction is set to inout and no NSX-V Services are selected. When no
NSX-V Services are specified, any type of traffic is redirected to the VM-Series firewall.
1. Select the auto-generated steering to be modified.
2. To change the traffic direction, select the direction from the NSX Traffic Direction drop-down.
3. Click Add under NSX Services and choose a service from the Services drop-down. Repeat this
step to add additional services.
4. Click OK.
4. If you deleted any steering rules, click Auto-Generate Steering Rules before committing your
changes.
5. Commit your changes.
VM-SERIES DEPLOYMENT GUIDE | Set Up the VM-Series Firewall on VMware NSX 187
© 2021 Palo Alto Networks, Inc.
STEP 3 | Verify that the corresponding traffic steering rules were created on the NSX-V Manager.
1. Select Network and Security > Firewall > Configuration > Partner Security Services.
2. Confirm that the traffic steering rules your created on Panorama are listed.
STEP 2 | Select Networking and Security > Service Composer > Security Groups, and add a New
Security Group.
STEP 3 | Add a Name and Description. This name will display in the match criteria list when defining
dynamic address groups on Panorama.
STEP 4 | Select the guests that constitute the security group. You can either add members
dynamically or statically. You can Define Dynamic Membership by matching on security tags
(recommended), or statically by adding IP Sets under Select the Objects to Include. In the
following screenshot, the guests that belong to the security group are selected using the
Objects Type: Virtual Machine option.
188 VM-SERIES DEPLOYMENT GUIDE | Set Up the VM-Series Firewall on VMware NSX
© 2021 Palo Alto Networks, Inc.
STEP 5 | Review the details and click OK to create the security group.
STEP 1 | Select Networking and Security > Service Composer > Security Policies and click Create
Security Policy ( ).
VM-SERIES DEPLOYMENT GUIDE | Set Up the VM-Series Firewall on VMware NSX 189
© 2021 Palo Alto Networks, Inc.
10.Click Finish to save your configuration.
Skip this step for security-centric deployments. If you are performing a security-centric
deployment, you have already created dynamic-address groups.
After creating the security redirection rules on the NSX-V Manager, the names of the security groups
that are referenced in security policy will be available on Panorama.
Shared dynamic address groups are not supported on the VM-Series for VMware NSX-V.
190 VM-SERIES DEPLOYMENT GUIDE | Set Up the VM-Series Firewall on VMware NSX
© 2021 Palo Alto Networks, Inc.
3. Click Add and enter a Name and Description for the dynamic address group.
4. Select Type as Dynamic.
5. Add Match Criteria to your dynamic address group.
Some browser extensions may block API calls between Panorama and NSX-V which
prevents Panorama from receiving match criteria. If Panorama displays no match
criteria and you are using browser extensions, disable the extensions and Synchronize
Dynamic Objects to populate the tags available to Panorama.
6. Click Add Match Criteria.
7. Select the And or Or operator and click the plus (+) icon next to the security group name to add it to
the dynamic address group.
The security groups that display in the match criteria dialog are derived from the
groups you defined on the Distributed Firewall Partner Security Services or on
the Service Composer on the NSX-V Manager. Only the security groups that are
referenced in the security policies and from which traffic is redirected to the VM-Series
firewall are available here.
8. Click OK.
9. Repeat these steps to create the appropriate number of dynamic address groups required for your
deployment.
10.Commit your changes.
VM-SERIES DEPLOYMENT GUIDE | Set Up the VM-Series Firewall on VMware NSX 191
© 2021 Palo Alto Networks, Inc.
1. Select Policies > Security > Prerules.
2.
Select the Device Group that you created for managing the VM-Series
firewalls for NSX-V in Register the VM-Series Firewall as a Service on the NSX-V Manager.
3. Click Add and enter a Name and a Description for the rule. In this example, the security rule allows all
traffic between the WebFrontEnd servers and the Application servers.
4. Select the Source Zone and Destination Zone. The zone name must be the same in both columns.
5. For the Source Address and Destination Address, select or type in an address, address group
or region. In this example, we select an address group, the Dynamic address group you created
previously.
6. Select the Application to allow. In this example, we create an Application Group that includes a static
group of specific applications that are grouped together.
1. Click Add and select New Application Group.
2. Click Add to select the application to include in the group. In this example, we select the following:
3. Click OK to create the application group.
7. Specify the action— Allow or Deny—for the traffic, and optionally attach the default security profiles
for antivirus, anti-spyware, and vulnerability protection, under Profiles.
8. Repeats the steps above to create the pertinent policy rules.
9. Click Commit, select Commit Type as Panorama. Click OK.
192 VM-SERIES DEPLOYMENT GUIDE | Set Up the VM-Series Firewall on VMware NSX
© 2021 Palo Alto Networks, Inc.
2. Select the device group, NSX-V Device Group in this example and click OK.
3. Verify that the commit is successful.
STEP 5 | Validate that the members of the dynamic address group are populated on the VM-Series
firewall.
1. From Panorama, switch device context to launch the web interface of a firewall to which you pushed
policies.
2. On the VM-Series firewall, select Policies > Security, and select a rule.
3. Select the drop-down arrow next to the address group link, and select Inspect. You can also verify
that the match criteria is accurate.
4. Click the more link and verify that the list of registered IP addresses is displayed.
Policy will be enforced for all IP addresses that belong to this address group, and are displayed here.
STEP 6 | (Optional) Use template to push a base configuration for network and device configuration such
as DNS server, NTP server, Syslog server, and login banner.
Refer to the Panorama Administrator’s Guide for information on using templates.
VM-SERIES DEPLOYMENT GUIDE | Set Up the VM-Series Firewall on VMware NSX 193
© 2021 Palo Alto Networks, Inc.
STEP 7 | Create a Zone Protection profile and attach it to a zone.
A zone protection profile provides flood protection and has the ability to protect against port scanning,
port sweeps and packet-based attacks. It allows you to secure intra-tier and inter-tier traffic between
virtual machines within your data center and traffic from the Internet that is destined to the virtual
machines (workloads) in your data center.
1. Select your Template.
2. Select Network > Network Profiles > Zone Protection to add and configure a new profile.
3. Select Network > Zones, click the default-zone listed and select the profile in the Zone Protection
Profile drop down.
STEP 8 | Create a DoS Protection profile and attach it to DoS Protection policy rule.
1. Select your Device Group.
2. Select Objects > Security Profiles > DoS Protection to add and configure a new profile.
• A classified profile allows the creation of a threshold that applies to a single source IP. For
example, you can configure a max session rate for an IP address that matched the policy, and then
block that single IP address once the threshold is triggered.
• An aggregate profile allows the creation of a max session rate for all packets matching the policy.
The threshold applies to new session rate for all IP addresses combined. Once the threshold is
triggered it affects all traffic that matches the policy.
3. Create a new DoS Protection policy rule in Policy > DoS Protection, and attach the new profile to it.
Steer Traffic from Guests that are not Running VMware Tools
VMware Tools contains a utility that allows the NSX-V Manager to collect the IP address(es) of each guest
running in the cluster. NSX-V Manager uses the IP address as a match criterion to steer traffic to the VM-
Series firewall. If you do not have VMware tools installed on each guest, the IP address(es) of the guest is
unavailable to the NSX-V Manager and traffic cannot be steered to the VM-Series firewall.
The following steps allow you to manually provision guests without VMware Tools so that traffic from each
of these guests can be managed by the VM-Series firewall.
STEP 1 | Create an IP set that includes the guests that need to be secured by the VM-Series firewall.
This IP set will be used as the source or destination object in an NSX-V distributed firewall rule
in Step 2 below.
1. Select NSX Managers > Manage > Grouping Objects > IP Sets.
2. Click Add and enter the IP address of each guest that does not have VMware tools installed, and
needs to be secured by the VM-Series firewall. Use commas to separate individual IP addresses; IP
ranges or subnets are not valid.
194 VM-SERIES DEPLOYMENT GUIDE | Set Up the VM-Series Firewall on VMware NSX
© 2021 Palo Alto Networks, Inc.
STEP 2 | Attach the IP sets to the Security Groups on NSX-V, to enforce policy.
1. Select Networking and Security > Service Composer > Security Groups.
2. Select Select objects to include > IP Sets, add the IP set object to include.
VM-SERIES DEPLOYMENT GUIDE | Set Up the VM-Series Firewall on VMware NSX 195
© 2021 Palo Alto Networks, Inc.
• Create your service definition—A service definition specifies the configuration for the VM-Series
firewalls on each host in the ESXi cluster. Each individual NSX-V manager configuration requires at
least one service definition. A service manager can have multiple service definitions but each service
definition can only have one device group and one template stack. After a device group or template
stack has been assigned to a service definition, you can no longer select that device group or template
stack for future service definitions.
For example, in a disaster recovery deployment scenario, you would need to create identical device groups
for each data center. Because all the policy rules and objects are the same for data centers, you can perform
all you configuration in a single device group. However, you cannot use the same device group in two
service definitions. To ensure that each data center gets the same policy rules, create a child device group
for each data center under the device group with the common configuration. These child device groups do
not need any configuration of their own because they inherit everything the VM-Series firewalls need from
the parent device group. And because each data center is identical, configure your network settings in a
template (Template 1). Create a template stack for each data center and assign Template 1 to each stack.
196 VM-SERIES DEPLOYMENT GUIDE | Set Up the VM-Series Firewall on VMware NSX
© 2021 Palo Alto Networks, Inc.
Deploy the VM-Series Firewall in a Multi-NSX Manager Environment
Whether you are deploying a single NSX-V Manager or a multi-NSX Manager environment, set up the
connection between an NSX-V Manager and Panorama before you continue on to set up the next NSX-V
Manager with Panorama.
STEP 1 | Install the VMware NSX Plugin version 2.0 as it allows you to connect up to 16 NSX-V
Managers. This version of the plugin allows you to add more than one Service Manager to your
VM-Series firewall for NSX-V configuration on Panorama.
STEP 3 | Create Template(s), Template Stack(s), and Device Group(s) on Panorama. Device groups and
template stacks push the security policy and network settings to the VM-Series firewalls in
each ESXi cluster.
When configuring policy rules and objects, verify that you have selected the correct device group.
When configuring network and device settings, verify that you have selected the correct template stack.
STEP 4 | Create the Service Definitions on Panorama and attach them to the service manager. Each
service definition can reference one device group and one template stack. Panorama supports
up to 32 service definitions across all service managers.
VM-SERIES DEPLOYMENT GUIDE | Set Up the VM-Series Firewall on VMware NSX 197
© 2021 Palo Alto Networks, Inc.
STEP 5 | Configure dynamic address groups or security groups and redirect traffic to the VM-Series
firewall.
• For security-centric deployments Set Up Dynamic Address Groups on Panorama and Create Steering
Rules on Panorama.
• For operations-centric deployments Set Up Security Groups on the NSX-V Manager and Create
Steering Rules on NSX-V Manager.
Verify that you have selected the correct device group so the right steering rules are sent to the
corresponding NSX-V Manager.
STEP 6 | Deploy the Palo Alto Networks NGFW Service on each ESXi cluster by using the relevant
service definitions.
198 VM-SERIES DEPLOYMENT GUIDE | Set Up the VM-Series Firewall on VMware NSX
© 2021 Palo Alto Networks, Inc.
Panorama includes predefined payload formats for threat and traffic logs in the HTTP Server Profile. These
payload formats correspond to predefined security tags in NSX-V. When a guest VM is found in the threat
or traffic logs, Panorama makes an API call to NSX-V Manager telling NSX-V Manager to tag the guest VM
with the tag specified in the HTTP Server Profile. When the guest VM becomes tagged, NSX-V Manager
dynamically moves the tagged guest VM into the quarantine security group, which places the guest VM into
the quarantine dynamic address group.
STEP 1 | Confirm that you have content update version 636 or later installed on Panorama.
STEP 2 | Create a dynamic address group to be your quarantine dynamic address group.
STEP 3 | Create an HTTP Server Profile to send API calls to NSX-V Manager.
1. Select Panorama > Server Profiles > HTTP and Add a new HTTP Server Profile.
2. Enter a descriptive Name.
3. Select Add to provide the details of NSX-V Manager.
4. Enter a Name for NSX-V Manager.
5. Enter the IP Address of NSX-V Manager.
6. Select the Protocol (HTTP or HTTPS). The default Port is 80 or 443 respectively.
7. Select PUT under the HTTP Method column.
8. Enter the username and password for NSX-V Manager.
9. Select Payload Format and choose an NSX-V payload format from the Pre-defined Formats drop-
down. This populates the URI Format, HTTP Headers, and Payload fields with the correct information
to send the HTTP API call to NSX-V Manager. Additionally, the chosen format determines which
security tag NSX-V Manager applies to infected guest VMs. In the example below, NSX-V Anti-Virus
Threat High is selected which corresponds to the ANTI_VIRUS.VirusFound.threat=high security tag
on NSX-V Manager.
VM-SERIES DEPLOYMENT GUIDE | Set Up the VM-Series Firewall on VMware NSX 199
© 2021 Palo Alto Networks, Inc.
STEP 4 | Define the match criteria for when Panorama will forward logs to the NSX-V Manager, and
attach the HTTP server profile to use.
1. Select Panorama > Collector Groups > Collector Log Forwarding for Threat or Traffic logs.
2. Click Traffic or Threat and Add.
3. Enter a descriptive name for the new log settings.
4. (Optional) Under Filter, you can add filters such as severity to narrow the logs that are forwarded to
NSX-V Manager. If All Logs is selected, all threat or traffic logs that meet the criteria set in the HTTP
Server profile are sent to NSX-V Manager.
5. Click Add under HTTP and select the HTTP Server Profile configured in Step 3.
6. Click OK.
STEP 5 | Configure an NSX-V server certificate for Panorama to forward logs to NSX-V manager.
1. Select Panorama > Certificate Management > Certificates.
2. Create a root CA certificate with CN=IP address of Panorama.
3. Create a signed certificate with CN=IP address of NSX-V Manager.
4. Export the root CA certificate in PEM format without a private key.
200 VM-SERIES DEPLOYMENT GUIDE | Set Up the VM-Series Firewall on VMware NSX
© 2021 Palo Alto Networks, Inc.
5. Export the signed certificate in PEM format with a private key.
6. Using a tool such as OpenSSL, concatenate the exported certificates into a single PEM file for upload
to NSX-V manager. Use the following commands in OpenSSL to complete this step.
cat cert_NSX_Root_CA.crt
cert_NSX_Signed1.pem > cert_NSX_cert_chain.pem
openssl pkcs12 -export -in cert_NSX_cert_chain.pem -out cert_NSX_cert.p12
7. Log in to NSX-V Manager and select Manage Appliance Settings > SSL Certificates > Upload
PKC#12 Keystore. Click Choose File, locate the p12 file you created in the previous step, and click
Import.
STEP 7 | After the guest VM is cleared for removal from quarantine, manually remove the NSX-V
security tag from the guest VM in NSX-V.
1. Log in to vCenter.
2. Select VMs and Templates and choose the quarantined guest.
VM-SERIES DEPLOYMENT GUIDE | Set Up the VM-Series Firewall on VMware NSX 201
© 2021 Palo Alto Networks, Inc.
3. Select Summary > Security Tags > Manage.
4. Uncheck the security tag used by the quarantine security group and click OK.
5. Refresh the page and the quarantine security will no longer be listed under Summary > Security
Group Membership.
Source and destination UUID fields in threat and traffic logs may be blank after a guest VM is removed
from quarantine. This can occur when running NSX-V 6.2.3 or earlier or if NSX-V steering rules do not
use the inout direction. You can resolve this by upgrading NSX-V to 6.2.4 or issue an NSX Config-sync
under Panorama > VMware > NSX-V > Service Manager and reboot the PA-VM to resolve this issue.
STEP 2 | Update the match criteria format in your dynamic address groups.
1. Select Objects > Address Groups and click the link name for your first dynamic address group.
2. Delete the existing match criteria entry.
3. Enter the new match criteria in the following format:
‘_nsx_<dynamic-address-group-name>’
4. Click OK.
5. Repeat this process for each dynamic address group.
202 VM-SERIES DEPLOYMENT GUIDE | Set Up the VM-Series Firewall on VMware NSX
© 2021 Palo Alto Networks, Inc.
3. Click OK.
4. Repeat this process for each security policy rule.
VM-SERIES DEPLOYMENT GUIDE | Set Up the VM-Series Firewall on VMware NSX 203
© 2021 Palo Alto Networks, Inc.
STEP 6 | Add match criteria to the newly created security groups to ensure that your VMs are placed in
the correct security group.
There two ways to complete this task—recreate the match criteria from the old security group in the
new security group or nest the old security group within the new security group.
To recreate the match criteria from the old security group, complete the following procedure.
1. Select Network & Security > Service Composer > Security Groups.
2. Click on a new security group and select Edit Security Group.
3. Select Define dynamic membership and click the plus icon.
4. Add the same match criteria in the corresponding old security group.
5. Repeat this process for each new security group.
6. Delete the old security groups.
To nest the old security group within the new security group, complete the following procedure. In this
method, VMs in the old security group are added to the new security group. Additionally, any new VM
that meets the criteria of the old security group is automatically added to the new security group.
1. Select Network & Security > Service Composer > Security Groups.
2. Click on a new security group and select Edit Security Group.
3. Select Select objects to include.
4. Select the Security Group Object Type.
5. Choose the corresponding old security group under Available Objects and move it to Selected
Objects by clicking the right arrow icon.
6. Click Finish.
204 VM-SERIES DEPLOYMENT GUIDE | Set Up the VM-Series Firewall on VMware NSX
© 2021 Palo Alto Networks, Inc.
STEP 7 | Delete the old steering rules from vCenter.
1. Select Networking & Security > Firewall > Configuration > Partner security services.
2. Delete the old steering rules. Take care not to delete the Palo Alto Networks rules created by the
Security-Centric workflow. These steering rule sections use the following naming convention.
<service-definition-name> - <dynamic-address-group-name>
STEP 2 | Deploy the VM-Series Firewall service instance on your new host.
STEP 3 | Disable vMotion on the virtual switches or distributed switches used by your new host.
• Virtual Switch
1. Log in to vCenter Server and select your new host in the inventory.
2. Select Configuration > Networking > Virtual Switch.
3. Select the virtual switch that includes the VMkernal port group used by your host and click
Properties > Ports.
4. Select the port group configured for VMotion and click Edit.
5. On the General tab, uncheck the Enabled check box for VMotion.
6. Click OK and Close.
• Distributed Virtual Switch
1. Log in to vCenter Server and select your new host in the inventory.
2. Select Configuration > Distributed Virtual Switch.
3. Select Manage Virtual Adapters.
4. Choose the virtual adapter used by your host and click Edit.
5. Uncheck Use this virtual adapter for VMotion.
6. Click OK.
VM-SERIES DEPLOYMENT GUIDE | Set Up the VM-Series Firewall on VMware NSX 205
© 2021 Palo Alto Networks, Inc.
STEP 5 | Move your new host to the existing cluster and exit maintenance mode. Wait for the VM-
Series firewall to boot up completely. Because VMotion is disabled on the host, no other virtual
machines will be moved to the host by DRS.
STEP 6 | When the VM-Series firewall is booted up completely, renable VMotion on the new host.
Guest VMs can now move to the new host and security is intact with no traffic lost.
206 VM-SERIES DEPLOYMENT GUIDE | Set Up the VM-Series Firewall on VMware NSX
© 2021 Palo Alto Networks, Inc.
5. Click OK.
6. Repeat the steps to add another zone, for example, Tenant2.
7. Verify that the zones are attached to the correct template stack.
3. Click Commit, and select Panorama as the Commit Type to save the changes to the running
configuration on Panorama.
VM-SERIES DEPLOYMENT GUIDE | Set Up the VM-Series Firewall on VMware NSX 207
© 2021 Palo Alto Networks, Inc.
3. Verify that the NSX-V Manager reports the Installation Status as Successful.
4. Verify that the VM-Series firewall is successfully deployed.
1. On the vCenter server, select Hosts and Clusters to check that every host in the cluster(s) has one
instance of the firewall.
2. View the management IP address(es) and the PAN-OS version running on the firewall directly
from vCenter server. VMware Tools is bundled with the PAN-OS software image and is
automatically enabled when you launch the VM-Series firewall.
2. On Panorama, create security policy rules and use the dynamic address groups as source or
destination address objects in security policy rules and push it to the firewalls.
1. Select Policies > Security > Prerules and click Add.
208 VM-SERIES DEPLOYMENT GUIDE | Set Up the VM-Series Firewall on VMware NSX
© 2021 Palo Alto Networks, Inc.
2. Create rules for each tenant. This use case has the following policy rules:
3. Click Commit, and select Commit Type as Device Groups. Select the device group, NSX-DG in this
example and click OK.
2. On the web interface of the VM-Series firewall, select Objects > Address Groups and verify that
you can view the IP address for the members of each Dynamic Address Group. The following is an
example of duplicate IP addresses in dynamic address groups across both tenants.
3. View the ACC and the Monitor > Logs > Traffic. Filter on the zone name to ensure that traffic from
the virtual machines for each tenant is secured.
VM-SERIES DEPLOYMENT GUIDE | Set Up the VM-Series Firewall on VMware NSX 209
© 2021 Palo Alto Networks, Inc.
Use Case: Shared Security Policies on Dedicated Compute
Infrastructure
If you are a Managed Service Provider who needs to secure a large enterprise (tenant) with multiple
departments (sub-tenants), and each tenant requires dedicated compute infrastructure and security policy
rules, you need to create a service definition for each tenant.
In this use case, each tenant—Oak and Maple— has a dedicated ESXi cluster. And each tenant has sub-
tenants—Dev, QA, and Prod—whose workloads are deployed in the cluster. You need to define two service
definitions to allow the VM-Series firewalls for each tenant to have Security policies for their respective
ESXi clusters. The service definition for each tenant includes multiple zones (with corresponding virtual wire
subinterface pairs) for isolating traffic from each sub-tenant. Each zone is mapped to a service profile on
the NSX-V Manager, which allows the firewall to distinguish traffic from the virtual machines for each sub-
tenant and to enforce zone-based security policy rules within the common set of policy rules for the tenant.
Zone-based policies in combination with the Dynamic Address groups also allow you to secure sub-tenants
who may have overlapping networks, and hence have duplicate IP addresses. To uniquely identify virtual
machines assigned to each sub-tenant and successfully enforce policy, the NSX-V Manager provides the
service profile and security group to which a virtual machine belongs as match criteria in dynamic address
groups on Panorama. For more information, see Policy Enforcement using Dynamic Address Groups.
You can also configure role-based access control using access domains on Panorama. Access domains
allow you to control administrative access to specific device groups (to manage policies and objects) and
template stacks (to manage network and device settings), so that each tenant administrator can manage the
configuration for their VM-Series firewalls. Role-based access also allows you to limit log visibility for the
respective tenant only.
210 VM-SERIES DEPLOYMENT GUIDE | Set Up the VM-Series Firewall on VMware NSX
© 2021 Palo Alto Networks, Inc.
STEP 1 | Enable Communication Between the NSX-V Manager and Panorama.
This is one-time task and is required if you have not enabled access between the NSX-V Manager and
Panorama.
VM-SERIES DEPLOYMENT GUIDE | Set Up the VM-Series Firewall on VMware NSX 211
© 2021 Palo Alto Networks, Inc.
5. Create a service profile zone for each other template stack.
3. Click Commit, and select Panorama as the Commit Type to save the changes to the running
configuration on Panorama.
2. Select Policies > Security > Pre Rules to set up security policy rules for sending traffic to the VM-
Series firewall.
3. Select Panorama > VMware > NSX-V > Steering Rules and click Auto-Generate Steering Rules.
4. Commit your changes
212 VM-SERIES DEPLOYMENT GUIDE | Set Up the VM-Series Firewall on VMware NSX
© 2021 Palo Alto Networks, Inc.
STEP 5 | Prepare the ESXi Host for the VM-Series Firewall
The ESXi hosts in the cluster must have the necessary NSX-V components that allow the NSX-V firewall
and the VM-Series firewall to work together. The NSX-V Manager will install the components— the
Ethernet Adapter Module (.eam) and the SDK —required to deploy the VM-Series firewall.
VM-SERIES DEPLOYMENT GUIDE | Set Up the VM-Series Firewall on VMware NSX 213
© 2021 Palo Alto Networks, Inc.
4. Create the dynamic address groups for the sub-tenants for the other tenant, Oak in this example.
2. On Panorama, create Security policies and use the dynamic address groups as source or destination
address objects in security policy rules and push it to the firewalls.
1. Select Policies > Security > Pre Rules.
2. Select a Device Group from the drop-down and click Add.
3. Create rules for each sub-tenant. Make sure to keep the source and destination zone the same in
a policy rule. To ensure that only the application that is running on the server is allowed, allow the
service on the application-default port only.
This use case has the following policy rules for the tenant Maple:
3. Select the other Device Group from the drop-down and create the Security policies for the each sub-
tenant for the other tenant, Oak in this example.
4. Click Commit, and select Commit Type as Device Groups. Select the device groups, NSX-DG-OAK
and NSX-DG-MAPLE in this example and click OK.
The commit pushes the Security policies to the firewalls that belong to each device group, and they
can enforce policy on the traffic redirected by the NSX-V Manager.
214 VM-SERIES DEPLOYMENT GUIDE | Set Up the VM-Series Firewall on VMware NSX
© 2021 Palo Alto Networks, Inc.
STEP 9 | (Optional) Enable role-based access for tenant administrators to manage the configuration and
policies for the VM-Series firewalls.
1. Create an access domain. An access domain allows you to restrict admin access to a specific device
group and template stack. In this example, you create two access domains and restrict access to the
device group and template stack for the respective tenant.
2. Configure an admin role for Device Group and Template role and allow the administrator to manage
the access domain. The administrator can only manage the firewalls that belong to the access domain.
3. Create an administrative account and associate the access domain and admin role with the account.
VM-SERIES DEPLOYMENT GUIDE | Set Up the VM-Series Firewall on VMware NSX 215
© 2021 Palo Alto Networks, Inc.
To understand this process, let’s trace the information update sent from the NSX-V Manager to Panorama
when a new server is added to a security group. Use the elements highlighted within the output in each
phase of this example, to troubleshoot where the process failed.
STEP 2 | Verify that the request from the NSX-V Manager is routed to the web server on Panorama.
To check the webserver-log on Panorama during an NSX-V Security Group update, use the following
command:
If your output does not include the elements above, check for routing issues. Ping the
Panorama from the NSX-V Manager and check for ACLs or other network security
devices that might be blocking the communication between the NSX-V Manager and
Panorama.
STEP 3 | Verify that the request is parsed by the PHP daemon on Panorama.
1. Enable debug using the following URL: https://<Panorama_IP>/php/utils/debug.php
2. From the CLI, enter the following command to view the logs generated by the PHP server:
216 VM-SERIES DEPLOYMENT GUIDE | Set Up the VM-Series Firewall on VMware NSX
© 2021 Palo Alto Networks, Inc.
...
<request>
<partner>
<vmware-service-manager>
<update>
<method>PUT</method>
<type>update</type>
<username>_vsm_admin</username>
<password>4006474760514053</password>
<url>/vmware/2.0/si/serviceprofile/serviceprofile-1/containerset</url>
<data><![CDATA[
<containerSet><container><id>securitygroup-10</id><name>WebServers</
name><description></description><revision>8</revision><type>IP</type><address>10.3.4.185</
address><address>10.3.4.186</address><address>15.0.0.203</address><address>15.0.0.202</
address></container></containerSet>]]></data>
</update>
</vmware-service-manager>
</partner>
</request>
</operations>
</request>
VM-SERIES DEPLOYMENT GUIDE | Set Up the VM-Series Firewall on VMware NSX 217
© 2021 Palo Alto Networks, Inc.
<username>_vsm_admin</username>
<password>4006474760514053</password><url>/vmware/2.0/si/serviceprofile/
serviceprofile-1/containerset</url><data><![CDATA[
<containerSet><container><id>securitygroup-10</id><name>WebServers</
name><description></description><revision>8</revision><type>IP</type><address>10.3.4.185</
address><address>10.3.4.186</address><address>15.0.0.203</address><address>15.0.0.202</
address></container></containerSet>]]>
</data></update>
4. Look for the list of IP addresses and security group tags.
218 VM-SERIES DEPLOYMENT GUIDE | Set Up the VM-Series Firewall on VMware NSX
© 2021 Palo Alto Networks, Inc.
Send to device: 007900002079 [UNREG: 0; REG: 2] with dynamic address
update : <request cmd='op' cookie='0604879067249569' target-…. <register>
<entry ip="15.0.0.203">
<tag>
<member>WebServers-securitygroup-10</member>
</tag>
</entry>
<entry ip="10.3.4.186">
<tag>
<member>WebServers-securitygroup-10</member>
</tag>
</entry>
</register>
VM-SERIES DEPLOYMENT GUIDE | Set Up the VM-Series Firewall on VMware NSX 219
© 2021 Palo Alto Networks, Inc.
Set Up the VM-Series Firewall on VMware
NSX-T (North-South)
The VM-Series firewall on VMware NSX-T integrates the Palo Alto next-generation firewalls and Panorama
with ESXi host servers to provide comprehensive visibility and safe application enablement of all north-
south traffic in your NSX-T software-defined datacenter.
The following topics provide information about the VM-Series firewall on VMware NSX-T:
• Supported Deployments of the VM-Series Firewall on VMware NSX-T (North-South)
• Components of the VM-Series Firewall on NSX-T (North-South)
• Deploy the VM-Series Firewall on NSX-T (North-South)
• Extend Security Policy from NSX-V to NSX-T
• Tier-0 Insertion—Tier-0 insertion deploys a VM-Series firewall to a tier-0 logical router, which processes
traffic between logical and physical networks. When you deploy the VM-Series firewall with tier-0
insertion, NSX-T Manager uses the deployment information you configured on Panorama to attach a
firewall to a tier-0 logical router in virtual wire mode.
• Tier-1 Insertion—Tier-1 insertion deploys a VM-Series firewall to a tier-1 logical router, which provides
downlink connections to segments and uplink connection to tier-0 logical routers. NSX-T Manager
attaches VM-Series firewalls deployed with tier-1 insertions to a tier-1 logical router in virtual wire
mode.
After deploying the firewall, you configure traffic redirection rules that send traffic to the VM-Series firewall
when crossing a tier-0 or tier-1 router. Security policy rules that you configure on Panorama are pushed to
managed VM-Series firewalls and then applied to traffic passing through the firewall.
220 VM-SERIES DEPLOYMENT GUIDE | Set Up the VM-Series Firewall on VMware NSX
© 2021 Palo Alto Networks, Inc.
VMware Components
NSX-T Manager VMware NSX-T Data Center 2.4.0 and later must be
installed and registered with the vCenter server. The
NSX-T Manager is required to deploy the VM-Series
firewall on the ESXi hosts within a ESXi cluster.
VM-Series Firewall Models The VM-100, VM-300, VM-500, and VM-700 support
NSX-T.
VM-SERIES DEPLOYMENT GUIDE | Set Up the VM-Series Firewall on VMware NSX 221
© 2021 Palo Alto Networks, Inc.
The following procedure refers to NSX-T Manager 3.0
.
STEP 1 | Select Panorama > Plugins. See the Compatibility Matrix before installing or upgrading your
plugin.
STEP 4 | Select the version of the plugin and click Install in the Action column to install the plugin.
Panorama will alert you when the installation is complete.
STEP 1 | (Optional) Bypass proxy server settings, configured on Panorama under Panorama > Setup >
Services > Proxy Server, for communication between Panorama and NSX-T Manager. This
command allows Panorama to communicate directly with NSX-T Manager while maintaining
proxied communication for other services.
1. Log in to the Panorama CLI.
2. Execute the following command to enable or disable proxy bypass.
admin@Panorama> request plugins vmware_nsx proxy bypass {yes | no}
Select yes to enable proxy bypass and no to disable proxy bypass. This is set to no by default.
222 VM-SERIES DEPLOYMENT GUIDE | Set Up the VM-Series Firewall on VMware NSX
© 2021 Palo Alto Networks, Inc.
STEP 3 | Set up access to the NSX-T Manager. Repeat this procedure for each NSX-T Manager to which
you will connect Panorama.
1. Select Panorama > VMware > NSX-T > Service Managers and click Add.
2. Enter a descriptive Name for your NSX-T Manager.
3. (Optional) Add a Description for NSX-T Manager.
4. Enter the NSX Manager URL—NSX-T Manager cluster virtual IP address or FQDN—at which to
access the NSX-T Manager.
5. Enter the NSX Manager Login credentials—username and password, so that Panorama can
authenticate to the NSX-T Manager.
6. Click OK.
If you change your NSX-T Manager login password, ensure that you update the password
on Panorama immediately. An incorrect password breaks the connection between
Panorama and NSX-T Manager.
VM-SERIES DEPLOYMENT GUIDE | Set Up the VM-Series Firewall on VMware NSX 223
© 2021 Palo Alto Networks, Inc.
2. Enter a unique Name and a Description to identify the device group.
3. Click OK.
4. Click Commit and select Panorama as the Commit Type to save the changes to the running
configuration on Panorama.
STEP 4 | Configure the virtual wire, interfaces, and zones. Ensure that you select the correct template
from the drop-down shown below. The objects you create must meet the following criteria:
If you change the default virtual wire or zone names, the virtual wire and zones on
Panorama must match the names used on the firewall.
STEP 5 | Click Commit, and select Panorama as the Commit Type to save the changes to the running
configuration on Panorama.
224 VM-SERIES DEPLOYMENT GUIDE | Set Up the VM-Series Firewall on VMware NSX
© 2021 Palo Alto Networks, Inc.
You can create up to 32 service definitions on Panorama.
STEP 2 | Assign a device group and a template stack to the service definition.
Make sure to Create Template Stacks and Device Groups on Panorama.
Because the firewalls deployed in this solution will be centrally administered from Panorama, you must
specify the Device Group and the Template Stack that the firewalls belong to. All the firewalls that are
deployed using this service definition belong to the specified template stack and device group.
1. Select the device group or device group hierarchy in the Device Group drop-down.
2. Select the template stack in the Template drop-down.
You cannot reuse a template stack or a device group assigned to one service
definition in another service definition.
Do not change the Panorama service definition OVF path after a successful NSX Service
Deployment of VM-Series firewalls. Changing the OVF path, after a successful VM-
Series firewall deployment, can result in a NSX Service Deployment failed state. You may
resolve this failure in NSX-T Manager, however this may cause all VM-Series firewalls to
redeploy.
It is recommended that you use an OVF path name that scales and allows you to change the base image
without impacting your deployed firewalls. Instead of a path such as https://acme.com/software/PA-
VM-NST.9.1.0.ovf, use something such as https://acme.com/software/PanoSvcDef1-Cluster1.ovf.
Using a static path reference will eliminate any future need to change the OVF path. It is recommended
to create a path for each Panorama service definition (vSphere cluster) in your deployment and change
the PAN-OS base images references on the web server as needed.
VM-SERIES DEPLOYMENT GUIDE | Set Up the VM-Series Firewall on VMware NSX 225
© 2021 Palo Alto Networks, Inc.
In OVF URL, add the location of the web server that hosts the ovf file. Both http and https are
supported protocols.
Panorama must have network connectivity with the web server to retrieve the OVF file.
You can use the same ovf version or different versions across service definitions. Using different ovf
versions across service definitions allows you to vary the PAN-OS version on the VM-Series firewalls in
different ESXi clusters.
STEP 4 | Select North South as the Insertion Type for your firewall.
STEP 5 | To automatically retrieve a device certificate when the VM-Series firewall is deployed by NSX
Manager, configure the device certificate.
Enable this option to apply a device certificate to newly deployed VM-Series firewalls. Only use this
option when deploying the firewall using a base image OVF that supports device certificates. Panorama
pushes the device certificate information to NSX Manager as part of the service definition. When a new
firewall is deployed in NSX, the device certificate is installed on the firewall at bootup.
For list of OVFs that support device certificates for the VM-Series firewall on VMware NSX, see the Palo
Alto Networks Compatibility Matrix.
If your OVF does not support a device certificate, disable this option.
1. If you have not done so already, log in to the Customer Support Portal and generate a Registration
PIN and PIN ID.
2. Under Device Certificate, click Enable.
3. Copy the PIN ID and enter it into the Device Certificate PIN ID field.
4. Reenter the PIN ID into the Confirm Device Certificate PIN ID field.
5. Copy the PIN Value and enter it into the Device Certificate PIN Value field.
6. Reenter the PIN Value into the Confirm Device Certificate PIN Value field.
226 VM-SERIES DEPLOYMENT GUIDE | Set Up the VM-Series Firewall on VMware NSX
© 2021 Palo Alto Networks, Inc.
STEP 7 | Attach the service definition to the service manager.
1. Select Panorama > VMware > NSX-T > Service Manager and click the link of the service manager
name.
2. Under Service Definitions, click Add and select your service definition from the drop-down.
3. Click OK.
VM-SERIES DEPLOYMENT GUIDE | Set Up the VM-Series Firewall on VMware NSX 227
© 2021 Palo Alto Networks, Inc.
STEP 9 | Commit to Panorama.
STEP 10 | On the NSX-T Manager, verify that the service definition is available.
Select System > Service Deployments > Catalog. The service definition is listed as a Service Instance on
the NSX-T Manager.
STEP 3 | Select your service definition from the Partner Service drop-down.
STEP 5 | Enter a descriptive Service Deployment Name for your VM-Series firewall.
STEP 6 | Select a tier-0 or tier-1 router under Attachment Points. NSX-T Manager attaches the VM-
Series firewall to the selected router and redirects traffic passing through that router to the
VM-Series firewall for inspection. You must select a router with no service insertion attached.
STEP 7 | Select a Compute Manager. The compute manager is the vCenter server managing your
datacenter.
STEP 8 | Select a Cluster. You can deploy the VM-Series firewall on any cluster that does not include
any Edge Transport Nodes.
228 VM-SERIES DEPLOYMENT GUIDE | Set Up the VM-Series Firewall on VMware NSX
© 2021 Palo Alto Networks, Inc.
5. Enter the Primary Subnet Mask.
6. Click Save.
STEP 11 | NSX-T Manager prepopulates the Deployment Specification and Deployment Template
based on the Partner Service you selected.
STEP 12 | Set the Failure Policy to Allow or Block. The failure policy defines how NSX-T Manager
handles traffic that is directed to the VM-Series firewall if the firewall becomes unavailable.
STEP 13 | Select the Deployment Mode for your VM-Series firewall—Standalone or High Availability.
If you have an edge node cluster and select High Availability, NSX-T Manager will deploy an
additional VM-Series firewall on the standby edge node in addition to the firewall deployed
on the active edge node.
The reflexive rule does not appear in the NSX-T web interface.
STEP 3 | Select Security > North South Security > Network Introspection (N-S).
STEP 6 | Select a VM-Series firewall service instance from the Redirect To drop-down. NSX-T Manager
will automatically populate the Applied To field based on the service instance you select.
If your NSX-T environment has Edge Nodes in active-standby HA, you must create a
redirect rule for each Edge Node. NSX-T does not automatically apply a redirect rule to
the standby node in the event of a failover.
STEP 9 | Click on the Name field and enter a descriptive name for the rule.
VM-SERIES DEPLOYMENT GUIDE | Set Up the VM-Series Firewall on VMware NSX 229
© 2021 Palo Alto Networks, Inc.
STEP 10 | By default, the source is set to Any. Complete the following steps to specify a different
source.
1. Click on the edit button in the Source column.
2. Select the group or groups to set as the Source or click Add Group to create a new group.
3. Click Apply.
STEP 11 | By default, the destination is set to Any. Complete the following steps to specify a different
destination.
1. Click on the edit button in the Destination column.
2. Select the group or groups to set as the Destination or click Add Group to create a new group.
3. Click Apply.
STEP 12 | By default, Any service is redirected to the firewall. Complete the following steps to specify
certain services and protocols.
1. Click on the edit button in the Services column.
2. Select the group or groups to set as the Service or click Add Service to create a new service.
3. Click Apply.
STEP 13 | Select Redirect from the Action drop-down to send traffic to your VM-Series firewall.
STEP 14 | Enable the rule. NSX-T Manager publishes the redirection rule you just created and
automatically creates a reflexive rule for return traffic. The reflexive rule does not appear in
the NSX-T Manager web interface.
230 VM-SERIES DEPLOYMENT GUIDE | Set Up the VM-Series Firewall on VMware NSX
© 2021 Palo Alto Networks, Inc.
STEP 15 | If your VM-Series firewalls are deployed in HA, create another rule for the passive HA peer.
If return traffic is not directed to the VM-Series firewall, manually configure a traffic
redirection rule for return traffic.
By default, the firewall creates a rule that allows Bidirectional Forwarding Detection
(BFD). Do not create a rule that blocks BFD. If BFD is blocked, NSX-T thinks that the
firewall is unavailable.
The VM-Series firewall on NSX-T does not support dynamic address groups for North-
South traffic.
6. Select the Application to allow. In this example, we create an Application Group that includes a static
group of specific applications that are grouped together.
1. Click Add and select New Application Group.
2. Click Add to select the application to include in the group.
3. Click OK to create the application group.
7. Specify the action— Allow or Deny—for the traffic, and optionally attach the default security profiles
for antivirus, anti-spyware, and vulnerability protection, under Profiles.
8. Click Commit, select Commit to Panorama. Click OK.
STEP 4 | (Optional) Use template to push a base configuration for network and device configuration such
as DNS server, NTP server, Syslog server, and login banner.
Refer to the Panorama Administrator’s Guide for information on using templates.
VM-SERIES DEPLOYMENT GUIDE | Set Up the VM-Series Firewall on VMware NSX 231
© 2021 Palo Alto Networks, Inc.
Use vMotion to Move the VM-Series Firewall Between Hosts
To maintain traffic flow while using vMotion to move your VM-Series firewall between ESXi hosts with
homogeneous CPU configurations in VMware NSX-T, you must use the PAN-OS CLI to pause the internal
heartbeat monitoring of the VM-Series firewall during vMotion. You can specify the amount of time, in
minutes, that heartbeat monitoring is paused. Heartbeat monitoring can be paused for up to 60 minutes.
When the pause interval expires or you deliberately end the pause interval, heartbeat monitoring resumes.
vMotion of the VM-Series firewall is supported on vSphere 6.5, 6.7, and 7.0 if the ESXi hosts have
homogeneous CPU configuration.
This procedure is not required when using vMotion to move the VM-Series firewall if you are
running vSphere 7.0 or later.
STEP 2 | Set the heartbeat monitoring pause interval using the following command. The pause begins as
soon as the command is executed. If vMotion is taking longer than expected, you can rerun this
command to set a new, longer interval that starts when the command is executed again.
request system heartbeat-pause set interval <pause-time-in-minutes>
You can view the time remaining in pause interval using the following command.
request system heartbeat-pause show interval
STEP 3 | (Optional) If you complete vMotion before the pause interval has elapsed, you can end the
pause by setting the interval to zero (0).
request system heartbeat-pause set interval 0
STEP 1 | Install the Panorama Plugin for VMware NSX 3.2.0 or later. See the Panorama Plugin for
VMware NSX 3.2.0 Release Notes before upgrading.
STEP 2 | Configure an NSX-T service definition for each NSX-V service definition in your deployment.
Do not create new device groups; instead use your existing NSX-V device groups. Using the
existing device groups allows you to apply the same security policy rules used on NSX-V to the
VM-Series firewalls deployed on NSX-T. If you have policy that reference a particular zone, add
the same template stack from your NSX-V service definition to your NSX-T service definition.
Additionally, if your device group references a particular template, ensure that you select the
template stack that includes the template referenced in the device group.
232 VM-SERIES DEPLOYMENT GUIDE | Set Up the VM-Series Firewall on VMware NSX
© 2021 Palo Alto Networks, Inc.
STEP 3 | Configure an NSX-T service manager and associate the NSX-T service definitions to the service
manager.
STEP 4 | Prepare your NSX-T environment and deploy the VM-Series firewall. You must create your
security groups, service chains, and traffic redirection policy before launching the VM-Series
firewall.
• Deploy the VM-Series Firewall on NSX-T (North-South)
• Deploy the VM-Series Firewall on NSX-T (East-West)
STEP 5 | Add the NSX-T tags to you existing dynamic address groups.
1. Select Panorama > Objects > Address Groups.
2. Click on the name of an existing NSX-V dynamic address group.
3. Click Add Match Criteria to display the tags from NSX-V and NSX-T.
4. Add the NSX-T tag to the dynamic address groups. Be sure to use the OR operator between the tags.
5. When you have added all the necessary tags, click OK.
6. Commit your changes.
STEP 6 | After your VM workloads have successfully migrated from NSX-V to NSX-T, you remove
the NSX-V tags from your dynamic address groups if you plan to discontinue use of NSX-
V. All NSX-V tags and corresponding IP addresses are unregistered after all NSX-V related
configuration is removed from the Panorama plugin for NSX and VM-Series firewall
configuration is removed from NSX-V manager.
VM-SERIES DEPLOYMENT GUIDE | Set Up the VM-Series Firewall on VMware NSX 233
© 2021 Palo Alto Networks, Inc.
Set Up the VM-Series Firewall on NSX-T (East-
West)
The VM-Series firewall on VMware NSX-T integrates the Palo Alto next-generation firewalls and Panorama
with ESXi host servers to provide comprehensive visibility and safe application enablement of all East-West
traffic in your NSX-T software-defined data center.
• Components of the VM-Series Firewall on NSX-T (East-West)
• VM-Series Firewall on NSX-T (East-West) Integration
• Supported Deployments of the VM-Series Firewall on VMware NSX-T (East-West)
• Deploy the VM-Series Firewall on NSX-T (East-West)
• Extend Security Policy from NSX-V to NSX-T
• Use In-Place Migration to Move Your VM-Series from NSX-V to NSX-T
VMware Components
NSX-T Manager VMware NSX-T Data Center 2.5.0 and later must be
installed and registered with the vCenter server. The
NSX-T Manager is required to deploy the VM-Series
firewall on the ESXi hosts within a ESXi cluster.
234 VM-SERIES DEPLOYMENT GUIDE | Set Up the VM-Series Firewall on VMware NSX
© 2021 Palo Alto Networks, Inc.
Palo Alto Networks Components
Panorama must be running the same release Panorama is the centralized management tool for the
version or later version that the firewalls that Palo Alto Networks next-generation firewalls. In this
it will manage. solution, Panorama works with the NSX-T Manager to
deploy, license, and centrally administer—configuration
and policies—the VM-Series firewall for NSX-T.
Panorama must be able to connect to the NSX-T
Manager, the VM-Series firewalls and the Palo Alto
Networks update server.
See the 9.1 Panorama Administrator’s Guide for
information about deploying your Panorama appliance.
VM-Series Firewall Models The VM-100, VM-300, VM-500, and VM-700 support
NSX-T.
VM-SERIES DEPLOYMENT GUIDE | Set Up the VM-Series Firewall on VMware NSX 235
© 2021 Palo Alto Networks, Inc.
1. Register the VM-Series firewall as a service—Use Panorama to connect to your VMware NSX-T
manager. Panorama communicates with NSX-T Manager using the NSX-T API and establishes bi-
directional communication. On Panorama, you configure the Service Manager by entering the IP address,
username, and password of NSX-T Manager to initiate communication.
After establishing communication with NSX-T Manager, configure the service definition. The service
definition includes the location of the VM-Series firewall base image, the authorization code needed
to license the VM-Series firewall, and the device groups and template stack to which the firewall will
belong.
Additionally, NSX-T Manager uses this connection to send updates on the changes in the NSX-T
environment with Panorama.
2. Deploy the VM-Series firewall per host or in a service cluster—NSX-T Manager uses the information
pushed from Panorama in the service definition to deploy the VM-Series firewall. Choose a where the
VM-Series firewall will be deployed (in a service cluster or on each ESXi host) and how NSX-T provides a
management IP address to the VM-Series firewall (DHCP or static IP). When the firewall boots up, NSX-
T manager’s API connects the VM-Series firewall to the hypervisor so it that can receive traffic from the
vSwitch.
3. The VM-Series connects to Panorama—The VM-Series firewall then connects to Panorama to obtain
its license. Panorama gets the license from the Palo Alto Networks update server and sends it to the
firewall. When the firewall gets its license, it reboots and comes back up with a serial number.
If Panorama does not have internet access, it cannot retrieve licenses and push them to
the firewall, so you have to manually license each firewall individually. If the VM-Series
firewall does not have internet access, you must manually add the serial numbers to
236 VM-SERIES DEPLOYMENT GUIDE | Set Up the VM-Series Firewall on VMware NSX
© 2021 Palo Alto Networks, Inc.
Panorama to register them as managed devices, so Panorama can push template stacks,
device groups, and other configuration information. For more information, see Activate
the License for the VM-Series Firewall for VMware NSX.
4. Panorama sends security policy to the VM-Series firewall—When the firewall reconnects to Panorama,
it is added to device group and template stack defined in the service definition and Panorama pushes the
appropriate security policy to that firewall. The firewall is now ready to secure traffic in your NSX-T data
center.
5. Create network introspection rules to redirect traffic to the VM-Series firewall—On the NSX-T
Manager, create a service chain and network introspection rules that redirect traffic in your NSX-T data
center.
6. Send real-time updates from NSX-T Manager—The NSX-T Manager sends real-time updates about
changes in the virtual environment to Panorama. These updates include changes in group membership
and IP addresses of virtual machines in groups that send traffic to the VM-Series firewall.
7. Panorama sends dynamic updates—As Panorama receives updates from NSX-T Manager, it sends those
updates from its managed VM-Series firewalls. Panorama places virtual machines into dynamic address
groups based on criteria that you determine and pushes dynamic address group membership information
to the firewalls. This allows firewalls to apply the correct security policy to traffic flowing to and from
virtual machines in your NSX-T data center.
• Host-Based—In a per host deployment, an instance of the VM-Series firewall is installed on each host in
the ESXi cluster. Traffic between guests on the same host is inspected by the local firewall, so it does not
need to leave the host for inspection. Traffic leaving the host is inspected by the firewall before reaching
the vSwitch.
VM-SERIES DEPLOYMENT GUIDE | Set Up the VM-Series Firewall on VMware NSX 237
© 2021 Palo Alto Networks, Inc.
After deploying the firewall, you configure traffic redirection rules that send traffic to the VM-Series
firewall. Security policy rules that you configure on Panorama are pushed to managed VM-Series firewalls
and then applied to traffic passing through the firewall.
STEP 4 | Select the version of the plugin and click Install in the Action column to install the plugin.
Panorama will alert you when the installation is complete.
238 VM-SERIES DEPLOYMENT GUIDE | Set Up the VM-Series Firewall on VMware NSX
© 2021 Palo Alto Networks, Inc.
Enable Communication Between NSX-T Manager and Panorama
Complete the following procedure to enable communication between Panorama and NSX-T Manager. You
can connect your Panorama to up to 16 NSX-T Managers. If you are connecting your Panorama to multiple
NSX-T Managers, you must carefully plan your device group hierarchy and template stacks and consider
how they interact with the other components needed for deployment. Service definitions reference device
groups and template stacks and push that information to the firewalls in the related ESXi clusters.
STEP 1 | (Optional) Bypass proxy server settings, configured on Panorama under Panorama > Setup >
Services > Proxy Server, for communication between Panorama and NSX-T Manager. This
command allows Panorama to communicate directly with NSX-T Manager while maintaining
proxied communication for other services.
1. Log in to the Panorama CLI.
2. Execute the following command to enable or disable proxy bypass.
admin@Panorama> request plugins vmware_nsx proxy bypass {yes | no}
Select yes to enable proxy bypass and no to disable proxy bypass. This is set to no by default.
STEP 3 | Set up access to the NSX-T Manager. Repeat this procedure for each NSX-T Manager to which
you will connect Panorama.
1. Select Panorama > VMware > NSX-T > Service Managers and click Add.
2. Enter a descriptive Name for your NSX-T Manager.
3. (Optional) Add a Description for NSX-T Manager.
4. Enter the NSX Manager URL—NSX-T Manager cluster virtual IP address or FQDN—at which to
access the NSX-T Manager.
5. Enter the NSX Manager Login credentials—username and password, so that Panorama can
authenticate to the NSX-T Manager.
6. Click OK.
If you change your NSX-T Manager login password, ensure that you update the password
on Panorama immediately. An incorrect password breaks the connection between
Panorama and NSX-T Manager.
VM-SERIES DEPLOYMENT GUIDE | Set Up the VM-Series Firewall on VMware NSX 239
© 2021 Palo Alto Networks, Inc.
T Manager may have a service definition with the same name as defined on Panorama. To fix
the error, use the service definition name listed in the error message to validate the service
definition on the NSX-T Manager. Until the configuration on Panorama and the NSX-T Manager is
synchronized, you cannot add a new service definition on Panorama.
• Connection Disabled: The connection between Panorama and the NSX-T Manager was manually
disabled.
240 VM-SERIES DEPLOYMENT GUIDE | Set Up the VM-Series Firewall on VMware NSX
© 2021 Palo Alto Networks, Inc.
5. Click OK.
6. Verify that the zones are attached to the correct template.
7. Click Commit, and select Panorama as the Commit Type to save the changes to the running
configuration on Panorama.
Panorama creates a corresponding service profile on NSX-T Manager for each qualified zone upon
commit.
STEP 3 | Assign a device group and a template stack to the service definition.
Make sure to Create Template Stacks and Device Groups on Panorama.
Because the firewalls deployed in this solution will be centrally administered from Panorama, you must
specify the Device Group and the Template Stack that the firewalls belong to. All the firewalls that are
deployed using this service definition belong to the specified template stack and device group.
1. Select the device group or device group hierarchy in the Device Group drop-down.
2. Select the template stack in the Template drop-down.
VM-SERIES DEPLOYMENT GUIDE | Set Up the VM-Series Firewall on VMware NSX 241
© 2021 Palo Alto Networks, Inc.
You cannot reuse a template stack or a device group assigned to one service
definition in another service definition.
Do not change the Panorama service definition OVF path after a successful NSX Service
Deployment of VM-Series firewalls. Changing the OVF path, after a successful VM-
Series firewall deployment, can result in a NSX Service Deployment failed state. You may
resolve this failure in NSX-T Manager, however this may cause all VM-Series firewalls to
redeploy.
It is recommended that you use an OVF path name that scales and allows you to change the base image
without impacting your deployed firewalls. Instead of a path such as https://acme.com/software/PA-
VM-NST.9.1.0.ovf, use something such as https://acme.com/software/PanoSvcDef1-Cluster1.ovf.
Using a static path reference will eliminate any future need to change the OVF path. It is recommended
to create a path for each Panorama service definition (vSphere cluster) in your deployment and change
the PAN-OS base images references on the web server as needed.
In OVF URL, add the location of the web server that hosts the ovf file. Both http and https are
supported protocols.
You can use the same ovf version or different versions across service definitions. Using different ovf
versions across service definitions allows you to vary the PAN-OS version on the VM-Series firewalls in
different ESXi clusters.
STEP 6 | Select East West as the Insertion Type for your firewall.
STEP 7 | (Optional) Enable Health Check. Health check is disabled by default. Also called service health
check, this NSX-T feature allows you to simulate high availability in the case of a service
instance failing. When configured with the VM-Series firewall, if a VM-Series service instance
fails, any traffic directed to that firewall is redirect to another firewall instance in the cluster
(for service cluster deployments) or a firewall instance on another host (for host-based
deployments).
242 VM-SERIES DEPLOYMENT GUIDE | Set Up the VM-Series Firewall on VMware NSX
© 2021 Palo Alto Networks, Inc.
You cannot disable or enable Health Check in a service definition after committing and
deploying VM-Series firewalls in NSX-T. Attempting to commit a change in the Health
Check configuration returns commit failure. To change this, you must delete and recreate
your service definition and redeploy your VM-Series firewalls.
STEP 8 | To automatically retrieve a device certificate when the VM-Series firewall is deployed by NSX
Manager, configure the device certificate.
Enable this option to apply a device certificate to newly deployed VM-Series firewalls. Only use this
option when deploying the firewall using a base image OVF that supports device certificates. Panorama
pushes the device certificate information to NSX Manager as part of the service definition. When a new
firewall is deployed in NSX, the device certificate is installed on the firewall at bootup.
For list of OVFs that support device certificates for the VM-Series firewall on VMware NSX, see the Palo
Alto Networks Compatibility Matrix.
If your OVF does not support a device certificate, disable this option.
1. If you have not done so already, log in to the Customer Support Portal and generate a Registration
PIN and PIN ID.
2. Under Device Certificate, click Enable.
3. Copy the PIN ID and enter it into the Device Certificate PIN ID field.
4. Reenter the PIN ID into the Confirm Device Certificate PIN ID field.
5. Copy the PIN Value and enter it into the Device Certificate PIN Value field.
6. Reenter the PIN Value into the Confirm Device Certificate PIN Value field.
You cannot use a service definition in more than one service manager.
1. Select Panorama > VMware > NSX-T > Service Manager and click the link of the service manager
name.
2. Under Service Definitions, click Add and select your service definition from the drop-down.
3. Click OK.
VM-SERIES DEPLOYMENT GUIDE | Set Up the VM-Series Firewall on VMware NSX 243
© 2021 Palo Alto Networks, Inc.
STEP 11 | Add the authorization code to license the firewalls.
1. Select Panorama > Device Groups and choose the device group you associated with the service
definition you just created.
2. Under Dynamically Added Device Properties, add the authorization code you received with your
order fulfillment email and, optionally, select None from the SW Version drop-down.
When a new firewall is deployed on NSX-T it is automatically added to the device group, licensed
using the authorization code you provided, and upgraded to the PAN-OS version you specified.
On the support portal, you can view the total number of firewalls that you are authorized to deploy
and the ratio of the number of licenses that have been used to the total number of licenses enabled
by your authorization code.
STEP 13 | On the NSX-T Manager, verify that the service definition is available.
Select System > Service Deployments > Catalog. The service definition is listed as a Service Instance on
the NSX-T Manager.
Do not edit any settings under Deployment Attributes. These values are imported from
Panorama and changing them causes the deployment to fail.
244 VM-SERIES DEPLOYMENT GUIDE | Set Up the VM-Series Firewall on VMware NSX
© 2021 Palo Alto Networks, Inc.
STEP 2 | Select System > Service Deployments > Deployment.
STEP 3 | Select your service definition from the Partner Service drop-down.
STEP 8 | If you selected Clustered as the Deployment Type, enter the Clustered Deployment Count to
specify the number of VM-Series firewall instances to deploy on the cluster.
STEP 9 | Select a Host if you are launching the VM-Series in a clustered deployment. Select a particular
host from the Host drop-down or Any to allow NSX-T Manager to choose the host. This option
is grayed out in Per Host deployments.
STEP 10 | Select a Data Store as the repository for the VM-Series firewall. In a clustered deployment,
select a shared data store if you choose Any for the host or select a local data store if you
specified a particular host.
STEP 12 | Select or configure a Service Segment. To configure a service segment, complete the
following procedure.
1. Click Action in the Service Segments column.
STEP 13 | Select the Cluster where the service will be deployed. You must select a cluster with NSX
Configuration.
VM-SERIES DEPLOYMENT GUIDE | Set Up the VM-Series Firewall on VMware NSX 245
© 2021 Palo Alto Networks, Inc.
2. Confirm that your firewalls are listed and the Deployment Status shows Up.
STEP 1 | Select Security > Network Introspection Settings > Service Chains > Add Chain.
STEP 2 | Enter a descriptive Name and Description (optional) for your service chain.
STEP 3 | Select the Service Segment that you applied when you deployed the VM-Series firewall.
STEP 4 | Set the forward path. The service chain is a logical sequence of service profiles, so traffic
moves through the services in the order you specify as the forward path.
1. Select Set Forward Path > Add Profile in Sequence.
2. Select a service profile. The service column is populated automatically based on the service profile
you select.
3. Click Add.
4. (Optional) If you have other partner service profiles in your NSX-T environment, click Add Profile in
Sequence to add them to this service chain.
You can select only one service profile per service definition.
STEP 5 | In the Reverse Path column, check Inverse ForwardPath for return traffic to move through the
service chain in reverse order.
STEP 6 | (Optional) If other partner service profiles are selected, set a reverse path.
You must select the same VM-Series service profile set in the Forward Path.
246 VM-SERIES DEPLOYMENT GUIDE | Set Up the VM-Series Firewall on VMware NSX
© 2021 Palo Alto Networks, Inc.
STEP 7 | Set the Failure Policy—Allow or Block. This defines the action NSX-T takes if a service profile
fails.
STEP 1 | Select Security > Network Introspection (E-W) > Rules > Add Policy.
VM-SERIES DEPLOYMENT GUIDE | Set Up the VM-Series Firewall on VMware NSX 247
© 2021 Palo Alto Networks, Inc.
2. Check the destination group or groups.
3. Click Apply.
248 VM-SERIES DEPLOYMENT GUIDE | Set Up the VM-Series Firewall on VMware NSX
© 2021 Palo Alto Networks, Inc.
2. Select the Device Group you created for managing your VM-Series on NSX-T firewall from the
Device Group drop-down.
3. Click Add and enter a Name and Description for the dynamic address group.
4. Select Type as Dynamic.
5. Add Match Criteria to your dynamic address group.
Some browser extensions may block API calls between Panorama and NSX-T which
prevents Panorama from receiving match criteria. If Panorama displays no match
criteria and you are using browser extensions, disable the extensions and Synchronize
Dynamic Objects to populate the tags available to Panorama.
6. Click Add Match Criteria.
7. Select the And or Or operator and click the plus (+) icon next to the security group name to add it to
the dynamic address group.
The security groups that display in the match criteria dialog are derived from the
groups you defined on the NSX-T Manager. Only the groups that are referenced in
the security policies and from which traffic is redirected to the VM-Series firewall are
available here.
8. Click OK.
9. Repeat these steps to create the appropriate number of dynamic address groups required for your
deployment.
10.Commit your changes.
VM-SERIES DEPLOYMENT GUIDE | Set Up the VM-Series Firewall on VMware NSX 249
© 2021 Palo Alto Networks, Inc.
7. Specify the action— Allow or Deny—for the traffic, and optionally attach the default security profiles
for antivirus, anti-spyware, and vulnerability protection, under Profiles.
8. Repeats the steps above to create the pertinent policy rules.
9. Click Commit, select Commit Type as Panorama. Click OK.
STEP 5 | Validate that the members of the dynamic address group are populated on the VM-Series
firewall.
1. From Panorama, switch device context to launch the web interface of a firewall to which you pushed
policies.
2. On the VM-Series firewall, select Policies > Security, and select a rule.
3. Select the drop-down arrow next to the address group link, and select Inspect. You can also verify
that the match criteria is accurate.
4. Click the more link and verify that the list of registered IP addresses is displayed.
Policy will be enforced for all IP addresses that belong to this address group, and are displayed here.
STEP 6 | (Optional) Use template to push a base configuration for network and device configuration such
as DNS server, NTP server, Syslog server, and login banner.
Refer to the Panorama Administrator’s Guide for information on using templates.
STEP 8 | Create a DoS Protection profile and attach it to DoS Protection policy rule.
1. Select your Device Group.
2. Select Objects > Security Profiles > DoS Protection to add and configure a new profile.
• A classified profile allows the creation of a threshold that applies to a single source IP. For
example, you can configure a max session rate for an IP address that matched the policy, and then
block that single IP address once the threshold is triggered.
• An aggregate profile allows the creation of a max session rate for all packets matching the policy.
The threshold applies to new session rate for all IP addresses combined. Once the threshold is
triggered it affects all traffic that matches the policy.
3. Create a new DoS Protection policy rule in Policy > DoS Protection, and attach the new profile to it.
250 VM-SERIES DEPLOYMENT GUIDE | Set Up the VM-Series Firewall on VMware NSX
© 2021 Palo Alto Networks, Inc.
Use vMotion to Move the VM-Series Firewall Between Hosts
To maintain traffic flow while using vMotion to move your VM-Series firewall between ESXi hosts with
homogeneous CPU configurations in VMware NSX-T, you must use the PAN-OS CLI to pause the internal
heartbeat monitoring of the VM-Series firewall during vMotion. You can specify the amount of time, in
minutes, that heartbeat monitoring is paused. Heartbeat monitoring can be paused for up to 60 minutes.
When the pause interval expires or you deliberately end the pause interval, heartbeat monitoring resumes.
vMotion of the VM-Series firewall is supported on vSphere 6.5, 6.7, and 7.0 if the ESXi hosts have
homogeneous CPU configuration.
This procedure is not required when using vMotion to move the VM-Series firewall if you are
running vSphere 7.0 or later.
STEP 2 | Set the heartbeat monitoring pause interval using the following command. The pause begins as
soon as the command is executed. If vMotion is taking longer than expected, you can rerun this
command to set a new, longer interval that starts when the command is executed again.
request system heartbeat-pause set interval <pause-time-in-minutes>
You can view the time remaining in pause interval using the following command.
request system heartbeat-pause show interval
STEP 3 | (Optional) If you complete vMotion before the pause interval has elapsed, you can end the
pause by setting the interval to zero (0).
request system heartbeat-pause set interval 0
STEP 1 | Install the Panorama Plugin for VMware NSX 3.2.0 or later. See the Panorama Plugin for
VMware NSX 3.2.0 Release Notes before upgrading.
STEP 2 | Configure an NSX-T service definition for each NSX-V service definition in your deployment.
Do not create new device groups; instead use your existing NSX-V device groups. Using the
existing device groups allows you to apply the same security policy rules used on NSX-V to the
VM-Series firewalls deployed on NSX-T. If you have policy that reference a particular zone, add
the same template stack from your NSX-V service definition to your NSX-T service definition.
Additionally, if your device group references a particular template, ensure that you select the
template stack that includes the template referenced in the device group.
VM-SERIES DEPLOYMENT GUIDE | Set Up the VM-Series Firewall on VMware NSX 251
© 2021 Palo Alto Networks, Inc.
STEP 3 | Configure an NSX-T service manager and associate the NSX-T service definitions to the service
manager.
STEP 4 | Prepare your NSX-T environment and deploy the VM-Series firewall. You must create your
security groups, service chains, and traffic redirection policy before launching the VM-Series
firewall.
• Deploy the VM-Series Firewall on NSX-T (North-South)
• Deploy the VM-Series Firewall on NSX-T (East-West)
STEP 5 | Add the NSX-T tags to you existing dynamic address groups.
1. Select Panorama > Objects > Address Groups.
2. Click on the name of an existing NSX-V dynamic address group.
3. Click Add Match Criteria to display the tags from NSX-V and NSX-T.
4. Add the NSX-T tag to the dynamic address groups. Be sure to use the OR operator between the tags.
5. When you have added all the necessary tags, click OK.
6. Commit your changes.
STEP 6 | After your VM workloads have successfully migrated from NSX-V to NSX-T, you remove
the NSX-V tags from your dynamic address groups if you plan to discontinue use of NSX-
V. All NSX-V tags and corresponding IP addresses are unregistered after all NSX-V related
configuration is removed from the Panorama plugin for NSX and VM-Series firewall
configuration is removed from NSX-V manager.
252 VM-SERIES DEPLOYMENT GUIDE | Set Up the VM-Series Firewall on VMware NSX
© 2021 Palo Alto Networks, Inc.
This procedure supports operations-centric NSX-V deployments only. An operations-centric deployment
means that your policy rules for redirecting traffic to the VM-Series firewall were created in NSX-V
Manager, not Panorama.
It is recommended that plan for security downtime while performing this migration.
STEP 1 | Prepare your NSX-V and NSX-T environments for migration based on the steps described by
VMware.
STEP 2 | Install the Panorama Plugin for VMware NSX 3.2.0 or later. See the Panorama Plugin for
VMware NSX 3.2.0 Release Notes before upgrading.
STEP 4 | Configure an NSX-T service definition for each NSX-V service definition in your deployment.
Do not create new device groups; instead use your existing NSX-V device groups. Using the
existing device groups allows you to apply the same security policy rules used on NSX-V to the
VM-Series firewalls deployed on NSX-T. If you have policy that reference a particular zone, add
the same template stack from your NSX-V service definition to your NSX-T service definition.
Additionally, if your device group references a particular template, ensure that you select the
template stack that includes the template referenced in the device group.
STEP 5 | Configure an NSX-T service manager and associate the NSX-T service definitions to the service
manager.
VM-SERIES DEPLOYMENT GUIDE | Set Up the VM-Series Firewall on VMware NSX 253
© 2021 Palo Alto Networks, Inc.
STEP 7 | If you have not already done so, add a compute manager in NSX-T Manager. After you have
verified that the Registration Status and Connection Status are up, continue below.
STEP 10 | Resolve Configuration issues on NSX-T Manager. While resolving configuration issues, you
must take specific actions to migrate your VM-Series firewall configuration. In most cases,
you can accept the recommendations presented by NSX-T Manager.
1. When resolving service insertion configuration, verify that you selected the correct service definition
that you previously configured on Panorama for the VM-Series on NSX-T.
254 VM-SERIES DEPLOYMENT GUIDE | Set Up the VM-Series Firewall on VMware NSX
© 2021 Palo Alto Networks, Inc.
2. Map the NSX-T service profile to the corresponding NSX-V service profile.
VM-SERIES DEPLOYMENT GUIDE | Set Up the VM-Series Firewall on VMware NSX 255
© 2021 Palo Alto Networks, Inc.
STEP 11 | Migrate the configuration.
STEP 15 | Add the NSX-T tags to you existing dynamic address groups.
1. Select Panorama > Objects > Address Groups.
2. Click on the name of an existing NSX-V dynamic address group.
3. Click Add Match Criteria to display the tags from NSX-V and NSX-T.
4. Add the NSX-T tag to the dynamic address groups. If you choose not to remove the NSX-V tags, be
sure to use the OR operator between the tags.
256 VM-SERIES DEPLOYMENT GUIDE | Set Up the VM-Series Firewall on VMware NSX
© 2021 Palo Alto Networks, Inc.
5. When you have added all the necessary tags, click OK.
6. Commit your changes.
STEP 16 | Launch the VM-Series Firewall on NSX-T (East-West). You do not need to create a new
service segment; instead select the service segment created during migration.
VM-SERIES DEPLOYMENT GUIDE | Set Up the VM-Series Firewall on VMware NSX 257
© 2021 Palo Alto Networks, Inc.
258 VM-SERIES DEPLOYMENT GUIDE | Set Up the VM-Series Firewall on VMware NSX
Set Up the VM-Series Firewall on AWS
The VM-Series firewall can be deployed in the public Amazon Web Services (AWS) cloud
and AWS GovCloud. It can then be configured to secure access to the applications that are
deployed on EC2 instances and placed into a Virtual Private Cloud (VPC) on AWS.
259
260 VM-SERIES DEPLOYMENT GUIDE | Set Up the VM-Series Firewall on AWS
© 2021 Palo Alto Networks, Inc.
About the VM-Series Firewall on AWS
The Amazon Web Service (AWS) is a public cloud service that enables you to run your applications on a
shared infrastructure managed by Amazon. These applications can be deployed on scalable computing
capacity or EC2 instances in different AWS regions and accessed by users over the internet.
For networking consistency and ease of management of EC2 instances, Amazon offers the Virtual Private
Cloud (VPC). A VPC is apportioned from the AWS public cloud, and is assigned a CIDR block from the
private network space (RFC 1918). Within a VPC, you can carve public/private subnets for your needs and
deploy the applications on EC2 instances within those subnets. To then enable access to the applications
within the VPC, you can deploy the VM-Series firewall on an EC2 instance. The VM-Series firewall can then
be configured to secure traffic to and from the EC2 instances within the VPC.
The VM-Series firewall is available in both the public AWS cloud and on AWS GovCloud. The VM-Series
firewall in public AWS and AWS GovCloud supports the Bring Your Own License (BYOL) model and
the hourly Pay-As-You-Go (PAYG), the usage-based licensing model that you can avail from the AWS
Marketplace. For licensing details, see VM-Series Firewall Licenses for Public Clouds.
• AWS EC2 Instance Types
• VM-Series Firewall on AWS GovCloud
• VM-Series Firewall on AWS China
• VM-Series Firewall on AWS Outposts
• AWS Terminology
• Management Interface Mapping for Use with Amazon ELB
See Register the VM-Series Firewall (with auth code), to create a support account and register the VM-
Series firewall on the Palo Alto Networks Customer Support website for activating your support entitlement
with Palo Alto Networks.
AWS Terminology
This document assumes that you are familiar with the networking and configuration of the AWS VPC. In
order to provide context for the terms used in this section, here is a brief refresher on the AWS terms (some
definitions are taken directly from the AWS glossary) that are referred to in this document:
Term Description
IP address types for An EC2 instance can have different types of IP addresses.
EC2 instances
• Public IP address: An IP address that can be routed across the internet.
• Private IP address: A IP address in the private IP address range as defined
in the RFC 1918. You can choose to manually assign an IP address or
to auto assign an IP address within the range in the CIDR block for the
subnet in which you launch the EC2 instance.
If you are manually assigning an IP address, Amazon reserves the first four (4)
IP addresses and the last one (1) IP address in every subnet for IP networking
purposes.
• Elastic IP address (EIP): A static IP address that you have allocated in
Amazon EC2 or Amazon VPC and then attached to an instance. Elastic IP
addresses are associated with your account, not with a specific instance.
They are elastic because you can easily allocate, attach, detach, and free
them as your needs change.
An instance in a public subnet can have a Private IP address, a Public IP
address, and an Elastic IP address (EIP); an instance in a private subnet will
have a private IP address and optionally have an EIP.
Instance type Amazon-defined specifications that stipulate the memory, CPU, storage
capacity, and hourly cost for an instance. Some instance types are designed
for standard applications, whereas others are designed for CPU-intensive,
memory-intensive applications, and so on.
Subnets A segment of the IP address range of a VPC to which EC2 instances can be
attached. EC2 instances are grouped into subnets based on your security and
operational needs.
There are two types of subnets:
• Private subnet: The EC2 instances in this subnet cannot be reached from
the internet.
• Public subnet: The internet gateway is attached to the public subnet, and
the EC2 instances in this subnet can be reached from the internet.
Security groups A security group is attached to an ENI and it specifies the list of protocols,
ports, and IP address ranges that are allowed to establish inbound/outbound
connections on the interface.
Route tables A set of routing rules that controls the traffic leaving any subnet that is
associated with the route table. A subnet can be associated with only one
route table.
Key pair A set of security credentials you use to prove your identity electronically. The
key pair consists of a private key and a public key. At time of launching the
VM-Series firewall, you must generate a key pair or select an existing key pair
for the VM-Series firewall. The private key is required to access the firewall in
maintenance mode.
At present, for use cases that require an ELB sandwich-type deployment to scale out
firewalls and application layer EC2 instances, swapping the management interface will
not allow you to seamlessly deploy the ELB solution. The ability to swap the management
interface only partially solves the integration with ELB.
To allow the firewall to send and receive dataplane traffic on eth0 instead of eth1, you must swap the
mapping of the ENIs within the firewall such that ENI eth0 maps to ethernet 1/1 and ENI eth1 maps to the
MGT interface on the firewall as shown below.
If possible, swap the management interface before you configure the firewall or define policy
rules.
Swapping how the interfaces are mapped allows ELB to distribute and route traffic to healthy instances of
the VM-Series firewall located in the same or different Availability Zones on AWS for increased capacity
and fault tolerance.
The interface swap is only required when the VM-Series firewall is behind the Amazon ELB Service. If your
requirement is to deploy the VM-Series firewalls in a traditional high availability set up, you don’t need to
configure the interface swap that is described in this section. Continue to High Availability for VM-Series
Firewall on AWS.
To swap the interfaces, you have the following options:
• At launch—When you launch the firewall, you can either enter the mgmt-interface-swap=enable
command in the User data field on the AWS management console (see Launch the VM-Series Firewall
on AWS) or CLI or you can include the new mgmt-interface-swap operational command in the
bootstrap configuration.
• After launch—After you launch the firewall, Use the VM-Series Firewall CLI to Swap the Management
Interface (set system setting mgmt-interface-swap enable yes operational command) on
the firewall.
The C5 and M5 instance types that have the Elastic Network Adapter support SR-IOV
mode only on PAN-OS 9.0.3 and earlier versions. DPDK support is available starting with
PAN-OS 9.0.3.xfr.
• Select the VM-Series model and VM-Series firewall license that best suits your deployment needs. For
help with sizing, refer to this article.
• Enable DPDK using the CLI command set system setting dpdk-pkt-io on or bootstrap the
firewall to use DPDK at launch, except if deploying the firewalls in an HA configuration. See init-cfg.txt
File Components.
For SR-IOV and DPDK driver support by PAN-OS version, see SR-IOV and DPDK Drivers on VM-Series
Firewalls.
• Deploy the VM-Series firewall for VPN access between the corporate network and the EC2 instances
within the AWS Virtual Private Cloud.
To connect your corporate network with the applications deployed in the AWS Cloud, you can configure
the firewall as a termination point for an IPSec VPN tunnel. This VPN tunnel allows users on your
network to securely access the applications in the cloud.
For centralized management, consistent enforcement of policy across your entire network, and for
centralized logging and reporting, you can also deploy Panorama in your corporate network. If you need
to set up VPN access to multiple VPCs, using Panorama allows you to group the firewalls by region and
administer them with ease.
• Deploy the VM-Series firewall as a GlobalProtect gateway to secure access for remote users using
laptops. The GlobalProtect agent on the laptop connects to the gateway, and based on the request,
the gateway either sets up a VPN connection to the corporate network or routes the request to the
internet. To enforce security compliance for users on mobile devices (using the GlobalProtect App), the
GlobalProtect gateway is used in conjunction with the GlobalProtect Mobile Security Manager. The
GlobalProtect Mobile Security Manager ensures that mobile devices are managed and configured with
the device settings and account information for use with corporate applications and networks.
In each of the use cases above, you can deploy the VM-Series firewall in an active/
passive high availability (HA) pair. For information on setting up the VM-Series firewall in
HA, see Use Case: Use Dynamic Address Groups to Secure New EC2 Instances within the
VPC.
• Deploy the VM-Series firewall with the Amazon Elastic Load Balancing (ELB) service, whereby the
firewall can receive dataplane traffic on the primary interface in the following scenarios where the VM-
Series firewall is behind the Amazon ELB:
• The VM-Series firewall(s) is securing traffic outbound directly to the internet without the need for
using a VPN link or a Direct Connect link back to the corporate network.
• The VM-Series firewall secures an internet-facing application when there is exactly one back-end
server, such as a web server, for each firewall. The VM-Series firewalls and web servers can scale
linearly, in pairs, behind ELB.
If you want to Auto Scale VM-Series Firewalls with the Amazon ELB Service, use the CloudFormation
Template available in the GitHub repository repository to deploy the VM-Series in an ELB sandwich
topology with an internet-facing classic ELB and an either an internal classic load balancer or an internal
application load balancer (internal ELB).
You cannot configure the firewall to send and receive dataplane traffic on eth0 when the
firewall is in front of ELB. The VM-Series firewall must be placed behind the Amazon ELB.
You can either Use the VM-Series Firewall CLI to Swap the Management Interface or enable
it on bootstrap. For details, see Management Interface Mapping for Use with Amazon ELB.
If you want to deploy a load balancer sandwich topology, see Auto Scale VM-Series Firewalls
with the Amazon ELB Service.
In addition to the links above that are covered under the Palo Alto Networks official support
policy, Palo Alto Networks provides Community supported templates in the Palo Alto
Networks GitHub repository that allow you to explore the solutions available to jumpstart
your journey into cloud automation and scale on AWS. See AWS Transit VPC for a hub and
subscribing VPC deployment that enables you to secure traffic between VPCs, between a
VPC and an on-prem/hybrid cloud resource, and secure outbound traffic to the internet.
For purchasing licenses with the BYOL option, contact your Palo Alto Networks sales engineer or reseller.
Requirement Details
EC2 instance types The EC2 instance type you select must meet the VM-Series System
Requirements for the VM-Series firewall model. If you deploy the VM-Series
firewall on an EC2 instance type that does not meet these requirements, the
firewall will boot into maintenance mode
Amazon Elastic Block The VM-Series firewall must use the Amazon Elastic Block Storage (EBS)
Storage (EBS) volume for storage. EBS optimization provides an optimized configuration
stack and additional, dedicated capacity for Amazon EBS I/O.
Networking Because the AWS only supports Layer 3 networking capabilities, the
VM-Series firewall can only be deployed with Layer 3 interfaces. Layer 2
Support entitlement For the Bring Your Own License model, a support account and a valid VM-
and Licenses Series license are required to obtain the Amazon Machine Image (AMI) file,
which is required to install the VM-Series firewall in the AWS VPC. The
licenses required for the VM-Series firewall—capacity license, support license,
and subscriptions for Threat Prevention, URL Filtering, WildFire, etc—must
be purchased from Palo Alto Networks. To purchase the licenses for your
deployment, contact your sales representative. See VM-Series Firewall
Licenses for Public Clouds.
For the usage-based licensing model, hourly and annual pricing bundles can
be purchased and billed directly to AWS. You must however, register your
support entitlement with Palo Alto Networks. For details see, Register the
Usage-Based Model of the VM-Series Firewall for Public Clouds (no auth
code).
STEP 1 | Install AWS CLI on the client that you are using to retrieve the AMI ID, and login with your
AWS credentials.
Refer to the AWS documentation for instructions on installing the CLI.
You need to replace the value in the angle brackets <> with the relevant information as shown below:
• Use the VM-Series product code for each license type. The values are:
e9yfvyj3uag5uo5j2hjikv74n
• Bundle 2—
hd44w1chf26uv4p52cdynb2o
• BYOL—
6njl1pau431dv1qxipg63mvah
• Use the PAN-OS version— 10.0. If there are multiple feature releases within a PAN-OS version all the
AMI-IDs are listed for you. For example, in 9.0.x, you will view a listing of the AMI IDs for PAN-OS
versions 9.0, 9.0.3.xfr, 9.0.5.xfr, and 9.0.6, and you can use the AMI-ID for the PAN-OS version you
need.
• Get the AWS region details from: https://docs.aws.amazon.com/general/latest/gr/rande.html.
For example: To find the AMI-ID for the VM-Series Bundle 1 for PAN-OS 10.0.0 in US California region,
the CLI command is:
"ProductCodes": [
"ProductCodeId": "e9yfvyj3uag5uo5j2hjikv74n",
"ProductCodeType": "marketplace"
],
"VirtualizationType": "hvm",
"Hypervisor": "xen",
"ImageOwnerAlias": "aws-marketplace",
"EnaSupport": true,
"SriovNetSupport": "simple",
"ImageId": "ami-06f7a63d7481d0ded",
"BlockDeviceMappings": [
"DeviceName": "/dev/xvda",
"Ebs": {
"SnapshotId": "snap-0009036179b39824b",
"DeleteOnTermination": false,
"VolumeType": "gp2",
"VolumeSize": 60,
"Encrypted": false
],
"Architecture": "x86_64",
"ImageLocation": "aws-marketplace/PA-VM-AWS-10.0.0-
f1260463-68e1-4bfb-bf2e-075c2664c1d7-ami-06f7a63d7481d0ded.1",
"RootDeviceType": "ebs",
"OwnerId": "679593333241",
"RootDeviceName": "/dev/xvda",
"CreationDate": "2020-07-20T12:45:22.000Z",
"Public": true,
"ImageType": "machine",
"Name": "PA-VM-AWS-10.0.0-f1260463-68e1-4bfb-
bf2e-075c2664c1d7-ami-06f7a63d7481d0ded.1"
You can also output to a table format. For example, to see AMI for BYOL image for PAN-OS 10.0.2:
--------------------------------------------------------------------------------------
DescribeImages
|+-----------------------
+---------------------------------------------------------------------------------
All VM-Series firewall interfaces must be assigned an IPv4 address when deployed in a
public cloud environment. IPv6 addresses are not supported.
VPC CIDR
Security Groups
Security Groups
• Rules for Management Access to
the firewall (eth0/0)
• Rules for access to the dataplane
interfaces of the firewall
• Rules for access to the interfaces
assigned to the application servers.
All VM-Series firewall interfaces must be assigned an IPv4 address when deployed in a
public cloud environment. IPv6 addresses are not supported.
Although you can add additional network interfaces (ENIs) to the VM-Series firewall when
you launch, AWS releases the auto-assigned Public IP address for the management
interface when you restart the firewall. Hence, to ensure connectivity to the management
interface you must assign an Elastic IP address for the management interface, before
attaching additional interfaces to the firewall.
If you want to conserve EIP addresses, you can assign one EIP address to the eth 1/1 interface and
use this interface for both management traffic and data traffic. To restrict services permitted on the
interface or limit IP addresses that can log in the eth 1/1 interface, attach a management profile to the
interface.
1. On the EC2 Dashboard, click Launch Instance.
2. Select the VM-Series AMI. To get the AMI, see Obtain the AMI.
3. Launch the VM-Series firewall on an EC2 instance.
1. Choose the EC2 instance type for allocating the resources required for the firewall, and click
Next. See VM-Series System Requirements, for resource requirements.
2. Select the VPC.
3. Select the public subnet to which the VM-Series management interface will attach.
4. Select Automatically assign a public IP address. This allows you to obtain a publicly accessible IP
address for the management interface of the VM-Series firewall.
You can later attach an Elastic IP address to the management interface; unlike the public IP
address that is disassociated from the firewall when the instance is terminated, the Elastic IP
address provides persistence and can be reattached to a new (or replacement) instance of the
VM-Series firewall without the need to reconfigure the IP address wherever you might have
referenced it.
Bootstrap Package—If you are bootstrapping the firewall with the bootstrap package, you
can also enter a semicolon separator after mgmt-interface-swap=enable, then enter
vmseries-bootstrap-aws-s3bucket=<bucketname>.
User Data—If you are bootstrapping with user data, enter a semicolon separator after mgmt-
interface-swap=enable, and enter additional key-value pairs according to Enter a Basic
Configuration as User Data (Public Clouds).
AWS Secret—If you are bootstrapping with an AWS secret, enter a semicolon separator
after mgmt-interface-swap=enable, and enter the secret name as a key-value pair, as
described in Step 3 of Bootstrap the VM-Series Firewall on AWS. For example:
7. Accept the default Storage settings. The firewall uses volume type SSD (gp2).
This key pair is required for first time access to the firewall. It is also required to
access the firewall in maintenance mode.
8. (Optional) Tagging. Add one or more tags to create your own metadata to identify and group the
VM-Series firewall. For example, add a Name tag with a Value that helps you remember that the
ENI interfaces have been swapped on this VM-Series firewall.
On the VM-Series firewall CLI, you must configure a unique administrative password
before you can access the web interface of the firewall. To log in to the CLI, you require
the private key that you used to launch the firewall.
1. Use the public IP address to SSH into the Command Line Interface (CLI) of the VM-Series firewall.
You will need the private key that you used or created in 3 above to access the CLI.
If you added an additional ENI to support deployments with ELB, you must first create
and assign an Elastic IP address to the ENI to access the CLI, see 6.
If you are using PuTTY for SSH access, you must convert the .pem format to a .ppk format. See
https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/putty.html
2. Enter the following command to log in to the firewall:
ssh-i <private_key.pem> admin@<public-ip_address>
3. Configure a new password, using the following command and follow the onscreen prompts:
configure
set mgt-config users admin password
4. If you have a BYOL that needs to be activated, set the DNS server IP address so that the firewall can
aceess the Palo Alto Networks licensing server. Enter the following command to set the DNS server
IP address:
set deviceconfig system dns-setting servers primary <ip_address>
5. Commit your changes with the command:
commit
6. Terminate the SSH session.
STEP 6 | Create and assign an Elastic IP address (EIP) to the ENI used for management access to the
firewall and reboot the VM-Series firewall.
1. Select Elastic IPs and click Allocate New Address.
2. Select EC2-VPC and click Yes, Allocate.
3. Select the newly allocated EIP and click Associate Address.
4. Select the Network Interface and the Private IP address associated with the management interface
and click Yes, Associate.
7. To attach the ENI to the VM-Series firewall, select the interface you just created, and click Attach.
STEP 8 | (Not required for the Usage-based licensing model) Activate the licenses on the VM-Series firewall.
This task is not performed on the AWS management console. Access to the Palo Alto
Networks support portal and the web interface of the VM-Series firewall is required for
license activation.
STEP 9 | Disable Source/Destination check on every firewall dataplane network interface(s). Disabling
this option allows the interface to handle network traffic that is not destined to the IP address
assigned to the network interface.
1. On the EC2 Dashboard, select the network interface, for example eth1/1, in the Network Interfaces
tab.
2. In the Action drop-down, select Change Source/Dest. Check.
STEP 10 | Configure the dataplane network interfaces as Layer 3 interfaces on the firewall.
For an example configuration, see steps 14 through 17 in Use Case: Secure the EC2 Instances in the
AWS Cloud.
On the application servers within the VPC, define the dataplane network interface of the
firewall as the default gateway.
1. Using a secure connection (https) from your web browser, log in using the EIP address and password
you assigned during initial configuration (https://<Elastic_IP address>). You will see a certificate
warning; that is okay. Continue to the web page.
2. Select Network > Interfaces > Ethernet.
3. Click the link for ethernet 1/1 and configure as follows:
• Interface Type: Layer3
• On the Config tab, assign the interface to the default router.
• On the Config tab, expand the Security Zone drop-down and select New Zone. Define a new
zone, for example VM_Series_untrust, and then click OK.
• On the IPv4 tab, select either Static or DHCP Client.
If using the Static option, click Add in the IP section, and enter the IP address and network mask
for the interface, for example 10.0.0.10/24.
Make sure that the IP address matches the ENI IP address that you assigned earlier.
If using DHCP, select DHCP Client; the private IP address that you assigned to the ENI in the
AWS management console will be automatically acquired.
4. Click the link for ethernet 1/2 and configure as follows:
• Interface Type: Layer3
• Security Zone: VM_Series_trust
• IP address: Select the Static or DHCP Client radio button.
For static, click Add in the IP section, and enter the IP address and network mask for the interface.
Make sure that the IP address matches the attached ENI IP address that you assigned earlier.
5. Click Commit. Verify that the link state for the interfaces are up.
For DHCP, clear the Automatically create default route to default gateway provided by
server check box. For an interface that is attached to the private subnet in the VPC,
disabling this option ensures that traffic handled by this interface does not flow directly
to the internet gateway on the VPC.
STEP 12 | Create security policies to allow/deny traffic to/from the servers deployed within the VPC.
1. Select Policies > Security on the web interface of the firewall.
2. Click Add, and specify the zones, applications and logging options that you would like to execute to
restrict and audit traffic traversing through the network.
STEP 14 | Verify that the VM-Series firewall is securing traffic and that the NAT rules are in effect.
1. Select Monitor > Logs > Traffic on the web interface of the firewall.
2. View the logs to make sure that the applications traversing the network match the security policies
you implemented.
All VM-Series firewall interfaces must be assigned an IPv4 address when deployed in a
public cloud environment. IPv6 addresses are not supported.
Although you can add additional network interfaces (ENIs) to the VM-Series firewall when
you launch, AWS releases the auto-assigned Public IP address for the management
interface when you restart the firewall. Hence, to ensure connectivity to the management
interface you must assign an Elastic IP address for the management interface, before
attaching additional interfaces to the firewall.
If you want to conserve EIP addresses, you can assign one EIP address to the eth 1/1 interface and
use this interface for both management traffic and data traffic. To restrict services permitted on the
interface or limit IP addresses that can log in the eth 1/1 interface, attach a management profile to the
interface.
1. On the EC2 Dashboard, click Launch Instance.
2. Select the VM-Series AMI. To get the AMI, see Obtain the AMI.
3. Launch the VM-Series firewall on an EC2 instance.
1. Choose the EC2 instance type for allocating the resources required for the firewall, and click
Next. See VM-Series System Requirements, for resource requirements.
2. Select the VPC.
3. Select the public subnet on Outpost to which the VM-Series management interface will attach.
4. Select Automatically assign a public IP address. This allows you to obtain a publicly accessible IP
address for the management interface of the VM-Series firewall.
You can later attach an Elastic IP address to the management interface; unlike the public IP
address that is disassociated from the firewall when the instance is terminated, the Elastic IP
address provides persistence and can be reattached to a new (or replacement) instance of the
VM-Series firewall without the need to reconfigure the IP address wherever you might have
referenced it.
5. Select Launch as an EBS-optimized instance.
6. Add another network interface for deployments with ELB so that you can swap the management
and data interfaces on the firewall. Swapping interfaces requires a minimum of two ENIs (eth0 and
eth1).
• Expand the Network Interfaces section and click Add Device to add another network interface.
Make sure that your VPC has more than one subnet so that you can add additional ENIs at
launch.
If you are bootstrapping the firewall, you can also enter vmseries-
bootstrap-aws-s3bucket=<bucketname> with a comma separator after
mgmt-interface-swap=enable.
7. Accept the default Storage settings. The firewall uses volume type SSD (gp2)
This key pair is required for first time access to the firewall. It is also required to
access the firewall in maintenance mode.
8. (Optional) Tagging. Add one or more tags to create your own metadata to identify and group the
VM-Series firewall. For example, add a Name tag with a Value that helps you remember that the
ENI interfaces have been swapped on this VM-Series firewall.
9. Select an existing Security Group or create a new one. This security group is for restricting access
to the management interface of the firewall. At a minimum consider enabling https and ssh access
for the management interface.
10.If prompted, select an appropriate SSD option for your setup.
11.Select Review and Launch. Review that your selections are accurate and click Launch.
12.Select an existing key pair or create a new one, and acknowledge the key disclaimer.
13.Download and save the private key to a safe location; the file extension is .pem. You cannot
regenerate this key, if lost.
It takes 5-7 minutes to launch the VM-Series firewall. You can view the progress on the EC2
Dashboard.When the process completes, the VM-Series firewall displays on the Instances page of
the EC2 Dashboard.
On the VM-Series firewall CLI, you must configure a unique administrative password
before you can access the web interface of the firewall. To log in to the CLI, you require
the private key that you used to launch the firewall.
1. Use the public IP address to SSH into the Command Line Interface (CLI) of the VM-Series firewall.
You will need the private key that you used or created in 3 above to access the CLI.
If you are using PuTTY for SSH access, you must convert the .pem format to a .ppk format. See
https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/putty.html
2. Enter the following command to log in to the firewall:
ssh-i <private_key.pem> admin@<public-ip_address>
3. Configure a new password, using the following command and follow the onscreen prompts:
configure
set mgt-config users admin password
4. If you have a BYOL that needs to be activated, set the DNS server IP address so that the firewall can
aceess the Palo Alto Networks licensing server. Enter the following command to set the DNS server
IP address:
set deviceconfig system dns-setting servers primary <ip_address>
5. Commit your changes with the command:
commit
6. Terminate the SSH session.
STEP 6 | Create and assign an Elastic IP address (EIP) to the ENI used for management access to the
firewall and reboot the VM-Series firewall.
1. Select Elastic IPs and click Allocate New Address.
2. Select EC2-VPC and click Yes, Allocate.
3. Select the newly allocated EIP and click Associate Address.
4. Select the Network Interface and the Private IP address associated with the management interface
and click Yes, Associate.
STEP 7 | Create virtual network interface(s) and attach the interface(s) to the VM-Series firewall. The
virtual network interfaces are called Elastic Network Interfaces (ENIs) on AWS, and serve as
the dataplane network interfaces on the firewall. These interfaces are used for handling data
traffic to/from the firewall.
You will need at least two ENIs that allow inbound and outbound traffic to/from the firewall. You can
add up to seven ENIs to handle data traffic on the VM-Series firewall; check your EC2 instance type to
verify the maximum number supported on it.
1. On the EC2 Dashboard, select Network Interfaces, and click Create Network Interface.
2. Enter a descriptive name for the interface.
3. Select the subnet. Use the subnet ID to make sure that you have selected the correct subnet. You
can only attach an ENI to an instance in the same subnet.
4. Enter the Private IP address to assign to the interface or select Auto-assign to automatically assign
an IP address within the available IP addresses in the selected subnet.
5. Select the Security group to control access to the dataplane network interface.
6. Click Yes, Create.
STEP 8 | (Not required for the Usage-based licensing model) Activate the licenses on the VM-Series firewall.
This task is not performed on the AWS management console. Access to the Palo Alto
Networks support portal and the web interface of the VM-Series firewall is required for
license activation.
STEP 9 | Disable Source/Destination check on every firewall dataplane network interface(s). Disabling
this option allows the interface to handle network traffic that is not destined to the IP address
assigned to the network interface.
1. On the EC2 Dashboard, select the network interface, for example eth1/1, in the Network Interfaces
tab.
2. In the Action drop-down, select Change Source/Dest. Check.
STEP 10 | Configure the dataplane network interfaces as Layer 3 interfaces on the firewall.
For an example configuration, see steps 14 through 17 in Use Case: Secure the EC2 Instances in the
AWS Cloud.
On the application servers within the VPC, define the dataplane network interface of the
firewall as the default gateway.
1. Using a secure connection (https) from your web browser, log in using the EIP address and password
you assigned during initial configuration (https://<Elastic_IP address>). You will see a certificate
warning; that is okay. Continue to the web page.
For DHCP, clear the Automatically create default route to default gateway provided by
server check box. For an interface that is attached to the private subnet in the VPC,
disabling this option ensures that traffic handled by this interface does not flow directly
to the internet gateway on the VPC.
STEP 11 | Create NAT rules to allow inbound and outbound traffic from the servers deployed within the
VPC.
1. Select Policies > NAT on the web interface of the firewall.
2. Create a NAT rule to allow traffic from the dataplane network interface on the firewall to the web
server interface in the VPC.
3. Create a NAT rule to allow outbound access for traffic from the web server to the internet.
STEP 12 | Create security policies to allow/deny traffic to/from the servers deployed within the VPC.
1. Select Policies > Security on the web interface of the firewall.
STEP 14 | Verify that the VM-Series firewall is securing traffic and that the NAT rules are in effect.
1. Select Monitor > Logs > Traffic on the web interface of the firewall.
2. View the logs to make sure that the applications traversing the network match the security policies
you implemented.
When creating a custom AMI with a BYOL version of the firewall, you must first activate the
license on the firewall so that you can access and download PAN-OS software updates to
upgrade your firewall, and then deactivate the license on the firewall before you reset the
firewall to factory defaults and create the custom AMI. If you do not deactivate the license,
you lose the license that you applied on this firewall instance.
STEP 3 | Install software updates and upgrade the firewall to the PAN-OS version you plan to use.
5. Verify that the custom AMI is created and has the correct product code.
1. On the EC2 Dashboard, select AMI.
2. Select the AMI that you just created. Depending on whether you selected an AMI with the BYOL,
Bundle 1, or Bundle 2 licensing options, you should see one of the following Product Codes in the
details:
• BYOL—6njl1pau431dv1qxipg63mvah
• Bundle 1—6kxdw3bbmdeda3o6i1ggqt4km
• Bundle 2—806j2of0qy5osgjjixq9gqc6g
STEP 1 | Create an encryption key on AWS or skip this step if you want to use the default master key
for your account.
You will use this key to encrypt the EBS volume on the firewall. Note that the key is region specific.
STEP 2 | Use the key to encrypt the EBS volume on the firewall.
You must create a copy of the AMI that you want to encrypt. You can copy an AMI that is published
on the AWS public or GovCloud Marketplace, or use a custom AMI (Create a Custom Amazon Machine
Image (AMI)).
1. On the EC2 Dashboard, select the AMI and Copy AMI.
3. Select the encryption key and Copy AMI to create an encrypted EBS snapshot.
4. Select EC2 Dashboard > Snapshots to verify that the EBS snapshot is encrypted with the key you
selected above.
Before you proceed, verify that the firewall has a minimum of two ENIs (eth0 and eth1).
If you launch the firewall with only one ENI, the interface swap command will cause the
firewall to boot into maintenance mode.
STEP 2 | On the EC2 Dashboard, view the IP address of the eth1 interface and verify that the AWS
Security Group rules allow connections (HTTPS and SSH) to the new management interface
(eth1).
STEP 3 | Log in to the VM-Series firewall CLI and enter the following command:
set system setting mgmt-interface-swap enable yes
STEP 4 | Confirm that you want to swap the interface and use the eth1 dataplane interface as the
management interface.
STEP 5 | Reboot the firewall for the swap to take effect. Use the following command:
request restart system
STEP 6 | Verify that the interfaces have been swapped. Use the following command:
STEP 1 | Assign the appropriate permissions for the AWS Identity and Access Management (IAM) user
role that you use to deploy the VM-Series firewall on AWS.
Whether you launch a new instance of the VM-Series firewall or upgrade an existing VM-Series firewall
on AWS, the IAM role associated with your instance, must have permissions to publish metrics to
CloudWatch.
1. On the AWS console, select IAM.
2. Edit the IAM role to grant the following permissions:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"cloudwatch:PutMetricData"
],
1. Enter the CloudWatch Namespace to which the firewall can publish metrics. The namespace
cannot begin with AWS.
The aggregated metrics for all VM-Series firewall in an HA pair or auto scaling deployment are
published to the namespace you entered above. The namespace with the _dimensions suffix
that is automatically created enables you to filter and view metrics for an specific VM-Series
firewall using the hostname or AWS instance ID metadata attached to the firewall.
2. Set the Update Interval to a value between 1-60 minutes. This is the frequency at which the
firewall publishes the metrics to CloudWatch. The default is 5 minutes.
To ensure that the VM-Series firewall can inspect traffic that is routed between VPC attachments, you
must enable appliance mode on the transit gateway VPC attachment for the security VPC containing
the VM-Series firewall. This ensures that bidirectional traffic is routed symmetrically—both request and
response traffic are directed to the same Gateway Endpoint in the firewall VPC and the GWLB will maintain
persistence to the same VM-Series firewall for inspection before continuing to the correct destination.
When deployed with a GWLB, you can use the VM-Series firewall to protect:
• Inbound traffic—traffic originating outside the VPC and destined to resources within your application
VPC, such as web servers. VM-Series firewalls prevent malware and vulnerabilities from entering the
network in traffic allowed by AWS security groups.
• Outbound traffic—traffic originating within the application VPCs and destined to external resources
on the Internet. The VM-Series firewalls protect outbound traffic flows by ensuring that workloads in
application VPCs connect to permitted services (such as Windows Update) and allowed URL categories
and preventing data exfiltration of sensitive information. Additionally, VM-Series security profiles
prevent malware and vulnerabilities from entering the network in the return traffic.
mgmt-interface-swap=enable set system setting mgmt- Swaps eth0 and eth1. Eth0
interface-swap enable yes becomes a data interface and
eth1 becomes the management
This command interface.
requires the
firewall to reboot
before taking
effect.
If you associate VPC endpoints to an interface or subinterfaces via user data while
bootstrapping and your bootstrap.xml file does not include the interface configuration, you
can configure the interfaces after the firewall boots up.
All VM-Series firewall interfaces must be assigned an IPv4 address when deployed in a
public cloud environment. IPv6 addresses are not supported.
STEP 1 | Set up the security VPC. See the AWS documentation for more information about creating
your security VPC.
• Create two subnets—one for management and one for data.
• Create two security groups—one for firewall management and one for data.
• The management subnet security groups should allow https and ssh for management access.
• Ensure that the security group(s) in your data VPC allows GENEVE-encapsulated packets (UDP port
6081).
• If your deployment includes a transit gateway and traffic that will move between VPCs, you must
enable appliance mode on security VPC attachment.
The target group of the GWLB cannot use HTTP for health checks because the VM-
Series firewall does not allow access with an unsecured protocol. Instead, use another
protocol such as HTTPS or TCP.
If you set the target type to the IP address of a specific interface on the VM-
Series firewall, you do not need to enable management interface swap.
6. Accept the default Storage settings. The firewall uses volume type SSD (gp2).
7. If prompted, select an appropriate SSD option for your setup.
8. (Optional) Tagging. Add one or more tags to create your own metadata to identify and group the
VM-Series firewall. For example, add a Name tag with a Value that helps you remember that the
ENI interfaces have been swapped on this VM-Series firewall.
9. Select the data Security Group for eth0 (data interface). Enable traffic on UDP port 6081.
If you enable health checks to the firewall, you cannot use HTTP. Instead, use another protocol
such as HTTPS or TCP.
10.Select Review and Launch. Review that your selections are accurate and click Launch.
11.Select an existing key pair or create a new one, and acknowledge the key disclaimer.
This key pair is required for first time access to the firewall. It is also required to
access the firewall in maintenance mode.
12.Download and save the private key to a safe location; the file extension is .pem. You cannot
regenerate this key, if lost.
It takes 5-7 minutes to launch the VM-Series firewall. You can view the progress on the EC2
Dashboard.When the process completes, the VM-Series firewall displays on the Instances page of
the EC2 Dashboard.
STEP 3 | Attach the management security group to eth1 (management interface). Allow ssh and https.
See the AWS Documentation for more information.
STEP 4 | Create and assign an Elastic IP address (EIP) to the ENI used for management access (eth1) to
the firewall.
1. Select Elastic IPs and click Allocate New Address.
2. Select EC2-VPC and click Yes, Allocate.
On the VM-Series firewall CLI, you must configure a unique administrative password
before you can access the web interface of the firewall. To log in to the CLI, you require
the private key that you used to launch the firewall.
1. Use the EIP to SSH into the Command Line Interface (CLI) of the VM-Series firewall. You will need
the private key that you used or created above and using the user name admin to access the CLI.
If you are using PuTTY for SSH access, you must convert the .pem format to a .ppk format. See
https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/putty.html
2. Enter the following command to log in to the firewall:
ssh-i <private_key.pem> admin@<public-ip_address>
3. Configure a new password, using the following command and follow the onscreen prompts:
configure
set mgt-config users admin password
4. If you have a BYOL that needs to be activated, set the DNS server IP address so that the firewall can
aceess the Palo Alto Networks licensing server. Enter the following command to set the DNS server
IP address:
set deviceconfig system dns-setting servers primary <ip_address>
5. Commit your changes with the command:
commit
6. Terminate the SSH session.
STEP 6 | Configure the dataplane network interface as a Layer 3 interface on the firewall.
On the application servers within the VPC, define the dataplane network interface of the
firewall as the default gateway.
1. Using a secure connection (https) from your web browser, log in using the EIP address and password
you assigned during initial configuration (https://<Elastic_IP address>). You will see a certificate
warning; that is okay. Continue to the web page.
2. Select Network > Interfaces > Ethernet.
3. Click the link for ethernet 1/1 and configure as follows:
• Interface Type: Layer3
• On the Config tab, assign the interface to the default router.
• On the Config tab, expand the Security Zone drop-down and select New Zone. Define a new
zone and then click OK.
• On the IPv4 tab, select DHCP Client.
If using DHCP, select DHCP Client; the private IP address that you assigned to the ENI in the
AWS management console will be automatically acquired.
• On the Advanced tab, create a management profile to allow health checks to be received by the
firewall.
4. Click Commit. Verify that the link state for the interface is up.
You can configure interfaces and associate a VPC with firewall interfaces using the following methods:
• Include the interface configuration in your bootstrap.xml file and the association commands as part
of the init-cfg.txt file or AWS user-data.
• After deploying the firewall, manually configure your interfaces and use the firewall CLI to associate
your VPCs with interfaces.
You can associate multiple VPC endpoints to a single interface on the VM-Series firewall. However,
you must associate each VPC endpoint individually. For example, to associate VPC endpoint 1 and VPC
endpoint 2 with subinterface ethernet1/1.2, you must execute the association command separately for
each VPC endpoint.
When associating a VPC endpoint using the bootstrapping init-cfg.txt file or AWS user-date, you can
list multiple interfaces or subinterfaces together. All the commands must be on a single line in a comma-
separated list with no spaces as shown in the following example.
plugin-op-commands=aws-gwlb-inspect:enable,aws-gwlb-associate-
vpce:vpce-0913731043b5c0ebc@ethernet1/1.1,aws-gwlb-associate-
vpce:vpce-08207ccb4cb23a1de@ethernet1/1.1,aws-gwlb-associate-
vpce:vpce-07b66cca88821d6e1@ethernet1/1.2,aws-gwlb-associate-
vpce:vpce-0a9a583fdb928492b@ethernet1/1.3
If you are using subinterfaces to separate traffic, create a subinterface for each VPC and associate it to a
VPC.
3. Repeat this command for each interface and VPC endpoint association.
STEP 4 | If necessary, you can use the following command to disassociate a VPC endpoint from a
interface.
request plugins vm_series aws gwlb disassociate vpc-endpoint <vpce-id>
interface <subinterface>
STEP 1 | Before you begin, ensure that you create different subnets for the trust and untrust interfaces.
STEP 4 | Use overlay routing CLI command. This CLI command is not required if you included the
overlay routing op-command in the AWS user-data or the init-cfg.txt bootstrap file.
1. Log in to the firewall command line interface.
2. Execute the following command.
request plugins vm_series aws gwlb overlay-routing enable yes
STEP 6 | Ensure that you have disabled Automatically create default route pointing to default gateway
provided by server on the trust (ingress) interface.
1. Select Network > Interfaces > Ethernet.
2. Click on your trust interface and then the IPv4 tab.
3. Uncheck Automatically create default route pointing to default gateway provided by server.
4. Click OK.
5. Click OK.
This solution provides a security VPC template and an application template. The security VPC template
deploys the VM-Series firewall auto scaling group, a GWLB, a GWLBE, GWLBE subnet, security attachment
subnet, and a NAT gateway for each availability zone. Download the CloudFormation templates from the
Palo Alto Networks GitHub Repository.
The VM-Series Auto Scaling template for integration with an AWS GWLB includes the following building
blocks:
All VM-Series firewall interfaces must be assigned an IPv4 address when deployed in a
public cloud environment. IPv6 addresses are not supported.
Firewall Based on the number of availability zones (AZs) you choose, the firewall-new-
template vpc-v3.0.template deploys the following:
(Community
The template supports a maximum of four AZs.
supported
template)
• Subnets for Lambda management, transit gateway attachments, GWLB endpoints,
and NAT gateways, as well as trust subnets.
• Routes tables for each subnet
• Transit gateway attachments and route tables
• NAT and internet gateways
• An auto scaling group with one VM-Series firewall per AZ.
• One GWLB and a GWLB endpoint in each AZ.
The VPC CIDR for the firewall template should be larger than /23.
VM-Series Auto Scaling template for AWS does not deploy a transit
gateway or Panorama. You must deploy a transit gateway and
Panorama before launching firewall-new-vpc-v3.0.template.
Application Based on the number of availability zones (AZs) you choose, the panw-aws-app-
template v3.0.template deploys the following:
(Community
The template supports a maximum of four AZs.
supported
template)
• Subnets for Lambda, transit gateway attachments, GWLB endpoints, application
load balancers.
• Routes tables for each subnet, as well as an inbound route table associated with
the internet gateway to direct inbound traffic to the GWLB endpoint.
• One application load balancer
• One internet gateway
• An auto scaling group with one Ubuntu instance per AZ.
The VPC CIDR for the application template should be larger than /23.
Lambda AWS Lambda provides robust, event-driven automation without the need for
functions complex orchestration software. In addition to deploying the components described
in the rows above, the firewall-new-vpc-v3.0.template performs the
following functions:
• Adds or removes an interface (ENI) when a firewall is launched or terminated.
• Deletes all the associated resources when you delete a stack or terminate an
instance.
• Removes a firewall as a Panorama managed device when there is a scale-in event.
• Deactivates the license when a scale-in event results in a firewall termination.
• Monitors the transit gateway periodically for new attachments or detachments,
and updates the route tables accordingly in the security VPC.
Bootstrap files This solution requires the init-cfg.txt file and the bootstrap.xml file so that the VM-
Series firewall has the basic configuration for handling traffic.
The
bootstrap.xml • The init-cfg.txt file includes the mgmt-interface-swap operational command
file provided to enable the firewall to receive dataplane traffic on its primary interface
in the GitHub (eth0). This auto-scaling solution requires the swapping of the dataplane and
repository is management interfaces to enable the GWLB to forward web traffic to the auto-
provided for scaling tier of VM-Series firewalls.
testing and
evaluation
only. For a
If you need to delete these templates from AWS, always delete the application template first.
Attempting to delete the firewall template causes the deletion to fail.
STEP 1 | Ensure that you have the following before you begin.
• Obtain the auth code for a bundle that supports the number of firewalls that might be required for
your deployment. You must save this auth code in a text file named authcodes (no extensions), and
put the authcodes file in the /license folder of the bootstrap package.
• Download the files required to launch the VM-Series Gateway Load Balancer template from the
GitHub repository.
• Create a Transit Gateway. This transit gateway connects your security and application VPCs.
• Take note of the transit gateway ID; you will need it later when deploying the template.
• You must add a 0.0.0.0/0 route to the application attachment route table pointing to the security
attachment to protect east-west and outbound traffic.
• Ensure that Default route table association and Default route table propagation are disabled.
• The recommended VPC CIDR for the firewall and application templates should be larger than /23.
The target group of the gateway GWLB cannot use HTTP for health checks because the
VM-Series firewall does not allow access with an unsecured protocol. Instead use HTTPS
or TCP.
Don’t enable HTTP or Telnet because those protocols transmit in cleartext and
therefore aren’t secure.
6. Assign the Interface Management profile to an interface.
1. Select Network > Interfaces, select the type of interface (Ethernet, VLAN, Loopback, or Tunnel),
and select the interface.
2. Select Advanced > Other info and select the Interface Management Profile you just added.
3. Click OK.
7. Configure the DNS server and FQDN refresh time.
1. Select Device > Setup > Services and click the Edit icon.
2. Set the Primary DNS Server to 169.254.169.253. This is the AWS DNS address.
3. Set the Minimum FQDN Refresh Time to 60 seconds.
4. Click OK.
8. Commit your changes. This is required before proceeding to the next step.
9. Create an administrator.
1. Select Device > Administrators.
2. Enter pandemo as the Name.
3. Set the Password to demopassword and Confirm.
4. Click OK.
STEP 5 | Configure a template stack and add the template to the template stack.
1. Select Panorama > Templates and Add Stack.
2. Enter a unique Name to identify the stack.
3. Click Add and select the template.
4. Click OK to save the template stack.
STEP 7 | Add the license deactivation API key for the firewall to Panorama.
1. Log in to the Customer Support Portal.
2. Select Assets > Licensing API.
3. Copy the API key.
4. Use the CLI to install the API key copied in the previous step.
request license api-key set key <key>
STEP 8 | After deploying Panorama, you must open the following ports as described below on the
Panorama security group in AWS.
• Port 443 (HTTPS)—Upon initial deployment of the firewall template, leave HTTPS open so Lambda
can connect to Panorama.
When you secure port 443 you specify an IP address range from which you will allow connections,
as well as the EIPs assigned to the NAT gateways. The number of NAT gateways in your deployment
depends on the number of availability zones you configure. To find NAT gateway EIPs in AWS, go to
VPC > NAT Gateways. Note the EIP information for the security group for HTTPS.
Additionally, to allow Panorama to release the firewall license after stack deletion, you must allow
traffic from the CIDR range of the region where you deployed the firewall template. You can find the
CIDR for your region at this link.
• Port 3978—Port 3978 must be able to receive traffic from any IP address.
All VM-Series firewall interfaces must be assigned an IPv4 address when deployed in a
public cloud environment. IPv6 addresses are not supported.
type=dhcp-client
ip-address=
default-gateway=
netmask=
ipv6-address=
ipv6-default-gateway=
hostname=
vm-auth-key=
panorama-server=
panorama-server-2=
tplname=
dgname=
dhcp-send-hostname=yes
dhcp-send-client-id=yes
dhcp-accept-server-hostname=yesdhcp-accept-server-domain=yes
plugin-op-commands=aws-gwlb-inspect:enable
STEP 2 | Add the license auth code in the /license folder of the bootstrap package.
1. Use a text editor to create a new text file named authcodes (no extension).
2. Add the authcode for your BYOL licenses to this file, and save. The authcode must represent a
bundle, and it must support the number of firewalls that might be required for your deployment. If
you use individual authcodes instead of a bundle, the firewall only retrieves the license key for the
first authcode in the file.
STEP 3 | Upload Lambda code for the firewall template (panw-aws.zip) and the Application template
(app.zip) to an S3 bucket. You can use the same S3 bucket that you use for bootstrapping.
If the Application stack is managed by a different account than the firewall, use the Application account
to create another s3 bucket in the same AWS region as the firewall template and copy app.zip to that
s3 bucket.
STEP 5 | Enter a descriptive Name for your stack. The name must be 28 characters or less.
STEP 8 | Specify the keys for enabling API access to the firewall and Panorama.
1. Enter the key that the firewall must use to authenticate API calls. The default key is based on the
sample file and you should only use it for testing and evaluation. For a production deployment, you
must create a separate PAN-OS login just for the API call and generate an associated key.
2. Enter the API Key to allow AWS Lambda to make API calls to Panorama. For a production
deployment, you should create a separate login just for the API call and generate an associated key.
STEP 9 | Add your AWS account number(s). You must provide the account number used to deploy any
VPC that is connected to your GWLB. Add these values as a comma-separated list. You can
add additional account numbers after deploying the template.
To locate your account number, click your AWS username in the top right of the AWS console and select
My Security Credentials.
STEP 10 | Enter the transit gateway ID. The transit gateway ID is required to secure east-west and
outbound traffic. If you do not enter a transit gateway ID, the template assumes that only
inbound traffic should be inspected by firewalls integrated with the GWLB.
STEP 13 | Verify that the template has launched all required resources.
STEP 14 | Create rules allowing the NAT gateway IP address(es) on the security group where your
Panorama appliance is deployed. This is required to allow your firewalls to connect to
Panorama. You can find the list of NAT gateway IP addresses in the CFT security stack
output.
STEP 1 | Create an S3 bucket from which you will launch the application template.
• If this is a cross-account deployment, create a new bucket.
• If there is one account you can create a new bucket or use the S3 bucket you created earlier (you can
use one bucket for everything).
STEP 3 | Select the application launch template you want you launch.
1. In the AWS Management Console, select CloudFormation > CreateStack
2. Select Upload a template to Amazon S3, to choose the application template to deploy the resources
that the template launches within the same VPC as the firewalls, or to a different VPC. Click Open
and Next.
3. Specify the Stack name. The stack name allows you to uniquely identify all the resources that are
deployed using this template.
STEP 4 | Select the Availability Zones (AZ) that your setup will span in Select list of AZ.
STEP 7 | Select the EC2 instance type for the Ubuntu web server launched by this template.
STEP 9 | Enter the name of the service configuration (Service Name) for the GWLB endpoint in the
security VPC.
1. Select DynamoDB from the Services drop-down in the AWS console.
2. Select Tables and locate your security VPC table. The table name will be <stack name>-gwlb-
<region>. For example—cft-deployment-gwlb-us-east-1.
3. Click the Items tab and copy the Service Name.
4. Paste the Service Name into the application template configuration parameters.
STEP 10 | Enter the transit gateway ID. This is the same transit gateway you created before deploying
the firewall template.
STEP 12 | After the application has been deployed, you must add a route to the transit gateway route
table to enable east-west and outbound traffic inspection.
1. Log in to the AWS VPC console.
2. Select Transit Gateway Route Tables and choose your transit gateway route table. This route table is
created by the template and is called <app-stack-name>-<region>-PANWAppAttRt.
STEP 13 | (Optional) Create a bastion host (also called a jump box) to access the web server created by
the application template.
1. Create a public-facing subnet in your application VPC.
2. Add a route to this subnet from your IP address to the internet gateway.
3. Create a new EC2 instance in the public subnet with a public IP address.
4. Create a security group for this EC2 instance that allows SSH from your IP address.
Overview of HA on AWS
To ensure redundancy, you can deploy the VM-Series firewalls on AWS in an active/passive high availability
(HA) configuration. The active peer continuously synchronizes its configuration and session information
with the identically configured passive peer. A heartbeat connection between the two devices ensures
failover if the active device goes down. There are two options for deploying the VM-Series firewall on AWS
in HA—Secondary IP move and Dataplane Interface (ENI) move.
To ensure that all traffic to your internet-facing applications passes through the firewall, you have two
options. You can either configure the application’s public IP address on the Untrust interface (E1/2 in the
illustration above) of the VM-Series firewall, or you can configure AWS ingress routing. The AWS ingress
routing capability allows you to associate route tables with the AWS Internet gateway and add route rules
to redirect the application traffic through the VM-Series firewall. This redirection ensures that all internet
traffic passes through the firewall without having to reconfigure the application endpoints.
Secondary IP Move
When the active peer goes down, the passive peer detects this failure and becomes active. Additionally,
it triggers API calls to the AWS infrastructure to move the configured secondary IP addresses from the
dataplane interfaces of the failed peer to itself. Additionally, AWS updates the route tables to ensure that
traffic is directed to the active firewall instance. These two operations ensure that inbound and outbound
traffic sessions are restored after failover. This option allows you to take advantage of DPDK to improve
the performance of your VM-Series firewall instances and provides better failover time than interface-move
HA, while supporting all the features provided by interface-move.
The following IAM actions, permissions, and resources are required to enable HA. To enable
AWS Cloudwatch monitoring, see Enable CloudWatch Monitoring on the VM-Series Firewall
for the required IAM action.
DescribeNetworkInterfaces
For fetching the ENI parameters in
order to attach an interface to the
instance.
The following screenshot shows the access management settings for the IAM role described above for
secondary-IP HA:
The minimum permissions you need for interface move HA are: {"Version":
"2012-10-17","Statement": [{"Sid": "VisualEditor0","Effect": "Allow","Action":
["ec2:AttachNetworkInterface","ec2:DetachNetworkInterface","ec2:DescribeInstances","ec2:D
"*"}]}
HA Links
The devices in an HA pair use HA links to synchronize data and maintain state information. on AWS, the
VM-Series firewall uses the following ports:
• Control Link—The HA1 link is used to exchange hellos, heartbeats, and HA state information, and
management plane sync for routing and User-ID information. This link is also used to synchronize
configuration changes on either the active or passive device with its peer.
The Management port is used for HA1. TCP port 28769 and 28260 for cleartext communication; port
28 for encrypted communication (SSH over TCP).
• Data Link—The HA2 link is used to synchronize sessions, forwarding tables, IPSec security associations
and ARP tables between devices in an HA pair. Data flow on the HA2 link is always unidirectional
(except for the HA2 keep-alive); it flows from the active device to the passive device.
Ethernet1/1 must be assigned as the HA2 link; this is required to deploy the VM-Series firewall on AWS
in HA. The HA data link can be configured to use either IP (protocol number 99) or UDP (port 29281) as
the transport.
The VM-Series firewall on AWS does not support backup links for HA1 or HA2.
All VM-Series firewall interfaces must be assigned an IPv4 address when deployed in a
public cloud environment. IPv6 addresses are not supported.
STEP 1 | Before you deploy the VM-Series firewalls for you HA pair, ensure the following:
• Refer to the VPC Planning Worksheet to ensure that your VPC is prepared for the VM-Series firewall.
• Secondary IP Move HA requires VM-Series plugin 2.0.1 or later.
• Deploy both HA peers in the same AWS availability zone.
Starting with VM-Series plugin 2.0.3, you can deploy the HA peers in different availability zones.
However, during an HA failover event, the route tables are updated but the secondary IP is not
moved. This type of deployment is not recommended.
• Create an IAM role and assign the role to the VM-Series firewalls when you deploy the instances.
• The active and passive firewalls must have at least four interfaces each—a management interface,
an HA2 interface, an untrust interface, and a trust interface. Additionally, the trust and untrust
interfaces on the active firewall must assigned a secondary IP address.
The management interface must be used as the HA1 interface.
• Verify that the network and security components are defined suitably.
STEP 3 | Configure the interfaces on the firewall. You must configure the HA2 data link and at least two
Layer 3 interfaces for your untrust and trust interfaces. Complete this workflow on the first HA
peer and then repeat the steps on the second HA peer.
1. Log in to the firewall web interface.
2. Select Network > Interfaces > Ethernet and click on your untrust interface. In this example, the HA2
interface is 1/1, the trust interface is ethernet 1/2, and the untrust interface is ethernet 1/3.
3. Click the link for ethernet 1/1 and configure as follows:
• Interface Type: HA
4. Click the link for ethernet 1/2 and configure as follows:
• Interface Type: Layer3
• On the Config tab, assign the interface to the default router.
• On the Config tab, expand the Security Zone drop-down and select New Zone. Define a new
zone, for example trust-zone, and then click OK.
• On the IPv4 tab, select DHCP Client.
• Check Enable.
• On the untrust interface, check Automatically create default route pointing to default gateway
provided by server. This option tells the firewall to create a static route to a default gateway.
• Repeat these steps for ethernet 1/3.
5. Repeat the above steps on the passive peer.
5. Edit the Election Settings to specify a particular firewall to be the active peer. Enter a lower
numerical Device Priority value on the active firewall. If both firewalls have the same Device Priority
value, the firewall with the lowest MAC value on the HA1 control becomes the active firewall.
6. Click OK.
7. Commit your changes.
8. Repeat the above steps on the passive peer.
2. (Optional) Select Encryption Enabled, for secure HA communication between the peers. To enable
encryption, you must export the HA key from a device and import it into the peer device.
1. Select Device > Certificate Management > Certificates.
2. Select Export HA key. Save the HA key to a network location that the peer device can access.
3. On the peer device, navigate to Device > Certificate Management > Certificates, and select
Import HA key to browse to the location that you saved the key and import it in to the peer
device.
7. (Optional) Modify the Threshold for HA2 Keep-alive packets. By default, HA2 Keep-alive is enabled
for monitoring the HA2 data link between the peers. If a failure occurs and this threshold (default
is 10000 ms) is exceeded, the defined action will occur. A critical system log message is generated
when an HA2 keep-alive failure occurs.
You can configure the HA2 keep-alive option on both devices, or just one device in the
HA pair. If you enable this option on one device, only that device will send the keep-
alive messages.
STEP 7 | After your finish configuring HA on both firewalls, verify that the firewalls are paired in active/
passive HA.
1. Access the Dashboard on both firewalls and view the High Availability widget.
2. On the active HA peer, click Sync to peer.
3. Confirm that the firewalls are paired and synced.
All VM-Series firewall interfaces must be assigned an IPv4 address when deployed in a
public cloud environment. IPv6 addresses are not supported.
Do not attach additional dataplane interfaces to the passive firewall in the HA pair.
On failover, the dataplane interfaces from the previously active firewall are moved —
detached and then attached—to the now active (previously passive) firewall.
• The HA peers must be deployed in the same AWS availability zone.
STEP 3 | (VM-Series plugin 2.0.1 or later) Disable DPDK on the active and passive firewalls. DPDK is
enabled by default and interface-move HA mode does not support DPDK, so you must disable
it; enabling Packet MMAP.
1. Log in to the passive firewall CLI.
2. Disable DPDK using the following command. Executing this command restarts the firewall.
admin@PA-VM> set system setting dpdk-pkt-io off
STEP 5 | Configure ethernet 1/1 as an HA interface. This interface must be used for HA2
communication.
1. Select Network > Interfaces.
2. Confirm that the link state is up on ethernet1/1.
3. Click the link for ethernet1/1 and set the Interface Type to HA.
STEP 6 | Set up the Control Link (HA1) to use the management port.
1. Select Device > High Availability > General, and edit the Control Link (HA1) section.
2. (Optional) Select Encryption Enabled, for secure HA communication between the peers. To enable
encryption, you must export the HA key from a device and import it into the peer device.
1. Select Device > Certificate Management > Certificates.
2. Select Export HA key. Save the HA key to a network location that the peer device can access.
3. On the peer device, navigate to Device > Certificate Management > Certificates, and select
Import HA key to browse to the location that you saved the key and import it in to the peer
device.
You can configure the HA2 keep-alive option on both devices, or just one device in the
HA pair. If you enable this option on one device, only that device will send the keep-
alive messages.
If both firewalls have the same device priority value, the firewall with the lowest MAC
address on the HA1 control link will become the active device.
3. Select Preemptive.
You must enable preemptive on both the active and the passive device.
4. Modify the failover timers. By default, the HA timer profile is set to the Recommended profile and is
suited for most HA deployments.
STEP 12 | After you finish configuring both devices, verify that the devices are paired in active/passive
HA.
STEP 1 | Upgrade the VM-Series Plugin on the passive HA peer and then the active peer.
STEP 2 | Create secondary IP address for all data interfaces on the active peer.
1. Log in to the AWS EC2 console.
2. Select Network Interface and then choose then select your network interface.
3. Select Actions > Manage IP Addresses > IPv4 Addresses > Assign new IP.
4. Leave the field blank to allow AWS to assign an IP address dynamically or enter an IP address within
the subnet range for the VM-Series firewall.
5. Click Yes and Update.
STEP 3 | Associate a secondary Elastic (public) IP address with the untrust interface of the active peer.
1. Log in to the AWS EC2 console.
2. Select Elastic IPs and then choose then select the Elastic IP address to associate.
3. Select Actions > Associate Elastic IP.
STEP 4 | Create a route table pointing the subnet containing the trust interface.
1. Select Route Tables > Create route table.
2. (Optional) Enter a descriptive Name tag for your route table.
3. Select your VPC.
4. Click Create.
5. Select Subnet Associations > Edit subnet associations.
6. Select the Associate checkbox for the subnet containing the trust interface.
7. Click Save.
STEP 5 | Update the IAM roles with additional actions and permissions required to migrate to secondary
IP move HA.
Wild card (*) In the ARN field use the * as a wild card.
STEP 6 | Create new interfaces (ENIs) on the passive firewall in the same subnet as the active firewall
data interfaces.
STEP 7 | Attach the new ENIs to the passive firewall instance. You must attach these ENIs to the
passive firewall in the correct order because the secondary IP HA method is based on the
network interface index assigned by AWS. For example, if eth1/2 on the active firewall is part
of subnet A and eth1/3 is part of subnet B, then you must attach the interface that is part
of subnet A and the interface that is part of subnet B. In this example, AWS has assigned an
index value of 2 to eth1/2 and a value of 3 to eth1/3. This indexing must be maintained for the
failover to occur successfully.
1. To attach the ENIs created above, select the untrust interface your created and click Attach.
2. Select the Instance ID of the of the passive firewall and click Attach.
3. Repeat these steps for the trust interface.
STEP 8 | Log into the passive and set the interfaces to get their IP addresses through DHCP.
1. Log in to the passive VM-Series firewall web interface.
2. Select Network > Interfaces.
3. Click on the first data interface.
4. Select IPv4.
5. Select DHCP Client.
6. On the untrust interface only, select Automatically create default route pointing to default gateway
provided by server.
7. Click OK.
8. Repeat this process for each data interface.
STEP 9 | If you have configure any NAT policies on the VM-Series firewall that reference the private
IP addresses of the data interfaces, those policies must be updated to reference the newly
assigned secondary IP addresses instead.
STEP 11 | After your finish configuring HA on both firewalls, verify that the firewalls are paired in
active/passive HA.
1. Access the Dashboard on both firewalls and view the High Availability widget.
2. On the active HA peer, click Sync to peer.
3. Confirm that the firewalls are paired and synced.
• On the passive firewall: the state of the local firewall should display Passive and the Running
Config should show as Synchronized.
• On the active firewall: the state of the local firewall should display Active and the Running Config
should show as Synchronized.
4. From the firewall command line interface, execute the following commands:
• To verify failover readiness:
show plugins vm_series aws ha state
• To show secondary IP mapping :
show plugins vm_series aws ha ips
STEP 1 | Disable DPDK support on the passive HA peer. Interface-move HA mode does not support
DPDK, so you must disable it; enabling Packet MMAP.
1. Log in to the passive firewall CLI.
2. Disable DPDK using the following command. Executing this command restarts the firewall.
admin@PA-VM> set system setting dpdk-pkt-io off
STEP 3 | Change the HA mode on the active peer from secondary-IP mode to interface-move mode.
1. Access the VM-Series firewall CLI on the active peer.
2. Execute the following command.
request plugins vm_series aws ha failover-mode interface-move
3. Commit your changes.
4. Comfirm your HA mode by executing the following command.
show plugins vm_series aws ha failover-mode
5. Repeat this command on the passive peer.
STEP 4 | Delete the data interfaces from the passive firewall instance.
1. Log in to the AWS EC2 console.
2. Select Network Interfaces.
3. Select a data interface on the passive firewall instance and click Delete.
4. In the Delete Network Interface window, click Yes, Delete.
5. Repeat this process for each data interface on the passive firewall instance.
The following image depicts the logical flow of traffic to/from the web server to the internet. Traffic to/
from the web server is sent to the data interface of the VM-Series firewall that is attached to the private
subnet. The firewall applies policy and processes incoming/outgoing traffic from/to the internet gateway of
the VPC. The image also shows the security groups to which the data interfaces are attached.
Although a main route table is automatically created on the VPC, we recommend creating
new route tables instead of modifying the default route table.
To direct outbound traffic from each subnet, you will add routes to the route table associated with each
subnet, later in this workflow.
1. Select Route Tables > Create Route Table.
2. Add a Name, for example CloudDC-public-subnet-RT, select the VPC you created in Step 1, and click
Yes, Create.
3. Select the route table, click Subnet Associations and select the public subnet.
STEP 4 | Create Security Groups to restrict inbound/outbound internet access to the EC2 instances in
the VPC.
By default, AWS disallows communication between interfaces that do not belong to the same security
group.
Select Security Groups and click the Create Security Group button. In this example, we create three
security groups with the following rules for inbound access:
Only the primary network interface that will serve as the management interface will be
attached and configured for the firewall during the initial launch. The network interfaces
required for handling data traffic will be added in Step 6.
STEP 6 | Create and attach virtual network interface(s), referred to as Elastic Network Interfaces (ENIs),
to the VM-Series firewall. These ENIs are used for handling data traffic to/from the firewall.
1. On the EC2 Dashboard, select Network Interfaces, and click Create Network Interface.
2. Enter a descriptive name for the interface.
3. Select the subnet. Use the subnet ID to make sure that you have selected the correct subnet. You
can only attach an ENI to an instance in the same subnet.
4. Enter the Private IP address that you want to assign to the interface or select Auto-assign to
automatically assign an IP address within the available IP addresses in the selected subnet.
5. Select the Security group to control access to the network interface.
6. Click Yes, Create.
In this example, we create two interfaces with the following configuration:
STEP 7 | Create an Elastic IP address and attach it to the firewall dataplane network interface that
requires direct internet access.
In this example, VM-Series_Untrust is assigned an EIP. The EIP associated with the interface is the
publicly accessible IP address for the web server in the private subnet.
1. Select Elastic IPs and click Allocate New Address.
2. Select EC2-VPC and click Yes, Allocate.
3. Select the newly allocated EIP and click Associate Address.
4. Select the Network Interface and the Private IP address associated with the interface and click Yes,
Associate.
STEP 8 | Disable Source/Destination check on each network interface attached to the VM-Series
firewall. Disabling this attribute allows the interface to handle network traffic that is not
destined to its IP address.
1. Select the network interface in the Network Interfaces tab.
2. In the Action drop-down, select Change Source/Dest. Check.
3. Click Disabled and Save your changes.
4. Repeat steps 1-3 for additional network interfaces, firewall-1/2 in this example.
STEP 10 | In the route table associated with the private subnet, add a default route to send traffic to the
VM-Series firewall.
Adding this route enables the forwarding of traffic from the EC2 instances in this private subnet to the
VM-Series firewall.
1. From the VPC Dashboard, select Route Tables and find the route table associated with the private
subnet.
2. Select the route table, select Routes and click Edit.
3. Add a route to forward packets from this subnet to the VM-Series firewall network interface that
resides on the same subnet. In this example, 0.0.0.0/0 indicates that all traffic from/to this subnet will
use eni-abf355f2 (ethernet 1/2, which is CloudDC-VM-Series-Trust) on the VM-Series firewall.
For each web or database server deployed on an EC2 instance in the private subnet,
you must define a default route to the IP address of the VM-Series firewall so that the
firewall is the default gateway for the server.
An SSH tool such as PuTTY is required to access the CLI on the firewall and change the
default administrative password. You cannot access the web interface until you SSH and
change the default password.
1. Use the public IP address you configured on the firewall, to SSH into the Command Line Interface
(CLI) of the VM-Series firewall.
You will need the private key that you used or created in Launch the VM-Series Firewall on AWS,
steps 3-12 to access the CLI.
STEP 13 | Activate the licenses on the VM-Series firewall. This step is only required for the BYOL
license; the usage-based licenses are automatically activated.
See Activate the License.
STEP 14 | On the VM-Series firewall, configure the dataplane network interfaces on the firewall as
Layer 3 interfaces.
1. Select Network > Interfaces > Ethernet.
2. Click the link for ethernet 1/1 and configure as follows:
• Interface Type: Layer3
• Select the Config tab, assign the interface to the default router.
• On the Config tab, expand the Security Zone drop-down and select New Zone. Define a new
zone, for example untrust, and then click OK.
• Select IPv4, select DHCP Client; the private IP address that you assigned to the network interface
in the AWS management console will be acquired automatically.
• On the Advanced > Other Info tab, expand the Management Profile drop-down, and select New
Management Profile.
• Enter a Name for the profile, such as allow_ping, and select Ping from the Permitted Services list,
then click OK.
• To save the interface configuration, click OK.
3. Click the link for ethernet 1/2 and configure as follows:
• Interface Type: Layer3
• Select the Config tab, assign the interface to the default router.
• On the Config tab, expand the Security Zone drop-down and select New Zone. Define a new
zone, for example trust, and then click OK.
• Select IPv4, select DHCP Client.
• On the IPv4 tab, clear the Automatically create default route to default gateway provided by
server check box. For an interface that is attached to the private subnet in the VPC, disabling this
option ensures that traffic handled by this interface does not flow directly to the IGW on the VPC.
• On the Advanced > Other Info, expand the Management Profile drop-down, and select the
allow_ping profile you created earlier.
• Click OK to save the interface configuration.
4.
Click Commit to save the changes. Verify that the Link state for the interface is up . If the link
state is not up, reboot the firewall.
3. Create a Source NAT rule to allow outbound traffic from the web server to the internet.
1. Click Add, and enter a name for the rule. For example, NAT2External.
2. In the Original Packet tab, make the following selections:
• Source Zone: trust (where the traffic originates)
• Destination Zone: untrust (the zone for the firewall dataplane interface with which the EIP for
the web server is associated.)
• Source Address: Any
• Destination Address: Any
3. In the Translated Packet tab, make the following selections in the Source Address Translation
section:
• Translation Type: Dynamic IP and Port
• Address Type: Translated Address
• Translated Address: 10.0.0.10 (the firewall dataplane interface in the untrust zone.)
4. Click OK.
Instead of entering a static IP address for the web server, use a dynamic address group.
Dynamic address groups allow you to create policy that automatically adapts to changes
5. Edit the interzone-default rule to log all traffic that is denied. This predefined interzone rule is
evaluated when no other rule is explicitly defined to match traffic across different zones.
1. Select the interzone-default rule and click Override.
2. In the Actions tab, select Log at session end.
3. Click OK.
• Traffic outbound from the web server (EC2 instance in the AWS VPC):
Instead of using VM Information Source on the firewall, you can opt to use Panorama as
the central point for communicating with your VPCs. Using the AWS plugin on Panorama,
you can retrieve the IP address-to-tag mapping and register the information on the managed
firewalls for which you configure notification. For more details on this option, see VM
Monitoring with the AWS Plugin on Panorama.
This workflow in the following section assumes that you have created the AWS VPC and deployed the VM-
Series firewall and some applications on EC2 instances. For instructions on setting up the VPC for the VM-
Series, see Use Case: Secure the EC2 Instances in the AWS Cloud.
5. Click OK.
6. Click Commit.
10.Click Commit.
STEP 5 | Verify that members of the dynamic address group are populated on the firewall.
Policy will be enforced for all IP addresses that belong to this address group, and are displayed here.
1. Select Policies > Security, and select the rule.
2. Select the drop-down arrow next to the address group link, and select Inspect. You can also verify
that the match criteria is accurate.
• Apply the templates and the device groups to the VM-Series firewalls on AWS, and verify that
the firewalls are configured properly.
If you do not have Panorama or you have a simpler deployment and need to monitor 10 VPCs or fewer,
you can use the VM Information Source on the firewall (hardware or VM-Series firewall) to monitor your
AWS workloads. You can use the metadata, which the firewall retrieves, in Dynamic Address Groups and
reference them in Security policies to secure your VM workloads as they spin up or down and IP addresses
change frequently. See Use Case: Use Dynamic Address Groups to Secure New EC2 Instances within the
VPC.
The AWS plugin version 2.0 is for monitoring EC2 instances for up to 1000 VPCs on the
AWS public cloud, AWS GovCloud, and AWS China. However, because Panorama cannot
be deployed on AWS China, the IAM role does not support instance profiles on AWS China;
you must provide the AWS credentials.
Duplicate IP addresses are written to the plugin_aws_ret.log file that you can access from
the CLI on Panorama.
Review the requirements for Panorama and the managed firewalls:
• Minimum system requirements—Panorama virtual appliance or hardware-based Panorama appliance.
Licenses Active support license and a device management license on Panorama for
managing the firewalls.
Next-generation firewalls must also have a valid support license.
• You must add the firewalls as managed devices on Panorama and create Device Groups so that you
can configure Panorama to notify these groups with the VM information it retrieves. Device groups
can include VM-Series firewalls or virtual systems on the hardware firewalls.
• If your Panorama appliances are in a high availability configuration, you must manually install the
same version of the AWS plugin on both Panorama peers. Additionally, if you are using instance
profiles, you must attach the same instance profile to both Panorama peers.
You configure the AWS plugin on the active Panorama peer only. On commit, the
configuration is synced to the passive Panorama peer. Only the active Panorama peer
polls the AWS accounts you have configured for VM Monitoring.
• Set up the credentials/permissions that Panorama requires to digitally sign API calls to the AWS
services.
You can choose whether you want to provide the long-term credentials—Access Key ID and Secret
Access Key—that enable access to the resources within each AWS account, or set up an Assume
Role on AWS to allow access to defined AWS resources within the same AWS account or cross-
accounts. With an Assume Role, you must set up a trust relationship and define the permissions
while creating the role itself. This is specifically useful in a cross-account deployment where the
querying account does not have permissions to see or handle data from the queried account. For the
Panorama plugin to successfully authenticate to the VPC and retrieve the tags, you must configure
the Assume Role to use the AWS Security Token Service (STS) API to any AWS service. And a user
from the querying account must have STS permissions to query the Assume Role and obtain the
temporary security credentials to access resources. If your Panorama is deployed on AWS, you can
opt to use an instance profile instead of providing the AWS credentials for the IAM role. The instance
profile includes the role information and associated credentials that Panorama needs to digitally sign
API calls to the AWS services. See IAM Roles and Permissions for Panorama for more details.
Roles and The AWS credentials associated with the AWS account that has the VPC/EC2 instances
Permissions you want to monitor.
Required
The JSON format for the minimum permissions associated with the IAM role with long-
term credentials is as follows:
Inputs on Enter the Access Key ID and Secret Access Key for the user in Panorama > Plugins >
Panorama AWS > Setup > IAM Role.
Roles and While you can use this option to monitor VPCs within the same or cross account, this
Permissions option is recommended to enable cross account access by assuming a role that allows
Required you to access resources to which you may normally have access.
To assume a role from a different account, your AWS account must be trusted by that
role and defined as a trusted entity in its trust policy. In addition, a user who wants to
access a role in a different account must have a policy with secure token service (STS)
access that specifies the role ARN.
On Account 1 that you want to monitor:
• Create an IAM role with required permissions. For VM Monitoring you need
AmazonEC2ReadOnlyAccess.
• Copy the Role ARN.
• Create a user and add the Account ID for Account 2 as a trusted entity. This allows
Account 2 the permissions to use this role to access the resources within your
Account 1.
{ "Version": "2012-10-17",
"Statement":
{
"Effect": “Allow",
"Action": "sts:AssumeRole",
"Resource":"arn:aws:iam::012347211234:role/
PAN-OS-assume-role"
}
}
Inputs on • Enter the Access Key ID and Secret Access Key for the user on Account 2 on
Panorama Panorama > Plugins > AWS > Setup > IAM Role.
• Enter the Role ARN for the AWS Account 1 which you want to monitor in the
Panorama > Plugins > AWS > Monitoring Definitions.
When Panorama and the resources you want to monitor are all in a single AWS account.
Create an IAM role with AmazonEC2ReadOnlyAccess.
Inputs on Select Instance Profile as the option in Panorama > Plugins > AWS > Setup > IAM Role.
Panorama
Roles and Use instance profile with Assume role when Panorama and the resources you want to
Permissions monitor are deployed across AWS accounts.
Required
For Panorama HA, make sure to attach the same instance profile to both Panorama
peers.
On Account 1, where your EC2 instances are deployed:
• Create an IAM role.
• To this role, add the AWS Account ID (Account 2) where your Panorama is deployed
as a trusted entity.
• Attach the JSON policies as detailed above for VM Monitoring.
• Copy the Role ARN.This role is required for Panorama to retrieve metadata on your
EC2 instances or EKS clusters.
On Account 2, where your Panorama is deployed:
Inputs on • Select Instance Profile as the option in Panorama > Plugins > AWS > Setup > IAM
Panorama Role
• Enter the Role ARN for the AWS account which you want to monitor in the
Panorama > Plugins > AWS > Monitoring Definitions.
For example Account 1 in this example.
After you install the AWS plugin v2.0 you cannot downgrade to v1.0.
If you have a Panorama HA configuration, repeat the installation/upgrade process on each Panorama peer.
STEP 1 | Log in to the Panorama Web Interface, select Panorama > Plugins and click Check Now to get
the AWS plugin version that supports VM monitoring.
2. Enter a Name to identify the group of firewalls to which Panorama pushes the VM information it
retrieves.
3. Select the Device Groups, which are a group of firewalls or virtual systems, to which Panorama
will push the VM information (IP address-to-tag mapping) it retrieves from your AWS VPCs. The
firewalls use the update to determine the most current list of members that constitute dynamic
address groups referenced in policy. If you are using the Panorama plugin for Azure and AWS, you
can target the same firewall or virtual system with tags from both environments.
Verify that monitoring is enabled on the plugin. This setting must be enabled for Panorama to
communicate with the AWS public cloud for VM Monitoring.
The checkbox for Enable Monitoring is on Panorama > Plugins > AWS > Setup > General.
STEP 3 | Create a Monitoring Definition for each VPC you want to monitor.
When you add a new Monitoring definition, it is enabled by default.
• Select Panorama > Plugins > AWS > Monitoring Definition, to Add a new definition.
• Enter a Name and optionally a Description to identify the AWS VPC for which you use this definition.
• Enter the Endpoint URI. The syntax is ec2.<your_region>.amazonaws.com;
For AWS China, it is ec2.<your region>.amazonaws.com.cn.
• (Optional) Enter the Role ARN, if you have set up role chaining and IAM roles with temporary
credentials that have permissions to use the AWS STS API to access AWS resources with the same
account or cross-account. The Role ARN must belong to the VPC you want to monitor.
• Select the IAM Role, Add the VPC ID from the VPC Dashboard on the AWS management console,
and Notify Group.
Click Validate to verify that Panorama can authenticate using the IAM role and keys and
to communicate with the AWS VPCs you’ve entered above.
STEP 5 | Verify that you can view the VM information on Panorama, and define the match criteria for
Dynamic Address Groups.
On HA failover, the newly active Panorama attempts to reconnect to the AWS cloud
and retrieve tags for all monitoring definitions. If Panorama is unable to reconnect with
If this happens, you must log into Panorama and verify the monitoring definitions to fix
invalid credentials or remove invalid accounts. Although Panorama is disconnected
from the AWS cloud, all tags that were retrieved for the monitoring definitions before
the failover, are retained and the firewalls can continue to enforce policy on that list of
IP addresses. Panorama removes all tags associated with the accounts only when you
delete a monitoring definition. As a best practice, to monitor this issue, you can configure
action-oriented log forwarding to an HTTPS destination from Panorama so that you can
take action immediately.
STEP 6 | Know where to find the logs related to the AWS plugin on Panorama for troubleshooting.
• Use the CLI command less plugins-log to view a list of all available logs
plugin_aws_ret.log displays logs related to IP address and tag retrieval.
plugin_aws_proc.log displays logs related to processing of the registered IP address and tags.
plugin_aws.log displays logs related to the AWS plugin configuration and daemons.
Use show plugins aws vm-mon-status for the status of the Monitoring Definitions.
The following table compares some high-level features of each template version.
Panorama running PAN-OS (Optional) If you choose to use Panorama, (Required) Deploy the
9.0.1 or a later release in you must configure VPC peering between Version 2.1 templates.
Panorama mode. the VM-Series firewall VPC and the
application VPCs. Peered traffic traverses On
Panorama the public internet. Panorama,
in a high you must
availability manually
(HA) install the
configuration VM-Series
is not plugin to
supported. enable
VM-Series
firewalls
to publish
PAN-OS
metrics
Palo Alto Networks S3 bucket Use your own S3 bucket or use the Use your own S3 bucket
sample sample in panw-aws-autoscale-v20-us- for the deployment.
west-2.
What Components Does the VM-Series Auto Scaling Template for AWS
(v2.0) Leverage?
The VM-Series Auto Scaling template for AWS includes the following building blocks:
Firewall template The firewall-v2.0.template deploys a new VPC with subnets, route
tables, an AWS NAT gateway, two Availability Zones (AZs), and security
(Palo Alto Networks
groups required for routing traffic across these AZs. This version 2.0 template
officially supported
also deploys an external ALB, and an ASG with a VM-Series firewall in each
template)
AZ.
Due to the many variations in a production environment that includes but
is not limited to a specific number components, such as subnets, availability
zones, route tables, and security groups. You must deploy the firewall-
v2.0.template in a new VPC.
This solution includes an AWS NAT gateway that the firewalls use to initiate
outbound requests for retrieving updates, connecting to Panorama, and
publishing metrics to AWS CloudWatch.
Application template The application template deploys an NLB and an ASG with a web server
in each AZ. Because the NLB has a unique IP address for each AZ and the
(Community supported
NAT policy rule on the firewalls must reference a single IP address, there
template)
is one ASG for each of the two AZs. All firewalls in an ASG use an identical
configuration.
Version 2.0 of the auto scaling solution includes two application templates:
• The panw_aws_nlb-v2.0.template allows you to deploy the
application template resources within the same VPC as the one in which
you deployed the firewall template (same AWS account).
• The panw_aws_nlb_vpcv-2.0.template allows you to deploy the
application template resources in a separate VPC using the same AWS
account or multiple AWS accounts.
Lambda functions AWS Lambda provides robust, event-driven automation without the need
for complex orchestration software. In the firewall-v2.0.template,
AWS Lambda monitors a Simple Queue Service (SQS) to learn about NLBs
that publish to the queue. When the Lambda function detects a new NLB, it
creates a new NAT policy rule and applies it to the VM-Series firewalls within
the ASG. The firewalls have a NAT policy rule for each application and the
firewalls use the NAT policy rule (that maps the port to NLB IP address) to
forward traffic to the NLB in front of the application web servers.
Bootstrap files This solution requires the init-cfg.txt file and the bootstrap.xml file so that the
VM-Series firewall has the basic configuration for handling traffic.
The bootstrap.xml
file provided in the • The init-cfg.txt file includes the mgmt-interface-swap operational
GitHub repository is command to enable the firewall to receive dataplane traffic on its primary
provided for testing and interface (eth0). This auto-scaling solution requires the swapping of the
evaluation only. For a dataplane and management interfaces to enable the ALB to forward web
production deployment, traffic to the auto-scaling tier of VM-Series firewalls. For details, see
you must modify the Management Interface Mapping for Use with Amazon ELB.
sample credentials in • The bootstrap.xml file enables basic connectivity for the firewall
the bootstrap.xml prior network interfaces and allows the firewall to connect to the AWS
to launch. CloudWatch namespace that matches the stack name you enter when you
launch the template.
To deploy the solution, see Launch the VM-Series Auto Scaling Template for AWS (v2.0).
How Does the VM-Series Auto Scaling Template for AWS (v2.0 and v2.1)
Enable Dynamic Scaling?
VM-Series firewall scale in and scale out using VM-Series firewalls that are deployed using auto scaling
templates based on custom PAN-OS metrics. The VM-Series firewalls natively publish these metrics to
the Amazon CloudWatch console and, based on the metrics you choose for the scaling parameters, you
can define CloudWatch alarms and policies to dynamically deploy or terminate instances for managing the
application traffic in your AWS deployment.
The firewalls publish metrics to AWS CloudWatch every five minutes (by default). When a monitored metric
reaches the configured threshold for the defined time interval, CloudWatch triggers an alarm and initiates
an auto-scaling event.
When the auto-scaling event triggers the deployment of a new firewall, the new instance bootstraps at
launch and an AWS Lambda function configures the firewall with NAT policy rules. A NAT policy rule is
created for each application and the rule references the IP addresses for each network load balancer in
your deployment. When the application load balancer receives a request, it forwards the request to the
firewall on the assigned TCP port. The firewall then inspects the traffic and forwards it to the corresponding
network load balancer, which then forwards the request to a web server in its target group.
Plan the VM-Series Auto Scaling Template for AWS (v2.0 and v2.1)
The items in this checklist are actions and choices you must make to implement this solution.
Verify the The auto scaling template requires AWS Lambda and S3 Signature versions
requirements for 2 or 4, and can deploy VM-Series firewalls running supported PAN-OS
deploying the VM- versions. You need to look up the list of supported regions and the AMI IDs,
Series Auto Scaling to provide as an input in the firewall template.
template.
Assign the The user who deploys the VM-Series Auto Scaling template must either have
appropriate administrative privileges or have the permissions listed in the iam-policy.json
permissions for the to launch this solution successfully. Copy and paste the permissions from this
IAM user role. file in to a new IAM policy and then attach the policy to a new or existing IAM
role.
For a cross-account deployment, to access resources that are in a different
AWS accounts, the IAM role for the user who deploys the application
template must have full SQS access permissions and a trust relationship
that authorizes her to write to the SQS queue that belongs to the firewall
template.
Collect the details For a deployment where the firewall template and the application template
required for a are in different accounts, the account that hosts the firewall template
cross-account resources is the trusting account and the other AWS account(s) that hold
deployment. the application template resources are the trusted accounts. To launch the
application template in a cross-account deployment, you need the following
information:
• Cross-account Role Amazon Resource Name (ARN) of the account in
which you are deploying the application template.
• External ID, which you defined when creating the IAM role that grants full
SQS access to the trusting account.
• The 10-digit account number for every AWS account in which you plan
to launch the application template. Because the account that hosts the
firewall template resources serves as a trusting account, and it owns the
resources that the users of the application template need, you need to list
the account number for each trusted account that can access the firewall
resources.
Create a Support You can opt for the BYOL or PAYG licenses.
Account on the
• For BYOL, you must register an auth code to your Palo Alto Networks
Palo Alto Networks
support account prior to launching the VM-Series Auto Scaling template
Support portal, if
and add the auth-code to the /license folder with filename as
you don’t already
authcodes in the bootstrap package. See Launch the VM-Series Auto
have one.
Scaling Template for AWS (v2.0) or Launch the Firewall Template (v2.1) for
details.
• For PAYG, you must register the VM-Series firewalls to activate your
support entitlement.
(For PAYG only) In the AWS Marketplace, search for Palo Alto Networks, and select the
Review and accept bundle you plan to use. The VM-Series firewalls will fail to deploy if you have
the End User not accepted the EULA for the bundle you plan to use.
License Agreement
• Search for VM-Series Next Generation Firewall Bundle 2, for example.
(EULA).
• Click Continue, and select Manual Launch. Review the agreement and
click Accept Software Terms to accept the EULA.
Decide whether Palo Alto Networks provides public S3 buckets in all AWS regions included in
you plan to use the supported regions list. These S3 buckets include all the templates, AWS
the public S3 Lambda code, and the bootstrap files that you need.
buckets or your
private S3 bucket Palo Alto Networks recommends using the bootstrap files in
for AWS Lambda, the public S3 bucket only for evaluating this solution. For a
Python scripts, and production deployment, you must create a private S3 bucket
templates. for the bootstrap package.
Download the • Get the files for deploying the firewall template (application load balancer
templates, AWS and the VM-Series firewalls) from the GitHub repository.
Lambda code, and
the bootstrap files. Do not mix and match files across VM-Series Auto Scaling
template versions.
Customize the To ensure that your production environment is secure, you must customize
bootstrap.xml file the bootstrap.xml file with a unique administrative username and password
for your production for production deployments. The default username and password are
environment. pandemo/demopassword. You can also use this opportunity to create an
optimal firewall configuration with interfaces, zones, and security policy rules
that meet your application security needs.
Decide whether Panorama is an option for administrative ease and is the best practice for
you want to managing the firewalls. It is not required to manage the auto scaling tier of
use Panorama VM-Series firewalls deployed in this solution.
for centralized
If you want to use Panorama, you can either a Panorama virtual appliance on
logging, reporting,
AWS or use an M-Series appliance or a Panorama virtual appliance inside your
and firewall
corporate network.
management.
The Panorama must be in Panorama mode and not
Management Only mode.
Get started Launch the VM-Series Auto Scaling Template for AWS (v2.0).
CIDR Block for the VPC The IP address space that you want to use for 192.168.0.0/16
the VPC.
Management Subnet CIDR Comma-delimited list of CIDR blocks for the 192.168.0.0/24,
Block management subnet of the firewalls. 192.168.10.0/24
Untrust Subnet CIDR Block Comma-delimited list of CIDR blocks for the 192.168.1.0/24,
Untrust subnet. 192.168.11.0/24
Trust Subnet CIDR Block Comma-delimited list of CIDR blocks for the 192.168.2.0/24,
Trust subnet. 192.168.12.0/24
NAT Gateway Subnet CIDR Comma-delimited list of CIDR blocks for the 192.168.100.0/24,
Block AWS NAT Gateway. 192.168.101.0/24
Lambda Subnet CIDR Block Comma-delimited list of CIDR blocks for the 192.168.200.0/24,
Lambda functions. 192.168.201.0/24
Firewall Instance size AWS Instance Types and size that you M4.xlarge
want for the VM-Series firewalls in your
deployment.
Choose your Scaling The template publishes all the following Dataplane CPU
Parameter metrics to AWS CloudWatch: Utilization
• CPU—DataPlane CPU Utilization
You do not
need to modify • AS—Active Sessions
the template • SU—Session Utilization
for the scaling • SSPU—SSL Proxy Utilization
parameter. • GPU—GlobalProtect Gateway Utilization
You can • GPAT—GlobalProtect Gateway Utilization
set AWS ActiveTunnels
CloudWatch • DPB—Dataplane Packet Buffer Utilization
alarms on
the AWS
console for
one or more
custom PAN-
OS metrics
on which you
want to trigger
autoscaling.
Choose time in seconds for The period in seconds over which the 900
Scaling Period average statistic is applied. Must be a
multiple of 60.
All VM-Series firewall interfaces must be assigned an IPv4 address when deployed in a
public cloud environment. IPv6 addresses are not supported.
This firewall template includes an AWS NAT gateway that the firewalls use to initiate
outbound requests for retrieving updates, connecting to Panorama, and publishing metrics to
AWS CloudWatch. If you are not using Panorama to manage the firewalls, you must deploy
a jump server (a bastion host with an EIP address) that attaches to the Untrust subnet within
the VPC to enable SSH and/or HTTPS access to the VM-Series firewalls. This jump server
is required because the management interface on the VM-Series firewalls has a private IP
address only.
STEP 1 | Review the checklist for Plan the VM-Series Auto Scaling Template for AWS (v2.0).
Make sure that you have completed the following tasks:
• (For PAYG only) Reviewed and accepted the EULA for the PAYG bundle you plan to use.
• (For BYOL only) Obtained the auth code. You need to enter this auth code in the /license folder of
the bootstrap package.
• Downloaded the files required to launch the VM-Series Auto Scaling template from the GitHub
repository.
STEP 3 | (For BYOL only) Add the license auth code in the /license folder of the bootstrap package. For
more information see Prepare the Bootstrap Package.
1. Create a new .txt file with a text editor, such as Notepad.
2. Add the authcode for your BYOL licenses to this file,then save the file with authcodes (no file
extension) and upload it to the /license folder. The auth code must support the number of firewalls
that may be required for your deployment. You must use an auth code bundle instead of individual
auth codes so that the firewall can simultaneously fetch all license keys associated with a firewall. If
you use individual auth codes instead of a bundle, the firewall retrieves only the license key for the
first auth code included in the file.
STEP 5 | Prepare the Amazon Simple Storage (S3) buckets for launching the VM-Series Auto Scaling
template to a production environment.
Make sure to create the S3 buckets in the same region in which you plan to deploy the
template; the bootstrapping files hosted in the public S3 bucket are provided only to make
it easier for you to evaluate the template.
6. (For BYOL only) Click the link to open the license folder and upload the txt file with the auth code
required for licensing the VM-Series firewalls.
3. Upload the AWS Lambda code (panw-aws.zip file) to an S3 bucket. In this example, the AWS Lambda
code is in the same S3 bucket as the bootstrap package.
1. Click the bucket name.
2. Click Add Files to select the panw-aws.zip file, click Open.
3. Click Start Upload to add the zip file to the S3 bucket.
1. Look up the AMI ID for the VM-Series firewall and enter it. Make sure that the AMI ID matches the
AWS region, PAN-OS version and the BYOL or PAYG licensing option you opted to use.
2. Select the EC2 Key pair (from the drop-down) for launching the firewall. To log in to the firewalls,
you must provide the name of this key pair and the private key associated with it.
3. Restrict SSH access to the firewall’s management interface. Make sure to supply a CIDR block that
corresponds to your dedicated management IP addresses or network. Do not make the allowed
source network range larger than necessary and do not ever configure the allowed source as
0.0.0.0/0. Verify your IP address before configuring it on the template to make sure that you do not
lock yourself out.
4. Select Yes if you want to Enable Debug Log. Enabling the debug log generates more verbose logs
that help with troubleshooting issues with the deployment. These logs are generated using the stack
name and are saved in AWS CloudWatch.
By default, the template uses CPU utilization as the scaling parameter for the VM-Series firewalls.
Custom PAN-OS metrics are automatically published to the CloudWatch namespace that matches the
stack name you specified earlier.
You can use one S3 bucket for the bootstrap package and the zip file.
1. Enter the name of the S3 bucket that contains the bootstrap package.
If the bootstrap bucket is not set up properly or if you enter the bucket name incorrectly, the
bootstrap process fails and you cannot be able to log in to the firewall. Health checks for the load
balancers also fail.
2. Enter the name of the S3 bucket that contains the panw-aws.zip file.
STEP 10 | Specify the keys for enabling API access to the firewall and Panorama.
STEP 12 | (Optional) Apply tags to identify the resources associated with the VM-Series Auto Scaling
template.
Add a name-value pair to identify and categorize the resources in this stack.
Unless you customized the template, the VM-Series Auto Scaling template launches an ASG that
includes one VM-Series firewall in each AZ, behind the application load balancer.
STEP 14 | Verify that the template has launched all required resources.
1. On the AWS Management Console, select the stack name to view the Output for the list of
resources.
• It can take up to 20 minutes for the firewalls to boot up and be available to handle
traffic.
• When you finish testing or a production deployment, the only way to ensure
charges stop occurring is to completely delete the stack. Shutting down instances,
or changing the ASG maximum to 0 is not sufficient.
STEP 15 | Save the following information. You need to provide these values as inputs when deploying
the application template.
• IP addresses of the NAT Gateway in each AZ. You need this IP address to restrict HTTP access
to the web servers if you deploy the application in a different VPC. Specifying this IP address
ensures that the firewall secures access your applications in a different VPC, and that nobody
can bypass the firewall to directly access the web server. The sample application template
(panw_aws_nlb_vpc-2.0.template) displays a template validation error if you do not enter the NAT
Gateway IP addresses; you must enter the IP addresses as a comma-separated list.
• Network Load Balancer SQS URL. An AWS Lambda function in the firewall stack monitors this
queue so that it can learn about any network load balancers that you deploy, and create NAT policy
rules (one per application) on the VM-Series firewalls that enable the firewalls to send traffic to the
network load balancer IP address.
STEP 1 | (Required only for a cross-account deployment) Create the IAM role. Refer to AWS documentation.
This role grants access to a user who belongs to a different AWS account. This user requires permissions
to access the Simple Queue Service (SQS) resource in the firewall template. The firewall uses this queue
to learn about each network load balancer that you deploy so that it can create NAT policy to send
traffic to the web servers that are behind the network load balancer.
• For Account ID, type the AWS account ID of the account into which you are deploying the
application template. Specifying that account ID allows you to grant access to the resources in your
account that hosts the firewall template resources.
• Select Require external ID and enter a value that is a shared secret. Specifying an external ID allows
the user to assume the role only if the request includes the correct value.
• Choose Permissons to allow Amazon SQS Full Access.
STEP 2 | Use the Palo Alto Networks public S3 bucket or prepare your private (S3) bucket for launching
the application template.
1. Create a zip file with all the files in the GitHub repository, excluding the three .template files, named
nlb.zip in the screenshot below.
2. Upload the zip file to the S3 bucket you created earlier or to a new bucket.
STEP 4 | Configure the parameters for the VPC and network load balancer.
1. Select the two Availability Zones that your setup will span in Select list of AZ. If you are deploying
within the same VPC make sure to select the same Availability Zones that you selected for the
firewall template.
2. Enter a CIDR Block for the VPC. The default CIDR is 192.168.0.0/16.
3. (Only if you are using the panw_aws_nlb-2.0.template to deploy the applications within the same
VPC)
Select the VPC ID and the Subnet IDs associated with the trust subnet on the firewalls in each AZ.
The network load balancer is attached to the trust subnet on the firewalls, to complete the load
balancer sandwich topology.
4. Enter a name for the network load balancer.
STEP 6 | Modify the web server EC2 instance type to meet your deployment needs.
STEP 7 | Select the EC2 Key pair (from the drop-down) for launching the web servers. To log in to the
web servers, you must provide the key pair name and the private key associated with it.
STEP 8 | (Only if you are using the panw_aws_nlb_vpc-2.0.template) Lock down access to the web
servers.
1. Restrict SSH From access to the web servers. Only the IP addresses you list here can log in to the
web servers.
2. Restrict HTTP access to the web servers. Enter the public IP addresses of the NAT gateway from the
firewall template output, and make sure to separate IP addresses with commas. Entering the NAT
gateway IP address allows you to ensure that all web traffic to the application servers are secured by
the VM-Series firewalls.
STEP 9 | (Only if you are using the panw_aws_nlb_vpc-2.0.template) Configure the other parameters
requires to launch the application template stack in a different VPC.
1. Select SameAccount true if you are deploying this application template within the same AWS
account as the firewall template, and leave the cross account role and external ID blank; select false
for a cross-account deployment.
For a cross-account deployment, enter the Amazon Resource Number (ARN) for the
CrossAccountRole and ExternalId that you defined in (Required only for a cross-account deployment)
STEP 11 | Verify that the network load balancer is deployed and in a ready state.
STEP 12 | Get the DNS name for the application load balancer, and enter it into a web browser.
For example: http://MVpublic-elb-123456789.us-east-2.elb.amazonaws.com/
When the web page displays, you have successfully launched the auto scaling template.
STEP 13 | Verify that each firewall has a NAT policy rule to the IP address of each network load
balancer.
When you deploy the application template to launch another instance of a network load balancer and
pair of web servers, the firewall learns about the port allocated for the next network load balancer
instance and creates another NAT policy rule. So, if you deploy the application template three times, the
firewall has three NAT policy rules for ports 81, 82, and 83.
STEP 14 | If you have launched the application template more than once, you need to Enable Traffic to
the ELB Service.
In v2.0, the ILB can only be a network load balancer. In v2.1 the ILB can be an application
load balancer or a network load balancer.
STEP 2 | Create a target group. The internal load balancer sends requests to registered targets using the
port and protocol that you specify for the servers in the target group.
When you add a new target group, use the port information that you verified on the DynamoDB table.
STEP 3 | Edit the listener rules on the internal load balancer to route requests to the target web servers.
1. On the AWS management console, select Load Balancers in the Load Balancing section, and select
the internal load balancer that matches your stack name.
2. Select View/edit rules to modify the rules for the listener.
STEP 4 | Attach the target group to both VM-Series firewalls auto scaling groups.
1. Select Auto Scaling Groups in the Auto Scaling section and select an auto scaling group that matches
the stack name.
2. Select Details > Editand select the new target group from the Target Groups drop-down.
STEP 5 | Log in to each web server that was deployed by the application template, create a new
directory with the target group name and copy the index.html file into the directory. Until you
set up the path to the index.html file, the health check for this web server reports as unhealthy.
sudo su
cd/var/www/html
mkdir <target-groupname>
cp index.html <target-groupname>
If you have deployed the template and now need to change the credentials for the
administrative user or add a new administrative user and update the template stack, see
Modify Administrative Account and Update Stack.
Create a new Bootstrap File from Scratch
Launch a new VM-Series firewall on AWS using the AMI for a supported PAN-OS version (see the
compatibility matrix for Panorama plugins), without using the sample bootstrap.xml file, and export the
configuration to create a new bootstrap.xml file for use with the VM-Series Auto Scaling template v2.0.
STEP 1 | Deploy the VM-Series Firewall on AWS (no bootstrapping required) and use the public IP
address to SSH into the Command Line Interface (CLI) of the VM-Series firewall. You will need
to configure a new administrative password for the firewall.
STEP 3 | (Optional) Configure the firewall. You can configure the dataplane interfaces, zones and policy
rules.
STEP 5 | Export the configuration file and name it as bootstrap.xml. (Device > Setup > Operation >
Export Named Configuration Snapshot).
STEP 7 | Edit the configuration file you exported earlier to include the AWS CloudWatch information.
Search for </management> and paste the lines 353 to 356 after </management>.
STEP 9 | Save the file. You can now proceed with Launch the VM-Series Auto Scaling Template for
AWS (v2.0).
STEP 1 | To launch the firewall see Bootstrap the VM-Series Firewall on AWS.
STEP 2 | Add an elastic network interface (ENI) and associate an elastic IP address (EIP) to it, so that you
can access the web interface on the VM-Series firewall. See Launch the VM-Series Firewall on
AWS for details.
STEP 3 | Use the EIP address to log in to the firewall web interface with admin as the username and
password.
STEP 4 | Add a secure password for the administrative user account (Device > Local User Database >
Users).
STEP 7 | Generate a new API key for the administrator account. Copy this new key to a new file. You
will need to enter this API key when you launch the VM-Series Auto Scaling template; the
AWS services use the API key to deploy the firewall and to publish metrics for auto scaling.
STEP 8 | Export the configuration file and save it as bootstrap.xml. (Device > Setup > Operation >
Export Named Configuration Snapshot).
STEP 9 | Open the bootstrap.xml file with a text editing tool and delete the management interface
configuration.
STEP 10 | (Required if you exported a PAN-OS 8.0 configuration) Ensure that the setting to validate the
Palo Alto Networks servers is disabled. Look for <server-verification>no</server-
verification>.
STEP 12 | Save the file. You can now proceed with Launch the VM-Series Auto Scaling Template for
AWS (v2.0).
DEL-NLB Message
Refer to the AWS documentation for details on how to send a message to an Amazon SQS Queue, or
review the describe_nlb_dns.py in the sample application template package to see how the application
template constructs the messages.
Stack Update with VM-Series Auto Scaling Template for AWS (v2.0)
A stack update allows you to modify the resources that the VM-Series Auto Scaling template—firewall-
v2.0.template—deploys. Instead of deleting your existing deployment and redeploying the solution, use the
stack update to modify the following parameters:
• License—Switch from BYOL to PAYG and vice versa or switch from one PAYG bundle to another.
• Other stack resources— Change the launch configuration parameters such as the Amazon Machine
Image (AMI) ID, the AWS instance type, key pair for your auto scaling groups. You can also update the
API key associated with the administrative user account on the firewall.
Changing the AMI-ID allows you to deploy new instances of the VM-Series firewalls with a
different PAN-OS version.
When you deploy the VM-Series Auto Scaling template, the auto scaling groups and the launch
configuration are automatically created for you. The launch configuration is a template that an auto scaling
group uses to launch EC2 instance, and it specifies parameters such as the AMI ID, the instance type,
key pair for your auto scaling group. To launch VM-Series firewalls with your updated parameters, you
must first update the stack and then delete the existing auto scaling groups in each AZ. To prevent service
disruption, delete the auto scaling group in one AZ first, and wait for the new firewall instances to launch
with the updated stack parameters. Then, verify that the firewalls have inherited the updates you made
before you proceed to complete the changes in the other AZ.
You can update stack directly or create change sets. The workflow in this document takes you through the
manual stack update.
STEP 1 | In the AWS CloudFormation console, select the parent stack that you want to update and
choose Actions > Update Stack.
STEP 3 | Acknowledge the notifications and review the changes and click Update to initiate the stack
update.
STEP 4 | On the EC2 dashboard > Auto Scaling Groups and pick an AZ in which to delete the ASG.
Deleting an ASG automatically triggers the process of redeploying a new ASG. The firewalls in the new
ASG use the updated stack configuration.
STEP 6 | Repeat steps 4 and 5 to replace the ASG in the other AZ.
STEP 1 | Log in to the web interface of the firewall and change the credentials for an existing
administrative user or create a new account.
STEP 4 | Upload this bootstrap.xml file to the S3 bootstrap folder; see Customize the Bootstrap.xml File
(v2.0).
STEP 5 | Update the API key in the stack to ensure that newly launched firewalls will have the updated
administrator account.
See Stack Update with VM-Series Auto Scaling Template for AWS (v2.0).
You can also deploy the firewall ASG in a centralized VPC and your application workloads in separate VPCs
within the same region, forming a hub and spoke architecture, as shown below.
With the hub and spoke architecture you can streamline the delivery of centralized security and
connectivity for AWS deployments with many applications, VPCs, or accounts. This architecture can
Ensure that the application VPCs connected to the firewall VPC, do not have an Internet
Gateway (IGW), and use a continuous monitoring and security compliance service such as
Prisma Public Cloud.
You can use a single AWS account or multiple AWS accounts to monitor and secure traffic between VPCs
and the internet. Centralizing firewalls in a single VPC can reduce costs for deployments with multiple VPCs
and/or multiple accounts.
To provide flexibility with securing your application workloads, version 2.1 allows you to deploy an
application load balancer or a network load balancer for both the external load balancer that fronts your
VM-Series firewall ASG, and the internal load balancer (ILB) that fronts your application workloads.
When an application load balancer fronts the application workloads, you can connect the firewall VPC to
the application VPC using VPC peering. When an NLB fronts the application workloads you can use VPC
Peering or an AWS Private Link to connect the firewall and application VPCs, as summarized below:
If you deploy in a single VPC you can use all the load balancing combinations in the previous table.
You can deploy the templates in both and greenfield (new VPC and applications) and brownfield (existing
VPC and applications) use cases.
Template Description
See Customize the Firewall Template Before Launch (v2.0 and v2.1) for more on these parameters.
Application Templates
The application template deploys an internal load balancer (ILB) and one auto scaling group with a web
server in each availability zone (AZ).
Template Description
Lambda Functions
AWS Lambda provides robust, event-driven automation without the need for complex orchestration
software. AWS Lambda monitors a Simple Queue Service (SQS) to learn about load balancers (ALBs or
NLBs) that publish to the queue. When the Lambda function detects a new load balancer, it creates a new
NAT policy rule and applies it to the VM-Series firewalls within the ASG. The firewalls have a NAT policy
rule for each application, and the firewalls use the NAT policy rule (that maps the port to the load balancer
IP address) to forward traffic to the load balancer in front of the application web servers.
The Lambda functions also delete all the configuration items that Lambda added to the device group and
template stack in Panorama. This includes the NAT rule, Address Object, and Static Routes that were
pushed to the VM-Series firewall. The Lambda function handles delicensing as well.
To learn more about the Lambda functions, refer to the
Palo Alto Networks AWS AutoScale Documentation.
Panorama
You must have Panorama management server in Panorama mode to configure Auto Scaling v2.1.
The Panorama management server provides centralized monitoring and management of multiple Palo
Alto Networks next-generation firewalls from a single location. Panorama allows you to oversee all
applications, users, and content traversing your network, and use this knowledge to create application
enablement policies that protect and control the network. If you are not familiar with Panorama please see
the Panorama Administrator’s Guide.
Managed firewalls are bootstrapped with an init-config.txt file. A sample file is included in the
GitHub repository so that you can copy the configuration from the template stack and device group when
you create them in your existing Panorama.
• The templates configure an Administrator account named pandemo and the password demopassword.
• Create a virtual router with the naming convention VR-<TemplateStackName>. On the virtual router
ECMP tab, enable ECMP.
• To set the DNS server address on Panorama, select Device > Setup > Services. Set the Primary DNS
Server to 169.254.169.253, the Secondary DNS Server to 8.8.8.8, and the FQDN Refresh Time (sec)
to 60. Panorama requires the AWS DNS server IP address to resolve the FQDN of the internal load
balancer on AWS. The FQDN refresh time is the interval at which Panorama commits newly detected
internal load balancers.
After the application template has launched, Lambda populates the following in Panorama:
• NAT policy
• Address object for LB in Application Template
• Static routes in the virtual router
• Tcp81 service object
The v2.1 firewall template includes an AWS NAT gateway that the firewalls use to initiate outbound
requests for retrieving updates, connecting to Panorama, and publishing metrics to AWS CloudWatch. The
NAT Gateways also have Elastic IP addresses attached to them for each zone.
You need the following Panorama resources to work with the Auto Scale templates for AWS.
Panorama API Key You need a Panorama API key to authenticate the API. Lambda uses your API
key to autoconfigure template and device group options. To generate the API
key, see Get Your API Key.
Panorama License The template requires a license deactivation API key and the “Verify Update
Deactivation Key Server Identity” to be enabled to deactivate the license keys from Panorama.
The license deactivation key should be obtained from Palo Alto Customer
Support Portal as described in Install a License Deactivation API Key.
Panorama Management • Port 443 (HTTPS)—Upon initial deployment of the firewall template, leave
Interface Access HTTPS open so Lambda can connect to Panorama. Wait to receive the
following confirmation of connection in Panorama:
When you secure port 443 you specify an IP address range from which
you will allow connections, as well as the EIPs assigned to the NAT
Bootstrap Files
The GitHub auto scaling repository includes an init-cfg.txt file so that the VM-Series firewall has the
basic configuration to:
• Perform interface swap so the VM-Series firewall untrust traffic uses AWS ENI for eth0.
• Communicate to Panorama for device group and template configuration.
The auto scaling GitHub repository has the basic configuration to get started. This auto scaling solution
requires swapping the dataplane and management interfaces to enable the load balancer to forward web
traffic to the VM-Series firewall auto scaling tier. For details on management interface mapping with the
Amazon ELB as shown in Management Interface Mapping for Use with Amazon ELB.
STEP 1 | Review the checklists in Plan to Deploy VM-Series Auto Scaling Templates for AWS (v2.1) and
Plan the VM-Series Auto Scaling Template for AWS (v2.0 and v2.1).
Verify that you have completed the following tasks:
• (For PAYG only) Review and accept the EULA for the PAYG bundle you plan to use.
• (For BYOL only) Obtain the auth code for a bundle that supports the number of firewalls that might
be required for your deployment. You must save this auth code in a text file named authcodes (no
extensions), and put the authcodes file in the /license folder of the bootstrap package.
If you use individual auth codes instead of a bundle, the firewall only retrieves the
license key for the first auth code in the file.
• Download the files required to launch the VM-Series Auto Scaling v2.1 template from the GitHub
repository.
STEP 2 | Modify the init-cfg.txt file and upload it to the /config folder.
type=dhcp-client
ip-address=
default-gateway=
netmask=
ipv6-address=
ipv6-default-gateway=
hostname=
vm-auth-key=
panorama-server=
panorama-server-2=
tplname=AWS-tmplspoke1
dgname=AWS-dgspoke1
dns-primary=169.254.169.253
dns-secondary=8.8.8.8
op-command-modes=mgmt-interface-swap
dhcp-send-hostname=yes
dhcp-send-client-id=yes
dhcp-accept-server-hostname=yesdhcp-accept-server-domain=yes
vm-series-auto-registration-pin-value=
STEP 3 | (For BYOL only) Add the license auth code in the /license folder of the bootstrap package.
1. Use a text editor to create a new text file named authcodes (no extension).
2. Add the authcode for your BYOL licenses to this file, and save. The authcode must represent a
bundle, and it must support the number of firewalls that might be required for your deployment. If
you use individual authcodes instead of a bundle, the firewall only retrieves the license key for the
first authcode in the file.
STEP 4 | Upload Lambda code for the firewall template (panw-aws-zip) and the Application template
(ilb.zip) to an S3 bucket. You can use the same S3 bucket that you use for bootstrapping.
2. Look up the AMI ID for the VM-Series firewall and enter it. Make sure that the AMI ID matches the
AWS region, PAN-OS version and the BYOL or PAYG licensing option you opted to use.
3. Select the EC2 Key pair (from the drop-down) for launching the firewall. To log in to the firewalls,
you must provide the name of this key pair and the private key associated with it.
1. Enter the name of the S3 bucket that contains the bootstrap package.
If the bootstrap bucket is not set up properly or if you enter the bucket name incorrectly, the
bootstrap process fails, and you cannot log in to the firewall. Health checks for the load balancers
also fail.
2. Enter the name of the S3 bucket that contains the panw-aws.zip file. As mentioned earlier you can
use one S3 bucket for the Bootstrap and Lambda code.
STEP 8 | Specify the keys for enabling API access to the firewall and Panorama.
1. Enter the key that the firewall must use to authenticate API calls. The default key is based on the
sample file and you should only use it for testing and evaluation. For a production deployment, you
must create a separate PAN-OS login just for the API call and generate an associated key.
2. Enter the API Key to allow AWS Lambda to make API calls to Panorama. For a production
deployment, you should create a separate login just for the API call and generate an associated key.
STEP 11 | Verify that the template has launched all required resources.
1. On the EC2 Dashboard, select Auto Scaling Groups. Verify that in each AZ, you have one ASG for the
VM-Series firewalls. The ASG name prefix includes the stack name.
2. On the AWS Management Console, select the stack name to view the Output for the list of
resources.
3. Your output should look similar to the output in the following image.
• Take note of the Network Load Balancer Queue name.
• Take note of the Elastic Load Balancer public DNS name.
It may take up to 20 minutes for the firewalls to boot up and be available to handle traffic.
When you are finished with a testing or a production deployment, the only way to ensure
charges stop occurring is to completely delete the stack. Shutting down instances, or
changing the ASG maximum to 0 is not sufficient.
STEP 12 | Save the following firewall template information. You must provide these values as inputs
when deploying the application template.
• IP addresses of the NAT Gateway in each AZ—You need this IP address to restrict HTTPS access
to your Panorama so that Lambda can use the EIPs for the NAT Gateway to communicate with
Panorama when needed.
STEP 1 | Create an S3 bucket from which you will launch the application template.
• If this is a cross-account deployment, create a new bucket.
• If there is one account you can create a new bucket or use the S3 bucket you created earlier (you can
use one bucket for everything).
STEP 3 | Select the application launch template you want you launch.
1. In the AWS Management Console, select CloudFormation > CreateStack
2. Select Upload a template to Amazon S3, to choose the application template to deploy the resources
that the template launches within the same VPC as the firewalls, or to a different VPC. Click Open
and Next.
3. Specify the Stack name. The stack name allows you to uniquely identify all the resources that are
deployed using this template.
STEP 4 | Configure the parameters for the VPC and network load balancer.
1. Select the two Availability Zones that your setup will span in Select list of AZ. If you are deploying
within the same VPC make sure to select the same Availability Zones that you selected for the
firewall template.
2. If deploying to a new VPC enter a CIDR Block for the VPC. The default CIDR is 192.168.0.0/16.
3. If deploying to the same VPC you will select the previous VPC and use the Trust subnets.
STEP 7 | Modify the web server EC2 instance type to meet your needs.
STEP 8 | Select the EC2 Key pair (from the drop-down) for launching the web servers. To log in to the
web servers, you must provide the key pair name and the private key associated with it.
STEP 9 | Select the IP address of the network you will be accessing the servers from for management
access only. Web traffic comes through the ELBDNS name you copied when you launched the
firewall template.
STEP 11 | After completion of the application template it can take up to 20 minutes for the web pages
to become active.
1. Verify that the application template load balancer is marked active.
STEP 13 | Upon successful launch your browser should look like this output.
When creating a custom AMI with a BYOL version of the firewall, you must first activate the
license on the firewall so that you can access and download PAN-OS content and software
updates to upgrade your firewall, and then deactivate the license on the firewall before
performing the private data reset and creating the custom AMI. If you do not deactivate the
license, you lose the license that you applied on this firewall instance.
Enter y to confirm.
The firewall reboots to initialize the default configuration.
5. Verify that the custom AMI is created and has the correct product code.
1. On the EC2 Dashboard, select AMI.
2. Select the AMI that you just created. Depending on whether you selected an AMI with the BYOL,
Bundle 1, or Bundle 2 licensing options, you should see one of the following Product Codes in the
details:
• BYOL—6njl1pau431dv1qxipg63mvah
STEP 1 | In the AWS Management Console, select Cloud Formation > Create Stack.
STEP 2 | Locate the firewall template and application template you launched previously and delete both
templates.
For more information on deleting template stacks see, “What is AWS CloudFormation?“
msg_add_nlb= {
"MSG-TYPE": "ADD-NLB",
"AVAIL-ZONES": [
"NLB-IP":"192.168.2.101",
"ZONE-NAME":"us-east-2a",
"SUBNET-ID": "subnet-2a566243"
},
"NLB-IP":"192.168.12.101",
"ZONE-NAME":"us-east-2b",
],
"DNS-NAME": "publicelb1-2119989486.us-east-2.elb.amazonaws.com",
"VPC-ID": "vpc-42ba9f2b",
DEL-NLB Message
msg_del_nlb= {
"MSG-TYPE": "DEL-NLB",
"DNS-NAME": "publicelb1-2119989486.us-east-2.elb.amazonaws.com",
ADD-ALB
{ "AVAIL-ZONES": [
"SUBNET-CIDR": "172.32.0.0/24",
"SUBNET-ID": "subnet-0953a3a8e2a8208a9",
"ZONE-NAME": "us-east-2a"
},
"SUBNET-CIDR": "172.32.2.0/24",
"SUBNET-ID": "subnet-0a9602e4fb0d88baa",
"ZONE-NAME": "us-east-2c"
},
"SUBNET-ID": "subnet-0b31ed16f308b3c4d",
"ZONE-NAME": "us-east-2b"
],
"VPC-PEERCONN-ID": "pcx-0538bb05dbe2e1b8e",
"VPC-CIDR": "172.32.0.0/16",
"ALB-NAME": "appILB-908-0",
"ALB-ARN":"arn:aws:elasticloadbalancing:us-
east-2:018147215560:loadbalancer/app/appILB-908-0/1997ed20eeb5bcef",
"VPC-ID": "vpc-0d9234597da6d9147",
"MSG-TYPE": "ADD-ALB",
"DNS-NAME": "internal-appILB-908-0-484644265.us-east-2.elb.amazonaws.com"
DEL-ALB Message
"MSG-TYPE": "DEL-ALB",
"DNS-NAME": "internal-appILB-908-0-484644265.us-east-2.elb.amazonaws.com"
Refer to the AWS documentation for details on how to send a message to an Amazon SQS Queue.
You do not have to update the stack to modify default notifications or create auto scaling
alarms. See Change Scaling Parameters and CloudWatch Metrics (v2.1).
When you deploy the VM-Series Auto Scaling template, the auto scaling groups and the launch
configuration are automatically created for you. The launch configuration is a template that an auto scaling
group uses to launch EC2 instance, and it specifies parameters such as the instance type, the key pair for
your auto scaling group, or the API key associated with the administrative user account on the firewall.
You can update your stack directly or create change sets. The workflow in this document takes you through
the manual stack update.
STEP 1 | In the AWS CloudFormation console, select the parent stack that you want to update and
choose Actions > Update Stack.
STEP 3 | Acknowledge the notifications and review the changes and click Update to initiate the stack
update.
STEP 1 | Log in to the web interface of the firewall and change the credentials for an existing
administrative user or create a new account.
STEP 3 | Update the API key in the stack to ensure that newly launched firewalls have the updated
administrator account.
See Stack Update with VM-Series Auto Scaling Template for AWS (v2.0).
STEP 2 | Choose a Custom Namespace link, and select the metrics link to view the custom PAN-OS
metrics.
STEP 4 | Define an alarm that removes a firewall when CPU utilization meets or falls below the criteria
you set, over the time frame you set.
1. Select Edit to change the graph title.
2. Under Alarm details fill in the Name and Description, choose an operator, and set the minimum value
to maintain the current instances. If the minimum value is not maintained, an instance is removed.
3. Under Actions, delete the default notification.
4. Select +AutoScaling Action.
• Use the From the list to select your namespace.
• From Take this action, select the policy to remove an instance.
STEP 5 | Create a second alarm that adds a firewall when CPU utilization meets or exceeds the criteria
you set.
STEP 6 | To view your alarms, select Services > CloudWatch > Alarms.
To edit an alarm from this window, check the box next to the alarm and select Action > Edit.
The maximum length of the tag-value (name and value included) must be 116 characters
or less. If a tag is longer than 116 characters, Panorama does not retrieve the tag and
register it on the firewalls.
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
421
422 VM-SERIES DEPLOYMENT GUIDE | Set Up the VM-Series Firewall on KVM
© 2021 Palo Alto Networks, Inc.
VM-Series on KVM—Requirements and
Prerequisites
• Options for Attaching the VM-Series on the Network
• Prerequisites for VM-Series on KVM
Requirements Description
Hardware Resources See VM-Series System Requirements for the minimum hardware
requirements for your VM-Series model.
Software Versions See the supported KVM software versions in the Compatibility Matrix.
SR-IOV Drivers See PacketMMAP Driver Versions drivers in the Compatibility Matrix.
• With a Linux bridge or OVS, data traffic uses the software bridge to connect guests on the same host.
For external connectivity, data traffic uses the physical interface to which the bridge is attached.
• With PCI passthrough, data traffic is passed directly between the guest and the physical interface to
which it is attached. When the interface is attached to a guest, it is not available to the host or to other
guests on the host.
• With SR-IOV, data traffic is passed directly between the guest and the virtual function to which it is
attached.
STEP 1 | From the host, download the package for Mellanox OpenFabric Enterprise Distribution for
Linux (MLNX_OFED) for your OS version from the following link:
https://www.mellanox.com/products/infiniband-drivers/linux/mlnx_ofed
# mst status
MST modules:
------------------------------------------------------------------
MST PCI module is not loaded
MST PCI configuration module loaded
MST devices:
------------------------------------------------------------------
/dev/mst/mt4121_pciconf0 - PCI configuration cycles access.
domain:bus:dev.fn=0000:3b:00.0 addr.reg=88 data.reg=92
Chip revision is: 00
Enable Virtual Functions for Mellanox CX5 NICs on the VM-Series Firewall on KVM
Install the Mellanox software tools before you enable virtual functions on Mellanox Cx5 NICs.
STEP 2 | Enable the number of number of virtual functions required. For example:
After you save the changes and reboot the Linux server, each interface (or physical function) in the
above example will have 4 virtual functions. Refer to the documentation provided by your network
vendor for details on the actual number of virtual functions supported, and the instructions to enable
virtual functions.
You might see the following error message the first time you enable virtual functions on
Mellanox Cx5 NICs:
To resolve the issue, enter the following command sequence on the Linux server:
# cat /sys/class/net/enp59s0f1/device/sriov_numvfs
(Optional) If the virtual functions are not set correctly (the status is 0 or empty), run the following
command:
STEP 4 | List the PCI devices to accurately match the number of virtual functions loaded on the
respective physical function for Mellanox:
STEP 1 | Create a new virtual machine and add the VM-Series Firewall for KVM image to virt-mgr.
1. On the Virt-manager, select Create a new virtual machine.
2. Add a descriptive Name for the VM-Series firewall.
3. Select Import existing disk image, browse to the image, and set the OS Type: Linux and Version: Red
Hat Enterprise Linux 6.
If you prefer, you can leave the OS Type and Version as Generic.
STEP 3 | Enable configuration customization and select the management interface bridge.
1. Select Customize configuration before install.
2. Under Advanced options, select the bridge for the management interface, and accept the default
settings.
If you want to use a SCSI disk bus, see Enable the Use of a SCSI Controller.
2. Expand Performance options, and set Cache mode to writethrough. This setting improves installation
time and execution speed on the VM-Series firewall.
5. In the Host Device list, select the interface on the card or the virtual function.
6. Click Apply or Finish.
STEP 6 | Click Begin Installation . Wait 5-7 minutes for the installation to complete.
By default, the XML template for the VM-Series firewall is created and stored at etc/libvirt/
qemu.
STEP 8 | Configure the network access settings for the management interface.
1. Open a connection to the console.
2. Log into the firewall with username/password: admin/admin.
3. Enter configuration mode with the following command:
configure
4. Use the following commands to configure the management interface:
1. set deviceconfig system type static
where <Firewall-IP> is the IP address you want to assign to the management interface,
<netmask> is the subnet mask, <gateway-IP> is the IP address of the network gateway, and
<DNS-IP> is the IP address of the DNS server.
3. commit
STEP 9 | Verify which ports on the host are mapped to the interfaces on the VM-Series firewall. In order
to verify the order of interfaces on the Linux host, see Verify PCI-ID for Ordering of Network
Interfaces on the VM-Series Firewall.
To make sure that traffic is handled by the correct interface, use the following command to identify
which ports on the host are mapped to the ports on the VM-Series firewall.
STEP 10 | Access the web interface of the VM-Series firewall and configure the interfaces and define
security rules and NAT rules to safely enable the applications that you want to secure.
Refer to the PAN-OS Administrator’s Guide.
STEP 3 | Configure the network access settings for the management interface.
Enter the following commands:
If a single error is encountered in parsing the bootstrap file, the VM-Series firewall will reject
all the configuration in this file and boot with default values.
STEP 1 | Create the XML file and define it as a virtual machine instance.
For a sample file, see Sample XML file for the VM-Series Firewall.
In this example, the VM-Series firewall is called PAN_Firewall_DC1.
For example:
Use the following example as a template for the bootstrap-networkconfig file. The bootstrap-
networkconfig file can include the following parameters only:
<vm-initcfg>
<hostname>VM_ABC_Company</hostname>
<ip-address>10.5.132.162</ip-address>
<netmask>255.255.254.0</netmask>
<default-gateway>10.5.132.1</default-gateway>
<dns-primary>10.44.2.10</dns-primary>
<dns-secondary>8.8.8.8</dns-secondary>
Save the ISO file in the images directory (/var/lib/libvirt/image) or the qemu directory (/etc/
libvirt/qemu) to ensure that the firewall has read access to the ISO file.
For example:
To modify the number of vCPUs assigned on the VM-Series firewall, change the value 2 to 4
or 8 vCPUs in this line of the sample XML file:
<vcpu placement="static">2</vcpu>
KVM on Ubuntu 12.04 does not support the virtio-scsi controller; the virtio-scsi controller can
only be enabled on the VM-Series firewall running on RHEL or CentOS.
This process requires virsh because Virt manager does not support the virtio-scsi controller.
STEP 1 | Create an XML file for the SCSI controller. In this example, it is called virt-scsi.xml.
Make sure that the slot used for the virtio-scsi controller does not conflict with another
device.
STEP 2 | Associate this controller with the XML template of the VM-Series firewall.
STEP 4 | Edit the XML template of the VM-Series firewall. In the XML template, you must change the
target disk and the disk bus, used by the firewall.
<interface type='bridge'>
<mac address='52:54:00:d7:91:52'/>
<source bridge='mgmt-br'/>
<model type='virtio'/>
<address type='pci' domain='0x0000' bus='0x00' slot='0x03'
function='0x0'/>
</interface>
<interface type='bridge'>
<mac address='52:54:00:f4:62:13'/>
<source bridge='br8'/>
<model type='e1000'/>
<address type='pci' domain='0x0000' bus='0x00' slot='0x10'
function='0x0'/>
</interface>
<interface type='bridge'>
<mac address='52:54:00:fe:8c:80'/>
<source bridge='br8'/>
<model type='e1000'/>
<address type='pci' domain='0x0000' bus='0x00' slot='0x06'
function='0x0'/>
</interface>
wget http://dpdk.org/browse/dpdk/snapshot/dpdk-2.2.0.tar.gz
tar xzvf dpdk-2.2.0.tar.gz
cd dpdk-2.2.0
vi config/common_linuxapp
2. Change CONFIG_RTE_APP_TEST=y to CONFIG_RTE_APP_TEST=n
3. Change CONFIG_RTE_BUILD_COMBINE_LIBS=n to CONFIG_RTE_BUILD_COMBINE_LIBS=y
4. Execute the following command:
vi GNUmakefile
wget http://openvswitch.org/releases/openvswitch-2.5.1.tar.gz
tar xzvf openvswitch-2.5.1.tar.gz
cd openvswitch-2.5.1
./configure –with-dpdk=”/root/dpdk-2.2.0/x86_64-native-linuxapp-gcc/”
make
make install
STEP 2 | If you are replacing or reconfiguring an existing OVS-DPDK setup, execute the following
commands to reset any previous configuration. Repeat the command for each interface.
rm /usr/local/var/run/openvswitch/<interface-name>
mkdir /dev/hugepages
mkdir /dev/hugepages/libvirt
mkdir /dev/hugepages/libvirt/qemu
mount -t hugetlbfs hugetlbfs /dev/hugepages/libvirt/qemu
STEP 5 | Use the following command to kill any currently existing OVS daemon.
mkdir -p /usr/local/etc/openvswitch
mkdir -p /usr/local/var/run/openvswitch
rm -f /var/run/openvswitch/vhost-user*
ovsdb-server --remote=punix:/usr/local/var/run/openvswitch/db.sock \
--remote=db:Open_vSwitch,Open_vSwitch,manager_options \
--private-key=db:Open_vSwitch,SSL,private_key \
--certificate=db:Open_vSwitch,SSL,certificate \
--bootstrap-ca-cert=db:Open_vSwitch,SSL,ca_cert \
--pidfile --detach
export DB_SOCK=/usr/local/var/run/openvswitch/db.sock
STEP 12 | Install the igb_uio module (network device driver) for DPDK.
cd ~/dpdk-2.2.0/x86_64-native-linuxapp-gcc/kmod
modprobe uio
insmod igb_uio.ko
cd ~/dpdk-2.2.0/tools/
STEP 14 | Start the OVS daemon in DPDK mode. You can change the number of cores for ovs-vswitchd.
By changing -c 0x1 to -c 0x3, you can have two core run this daemon.
STEP 15 | Create the OVS bridge and attach ports to the OVS bridge.
STEP 17 | Set the number of hardware queues of the NIC used by the host.
STEP 19 | Set the necessary permissions for DPDK vhost user ports. In the example below, 777 is used
to give read, write, and executable permissions.
<memory unit='KiB'>12582912</memory>
<currentMemory unit='KiB'>6291456</currentMemory>
<memoryBacking>
<hugepages/>
3. Set the necessary CPU flags for VM.
<cpu mode='host-model'>
4. Enable memory sharing between the VM and the host.
<numa>
<cell id='0' cpus='0,2,4,6' memory='6291456' unit='KiB'
memAccess='shared'/>
<interface type='vhostuser'>
<mac address='52:54:00:36:83:70'/>
<source type='unix' path='/usr/local/var/run/openvswitch/vhost-
user1' mode='client'/>
<model type='virtio'/>
<driver name=’vhost’ queues=’8’/>
<address type='pci' domain='0x0000' bus='0x00' slot='0x04'
function='0x0'/>
</interface>
<interface type='vhostuser'>
<mac address='52:54:00:30:d7:94'/>
<source type='unix' path='/usr/local/var/run/openvswitch/vhost-
user2' mode='client'/>
<model type='virtio'/>
<driver name=’vhost’ qeueus=’8’>
<address type='pci' domain='0x0000' bus='0x00' slot='0x05'
function='0x0'/>
</interface>
<network>
<name>passthrough</name>
<forward mode='hostdev' managed='yes'>
<pf dev='eth3'/>
</forward>
</network>
2. Save the XML file.
3. Execute the following commands:
STEP 3 | After defining and starting the network, modify the guest XML definition to specify the
network.
<interface type='network'>
<source network='passthrough'>
</interface>
STEP 1 | On the host system, set up the physical and virtual function to operate in VLAN access mode.
ip link set [inf_name] vf [vf_num] vlan [vlan_id].
Modify the guest XML definition. Insert a value from 1 to 256 for N to specify the number
of queues. For the best results, match the number of queues with number of dataplane cores
configured on the VM.
<interface type='network'>
<source network='default'/>
<model type='virtio'/>
<driver name='vhost' queues='N'/>
</interface>
STEP 1 | View the NUMA topology. In the example below, there are two NUMA nodes (sockets), each
with a four-core CPU with hyperthreading enabled. All the even-numbered CPU IDs belong to
one node and all the odd-numbered CPU IDs belong to the other node.
% virsh capabilities
<…>
<topology>
<cells num='2'>
<cell id='0'>
<memory unit='KiB'>33027228</memory>
<pages unit='KiB' size='4'>8256807</pages>
<pages unit='KiB' size='2048'>0</pages>
<distances>
STEP 2 | Pin vCPUs in a KVM guest to specific physical vCPUs, use the cpuset attribute in the guest xml
definition. In this example, all 8 vCPUs are pinned to physical CPUs in the first NUMA node.
If you do not wish to explicitly pin the vCPUs, you can omit the cputune block, in which case,
all vCPUs will be pinned to the range of CPUs specified in cpuset, but will not be explicitly
mapped.
<vcpu cpuset='0,2,4,6,8,10,12,14'>8</vcpu>
<cputune>
<vcpupin vcpu='0' cpuset='0'/>
<vcpupin vcpu='1' cpuset='2'/>
<vcpupin vcpu='2' cpuset='4'/>
<vcpupin vcpu='3' cpuset='6'/>
<vcpupin vcpu='4' cpuset='8'/>
<vcpupin vcpu='5' cpuset='10'/>
<vcpupin vcpu='6' cpuset='12'/>
<vcpupin vcpu='7' cpuset='14'/>
</cputune>
453
454 VM-SERIES DEPLOYMENT GUIDE | Set Up the VM-Series Firewall on Hyper-V
© 2021 Palo Alto Networks, Inc.
Supported Deployments on Hyper-V
You can deploy one or more instances of the VM-Series on hosts running Hyper-V. Where you place the
VM-Series firewall depends on your network topology. VM-Series supports tap, virtual wire, Layer 2, and
Layer 3 interface deployments.
• Secure Traffic on a Single Hyper-V Host
• Secure Traffic Across Multiple Hyper-V Hosts
STEP 2 | Select Settings > Hardware > Network Adapter > Hardware Acceleration.
STEP 3 | Under Virtual machine queue, uncheck Enable virtual machine queue.
STEP 4 | Click Apply save your changes and OK to exit the VM settings.
Do not enable dynamic memory; the VM-Series firewall requires static memory
allocation.
4. Configure Networking. Select an external vSwitch to connect the management interface on the
firewall.
5. To connect the Virtual Hard Disk, select Use an existing virtual hard disk and browse to the
VHDX file you downloaded earlier.
6. Review the summary and click Finish.
2. Assign virtual CPUs to the firewall.
1. Select the VM you created and navigate to Action > Settings.
2. Select Processor and enter the minimum number of CPUs based on the VM-Series System
Requirements of your VM-Series model..
3. Click OK.
STEP 4 | Connect at least one network adapter for the dataplane interface on the firewall.
1. Select Settings > Hardware > Add Hardware and select the Hardware type for your network
adapter.
Legacy Network Adapter and SR-IOV are not supported. If selected, the VM-Series
firewall will boot into maintenance mode.
2. Click OK.
STEP 5 | (Optional) Enable MAC address spoofing on Hyper-V if you are not using Layer 3 with
hypervisor assigned MAC address.
1. Double click the dataplane virtual network adapter and click Advanced Settings.
2. Click the Enable MAC address spoofing check box and click Apply.
STEP 4 | Connect at least one network adapter for the management interface on the firewall.
Connect the default network adapter created during VM creation to management vSwitch.
STEP 5 | (Optional) Enable MAC address spoofing on Hyper-V if you are not using Layer 3 with
hypervisor assigned MAC address.
STEP 3 | Configure the network access settings for the management interface.
Enter the following commands:
where <Firewall-IP> is the IP address you want to assign to the management interface, <netmask> is the
subnet mask, <gateway-IP> is the IP address of the network gateway, and <DNS-IP> is the IP address of
the DNS server.
STEP 5 | Verify that you can view the management interface IP address from the Hyper-V Manager.
1. Select the VM-Series firewall from the list of Virtual Machines.
2. Select Networking. The first network adapter that displays in the list is used for management access
to the firewall; subsequent adapters in the list are used as the dataplane interfaces on the firewall.
After verifying DNS resolution, press Ctrl+C to stop the ping request.
2. Use the following CLI command to retrieve information on the support entitlement for the firewall
from the Palo Alto Networks update server:
request support
check
If you have connectivity, the update server will respond with the support status for your firewall.
STEP 7 | (Optional) Verify that your VM-Series jumbo frame configuration does not exceed the maximum
MTU supported on Hyper-V.
The VM-Series has a default MTU size of 9216 bytes when jumbo frames are enabled. However, the
maximum MTU size supported by the physical network adapter on the Hyper-V host is 9000 or 9014
bytes depending on the network adapter capabilities. To verify the configured MTU on Hyper-V:
1. In Windows Server 2012 R2, open the Control Panel and navigate to Network and Internet >
Network and Sharing Center > View network status and tasks.
2. Click on a network adapter or virtual switch from the list.
3. Click Properties.
4. Click Configure.
5. On the Advanced tab, select Jumbo Packet from the list.
6. Select 9000 or 9014 bytes from the Value drop-down menu.
7. Click OK.
If you have enabled jumbo frames on Hyper-V, Enable Jumbo Frames on the VM-Series Firewall and set
the MTU size to match that configured on the Hyper-V host.
STEP 8 | Access the web interface of the VM-Series firewall and configure the interfaces and define
security rules and NAT rules to safely enable the applications you want to secure.
Refer to the PAN-OS Administrator’s Guide.
465
466 VM-SERIES DEPLOYMENT GUIDE | Set up the VM-Series Firewall on Azure
© 2021 Palo Alto Networks, Inc.
About the VM-Series Firewall on Azure
The VM-Series firewall on Azure must be deployed in a virtual network (VNet) using the Resource Manager
deployment mode. You can deploy the VM-Series firewall on the standard Azure public cloud, Azure China,
and Azure Government—including DoD on Azure Government, which meets the security requirements for
DoD Impact Level 5 data and FedRAMP High standards.
The VM-Series firewall on the marketplace for the Azure public cloud, Azure Government, and Azure DoD
regions, supports both the Bring Your Own License (BYOL) model and the hourly Pay-As-You-Go (PAYG)
option (usage-based licensing) For licensing details, see License Types—VM-Series Firewalls, and refer to
the list of supported Azure regions in which you can deploy the VM-Series firewall.
For Azure China, the VM-Series firewall is available in the BYOL option only. See Deploy the VM-Series
Firewall from the Azure China Marketplace (Solution Template) for the workflow.
You can also deploy the VM-Series firewall on Azure Stack, Microsoft's private cloud solution that enables
you to use Azure services within your organization's datacenter. With Azure Stack, you can build out a
hybrid cloud solution that unifies your public Azure deployment with your on-premise Azure Stack set up.
You can download the VM-Series firewall BYOL offer from the Azure Marketplace and make it available to
your tenants on Azure Stack. For instructions, see Deploy the VM-Series Firewall on Azure Stack.
• Azure Networking and VM-Series Firewall
• Azure Security Center Integration
• VM-Series Firewall Templates on Azure
• Minimum System Requirements for the VM-Series on Azure
• Support for High Availability on VM-Series on Azure
On Azure, UDRs are for traffic leaving a subnet only. You cannot create user defined routes
to specify how traffic comes into a subnet from the Internet or to route traffic to virtual
machines within a subnet. UDRs allow you to direct outbound traffic to an interface on the
VM-Series firewall so that you can always ensure that the firewall secures traffic to the
internet also.
For documentation on Microsoft Azure, refer to https://azure.microsoft.com/en-us/
documentation/.
The solution templates for deploying the VM-Series firewall that are available in the Azure Marketplace,
have three network interfaces. To Set up Active/Passive HA on Azure, you will need to add an additional
interface for the HA2 link. If you want to customize the template, use the ARM templates that are available
in the GitHub repository.
When the Azure Security Center dashboard recommends that you deploy a VM-Series firewall to secure
a workload that is exposed to the internet, you can only deploy the firewall in an new resource group or
an existing resource group that is empty. This is because Azure currently restricts you from deploying
a multi NIC appliance in an existing resource group. Therefore, after you deploy the VM-Series firewall
you must manually configure it to be in the path of traffic of the workload that you need to secure.
When you deploy the firewall from Azure Security Center, the firewall is launched with three network
interfaces—management, external facing (untrust) and internal facing (trust)—and a user defined route
(UDR) that sends all outbound traffic from the trust subnet to the trust interface on the firewall so
that internet-bound traffic is always inspected by the firewall. The default configuration includes two
example Security Policy rules—the outbound-default rule allows all traffic from the trust zone to the
untrust zone on the application default port, and the inbound-default rule allows all web-browsing traffic
from the untrust zone to the trust zone, after inspecting traffic with the default Antivirus, Anti-spyware,
and Vulnerability Protection security profiles. The firewall also forwards all files that are intercepted with
the inbound or outbound rule to the WildFire public cloud for analysis. Both rules include a URL Filtering
profile that blocks all traffic to the URL categories copyright-infringement, dynamic-dns, extremism,
malware, phishing, and unknown. In addition to these security profiles, both Security policy rules are
enabled to log at session end and to forward Threat and WildFire Submissions logs as security alerts to
the Azure Security Center dashboard.
To make practical use of this integration and Deploy a VM-Series Firewall Based on an Azure Security
Center Recommendationwithin the same resource group as the workloads you want to secure, you can
stage a workload with a public IP address that is exposed to the internet. When Azure Security Center
detects the security risk, it triggers a recommendation to deploy a next-generation firewall, and you can
To Connect an Existing VM-Series Firewall From Azure Security Center, you must set up a Linux virtual
machine and configure Syslog forwarding to forward firewall logs in the Common Event Format as alerts
to Azure Security Center. The additional configuration enables a single pane of glass view for monitoring
all your Azure assets.
Forwarding a large volume of logs to Azure Security Center, may result in additional
subscription cost to you.
If you want to use the Azure CLI to locate all the images available from Palo Alto
Networks, you the need the following details to complete the command (show vm-
image list):
• Publisher: paloaltonetworks
• Offer: vmseries-flex
• SKU: byol, bundle1, bundle 2
• Version: 10.0.0, or latest
• Deploy the VM-Series and Azure Application Gateway Template to support a scale out security
architecture that protects your internet-facing web applications using two VM-Series firewalls
between a pair of (external and internal) Azure load balancers VM-Series and Azure Application
Gateway. This template is currently not available for Azure China.
• Use the ARM template to deploy the VM-Series firewall in to an existing Resource Group, for
example when you want to Set up Active/Passive HA on Azure.
In addition to the ARM templates above that are covered under the Palo Alto Networks official support
policy, Palo Alto Networks provides Community supported templates in the Palo Alto Networks GitHub
repository that allow you to explore the solutions available to jumpstart your journey in to cloud automation
and scale on Azure.
Permissions
The following table lists the minimum built-in roles required and the granular permissions if you would like
to customize the role.
To support Permissions
Azure Monitoring Requires a minimum Role of Reader for Service Principal. Alternatively,
you can add the following custom permissions:
Set Up the Azure Plugin for
Monitoring on Panorama “Microsoft.Compute/virtualMachines/read”,
“Microsoft.Network/networkInterfaces/read”,
“Microsoft.Network/virtualNetworks/read”,
“Microsoft.Network/locations/serviceTags/read”
"Microsoft.Network/loadBalancers/read",
"Microsoft.Network/publicIPPrefixes/write",
"Microsoft.Network/publicIPPrefixes/read",
"Microsoft.Network/publicIPPrefixes/delete",
"Microsoft.Network/publicIPAddresses/write",
"Microsoft.Network/publicIPAddresses/read",
"Microsoft.Network/publicIPAddresses/delete",
"Microsoft.Network/publicIPAddresses/join/action",
"Microsoft.Network/natGateways/write",
"Microsoft.Network/natGateways/read",
"Microsoft.Network/natGateways/delete",
"Microsoft.Network/natGateways/join/action",
"Microsoft.Network/virtualNetworks/read",
"Microsoft.Network/virtualNetworks/write",
"Microsoft.Network/virtualNetworks/delete",
"Microsoft.Network/virtualNetworks/subnets/write",
"Microsoft.Network/virtualNetworks/subnets/read",
"Microsoft.Network/virtualNetworks/subnets/delete",
"Microsoft.Network/virtualNetworks/subnets/join/
action",
"Microsoft.Network/virtualNetworks/
virtualNetworkPeerings/read",
"Microsoft.Network/networkSecurityGroups/write",
"Microsoft.Network/networkSecurityGroups/read",
"Microsoft.Network/networkSecurityGroups/delete",
"Microsoft.Network/networkSecurityGroups/join/
action",
"Microsoft.Network/loadBalancers/write",
"Microsoft.Network/loadBalancers/read",
"Microsoft.Network/loadBalancers/delete",
"Microsoft.Network/loadBalancers/probes/join/action",
"Microsoft.Network/loadBalancers/backendAddressPools/
join/action",
"Microsoft.Network/loadBalancers/
frontendIPConfigurations/read",
"Microsoft.Network/locations/serviceTags/read",
"Microsoft.Network/applicationGateways/read",
"Microsoft.Network/networkInterfaces/read",
"Microsoft.Compute/virtualMachineScaleSets/write",
"Microsoft.Compute/virtualMachineScaleSets/read",
"Microsoft.Compute/virtualMachineScaleSets/delete",
"Microsoft.Compute/virtualMachineScaleSets/
virtualMachines/read",
"Microsoft.Compute/virtualMachines/read",
"Microsoft.Compute/images/read",
"Microsoft.insights/components/write",
"Microsoft.insights/components/read",
"Microsoft.insights/components/delete",
"Microsoft.insights/autoscalesettings/write"
• Inter-Subnet —The VM-Series firewall can front your servers in a VNet and protects against lateral
threats for inter-subnet traffic between applications in a multi-tier architecture.
• Gateway—The VM-Series firewall serves as the VNet gateway to protect Internet-facing deployments in
the Azure Virtual Network (VNet). The VM-Series firewall secures traffic destined to the servers in the
VNet and it also protects against lateral threats for inter-subnet traffic between applications in a multi-
tier architecture.
• GlobalProtect—Use the Azure infrastructure to quickly and easily deploy the VM-Series firewall as
GlobalProtect™ and extend your gateway security policy to remote users and devices, regardless of
location.
You can continue with Deploy the VM-Series Firewall from the Azure Marketplace (Solution Template),
Deploy the VM-Series Firewall on Azure Stack, or Orchestrate a VM-Series Firewall Deployment in Azure.
You can also learn about the VM-Series Firewall Templates on Azure that you can use to deploy the
firewall.
For information on bootstrapping, see Bootstrap the VM-Series Firewall on Azure.
All VM-Series firewall interfaces must be assigned an IPv4 address when deployed in a
public cloud environment. IPv6 addresses are not supported.
If you are using a trial subscription, you may need to open a support request (Help +
Support > New Support Request) to increase the quota of allocated VM cores.
Azure has removed the option to select an existing resource group for Marketplace
solutions that enable multiple network interface controllers (NICs). To deploy
the firewall into an existing resource group, use the ARM template in the GitHub
Repository or use your own custom ARM template.
3. Select the Azure Region in which you are deploying the firewall.
4. Enter a Username for the firewall administrator.
5. Select the Authentication type—Password or SSH Public Key.
You must enable SSH key authentication if you plan to use the firewall in FIPS-
CC operational mode. Although you can deploy the VM-Series firewall using a
username and password, you will be unable to authenticate using the username
and password after changing the operational mode to FIPS-CC. After resetting
to FIPS-CC mode, you must use the SSH key to log in and can then configure
a username and password that you can use for subsequently logging in to the
firewall web interface. For details on creating the SSH key, refer to the Azure
documentation.
6. Enter a Password (up to 31 characters) or copy and paste an SSH public key for securing
administrative access to the firewall.
2. Configure networking.
1. Select an existing Azure Virtual Network (VNet) or create a new one and enter the IP address
space for the VNet. By default, the Classless Inter-Domain Routing (CIDR) IP address is
10.8.0.0/16.
2. Configure the subnets for the network interfaces.
Restrict access to the firewall. Make sure to supply a CIDR block that corresponds
to your dedicated management IP addresses or network. Do not make the allowed
source network range larger than necessary and never configure the allowed
source as 0.0.0.0/0. Verify your IP address before you configure it on the template
to make sure that you do not lock yourself out.
2. Enter a prefix to access the firewall using a DNS name. You must combine the prefix you enter
with the suffix displayed on screen to access the web interface of the firewall. For example:
<yourname><your-region>.cloudapp.azure.com
3. Select latest VM-Series Version.
4. Enter a display name to identify the VM-Series firewall within the resource group.
STEP 4 | Attach a public IP address for the untrust interface of the VM-Series firewall. When you create
a new public IP address, you get one from the block of IP addresses that Microsoft owns, so
you can’t choose a specific one. The maximum number of public IP addresses you can assign to
an interface is based on your Azure subscription.
1. On the Azure portal, select the network interface for which you want to add a public IP address (such
as the eth1 interface).
2. Select IP Configurations > Add and, for Public IP address, select Enabled. Create a new public IP
address or select one that you have available.
3. Verify that you can view the secondary IP address associated with the interface.
1. Using a secure (https) connection from your web browser, log in to the DNS name for the firewall.
2. Enter the usernamepassword that you defined in the parameters file. You will see a certificate
warning but that is OK—continue to the web page.
STEP 7 | Configure the dataplane network interfaces as Layer 3 interfaces on the firewall.
If you are hosting multiple websites or services with different IP addresses and SSL certificates on
a single server, you might need to configure more than one IP address on the VM-Series firewall
interfaces.
1. Select Network > Interfaces > Ethernet.
2. Click ethernet 1/1 and configure as follows:
• Set Interface Type to Layer3 (default).
• On the Config tab, assign the interface to the default router.
• Also on the Config tab, expand the Security Zone drop-down and select New Zone. Define a new
zone called UnTrust, and then click OK.
• On the IPv4 tab, select DHCP Client if you plan to assign only one IP address on the interface
—the firewall will automatically acquire the private IP address assigned in the ARM template. If
you plan to assign more than one IP address, select Static and manually enter the primary and
secondary IP addresses assigned to the interface on the Azure portal.
• Disable (clear) the Automatically create default route to default gateway provided by server to
ensure that traffic handled by this interface does not flow directly to the default gateway in the
VNet.
3. Click ethernet 1/2 and configure as follows:
• Set Interface Type to Layer3 (default).
• Set Security Zone to Trust.
• Set IP address DHCP Client or Static.
• Disable (clear) the Automatically create default route to default gateway provided by serverto
ensure that traffic handled by this interface does not flow directly to the default gateway in the
VNet.
4. Commit your changes and verify that the link state for the interfaces is up.
5. Add a static route on the virtual router of the VM-Series firewall for any networks that the firewall
needs to route.
For example, to add a default route to the destination subnets for the servers that the firewall
secures:
• Select Network > Virtual Router > default >
• Select Static Routes > IPv4, and add the next hop IP address for the destination servers. You
can set x.x.x.1 as the next hop IP address for all traffic (destined to 0.0.0.0/0 from interface
ethernet1/1).
STEP 10 | To publish PAN-OS® metrics to Azure Application Insights, see Enable Azure Application
Insights on the VM-Series Firewall.
All VM-Series firewall interfaces must be assigned an IPv4 address when deployed in a
public cloud environment. IPv6 addresses are not supported.
If you are using a trial subscription, you may need to open a support request (Help +
Support > New Support Request) to increase the quota of allocated VM cores.
You can deploy the VM-Series firewall into a new Resource Group, or an existing
Resource Group that is empty. To deploy the firewall into an existing resource group
that has other resources, use the ARM template in the GitHub Repository or your own
custom ARM template. Ensure that the existing resources match the parameter values
you provide in the ARM template.
1. If you create a new resource group, enter a name for the resource group and select the Azure
China region where you want to deploy the firewall.
2. If you select an existing resource group, select the Azure China region for this resource group, and
select complete deployment.
3. Configure basic settings for the firewall.
1. Enter the storage account name for an existing account or create a new one.
2. Enter the name for the blob storage container to which the firewall vhd mage will be copied and
saved.
3. Enter a DNS name for accessing the Public IP address on the management interface (eth0) of the
firewall. To access the web interface of the firewall, you must combine the prefix you enter with
the suffix, for example <yourDNSname><china_region>.cloudapp.azure.com.
4. Enter a Username for the firewall administrator.
5. Enter a Password for securing administrative access to the firewall.
6. Select the Azure virtual machine tier and size to meet your needs. See Minimum System
Requirements for the VM-Series on Azure.
7. Enter a VmName, which is a display name to identify the VM-Series firewall within the resource
group.
8. Use a PublicIPAddressName to label the firewall management interface within the resource
group. Microsoft Azure binds the DNS name that you defined with this name so that you can
access the management interface on the firewall from the public internet.
9. Enter a VirtualNetworkName to identify your VNet. The default IP Address Prefix for the VNet is
10.0.0.0/16. You can change this to meet your IP addressing needs.
10.Configure the subnets for the network interfaces. If you use an existing VNet, you must have
defined three subnets, one each for the management, trust and untrust interfaces. If you create
a new VNet, verify or change the prefixes for each subnet. The default subnets are 10.0.1.0/24,
10.0.2.0/24, and 10.0.3.0/24. You can allocate these subnets to the management, trust, and
untrust interfaces as you would like.
4. Review the summary, accept the terms of use and privacy policy, and click Immediate deployment to
deploy the firewall. The deployment maybe take 20 minutes and you can use the link on the page to
verify progress.
STEP 4 | Attach a public IP address for the untrust interface of the VM-Series firewall. This allows you
to access the interface from the public internet and is useful for any internet-facing application
or service.
1. On the Azure portal, select the network interface for which you want to add a public IP address. For
example the eth1 interface.
2. Select IP Configurations > Add and for Public IP address, select Enabled. Create a new public IP
address or select one that you have available.
3. Verify that you can view the secondary IP address associated with the interface.
When you attach a secondary IP address to a network interface, the VM-Series firewall
does not automatically acquire the private IP address assigned to the interface. You
will need to manually configure the private IP address using the VM-Series firewall web
interface. See Configure the dataplane network interfaces as Layer 3 interfaces on the
firewall.
Each interface on the VM-Series firewall on Azure can have one dynamic (default) or static private IP
address, and multiple public IP addresses (static or dynamic) associated with it. The maximum number of
public IP addresses you can assign to an interface is based on your Azure subscription. When you create
a new public IP address you get one from the block of IP addresses Microsoft owns, so you can’t choose
a specific one.
STEP 7 | Configure the dataplane network interfaces as Layer 3 interfaces on the firewall.
If you are hosting multiple websites or services with different IP addresses and SSL certificates on
a single server, you might need to configure more than one IP address on the VM-Series firewall
interfaces.
1. Select Network > Interfaces > Ethernet.
2. Click the link for ethernet 1/1 and configure as follows:
• Interface Type: Layer3 (default).
• On the Config tab, assign the interface to the default router.
• On the Config tab, expand the Security Zone drop-down and select New Zone. Define a new
zone called UnTrust, and then click OK.
• On the IPv4 tab, select DHCP Client if you plan to assign only one IP address on the interface.
The private IP address assigned in the ARM template will be automatically acquired. If you plan
to assign more than one IP address select Static and manually enter the primary and secondary IP
addresses assigned to the interface on the Azure portal.
• Clear the Automatically create default route to default gateway provided by server check box.
Disabling this option ensures that traffic handled by this interface does not flow directly to the
default gateway in the VNet.
3. Click the link for ethernet 1/2 and configure as follows:
• Set Interface Type to Layer3 (default).
• Security Zone: Trust
• IP address: Select DHCP Client or Static.
All VM-Series firewall interfaces must be assigned an IPv4 address when deployed in a
public cloud environment. IPv6 addresses are not supported.
Configuration Prerequisites
Complete the following basic tasks on Panorama and Azure.
• Azure
• Create a service principal to enable the plugin to make API calls.
• Plan a CIDR block specifically dedicated to VM-Series firewall Transit VNet. The plugin manages this
CIDR block and uses it to deploy the initial firewall VNet and perform as future upgrades to new
template stacks.
Orchestration Permissions
The is a sample JSON file with permissions for the Template Deployer role. In the AssignableScopes
section, include all relevant subscriptions that must be queried, including the subscription into which the
deployment is deployed and EVERY subscription containing an application VNET that is peered to the VM-
Series firewall VNet where protected resources exist.
{
"Name": "Template Deployment",
"IsCustom": true,
"Description": "Manage template deployments.",
"Actions": [
"Microsoft.Resources/subscriptions/resourcegroups/*",
"Microsoft.Resources/deployments/write",
"Microsoft.Resources/deployments/operationStatuses/read",
"Microsoft.Resources/deployments/read",
"Microsoft.Resources/deployments/delete",
"Microsoft.Network/publicIPPrefixes/write",
"Microsoft.Network/publicIPPrefixes/read",
"Microsoft.Network/publicIPPrefixes/delete",
"Microsoft.Network/publicIPAddresses/write",
"Microsoft.Network/publicIPAddresses/read",
"Microsoft.Network/publicIPAddresses/delete",
"Microsoft.Network/publicIPAddresses/join/action",
"Microsoft.Network/natGateways/write",
"Microsoft.Network/natGateways/read",
"Microsoft.Network/natGateways/delete",
"Microsoft.Network/natGateways/join/action",
"Microsoft.Network/virtualNetworks/read",
"Microsoft.Network/virtualNetworks/write",
"Microsoft.Network/virtualNetworks/delete",
"Microsoft.Network/virtualNetworks/subnets/write",
"Microsoft.Network/virtualNetworks/subnets/read",
"Microsoft.Network/virtualNetworks/subnets/delete",
"Microsoft.Network/virtualNetworks/subnets/join/action",
"Microsoft.Network/virtualNetworks/virtualNetworkPeerings/read",
"Microsoft.Network/networkSecurityGroups/write",
"Microsoft.Network/networkSecurityGroups/read",
"Microsoft.Network/networkSecurityGroups/delete",
"Microsoft.Network/networkSecurityGroups/join/action",
"Microsoft.Network/loadBalancers/write",
"Microsoft.Network/loadBalancers/read",
"Microsoft.Network/loadBalancers/delete",
"Microsoft.Network/loadBalancers/probes/join/action",
"Microsoft.Network/loadBalancers/backendAddressPools/join/action",
"Microsoft.Network/loadBalancers/frontendIPConfigurations/read",
STEP 2 | Create a custom role with the permissions the plugin requires.
See Orchestration Permissions.
1. Log in to the Azure CLI.
az login
2. Create a custom role from the file in Orchestration Permissions.
STEP 3 | Associate the role with Active Directory you created in Step 1. You can use the console or the
CLI.
You must repeat this step in every subscription defined in the assignableScope section
of the custom role in Orchestration Permissions.
All VM-Series firewall interfaces must be assigned an IPv4 address when deployed in a
public cloud environment. IPv6 addresses are not supported.
If you selectYes the plugin asks for the VNET Resource Group, the VNET Name, the Security CIDR,
and the Directory Domain.
• VNET Resource Group—Choose from a list of all resource groups in your selected region.
• VNET Name—Choose from a list of VNETS in your chosen resource group.
• Security CIDR—Enter your CIDR range. The prefix must be smaller than or equal to /22. For
example, 192.168.0.0/22.
• Directory Domain—See Find Your Azure Directory Domain Name. This string is part of the URL
for all resources in the subscription, and it helps the plugin link to your deployments.
STEP 4 | Select Build > Firewall > Basic to configure information common to both Stacks.
For Image Type, select Marketplace Image or Custom Image.
• Image Resource Group—(custom image only) Choose the resource group containing your custom
image. For a custom image, the list displays all resource groups that contain an image from the region
you selected in Step 2.b.
• Image—(custom image only) The dropdown list displays all images in your chosen resource group.
• Software Version—(Marketplace Image) Only valid software versions are displayed. Consult the
Compatibility Matrix for the minimum PAN-OS version.
• Username—The administrator user name for the firewall you create. The name must be legal for both
VM-Series firewall and Azure. Refer to What are the user name requirments when creating a VM?
• Password—The administrator password for the firewall you create. The password must meet the
character and length requirements (31 characters) for both VM-Series firewall and Azure. Refer to
What are the password requirements when creating a VM?.
• Confirm Password—Re-enter your password.
STEP 5 | Select Build > Firewall > Advanced optional default values.
Check Advanced to edit the default values.
• Autoscaling Metric—Default is Data Plane CPU Util Percent.
• Scale In Threshold—Accept the default or define a scale in thresholdt.
• Scale Out Threshold—Accept the default or define a scale in threshold.
• Jumbo Frame—Disabled by default.
Click OK and commit your changes. Refresh the page until you can see the Deploy button, and
click Deploy to launch the deployment. Once the deployment starts, information is written to the
Deployments page.
If Panorama is deployed in a Public Cloud, make sure to add the Firewall Access IP to
the Panorama security group.
See Ports Used for Panorama to determine which ports you need to open to allow traffic.
• Open the link in the Deployment Status column for additional details for each stack.
• Hub-Stack—The Hub stack Public IP matches the Firewall Access IP in the deployment
summary because the NAT gateway is the same for egress traffic from the deployment and the
management traffic from the firewalls.
All outbound and East-West traffic should be routed to the Egress Private IP for inspection. You
can direct traffic to this address if you configured UDRs.
• Inbound-Stack—The Private IP is the address on the Azure internal load balancer that fronts the
firewalls. You can direct traffic to this address if you are configuring UDRs.
• Follow the links to view deployment information and Application Insights on Azure.
• The Deployment details can show Success, Warning, and Failure messages
If the VM-Series firewall used to create your custom image was deployed using a premium
disk type, any VM-Series firewall deployed using the custom image must be deployed using
the same premium disk type. However, if you create an image using firewall deployed with a
standard disk type, you can deploy the firewall using a standard or premium disk type.
STEP 4 | Upgrade the VM-Series Firewall to PAN-OS 10.0.3. Upgrading to PAN-OS 10.0.3 also
upgrades the VM-Series plugin to 2.0.3.
STEP 5 | Access the VM-Series firewall command line interface via SSH using the username and
password provided in the Azure Marketplace template.
STEP 6 | Verify that you VM-Series firewall has the correct PAN-OS, VM-Series plugin, content, and
antivirus versions.
show system info
STEP 8 | Perform a private data reset on the VM-Series firewall. This command requires the firewall to
reboot. You must wait for the VM-Series firewall to reboot complete before continuing; the
reboot can take five to seven minutes.
request system private-data-reset
STEP 11 | After deploying a VM-Series firewall with your custom image, verify your deployment.
1. You should log in to the firewall using the credentials you used previously.
2. After logging in successfully, verify that your firewall is running the correct PAN-OS version and has
the correct content and antivirus versions.
show system info
When you deploy new workloads within your Azure subscription that is enabled for Azure Security Center,
Azure Security Center enables you to secure these workloads in two ways. In one workflow, Azure Security
Center recommends you to deploy a new instance of the VM-Series firewall to secure an internet-facing
application workload. In the other workflow, Azure Security Center discovers VM-Series firewalls (partner
security solutions) that you have deployed within the Azure subscription and you have to then perform
additional configuration to connect the VM-Series firewall to Azure Security Center so that you can view
alerts on the dashboard. See Azure Security Center Integration for details on the integration and the pros
and cons of each workflow:
• Deploy a VM-Series Firewall Based on an Azure Security Center Recommendation
• Connect an Existing VM-Series Firewall From Azure Security Center
STEP 1 | Log in to your Azure portal and access the Security Center dashboard.
STEP 3 | Select Add a Next Generation Firewall, select the workload you want to secure.
STEP 1 | Log in to your Azure portal and access the Security Center dashboard.
STEP 2 | Select Security Solutions to view all available VM-Series firewalls within this Azure
subscription.
STEP 4 | On successfully connecting the VM-Series firewall to Security Center, the VM-Series firewall
displays in the Connected solutions list.
Click View to verify that the firewall is protecting the workload that you need to secure.
STEP 2 | From Panorama, create a template and a device group to push log forwarding settings to the
firewalls that will be forwarding logs to Azure Security Center.
3. Create basic security policy rules in the device group you just created and select Actions to attach
the Log Forwarding profile you created for forwarding logs to Azure Security Center. Until the
firewall has interfaces and zones and a basic security policy, it will not let any traffic through, and
only traffic that matches a security policy rule will be logged (by default).
4. For each rule you create, select Actions and select the Log Forwarding profile that allows the
firewall to forward logs to Azure Security Center.
STEP 4 | Commit your changes to Panorama and push them to the template and device group you
created.
The VM-Series firewall on Azure stack does not have support for bootstrapping, Azure
Application Insights, or the Azure Security Center integration.
Unlike on public Azure, you do not have a solution template to deploy the VM-Series firewall on Azure
Stack. Therefore, you must use an ARM template to deploy the VM-Series firewall. To get started, you can
use the community supported sample ARM template on GitHub, and then develop your own ARM template
for production deployments.
All VM-Series firewall interfaces must be assigned an IPv4 address when deployed in a
public cloud environment. IPv6 addresses are not supported.
• Edit parameters, enter the values for the required parameters and modify the defaults if you need
to, then click OK.
STEP 1 | On the Azure portal, create your Application Insights instance to monitor the firewall and copy
the Instrumentation Key from Configure > Properties.
The firewall needs this key to authenticate to the Application Insights instance and publish metrics to it.
See VM-Series on Azure Service Principal Permissions for the permissions required.
STEP 2 | Enable the firewall to publish metrics to your Application Insights instance.
1. Log in to the VM-Series firewall on Azure.
2. Select Device > VM-Series > Azure.
3. Edit Azure Application Insights and enter the Instrumentation Key you copied earlier.
The default interval for publishing metrics is five minutes. You can change this to vary from 1-60
minutes.
STEP 3 | Verify that you can view the metrics on the Azure Application Insights dashboard.
1. On the Azure portal, select the Application Insights instance, and select Monitoring > Metrics to view
the PAN-OS custom metrics.
2. Select the metric(s) that you want to monitor for trends and trigger alerts. Refer to the Microsoft
Azure documentation for details on exploring metrics on Application Insights.
The Azure plugin is for monitoring Azure resources on the Azure public cloud. Azure
Government or Azure China are not supported.
You configure the Azure plugin on the active Panorama peer only. On commit, the
configuration is synced to the passive Panorama peer. Only the active Panorama
peer polls the Azure subscriptions you have configured for Monitoring.
If you currently have installed a Panorama plugin, the process of installing (or uninstalling)
another plugin requires a Panorama reboot to enable you to commit changes. So, install
additional plugins during a planned maintenance window to allow for a reboot.
STEP 1 | Log in to the Panorama Web Interface, select Panorama > Plugins and click Check Now to get
the list of available plugins.
2. Enter a Name and optionally a Description to identify the group of firewalls to which Panorama
pushes the information it retrieves.
3. Select the Device Groups, which are a group of firewalls or virtual systems, to which Panorama
will push the information (IP address-to-tag mapping) it retrieves from your Azure subscriptions.
The firewalls use the update to determine the most current list of members that constitute
dynamic address groups referenced in policy.
• Because a Monitoring Definition can include only one notify group, make sure to select all
the relevant Device Groups within your notify group. If you want to deregister the tags that
Panorama has pushed to a firewall included in a notify group, you must delete the Monitoring
Definition.
• To register tags to all virtual systems on a firewall enabled for multiple virtual systems, you
must add each virtual system to a separate device group on Panorama and assign the device
groups to the notify group. Panorama will register tags to only one virtual system, if you assign
all the virtual systems to one device group.
4. Verify that monitoring is enabled on the plugin. This setting must be enabled for Panorama to
communicate with the Azure public cloud for Monitoring.
The checkbox for Enable Monitoring is on Panorama > Plugins > Azure > Setup > General.
STEP 5 | Verify that you can view the information on Panorama, and define the match criteria for
Dynamic Address Groups.
Some browser extensions may block API calls between Panorama and Azure which
prevents Panorama from receiving match criteria. If Panorama displays no match criteria
and you are using browser extensions, disable the extensions and Synchronize Dynamic
Objects to populate the tags available to Panorama.
On HA failover, the newly active Panorama attempts to reconnect to the Azure cloud and
retrieve tags for all monitoring definitions. If there is an error with reconnecting even one
monitoring definition, Panorama generates a system log message
When you see this error, you must log in to Panorama and fix the issue, for example
remove an invalid subscription or provide valid credentials, and commit your changes to
enable Panorama to reconnect and retrieve the tags for all monitoring definitions. Even
when Panorama is disconnected from the Azure cloud, the firewalls have the list of all
tags that had been retrieved before failover, and can continue to enforce policy on that list
of IP addresses. Panorama removes all tags associated with the subscription only when
you delete a monitoring definition. As a best practice, to monitor this issue, configure
action-oriented log forwarding to an HTTPS destination from Panorama so that you can
take immediate action.
The maximum length of a tag can be 127 characters. If a tag is longer than 127 characters,
Panorama does not retrieve the tag and register it on the firewalls. Also the tags should not
include non-ASCII special characters such as { or ".
The following attributes are monitored in all Panorama plugin for Azure versions.
Virtual Machine
VM Monitoring Example
VM Name azure-tag.vm-name.web_server1
OS Type azure-tag.os-type.Linux
OS Publisher azure-tag.os-publisher.Canonical
OS Offer azure-tag.os-offer.UbuntuServer
OS SKU azure-tag.os-sku.14.04.5-LTS
Subnet azure-tag.subnet.webtier
VNet azure-tag.vnet.untrustnet
Subscription ID azure.sub-id.93486f84-8de9-44f1-b4a8-f66aed312b64
Load Balancer
Panorama plugin on Azure version 3.0 or later supports tags for each application gateway and standard load
balancer (both public and private IP addresses). Each load balancer has predefined tags for resource group,
load balancer name and region, and supports up to 21 user-defined tags specific to load balancing.
Subnet/VNET
Panorama plugin on Azure version 3.0 or later supports tags for each Subnet and VNET in your subscription.
Each subnet and VNET tag is associated with the full IP CIDR range so you can create policies based
on a CIDR range rather than individual IP addresses. The plugin queries every subnet and VNET in your
subscription and creates tags for them.
All VM-Series firewall interfaces must be assigned an IPv4 address when deployed in a
public cloud environment. IPv6 addresses are not supported.
To enable HA on the VM-Series firewall on Azure, you must create an Azure Active Directory application
and Service Principal that includes the permissions listed in the table below.
• Set up the Active Directory application and a Service Principal to enable programmatic API
access.
• For the firewall to interact with the Azure APIs, you need to create an Azure Active Directory
Service Principal. This Service Principle has the permissions required to authenticate to the Azure
AD and access the resources within your subscription.To complete this set up, you must have
permissions to register an application with your Azure AD tenant, and assign the application to a role
in your subscription. If you don't have the necessary permissions, ask your Azure AD or subscription
administrator to create a Service Principal. See the table above for the required permissions. Copy
the following details for use later in this workflow:
• Client ID—The Application ID associated with the Active Directory (Azure Active Directory > App
registrations, select your application and copy the ID).
• Tenant ID—The Directory ID (Azure Active Directory > Properties > Directory ID on the Azure
portal).
• Azure Subscription ID—The Azure subscription in which you have deployed the firewalls. You
must login to your Azure portal to get this subscription ID.
• Resource Group Name— The resource group name in which you have deployed the firewalls that
you want to configure as HA peers. Both firewalls must be in the same resource group.
• Secret Key—The authentication key associated with the Active Directory application. To log in as
the application, you must provide both the key value and the Application ID.
• Know where to get the templates you need to deploy the VM-Series firewalls within the same
Azure Resource Group.
For an HA configuration, both HA peers must belong to the same Azure Resource Group. If you deploy
the first instance of the firewall from the Azure Marketplace, and must use your custom ARM template
or the Palo Alto Networks sample GitHub template for deploying the second instance of the firewall into
the existing Resource Group. The reason you need a custom template or the Palo Alto Networks sample
template is because Azure does not support the ability to deploy the firewall in to an Resource Group
that is not empty.
• Match the VM Name of VM-Series firewall as shown in the screenshot above with the
Hostname on the firewall web interface. You must add the same name on Device > Setup >
Management, because the hostname of the firewall is used to trigger failover.
HA2 Add a NIC to the Add a NIC to the On the active and
firewall from the Azure firewall from the passive peers, add a
management console. Azure management dedicated HA2 link
console. to enable session
synchronization.
The default interface for
HA1 is the management
interface, and you
can opt to use the
management interface
instead of adding an
additional interface
to the firewall. For
enabling data flow over
the HA2 link, you need
to add an additional
network interface on
the Azure portal and
configure the interface
for HA2 on the firewall.
The authentication key (client secret) associated with the Active Directory application
required for setting up the VM-Series firewall in an HA configuration, is encrypted with VM-
Series plugin version 1.0.4 on the firewall and on Panorama. Because the key is encrypted
in VM-Series plugin version 1.0.4, you must install the same version of the plugin on
Panorama and the managed VM-Series firewalls in order to centrally manage the firewalls
from Panorama.
STEP 1 | Deploy the VM-Series firewall using a solution template and set up the network interfaces for
HA.
1. Add a secondary IP configuration to the untrust interface of the firewall.
The secondary IP configuration for the trust interface requires a static private IP address only. This IP
address moves from the active firewall to the passive firewall on failover so that traffic flows through
from the untrust to the trust interface and to the destination subnets that the firewall secures.
3. Attach a network interface for the HA2 communication between the firewall HA peers.
1. Add a subnet within the virtual network.
2. Create and attach a network interface to the firewall.
4. Set up your route table on Azure.
STEP 3 | Configure the VM-Series plugin to authenticate to the Azure resource group in which you have
deployed the firewall.
Set up the Azure HA configuration on the VM-Series plugin.
To encrypt the client secret, use the VM-Series plugin version 1.0.4 or later. If using Panorama to
manage your firewalls, you must install the VM-Series plugin version 1.0.4 or later.
1. Select Device > VM-Series to enable programmatic access between the firewall plugin and the Azure
resources.
2. Enter the Client ID. The client ID is the Application ID associated with your Azure Active Directory
application.
3. Enter the Subscription ID for the Azure subscription you want to monitor.
4. Enter the Client Secret and re-enter it to confirm.
5. Enter the Tenant ID. The tenant ID is the Directory ID you saved when you set up the Active
Directory application.
6. Click Validate to verify that the keys and IDs you entered are valid, and that VM-Series plugin can
successfully communicate with the Azure resources using the API.
STEP 6 | Set up the passive HA peer within the same Azure Resource Group.
1. Deploy the second instance of the firewall.
• Download the custom template and parameters file from GitHub.
• Log in to the Azure Portal.
• Search for custom template and select Deploy from a custom template.
• Select Build your own template in the editor > Load file.
• Select the azuredeploy.json that you downloaded earlier, and Save.
• Complete the inputs, agree to the terms and Purchase.
Make sure to match the following inputs to that of the firewall instance you have already
deployed— Azure subscription, name of the Resource Group, location of the Resource Group,
name of the existing VNet into which you want to deploy the firewall, VNet CIDR, Subnet names,
Subnet CIDRs, and start the IP address for the management, trust and untrust subnets.
2. Repeat Step 1and Step 2to set up the interfaces and configure the firewall as the passive HA peer.
3. Skip Step 3 and complete Enable HA (Step 5). In Step 4 modify the IP addresses as appropriate for
this passive HA peer.
• On the passive firewall: the state of the local firewall should display passive and the Running
Config should show as synchronized.
• On the active firewall: The state of the local firewall should display active and the Running Config
should show as synchronized.
4. On the passive peer, verify that the VM-Series plugin configuration is now synced.
Select Device > VM-Series and validate that you can view the Azure HA configuration that you had
omitted configuring on the passive peer.
• Set up the Active Directory application and a Service Principal to enable programmatic API
access.
• For the firewall to interact with the Azure APIs, you need to create an Azure Active Directory
Service Principal. This Service Principle has the permissions required to authenticate to the Azure
AD and access the resources within your subscription.To complete this set up, you must have
permissions to register an application with your Azure AD tenant, and assign the application to a role
in your subscription. If you don't have the necessary permissions, ask your Azure AD or subscription
administrator to create a Service Principal. See the table above for the required permissions. Copy
the following details for use later in this workflow:
• Client ID—The Application ID associated with the Active Directory (Azure Active Directory > App
registrations, select your application and copy the ID).
• Tenant ID—The Directory ID (Azure Active Directory > Properties > Directory ID on the Azure
portal).
• Azure Subscription ID—The Azure subscription in which you have deployed the firewalls. You
must login to your Azure portal to get this subscription ID.
• Resource Group Name— The resource group name in which you have deployed the firewalls that
you want to configure as HA peers. Both firewalls must be in the same resource group.
• Know where to get the templates you need to deploy the VM-Series firewalls within the same
Azure Resource Group.
For an HA configuration, both HA peers must belong to the same Azure Resource Group. If you deploy
the first instance of the firewall from the Azure Marketplace, and must use your custom ARM template
or the Palo Alto Networks sample GitHub template for deploying the second instance of the firewall into
the existing Resource Group. The reason you need a custom template or the Palo Alto Networks sample
template is because Azure does not support the ability to deploy the firewall in to an Resource Group
that is not empty.
Copy the deployment information for the first firewall instance. For example:
• Match the VM Name of VM-Series firewall as shown in the screenshot above with the
Hostname on the firewall web interface. You must add the same name on Device > Setup >
Management, because the hostname of the firewall is used to trigger failover.
HA2 Add a NIC to the Add a NIC to the On the active and
firewall from the Azure firewall from the passive peers, add a
management console. Azure management dedicated HA2 link
console. to enable session
synchronization.
The default interface for
HA1 is the management
interface, and you
can opt to use the
management interface
instead of adding an
additional interface
to the firewall. For
enabling data flow over
the HA2 link, you need
to add an additional
network interface on
the Azure portal and
configure the interface
for HA2 on the firewall.
The authentication key (client secret) associated with the Active Directory application
required for setting up the VM-Series firewall in an HA configuration, is encrypted with VM-
Series plugin version 1.0.9 on the firewall and on Panorama. Because the key is encrypted
in VM-Series plugin version 1.0.9, you must install the same version of the plugin on
Panorama and the managed VM-Series firewalls in order to centrally manage the firewalls
from Panorama.
STEP 1 | Deploy the VM-Series firewall using a solution template and set up the network interfaces for
HA.
For securing east west traffic within an Azure VNet, you only need a primary IP address for the trust and
untrust firewall interfaces. When a failover occurs, the UDR changes and the route points to the primary
IP address of the peer that transitions to the active state.
1. Add a Primary IP configuration to the trust interface of the active firewall peer.
In this workflow, this firewall will be designated as the active peer. The active HA peer has a lower
numerical value for device priority that you configure as a part of the HA configuration on the
firewall, and this value indicates a preference for which firewall assumes the role of the active peer.
3. Attach a network interface for the HA2 communication between the firewall HA peers.
1. Add a subnet within the virtual network.
2. Create and attach a network interface to the firewall.
4. Set up your route table on Azure.
Create a route to the Next hop of Primary IP address of the trust and untrust interfaces of the active
firewall peer.
STEP 3 | Configure the VM-Series plugin to authenticate to the Azure resource group in which you have
deployed the firewall.
Set up the Azure HA configuration on the VM-Series plugin.
To encrypt the client secret, use the VM-Series plugin version 1.0.4 or later. If using Panorama to
manage your firewalls, you must install the VM-Series plugin version 1.0.4 or later.
1. Select Device > VM-Series to enable programmatic access between the firewall plugin and the Azure
resources.
STEP 6 | Set up the passive HA peer within the same Azure Resource Group.
1. Deploy the second instance of the firewall.
• Download the custom template and parameters file from GitHub.
• Log in to the Azure Portal.
• Search for custom template and select Deploy from a custom template.
• Select Build your own template in the editor > Load file.
• Select the azuredeploy.json that you downloaded earlier, and Save.
STEP 7 | After you finish configuring both firewalls, verify that the firewalls are paired in active/passive
HA.
1. Access the Dashboard on both firewalls, and view the High Availability widget.
2. On the active firewall, click the Sync to peer link.
3. Confirm that the firewalls are paired and synced, as shown as follows:
• On the passive firewall: the state of the local firewall should display passive and the Running
Config should show as synchronized.
• On the active firewall: The state of the local firewall should display active and the Running Config
should show as synchronized.
4. On the passive peer, verify that the VM-Series plugin configuration is now synced.
Select Device > VM-Series and validate that you can view the Azure HA configuration that you had
omitted configuring on the passive peer.
STEP 1 | Download the two-tier sample ARM template from the GitHub repository.
Download and save the files to a local client: https://github.com/PaloAltoNetworks/azure/tree/master/
two-tier-sample
In Azure China, you must edit the path for the storage account that hosts the VHD
image required to deploy the VM-Series firewall. In the variables section of the
template file, find the parameter called userImageNameURI and replace the value with
the location where you saved the VHD image.
2. Deploy the template in the resource group you created.
-l “<YourAzureLocation>” -d “<GiveASmallDeploymentLabel>”
-f azureDeploy.json -e azureDeploy.parameters.json
3. Check the progress/status of the deployment from the Azure CLI:
“<YourDeploymentLabel>“
If the ProvisioningStateis Failed, you must check for errors on the Azure
portal at Resource Group > Events. Filter for only events in the last one hour, select
the most recent events, and drill down to find the errors.
4. Verify that you have successfully deployed the VM-Series firewall.
1. Select Dashboard > Resource Groups, select the resource group.
2. Select All Settings > Deployments > Deployment History for detailed status.
STEP 4 | Configure the firewall as a VNet gateway to protect your Internet-facing deployment.
1. Log in to the management interface IP address on the firewall.
2. Configure the dataplane network interfaces as Layer 3 interfaces on the firewall (Network >
Interfaces > Ethernet).
3. Add static rules to the virtual router on the firewall. To route traffic through the firewall in this
example, you need three static routes on the firewall (Network > Virtual Routers, select the router
and click Static Routes):
1. Route all outbound traffic through the UnTrust zone, ethernet1/1 to the Azure router at
192.168.1.1.
2. Route all inbound traffic destined to the web server subnet through the Trust zone, ethernet1/2
to the Azure router at 192.168.2.1.
3. Route all inbound traffic destined to the database server subnet through the Trust zone,
ethernet1/2 to the Azure router at 192.168.2.1.
4. Create security policy rules (Policies > Security) to allow inbound and outbound traffic on the
firewall. You also need security policy rules to allow appropriate traffic from the web server subnet to
the database server subnet and vice versa.
5. Commit the changes on the firewall.
6. Verify that the VM-Series firewall is securing traffic (Monitor > Logs > Traffic).
You can use a new or an existing storage account and resource group in which to deploy all the resources
for this solution within an Azure location. It does not provide default values for the resource group name
and storage account name, you must enter a name for them. While you can create a new or use an existing
VNet, the template creates a default VNet named vnet-FW with the CIDR block 192.168.0.0/16, and
allocates five subnets (192.168.1.0/24 - 192.168.5.0/24) for deploying the Azure Application Gateway, the
VM-Series firewalls, the Azure load balancer and the web servers. Each VM-Series firewall is deployed with
three network interfaces—ethernet0/1 in Mgmt subnet (192.168.0.0/24), ethernet1/1 in Untrust subnet
(192.168.1.0/24), and ethernet1/2 in the Trust subnet (192.168.2.0/24).
The template creates a Network Security Group (NSG) that allows inbound traffic from any source IP
address on ports 80,443, and 22. It also deploys the pair of VM-Series firewalls and the web server pair in
their respective Availability Sets to ensure that at least one instance of each is available during a planned
or unplanned maintenance window. Each Availability Set is configured to use three fault domains and five
update domains.
The Azure Application Gateway acts as a reverse-proxy service, which terminates a client connection and
forwards the requests to back-end web servers. The Azure Application Gateway is set up with an HTTP
listener and uses a default health probe to test that the VM-Series firewall IP address (for ethernet1/1) is
healthy and can receive traffic.
The template does not provide an auto-scaling solution; you must plan your capacity needs
and then deploy additional resources to Adapt the Template for your deployment.
The VM-Series firewalls are not configured to receive and secure web traffic destined to the web servers.
Therefore, at a minimum, you must configure the firewall with a static route to send traffic from the VM-
Series firewalls to the default router, configure destination NAT policy to send traffic back to the IP address
of the load balancer, and configure Security policy rules. The NAT policy rule is also required for the firewall
to send responses back to the health probes from the HTTP listener on the Azure Application Gateway.
To assist you with a basic firewall configuration, the GitHub repository includes a sample configuration file
called appgw-sample.xml that you can use to get started.
All VM-Series firewall interfaces must be assigned an IPv4 address when deployed in a
public cloud environment. IPv6 addresses are not supported.
STEP 4 | Log in and configure the other instance of the VM-Series firewall.
See step Configure the VM-Series firewall.
Parameter Description
Subscription The type of Azure subscription you will use to cover the cost of the
resources deployed with the template.
Location Select the Azure location to which you want to deploy the template (no
default).
Network Security Group The network security group limits the source IP addresses from which the
Name VM-Series firewalls and web servers can be accessed.
Default: nsg-mgmt
Network Security Group The source IP addresses that can log in to the management port of the
Inbound Src IP VMs deployed by the template.
The default value 0.0.0.0/0 means you can log into the firewall
management port from any IP address.
Storage Account
Storage Account Name Create new or enter the name of an existing Storage Account (no default).
The name must be globally unique.
Storage Account Type Choose between standard and premium storage and your data replication
needs for local redundancy, geo-redundancy, and read-access geo-
redundancy.
The default option is Locally Redundant Storage (LRS). The other options
are Standard GRS, Premium LRS, and Standard RAGRS.
VNet
App Gateway DNS Name Enter a globally unique DNS name for the Azure Application Gateway.
App Gateway Subnet Name Default name is AppGWSubnet and the subnet prefix is 192.168.3.0/24.
and Prefix
Internal Load Balancer Default name is backendSubnet and the subnet prefix is 192.168.4.0/24.
Subnet Name and Prefix
Backend Vm Size The default size is Standard tier D1 Azure VM. Use the drop-down in the
template to view the other Azure VM options available for the backend
web servers.
Firewalls
Firewall Model Choose from BYOL or PAYG (bundle 1 or bundle 2, each bundle includes
the VM-300 and a set of subscriptions).
Firewall Vm Name and Size The default name for the firewall is VM-Series, and the default size is
Standard tier D3 Azure VM.
Use the drop-down in the template to view the other Azure VM options
available for the VM-Series firewalls
Mgmt Subnet Name and The management subnet for the VM-Series firewalls and the web servers
Prefix deployed in this solution.
Mgmt Public IP Address Enter a hostname to access the management interface on each firewall.
Name The names must be globally unique.
Trusted Subnet Name and The subnet to which eth1/1 on the VM-Series firewall is connected;
Prefix this subnet connects the VM-Series firewall to the Azure Application
gateway. The firewall receives web traffic destined to the web servers on
eth1/1.
Default name is Trust and the subnet prefix is 192.168.2.0/24.
Untrusted Subnet Name The subnet to which eth1/2 on the VM-Series firewall is connected. The
firewall receives return and outbound web traffic on this interface.
Default name is Untrust and the subnet prefix is 192.168.1.0/24. The
name must be globally unique.
Username Enter the username for the administrative account on the VM-Series
firewalls and the web servers.
Authentication Type You must either enter a password for authentication or use an SSH public
key (no default).
Requirements
This solution requires the following components. See the Panorama plugin information in the Compatibility
Matrix for the minimum version requirements.
• VM-Series firewalls.
• Panorama—Your Panorama version must be the same or higher than your VM-Series PAN-OS version.
• Panorama Plugin for Azure.
• A Panorama orchestrated deployment.
• Azure AKS template version 1.0. This template creates an AKS cluster.
You must enable AKS advanced networking (CNI) for the cluster.
• Auto Scaling Infrastructure—The Azure Auto Scaling templates create the messaging infrastructure and
the basic hub and spoke architecture.
• AKS Clusters—The Palo Alto Networks AKS template creates an AKS cluster in a new VNet. Given the
name of the Spoke resource group, the template tags the VNet and AKS cluster with the Spoke resource
group name, so the resource group can be discovered by the Azure Auto Scaling plugin for Panorama.
The Azure plugin for Panorama queries service IP addresses on the Staging ILB to learn about AKS
cluster services.
Only one Spoke firewall scale set can be associated with an AKS Cluster; if you expose
multiple services in a single AKS cluster, they must be protected by the same Spoke.
For each resource group, create a subnet-based address group. In the above diagram,
for example, create an address group for 10.240.0.0/24 (AKS Cluster 1).
• VNet Peering—You must manually configure VNET peering to communicate with other VNets in the
same region.
You can use other automation tools to deploy AKS clusters. If you deploy in an existing
VNet (the Hub Firewall VNet, for example) you must manually configure VNet peering to
User-Defined Routing
You must manually create user-defined routing and routing rules to govern inbound or outbound traffic.
Inbound
In the above diagram, inbound traffic from the Application gateway is driven to the backend pool, and based
on UDR rules, redirected to the Firewall ILB. For example, create a UDR pointing to the VNet subnet so that
the traffic for Kubernetes services is pointed to the firewall ILB.
Outbound
On the Hub firewall set, for each AKS cluster being protected, you must create static routes for the cluster
subnet CIDR, with the next hop being the gateway address of the Hub VNet trust subnet.
All outbound traffic for an AKS cluster is directed to the Hub firewall set with a single UDR rule.
apiVersion: rbac.authorization.k8s.io
kind: ClusterRoleBinding
metadata:
name: default-view
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: view
subjects:
- kind: ServiceAccount
name: default
Add the address group to the top-level policy before you configure VNet peering or User-
Defined Routing.
Prevent Application Disruption when Workload and AKS Cluster VNets Are Peered
If an AKS cluster co-exists with VM workloads that run in separate VNets, and the VNet is peered with both
the workload spoke (Inbound) and the Hub (Outbound), you must create address groups to differentiate the
workloads and the AKS traffic, and add the address group to Top-Level Policy as described above.
If a labelSelector tag is defined for a cluster, the plugin generates the following IP tag:
STEP 1 | On GitHub, go to PaloAltoNetworks/azure-aks and locate the build package in the repository.
STEP 2 | Unzip the build package. Edit the files azuredeploy.json and parameters.json for your own
deployment, and save.
STEP 3 | Issue the following Azure CLI commands to deploy the template.
apiVersion: v1
kind: Service
metadata:
name: azure-vote-front
labels:
service: "azure-vote-front"
tier: "stagingapp"
annotations:
service.beta.kubernetes.io/azure-load-balancer-internal: "true"
spec:
type: LoadBalancer
ports:
- port: 80
selector:
app: azure-vote-front
2. If you have not done so, create AKS cluster authentication before continuing.
3. Deploy your service on your AKS cluster.
For example, you can deploy your application through kubectl:
kubectl apply -f myapplication.yaml
For a sample, see: https://github.com/Azure-Samples/azure-voting-app-redis/blob/master/azure-
vote-all-in-one-redis.yaml
4. Use kubectl to get the service IP for the deployed service.
STEP 5 | Create a UDR rule to point your service to the Firewall ILB behind the Application Gateway.
In Azure, go to your inbound spoke resource group, view the route table and add a new route based
on the destination service IP. In the following screen, the value in the tov1service ADDRESS PREFIX
column is the service IP.
STEP 1 | Select Panorama > Azure > Deployments to view the monitoring definition you created when
you configured the deployment. As shown below, if Auto Program Routes is enabled, the
firewall routes are programmed for you.
The template takes the name of the Spoke resource group as a parameter, and tags the VNet and
AKS cluster with the Spoke resource group name so that it can be discovered by the Panorama plugin
for Azure.
The templates deploy resources in separate VNets. If you manually deploy the AKS
cluster and service in the same VNet as the Spoke firewall set, you must manually create
tags for the spoke resource group name.
If you have service names or tags that are not unique across namespaces, use the
label selector to filter both a tag and a namespace so that you get a unique result.
STEP 1 | Create URL routing rules that redirect web traffic to the appropriate backend pool.
STEP 2 | In the Device Group list, choose the device group for your AKS service.
STEP 3 | Add a Security Policy rule. Fill out the form, and on the Destination tab Add the destination
address or address group.
STEP 1 | In the application deployment environment, create a YAML file for the application or use a file
that already exists. The following is a sample application YAML file:
apiVersion: apps/v1
kind: Deployment
metadata:
name: azure-vote-back
spec:
replicas: 1
selector:
matchLabels:
app: azure-vote-back
template:
metadata:
labels:
app: azure-vote-back
spec:
567
568 VM-SERIES DEPLOYMENT GUIDE | Set Up the VM-Series Firewall on OpenStack
© 2021 Palo Alto Networks, Inc.
VM-Series Deployments in OpenStack
The Heat Orchestration templates provided by Palo Alto Networks allow you to deploy the VM-Series
firewall individually, through service chaining, or dynamically with service scaling.
• Basic Gateway
• Service Chaining and Service Scaling
Basic Gateway
The VM-Series firewall for OpenStack allows you to deploy the VM-Series firewall on the KVM hypervisor
running on a compute node in your OpenStack environment. This solution uses Heat Orchestration
Templates and bootstrapping to deploy the VM-Series firewall and a Linux server. The VM-Series firewall
protects the deployed Linux server by inspecting the traffic going in and out of the server. The sample
bootstrap files allow the VM-Series firewall to boot with basic configuration for handling traffic.
These heat template files and the bootstrap files combine to create two virtual machines, the VM-Series
firewall and Linux server, in a network configuration similar to that shown below.
Service chaining is a Contrail feature that deploys a VM-Series firewall as a service instance in your
OpenStack environment. A service chain is a set of service virtual machines, such as firewalls or load
balancers, and each virtual machine in the service chain is a service instance. Service scaling allows you to
dynamically deploy additional instances of the VM-Series firewall. Using CPU utilization or incoming bytes
per second metrics gathered by Ceilometer, OpenStack deploys or shuts down additional instances of the
VM-Series firewall to meet the current needs of your network.
The VM-Series firewall in OpenStack solution leverages heat orchestration templates to configure and
deploy the components required for service chaining and service scaling. The heat templates provided by
Palo Alto networks create a service template, service instance, and service policy (to direct traffic to the
VM-Series firewall) to deploy two Linux servers and the VM-Series firewall service instance between them.
Component Description
Software See the Compatibility Matrix for details about supported software
versions.
VM-Series Hardware See VM-Series System Requirements for the minimum hardware
Resources requirements for your VM-Series model.
In OpenStack, flavors define the CPU, memory, and storage capacity of
a compute instance. When setting up your Heat template, choose the
compute flavor that meets or exceeds the hardware requirements for the
VM-Series model.
Fuel Master Fuel is a web UI-driven deployment and management tool for OpenStack.
OpenStack Controller This node runs most of the shared OpenStack services, such API and
scheduling. Additionally, the Horizon UI runs on this node.
OpenStack Compute The compute node contains the virtual machines, including the VM-Series
firewall, in the OpenStack deployment. The compute node that houses
the VM-Series must meet the following criteria:
• Instance type OS::Nova::Server
• Allow configuration of at least three interfaces
• Accept the VM-Series qcow2 image
• Accept the compute flavor parameter
Contrail Gateway The Contrail gateway node provides IP connectivity to external networks
from virtual networks. MPLS over GRE tunnels from the virtual machines
terminate at the gateway node, where packets are decapsulated and sent
to their destinations on IP networks.
Ceilometer (OpenStack In the case of the VM-Series firewall for OpenStack, Ceilometer monitors
Telemetry) CPU utilization for service scaling. When CPU utilization meets the
Heat Orchestration Palo Alto Networks provides a sample Heat template for deploying the
Template Files VM-Series firewall. This template is made up of a main template and an
environment template. These files instantiate one VM-Series instance
with one management interface and two data interfaces.
In a basic gateway deployment, the template instantiates a Linux server
with one interface. The interface of the server attaches to the private
network created by the template.
In a service chaining or service scaling deployment, the templates
instantiate two Linux servers with one server attached to each data
interface of the firewall.
VM-Series Firewall The VM-Series firewall bootstrap files consist of a init-cfg.txt file,
Bootstrap Files bootstrap.xml file, and VM-Series auth codes. Along with the Heat
template files, Palo Alto Networks provides a sample init-cfg.txt and
bootstrap.xml files. You must provide your own auth codes to license
your VM-Series firewall and activate any subscriptions. See Bootstrap the
VM-Series Firewall for more information about VM-Series bootstrap files.
File injection is no longer supported beginning with OpenStack Queens; you must use user
data instead.
The table below describes resources that the pan_basic_gw.yaml template file creates and provides the
default value, if applicable.
Resource Description
pan_trust_net A connection to the internal network to which the trust interface of the
firewall and trust interface of the server are attached.
pan_trust_subnet Subnet attached to the trust interface on the firewall (pan_trust_net) and
has a CIDR value of 192.168.100.0/24.
pan_untrust_net Untrust network to which the untrust port of the firewall is attached.
allow_ssh_https_icmp_secgroup Security group that allows TCP on ports 22 and 443 and ICMP traffic.
pan_untrust_port The untrust port of the VM-Series firewall deployed in Layer 3 mode.
The Heat template provides a default IP address of 192.168.200.10 to
this port.
server_trust_port The trust port of the Linux server Layer 3 mode. The Heat template
provides a default IP address of 192.168.100.10 to this port.
If you change this IP address in the heat template, you must change the
IP address in the bootstrap.xml file.
The pan_basic_gw.yaml file references the pan_basic_gw_env.yaml for many of the values needed to create
the resources need to deploy the VM-Series firewall and Linux server. The heat template environment file
contains the following parameters.
Parameter Description
public_network Addresses that the OpenStack cluster and the virtual machines in the cluster
use to communicate with the external or public network. The public network
provides virtual IP addresses for public endpoints, which are used to connect
to OpenStack services APIs. The template does not create the public network;
you must create this before deploying the heat templates. The default value is
public_net.
pan_image This parameter specifies the VM-Series base image used by the Heat
template when deploying the VM-Series firewall. The default value is pa-
vm-7.1.4.
pan_flavor This parameter defines the hardware resources allocated to the VM-Series
firewall. The default value is m1.medium. This value meets the VM-Series on
KVM System Requirements described in the Set Up the VM-Series Firewall on
KVM chapter.
server_image This parameter tells the Heat template which image to use for the Linux
server. The default value is Ubuntu-14.04.
server_flavor This parameter defines the hardware resources allocated to the Linux server.
The default value is m1.small.
server_key The server key is used for accessing the Linux server through ssh. The default
value is server_key. You can change this value by entering a new server key in
the environment file.
The heat template environment file defines the parameters specific to the VM-Series firewall instance
deployed through service chaining or service scaling. The parameters defined in the environment file are
divided into sections described below. There are two versions of the heat templates for service chaining—
vwire and L3— and one for service scaling.
Service chaining requires the heat template files and two bootstrap files to launch the VM-Series firewall
service instance and two Linux servers in the left and right networks.
• Template files—This template defines the resources created to support the VM-Series firewall and two
Linux servers, such as interfaces and IP addresses.
• service_chaining_template_vm.yaml for vwire deployments.
• service_chaining_template_L3.yaml for L3 deployments.
• service_scaling_template.yaml for service scaling deployments.
• Environment file—This environment file defines the environment that the VM-Series firewall and Linux
servers exist in. Many parameters in the template reference the parameters defined in this file, such as
flavor for the VM-Series and the names of the Linux servers.
• service_chaining_env_vm.yaml for vwire deployments.
• service_chaining_env_L3.yaml for L3 deployments.
• service_scaling_env.yaml for service scaling deployments.
• service_instance.yaml—(Service Scaling only) This is a nested heat template that is reference by
Service_Scaling_template.yaml to deploy the service instance. It provides the necessary information to
deploy service instances for scaling events.
• init-cfg.txt—Provides the minimum information required to bootstrap a VM-Series firewall. The init-
cfg.txt provided only includes the operational command to enable DHCP on the firewall management
interface.
• <file_name>_bootstrap.xml—Provides basic configuration for the VM-Series firewall. The bootstrap.xml
file configures the data interfaces. These values must match the corresponding values in the heat
templates files.
For more information about the init-cfg.txt and bootstrap.xml files, see Bootstrap Configuration Files.
The following tables describe the parameters of the environment file.
• Virtual Network
• Virtual Machine
• Service Template
• Service Instance
• IPAM
• Service Policy
• Alarm
route_target Edit this value so route target configuration matches that of your external
gateway.
Virtual Machine
The virtual machine parameters define the left and right Linux servers. The name of the port tuple is defined
here and referenced by the heat template. In Contrail, a port tuple is an ordered set of virtual network
interfaces connected to the same virtual machine. With a port tuple, you can create ports and pass that
information when creating a service instance. The heat template creates the left, right, and management
ports and adds them to the port tuple. The port tuple is then linked to the service instance. When you
launch the service instance using the heat templates, the port tuple maps the service virtual machine to the
virtual machine deployed in OpenStack.
flavor The flavor of the left and right virtual machines. The default value is m1.small.
left_vm_image or The name of the software image for the left and right virtual machines.
right_vm_image or Change this value to match the file name of the image you uploaded.
image
The default is TestVM, which is a default image provided by OpenStack.
left_vm_name and The name of the left and right virtual machines.
right_vm_name
port_tuple_name The name of the port tuple used by the two Linux servers and the VM-Series
firewall.
server_key The server key is used for accessing virtual machines through SSH. The
default value is server_key. You can change this value by entering a new
server key in the environment file.
S_Tmp_version The service template version. The default value is 2. Do not change this
parameter because service template version 2 is required to support port
tuples.
S_Tmp_service_mode Service mode is the network mode used by the VM-Series firewall service
instance. For the L3 network template, the default value is in-network. For
the virtual wire template, the default value is transparent.
S_Tmp_service_type The type of service being deployed by the template. The default value is
firewall and should not be changed when deploying the VM-Series firewall.
S_Tmp_image_name This parameter specifies the VM-Series base image used by the Heat
template when deploying the VM-Series firewall. Edit this parameter to
match the name of the VM-Series firewall image uploaded to your OpenStack
environment.
S_Tmp_flavor This parameter defines the hardware resources allocated to the VM-Series
firewall. The default value is m1.large.
S_Tmp_interface_type_mgmt The parameters define the interface type for management, left, and right
S_Tmp_interface_type_left interfaces.
S_Tmp_interface_type_right
domain The domain where this service template is tied to. The default value is
default-domain.
Service Instance
The service instance portion of the heat template environment file provides the name of the individual
instance deployed by the heat template and service template.
S_Ins_name The service instance name. This is the name of the VM-Series firewall
instance in Contrail.
NetIPam_ip_prefix_mgmt The IP prefix of the management interface on the VM-Series firewall. The
default value is 172.2.0.0.
NetIPam_ip_prefix_len_mgmt
The IP prefix length of the management interface on the VM-Series firewall.
The default value is /24.
NetIPam_ip_prefix_left The IP prefix of the left interface on the VM-Series firewall. The default value
is 10.10.1.0.
NetIPam_ip_prefix_len_leftThe IP prefix length of the left interface on the VM-Series firewall. The
default value is /24.
NetIPam_ip_prefix_right The IP prefix of the right interface on the VM-Series firewall. The default
value is 10.10.2.0.
NetIPam_ip_prefix_len_right
The IP prefix length of the right interface on the VM-Series firewall. The
default value is /24.
NetIPam_addr_from_start_true
This parameter determines how IP addresses are assigned to VMs on the
subnets described above. If true, any new VM takes the next available IP
address. If false, any new VM is assigned an IP address at random. The default
value is true.
Service Policy
The service policy defines the traffic redirection rules and policy that point traffic passing between the left
and right virtual machines to the VM-Series firewall service instance.
policy_name The name of the service policy in Contrail that redirects traffic through
the VM-Series firewall. For the L3 template, the default value is
PAN_SVM_policy-L3. For the virtual wire template, the default value is
PAN_SVM_policy-vw.
simple_action The default action Contrail applies to traffic going to the VM-Series firewall
service instance. The default value is pass because the VM-Series firewall will
apply its own security policy to the traffic.
protocol The protocols allowed by Contrail to pass to the VM-Series firewall. The
default value is any.
src_port_end and Use this parameter to specify source port(s) that should be associated with
src_port_start the policy rule. You can enter a single port, a list of ports separated with
commas, or a range of ports in the form of <port>-<port>.
The default value is -1 in the provided heat templates; meaning any source
port.
direction This parameter defines the direction of traffic that is allowed by Contrail to
pass to the VM-Series firewall. The default value is <> or bidirectional traffic.
dst_port_end and Use this parameter to specify destination port(s) that should be associated
dst_port_start with the policy rule. You can enter a single port, a list of ports separated with
commas, or a range of ports in the form of <port>-<port>.
The default value is -1 in the provided heat templates; meaning any
destination port.
Alarm
The alarm parameters are used in service scaling and are not included in the service chaining environment
files. These parameters define the thresholds used by Contrail to determine when scaling should take place.
This set of parameters is only used the service scaling heat template.
The default time configured under the cooldown parameters is intended to allow the firewall enough time
to boot up. If you change the cooldown values, leave sufficient time for each new firewall instance to boot
up.
Alarm
meter_name The metric monitored by Ceilometer and used by contrail to determine when
an additional VM-Series firewall should be deployed or brought down. The
heat template uses CPU utilization or bytes per second as metrics for service
scaling.
cooldown_initial The amount time Contrail waits before launching a additional service instance
after the initial service instance is launched. The default is 1200 seconds.
cooldown_scaleup The amount of time Contrail waits between launching additional service
instance after the first scale up service instance launch. The default is 1200
seconds.
cooldown_scaledown The amount of time Contrail waits between shutting down additional service
instances after the first scale up service instance shut down. The default is
1200 seconds.
period_high The interval during which the average CPU load is calculated as high before
triggering an alarm. The default value is 300 seconds.
period_low The interval during which the average CPU load is calculated as low before
triggering an alarm. The default value is 300 seconds.
threshold_high The value of CPU utilization in percentage or bytes per second that Contrail
references before launching a scale up event. The default is 40% CPU
utilization or 2800 bytes per second.
threshold_low The value of CPU utilization in percentage or bytes per second that Contrail
references before launching a scale down event. The default is 20% CPU
utilization or 12000 bytes per second.
STEP 3 | Download Ubuntu 14.04 and upload the image to the OpenStack controller.
The Heat template needs an Ubuntu image for launching the Linux server.
1. Download Ubuntu 14.04.
2. Log in to the Horizon UI.
3. Select Project > Compute > Images > Create Image.
4. Name the image Ubuntu 14.04 to match the parameter in the pan_basic_gw_env.yaml file.
5. Set Image Source to Image File.
6. Click Choose File and navigate to your Ubuntu image file.
7. Set the Format to match the file format of your Ubuntu image.
8. Click Create Image.
STEP 4 | Upload the VM-Series for KVM base image to the OpenStack controller.
1. Log in to the Horizon UI.
2. Select Project > Compute > Images > Create Image.
3. Name the image to match the image name in your Heat template.
4. Set Image Source to Image File.
5. Click Choose File and navigate to your VM-Series image file.
6. Set the Format to QCOW2-QEMU Emulator.
7. Click Create Image.
STEP 5 | Upload the bootstrap files. You have two options for passing bootstrapping files to OpenStack
—file injection (personality files) or user data. To pass the bootstrap files using user-data, you
must place the files in a tar ball (.tgz file) and encode that tar ball with base64.
File injection is no longer supported beginning with OpenStack Queens; you must use
user data instead.
• For file injection, upload the init-cfg.txt, bootstrap.xml, and your VM-Series auth codes to your
OpenStack controller or a web server that the OpenStack controller can access.
• If using the --user-data method to pass the bootstrap package to the config-drive, you can use
the following command to create the tar ball and encode the tar ball (.tgz file) with base64:
STEP 6 | Edit the pan_basic_gw.yaml template to point to the bootstrap files and auth codes.
• If you are using personality files, specify the file path or web server address to the location of your
files under personality. Uncomment whichever lines you are not using.
pan_fw_instance:
type: OS::Nova::Server
properties:
image: { get_param: pan_image }
flavor: { get_param: pan_flavor }
networks:
- network: { get_param: mgmt_network }
- port: { get_resource: pan_untrust_port }
- port: { get_resource: pan_trust_port }
user_data_format: RAW
config_drive: true
personality:
/config/init-cfg.txt: {get_file: "/opt/pan_bs/init-cfg.txt"}
# /config/init-cfg.txt: { get_file: "http://web_server_name_ip/
pan_bs/init-cfg.txt" }
/config/bootstrap.xml: {get_file: "/opt/pan_bs/bootstrap.xml"}
# /config/bootstrap.xml: { get_file: "http://web_server_name_ip/
pan_bs/bootstrap.xml" }
/license/authcodes: {get_file: "/opt/pan_bs/authcodes"}
# /license/authcodes: {get_file: "http://web_server_name_ip/pan_bs/
authcodes"}
• If you are using user-data, specify the file path or web server address to the location of your files
under user_data. If you have more than one
pan_fw_instance:
type: OS::Nova::Server
properties:
image: { get_param: pan_image }
flavor: { get_param: pan_flavor }
networks:
- port: { get_resource: mgmt_port }
- port: { get_resource: pan_untrust_port }
- port: { get_resource: pan_trust_port }
user_data_format: RAW
config_drive: true
user_data:
# get_file: http://10.0.2.100/pub/repository/panos/images/
openstack/userdata/boot.tgz
get_file: /home/stack/newhot/bootfiles.tgz
STEP 7 | Edit the pan_basic_gw_env.yaml template environment file to suit your environment. Make
sure that the management and public network values match those that you created in your
OpenStack environment. Set the pan_image to match the name you assigned to the VM-Series
base image file. You can also change your server key here.
STEP 10 | Verify that the VM-Series firewall is bidirectionally inspecting traffic accessing the Linux
server.
1. Log in to the firewall.
2. Select Monitor > Logs > Traffic to view the SSH session.
Deploying the VM-Series firewall through service chaining or service scaling is not supported
on OpenStack Queens.
STEP 3 | Download Ubuntu 14.04 and upload the image to the OpenStack controller.
For service chaining, you can use the default image provided by OpenStack called TestVM. Skip this step
when using TestVM. An Ubuntu image is required for service scaling.
1. Download Ubuntu 14.04.
2. Log in to the Horizon UI.
3. Select Project > Compute > Images > Create Image.
4. Name the image Ubuntu 14.04 to match the parameter in the pan_basic_gw_env.yaml file.
5. Set Image Source to Image File.
6. Click Choose File and navigate to your Ubuntu image file.
7. Set the Format to match the file format of your Ubuntu image.
8. Click Create Image.
A server key is required when using an Ubuntu image. Ensure that the server key is
added to the environment file.
STEP 4 | Upload the VM-Series for KVM base image to the OpenStack controller.
1. Log in to the Horizon UI.
2. Select Project > Compute > Images > Create Image.
3. Name the image to match the image name in your Heat template.
4. Set Image Source to Image File.
5. Click Choose File and navigate to your VM-Series image file.
6. Set the Format to QCOW2-QEMU Emulator.
7. Click Create Image.
STEP 5 | Upload the bootstrap files. The files must be uploaded to the folder structure described here.
The heat template uses this folder structure to locate the bootstrap files.
1. Log in to your OpenStack controller.
2. Create the following folder structure:
STEP 6 | Edit the template environment file to suit your environment. Verify that the image names in
the environment file match the names you gave the files when you uploaded them.
parameters:
# VN config
management_network: 'mgmt_net'
left_vn: 'left_net'
right_vn: 'right_net'
left_vn_fqdn: 'default-domain:admin:left_net'
right_vn_fqdn: 'default-domain:admin:right_net'
route_target: "target:64512:20000"
# VM config
flavor: 'm1.small'
left_vm_image: 'TestVM'
right_vm_image: 'TestVM'
svm_name: 'PAN_SVM_L3'
left_vm_name: 'Left_VM_L3'
right_vm_name: 'Right_VM_L3'
port_tuple_name: 'port_tuple_L3'
#ST Config
S_Tmp_name: PAN_SVM_template_L3
S_Tmp_version: 2
S_Tmp_service_mode: 'in-network'
S_Tmp_service_type: 'firewall'
S_Tmp_image_name: 'PA-VM-8.0.0'
S_Tmp_flavor: 'm1.large'
S_Tmp_interface_type_mgmt: 'management'
S_Tmp_interface_type_left: 'left'
S_Tmp_interface_type_right: 'right'
domain: 'default-domain'
# SI Config
S_Ins_name: PAN_SVM_Instance_L3
S_Ins_fq_name: 'default-domain:admin:PAN_SVM_Instance_L3'
#IPAM Config
NetIPam_ip_prefix_mgmt: '172.2.0.0'
NetIPam_ip_prefix_len_mgmt: 24
NetIPam_ip_prefix_left: '10.10.1.0'
NetIPam_ip_prefix_len_left: 24
NetIPam_ip_prefix_right: '10.10.2.0'
NetIPam_ip_prefix_len_right: 24
NetIPam_addr_from_start_true: true
#Policy Config
policy_name: 'PAN_SVM_policy-L3'
policy_fq_name: 'default-domain:admin:PAN_SVM_policy-L3'
simple_action: 'pass'
protocol: 'any'
src_port_end: -1
src_port_start: -1
direction: '< >'
dst_port_end: -1
dst_port_start: -1
Pan_Svm_instance:
type: OS::Nova::Server
depends_on: [ mgmt_InstanceIp, left_InstanceIp, right_InstanceIp ]
properties:
name: {get_param: svm_name }
image: { get_param: S_Tmp_image_name }
flavor: { get_param: S_Tmp_flavor }
networks:
- port: { get_resource: mgmt_VirtualMachineInterface }
- port: { get_resource: left_VirtualMachineInterface }
- port: { get_resource: right_VirtualMachineInterface }
user_data_format: RAW
config_drive: true
personality:
/config/init-cfg.txt: {get_file: "/root/bootstrap/config/init-
cfg.txt"}
# /config/init-cfg.txt: { get_file: "http://10.4.1.21/op_test/config/
init-cfg.txt" }
/config/bootstrap.xml: {get_file: "/root/bootstrap/config/
Service_Chaining_bootstrap_L3.xml"}
# /config/bootstrap.xml: { get_file: "http://10.4.1.21/op_test/
config/Service_Chaining_bootstrap_L3.xml" }
# /license/authcodes: {get_file: "/root/bootstrap/license/authcodes"}
# /license/authcodes: {get_file: "http://10.4.1.21/op_test/license/
authcodes"}
STEP 11 | Verify that the VM-Series firewall is bidirectionally inspecting traffic between the Linux
servers.
1. Log in to the firewall.
2. Select Monitor > Logs > Traffic to view the SSH session.
587
588 VM-SERIES DEPLOYMENT GUIDE | Set Up the VM-Series Firewall on Google Cloud Platform
© 2021 Palo Alto Networks, Inc.
About the VM-Series Firewall on Google Cloud
Platform
VM-Series firewalls bring next-generation firewall features to the Google® Cloud Platform (GCP™).
To maximize performance, VM-Series firewalls on GCP support the Data Plane Development Kit (DPDK)
libraries, which provide fast packet processing and improve network performance based on specific
combinations of VM-Series firewall licenses and Google Cloud Platform virtual machine (VM) sizes.
• Google Cloud Platform and the VM-Series Firewall
• Minimum System Requirements for the VM-Series Firewall
VM-100 Firewall
VM-300 Firewall
VM-SERIES DEPLOYMENT GUIDE | Set Up the VM-Series Firewall on Google Cloud Platform 589
© 2021 Palo Alto Networks, Inc.
Capacity BYOL Bundles 1 and 2
PAYG Marketplace Recommended Predefined
Machine Type
VM-1000-HV Firewall
590 VM-SERIES DEPLOYMENT GUIDE | Set Up the VM-Series Firewall on Google Cloud Platform
© 2021 Palo Alto Networks, Inc.
Supported Deployments on Google Cloud
Platform
You can deploy the VM-Series firewall on a Google® Compute Engine instance in a network in your
virtual private cloud (VPC). The deployment types are:
• Internet Gateway
• Segmentation Gateway
• Hybrid IPSec VPN
Internet Gateway
The VM-Series firewall secures North/South traffic to and from the internet to protect applications from
known and unknown threats. A Google project can have up to five VPC networks. For a typical example of
an internet gateway, refer to the Google configuration examples.
In public cloud environments, it is a common practice to use a scale-out architecture (see the figure below)
rather than larger, higher performing VMs. This architecture (sometimes called a sandwich deployment)
avoids a single point of failure and enables you to add or remove firewalls as needed.
Segmentation Gateway
A segmentation gateway secures East/West traffic between virtual private clouds (VPCs) to ensure data
protection compliance and application access. The following figure shows a firewall securing both North/
South and East/West traffic.
VM-SERIES DEPLOYMENT GUIDE | Set Up the VM-Series Firewall on Google Cloud Platform 591
© 2021 Palo Alto Networks, Inc.
Hybrid IPSec VPN
The VM-Series firewall serves as an IPSec VPN termination point, which enables secure communications to
and from applications hosted on Google Cloud Platform (GCP).
The deployment in the figure below shows a site-to-site VPN from an on-premises network to a VM-Series
firewall deployed on GCP and an IPSec connection from an on-premises network to a Google Cloud VPN
gateway.
592 VM-SERIES DEPLOYMENT GUIDE | Set Up the VM-Series Firewall on Google Cloud Platform
© 2021 Palo Alto Networks, Inc.
Prepare to Set Up VM-Series Firewalls on
Google Public Cloud
The process to Deploy the VM-Series Firewall from Google Cloud Platform Marketplace requires
preparation tasks.
If you are deploying using the Google Marketplace, you must create your project networks and
subnetworks, and plan networks and IP address assignments for the VM-Series firewall interfaces in
advance. During the deployment, you must choose from existing networks and subnetworks.
Refer to the following topics when planning your deployment:
• General Requirements
• Install the VM-Series Plugin on Panorama
• Install the Panorama Plugin for GCP
• Prepare to Deploy from the GCP Marketplace
General Requirements
The components in this checklist are common to deploying a VM-Series firewall that you manage directly
or with Panorama. Additional requirements apply for Panorama plugin for services such as Stackdriver
monitoring, VM monitoring, auto scaling or securing Kubernetes deployments.
Always consult the Compatibility Matrix for Panorama plugin information for public clouds.This release
requires the following software:
• GCP account—You must have a GCP user account with a linked email address and you must know the
username and password for that email address.
• Google Cloud SDK—If you have not done so, install Google Cloud SDK, which includes Google Cloud
APIs, gcloud and other command line tools. You can use the command line interface to deploy the
firewall template and other templates.
• PAN-OS on VM-Series firewalls on GCP—VM-Series firewalls running a PAN-OS version available from
the Google Marketplace.
• VM-Series firewalls—VM-Series firewalls that you want to manage from Panorama must be deployed
in Google Cloud Platform using a Palo Alto Networks image from the Google Marketplace. Firewalls
must meet the Minimum System Requirements for the VM-Series Firewall.
• VM-Series Licenses—You must license a VM-Series firewall to obtain a serial number. A serial
number is required to add a VM-Series firewall as a Panorama managed device. If you are using the
Panorama plugin for GCP to deploy VM-Series firewalls you must supply a BYOL auth code. The
Google Marketplace handles your service billing, but the firewalls you deploy will directly interface
with the Palo Alto Networks licensing server.
• VM-Series plugin on the firewall—VM-Series firewalls running PAN-OS 9.0 and later include the
VM-Series plugin, which manages integration with public and private clouds. As shown in the
Compatibility Matrix, the VM-Series plugin has a minimum version that corresponds to each PAN-OS
release.
When there is a major PAN-OS upgrade the VM-Series plugin version is automatically upgraded. For
minor releases it is up to you to determine whether a VM-Series plugin upgrade is necessary, and if
so, perform a manual upgrade. See Install the VM-Series Plugin on Panorama.
• Panorama running in Management mode—A Panorama physical or virtual appliance running a PAN-
OS version that is the same or later than the managed firewalls. Virtual instances do not need to be
deployed in GCP.
VM-SERIES DEPLOYMENT GUIDE | Set Up the VM-Series Firewall on Google Cloud Platform 593
© 2021 Palo Alto Networks, Inc.
• You must have a licensed version of Panorama.
• Panorama must have network access to the VPCs in which the VMs you want to manage are
deployed.
• If you intend to manage VMs deployed in GCP, or configure features such as auto scaling, your
PAN-OS and VM-Series plugin versions must meet the Public Cloud requirements to support the
Panorama plugin for GCP.
• VM-Series plugin on Panorama. See Install the VM-Series Plugin on Panorama
• Panorama plugin for GCP version 2.0.0—The GCP plugin manages the interactions required to license,
bootstrap and configure firewalls deployed with the VM Monitoring or Auto Scaling templates. The GCP
plugin, in conjunction with the VM Monitoring or Auto Scaling templates, uses Panorama templates
template stacks, and device groups to program NAT rules that direct traffic to managed VM-Series
firewalls.
See Install the Panorama Plugin for GCP.
You cannot upgrade the Panorama Plugin for GCP from version 1.0.0 to version 2.0.x. If you
have installed version 1.0.0, remove it before installing 2.0.x.
STEP 4 | (Optional) If your Panorama appliances are in a high availability configuration, you must
manually install the same version of the Google plugin on both Panorama peers.
594 VM-SERIES DEPLOYMENT GUIDE | Set Up the VM-Series Firewall on Google Cloud Platform
© 2021 Palo Alto Networks, Inc.
Configure the Google plugin on the active Panorama peer only. On commit, the
configuration syncs to the passive Panorama peer. Only the active Panorama peer polls
Google VMs you have configured for VM Monitoring.
Users in your organization might have IAM permissions or predefined roles that are
more permissive than required. Ensure that you appropriately restrict VM-Series firewall
access.
You can also restrict access with service accounts, as described in Google Authentication Methods.
Monitoring Metric Writer—Required for Stackdriver.
VM-SERIES DEPLOYMENT GUIDE | Set Up the VM-Series Firewall on Google Cloud Platform 595
© 2021 Palo Alto Networks, Inc.
1. Service Accounts—Service Accounts apply to applications or VMs—not to end users. They are
commonly used to control access when you use programs or scripts, or when you access the
firewall from the gcloud command line. If you are using Google Service Accounts to authenticate
instances or applications, you must know the email address for the account(s). Refer to
Creating and Managing Service Account Keys.
Using a service account is necessary if you want to connect to the VM-Series firewall from outside the
project—either from a different project or from the command line. For example, if you want to enable
a physical next generation firewall to monitor your VM-Series firewall, you must save the VM-Series
firewall service account information to a JSON file. In the physical firewall, you upload the file when you
configure the connection.
1. Select IAM & Admin > Service accounts and choose +Create Service Account.
Enter the service account name and description, and click Create.
2. Select a role type from the drop menu, and on the right, select an appropriate access level.
For example, select Project > Editor. You can select multiple roles for a service account. When you
are finished, click Continue.
3. Grant specific users permission to access this service account. Select members from the Permissions
column on the right to give them permission to access the roles in the previous step.
2. SSH Keys—If you deploy the VM-Series firewall from the Marketplace, you must supply one Open SSH
key in RSA format for the Google Compute Engine instance metadata.
At deployment time, you paste the public key into the Marketplace deployment, as described in SSH Key
Pair. After deployment you use the private key to SSH in to the firewall to configure the administrator
account. To add users, see Manage Firewall Administrators.
You can authenticate in several ways:
• Create service accounts for instances—You can create a service account for a specific instance or
instance group, and grant specific permissions, which in turn can be granted to users.
• Use the default service account for your project—If you are using the Google Cloud Platform (GCP™)
Console, then you logged in with your email address and can access a GCE instance based on whatever
permissions or roles the project administrator assigned to your account.
Every Google Compute Engine instance created with the Google Cloud Console or the gcloud command
line tool has a default service account with the name in email address format:
<project-number>[email protected]
To see the service account name for the firewall instance, view the instance details and scroll to the
bottom (refer to the Compute Engine default service account).
The default service account can manage authentication to VMs in the same project as a VM-Series
firewall. Access scopes allow the firewall to initiate API calls to VMs in the Google Cloud project.
• Use IAM permissions and the Google APIs—If you use the Google SDK APIs and gcloud, then you must
call the APIs to authenticate.
• You typically use the Google SDK when you want to manage the firewall from a command line or you
want to run a script to configure the firewall.
• You need to access the Google APIs if a virtual machine you connect to has a custom image with
applications that require Google APIs.
596 VM-SERIES DEPLOYMENT GUIDE | Set Up the VM-Series Firewall on Google Cloud Platform
© 2021 Palo Alto Networks, Inc.
SSH Key Pair
When you deploy the VM-Series firewall from the Google Marketplace you need an SSH key pair to
authenticate with the VM-Series firewall.
Create the key pair according to your key generator documentation. Do not edit the public
key file. Editing risks introducing illegal characters.
The VM-Series firewall manages authentication differently than GCE instances. After deployment, you
first log in with the admin user. The VM-series firewall default user name is accepted only once. After a
successful login you set an administrator username and password for the VM-Series web interface (see
Deploy the VM-Series Firewall from Google Cloud Platform Marketplace).
The Google Marketplace deployment interface SSH key field displays the following placeholder:
admin:ssh-rsa your-SSH-key
admin is the VM-Series firewall Administrator user name required to log in to the firewall for the first
time. You add the admin: prefix into the Marketplace field when you Deploy the VM-Series Firewall from
Google Cloud Platform Marketplace.
You cannot log in to the VM-Series firewall if you do not supply the entire public key, or your key has illegal
characters when you paste the key into the Marketplace SSH key field. When you SSH in to the VM-Series
firewall for the first time, the public key is transferred to the firewall.
If the public key is corrupted, you must delete the deployment and start over. Any networks and
subnetworks remain, but the firewall rules must be recreated.
STEP 1 | Create an SSH key pair and store the SSH Key pair in the default location for your operating
system mentioned in Locating an SSH key.
• Linux or MacOS—Use ssh-keygen to create the key pair in your .ssh directory.
• Windows—Use PuTTYgen to create the key pair.
The content of the Key comment field does not matter to the VM-Series firewall; you can accept
the default (the key creation date) or enter a comment that helps you remember the name of the key
pair. Use the Save private key button to store the private key in your .ssh directory.
VM-SERIES DEPLOYMENT GUIDE | Set Up the VM-Series Firewall on Google Cloud Platform 597
© 2021 Palo Alto Networks, Inc.
STEP 3 | Enter the public key in the SSH key field as detailed below.
1. In the Marketplace SSH key field, delete the placeholder text, and type:
admin:
Make sure there are no extra spaces following the colon.
2. Insert the cursor after admin: and choose Paste as plain text. The key must be on a single line, as
shown below:
3. Move the cursor to the end of the key, add a space, and type: admin
The final contents of the SSH key field must be:
admin:ssh-rsa [KEY] admin
If the key is all on one line and the format is admin:ssh-rsa [KEY] admin, you are finished.
598 VM-SERIES DEPLOYMENT GUIDE | Set Up the VM-Series Firewall on Google Cloud Platform
© 2021 Palo Alto Networks, Inc.
Virtual Private Cloud (VPC) Network Planning
Before you deploy from the Google Market place, make a plan for VPC networks (referred to as networks),
subnetworks (also called subnets), and Google firewall rules. You must create networks and subnetworks
before you start to Deploy the VM-Series Firewall from Google Cloud Platform Marketplace.
The Marketplace deployment page displays only networks and subnetworks that exist when
you start the deployment. If a network is missing, you must exit the deployment, create the
network, and start over.
VPC networks—You must create a custom network specifically for each VM-Series firewall network
interface.
See VM-Series Firewall Licenses for Public Clouds to determine the number of network interfaces
needed based on your VM-Series firewall license. At a minimum, set up the three VPC networks and
subnets required to launch the VM-Series firewall.
A GCP project has a default network with preset configurations and firewall rules; you can delete the
default network, if unused.
By default, there are up to five networks in a project. Your GCP administrator can request additional
networks for your project.
To connect to the management interface you must create a GCP firewall rules that allows access.
You can do this during the deployment if you choose Enable GCP Firewall rule for connections to
Management interface then supply a CIDR block for Source IP in GCP Firewall rule for connections
to Management Interface.
Subnetworks—A compute engine instance can support up to eight Layer 3 interfaces on a single
instance. The Management, Trust, and Untrust interfaces consume three interfaces and you can create
up to five additional dataplane interfaces. Typically the dataplane interfaces represent application
networks.
IP address—You supply IP address ranges when you create interface subnetworks, and you have the
option to enable an external address when you deploy a subnetwork.
• When you create a network subnet, you must specify an IP address range. This range is used for your
internal network, so it cannot overlap with other subnets.
• During deployment, you can choose to enable an external IP address when you create a network
interface. By default, you are given an ephemeral IP address. You cannot supply a reserved static IP
address during the deployment, but you can promote the ephemeral address to a static IP address
after you complete the deployment process (see Promoting an ephemeral external IP address).
All VM-Series firewall interfaces must be assigned an IPv4 address when deployed in a
public cloud environment. IPv6 addresses are not supported.
During the deployment you have the opportunity to name these interfaces.
VM-SERIES DEPLOYMENT GUIDE | Set Up the VM-Series Firewall on Google Cloud Platform 599
© 2021 Palo Alto Networks, Inc.
Interface Order
When you deploy with Marketplace, the order of the network interfaces is predefined. The Management
interface maps to eth0, Untrust to eth1, and Trust to eth2. Marketplace uses this order because mapping
the Management interface to eth0 and the Untrusted interface to eth1 is a requirement if you need to Swap
the Management Interface for load balancing.
Management Interface
The first network interface you add is mapped to eth0 on the firewall and includes the option to enable IP
forwarding. You use this network interface to manage the VM-Series firewall. Typically, this interface has an
external IP address.
600 VM-SERIES DEPLOYMENT GUIDE | Set Up the VM-Series Firewall on Google Cloud Platform
© 2021 Palo Alto Networks, Inc.
Deploy the VM-Series Firewall on Google
Cloud Platform
To deploy the VM-Series firewall using the GCP market place template, you must first create a VPC
network for each interface on the firewall. After you deploy the firewall from the Google Marketplace, you
can log in to the firewall to adjust the configuration to work within your GCP VPC configuration. You can
also enable monitoring so you can collect metrics that enable you to improve resource management or
create Security policy rules that automatically adapt to changes in your application environment.
• Deploy the VM-Series Firewall from Google Cloud Platform Marketplace
• Management Interface Swap for Google Cloud Platform Load Balancing
• Use the VM-Series Firewall CLI to Swap the Management Interface
• Enable Google Stackdriver Monitoring on the VM Series Firewall
• Enable VM Monitoring to Track VM Changes on Google Cloud Platform (GCP)
• Use Dynamic Address Groups to Secure Instances Within the VPC
• Use Custom Templates or the gcloud CLI to Deploy the VM-Series Firewall
All VM-Series firewall interfaces must be assigned an IPv4 address when deployed in a
public cloud environment. IPv6 addresses are not supported.
VM-SERIES DEPLOYMENT GUIDE | Set Up the VM-Series Firewall on Google Cloud Platform 601
© 2021 Palo Alto Networks, Inc.
4. Select one of the VM-Series firewall licensing options.
vmseries-bootstrap-gce-storagebucket=<bucketname>
or
vmseries-bootstrap-gce-storagebucket=<bucketname/directoryname>
If the key is not formatted properly, the VM-Series firewall does not allow you to log in.
You must delete the deployment and start over.
4. Click More to reveal additional metadata options. The options blockProjectKeys, and
enableSerialConsole are properties of the instance; you can change these metadata values after a
successful deployment.
• blockProjectKeys (Optional)—If you Block Project Keys, you can use only the public SSH key you
supply to access the instance.
• enableSerialConsole (Optional)—Interacting with the Serial Console enables you to monitor
instance creation and perform interactive debugging tasks.
602 VM-SERIES DEPLOYMENT GUIDE | Set Up the VM-Series Firewall on Google Cloud Platform
© 2021 Palo Alto Networks, Inc.
STEP 7 | Configure the boot disk.
1. Boot disk type—Select from SSD Persistent disk or Standard Persistent Disk. See Storage Options.
2. Enter the Boot disk size—60GB is the minimum size. You can edit the disk size later but you must
stop the VM to do so.
STEP 11 | Configure additional interfaces. You must enter the number of dataplane interfaces you want
to add; the default is 0 (none). The deployment page always displays fields for five additional
dataplanes numbered 4 through 8.
1. Additional Dataplane interfaces—Enter the number of additional dataplane instances.
If this number is 0 (default), dataplane numbers 4 through 8 are ignored even if you fill
out the interface fields. If, for example, you specify 2 and then fill out information for
three interfaces, only the first two are created.
VM-SERIES DEPLOYMENT GUIDE | Set Up the VM-Series Firewall on Google Cloud Platform 603
© 2021 Palo Alto Networks, Inc.
2. Additional Dataplane # VPC name—Choose an existing network.
3. Dataplane # Subnet name—Choose a subnet that exists.
4. Enable External IP for dataplane # interface—Enable GCP to provide an ephemeral IP address to act
as the external IP address.
STEP 13 | Use Google Cloud Deployment Manager to view and manage your deployment.
STEP 14 | Use the CLI to change the administrator password on the firewall.
1. Log in to the VM-Series firewall from the command line. In your SSH tool, connect to the External IP
for the management interface, and specify the path to your private key.
Windows users: Use PuTTY to connect to the VM-Series firewall and issue command line
instructions. To specify the path to the private key, select Connection > SSH > Auth. In Private key
file for authentication: click Browse to select your private key.
2. Enter configuration mode:
VMfirewall> configure
3. Enter the following command:
VMfirewall# set mgt-config users admin password
4. Enter and confirm a new password for the administrator.
5. Commit your new password:
VMfirewall# commit
6. Return to command mode:
VMfirewall# exit
7. (Optional) If you used a bootstrap file for interface swap, use the following command to view the
interface mapping:
VMfirewall> debug show vm-series interfaces all
604 VM-SERIES DEPLOYMENT GUIDE | Set Up the VM-Series Firewall on Google Cloud Platform
© 2021 Palo Alto Networks, Inc.
All VM-Series firewall interfaces must be assigned an IPv4 address when deployed in a
public cloud environment. IPv6 addresses are not supported.
The firewall can receive dataplane traffic on eth0 if the VM-Series firewall is behind the Google Cloud
Platform internal load balancing interface.
• The VM-Series firewalls secure traffic outbound directly to the internet without requiring a VPN link or a
Direct Connect link back to the corporate network.
• The VM-Series firewall secures an internet-facing application when there is exactly one back-end server,
such as a web server, for each firewall. The VM-Series firewalls and web servers can scale linearly, in
pairs, behind the Google internal load balancing address.
To allow the firewall to send and receive dataplane traffic on eth0 instead of eth1, you must swap the
mapping of the internal load balancing network interface within the firewall so that eth0 maps to ethernet
1/1, and eth1 maps to the MGT interface on the firewall.
If possible, swap the management interface mapping before you configure the firewall and
define policy rules.
Swapping how the interfaces are mapped allows Google Cloud Platform to distribute and route traffic to
healthy instances of the VM-Series firewall located in the same or different zones.
• Pick one method to specify the interface swap setting— the bootstrap configuration file,
the firewall CLI, or the Google Compute Engine instance Metadata field (accessed from
the Google Cloud Console). Using one method ensures predictable behavior on the
firewall.
VM-SERIES DEPLOYMENT GUIDE | Set Up the VM-Series Firewall on Google Cloud Platform 605
© 2021 Palo Alto Networks, Inc.
From the Google Cloud Console you cannot confirm whether you have swapped eth0 and
eth1. After swapping, you must remember that load balancing is on eth0 and the firewall
management interface is eth1 so that you can properly configure Google Cloud Platform
load balancing, and create security policy rules to secure load balancing to one or more
VM-Series firewalls.
• If you configured the VM-Series firewall before swapping, check whether any IP address
changes for eth0 and eth1 impact policy rules.
If you did not specify metadata to swap the management interface (MGT) with the dataplane interface
when you deployed the firewall, you can use the CLI to enable the firewall to receive dataplane traffic on
the primary interface.
STEP 1 | Deploy the VM-Series Firewall from Google Cloud Platform Marketplace.
Before you proceed, verify that the firewall has a minimum of two network interfaces (eth0
and eth1). If you launch the firewall with only one interface, the interface swap command
causes the firewall to boot into maintenance mode.
STEP 2 | On the Google Cloud Console, view the VM instance details to verify the network interface IP
addresses of the eth1 interface and verify that any security rules allow connections (HTTPS
and SSH) to the new management interface (eth1).
STEP 3 | Log in to the VM-Series firewall CLI and enter the following command:
set system setting mgmt-interface-swap enable yes
You can view the default mapping from the command line interface. The output is similar to this:
STEP 4 | Confirm that you want to swap the interface (use the eth1 dataplane interface as the
management interface).
606 VM-SERIES DEPLOYMENT GUIDE | Set Up the VM-Series Firewall on Google Cloud Platform
© 2021 Palo Alto Networks, Inc.
Enable Google Stackdriver Monitoring on the VM Series Firewall
A VM-Series firewall on a Google® Compute Engine instance can publish custom PAN-OS metrics to
Google Stackdriver. These metrics allow you to assess performance and usage patterns so that you can
manage your firewall resources accordingly.
• Google Stackdriver Permissions
• Enable Google Stackdriver
STEP 1 | Push PAN-OS metrics from a VM-Series firewall on a Google Compute Engine instance to
Stackdriver.
1. Log in to the web interface on the VM-Series firewall.
2. Select Device > VM-Series. Under Google Cloud Stackdriver Monitoring Setup, click Edit ( ).
1. Check Publish PAN-OS metrics to Stackdriver.
VM-SERIES DEPLOYMENT GUIDE | Set Up the VM-Series Firewall on Google Cloud Platform 607
© 2021 Palo Alto Networks, Inc.
2. Set the Update Interval (range is 1 - 60 minutes; default is 5). This is the frequency at which the
firewall publishes the metrics to Stackdriver.
3. Click OK.
3. Commit your changes.
Wait until the firewall starts to publish metrics to Stackdriver before you configure alarms for PAN-
OS metrics.
STEP 3 | Configure alerts and actions for PAN-OS metrics on Stackdriver. See Monitoring Quickstart for
Google Compute Engine and Stackdriver Introduction to Alerting.
608 VM-SERIES DEPLOYMENT GUIDE | Set Up the VM-Series Firewall on Google Cloud Platform
© 2021 Palo Alto Networks, Inc.
Enable VM Monitoring to Track VM Changes on Google Cloud
Platform (GCP)
You can enable any firewall that runs PAN-OS 9.0 (virtual or physical) to monitor application workloads
deployed on Google Compute Engine instances. VM Monitoring enables you to monitor a predefined set of
metadata elements or attributes on the VM-Series firewall. In the PAN-OS 9.1 Administrator’s Guide, see
Attributes Monitored on Virtual Machines in Cloud Platforms.
With an awareness of virtual machine adds, moves, and deletes within a Google VPC, you can create
Security policy rules that automatically adapt to changes in your application environment. As you deploy or
move virtual machines, the firewall collects attributes (or metadata elements). You can use this metadata
for policy matching and to define Dynamic Address Groups (see Use Dynamic Address Groups to Secure
Instances Within the VPC).
You can configure up to ten VM information sources on each firewall or on each virtual system on a firewall
capable of multiple virtual systems. Information sources can also be pushed using Panorama templates.
To perform VM monitoring, you must have the IAM role Monitoring Metric Writer.
VM-SERIES DEPLOYMENT GUIDE | Set Up the VM-Series Firewall on Google Cloud Platform 609
© 2021 Palo Alto Networks, Inc.
• (Optional) To change the number of hours before timeout, check Enable timeout when the source
is disconnected and enter the Timeout (hours) before the connection to the monitored source is
closed (range is 2 to 10; default is 2).
If the firewall cannot access the host and the specified limit is reached, the firewall closes the
connection to the source.
• Click OK and Commit your changes.
610 VM-SERIES DEPLOYMENT GUIDE | Set Up the VM-Series Firewall on Google Cloud Platform
© 2021 Palo Alto Networks, Inc.
This workflow assumes that you have deployed the VM-Series firewall, configured some applications on
instances, and enabled Google Stackdriver monitoring.
The labels you create support your strategy for differentiating your resources in ways that are useful to
your Security policy.
5. Click OK.
VM-SERIES DEPLOYMENT GUIDE | Set Up the VM-Series Firewall on Google Cloud Platform 611
© 2021 Palo Alto Networks, Inc.
6. Click Commit.
STEP 5 | Verify that members of the dynamic address group are populated on the firewall.
Policy will be enforced for all IP addresses that belong to this address group and that are displayed here.
1. Select Policies > Security and select the rule.
2. Select Inspect from the drop-down. You can also verify that the match criteria is accurate.
3. Click more to verify that the list of registered IP addresses is displayed.
https://www.googleapis.com/compute/v1/projects/paloaltonetworksgcp-public
/global/images/vmseries-bundle1-810
612 VM-SERIES DEPLOYMENT GUIDE | Set Up the VM-Series Firewall on Google Cloud Platform
© 2021 Palo Alto Networks, Inc.
https://www.googleapis.com/compute/v1/projects/paloaltonetworksgcp-public
/global/images/vmseries-bundle2-810
https://www.googleapis.com/compute/v1/projects/paloaltonetworksgcp-public
/global/images/vmseries-byol-810
VM-SERIES DEPLOYMENT GUIDE | Set Up the VM-Series Firewall on Google Cloud Platform 613
© 2021 Palo Alto Networks, Inc.
VM Monitoring with the Panorama Plugin for
GCP
The Panorama plugin for Google Cloud Platform (GCP) version 2.0.0 enables you to create a VM monitoring
configuration that authenticates with a GCP project and monitors VM-Series firewalls and other VMs
deployed within it. Once you establish a connection to your project, the plugin can retrieve IP-address-to-
tag communication between Panorama and GCP assets. Tags can be predefined attributes, user-defined
labels for VMs, and user-defined network tags (see Review and Create Tags).
The Panorama plugin for GCP retrieves the internal and external IP addresses from running VMs, and
periodically retrieves IP-to-tag mappings from VMs in connected GCP VPCs.
You can use tags to organize VMs into dynamic address groups, and then reference your tags in Security
policy rules that allow or deny traffic to specific VM IP addresses. To consistently enforce Security policy,
you can then push rules to your VM-Series firewalls.
• Configure VM Monitoring with the Panorama Plugin for GCP
614 VM-SERIES DEPLOYMENT GUIDE | Set Up the VM-Series Firewall on Google Cloud Platform
© 2021 Palo Alto Networks, Inc.
GCP plugin for Panorama retrieves pre-defined attributes for Google assets, user defined VM labels, and
user-defined network tags.
Every project has a default service account that was automatically created when the project was created. If
you create a separate service account specifically for VM Monitoring you have greater control of users and
their roles. You can configure up to 100 service accounts per project.
STEP 1 | In the Google Cloud Platform console, select the project you want to monitor.
STEP 2 | Select IAM & Admin > Service accounts and choose +Create Service Account.
Enter the service account name and description, and click Create.
STEP 3 | Select a role type from the drop menu, and on the right, select an appropriate access level.
For example, select Project > Editor. You can select multiple roles for a service account.
When you are finished, click Continue.
STEP 4 | Grant specific users permission to access this service account. Select members from the
Permissions column on the right to give them permission to access the roles in the previous
step.
STEP 5 | (Optional) Click +CREATE KEY to create a credential that allows you to authenticate with the
Google Cloud CLI to access VM-Series firewalls, networks, and other VMs associated with this
service account.
The key is downloaded automatically. Be sure to store it in a secure location. The JSON format for the
generated private key is as follows:
{
"type": "service_account",
"project_id": "gcp-xxx",
"private_key_id": "252e1e7a2e9c84b5d4dbb6195b1de074594b6499",
"private_key": "-----BEGIN PRIVATE KEY-----
\nMIIEvgIBADANBgkqhkiG9w0BAQEFAASCBKgwggSkAgEAAoIBAQDAd0i+RMKCtrsO
\n4KHnzTAPrgoBjRgpjyNcvQmdUqHr\n-----END PRIVATE KEY-----\n",
"client_email": "[email protected]",
"client_id": "108932514695821539229",
"auth_uri": "https://accounts.google.com/o/oauth2/auth",
"token_uri": "https://oauth2.googleapis.com/token",
"auth_provider_x509_cert_url": "https://www.googleapis.com/oauth2/v1/
certs",
"client_x509_cert_url": "https://www.googleapis.com/robot/v1/metadata/
x509/dlp-vm-monit-svc-acct%40gcp-xxx.iam.gserviceaccount.com"
}
VM-SERIES DEPLOYMENT GUIDE | Set Up the VM-Series Firewall on Google Cloud Platform 615
© 2021 Palo Alto Networks, Inc.
• Tags must be associated with a VM. This also applies to networks and subnetworks.
• If there are multiple IP addresses associated with an instance (for example if you tagged the VM-Series
firewall trust and untrust interfaces), Panorama generates multiple sets of tag information.
The total number of tags that the Panorama plugin can retrieve and register depends on the PAN-OS
version Panorama is running and the version of the managed VM-Series firewalls.
Google zone, Google region, VPC name, and Subnet name are used to tag network interfaces on VMs with
multiple interfaces. specific to network interface.
Predefined Attributes
The Google Cloud Platform plugin for Panorama retrieves the following predefined tags from any managed
VM:
• Project ID—For example: google.project-id.myProjectId.
To find your project information in the Google console, select your project, then select IAM & Admin >
Settings.
• Service account—Your service account in the form of an email address. For example: google.svc-
[email protected].
To find your Service account, view the VM instance details.
• VPC name—The name of the VPC network for a managed VM. For example: google.vpc-name.myvnet.
• Subnet name—The name of a subnet you created for a managed VM interface. For example, for the
VM-Series firewall untrust interface, the name of the subnet you created for the untrust interface:
google.subnet-name-untrust.web.
• OS SKU—The operating system you chose when you deployed the managed VM. For example:
google.os-sku.centos-7.
• Google zone—The zone you selected when you deployed the VM. For example: google.zone.us-east1-c.
• Google region—The region containing the zone you selected. For example: google.region.us-east1.
• Instance group name—For example: google.instance-group.myInstanceGroup. To view or create an
instance group in the Google console, select Compute Engine > Instance Group.
User-defined Labels
Panorama uses up to 16 user-defined labels. If you have more than 16 labels, Panorama sorts your user-
defined labels alphabetically and uses the first 16 tags.
Review the Google requirements for label key-value pairs: Keys have a minimum length of 1 character and a
maximum length of 63 characters, and cannot be empty. Values can be empty, and have a maximum length
of 63 characters.
To create or view labels in the GCP console, go to Compute Engine > VM Instances and select Show Info
Panel. Select one or more VMs and in the Info Panel, select Labels. Click +Add a label, add a key and value,
and click Save.
User-defined Network Tags
Panorama uses up to 8 user-defined network tags, If you have more than 8 tags, Panorama sorts your user-
defined labels alphabetically and uses the first 8 tags.
Note that Google limits network tags as follows:
• Maximum 63 characters per tag.
• You can use lowercase letters, numbers, and dashes; a tag must start with a lowercase letter, and end
with a number or a lowercase letter.
616 VM-SERIES DEPLOYMENT GUIDE | Set Up the VM-Series Firewall on Google Cloud Platform
© 2021 Palo Alto Networks, Inc.
To create or view network tags in the GCP console, go to Compute Engine > VM Instances and select an
instance. Edit the instance, and scroll down to Network Tags, enter tags (separated by commas), and Save.
See Configuring Network Tags.
STEP 1 | In Panorama, add the VM-Series firewalls and other VMs associated with your GCP project as
managed devices.
STEP 2 | Add a Device Group and assign managed devices to it. A Device Group is a group of firewalls
or virtual systems that you want to manage as a group.
A VM can be a member of only one Device Group. Plan your Device Groups carefully.
STEP 3 | Add a template. Name the template and accept the default VPC.
STEP 4 | Add a template stack. Add the stack, Add the template you just created, and select your
devices.
Set Up VM Monitoring
STEP 1 | If you have not done so, Install the Panorama Plugin for GCP.
STEP 2 | Log in to the Panorama web interface and select Panorama > Google Cloud Platform.
1. Select Panorama > Google Cloud Platform > Setup > Notify Groups and click Add.
2. Enter a Name to identify the group of firewalls to which Panorama pushes the VM information (IP
address-to-tag mappings) it retrieves.
VM-SERIES DEPLOYMENT GUIDE | Set Up the VM-Series Firewall on Google Cloud Platform 617
© 2021 Palo Alto Networks, Inc.
3. Select the Device Groups to which Panorama will push the VM information (IP address-to-tag
mappings) retrieved from your project. The VM-Series firewalls use the update to determine the
current member list for Dynamic Address Groups referenced in Security policy.
You must use the Panorama web interface. You cannot use the CLI to add a service
account
You can only use a service account for one credential. Do not create multiple
credentials from a single JSON file.
After you add a service account credential, you can validate the credential from your Panorama
command line:
A project can have only one monitoring definition, and a monitoring definition can include
only one notify group.
1. Select Panorama > Google Cloud Platform > Monitoring Definition and click Add.
2. Name the monitoring definition.
3. Enter an optional Description for the project and assets you are monitoring.
4. Select the Service Account credential you created in the previous step.
5. Select a Notify Group.
6. Enable monitoring for the elements associated with this service account.
618 VM-SERIES DEPLOYMENT GUIDE | Set Up the VM-Series Firewall on Google Cloud Platform
© 2021 Palo Alto Networks, Inc.
Verify that the status for the Monitoring Definition displays as Success. If it fails, verify that you entered
the project ID accurately and provided the correct keys and IDs for the service.
STEP 6 | Verify that you can view the VM information on Panorama, and define the match criteria for
Dynamic Address Groups.
On HA failover, the newly active Panorama attempts to reconnect to Google Cloud Platform and
retrieve tags for all monitoring definitions. If there is an error with reconnecting even one monitoring
definition, Panorama generates a system log message:
If you see this error, fix the issue in Panorama. For example, remove an invalid subscription or provide
valid credentials, and commit your changes to enable Panorama to reconnect and retrieve the tags for all
monitoring definitions.
Even when Panorama is disconnected from Google Cloud Platform, the firewalls have the
list of all tags that had been retrieved before failover, and can continue to enforce policy
on that list of IP addresses. When you delete a monitoring definition, Panorama removes
all tags associated with registered VMs. As a best practice, configure action-oriented
log forwarding to an HTTPS destination from Panorama so that you can take immediate
action.
VM-SERIES DEPLOYMENT GUIDE | Set Up the VM-Series Firewall on Google Cloud Platform 619
© 2021 Palo Alto Networks, Inc.
Auto Scaling the VM-Series Firewall on Google
Cloud Platform
The Panorama plugin for Google Cloud Platform (GCP) version 2.0.0 assists you in deploying the VM-Series
firewall in GCP and enables Panorama to manage VM-Series firewalls securing VM monitoring or auto
scaling deployments in GCP. Using Panorama for centralized policy and firewall management increases
operational efficiency in managing and maintaining a distributed network of firewalls.
With Panorama maintaining your GCP managed instance groups you can create application enablement
policies that protect and control the network.
The auto scaling deployment supports using a shared VPC network configuration or VPC network peering
to create a common VPC network in which a host project contains shared VPC networks and the VM-
Series firewalls, and a service project contains a vm-based or container-based application deployment (a
Kubernetes cluster). Palo Alto networks supplies templates to help you deploy the VM-Series firewalls in
the host project and deploy an optional sample application in the service project.
BYOL and PAYG licenses can be used for the VM-Series firewalls. During licensing, VM-Series firewall
instances talk directly to the Palo Alto Networks license server.
If you choose BYOL your deployment can deactivate license instances in response to a scale-down event.
If a VM-Series firewall’s deployment information is configured in the Panorama plugin for GCP and the
firewall is automatically removed, Panorama detects the firewall status and automatically deregisters the
firewall.
• Auto Scaling Components for Google Cloud Platform
• Deploy GCP Auto Scaling Templates
If you previously installed the Panorama plugin for GCP version 1.0.0, remove it before
you install 2.0.X. You cannot upgrade.
Palo Alto Networks Auto Scale templates version 1.0—Palo Alto Networks provides the templates to
deploy VM-Series firewall instances in the host project and configure and deploy a sample application in
a service project. See About the Auto Scaling Templates for more about the templates.
Download the templates from GitHub. The zip file contains separate zip files for the firewall and
application templates.
620 VM-SERIES DEPLOYMENT GUIDE | Set Up the VM-Series Firewall on Google Cloud Platform
© 2021 Palo Alto Networks, Inc.
Prepare to Deploy the Auto Scaling Templates
Complete the following tasks before you deploy the auto scaling templates.
• Prepare a Host Project and Required Service Accounts
• Obtain a Licensing API Key
• Configure the Panorama Plugin for GCP to Secure an Auto Scaling Deployment
• Prepare a VM-Series Firewall Bootstrap Package for Auto Scaling
Prepare a Host Project and Required Service Accounts
You need a host project and a service project to form the shared VPC topology that supports the firewall
and application templates. You can create a new host project or prepare an existing project to act as your
host.
To set up the Shared VPC an organization administrator must grant the host project administrator the
Shared VPC Admin role. The Shared VPC Admin can enable a project to act as a host, and grant the Service
Project Admin role to the service project administrator. Review the GCP documentation on Administrators
and IAM roles.
STEP 1 | In the GCP console, create a GCP project to act as the host. If you want to use an existing
project, skip to the next step.
To create a new project, select your organization or No organization, click New Project and fill in your
project information. Note, this is your only chance to EDIT the project ID.
The Google Cloud SDK must be installed and configured so that you can authenticate
with your host project from the CLI. You will use the command line interface to deploy the
firewall template and the application template, and to attach the service project to the host
project.
STEP 2 | Enable APIs and services required for auto scaling. The required APIs are:
Cloud Pub/Sub API
Cloud Deployment Manager API
Cloud Storage API
Compute Engine API
Google Compute Engine Instance Group Manager API
Google Compute Engine Instance Group Updater API
Google Compute Engine Instance Groups API
Kubernetes Engine API
Stackdriver API
Stackdriver Logging API
Stackdriver Monitoring API
You can enable APIs from the GCP console or the GCP CLI, as shown below.
Enable APIs from the GCP console
1. Select the host project, and from the Navigation menu, select APIs & Services.
2. Search for and view each required API.
3. ENABLE any APIs that do not display the “API enabled” status.
Enable APIs from the CLI
1. In the CLI, view your configuration to ensure that you are in the correct project.
VM-SERIES DEPLOYMENT GUIDE | Set Up the VM-Series Firewall on Google Cloud Platform 621
© 2021 Palo Alto Networks, Inc.
gcloud config list
STEP 3 | Create a service account for deploying the VM-Series firewall, and assign the IAM roles
required for auto scaling a service or a Kubernetes cluster.
When you configure the firewall templates you add the email address for this service account to the
VM-Series firewall .yaml file. Within the host project, the template uses credentials from this service
account to create a host VPC with subnets, deploy VM-Series firewalls in the VPC, configure Stackdriver
custom metrics, create a Pub/Sub topic, and more.
1. In the GCP console select IAM & Admin > Service accounts and select +CREATE SERVICE
ACCOUNT.
Fill in the service account details and click CREATE.
2. Give the service account permission to auto-scale resources in this project.
Select a role type from the drop menu, and on the right, select an appropriate access level. For
example, select Project > Editor. You can select multiple roles for a service account.
Compute Engine > Compute Admin
Compute Engine > Compute Network User
Pub/Sub > Admin
Monitoring > Monitoring Metric Writer
Stackdriver > Stackdriver Accounts Editor
Storage > Storage Admin
(GKE only) Kubernetes > Kubernetes Engine Cluster Admin
(GKE only) Kubernetes > Kubernetes Engine Viewer
622 VM-SERIES DEPLOYMENT GUIDE | Set Up the VM-Series Firewall on Google Cloud Platform
© 2021 Palo Alto Networks, Inc.
Continue when you are finished adding roles.
3. Click +CREATE KEY to create a key for the host service account.
• (Optional) Add email addresses to grant other users or administrators access to this service
account.
• Click JSON to download the private key in JSON form.
• Store the key in a safe location. You will need this key when you Deploy GCP Auto Scaling
Templates.
4. Click DONE.
STEP 4 | Create a service account that a Panorama administrator can use to interact with this host
project.
1. In the GCP console select IAM & Admin > Service accounts and select +CREATE SERVICE
ACCOUNT.
2. Fill in the service account details and click CREATE.
3. Grant service account access.
Select a role type from the drop menu, and on the right, select an appropriate access level. For
example, select Project > Editor. You can select multiple roles for a service account.
Compute Engine > Compute Viewer
Deployment Manager > Viewer
Pub/Sub > Admin
Click CONTINUE.
4. Click +CREATE KEY to create a key for the host service account.
• (Optional) Add email addresses to grant other users or administrators access to this service
account.
• Select JSON to download the private key in JSON form.
• Store the key in a safe location. You will need this key when you Configure the Panorama Plugin
for GCP to Secure an Auto Scaling Deployment.
STEP 5 | (optional) In the CLI, ensure you can communicate with your new host project.
1. Set your project to the host project you just created.
gcloud set project <your-autoscale-host-project-name>
VM-SERIES DEPLOYMENT GUIDE | Set Up the VM-Series Firewall on Google Cloud Platform 623
© 2021 Palo Alto Networks, Inc.
2. Create a configuration for auto scaling. Your new configuration is automatically activated unless you
disable activation.
gcloud config configurations create <CONFIGURATION_NAME> gcloud config
list
STEP 1 | Log in to the Support portal and selectAssets > Licensing API and click Enable. The key is
displayed.
Only a Super User can view the Enable link to generate this key. See How to Enable,
Regenerate, Extend the Licensing API Key.
STEP 3 | From the CLI, SSH in to Panorama and issue the following command, replacing <key> with the
API key you copied from the support portal:
Configure the Panorama Plugin for GCP to Secure an Auto Scaling Deployment
In Panorama, create assets to support the auto scaling firewall deployment.
STEP 1 | Create a template, and a template stack that includes the template, and Commit the changes.
624 VM-SERIES DEPLOYMENT GUIDE | Set Up the VM-Series Firewall on Google Cloud Platform
© 2021 Palo Alto Networks, Inc.
STEP 2 | In the Network context, select either the template or the template stack. Select Virtual
Routers and Add a virtual router.
When the firewall template creates static routes, they are added to this virtual router.
STEP 3 | In the Network context, select the template you created, select Interfaces and Add Interface.
• On the Config tab, select a slot, select the Interface name and select the Layer3 Interface Type. From
the Security Zone menu, select New Zone, name the zone Untrust and click OK.
• On the IPv4 tab enable DHCP Client and Automatically create default route pointing to default
gateway provided by server (enabled by default) and click OK.
VM-SERIES DEPLOYMENT GUIDE | Set Up the VM-Series Firewall on Google Cloud Platform 625
© 2021 Palo Alto Networks, Inc.
STEP 5 | Return to your template stack and the virtual router you created earlier. Place the untrust and
trust interfaces (ethernet1/1 and ethernet1/2) in the virtual router, and click OK.
626 VM-SERIES DEPLOYMENT GUIDE | Set Up the VM-Series Firewall on Google Cloud Platform
© 2021 Palo Alto Networks, Inc.
3. Commit your changes.
STEP 7 | Create a Device Group that references the template or template stack you created in step 1.
This Device Group will contain the VM-Series firewalls you create with the firewall template.
1. Add a security policy that allows web-browsing traffic from Untrust to Trust.
In the Policies context, select the Device Group you just created. Select Security > Pre Rules and Add
the following security policy.
STEP 8 | Set up the GCP service account for the host project.
1. In the Panorama context, expand Google Cloud Platform, select Setup, and click Add.
2. Supply a name and description for the host service account you created in Step 4.
3. Upload the JSON credentials file you created in Step 4.4.
After you add a service account credential, you can validate the credential from your Panorama
command line (you cannot validate from the web interface):
4. Chose the Device Group you created in Step 7, and the Template Stack you created in Step 1.
VM-SERIES DEPLOYMENT GUIDE | Set Up the VM-Series Firewall on Google Cloud Platform 627
© 2021 Palo Alto Networks, Inc.
5. Disable License Management Only to ensure traffic is secured.
STEP 1 | Set up a Google storage bucket with the folders required to Bootstrap the VM-Series Firewall
on Google Cloud Platform. You can use an existing bootstrap package or create a new
bootstrap package, for these folders.
STEP 2 | Edit the values in the sample init-cfg.txt file to customize the file for your environment.
The firewall templates include a sample init-cfg.txt file.
type dhcp-client
628 VM-SERIES DEPLOYMENT GUIDE | Set Up the VM-Series Firewall on Google Cloud Platform
© 2021 Palo Alto Networks, Inc.
Parameter Value Comment
Plugin for GCP to Secure an
Auto Scaling Deployment.
STEP 3 | Upload your edited init-cfg.txt file to the /config folder in your bootstrap package.
STEP 4 | If you are using BYOL, create a text file named authcodes (no extension), add your auth code,
and upload the file to the /license folder.
VM-SERIES DEPLOYMENT GUIDE | Set Up the VM-Series Firewall on Google Cloud Platform 629
© 2021 Palo Alto Networks, Inc.
To configure your load balancer, edit the .yaml file for an external application load balancer (ALB) or
network load balancer (NLB).
• ALB (HTTP External Load Balancer)
To customize an ALB, edit vm-series-fw-alb.yaml.
HTTP external load balancer is a proxy-based load balancer that performs SNAT and DNAT on the
inbound traffic from Internet. The HTTP load balancer is designed to support only the 80 and 8080 TCP
ports.
To support multiple applications using HTTP load balancer in load balancer sandwich architecture, we
can use the GCP HTTP load balancer urlMap and namedPort to map different URLs to different ports in
the load balancer. In turn, the VM-Series firewall can translate the ports to different applications, each
represented by one internal load balancer per application.
• NLB (TCP Load Balancer)
To customize an NLB, edit vm-series-fw-nlb.yaml.
TCP load balancer is a non-proxy based load balancer, which means it doesn't perform NATing on
inbound traffic from the Internet.
TCP load balancer in GCP allows adding multiple frontend IP addresses with an arbitrary port, making it
possible to support multiple applications.
Another advantage of TCP load balancer is that the original client IP address is preserved, which is
desirable for some applications.
Application Template
The application directory provides a sample application. You configure and deploy an internal load balancer
(ILB) to enable your application servers to subscribe to the Pub/Sub service and communicate with your
VM-Series firewalls and the GCP plugin on Panorama.
To customize the application template, edit apps.yaml as described in Deploy the Firewall Template and
Application Template.
All VM-Series firewall interfaces must be assigned an IPv4 address when deployed in a
public cloud environment. IPv6 addresses are not supported.
properties:
region: us-east1
zones:
-us-east1-b
# Do not modify the lb-type field.
lb-type: nlb
cloud-nat: yes
forwarding-rule-port: 80
630 VM-SERIES DEPLOYMENT GUIDE | Set Up the VM-Series Firewall on Google Cloud Platform
© 2021 Palo Alto Networks, Inc.
urlPath-namedPort-maps:
- appName: app1
The autoscaling firewall template requires you to enter the value in single quotes and prepend the
key with admin: followed by a space. This is the same convention used for the Google Marketplace
template, as detailed in SSH Key Pair. For example:
bootstrap-bucket: bootstrap-autoscale
image: vmseries-byol-814
machine-type: n1-standard-4
For the service-account, supply the email address for the host project service account you created
earlier (step 3).
service-account: [email protected]
The fw-instance-tag value will be the managed instance group name in the deployment.
fw-instance-tag: vm-series-fw
Choose one metric for auto scaling. Possible values are: panSessionActive, panSessionUtilization,
DataPlaneCPUUtilizationPct, DataPlanePacketBufferUtilization, or panSessionUtilization.
metric: custom.googleapis.com/VMSeries/panSessionActive
max-size: 2
min-size: 1
target-type: GAUGE
util-target: 100
# Greenfield deployment
mgmt-network-cidr: 172.22.2.0/24
untrust-network-cidr: 172.22.1.0/24
trust-network-cidr: 172.22.3.0/24
mgmt-network-access-source-range:
- 199.167.54.229/32
- 199.167.52.5/32
mgmt-network-access-ports:
- 22
VM-SERIES DEPLOYMENT GUIDE | Set Up the VM-Series Firewall on Google Cloud Platform 631
© 2021 Palo Alto Networks, Inc.
- 443
Take note of the outputs the CLI prints after the deployment—the subnet names, the deployment name,
and the Panorama Pub/Sub topic name. You need these values to configure the Shared VPC and for the
application template deployment.
The firewall deployment name must be configured in the Panorama plugin for GCP auto scaling
definition.
STEP 1 | Enable the service project APIs from the GCP console or the CLI.
The required APIs are:
Cloud Deployment Manager API
Cloud Pub/Sub API
Compute Engine API
Enable APIs from the GCP console
1. Select the service project, and from the Navigation menu, select APIs & Services.
2. Search for and view each required API.
3. ENABLE any APIs that do not display the “API enabled” status.
Enable APIs from the CLI
1. In the CLI, view your configuration to ensure that you are in the correct project.
632 VM-SERIES DEPLOYMENT GUIDE | Set Up the VM-Series Firewall on Google Cloud Platform
© 2021 Palo Alto Networks, Inc.
gcloud services list --enabled
STEP 2 | Make the application project a service project for the host project.
Add the service account from Service/application project administrator as a member in host project with
following roles:
• Compute Network User
• Pub/Sub Admin
STEP 1 | Create a shared VPC using the Trust VPC created when you deployed the firewall template.
Set up a shared VPC for the host (firewall) project:
STEP 3 | If you want to use the sample application template to deploy an application, continue to
Deploy the Application Template.
If you have already deployed an application and you want to secure it in your auto scaling deployment,
go to Manually Onboard an Application to an Existing Auto Scaling Deployment.
If you have deployed a service in a GKE cluster, continue to Onboard a GKE Cluster in a Shared VPC.
STEP 1 | In the host project, peer the Trust VPC network of the Firewall deployment with the
Application VPC.
VM-SERIES DEPLOYMENT GUIDE | Set Up the VM-Series Firewall on Google Cloud Platform 633
© 2021 Palo Alto Networks, Inc.
--peer-network [PEER-NETWORK-NAME] \
[--import-custom-routes] \
[--export-custom-routes]
STEP 2 | In the service project, peer the Trust VPC network of the application deployment with the
Trust VPC network of the Firewall deployment.
STEP 3 | If you want to use the sample application template to deploy an application, continue to
Deploy the Application Template.
If you have already deployed an application and you want to secure it in your auto scaling deployment,
go to Manually Onboard an Application to an Existing Auto Scaling Deployment.
If you have deployed a service in a GKE cluster, continue to Onboard a GKE Cluster in a Peered VPC.
STEP 1 | Create a separate application project (service project) to deploy the application (see Prepare a
Service Project).
STEP 3 | Deploy a new application with the application template and define a label for the named port.
Continue to View the Onboarded Application in the Panorama Plugin for GCP.
STEP 1 | Prepare to add a new named port and URL path to the HTTP external load balancer created
when you deployed the firewall template.
634 VM-SERIES DEPLOYMENT GUIDE | Set Up the VM-Series Firewall on Google Cloud Platform
© 2021 Palo Alto Networks, Inc.
STEP 2 | Update all instance groups named-ports with an additional service name and port values. The
following sample onboards the applications app2 and app3.
STEP 4 | Create a new backend service with the port-name created earlier on the HTTP external load
balancer.
STEP 5 | Edit url-maps and add new path rule. For example:
- paths:
- /app3
- /app3/*service:
https://www.googleapis.com/compute/v1/projects/<project-name>/global/
backendServices/fw-template2-backend-app3
STEP 6 | To secure this application with the VM-Series firewall, manually trigger the pub/sub message
through the gcloud CLI. This sends a message to the topic created in the firewall template.
VM-SERIES DEPLOYMENT GUIDE | Set Up the VM-Series Firewall on Google Cloud Platform 635
© 2021 Palo Alto Networks, Inc.
ilb-port=80,
named-port=81,
network-cidr=172.22.9.0/24,
fw-deployment-name=hj-asg-891ca3,
host-project=gcp-pavmqa,
type=ADD-APP
--message "ADD-APP"
STEP 7 | View the Onboarded Application in the Panorama Plugin for GCP.
STEP 8 | (Optional) To update application attributes, such as ilb-ip, ilb-port, or named-port, issue the
pubsub command:
STEP 9 | (Optional) To stop securing the application, issue the following command:
The GKE cluster name must not exceed 24 characters. This ensures that if you deploy auto
scaling in a peered VPC configuration the static route name does not exceed 31 characters.
636 VM-SERIES DEPLOYMENT GUIDE | Set Up the VM-Series Firewall on Google Cloud Platform
© 2021 Palo Alto Networks, Inc.
Onboard a GKE Cluster in a Shared VPC
To onboard the GKE cluster you must share the Host project Trust network VPC with the Service project.
See Configure the Shared VPC.
For security reasons, only private clusters should be used in an auto scaling deployment.
See Creating a private cluster.
STEP 3 | In the Host project, update secondary ranges in the Trust VPC subnet.
STEP 4 | In the Service project, create a private cluster in the shared VPC.
1. Set the Service project ID.
VM-SERIES DEPLOYMENT GUIDE | Set Up the VM-Series Firewall on Google Cloud Platform 637
© 2021 Palo Alto Networks, Inc.
STEP 5 | Check your current cluster context:
If you created your cluster in the GCP console, generate a kubeconfig entry:
apiVersion: rbac.authorization.k8s.io/v1beta1
kind: ClusterRole
metadata:
name: gke-plugin-role
rules:
- apiGroups:
- ""
resources:
- services
verbs:
- list
kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
name: gke-plugin-role-binding
subjects:
- kind: ServiceAccount
name: [SERVICEACCOUNT_NAME]
namespace: default
roleRef:
kind: ClusterRole
name: gke-plugin-role
apiGroup: rbac.authorization.k8s.io
638 VM-SERIES DEPLOYMENT GUIDE | Set Up the VM-Series Firewall on Google Cloud Platform
© 2021 Palo Alto Networks, Inc.
kubectl apply -f gke_cluster_role_binding.yaml
kubectl config view --minify | grep server | cut -f 2- -d ":" | tr -d " "
STEP 15 | In the Panorama plugin for GCP, add the service account information.
Select Panorama > Google Cloud Platform > Setup.
Name the credential, enter a description, and enter the API server address from step 14, and for GKE
Service Account Credential, upload the JSON file you exported in step 13.
After you add a service account credential, you can validate the credential from your Panorama
command line (you cannot validate from the web interface):
STEP 18 | (Optional) Create and deploy a service template according to Using the Sample GKE Service
Templates, or deploy a GKE service in the GCP console. .
VM-SERIES DEPLOYMENT GUIDE | Set Up the VM-Series Firewall on Google Cloud Platform 639
© 2021 Palo Alto Networks, Inc.
Onboard a GKE Cluster in a Peered VPC
To onboard the GKE cluster you must create and peer the Service VPC with the firewall Trust network in
the Host project, as described in Configure a Peered VPC.
For security reasons, only private clusters should be used in an auto scaling deployment.
See Creating a private cluster.
STEP 3 | Update the service project VPC network with the secondary IP ranges for the pods and
services.
640 VM-SERIES DEPLOYMENT GUIDE | Set Up the VM-Series Firewall on Google Cloud Platform
© 2021 Palo Alto Networks, Inc.
--network [NETWORK_NAME]
--subnetwork [SUBNETWORK_NAME]
--enable-private-nodes
--cluster-secondary-range-name=[PODS_IP_RANGE_NAME]
--services-secondary-range-name=[SERVICE_IP_RANGE_NAME]
--master-ipv4-cidr=[MASTER_IPV4_CIDR]
--enable-master-authorized-networks
--master-authorized-networks=[PANORAMA_MANAGEMENT_IP/32],
[MY_MANAGEMENT_IP/32]
If you created your cluster in the GCP console, generate a kubeconfig entry:
apiVersion: rbac.authorization.k8s.io/v1beta1
kind: ClusterRole
metadata:
name: gke-plugin-role
rules:
- apiGroups:
- ""
resources:
- services
verbs:
- list
kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
name: gke-plugin-role-binding
subjects:
VM-SERIES DEPLOYMENT GUIDE | Set Up the VM-Series Firewall on Google Cloud Platform 641
© 2021 Palo Alto Networks, Inc.
- kind: ServiceAccount
name: [SERVICEACCOUNT_NAME]
namespace: default
roleRef:
kind: ClusterRole
name: gke-plugin-role
apiGroup: rbac.authorization.k8s.io
kubectl config view --minify | grep server | cut -f 2- -d ":" | tr -d " "
STEP 16 | In the Panorama plugin for GCP, add the service account information.
Select Panorama > Google Cloud Platform > Setup.
Name the credential and enter the API server address from Step 15, and upload the JSON file you
exported in Step 14.
After you add a service account credential, you can validate the credential from your Panorama
command line:
642 VM-SERIES DEPLOYMENT GUIDE | Set Up the VM-Series Firewall on Google Cloud Platform
© 2021 Palo Alto Networks, Inc.
STEP 18 | (Optional) In your service project, create and deploy a GKE template according to Using the
Sample GKE Service Templates, or deploy a GKE service use the GCP console. Onboard a
GKE Cluster
The following fields display information obtained from the selected deployment. You specified these
values in the pub/sub message or through GKE cluster service polling.
• Application/GKE Service Name—An application deployment name, or the name of a GKE service.
• Host Project—The name of the host project.
• Cluster/Namespace—A GKE cluster name followed by the namespace for example, mycluster/
namespace9.
• Named Port—The port assigned to the named port for the service.
• ILB IP—The ILB IP address.
• ILB Port—The ILB port number.
For autoscaling an application, this property is ilb-port in apps.yaml.
For securing a GKE cluster, this value is the port number of the GKE cluster, as specified in the
.yaml file you used to deploy the service in your cluster.
• Configuration Programmed— True if a NAT Rule exists, False if not.
• Protected— True when an application is onboarded successfully, or False if onboarding failed. If
False, see the Not Protected Reason column for an explanation.
• Not Protected Reason— If Protected is False, displays the reason the application is not protected.
Some common reasons are:
• Configuration Programmed—True if a NAT Rule exists, False if not.
• Protected—True when an application is onboarded successfully, or False if onboarding failed. If
False, see the Not Protected Reason column for an explanation.
• Not Protected Reason—If Protected is False, displays the reason the application is not protected.
Some common reasons are:
VM-SERIES DEPLOYMENT GUIDE | Set Up the VM-Series Firewall on Google Cloud Platform 643
© 2021 Palo Alto Networks, Inc.
• You deployed a UDP service in the GKE cluster.
• You specified a named port that is already in use. Only one application can listen on a specific
named port.
• You chose the License management only option, so we do not program the configuration.
• No matching label found for GKE services.
• Delicense Inactive VMs—Answer Yes to trigger the delicensing function for inactive VMs.
• Trigger GKE Services Sync—Answer Yes to poll the services running in the clusters, and program the
NAT, address, and service objects, and static routes if necessary. By default, Panorama automatically
polls 10 minutes after the completion of the previous poll.
View the Deployment Status from the CLI
You can use the Panorama CLI to manage deployed applications. The command line actions parallel those
described in View the Onboarded Application in the Panorama Plugin for GCP. In the following commands,
the autoscaling_name is the Firewall Deployment Name you entered in the auto scaling configuration.
• List the onboarded (protected) applications.
In all .yaml files, you customize the resources properties for your deployment. Do not change anything
in the imports or outputs sections.
644 VM-SERIES DEPLOYMENT GUIDE | Set Up the VM-Series Firewall on Google Cloud Platform
© 2021 Palo Alto Networks, Inc.
• Firewall Templates
• Application Template
Firewall Templates
The following sections detail the parameters for the NLB and ALB .yaml files.
• vm-series-fw-nlb.yaml
• vm-series-fw-alb.yaml
vm-series-fw-nlb.yaml
In the vm-series-fw-nlb.yaml template, edit the -properties.
forwarding-rule-port 80 80 or 8080
VM-SERIES DEPLOYMENT GUIDE | Set Up the VM-Series Firewall on Google Cloud Platform 645
© 2021 Palo Alto Networks, Inc.
Parameter Sample Value Comment
If your license permits it, you
can use any machine type in
Minimum System Requirements
for the VM-Series Firewall.
panSessionActive
panSessionUtilization
DataPlaneCPUUtilizationPct
DataPlanePacketBufferUtilization
panSessionUtilization
max-size 2
min-size 1
util-target 100
To deploy the VM-Series firewall you need a dedicated network and subnetwork for the firewall’s
managment, untrust, and trust interfaces. Fill out the information for either a greenfield deployment
(configure the template to create new networks) or brownfield deployment (use existing networks). Be
sure to remove or comment out the network deployment parameters you are not using.
Greenfield Deployment: Enter values to create management, untrust, and trust networks and
subnetworks for the firewall.
mgmt-network-cidr 172.22.2.0/24
untrust-network-cidr 172.22.1.0/24
trust-network-cidr 172.22.3.0/24
mgmt-network-access-source-
range- <permitted-ip-range> mgmt-network-access-source-range
- <permitted-ip-range-1>
- <permitted-ip-range-2>
646 VM-SERIES DEPLOYMENT GUIDE | Set Up the VM-Series Firewall on Google Cloud Platform
© 2021 Palo Alto Networks, Inc.
Parameter Sample Value Comment
mgmt-network-access-ports-
<port-number> mgmt-network-access-
ports
- 22
- 443
mgmt-network my-mgmt-network
mgmt-subnet my-mgmt-subnet
trust-network my-trust-network
trust-subnet my-trust-subnet
untrust-network my-untrust-network
untrust-subnet my-untrust-subnet
vm-series-fw-alb.yaml
In the vm-series-fw-alb.yaml template, edit the -properties.
forwarding-rule-port 80 80
VM-SERIES DEPLOYMENT GUIDE | Set Up the VM-Series Firewall on Google Cloud Platform 647
© 2021 Palo Alto Networks, Inc.
Parameter Sample Value Comment
urlMapPaths:
- '/app2'
- '/app2/*'
service-account The unique service account name for the service project.
panSessionActive
panSessionUtilization
DataPlaneCPUUtilizationPct
DataPlanePacketBufferUtilization
panSessionUtilization
max-size 2
min-size 1
648 VM-SERIES DEPLOYMENT GUIDE | Set Up the VM-Series Firewall on Google Cloud Platform
© 2021 Palo Alto Networks, Inc.
Parameter Sample Value Comment
Greenfield Deployment: Enter values to create management, untrust, and trust networks and
subnetworks for the firewall.
mgmt-network-cidr 192.168.12.0/24
untrust-network-cidr 192.168.11.0/24
trust-network-cidr 192.168.11.0/24
mgmt-network-access-ports- mgmt-network-access-
<port-number> ports- 22- 443
mgmt-network existing-vpc-mgmt
mgmt-subnet existing-subnet-mgmt
trust-network existing-vpc-trust
trust-subnet existing-subnet-trust
untrust-network existing-vpc-untrust
untrust-subnet existing-subnet-untrust
Application Template
apps.yaml
The application template creates the connection between the host project (which contains the VM-Series
firewalls) and the service project, which contains the application or services that the firewall deployment
secures.
fw-deployment-name my-vm-series-firewall-name
VM-SERIES DEPLOYMENT GUIDE | Set Up the VM-Series Firewall on Google Cloud Platform 649
© 2021 Palo Alto Networks, Inc.
Parameter Sample Value Comment
- <list of zones> zones- us-central1-a-
us-central1-b-
us-central1-c-
us-central1-f
650 VM-SERIES DEPLOYMENT GUIDE | Set Up the VM-Series Firewall on Google Cloud Platform
© 2021 Palo Alto Networks, Inc.
Parameter Sample Value Comment
After a deployment, you can delete all services deployed in the service template .yaml file
as follows:
gke_cluster_role.yaml
apiVersion: rbac.authorization.k8s.io/v1beta1
kind: ClusterRole
metadata:
name: gke-plugin-role
rules:
- apiGroups:
VM-SERIES DEPLOYMENT GUIDE | Set Up the VM-Series Firewall on Google Cloud Platform 651
© 2021 Palo Alto Networks, Inc.
- ""
resources:
- services
verbs:
- list
gke_cluster_role_binding.yaml
kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
name: gke-plugin-role-binding
subjects:
- kind: ServiceAccount
name: hj-gke-891ca3-cluster1-sa
namespace: default
roleRef:
kind: ClusterRole
name: gke-plugin-role
apiGroup: rbac.authorization.k8s.io
web-deployment.yaml
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
name: web
namespace: default
spec:
selector:
matchLabels:
run: web
template:
metadata:
labels:
run: web
spec:
containers:
- image: gcr.io/google-samples/hello-app:1.0
imagePullPolicy: IfNotPresent
name: web
ports:
- containerPort: 8080
protocol: TCP
web-service.yaml
apiVersion: v1
kind: Service
metadata:
name: web
namespace: default
annotations:
cloud.google.com/load-balancer-type: "Internal"
labels:
panw-named-port-port1: "80"
spec:
ports:
# the port that this service should serve on
652 VM-SERIES DEPLOYMENT GUIDE | Set Up the VM-Series Firewall on Google Cloud Platform
© 2021 Palo Alto Networks, Inc.
- name: port1
port: 80
protocol: TCP
targetPort: 8080
selector:
run: web
type: LoadBalancer
web-deployment-v2.yaml
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
name: web2
namespace: default
spec:
selector:
matchLabels:
run: web2
template:
metadata:
labels:
run: web2
spec:
containers:
- image: gcr.io/google-samples/hello-app:2.0
imagePullPolicy: IfNotPresent
name: web2
ports:
- containerPort: 8080
protocol: TCP
web-service-v2.yaml
apiVersion: v1
kind: Service
metadata:
name: web2
namespace: default
annotations:
cloud.google.com/load-balancer-type: "Internal"
labels:
panw-named-port-port2: "81"
spec:
ports:
# the port that this service should serve on
- name: port2
port: 81
protocol: TCP
targetPort: 8080
selector:
run: web2
type: LoadBalancer
VM-SERIES DEPLOYMENT GUIDE | Set Up the VM-Series Firewall on Google Cloud Platform 653
© 2021 Palo Alto Networks, Inc.
apiVersion: v1
kind: Service
metadata:
name: carts
annotations:
cloud.google.com/load-balancer-type: "Internal"
labels:
panw-named-port-carts-http: "6082"
panw-named-port-carts-https: "6083"
namespace: default
spec:
type: LoadBalancer
ports:
# the port that this service should serve on
- name: carts-http
protocol: TCP
port: 80
targetPort: 80
- name: carts-https
protocol: TCP
port: 443
targetPort: 443
selector:
name: carts
654 VM-SERIES DEPLOYMENT GUIDE | Set Up the VM-Series Firewall on Google Cloud Platform
Set Up a VM-Series Firewall on a Cisco
ENCS Network
If you have virtualized the traditional appliance-based network infrastructure at your branch
or remote office with the Cisco 5400 Series Enterprise Network Compute System (ENCS)
appliance, you can use Enterprise NFV Infrastructure Software (NFVIS) to deploy the VM-
Series firewall within your Cisco network. The VM-Series firewall serves as a virtual network
function (VNF) with next-generation firewall capabilities to safely enable all applications and
protect your branch or remote office users and network from threats.
The Cisco Enterprise Network Compute System (ENCS) appliances combine with Cisco
Integrated Services Virtual Routers (ISRV) and NFVIS software to support Software-Defined
Branch (SD-Branch) network architectures.
655
656 VM-SERIES DEPLOYMENT GUIDE | Set Up a VM-Series Firewall on a Cisco ENCS Network
© 2021 Palo Alto Networks, Inc.
Plan Your Cisco ENCS Deployment
In your Cisco SD-Branch, deploy the VM-Series Firewall on the Cisco ENCS appliance as a VNF that
provides next generation firewall capabilities to secure your applications and users at the branch office.
You can deploy the firewall in a virtual wire, Layer 2, or Layer 3 deployment, and in high availability
configuration.
To manage the VM-Series firewall, the Panorama appliance can be deployed on premises or in the cloud.
The following topology shows the VM-Series firewall at the branch edge.
The dataplane interfaces of the VM-Series firewall on Cisco ENCS support Virtio mode
only; ENCS SR-IOV and PCI passthrough modes are not supported.
Set up network connections for VM-Series firewall management access. If you are using Panorama,
ensure that Panorama has network access to manage the firewall you deploy.
Python 2.7. Required on your local machine if you are using the command line to convert.
VM-SERIES DEPLOYMENT GUIDE | Set Up a VM-Series Firewall on a Cisco ENCS Network 657
© 2021 Palo Alto Networks, Inc.
qcow2 file (the PAN-OS for VM-Series KVM base image) for PAN-OS 9.1 or later. See Convert a
qcow2 File from the Graphical User Interface, Step 2 or Convert a qcow2 File from the Command
Line Interface, Step 2.
VM-Series firewall capacity license and subscription auth codes that meet your requirements. See
VM-Series Model License Types. You enter auth codes in the NFVIS user interface, or include the
auth codes in the authcodes text file in the conversion folder as described in Convert a qcow2 File
from the Command Line Interface, Step 4.
With PAN-OS 9.1, the VM-Series firewall on Cisco ENCS supports Virtio with DPDK mode enabled
by default.
Panorama hardware or virtual appliance. While you can deploy a single VM-Series firewall in a Cisco SD-
Branch network, it is more common to deploy firewalls in many branches and centrally manage them
with Panorama.
Panorama version 9.1 or later. The version must be the same or higher than the version on your VM-
Series firewall.
A VM auth key generated on Panorama. This key allows the VM-Series firewall to authenticate with
Panorama.
658 VM-SERIES DEPLOYMENT GUIDE | Set Up a VM-Series Firewall on a Cisco ENCS Network
© 2021 Palo Alto Networks, Inc.
Prepare the VM-Series Firewall Image for
Cisco ENCS
You can convert a PAN-OS qcow2 file from the NFVIS graphical user interface or the command line
interface.
• Convert a qcow2 File from the Graphical User Interface
• Convert a qcow2 File from the Command Line Interface
STEP 1 | In NFVIS, go to VM Life Cycle > Image Repository > Image Packaging.
STEP 2 | Fill in the package information as shown below, supplying your own values.
1. Enter a Package Name and VM Version, and for the VM Type, choose Firewall.
2. Enable the Serial Console.
3. Leave the Sriov Driver(s) field blank, as SR-IOV is not supported.
4. Select Local to choose a qcow2 file you uploaded previously, or click Upload Raw Images to upload a
qcow2 file.
• Log in to the Palo Alto Networks Customer Support Portal.
If you have not already done so, create a support account and register the VM-Series firewall.
• Select Support > Software Updates and from the Filter By drop-down, select Pan OS for VM-
Series KVM Base Image, for example, version 9.1.
• Download the qcow2 image.
VM-SERIES DEPLOYMENT GUIDE | Set Up a VM-Series Firewall on a Cisco ENCS Network 659
© 2021 Palo Alto Networks, Inc.
STEP 4 | Set the Advanced Configuration.
STEP 6 | Set values for your resource requirements and choose the Default profile, or add a profile for
the current configuration.
Click Submit to save your package.
660 VM-SERIES DEPLOYMENT GUIDE | Set Up a VM-Series Firewall on a Cisco ENCS Network
© 2021 Palo Alto Networks, Inc.
STEP 7 | Click Register to register the new image.
STEP 1 | Create or choose a folder on your local machine (the conversion folder) in which you want to
download and save the files necessary to convert the VM-Series firewall qcow2 image to the
Cisco ENCS format.
type=static
ip-address=${IP_ADDRESS}
default-gateway=${GATEWAY}
netmask=${NETMASK}
ipv6-address=
ipv6-default-gateway=
hostname=${HOSTNAME}
VM-SERIES DEPLOYMENT GUIDE | Set Up a VM-Series Firewall on a Cisco ENCS Network 661
© 2021 Palo Alto Networks, Inc.
vm-auth-key=${VM_AUTH_KEY}
panorama-server=${PANORAMA_SERVER}
panorama-server-2=
tplname=
dgname=
dns-primary=${DNS_SERVER}
dns-secondary=
op-command-modes=jumbo-frame, mgmt-interface-swap**
dhcp-send-hostname=yes
dhcp-send-client-id=yes
dhcp-accept-server-hostname=yes
dhcp-accept-server-domain=yes
STEP 4 | Create a text file named authcodes (no extension), and enter the auth codes for the VM-Series
firewall capacity and subscriptions. Save the file in the conversion folder.
STEP 5 | Create the following image_properties_template.xml file in the conversion folder, and
supply values for your deployment:
<image_properties>
<vnf_type>FIREWALL</vnf_type>
<name>pafw</name>
<version>9.1.0</version>
<bootup_time>-1</bootup_time>
<root_file_disk_bus>virtio</root_file_disk_bus>
<root_image_disk_format>qcow2</root_image_disk_format>
<vcpu_min>2</vcpu_min>
<vcpu_max>8</vcpu_max>
<memory_mb_min>4096</memory_mb_min>
<memory_mb_max>16384</memory_mb_max>
<vnic_max>8</vnic_max>
<root_disk_gb_min>32</root_disk_gb_min>
<root_disk_gb_max>60</root_disk_gb_max>
<console_type_serial>true</console_type_serial>
<sriov_supported>true</sriov_supported>
<pcie_supported>false</pcie_supported>
<monitoring_supported>false</monitoring_supported>
<monitoring_methods>ICMPPing</monitoring_methods>
<low_latency>true</low_latency>
<privileged_vm>true</privileged_vm>
<custom_property>
<HOSTNAME> </HOSTNAME>
</custom_property>
<custom_property>
<IP_ADDRESS> </IP_ADDRESS>
</custom_property>
<custom_property>
<NETMASK> </NETMASK>
</custom_property>
<custom_property>
<GATEWAY> </GATEWAY>
</custom_property>
<custom_property>
<PANORAMA_SERVER> </PANORAMA_SERVER>
</custom_property>
<custom_property>
<DNS_SERVER> </DNS_SERVER>
</custom_property>
<custom_property>
<VM_AUTH_KEY> </VM_AUTH_KEY>
662 VM-SERIES DEPLOYMENT GUIDE | Set Up a VM-Series Firewall on a Cisco ENCS Network
© 2021 Palo Alto Networks, Inc.
</custom_property>
<default_profile>VM-50</default_profile>
<profiles>
<profile>
<name>VM-50</name>
<description>VM-50 profile</description>
<vcpus>2</vcpus>
<memory_mb>5120</memory_mb>
<root_disk_mb>60000</root_disk_mb>
</profile>
<profile>
<name>VM-100-n-200</name>
<description>VM-100 and VM-200 profile</description>
<vcpus>2</vcpus>
<memory_mb>7168</memory_mb>
<root_disk_mb>60000</root_disk_mb>
</profile>
<profile>
<name>VM-300</name>
<description>VM-300 profile</description>
<vcpus>2</vcpus>
<memory_mb>9216</memory_mb>
<root_disk_mb>60000</root_disk_mb>
</profile>
<profile>
<name>VM-1000-HV</name>
<description>VM-1000-HV profile</description>
<vcpus>4</vcpus>
<memory_mb>9216</memory_mb>
<root_disk_mb>60000</root_disk_mb>
</profile>
<profile>
<name>VM-500</name>
<description>VM-500 profile</description>
<vcpus>4</vcpus>
<memory_mb>16384</memory_mb>
<root_disk_mb>60000</root_disk_mb>
</profile>
</profiles>
<cdrom>true</cdrom>
<bootstrap_file_1>/config/init-cfg.txt</bootstrap_file_1>
<bootstrap_file_2>/config/bootstrap.xml</bootstrap_file_2>
<bootstrap_file_3>/license/authcodes</bootstrap_file_3>
</image_properties>
STEP 7 | In the conversion folder that contains the qcow2, the init-config.txt and the authcodes
file, run the nfvpt.py script. See the nfvpt.py image packaging utility documentation.
VM-SERIES DEPLOYMENT GUIDE | Set Up a VM-Series Firewall on a Cisco ENCS Network 663
© 2021 Palo Alto Networks, Inc.
The following sample creates the image file Palo-Alto-9.1.0, and a VM-100 profile. Options are space-
separated (the sample shows options on separate lines for clarity only) and custom options are key-value
pairs with a colon separator.
664 VM-SERIES DEPLOYMENT GUIDE | Set Up a VM-Series Firewall on a Cisco ENCS Network
© 2021 Palo Alto Networks, Inc.
Deploy the VM-Series Firewall on Cisco ENCS
Before you begin to deploy the firewall, make sure that you have created network connections for
management access to the VM-Series firewall. If you are using Panorama, ensure that Panorama has
management connectivity to the firewall.
VM-SERIES DEPLOYMENT GUIDE | Set Up a VM-Series Firewall on a Cisco ENCS Network 665
© 2021 Palo Alto Networks, Inc.
4. Click ethernet 1/1 and configure as follows:
• Set Interface Type to Layer3.
• On the Config tab, assign the interface to the default router.
• Also on the Config tab, expand the Security Zone drop-down and select New Zone. Define a new
zone called UnTrust for example, and then click OK.
• On the IPv4 tab, select DHCP Client or Static. If you choose static, enter the IP address.
STEP 3 | Configure Security policies to safely enable applications and users on your network.
If using Panorama, the following steps show you how to use device groups to centrally manage policy
rules for your managed firewalls.
1. Add a device group and assign the managed firewalls to your device group.
666 VM-SERIES DEPLOYMENT GUIDE | Set Up a VM-Series Firewall on a Cisco ENCS Network
© 2021 Palo Alto Networks, Inc.
2. Configure the security policies for the device group.
STEP 4 | Verify that the VM-Series firewall is securing traffic on your network.
VM-SERIES DEPLOYMENT GUIDE | Set Up a VM-Series Firewall on a Cisco ENCS Network 667
© 2021 Palo Alto Networks, Inc.
668 VM-SERIES DEPLOYMENT GUIDE | Set Up a VM-Series Firewall on a Cisco ENCS Network
Set up the VM-Series Firewall on Oracle
Cloud Infrastructure
Deploy the VM-Series firewall on Oracle Cloud Infrastructure (OCI) cloud. With the VM-Series
on OCI, you can protect and segment your workloads, prevent advanced threats, and improve
visibility into your applications as you move to the cloud.
OCI is a public cloud computing service that enables you to run your applications in a highly-
available, hosted environment offered by Oracle. You can deploy the VM-Series firewall to
secure your applications and services running your OCI environment.
669
670 VM-SERIES DEPLOYMENT GUIDE | Set up the VM-Series Firewall on Oracle Cloud Infrastructure
© 2021 Palo Alto Networks, Inc.
OCI Shape Types
The VM-Series firewalls support the following OCI VM shapes. See Oracle Cloud Infrastructure
documentation for more information about VM shapes.
VM-100 VM.Standard2.4
VM-300 VM.Standard2.4
VM-500 VM.Standard2.8
VM-700 VM.Standard2.16
You can deploy the VM-Series firewall on an OCI instance with more resources than the minimum VM-
Series System Requirements. If you chooses a larger shape size for the VM-Series firewall model. Although
the firewall only uses the maximum vCPUs cores and memory listed on the system requirements page, it
does take advantage of the faster network performance that the larger shape provides.
VM-SERIES DEPLOYMENT GUIDE | Set up the VM-Series Firewall on Oracle Cloud Infrastructure 671
© 2021 Palo Alto Networks, Inc.
Deployments Supported on OCI
Use the VM-Series firewall on OCI to secure your cloud environment in the following scenarios:
• North-South Traffic—You can use the VM-Series firewall to secure traffic entering your cloud network
from an untrusted source or exiting your cloud network to reach an untrusted source. For either type of
traffic, you must configure route table rules in your Virtual Cloud Network (VCN) and NAT policy rules
on the firewall.
In this example, outbound traffic is exiting the trust subnet in your VCN. You must configure source
address translation policy onto a public IP address and a route table rule that redirects that traffic to
the firewall. The route rule points outgoing traffic to the firewall’s interface in the trust subnet of the
VCN. When the firewall receives this traffic, it performs the source address translation on the traffic and
applies any other security policy you have configured.
• Inter-VCN Traffic (East-West)—The VM-Series firewall allows you to secure traffic moving within your
cloud environment between VCNs. Each subnet must belong to a different VCN because, by default, no
route rules are used to enable traffic within a VCN. In this scenario, you configure an interface on the
firewall connected to a subnet in each VCN.
In the example below, a user in the Trust Subnet wants to access data in the DB Subnet. Configure
a route on OCI that reaches DB Subnet CIDR next hop, which points to the interface Trust Subnet
network on the VM-Series firewall.
672 VM-SERIES DEPLOYMENT GUIDE | Set up the VM-Series Firewall on Oracle Cloud Infrastructure
© 2021 Palo Alto Networks, Inc.
Prepare to Set Up the VM-Series Firewall on
OCI
The process to deploy the VM-Series firewall on Oracle Cloud Infrastructure requires the completion of
preparation tasks.
• Virtual Cloud Networks
• SSH Keys
• Initial Configuration User Data
If there is no route rule that matches the traffic that is attempting to leave the VCN, the traffic
is dropped.
Each subnet requires a route table and once you have added a route table to a subnet, you cannot change it.
However, you can add, remove, or edit rules in a route table after it has been created.
SSH Keys
You must create an SSH key pair to login to the firewall for the first time. You cannot use the default
username and password to access the firewall for the first time. After the firewall boots up for the first time,
you must access the firewall through the CLI and create a new username and password.
1. Create an SSH key pair and store the SSH Key pair in the default location for your operating system.
• On Linux or MacOS, use ssh-keygen to create the key pair in your .ssh directory.
• On Windows, use PuTTYgen to create the key pair.
The content of the Key comment field does not matter to the VM-Series firewall; you can accept
the default (the key creation date) or enter a comment that helps you remember the name of the key
pair. Use the Save private key button to store the private key in your .ssh directory.
2. Select the full public key.
• Linux or MacOS:
Open your public key in a text editor and copy the public key.
• Windows: You must use the PuTTY Key Generator to view the public key. Launch PuTTYgen, click
Load, and browse to private key you saved in your .ssh directory.
In PuTTYgen, scroll down to ensure you select the entire key, right click, and choose Copy.
VM-SERIES DEPLOYMENT GUIDE | Set up the VM-Series Firewall on Oracle Cloud Infrastructure 673
© 2021 Palo Alto Networks, Inc.
Initial Configuration User Data
You must provide the following bootstrapping parameters when setting up the VM-Series firewall instance.
OCI uses this information to perform the initial configuration of the firewall, which provides the firewall
with a hostname and license and connects the firewall to Panorama, if applicable.
The Panorama-related fields are required only if you have a Panorama appliance and want
use Panorama to manage your VM-Series firewall.
Field Description
674 VM-SERIES DEPLOYMENT GUIDE | Set up the VM-Series Firewall on Oracle Cloud Infrastructure
© 2021 Palo Alto Networks, Inc.
Field Description
in this field so that you can group the firewalls logically
and push policy rules to the firewall.
Paste the bootstrapping parameters into the OCI console in the following format.
hostname=<fw-hostname>
vm-auth-key=<auth-key>
panorama-server=<panorama-ip>
panorama-server-2=<panorama2-ip>
tplname=<template-stack-name>
dgname=<device-group-name>
authocodes=<firewall-authcode>
op-command-modes=jumbo-frame
VM-SERIES DEPLOYMENT GUIDE | Set up the VM-Series Firewall on Oracle Cloud Infrastructure 675
© 2021 Palo Alto Networks, Inc.
Deploy the VM-Series Firewall From the
Oracle Cloud Marketplace
Complete the following procedure to deploy the VM-Series firewall in OCI from the Oracle Cloud
Marketplace.
All VM-Series firewall interfaces must be assigned an IPv4 address when deployed in a
public cloud environment. IPv6 addresses are not supported.
STEP 2 | Find the VM-Series firewall application in the Oracle Cloud Marketplace.
1. Search for Palo Alto Networks and a list of offerings for the VM-Series firewall will display.
2. Select an offering.
3. Click Get App.
4. Select your Region and click Sign In.
5. Select the Version and Compartment.
6. Accept the Oracle and Partner terms.
7. Click Launch Instance.
STEP 6 | Select the shape with the number of CPUs, amount of RAM, and number of interfaces required
for the VM-Series firewall model. See the Compute Shapes page for the amount resources
676 VM-SERIES DEPLOYMENT GUIDE | Set up the VM-Series Firewall on Oracle Cloud Infrastructure
© 2021 Palo Alto Networks, Inc.
provided by the different compute shapes. See VM-Series System Requirements for more
information about the resources required for each VM-Series firewall model.
STEP 7 | Under Networking, select your Virtual cloud network compartment, Virtual cloud network,
Subnet compartment, and Subnet for your management interface. You can only add one
interface when creating the VM-Series firewall instance. You will add additional interfaces
later.
STEP 8 | (Optional) Set the boot volume to a size larger than the default. By default, the boot volume is
set to 60GB. Complete this procedure if you require a larger boot volume to support features
such as attaching logs.
1. Select Custom boot volume size (in GB).
2. Enter 60 or greater. 60 GB is the minimum hard drive size required by the VM-Series firewall.
VM-SERIES DEPLOYMENT GUIDE | Set up the VM-Series Firewall on Oracle Cloud Infrastructure 677
© 2021 Palo Alto Networks, Inc.
panorama-server=<panorama-ip>
panorama-server-2=<panorama2-ip>
tplname=<template-stack-name>
dgname=<device-group-name>
authcodes=<firewall-authcode>
op-command-modes=jumbo-frame
STEP 13 | Attach a vNIC to your VM-Series firewall instance for each data interface. You must attach at
least two data interfaces to your firewall instance—untrust and trust.
1. Select your newly launched VM-Series firewall instance and select Attached VNICs > Create VNIC.
2. Enter a descriptive Name for your vNIC.
3. Select your VCN from the Virtual Cloud Network drop-down.
4. Select your subnet from the Subnet drop-down.
5. Specify a Private IP Address. This is only required if your want to choose a particular IP for the vNIC.
If you do not specify an IP, OCI will assign an IP address from the CIDR block you assigned to the
subnet.
6. Select Assign Public IP Address for public facing vNICs such as your untrust subnet.
7. Click Create VNIC.
8. Repeat this procedure for each vNIC your deployment requires.
678 VM-SERIES DEPLOYMENT GUIDE | Set up the VM-Series Firewall on Oracle Cloud Infrastructure
© 2021 Palo Alto Networks, Inc.
STEP 14 | Configure the dataplane network interfaces as Layer 3 interfaces on the firewall.
1. Log in to the firewall.
2. Select Network > Interfaces > Ethernet.
3. Click the link for ethernet 1/1 and configure as follows:
• Interface Type: Layer3
• On the Config tab, assign the interface to the default router.
• On the Config tab, expand the Security Zone drop-down and select New Zone. Define a new
zone, for example untrust-zone, and then click OK.
• On the IPv4 tab, select either Static.
• Click Add in the IP section and enter the IP address and network mask for the interface. Make
sure that the IP address matches the IP address that you assigned to the corresponding subnet in
VCN. For example, if you add this interface to your untrust zone, make sure you assign the untrust
vNIC IP address configured in your VCN.
4. Repeat this procedure for each vNIC configured in your VCN except your management vNIC.
Always only delete interfaces at the bottom of the interface list. Deleting firewall interfaces
in the wrong order results in a interface mismatch between the firewall and OCI. For
example, say you have five data interfaces, then delete interface two on the firewall and
add a new interface at the bottom. After rebooting the firewall, the newly added interface
will take the place of the deleted interface two instead of taking a place at the bottom of
the list.
VM-SERIES DEPLOYMENT GUIDE | Set up the VM-Series Firewall on Oracle Cloud Infrastructure 679
© 2021 Palo Alto Networks, Inc.
Configure Active/Passive HA on OCI
You can configure a pair of VM-Series firewalls on OCI in an active/passive high availability (HA)
configuration. To ensure uptime in an HA setup on OCI, you must create a secondary, floating IP addresses
that can quickly move from one peer to the other. When the active firewall goes down, the floating IP
address moves from the active to the passive firewall so that the passive firewall can seamlessly secure
traffic as soon as it becomes the active peer. In addition to the floating IP address, the HA peers also need
HA links—a control link (HA1) and a data link (HA2)—to synchronize data and maintain state information.
To allow the firewalls to move the floating IP address upon failover, you must place the firewall instances
in a dynamic group on OCI. Dynamic groups allow you to group the firewall instances as principal actors
and create policy to allow the instances in the dynamic group to make API calls against OCI services. You
will use matching rules to add the HA peer instances to the dynamic group and then create the policy the
floating IP from one VNIC to another.
Both VM-Series firewalls in the HA pair must have the same number of network interfaces. Each firewall
requires a minimum of four interfaces—management, untrust, trust, and HA. You can configure additional
data interfaces as required by your deployment.
• Management interface—the private and public IP addresses associated with the primary interface. You
can use the private IP address on the management interface as the IP address for the HA1 interface
between the peers. If you want a dedicated HA interface, you must attach an additional interface to each
firewall, for a total of five interfaces each.
• Untrust and trust interfaces—each of these data interfaces on the active HA peer require a primary
and secondary IP address. Upon failover, when the passive HA peer transitions to the active state, the
secondary private IP address is detached from the previously active peer and attached to the now active
HA peer.
680 VM-SERIES DEPLOYMENT GUIDE | Set up the VM-Series Firewall on Oracle Cloud Infrastructure
© 2021 Palo Alto Networks, Inc.
• HA2 interface—this interface has a single private IP address on each HA peer. The HA2 interface is
the data link peers use to synchronize sessions, forwarding tables, IPsec security associations, and ARP
tables.
STEP 1 | Deploy the VM-Series Firewall From the Oracle Cloud Marketplace and set up the network
interfaces for HA.
1. (Optional) Configure a dedicated HA1 interface on each HA peer.
1. From the OCI Console, select Compute > Instances and click on the name of your active peer
instance.
2. Select Attached VNICs and click Create VNIC.
3. Enter a descriptive name for your HA1 interface.
4. Select the VCN and subnet.
5. Enter a private IP address.
6. Click Create VNIC.
7. Repeat this process on your passive peer instance.
2. Configure an HA2 interface on each HA peer.
1. From the OCI Console, select Compute > Instances and click on the name of your active peer
instance.
2. Select Attached VNICs and click Create VNIC.
3. Enter a descriptive name for your HA2 interface.
4. Select the VCN and subnet. The HA2 interface should be on a separate subnet from your data
interfaces.
5. Enter a private IP address.
6. Click Create VNIC.
7. Repeat this process on your passive peer instance.
3. Add a secondary IP address to your dataplane interfaces on the active peer.
1. From the OCI Console, select Compute > Instances and click on the name of your active peer
instance.
2. Select Attached VNICs and click on your untrust VNIC.
3. Select IP Addresses and click Assign Private IP Address.
4. Enter the IP address and click Assign.
5. Repeat this procedure for each dataplane interface on your active peer.
STEP 2 | Create security rules to allow the HA peers to synchronize data and maintain state information.
By default, OCI allows ICMP traffic only. You must open the necessary HA ports.
1. Open the ports for your HA1 interface.
1. From the OCI Console, select Networking > Virtual Cloud Networks and select your VCN.
2. Select Subnets and select the subnet containing your HA1 interface.
3. Select Security Lists and click the default security list to edit it.
4. Click Add Ingress Rule.
5. Enter the Source CIDR that includes the HA peer HA1 port IP address.
6. Select TCP from the IP Protocol drop-down.
7. Click +Additional Ingress Rule. You need to create two additional rules for TCP ports 28260 and
28769.
8. If encryption is enabled on your VM-Series firewall for the HA1 link, create an additional rules for
ICMP and TCP port 28.
9. Click Add Ingress Rules.
VM-SERIES DEPLOYMENT GUIDE | Set up the VM-Series Firewall on Oracle Cloud Infrastructure 681
© 2021 Palo Alto Networks, Inc.
2. Open the ports for your HA2 interface.
1. From the OCI Console, select Networking > Virtual Cloud Networks and select your VCN.
2. Select Subnets and select the subnet containing your HA2 interface.
3. Select Security Lists and click the default security list to edit it.
4. Click Add Ingress Rule.
5. Enter the Source CIDR that includes the HA peer HA2 port IP address.
6. Select UDP or IP from the IP Protocol drop-down.
7. If the transport mode is UDP, enter 29281 into Source Port Name. If the transport mode is IP,
enter 99 into Source Port Name.
8. Click Add Ingress Rules.
STEP 3 | Add both HA peers to a dynamic group and create policy that allows the HA peers to move the
floating IP address. You must have the OCID of each HA peer instance to build the dynamic
group matching rules, so have those on hand to past into the rule builder.
1. Create the dynamic group.
1. From the OCI Console, select Identity > Dynamic Groups > Create Dynamic Group.
2. Enter a descriptive Name for your dynamic group.
3. Click Rule Builder.
4. Select Any of the following rules from the first drop-down.
682 VM-SERIES DEPLOYMENT GUIDE | Set up the VM-Series Firewall on Oracle Cloud Infrastructure
© 2021 Palo Alto Networks, Inc.
5. Select Match instances with ID: from the Attributes drop-down and paste one of the peer OCIDs
into the Value field.
6. Click +Additional Line.
7. Select Match instances with ID: from the Attributes drop-down and paste the other peer OCID
into the Value field.
8. Click Add Rule.
STEP 4 | Configure the interfaces on the firewall. You must configure the HA2 data link and at least two
Layer 3 interfaces for your untrust and trust interfaces. Complete this workflow on the first HA
peer and then repeat the steps on the second HA peer.
1. Log in to the firewall web interface.
2. (Optional) If you are using the management interface as HA1, you must set the interface IP Type to
static and configure a DNS server.
VM-SERIES DEPLOYMENT GUIDE | Set up the VM-Series Firewall on Oracle Cloud Infrastructure 683
© 2021 Palo Alto Networks, Inc.
1. Select Device > Setup > Interfaces > Management.
2. Set the IP Type to Static.
3. Enter the private IP address of the primary VNIC of your VM-Series firewall instance.
4. Click OK.
5. Select Device > Setup > Services.
6. Click Edit.
7. Enter the IP address of the Primary DNS Server.
8. Click OK.
9. Commit your changes.
3. Select Network > Interfaces > Ethernet and click on your untrust interface. In this example, the HA2
interface is 1/1, the trust interface is ethernet 1/2, and the untrust interface is ethernet 1/3.
4. Click the link for ethernet 1/1 and configure as follows:
• Interface Type: HA
5. Click the link for ethernet 1/2 and configure as follows:
• Interface Type: Layer3
• On the Config tab, assign the interface to the default router.
• On the Config tab, expand the Security Zone drop-down and select New Zone. Define a new
zone, for example trust-zone, and then click OK.
• On the IPv4 tab, select either Static.
• Click Add in the IP section and enter the primary IP address and network mask for the interface.
Make sure that the IP address matches the IP address that you assigned to the corresponding
subnet in VCN. For example, if you add this interface to your trust zone, make sure you assign the
trust vNIC IP address configured in your VCN.
• Click Add in the IP section and enter the secondary, floating IP address and network mask.
6. Click the link for ethernet 1/3 and configure as follows:
• Interface Type: Layer3
• On the Config tab, assign the interface to the default router.
• On the Config tab, expand the Security Zone drop-down and select New Zone. Define a new
zone, for example untrust-zone, and then click OK.
• On the IPv4 tab, select either Static.
• Click Add in the IP section and enter the primary IP address and network mask for the interface.
Make sure that the IP address matches the IP address that you assigned to the corresponding
subnet in VCN. For example, if you add this interface to your untrust zone, make sure you assign
the untrust vNIC IP address configured in your VCN.
• Click Add in the IP section and enter the secondary, floating IP address and network mask.
684 VM-SERIES DEPLOYMENT GUIDE | Set up the VM-Series Firewall on Oracle Cloud Infrastructure
© 2021 Palo Alto Networks, Inc.
5. (Optional) Edit the Control Link (HA1). If you do not plan to use the management interface for the
control link and have added an additional interface (for example ethernet 1/4), edit this section to
select the interface to use for HA1 communication.
6. Edit the Data Link (HA2) to use Port ethernet 1/1 and add the IP address of active peer and the
Gateway IP address for the subnet.
7. Select IP or UDP from the Transport drop-down. Ethernet is not supported.
8. Click OK.
STEP 8 | After your finish configuring HA on both firewalls, verify that the firewalls are paired in active/
passive HA.
1. Access the Dashboard on both firewalls and view the High Availability widget.
2. On the active HA peer, click Sync to peer.
3. Confirm that the firewalls are paired and synced.
• On the passive firewall: the state of the local firewall should display Passive and the Running
Config should show as Synchronized.
• On the active firewall: the state of the local firewall should display Active and the Running Config
should show as Synchronized.
VM-SERIES DEPLOYMENT GUIDE | Set up the VM-Series Firewall on Oracle Cloud Infrastructure 685
© 2021 Palo Alto Networks, Inc.
686 VM-SERIES DEPLOYMENT GUIDE | Set up the VM-Series Firewall on Oracle Cloud Infrastructure
Set Up the VM-Series Firewall on Alibaba
Cloud
Deploying the VM-Series firewall on Alibaba Cloud protects networks you create within
Alibaba Cloud. You can deploy VM-Series firewalls to protect internet facing applications and
hybrid cloud deployments.
687
688 VM-SERIES DEPLOYMENT GUIDE | Set Up the VM-Series Firewall on Alibaba Cloud
© 2021 Palo Alto Networks, Inc.
VM-Series Firewall on Alibaba Cloud
You can deploy the VM-Series firewall to secure inbound and outbound north-south traffic in Alibaba
Cloud.
Securing east-west traffic within the same VPC is not supported because Alibaba Cloud
does not support subnet routing.
The VM-Series firewall on Alibaba Cloud runs on the KVM hypervisor and supports up to 8 network
interfaces when you select an Alibaba Cloud instance with sufficient resources (see Minimum System
Requirements for the VM-Series Firewall on Alibaba Cloud).
The VM-Series firewall on Alibaba Cloud supports BYOL licensing and the VM-Series ELA on Alibaba Cloud
International Regions and Mainland China. PAYG licensing is not currently supported.
In Alibaba Cloud, your VPC logically isolates your virtual network. After creating a VPC, you can create
VSwitches to further segment your virtual private network, as shown in the following diagram. To secure
inbound traffic, both DNAT and SNAT must be configured on the firewall.
Inbound traffic originates from a client outside of your VPC going to the VM-Series firewall untrust
interface. The firewall inspects the traffic and sends it to an application through the trust interface. Traffic
returning from the application must travel through the VM-Series firewall trust interface, which inspects the
return traffic flow and sends it out through the untrust interface.
Outbound traffic typically originates from an external application. Typically you route the internet facing
traffic within a VPC to a NAT gateway (with EIP attached). To do this, add a default gateway route in
the VPC routing table, with the VM-Series firewall IP address of the application subnet as the next hop.
Configure SNAT using the untrust interface IP to ensure traffic originating from the internet returns through
the VM-Series firewall.
Refer to Secure North-South Traffic on Alibaba Cloud for a sample configuration.
VM-SERIES DEPLOYMENT GUIDE | Set Up the VM-Series Firewall on Alibaba Cloud 689
© 2021 Palo Alto Networks, Inc.
Minimum System Requirements for the VM-
Series Firewall on Alibaba Cloud
On Alibaba Cloud, you can deploy the VM-Series firewall on the KVM hypervisor (see VM-Series
Deployments).
• VM-Series Firewall Software Requirements
• Alibaba Cloud Instance Type Recommendations for the VM-Series Firewall
• Alibaba Cloud CLI
690 VM-SERIES DEPLOYMENT GUIDE | Set Up the VM-Series Firewall on Alibaba Cloud
© 2021 Palo Alto Networks, Inc.
Prepare to Deploy the VM-Series Firewall on
Alibaba Cloud
This task uses the Aliyun CLI to create a VPC and VSwitches for the VM-Series firewall, however, you
should plan your network before you start. Evaluate the applications you want to protect, and determine
where you will deploy the VM-Series firewall to inspect and secure north-south traffic.
• Choose Licenses and Plan Networks
• Prepare to Use the Aliyun Command Line Interface
STEP 2 | Evaluate your applications and network configurations and calculate the firewall capacity you
need to secure your applications and networks.
The VM-Series firewall supports up to 8 interfaces, provided the VM-Series model and
Alibaba Cloud instance have sufficient resources.You can use the model
Use the VM-Series model you have chosen to choose one of the Alibaba Cloud Instance Type
Recommendations for the VM-Series Firewall.
2. Choose a VM-Series capacity license that meets your needs.
3. Purchase a BYOL subscription bundle (if you do not already have one). You receive an auth code for
your VM-Series subscription, and you must supply it during the deployment.
STEP 4 | Plan how to configure Alibaba accounts and permissions to access the VM-Series firewall. For a
start, see the Security FAQ, and learn about Instance RAM Roles.
VM-SERIES DEPLOYMENT GUIDE | Set Up the VM-Series Firewall on Alibaba Cloud 691
© 2021 Palo Alto Networks, Inc.
Install and configure a recent version of Aliyun, the Alibaba Cloud command line interface.
STEP 1 | Create an AccessKey and save the Access Key ID and Secret in a secure place.
aliyun configure
Configuring profile '' in '' authenticate mode...
Access Key Id [*************8rq]: *************8rq
Access Key Secret [***************************tM2]:
***************************tM2
Default Region Id [us-west-1]: us-west-1
Default Output Format [json]: json (Only support json))
Default Language [zh|en] en: en
Saving profile[] ...Done.
available regions:
...
692 VM-SERIES DEPLOYMENT GUIDE | Set Up the VM-Series Firewall on Alibaba Cloud
© 2021 Palo Alto Networks, Inc.
Deploy the VM-Series Firewall on Alibaba
Cloud
The VM-Series firewall assumes a minimum of three interfaces: management, untrust, and trust. When
you create an Alibaba Cloud VPC, it is logically isolated. To segment your virtual private network into
subnets you create VSwitches, each having its own CIDR block. Because the VM-Series firewall has multiple
interfaces, it can inspect traffic on all subnets.
Typically external inbound traffic encounters the VM-Series firewall untrust interface. The firewall inspects
the inbound traffic and sends it to an application through the trust interface. Return traffic from the
application goes to the firewall’s trust interface, where the firewall inspects the return traffic and sends it
out through the untrust interface.
The following tasks demonstrate how to use the console to create the VM-Series firewall infrastructure.
• Create a VPC and Configure Networks
• Create and Configure the VM-Series Firewall
• Secure North-South Traffic on Alibaba Cloud
• Configure Load Balancing on Alibaba Cloud
All VM-Series firewall interfaces must be assigned an IPv4 address when deployed in a
public cloud environment. IPv6 addresses are not supported.
STEP 1 | Open the VPC console and select your region from the menu. Note, the region you select must
provide one of the instance types that Palo Alto Networks supports.
STEP 2 | From the Alibaba Cloud Console home page, select Products and Services > Networking >
Virtual Private Cloud.
Property Value
IPV4 CIDR Bock Your choice. Refer to the CIDR block FAQ.
VM-SERIES DEPLOYMENT GUIDE | Set Up the VM-Series Firewall on Alibaba Cloud 693
© 2021 Palo Alto Networks, Inc.
2. Select Create VSwitch.
• Name the VSwitch Management.
• Choose the Zone, specify an IPv4 CIDR Block that is a subset of the block you specified for the
VPC, and specify a Description.
• At the bottom, click Add to add another vSwitch (do not click OK until you have added all
VSwitches).
Refer to Create a VSwitch.
3. Add the Untrust VSwitch in the same manner.
4. Add the Trust VSwitch.
5. Click OK.
View the VPC details and make any changes before you click Complete.
Property Value
Template Customize
Property Value
Action Allow
694 VM-SERIES DEPLOYMENT GUIDE | Set Up the VM-Series Firewall on Alibaba Cloud
© 2021 Palo Alto Networks, Inc.
Property Value
Priority 100
Authorization Object
• Click Add Security Group Rule to create an inbound rule to allow SSH on the management
interface.
Property Value
Action Allow
Authorization Object
Property Value
Action Allow
Priority 100
Authorization Object
VM-SERIES DEPLOYMENT GUIDE | Set Up the VM-Series Firewall on Alibaba Cloud 695
© 2021 Palo Alto Networks, Inc.
Create and Configure the VM-Series Firewall
This task uses the ECS console to create a VM-Series firewall instance with a minimum of three interfaces:
management, untrust, and trust. An ECS instance supports a single NIC by default, and automatically
attaches an Elastic Network Interface (ENI) to it. To support the VM-Series firewall, you must separately
create the Untrust and Trust Elastic Network Interfaces (ENIs) and attach them to your instance.
STEP 1 | From the Alibaba Cloud console home page, select Elastic Compute Service > Instances &
Images > Instances, and click Create Instance on the upper right.
Property Value
Region Your choice. You can also select a Zone. The region you select must
provide one of the required instance types.
Instance Type One of the types in Alibaba Cloud Instance Type Recommendations
for the VM-Series Firewall. You can use Type-based Selection to
search for the instance type.
696 VM-SERIES DEPLOYMENT GUIDE | Set Up the VM-Series Firewall on Alibaba Cloud
© 2021 Palo Alto Networks, Inc.
2. Select Next: Networking.
VM-SERIES DEPLOYMENT GUIDE | Set Up the VM-Series Firewall on Alibaba Cloud 697
© 2021 Palo Alto Networks, Inc.
Make any corrections.
Select Preview to view your settings thus far.
3. Following Advanced (based or instance RAM roles or cloud-init) click Show.
• The RAM role is optional.
• In the User Data field, enter basic bootstrap information as key-value pairs separated by newlines.
See Enter a Basic Configuration as User Data (Public Clouds). For example, enter the following in
the User Data field.
type=dhcp-client
hostname=Ca-FW-DC1
vm-auth-key=7550362253****
panorama-server=10.*.*.20
panorama-server-2=10.*.*.21
tplname=FINANCE_TG4
dgname=finance_dg
op-cmd-dpdk-pkt-io=on
dhcp-send-hostname=yes
dhcp-send-client-id=yes
dhcp-accept-server-hostname=yes
dhcp-accept-server-domain=yes
authcodes=I7115398
vm-series-auto-registration-pin-id=abcdefgh1234****
vm-series-auto-registration-pin-value=zyxwvut-0987****
STEP 6 | View the terms of service, and select Create Order to create the VM-Series firewall instance.
View the purchase order and select Subscribe.
STEP 7 | From the console home page, choose > Elastic Compute Service > Networks and Security >
ENIs and select Create ENI in the top right corner. Create elastic network interfaces for the
Untrust and Trust interfaces.
1. Create the Untrust ENI.
In the Actions column, select Bind to Instance and select the instance you just created.
2. Create the Trust ENI and bind it to the instance.
698 VM-SERIES DEPLOYMENT GUIDE | Set Up the VM-Series Firewall on Alibaba Cloud
© 2021 Palo Alto Networks, Inc.
STEP 9 | Restart your instance to attach the new network interfaces.
On the Instances list, select your instance, select Manage, and select Restart on the upper right.
STEP 10 | SSH in to the VM-Series firewall with the security key and set the admin password:
admin> configure
Entering configuration mode
[edit]
admin# set mgt-config users admin password
Enter password:<password>
Confirm password:<password>
[edit]
admin# commit
db eth3 192.168.3.0/24
In the following diagram, the VM-Series firewall connects to two trusted subnets, web and db. Inbound
traffic is initiated when an external client accesses the VM-Series firewall’s Untrust interface. The firewall
inspects the traffic and sends it to an application. For example, the firewall sends traffic to a Web server
through the Trust interface. The traffic returning from the Web server must hit the VM-Series firewall’s
Trust interface. The firewall inspects the return traffic flow, and sends it out through the Untrust interface.
VM-SERIES DEPLOYMENT GUIDE | Set Up the VM-Series Firewall on Alibaba Cloud 699
© 2021 Palo Alto Networks, Inc.
To secure inbound traffic, both DNAT and SNAT must be configured on the firewall.
<nat>
<rules>
<entry name="inbound_web">
<source-translation>
<dynamic-ip-and-port>
<interface-address>
<interface>ethernet1/2</interface>
</interface-address>
</dynamic-ip-and-port>
</source-translation>
<destination-translation>
<translated-address>web_server</translated-address>
</destination-translation>
<to>
<member>untrust</member>
</to>
<from>
<member>any</member>
</from>
<source>
<member>any</member>
</source>
<destination>
<member>fw_untrust</member>
</destination>
<service>any</service>
<to-interface>ethernet1/1</to-interface>
</entry>
</rules>
</nat>
<address>
<entry name="fw_untrust">
<ip-netmask>192.168.1.4</ip-netmask>
700 VM-SERIES DEPLOYMENT GUIDE | Set Up the VM-Series Firewall on Alibaba Cloud
© 2021 Palo Alto Networks, Inc.
</entry>
<entry name="fw_trust">
<ip-netmask>192.168.2.201</ip-netmask>
</entry>
<entry name="web_server">
<ip-netmask>192.168.2.203</ip-netmask>
</entry>
</address>
VM-SERIES DEPLOYMENT GUIDE | Set Up the VM-Series Firewall on Alibaba Cloud 701
© 2021 Palo Alto Networks, Inc.
3. Configure SNAT rules using the Untrust interface IP to ensure traffic returning from the internet goes
through the VM-Series firewall.
Here's a sample SNAT configuration.
<nat>
<rules>
<entry name="outbound_web">
<source-translation>
<dynamic-ip-and-port>
<interface-address>
<interface>ethernet1/1</interface>
</interface-address>
</dynamic-ip-and-port>
</source-translation>
<to>
<member>untrust</member>
</to>
<from>
<member>trust</member>
</from>
<source>
<member>any</member>
</source>
<destination>
<member>any</member>
</destination>
<service>any</service>
<to-interface>any</to-interface>
</entry>
</rules>
</nat>
702 VM-SERIES DEPLOYMENT GUIDE | Set Up the VM-Series Firewall on Alibaba Cloud
© 2021 Palo Alto Networks, Inc.
Configure Load Balancing on Alibaba Cloud
On Alibaba Cloud, you can deploy the VM-Series firewall in a load balancer sandwich configuration where
the firewall is deployed between a public network and a private network, as shown below.
In Create a VPC and Configure Networks, you created Untrust and Trust ENIs and attached them to the
VM-Series firewall instance as secondary ENIs.
When you use the console to add multiple backend servers to Alibaba Server Load Balancer (SLB), the
SLB sends traffic to the primary ENI of the next-hop backend servers. Because the primary ENI is the
management interface, traffic must go to the Untrust interface (a secondary ENI) for inspection.
To ensure that internet traffic goes to dataplane interfaces rather than the management interface, use the
Alibaba CLI to attach the VM-Series firewall untrust ENIs to your SLB instance.
You must install the Aliyun command line interface to use the following CLI commands.
STEP 1 | Create the public and private VPCs for a load balancer sandwich configuration, and deploy the
VM-Series firewalls.
The remaining steps are sample CLI commands you can adapt to your environment.
VM-SERIES DEPLOYMENT GUIDE | Set Up the VM-Series Firewall on Alibaba Cloud 703
© 2021 Palo Alto Networks, Inc.
"Address": "***********,
"ResourceGroupId": "rg-************ofi",
"RequestId": "0B8BA2AA-E837-****-****-B82A8A1D5FBB",
"AddressIPVersion": "ipv4",
"LoadBalancerId": "lb-******************mvz",
"VSwitchId": "",
"VpcId": "vpc-*****************r7z"
}
Use the CLI to add interfaces one at a time. The order in which you add the interfaces
determines which NIC receives the interface.
704 VM-SERIES DEPLOYMENT GUIDE | Set Up the VM-Series Firewall on Alibaba Cloud
Set Up a Firewall in Cisco ACI
Palo Alto Networks integrates as a service with Cisco Application-Centric Infrastructure (ACI).
ACI is a software-defined networking (SDN) solution for easily deploying new workloads and
network services. Using an SDN controller called the Cisco Application Policy Infrastructure
Controller (APIC), you deploy the firewall service between Endpoint Groups (EPGs). EPGs
act as a container for applications or application tiers. When you place a firewall between
EPGs, security policy configured on the firewall secures the traffic between the EPGs. The
APIC provides a single pane of glass for managing the network topology, network policies,
and connectivity for the entire data center and supports inserting L4 - L7 devices, such
as a hardware-based or VM-Series firewall. Panorama is required for centralized security
management.
705
706 VM-SERIES DEPLOYMENT GUIDE | Set Up a Firewall in Cisco ACI
© 2021 Palo Alto Networks, Inc.
Palo Alto Networks Firewall Integration with
Cisco ACI
Palo Alto Networks integration with Cisco ACI allows you to insert a firewall between EPGs as a Layer 4 to
Layer 7 service. The firewall then secures the east-west traffic between the application tiers within those
EPGs or north-south traffic between users and the applications.
The figure below shows an example of a physical ACI deployment that includes integrated Palo Alto
Network firewalls. All the entities in the ACI Fabric are connected to leaf switches and those leaf switches
are connected to larger spine switches. As users access the application, the ACI fabric moves the traffic
to the correct destination. To secure the traffic between the application tiers, the network administrator
inserts the Palo Alto Networks firewalls as L4 to L7 services between each EPG and creates a service graph
to define what services the L4 to L7 device provides.
After the firewall services have been deployed, traffic now flows logically as shown below. Traffic to and
from the end users and each tier in the application regardless of where or how each entity is physically
connected to the network.
When the your firewall is integrated with Cisco ACI, traffic is sent to the firewall with a policy-based
redirect (PBR). Additionally, configuration of the firewall and configuration of the APIC are completely
separate. Network policy mode does not rely on any other configuration integration between the firewall
and the APIC, so it provides greater flexibility of configuration and deployment of the firewall.
Multi-Context Deployments
Cisco ACI integration supports physical firewalls divided into contexts that are managed by ACI as individual
firewalls. On the firewall, these contexts are the virtual systems (vsys) on the firewalls and each firewall is
licensed to support a certain number of vsys instances. When deploying a multi-vsys firewall in ACI, you
must configure a chassis manager in the tenant and assign it to the firewall service.
STEP 1 | Select Network > Interfaces > Ethernet and click Add Aggregate Group.
STEP 2 | Enter a number for the aggregate group in the second Interface Name field.
Do not select Same System MAC Address for Active-Passive HA. This option makes the
firewall pair appear as a single device to the switch, so traffic will flow to both firewalls
instead of just the active firewall.
STEP 9 | Add a subinterface on the aggregate Ethernet interface for the tenant and VRF.
1. Select the row of your aggregate Ethernet group and click Add Subinterface.
2. In the second Interface Name field, enter a numerical suffix to identify the subinterface.
3. In the Tag field, enter the VLAN tag of the subinterface.
4. Select the virtual router you configured previously from the Virtual Router drop-down.
5. Select the zone you configured previously from the Zone drop-down.
6. Select the IPv4 tab.
7. Select the Static Type.
8. Click Add and enter the subinterface IP address and network mask in CIDR notation.
9. Click OK.
STEP 5 | From the Interface drop-down, select the aggregate Ethernet group you created previously in
this procedure.
STEP 6 | Select IP Address from the Next Hop drop-down and enter the IP address of the next hop
router.
STEP 6 | Configure additional security policy rules based on your needs using the address objects and
zone you created for your EPG.
Configure an Interface Policy for LLDP and LACP for East-West Traffic
Create policy that enables LLDP and LACP on the ACI interfaces that connect to your firewall.
LLDP is necessary for forwarding to work correctly in the ACI environment; ACI does not deploy a subnet
router interface on a leaf switch unless it detects an endpoint on the switch that requires one. LLDP helps
determine if a subnet router interface is required.
LACP provides greater resiliency and recovery speed on a link failure.
STEP 4 | Select the leaf switch or switches to which you firewall is connected from the Switches drop-
down.
STEP 7 | In the Interfaces field, enter the number of the interface your firewall uses to connect to the
leaf switch.
STEP 8 | Enter a descriptive name into the Interface Selector Name field.
STEP 10 | Select LACP Active from the Port Channel Policy drop-down.
STEP 13 | Select the physical domain or VMM domain you created previously in this procedure from the
Domain drop-down.
STEP 16 | Repeat this procedure for the second firewall in your HA pair.
STEP 7 | Select Physical for a physical firewall or Virtual for a VM-Series firewall from the Device Type
drop-down.
STEP 8 | Select the physical or VMM domain you created previously from the Domain drop-down.
STEP 12 | Under Path, select the path to the primary firewall in your HA pair.
STEP 14 | Under Device 2, click the plus (+) icon to the right of Device Interfaces.
STEP 16 | Under Path, select the path to the secondary firewall in your HA pair.
STEP 18 | Under Cluster, click the plus (+) icon to the right of Cluster Interfaces.
STEP 20 | Select the two interfaces you configured above from the list under Concrete Interfaces.
The APIC requires that you configure two interfaces. However, because there is only one
connection between the firewall and the ACI fabric, only one of the interfaces is used.
STEP 21 | Under Encap, enter a VLAN from the from the static VLAN pool you created earlier. Traffic
will be redirected to the firewall on the VLAN assigned here.
10.Select the service graph template you created in the previous procedure from the Service Graph
Template drop-down.
STEP 3 | Right-click External Routed Networks and select Create Routed Outside.
STEP 5 | Select your VRF with external connectivity from the VRF drop-down.
STEP 6 | Select the external routed domain you created previously form the External Routed Domain
drop-down.
STEP 8 | Enter an OSPF Area ID. The Area ID can be expressed in decimal number or dotted decimal
form. For example, Area 1 is the same as Area 0.0.0.1 or Area 271 is the same as Area 0.0.1.15.
The Area ID range is 0 (0.0.0.0) to 4294967295 (255.255.255.255).
STEP 10 | Click the plus (+) button to the right of Nodes and Interface Profiles to create a Node Profile
with a node that for the border-leaf switches that connect to the firewall.
STEP 17 | Click the plus (+) button to the right of External EPG Networks. This opens the Create Routed
Outside window.
STEP 2 | Select Networking > Bridge Domains > <your bridge domain>.
STEP 4 | Click the plus (+) button to the right of Associated L3 Outs.
STEP 5 | Select the Layer 3 external routed network connection you created in the previous procedure
from the L3 Out drop-down.
STEP 7 | Select Networking > Bridge Domains > <your bridge domain> > Subnets > <externally
advertised subnet>.
STEP 2 | Apply the inbound contract so an internal EPG provides it to the external EPG.
1. On the Tenants tab, double-click on the name of your tenant.
2. Select Application Profiles > <your application profile> > Application EPGs > <your application
EPG> > Contracts.
3. Right-click on Contracts and select Add Provided Contract.
4. Select your inbound contract from the Contract drop-down.
5. Click Submit.
6. On the same tenant, select Networking > External Routed Networks > <your external routed
network> > Networks > External.
7. On the Contracts tab, click the plus (+) button to the right of Consumed Contracts.
8. Select your inbound contract from the Name drop-down.
9. Click Update.
STEP 1 | Select Network > Interfaces > Ethernet and click Add Aggregate Group.
STEP 2 | Enter a number for the aggregate group in the second Interface Name field.
Do not select Same System MAC Address for Active-Passive HA. This option makes the
firewall pair appear as a single device to the switch, so traffic will flow to both firewalls
instead of just the active firewall.
STEP 8 | Click on the name of an Ethernet interface to configure it and add it to the aggregate group.
1. Select Aggregate Ethernet from the Interface Type drop-down.
2. Select the interface you defined in the aggregate Ethernet group configuration.
3. Click OK.
4. Repeat this step for each other member interface of the aggregate Ethernet group.
STEP 1 | Configure address translation for traffic entering an EPG in your data center.
1. Select Policies > NAT and click Add.
2. Enter a descriptive Name for your NAT policy rule.
3. Select Original Packet and click Add under Source Zone.
4. Select the source zone from the drop-down.
5. Select the destination zone from the Destination Zone drop-down.
6. Select Any for the Source Address.
7. Click Add under Destination Address and enter the external IP address.
6. On the Translated Packet tab, select the Translation Type under Source Address Translation.
7. Enter additional required address information.
8. Click OK.
8GB 10,000
16GB 20,000
The Cisco ACI plugin processes the endpoint information and converts it into a set of tags that can be
used as match criteria for placing IP addresses in dynamic address groups. The tags are constructed in the
following format:
cisco.cl_<cluster>.tn_<tenant>.ap_<app-profile>.{epg_<EPG> | uepg_<micro-EPG>}
• cisco.cl_<cluster>—this tag groups IP addresses into a dynamic address group based on the Cisco ACI
cluster and displays the name of your cluster.
• cisco.cl_<cluster>.tn_<tenant>—this tag groups IP addresses into a dynamic address group based on
tenant and displays the name of your cluster and tenant.
• cisco.cl_<cluster>.tn_<tenant>.ap_<app-profile>—this tag groups IP addresses into a dynamic address
group base on application profile and displays the name of your cluster, tenant, and application profile.
• cisco.cl_<cluster>.tn_<tenant>.ap_<app-profile>.epg_<EPG>—this tag groups IP addresses into a
dynamic address group based on EPG and displays the name of your cluster, tenant, application profile,
and EPG.
• cisco.cl_<cluster>.tn_<tenant>.ap_<app-profile>.uepg_<micro-EPG>—this tag groups IP addresses into
a dynamic address group based on micro-EPG and displays the name of your cluster, tenant, application
profile, and micro-EPG.
• cisco.cl_<cluster>.tn_<tenant>.l2out_<L2-external-endpoint>—this tag groups IP addresses into
dynamic address groups based on L2 external endpoint and displays the name of you cluster, tenant, and
L2 external endpoint.
• cisco.cl_<cluster>.tn_<tenant>.bd_<bridge-domain>.subnet_<subnet>—this tag groups IP address into
a dynamic address group based on subnet and displays the name of you cluster, tenant, bridge domain,
and subnet.
To retrieve endpoint IP-address-to-tag mapping information, you must configure a Monitoring Definition
for each APIC fabric in your Cisco ACI environment. The Monitoring Definition specifies the username
and password that allows Panorama to connect to the APICs. It also specifies the device groups and
corresponding notify groups containing the firewalls to which Panorama pushes the tags. After you
configure the Monitoring Definition and the Cisco ACI plugin retrieves the tags, you can create dynamic
address groups and add the tags as match criteria.
The Cisco ACI plugin uses two intervals to retrieve information from the APIC. The first is the monitoring
interval.
If you configure a value for the monitoring interval greater than that of the full-sync interval,
the full-sync interval is ignored and a full synchronization is performed at every monitoring
interval.
If Panorama loses its connection with the APIC, Panorama will attempt to reconnect five times. After five
failed attempts, Panorama stops monitoring for changes in your clusters and displays the reconnection
attempts in the system log. To recover and begin monitoring your clusters again, you must perform a
commit on Panorama.
• Install the Panorama Plugin for Cisco ACI
• Configure the Cisco ACI Plugin
• Panorama Plugin for Cisco ACI Dashboard
STEP 1 | Verify that your virtual Panorama has enough memory to support the number endpoints in
your ACI environment.
STEP 5 | Select the version of the plugin and click Install in the Action column to install the plugin.
Panorama will alert you when the installation is complete.
STEP 3 | You must add the firewalls as managed devices on Panorama and create Device Groups so
that you can configure Panorama to notify these groups with the VM information it retrieves.
Device groups can include VM-Series firewalls or virtual systems on the hardware firewalls.
STEP 4 | Enable monitoring, set the monitoring interval, and enable bypass proxy.
1. Select Panorama > Cisco ACI > Setup > General.
2. Select Enable Monitoring. This enables monitoring for all clusters in your deployment.
3. Set the Monitoring Interval in seconds. The monitoring interval is how often Panorama retrieves
updated network information from the APIC. The default value is 60 seconds and the range is 60
seconds to 86,400 seconds (one day).
4. (Optional) Select Bypass Proxy to Bypass proxy server settings, configured on Panorama under
Panorama > Setup > Services > Proxy Server, for communication between Panorama and the
APIC. This allows Panorama to communicate directly with the APIC while maintaining proxied
communication for other services.
STEP 9 | Verify that you can view the EPG information on Panorama, and define the match criteria for
Dynamic Address Groups.
Some browser extensions may block API calls between Panorama and the APIC which
prevents Panorama from receiving match criteria. If Panorama displays no match criteria
and you are using browser extensions, disable the extensions and Synchronize Dynamic
Objects to populate the tags available to Panorama.
Panorama does not immediately process new monitoring definitions and populate the
match criteria available to dynamic address. You should wait for the duration of your
configured monitoring interval before verifying that EPG information.
STEP 10 | Verify that addresses in your EPGs are added to dynamic address groups.
1. Select Panorama > Objects > Address Groups.
2. Click More in the Addresses column of a dynamic address group.
Panorama displays a list of IP addresses added to that dynamic address group based on the match
criteria you specified.
STEP 12 | You can update the dynamic objects from the APIC at any time by synchronizing dynamic
objects. Synchronizing dynamic objects enables you to maintain context on changes in the
virtual environment and allows you to enable applications by automatically updating the
Dynamic Address Groups used in policy rules.
1. Select Panorama > Cisco ACI > Monitoring Definition.
2. Click Synchronize Dynamic Objects.
On HA failover, the newly active Panorama attempts to reconnect to the APIC and
retrieve tags for all monitoring definitions. If there is an error with reconnecting even one
monitoring definition, Panorama generates a system log message
When you see this error, you must log in to Panorama and fix the issue, for example
remove an invalid APIC IP or provide valid credentials, and commit your changes to
enable Panorama to reconnect and retrieve the tags for all monitoring definitions. Even
when Panorama is disconnected from the APIC, the firewalls have the list of all tags that
had been retrieved before failover, and can continue to enforce policy on that list of IP
addresses. If you perform a commit before resolving the failover error, the newly active
Panorama will not push any IP-to-tag mapping information and clearing the mapping
information from the firewalls. As a best practice, to monitor this issue, configure action-
oriented log forwarding to an HTTPS destination from Panorama so that you can take
immediate action.
Tenant Tags Displays the total number of tenants Panorama retrieved from the APIC.
Additionally, it displays the number of dynamic address groups associated with
If a tenants and the number of tenants used in policy.
tenant’s
Click the tile to drill down and view the following columns.
health
score • Tenant Name—list all the tenants retrieved by Panorama.
is zero • Tenant Tag—the Panorama tag associated with each tenant.
(0) on • Dynamic Address Group—displays the dynamic address groups associated
the with the listed tag.
APIC, • In Policy—shows if the listed dynamic address group is used in policy.
Panorama
does
not
retrieve
information
about
that
tenant.
Therefore,
the
tenant
count
on
Panorama
will not
match
the
total
on the
APIC.
Application Profiles Displays the total number of application profiles Panorama retrieved from
the APIC. Additionally, it displays the number of dynamic address groups
associated with application profiles and the number of application profiles used
in policy.
Click the tile to drill down and view the following columns.
• Application Profile Name—lists all application profiles retrieved by
Panorama.
• Tenant Name—displays the tenant associated with the listed application
profile.
• Application Profile Tag—the Panorama tag associated with each application
profile.
• Dynamic Address Group—displays the dynamic address groups associated
with the listed tag.
• In Policy—shows if the listed dynamic address group is used in policy.
End Point Groups Displays the total number of end point groups (EPG) Panorama retrieved from
the APIC. Additionally, it displays the number of dynamic address groups
associated with EPGs and the number of EPGs used in policy.
Click the tile to drill down and view the following columns.
• EPG Name—lists all EPGs retrieved by Panorama.
• Application Profile Name—lists the EPG’s associated application profile.
• Tenant Name—displays the tenant associated with the listed application
profile.
• EPG Tag—the Panorama tag associated with each EPG.
• Dynamic Address Group—displays the dynamic address groups associated
with the listed tag.
• In Policy—shows if the listed dynamic address group is used in policy.
Micro End Point Displays the total number of micro end point groups (EPG) Panorama retrieved
Groups from the APIC. Additionally, it displays the number of dynamic address groups
associated with micro EPGs and the number of micro EPGs used in policy.
Click the tile to drill down and view the following columns.
• Micro EPG Name—lists all EPGs retrieved by Panorama.
• Application Profile Name—lists the Micro EPG’s associated application
profile.
• Tenant Tag—displays the tenant associated with the listed application
profile.
• Micro EPG Tag—the Panorama tag associated with each Micro EPG.
• Dynamic Address Group—displays the dynamic address groups associated
with the listed tag.
• In Policy—shows if the listed dynamic address group is used in policy.
Bridge Domains Displays the total number of bridge domains Panorama retrieved from
the APIC. Additionally, it displays the number of dynamic address groups
associated with brdige domains and the number of bridge domains used in
policy.
Click the tile to drill down and view the following columns.
• Bridge Domain Name—lists all bridge domains retrieved by Panorama.
• Tenant Name—displays the tenant associated with the listed bridge domain.
• Bridge Domain Tag—the Panorama tag associated with each bridge domain.
• Dynamic Address Group—displays the dynamic address groups associated
with the listed tag.
• In Policy—shows if the listed dynamic address group is used in policy.
Service Graphs Displays the total number of Service Graphs monitored by the plugin as well as
well as the number of firewalls in line with monitored service graphs.
Click the tile to drill down and view the following columns.
• Service Graph Name—lists all service graphs retrieved by Panorama.
• Producer EPG—displays the producer EPG associated with the service
graph.
• FW InLine—displays the firewall associated with the service graph.
743
744 VM-SERIES DEPLOYMENT GUIDE | Set Up the VM-Series Firewall on Cisco CSP
© 2021 Palo Alto Networks, Inc.
VM-Series on Cisco CSP System Requirements
You can create and deploy multiple instances—standalone or as an HA pair—of the VM-Series firewall on
your Cisco CSP.
The VM-Series firewall has the following requirements:
• See the Compatibility Matrix for supported versions of CSP and PAN-OS.
• Bootstrap Package converted to a ISO file
• See VM-Series System Requirements for the minimum hardware requirements for your VM-Series
model.
• Minimum of two network interfaces (vNICs). One is a dedicated vNIC for the management interface and
one is for the data interface. You can then add up to eight more vNICs for data traffic.
• The VM-Series firewall on Cisco CSP supports all VM-Series models except the VM-50.
• SR-IOV and packet MMAP mode only; DPDK is not supported.
VM-SERIES DEPLOYMENT GUIDE | Set Up the VM-Series Firewall on Cisco CSP 745
© 2021 Palo Alto Networks, Inc.
Deploy the VM-Series Firewall on Cisco CSP
Complete the following procedure to deploy the VM-Series firewall on Cisco CSP.
STEP 1 | Download the VM-Series qcow2 base image file from the Customer Support Portal.
STEP 4 | Upload the VM-Series firewall qcow2 image and ISO file.
1. Select Configuration > Repository.
2. Click the plus (+) icon.
3. Click Browse and navigate to your qcow2 file.
4. Click Upload.
5. Click Browse and navigate to your ISO file.
6. Click Upload.
746 VM-SERIES DEPLOYMENT GUIDE | Set Up the VM-Series Firewall on Cisco CSP
© 2021 Palo Alto Networks, Inc.
5. Allocate the number of cores and memory required for your VM-Series firewall model.
6. Add enough vNICs to support the number of VM-Series interfaces configured in your bootstrap ISO
file.
See the Cisco Cloud Service Platform documentation for more information about creating and deploying
a service instance.
STEP 6 | After the bootstrap process is complete, log in to your VM-Series firewall using the
management IP address your specified in the bootstrap ISO file.
The firewall should be up and configure based on the parameters you defined in the bootstrap package.
VM-SERIES DEPLOYMENT GUIDE | Set Up the VM-Series Firewall on Cisco CSP 747
© 2021 Palo Alto Networks, Inc.
748 VM-SERIES DEPLOYMENT GUIDE | Set Up the VM-Series Firewall on Cisco CSP
Endpoint Monitoring for Cisco TrustSec
Install and configure the Panorama plugin for Cisco TrustSec to retrieve the IP addresses of
endpoints in your environment and build security policy for those endpoints using Dynamic
Address Groups.
749
750 VM-SERIES DEPLOYMENT GUIDE | Endpoint Monitoring for Cisco TrustSec
© 2021 Palo Alto Networks, Inc.
Panorama Plugin for Cisco TrustSec
The Panorama plugin for Cisco TrustSec enables you to create security policy for your TrustSec
environment using dynamic address groups. The plugin monitors for changes in TrustSec security groups
and registers that information with Panorama and forwards IP information to the firewall, so Panorama can
apply the correct policy to corresponding endpoints. The Panorama plugin for Cisco TrustSec supports up to
16 pxGrid (Cisco ISE) servers.
The Panorama plugin processes the endpoint information and converts it to a set of tags that you can use as
match criteria for placing IP addresses in dynamic address groups. Panorama creates a tag for each security
group tag (SGT) on your pxGrid servers. The tags are constructed in the following format:
cts.svr_<pxgrid-server-name>.sgt_<SGT-name>
To retrieve endpoint IP-address-to-tag mapping information, you must configure a Monitoring Definition
for each pxGrid server in your environment. The pxGrid server configuration specifies the username and
password and is referenced by the monitoring definition that allows Panorama to connect to the pxGrid.
Additionally, you can configure the plugin to verify the pxGrid server identity with a certificate profile on
Panorama. It also specifies the device groups and corresponding notify groups containing the firewalls to
which Panorama pushes the tags. After you configure the Monitoring Definition and the plugin retrieves the
tags, you can create dynamic address groups and add the tags as match criteria.
The Panorama Plugin for Cisco TrustSec version 1.0.2 and later supports Bulk Sync and PubSub monitoring
modes. The plugin selects a mode based on the Panorama version—Bulk Sync mode if the Panorama version
is earlier than 10.0.0, and PubSub mode on Panorama 10.0.0 and later. The user interface displays the
configuration options for the default monitoring mode.
• Bulk Sync
• PubSub
Bulk Sync
Bulk Sync mode uses two intervals to retrieve information from your pxGrid servers—the monitoring
interval and full-sync interval. This mode is the default when the Panorama Plugin for Cisco TrustSec
version 1.0.2 or later is installed on a Panorama version earlier than 10.0.0. Panorama versions earlier than
10.0.0 support IP-tab updates to configd every 10 seconds.
• Monitoring interval—The monitoring interval is the amount of time that the plugin waits before querying
for changes. If no changes have occurred, the monitoring interval resets. If there are changes, the plugin
processes the changes before resetting the monitoring interval. The default monitoring interval is 60
seconds. You can set the monitoring interval from 10 seconds to one day (86,400 seconds).
The minimum monitoring interval is 30 seconds when the Panorama plugin for Cisco
TrustSec 1.0.0 is installed.
• Full-sync interval—The full-sync interval is the amount of time that the plugin waits before updating the
dynamic objects from all pxGrid servers regardless of any changes occurred. This ensures that the plugin
is synchronized with the pxGrid server even if a change event is missed by the monitoring interval. You
can set the full-sync interval from 600 seconds (10 minutes) to 86,400 seconds (one day). You must
configure the full-sync interval from the Panorama CLI.
If the monitoring interval is greater than the full-sync interval, the full-sync interval is ignored
and a full synchronization is performed at every monitoring interval.
If you have a Panorama HA configuration, repeat this installation process on each Panorama peer. When
installing the plugin on Panorama appliances in an HA pair, install the plugin on the passive peer before
the active peer. After installing the plugin on the passive peer, it will transition to a non-functional state.
Installing the plugin on the active peer returns the passive peer to a functional state.
STEP 2 | Click Check Now to get the latest version of the plugin.
STEP 4 | Select the version of the plugin and click Install in the Action column to install the plugin.
Panorama will alert you when the installation is complete.
STEP 1 | Configure the full-sync interval if you want to change it from the default 600 seconds (10
minutes).
1. Log in to the Panorama CLI.
2. Enter configure mode.
admin@Panorama> configure
3. Use the following command to set the full-sync interval. The range is 600 seconds to 86,400 seconds
(one day).
admin@Panorama# set plugins cisco_trustsec full-sync-interval <interval-
in-seconds>
STEP 3 | You must add the firewalls as managed devices on Panorama and create Device Groups so
that you can configure Panorama to notify these groups with the VM information it retrieves.
Device groups can include VM-Series firewalls or virtual systems on the hardware firewalls.
The plugin selects Bulk Sync mode when it is installed on a Panorama version earlier than 10.0.0:
STEP 6 | (Optional) If enabling server identity verification of the pxGrid server, configure a certificate
profile on Panorama.
STEP 7 | Create, activate, and approve the pxGrid client name and client password.
1. Log in to the Panorama CLI.
2. Execute the following command to create the client name.
• If you have a certificate profile, create the client name as follows:
AccountCreate in progress...
AccountCreate successful.
client nodename: test
client password: PmVKBmPgf63Hypq
AccountActivate in progress...
AccountActivate successful.
STEP 8 | Add pxGrid server information. The Panorama plugin for Cisco TrustSec supports up to 16
pxGrid (Cisco ISE) servers.
1. Select Panorama > Cisco TrustSec > Setup > pxGrid Server.
2. Enter a descriptive Name for your pxGrid server.
3. In the Host field, enter the IP address or FQDN for your pxGrid server.
4. Enter the client name you created in the previous step.
5. Enter and confirm the client password you generated in the previous step.
6. Verify the pxGrid server identity.
1. Select Verify server certificate.
2. Select your certificate profile from the Cert Profile drop-down.
7. Click OK.
STEP 11 | Create active ISE sessions so that Panorama can learn SGT tags for dynamic address group
definition. To create active sessions, use ISE to authenticate devices.
Panorama does not collect default SGT tags on ISE.
STEP 12 | Create dynamic address groups and verify that addresses are added to dynamic address
groups.
1. Select Objects > Address Groups.
2. Select the Device Group you created for monitoring endpoints in your Cisco TrustSec environment
from the Device Group drop-down.
3. Click Add and enter a Name and Description for the dynamic address group.
Dynamic address groups are empty until you attach them to a policy. You won’t see any
IP addresses in your dynamic address group unless a policy is using it.
STEP 14 | (Optional) Update the dynamic objects from the pxGrid server at any time by synchronizing
dynamic objects. Synchronizing dynamic objects enables you to maintain context on changes
in the virtual environment and allows you to enable applications by automatically updating
the dynamic address groups used in policy rules.
1. Select Panorama > Cisco TrustSec > Monitoring Definition.
2. Click Synchronize Dynamic Objects.
Debug Commands
• Check IP addresses in dynamic address groups.
/opt/plugins/var/log/pan/plugin_cisco_trustsec.log
/opt/plugins/var/log/pan/plugin_cisco_trustsec_sub.log
/opt/plugins/var/log/pan/plugin_cisco_trustsec_ret.log
/opt/plugins/var/log/pan/plugin_cisco_trustsec_proc.log
The size limit for a log file (shared by all plugins installed on your Panorama device) is 10 million bytes. A
log file can accept 93,000 session logins. If you configure log rotation, a backup log can support 186,000
session logins.
• Change the plugin debug level.
763
764 VM-SERIES DEPLOYMENT GUIDE | Set Up the VM-Series Firewall on Nutanix AHV
© 2021 Palo Alto Networks, Inc.
VM Monitoring on Nutanix
Install and configure the Panorama plugin for Nutanix to monitor changes in your Nutanix environment and
build policy using dynamic address groups.
• About VM Monitoring on Nutanix
• Install the Panorama Plugin for Nutanix
• Configure the Panorama Plugin for Nutanix
In the example above, we have two categories—Dev and HR—with two values within each of them. And
these categories are within the cluster, which is within Prism Central. After you begin monitoring your
Nutanix environment, Panorama uses value, category, cluster, and Prism Central to form tags. When you
view the match criteria for dynamic address groups, the tags are listed in the following format.
ntnx.PC-<prism-central-name>.CL-<cluster-name>.<category>.<value>
With the information in the example above, Panorama creates the following tags.
ntnx.PC-PrismCentralHQ.CL-ClusterAlpha.Dev.Engineering
ntnx.PC-PrismCentralHQ.CL-ClusterAlpha.Dev.QA
ntnx.PC-PrismCentralHQ.CL-ClusterAlpha.HR.Recruiting
ntnx.PC-PrismCentralHQ.CL-ClusterAlpha.HR.Benefits
To secure these workloads in these categories, use tags such as these as match criteria in the dynamic
address groups. You can then use the dynamic address groups as source and destination address groups in
VM-SERIES DEPLOYMENT GUIDE | Set Up the VM-Series Firewall on Nutanix AHV 765
© 2021 Palo Alto Networks, Inc.
your security policy rules. When a virtual machine joins a dynamic address group, the policy your created is
applied automatically.
STEP 5 | Select the version of the plugin and click Install in the Action column to install the plugin.
Panorama will alert you when the installation is complete.
766 VM-SERIES DEPLOYMENT GUIDE | Set Up the VM-Series Firewall on Nutanix AHV
© 2021 Palo Alto Networks, Inc.
STEP 4 | Add Prism Central information.
1. Select Panorama > Nutanix > Setup > Nutanix Prism Central.
2. Click Add.
3. Enter a descriptive Name for your Prism Central.
4. Enter the IP address or FQDN for Prism Central.
5. Enter your Prism Central username.
6. Enter and confirm your Prism Central password.
7. Click Validate to confirm that you entered the Prism Central credentials correctly.
If you return to the Nutanix Prism Central Info window after clicking OK, clicking the
Validate button returns a credential validation error message. This is the expected
behavior. Although Panorama displays dots in the password field, the field is empty;
this causes the validation to fail despite Panorama being successfully connected to
Prism Central.
8. Click OK.
VM-SERIES DEPLOYMENT GUIDE | Set Up the VM-Series Firewall on Nutanix AHV 767
© 2021 Palo Alto Networks, Inc.
STEP 6 | Commit your changes.
STEP 7 | Verify that you can view the VM information on Panorama, and define the match criteria for
dynamic address groups.
1. Select Panorama > Objects > Address Groups and click Add.
2. Enter a descriptive Name for your dynamic address groups.
3. Select Dynamic from the Type drop-down.
4. Click Add Match Criteria. You can select dynamic tags as the match criteria to populate the members
of the group. Select the And or Or operator and select the attributes that you would like to filter for
or match against. and then click OK.
5. Commit your changes.
STEP 8 | Verify that addresses in your VMs are added to dynamic address groups.
1. Select Panorama > Objects > Address Groups.
2. Click More in the Addresses column of a dynamic address group.
Panorama displays a list of IP addresses added to that dynamic address group based on the match
criteria you specified.
768 VM-SERIES DEPLOYMENT GUIDE | Set Up the VM-Series Firewall on Nutanix AHV
© 2021 Palo Alto Networks, Inc.
6. Specify the action— Allow or Deny—for the traffic, and optionally attach the default security profiles
to the rule.
7. Repeat Steps 1 through 6 to create another policy rule.
8. Click Commit.
VM-SERIES DEPLOYMENT GUIDE | Set Up the VM-Series Firewall on Nutanix AHV 769
© 2021 Palo Alto Networks, Inc.
770 VM-SERIES DEPLOYMENT GUIDE | Set Up the VM-Series Firewall on Nutanix AHV
Bootstrap the VM-Series Firewall
Bootstrapping allows you to create a repeatable and streamlined process of deploying new
VM-Series firewalls on your network because it allows you to create a package with the model
configuration for your network and then use that package to deploy VM-Series firewalls
anywhere.
You can either bootstrap the firewall with complete configuration so that the firewall is
fully configured at startup, or you can begin with a basic configuration—a minimal initial
configuration that enables you to boot the firewall and then register with Panorama to
complete the configuration.
If you choose the basic configuration and you are deploying on AWS, Azure or GCP, you can
use the bootstrap package and an init-cfg.txt file. Alternatively, you can bootstrap with
user data. Instead of providing bootstrap configuration parameters in files, you enter them
as key-value pairs directly into the AWS or GCP user interface when you launch a VM-Series
firewall. Azure has a similar process with which you provide the bootstrap parameters in a
template or other text file accessed from the Azure CLI.
If you create the bootstrap package, you deliver it from an external device (such as a virtual
disk, a virtual CD-ROM, or a cloud storage device (such as a bucket).
771
772 VM-SERIES DEPLOYMENT GUIDE | Bootstrap the VM-Series Firewall
© 2021 Palo Alto Networks, Inc.
Choose a Bootstrap Method
You can bootstrap the VM-Series firewall with a basic configuration or a complete configuration.
A complete configuration uses the bootstrap package and includes everything you need to fully configure
the firewall at boot up. This includes configuration parameters (in init-cfg.txt), content updates, and
software versions. A complete configuration can include both init-cfg.txt and bootstrap.xml files.
Specify complete configuration Public cloud storage • Full bootstrap package in the
information in /config/ storage bucket.
AWS S3 bucket, Azure storage
bootstrap.xml in the bootstrap • Requires cloud storage and an
account, or Google storage
package. IAM role to access it.
bucket.
A basic configuration is a minimal configuration that enables you to launch, license, and register the
VM-Series firewall. The basic configuration does not support plugins, content, software images, or
bootstrap.xml.
After you boot the firewall you can connect with Panorama to complete the configuration, or log in to the
firewall to update content and software manually. The following table briefly contrasts three ways you can
store and access a basic configuration:
AWS Secret Manager Encrypted in AWS Secret • You need an IAM role to create
Manager. a secret. Others can be granted
Enter configuration parameters
permission to get the secret.
into the AWS secret manager
as key-value pairs. • To get the secret, pass the
secret name using user data.
See the VM-Series firewall bootstrap workflow to compare the workflow for the basic and complete
configurations.
• Basic Configuration
• Complete Configuration
type=dhcp-client; op-command-modes=mgmt-interface-swap,jumbo-frame;
vm-series-auto-registration-pin-id=abcdefgh1234****;
vm-series-auto-registration-pin-value=zyxwvut-0987****
type=dhcp-client
op-command-modes=mgmt-interface-swap,jumbo-frame
vm-series-auto-registration-pin-id=abcdefgh1234****
vm-series-auto-registration-pin-value=zyxwvut-0987****
• Azure Custom Data—semicolon. If a parameter has more than one option, separate options with a
comma. For example:
type=dhcp-client; op-command-modes=jumbo-frame;
vm-series-auto-registration-pin-id=abcdefgh1234****;
vm-series-auto-registration-pin-value=zyxwvut-0987****
• GCP Custom Metadata—In a file, such as a YAML file or Terraform template, use a newline (\n) for each
parameter, and if a parameter has multiple options, use commas to separate them. For example:
type=dhcp-client
op-command-modes=mgmt-interface-swap,jumbo-frame
vm-series-auto-registration-pin-id=abcdefgh1234****
vm-series-auto-registration-pin-value=zyxwvut-0987****
• Oracle Cloud Infrastructure User Data—Use a newline (\n) for each parameter, and if a parameter has
multiple options, use commas to separate them.
{
"Version": "2012-10-17",
{
"Effect": "Allow",
"Action": "secretsmanager:GetSecretValue",
"Resource":
"arn:aws:secretsmanager:us-east-1:688382******:secret:My_bts-******"
}
}
Refer to Actions, Resources, and Context Keys You Can Use in an IAM Policy or Secret Policy for AWS
Secrets Manager to see actions that require permission, such as list, get, and rotate secret.
• (Optional) To encrypt the secret you can use the DefaultEncryptionKey from AWS Secrets Manager.
STEP 1 | Log in to the AWS console and under Security, Identity and Compliance, select Secrets
Manager and select Store a new secret.
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "VisualEditor0",
"Effect": "Allow",
"Action": "s3:ListBucket",
"Resource": "arn:aws:s3:::sn-bootstrap"
},
{
"Sid": "VisualEditor1",
"Effect": "Allow",
"Action": "s3:GetObject",
"Resource": "arn:aws:s3:::sn-bootstrap/*"
},
{
"Effect": "Allow",
"Action": "secretsmanager:GetSecretValue",
"Resource": "arn:aws:secretsmanager:us-east-1:688382******:
secret:My_bootstrap"
}
]
}
2. (Optional) You can examine the secret from the command line (if you have permission). For example:
Complete Configuration
A complete configuration ensures the firewall is fully configured on boot up. The bootstrap.xml file includes
the initial configuration, licenses, software, content, and a version of the VM-Series plugin. You can
create bootstrap.xml manually or you can export an existing configuration, as described in Create the
bootstrap.xml File.
STEP 1 | (Optional) For security reasons, you can only bootstrap a firewall when it is in factory default
state. If you want to use the bootstrap package to bootstrap a VM-Series firewall that has been
previously configured, reset the firewall to factory default settings.
STEP 3 | (Optional) If you want to use Panorama to manage the VM-Series firewalls being bootstrapped,
generate the VM auth key on Panorama. You must include this key in the init-cfg.txt file
(vm-auth-key) or enter the key-value pair as user data.
STEP 5 | If you choose the basic configuration and you plan to bootstrap with user data, skip to Step 7.
If you plan to use the basic configuration and the bootstrap package, create the init-cfg.txt file and
prepare the bootstrap package.
If you choose the complete configuration, create the bootstrap.xml file and prepare the full bootstrap
package.
STEP 6 | Prepare the bootstrap package and save the bootstrap package in the appropriate delivery
format for your hypervisor.
If you intend to pre-register VM-Series firewalls with Panorama with bootstrapping, you
must generate a VM auth key on Panorama and include the generated key in the init-
cfg.txt file. See Generate the VM Auth Key on Panorama.
• /license folder—Contains the license keys or auth codes for the licenses and subscriptions that you
intend to activate on the firewalls. If the firewall does not have Internet connectivity, you must either
manually obtain the license keys from the Palo Alto Networks Support portal or use the Licensing
API to obtain the keys and then save each key in this folder. For details, see Prepare the Licenses for
Bootstrapping.
You must include an auth code bundle instead of individual auth codes so that the firewall
or orchestration service can simultaneously fetch all license keys associated with a
firewall. If you use individual auth codes instead of a bundle, the firewall will retrieve only
the license key for the first auth code included in the file.
• /software folder—Contains the software images required to upgrade a newly provisioned VM-Series
firewall to the desired PAN-OS version for your network. You must include all intermediate software
versions between the current version and the final PAN-OS software version to which you want to
upgrade the VM-Series firewall. Refer to VM-Series Firewall Hypervisor Support in the Compatibility
Matrix.
• /content folder—Contains the application and threat updates, WildFire updates, and the BrightCloud
URL filtering database for the valid subscriptions on the VM-Series firewall. You must include the
minimum content versions required for the desired PAN-OS version. If you do not have the minimum
required content version associated with the PAN-OS version, the VM-Series firewall cannot complete
the software upgrade.
• /plugins folder—Optional folder contains a single VM-Series plugin image.
External Device for Bootstrapping AWS Azure ESXi Google Hyper-V KVM
(Bootstrap Package Format)
When you attach the storage device to the firewall, the firewall scans for a bootstrap package and, if one
exists, the firewall uses the settings defined in the bootstrap package.
If you have included a Panorama server IP address in the file, the firewall connects with Panorama. If the
firewall has Internet connectivity, it contacts the licensing server to update the UUID and obtain the license
keys and subscriptions. The firewall is then added as an asset in the Palo Alto Networks Support portal. If
the firewall does not have Internet connectivity, it either uses the license keys you included in the bootstrap
package, or it connects to Panorama to retrieve the appropriate licenses and deploys them to the managed
firewalls.
init-cfg.txt
Contains basic information for configuring the management interface on the firewall, such as the IP address
type (static or DHCP), IP address (IPv4 only or both IPv4 and IPv6), netmask, and default gateway. The DNS
server IP address, Panorama IP address and device group and template stack parameters are optional.
You can use the generic name init-cfg.txt, or to be more specific, you can prepend the UUID or Serial
number of each firewall to the filename (for example: 0008C100105-init-cfg.txt).
When the firewall boots, it searches for a text file that matches its UUID or serial number and, if none is
found, it searches using the generic filename init-cfg.txt. For a sample file, see Create the init-cfg.txt
File.
bootstrap.xml
The optional bootstrap.xml file contains a complete configuration for the firewall. If you are not using
Panorama to centrally manage your firewalls, the bootstrap.xml file provides a way to automate the
process of deploying firewalls that are configured at launch.
You can define the configuration manually or export the running configuration (running-config.xml)
from an existing firewall and save the file as bootstrap.xml. If you export bootstrap.xml file,
make sure to export the XML file from a firewall deployed on the same platform or hypervisor as your
deployment. See Create the bootstrap.xml File.
For example to generate a key that is valid for 24 hrs, enter the following:
STEP 2 | Verify the validity term of the VM auth key(s) you generated on Panorama. Make sure that the
validity term allows enough time for the firewall(s) to register with Panorama.
https://<Panorama_IP_address>/api/?type=op&cmd=<request><bootstrap><vm-auth-
key><show></show></vm-auth-key></bootstrap></request>
STEP 2 | Add the basic network configuration for the management interface on the firewall.
If any of the required parameters are missing in the file, the firewall exits the bootstrap
process and boots up using the default IP address, 192.168.1.1. You can view the system
log on the firewall to detect the reason for the bootstrap failure. For errors, see Licensing
API.
There are no spaces between the key and value in each field. Do not add spaces as they
could cause failures during parsing on the mgmtsrvr side.
• To configure the management interface with a static IP address, you must specify the IP address,
type of address, default gateway, and netmask. An IPv4 address is required, IPv6 address is optional.
For syntax, see Sample init-cfg.txt File.
• To configure the management interface as a DHCP client, you must specify only the type of address.
If you enable the DHCP client on the management interface, the firewall ignores the IP address,
default gateway, netmask, IPv6 address, and IPv6 default gateway values defined in the file. For
syntax, see Sample init-cfg.txt File.
When you enable DHCP on the management interface, the firewall takes the DHCP assigned IP
address and is accessible over the network. You can view the DHCP assigned IP address on the
General Information widget on the Dashboard or with the CLI command show system info.
However, the default static management IP address 192.168.1.1 is retained in the running configuration
(show config running) on the firewall. This static IP address ensures that you can always restore
connectivity to your firewall, in the event you lose DHCP access to the firewall.
STEP 3 | Add the VM auth key to register a VM-Series firewall with Panorama.
To add a VM-Series firewall on Panorama, you must add the VM auth key that you generated on
Panorama to the basic configuration (init-cfg.txt) file. For details on generating a key, see Generate
the VM Auth Key on Panorama.
STEP 5 | (Recommended) Add the VM-Series registration pin and value for installing the device
certificate.
Field Description
ip-address= IPv4 address. This field is ignored if the type is dhcp-client. If the type is
static, an IPv4 address is required; the ipv6-address field is optional and can
be included.
You cannot specify the management IP address and netmask configuration
for the VM-Series firewall in AWS and Azure. If defined, the firewall ignores
the values you specify.
default-gateway= IPv4 default gateway for the management interface. This field is ignored if
the type is dhcp-client. If the type is static, and ip-address is used, this field is
required.
netmask= IPv4 netmask. This field is ignored if the type is dhcp-client. If the type is
static, and ip-address is used, this field is required.
ipv6-address= (Optional) IPv6 address and /prefix length of the management interface. This
field is ignored if the type is dhcp-client. If the type is static, this field can be
specified along with the ip-address field, which is required.
ipv6-default-gateway= IPv6 default gateway for the management interface. This field is ignored if
the type is dhcp-client. If the type is static and ipv6-address is used, this field
is required.
panorama-server= IPv4 or IPv6 address of the primary Panorama server. This field is not
required but recommended for centrally managing your firewalls.
panorama-server-2= IPv4 or IPv6 address of the secondary Panorama server. This field is not
required but recommended.
tplname= Panorama template stack name. If you add a Panorama server IP address, as
a best practice assign the firewall to a template stack on Panorama and enter
the template stack name in this field so that you can centrally manage and
push configuration settings to the firewall.
dgname= Panorama device group name. If you add a Panorama server IP address, as a
best practice create a device group on Panorama and enter the device group
name in this field so that you can group the firewalls logically and push policy
rules to the firewall.
cgname= Panorama collector group name. If you want to bootstrap the firewall to
send logs to a Panorama collector group, you must first configure a collector
group on Panorama and then configure the firewall to forward logs to
Panorama.
On the M-Series appliances, a default Collector Group is predefined and
already contains the local Log Collector as a member. On the Panorama
virtual appliance, you must add the Collector Group and add the local Log
Collector as a member.
vm-auth-key= Virtual machine authentication key for Panorama (see Generate the VM
Auth Key on Panorama). This field is ignored when bootstrapping hardware
firewalls.
op-cmd-dpdk-pkt-io= The value on or off allows you to enable or disable Data Plane
Development Kit (DPDK) in environments where the firewall supports
DPDK. DPDK allows the host to process packets faster by bypassing the
Linux kernel; interactions with the NIC are performed using drivers and the
DPDK libraries.
dhcp-send-hostname= The value of yes or no comes from the DHCP server. If yes, the firewall will
send its hostname to the DHCP server. This field is relevant only if type is
dhcp-client.
dhcp-send-client-id= The value of yes or no comes from the DHCP server. If yes, the firewall will
send its client ID to the DHCP server. This field is relevant only if type is
dhcp-client.
dhcp-accept-server- The value of yes or no comes from the DHCP server. If yes, the firewall will
hostname= accept its hostname from the DHCP server. This field is relevant only if type
is dhcp-client.
dhcp-accept-server- The value of yes or no comes from the DHCP server. If yes, the firewall will
domain= accept its DNS server from the DHCP server. This field is relevant only if
type is dhcp-client.
vm-series-auto- The VM-Series registration PIN ID and value for installing the device
registration-pin-id certificate on the VM-Series firewall. The PIN ID and value also enable you
to automatically activate the site licenses for AutoFocus and Cortex Data
and
Lake on PAYG instances of the firewall.
vm-series-auto-
You must generate this in registration PIN ID and value on the Palo Alto
registration-pin-value
Networks CSP. See Install a Device Certificate on the VM-Series Firewall for
information on generating PIN ID and value.
Sample init-cfg.txt file (Static IP Address) Sample init-cfg.txt file (DHCP Client)
type=static type=dhcp-client
You cannot specify the management IP address and netmask configuration for the VM-
Series firewall on AWS. If defined, the firewall ignores the values you specify because AWS
uses a back-end metadata file to assign the management IP address and netmask.
*The IPv6 default gateway is required if you include an IPv6 address.
**The mgmt-interface-swap operational command pertains only to a VM-Series firewall
on AWS or GCP.
***The op-cmd-dpdk-pkt-io=off is for disabling DPDK on the VM-Series firewall on
ESXi, KVM, and GCP (DPDK is enabled by default).
**** The vm-series-auto-registration-pin-id and vm-series-auto-
registration-pin-value are required for two use cases:
• Activation of site licenses—AutoFocus or Cortex Data Lake—with Pay-As-You-Go
(PAYG) license options of the VM-Series firewall.
• Retrieve and install the device certificate on the VM-Series firewall.
• For a custom script or an orchestration service that can access the Internet on behalf of
firewalls.
The script or service must fetch the CPU ID and the UUID from the hypervisor on which the firewall is
deployed and access the Palo Alto Networks Support portal with CPU ID, UUID, API key and the auth
code to obtain the required keys. See Licensing API.
STEP 1 | Create the top-level directory structure for the bootstrap package.
On your local client or laptop, or in a public cloud storage bucket, create the following folders:
/config
/content
/software
/license
/plugins
You can leave a folder empty, but you must have /config, /license, /software, and /content
folders. The /plugins folder is optional, and only required if you are upgrading the VM-Series plugin
independent of a PAN-OS release.
Do not place any other files or folders in the bootstrap structure. Adding other files or folders will result
in a bootstrapping failure.
/my-storage
/my-firewalls
/internal /external
/config /config
/content /content
/license /license
/plugins /plugins
/software /software
/config
0008C100105-init-cfg.txt
0008C100107-init-cfg.txt
bootstrap.xml
/content
panupv2-all-contents-488-2590
panup-all-antivirus-1494-1969
panup-all-wildfire-54746-61460
• If you save the keys to the license folder, you can use a file naming convention that
works for you, but keep the .key extension in the filename. For auth codes, create a
text file named authcodes (without a file extension), add your auth codes to that file,
and save it to the license folder.
• Use an auth code bundle instead of individual auth codes so that the firewall or
orchestration service can simultaneously fetch all license keys associated with a
firewall. If you use individual auth codes instead of a bundle, the firewall will retrieve
only the license key for the first auth code included in the file.
• In the /plugins folder, supply only one VM-Series plugin binary. Do not supply
multiple plugin versions.
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": ["s3:ListBucket"],
"Resource": ["arn:aws:s3:::<bucketname>"]
},
{
"Effect": "Allow",
"Action": ["s3:GetObject"],
"Resource": ["arn:aws:s3:::<bucketname>/*"]
}
]
}
3. Create the folders within the S3 bucket as described in Prepare the Bootstrap Package.
• Create the structure directly in your S3 bucket.
If you have enabled logging in Amazon S3, a Logs folder is automatically created
in the S3 bucket. The Logs folder helps troubleshoot issues with access to the S3
bucket.
STEP 3 | Launch the VM-Series firewall on AWS. Choose one of the following.
• init-cfg.txt—If you are using a file to configure the firewall, attach the IAM role you created in
Step 2.1, expand the Advanced Details section, and in the User Data field, specify the path to an S3
bucket, directory, or subdirectory. For example,
vmseries-bootstrap-aws-s3bucket=<bucketname>
or
vmseries-bootstrap-aws-s3bucket=<bucketname/directoryname>
• User Data—If you are using user data to configure the firewall, expand the Advanced Details section
and in the User Data field enter the initial bootstrap parameters as described in Enter a Basic
Configuration as User Data (Public Clouds).
• AWS Secrets Manager—If you stored your basic configuration as described in Save a Basic
Configuration in the AWS Secrets Manager, expand the Advanced Details section and in the User
Data field choose As text and enter the secret name as a key-value pair. For example:
STEP 4 | Verify Bootstrap Completion. Select the firewall instance on the AWS Management console
and choose Actions > Instance Settings > Get Instance Screenshot.
• The screenshot shows bootstrapping in progress. A successful bootstrap is shown below:
1. If you choose to use the bootstrap package, select Enable Bootstrap: Yes and provide the
information required to access the file share that holds the bootstrap files.
1. Storage Account Name— This is the Azure storage account in which you created the file share for
the bootstrap folders.
2. Storage Account Access Key—The firewall needs this access key to authenticate to the storage
account and access the files stored within. To copy this access key, select the storage account
name, and then select Settings > Access Keys.
type=dhcp-client; op-command-modes=jumbo-frame;
vm-series-auto-registration-pin-id=abcdefgh1234****;
vm-series-auto-registration-pin-value=zyxwvut-0987****
Provide custom data using one of the methods in Custom data and Cloud-Init on Azure Virtual
Machines.
STEP 1 | Create an ISO image and upload it to a Virtual Machine File System (VMFS) datastore or to a
Network File System (NFS) volume.
1. Prepare the Bootstrap Package.
2. Create an ISO image. The tool you use to create the image varies based on your client operating
system.
3. Upload the ISO image to a VMFS datastore or to an NFS volume that is accessible to the ESX/ESXI
host.
STEP 1 | Create the bootstrap package and the virtual hard disk.
1. Create the bootstrap package.
2. Deploy a Linux virtual machine.
3. On the Linux machine, Prepare the Bootstrap Package. You can leave the folder empty, but you must
have all four folders.
4. Attach a new data disk less than 39 GB to the Linux virtual machine.
5. Partition the disk and format the file system as ext3.
6. Make a directory for the new file system and mount the disk to the Linux virtual machine.
7. Copy the contents of your bootstrap package to the disk.
8. Unmount the disk.
6. (Optional) If you created an init-cfg.txt file, open the config folder. Click Upload Files, browse
to select your init-cfg.txt file, and click Open.
7. Open the license folder and upload the authcodes file.
8. Continue until you have uploaded all the bootstrap files.
STEP 4 | Add the initial configuration parameters as metadata. Add each key-value pair as described in
Enter a Basic Configuration as User Data (Public Clouds).
STEP 1 | Create the bootstrap package and the virtual hard disk.
1. Deploy a Linux virtual machine.
2. On the Linux machine, Prepare the Bootstrap Package. You can leave the folder empty, but you must
have all four folders.
3. Attach a new data disk less than 39 GB to the Linux virtual machine.
1. Power of the Linux virtual machine.
2. In Hyper-V, select the Linux virtual machine from the Virtual Machines list.
3. Select Settings > Hardware > IDE Controller.
4. Select Hard Drive and click Add.
5. Select Virtual Hard Disk and click New.
STEP 1 | Create the bootstrap package and the virtual hard disk.
1. Create the bootstrap package.
2. Create a new disk image less than 39 GB in size and partition the disk and format the file system as
ext3. The tools used to complete this process vary based on your client operating system.
3. Mount the disk image file and copy the prepared bootstrap package to the disk image files.
4. Copy the contents of your bootstrap package to the disk.
5. Unmount the disk image.
STEP 1 | If you included panorama-server, tplname, and dgname in your init-cfg.txt file, check
Panorama managed devices, the device group, and the template name.
STEP 2 | Verify the general system settings and configuration. Access the web interface and select
Dashboard > Widgets > System or use the CLI operational commands show system info and
showconfig running.
STEP 3 | Verify the license installation. Select Device > Licenses or use the CLI operational command
request license info.
STEP 4 | If you have Panorama configured, manage the content versions and software versions from
Panorama. If you do not have Panorama configured, use the web interface to manage content
versions and software versions.
Boot image error (high) • No external device was detected with the bootstrap package.
Or
• A critical error happened while booting from the image on the
external device. The bootstrap process was aborted.
No bootstrap config file on The external device did not have the bootstrap configuration file.
external device (high)
Bad or no parameters for The networking parameters required for bootstrapping were either
mandatory networking incorrect or missing. The error message lists the value—IP address,
information in the netmask, default gateway—that caused the bootstrap failure.
bootstrap config file (high)
Failed to install license The license key could not be applied. This error indicates that the
key for file <license-key- license key used was invalid. The output includes the name of the
filename> (high) license key that could not be applied.
Failed to install license The license auth code could not be applied. This error indicates that the
key using authcode license auth code used was invalid. The output includes the name of
<authcode> (high) the authcode that could not be applied.
Failed content update The content updates were not successfully applied.
commits (high)
USB media prepared The bootstrap image has been successfully complied on the USB flash
successfully using given device. <username>: Successfully prepared the USB using bundle
bundle (informational) <bundlename>
Successful bootstrap The firewall was successfully provisioned with the bootstrap
(informational) configuration file. The output includes the license keys installed
and the filename of the bootstrap configuration. On the VM-Series
firewalls only, the PAN-OS version and content update version are also
displayed.
Read about the Bootstrap Package and how to Prepare the Bootstrap Package.