Azure Deployment Guide Shared R1 Aug 2018
User Manual:
Open the PDF directly: View PDF 
.
Page Count: 150 [warning: Documents this large are best viewed by clicking the View PDF Link!]
- Purpose of This Guide
- Objectives
- Deployment Overview
- Design Models
- Assumptions and Prerequisites
- Deployment Details for Panorama
- Deployment Details for VM-Series
- Deployment Details for Azure Networking and Firewall Policies
- Deployment Details for Backhaul Connection
- Deployment Details for Automated Bootstrapping
- What’s New in This Release
DEPLOYMENT GUIDE FOR
MICROSOFT AZURE—
SHARED DESIGN MODEL
RELEASE 1
AUGUST 2018
Palo Alto Networks
Table of Contents
Table of Contents
Purpose of This Guide ........................................................................................................................................................ 1
Objecves .............................................................................................................................................................................................................. 1
Audience ................................................................................................................................................................................................................ 2
Related Documentaon ..................................................................................................................................................................................... 2
Deployment Overview ....................................................................................................................................................... 3
Choosing A Design Model ................................................................................................................................................................................. 3
Design Models ..................................................................................................................................................................... 4
Shared Design Model .......................................................................................................................................................................................... 4
Assumpons and Prerequisites........................................................................................................................................ 9
Deployment Details for Panorama ................................................................................................................................10
Creang and Conguring Azure Common Resources ...............................................................................................................................10
Deploying Panorama on Azure ....................................................................................................................................................................... 21
Deployment Details for VM-Series ...............................................................................................................................37
Creang and Conguring Azure Common Resource for VM-Series .......................................................................................................38
Deploying VM-Series on Azure ......................................................................................................................................................................46
Preparing VM-Series Firewall Conguraons Using Panorama ............................................................................................................... 52
Managing VM-Series with Panorama ............................................................................................................................................................ 63
Deployment Details for Azure Networking and Firewall Policies .......................................................................... 69
Conguring Azure Networking and Services ............................................................................................................................................... 70
Using Panorama to Congure Centralized Security Policy and NAT Policy ..........................................................................................86
Palo Alto Networks
Table of Contents
Deployment Details for Backhaul Connecon .........................................................................................................101
Conguring Azure Networking for Backhaul Connecon ...................................................................................................................... 102
Conguring On-site Firewall for VPN Access to Azure .......................................................................................................................... 113
Conguring Resilient Backhaul Connecon .............................................................................................................................................. 126
Using Panorama to Congure Security and NAT for Backhaul Connecon ...................................................................................... 131
Deployment Details for Automated Bootstrapping ................................................................................................136
Preparing For Bootstrapping ........................................................................................................................................................................ 136
Deploying the VM-Series with Bootstrap.................................................................................................................................................. 140
What’s New in This Release .........................................................................................................................................146
1Palo Alto Networks
Purpose of This Guide
Purpose of This Guide
This guide provides design and deployment details for Palo Alto Networks® Security Operang Plaorm on Microso
Azure. This deployment guide focuses specically on the shared design model. Details for the scaled design model are
included in a separate deployment guide.
This deployment guide:
• Provides architectural guidance and deployment details for using Palo Alto Networks next-generaon rewalls
to provide visibility, control, and protecon to your applicaons built on Microso Azure.
• Requires that you rst read the
Reference Architecture Guide for Azure
. The reference architecture guide pro-
vides architectural insight and guidance for your organizaon to plan linkage of pernent features with the next-
generaon rewall in a scalable and highly available design.
• Provides decision criteria for deployment scenarios, as well as procedures for programming features of Microso
Azure and the Palo Alto Networks VM-Series next-generaon rewall in order to achieve an integrated design.
• Focuses specically on the shared design model. Details for the scaled design model are included in a separate
deployment guide.
OBJECTIVES
Compleng the procedures in this guide, you can successfully deploy a Palo Alto Networks VM-series next-generaon
rewall in the Azure environment. The main objecves are to enable the following funconality:
• Protecon and inspecon of ows inbound from the internet, outbound and east-west from private networks
and for secure communicaon with on-premise devices
• Applicaon layer visibility and control for all ows
• Preparing the rewalls to parcipate in the full Security Operang Plaorm with WildFire® analycs, URL lter-
ing, identy-based services, and the full Threat Prevenon services
• Resilient and scalable operaon through integraon with Azure load-balancer
• Panorama™ centralized management using templates and device groups
• Centralized reporng with Palo Alto Networks cloud-delivered Logging Service
• Automac rewall conguraon through bootstrapping
2Palo Alto Networks
Purpose of This Guide
AUDIENCE
This deployment guide is wrien for technical readers, including system architects and design engineers, who want to
deploy the Palo Alto Networks Security Operang Plaorm within a public cloud datacenter infrastructure. It assumes
the reader is familiar with the basic concepts of applicaons, networking, virtualizaon, security, and high availability, as
well as a basic understanding of network and data center architectures.
To be successful, you must have a working knowledge of networking and policy in PAN-OS®.
RELATED DOCUMENTATION
The following documents support this deployment guide:
•
Palo Alto Networks Security Operang Plaorm Overview
—Introduces the various components of the Security
Operang Plaorm and describes the roles they can serve in various designs.
•
Reference Architecture Guide for Azure
—Presents a detailed discussion of the available design consideraons and
opons for the next-generaon VM-Series rewall on Microso Azure. If you are unable to access the URL for
the reference architecture guide, please ask your account team to assist you.
3Palo Alto Networks
Deployment Overview
Deployment Overview
There are many ways to use the concepts discussed in the Security Operang Plaorm on Azure Design Guide to
achieve an architecture that secures applicaons deployed on Azure. Each of the design models in the design guide
provide an example architecture that secures inbound access to an applicaon in Azure, the communicaon between
private virtual machines and workloads, and the connecon to your on-site networks.
This guide is specic to the Shared Design model, the key design consideraons for when to choose this model follow.
CHOOSING A DESIGN MODEL
As discussed in the reference architecture guide, when choosing a design model, consider the following factors:
• Scale—What are the expected number of sessions and bandwidth required for the applicaons? Is this deploy-
ment for a proof-of-concept? Are the trac proles for inbound, outbound, east-west and on-premise com-
municaon balanced? The shared model does not dierenate between trac ows, and resources consumed
by one trac prole may aect overall performance. The shared model provides linear scaling across all trac
proles by adding addional rewalls to the load-balancer backend pools. To provide increased scale for a specif-
ic trac prole, consider the scaled and dedicated models.
• Complexity—Is it more important to keep individual device conguraon simple and permit easier trouble-
shoong, or is it acceptable to take on a somewhat higher administrave workload in order to reduce the total
number of deployed devices? The shared model combines the conguraons for all funcons to a single set of
devices with uni-direconal and bi-direconal ows across mulple zones. Careful consideraon of any changes
is necessary in order to evaluate overall impact, and conguraon errors may be more likely. For simplied con-
guraon and/or reduced impact of conguraon errors, consider the scaled and dedicated models.
• Resiliency and high availability—Are there dierenated availability requirements for dierent trac proles?
The shared model provides the same level of availability for all proles. To provide dierenated availability for
high priority trac proles, consider using the scaled and dedicated models.
4Palo Alto Networks
Design Models
Design Models
The design models primarily dier in how trac ows are divided amongst VM-Series rewalls while oering you ex-
ibility in the number of rewalls, scale, and operaonal resiliency. Consider which model best ts your needs and use it
as a starng point for your design. The design models in this reference design are the:
• Shared model—In this model, all trac ows through a single set of rewalls. This model keeps the number of
rewalls low for small deployments and proof-of-concepts. However, the technical integraon complexity is
high. The deployment details for this design model only are covered in this guide.
• Scaled model—The model separates inbound trac ows onto a dedicated set of rewalls while all other trac
ows through a shared rewall set. This design reduces technical integraon complexity and increases scale
compared to the shared model. The deployment details for this design model are covered in the Security Oper-
ang Plaorm on Azure Deployment Guide (Scaled Design Model).
• Dedicated model—Inbound, outbound and east-west, and backhaul trac are each on dedicated sets of re-
walls. This model oers increased operaonal resiliency and reduces the chances of high bandwidth use from
one trac prole aecng another. This design model does not currently have a deployment guide.
SHARED DESIGN MODEL
In the shared design model, a common set of rewalls provides visibility and control of all trac proles (inbound,
outbound, east-west, backhaul). The rewalls are members of an availability set that distributed their virtual machines
across the Azure infrastructure to avoid downme caused by infrastructure maintenance or failure.
Figure 1 Shared design model
192.168.1.6
192.168.1.7
Ma nagem en t – 192.168.1.0/24
172.16.1.6
(e th 1)
10.5.0.6
(e th 2)
Virtual Network
172.16.1.7
(e th 1)
10.5.0.7
(e th 2)
191.237.87.98
191.237.87.98
We b - 10. 5 . 1. 0 / 24
Business - 1 0. 5 . 2.0 / 24
DB - 1 0. 5 . 3. 0 / 24
10.5.15.6
(e th 3)
10.5.15.7
(e th 3)
Gateway - 10.5.16.0/24
VPN - 10.5.15.0/24
Private
1 0. 5 .0. 0 / 24
Pub lic
1 72 . 16 .1 . 0/ 24
Local Network – 1 0.6 . 0. 0 / 16
191.237.87.98
(tcp/80)
10.5.0.21
10.5.15.21
10.5.0.21
10.5.15.21
Azure Internal Load Balancer
(2 ) Fro nt e nd IPs
(2) Backend Pools
5Palo Alto Networks
Design Models
Inbound Trac
For inbound trac, a public load-balancer distributes trac to the rewalls. To simplify rewall conguraon, the fron-
tend public IP address is associated with a DNS name and oang IP is enabled on the load-balancer rules. The public
load-balancer’s health probes monitor rewall availability through the HTTPS service acvated in the interface manage-
ment prole. Connecvity to the HTTPS service is limited to trac sourced from the health probe IP address.
User-dened routes direct trac from the subnet that contains the public interfaces to the other networks in the
VNet to the next-hop of none. This ensures the public subnet can only communicate to private resources through the
rewall.
Figure 2 Health probe failures with single virtual router
VR: def ault - Ro ute T able
Destination Next Hop I n t e r f ac e
0.0.0.0/0
10.5.0.0/24
10.5.15.0/24
1 72 . 16 . 1 .0/ 24
172.16.1.1 ethernet1 /1
10.5.0.5 ethernet1/ 2
10.5.15.5 eth ernet1/3
172.16.1.5 ethernet1 /1
e1 /2
10.5.0.0/24
(.5)
e1 /1
1 72 . 16 .1 . 0/ 24
(.5)
10.5.15.0/24
e1 /3 (.5)
Public
Load Balancer
In tern a l
Load Balancer
VR: def ault
10.5.0.5
172.16.1.5
10.5.0.5
10.5.15.5
172.16.1.5
172.16.1.5 Av ailable
10.5.0.5 Unavailable
10.5.15.5 Unavailable
Azure LB Health Probe src IP = 168.63.129.16
Probe Response dst IP = 168.63.129.16
Probe Response (failed) dst IP = 168.63.129.16
10.5.15.5
The public interface uses a dedicated virtual router. Stac routes dene a default route out the public interface as well
as a route to private networks through the virtual router dedicated to the private interface. Dedicated virtual routers
are required in the shared design model because Azure always sources load-balancer health probes from the same
IP address. Dedicated virtual routers allow the rewall to have the interface that received the health probe to source
responses.
6Palo Alto Networks
Design Models
Figure 3 Health probes with mulple virtual routers
VR: VR-VP N - Ro ute Table
Destination Next Hop I n t e r f ac e
168.63.129.16/32
10.5.15.0/24
10.5.15.1 eth ernet1/3
10.5.15.5 eth ernet1/3
VR: VR-Private - Ro ute Table
Destination Next Hop I n t e r f ac e
168.63.129.16/32
10.5.0.0/24
10.5.0.1 ethernet1/ 2
10.5.0.5 ethernet1/ 2
VR: VR-Pu bl ic VR: VR-Private
VR: VR-VP N
10.5.15.0/24
e1 /3 (.5)
e1 /2
10.5.0.0/24
(.5)
e1 /1
1 72 . 16 .1 . 0/ 24
(.5)
Public
Load Balancer
172.16.1.5
172.16.1.5 Available
10.5.0.5
Internal
Load Balancer
10.5.0.5 Available
10.5.15.5 Available
10.5.15.5
VR: VR-Pu bl ic - Ro ut e T able
Destination Next Hop I n t e r f ac e
0.0.0.0/0
168.63.129.16/32
1 72 . 16 . 1 .0/ 24
172.16.1.1 ethernet1 /1
172.16.1.1 ethernet1 /1
172.16.1.5 ethernet1 /1
172.16.1.5 10.5.0.5
10.5.15.5
Azure LB Health Probe src IP = 168.63.129.16
Probe Response dst IP = 168.63.129.16
The rewall applies both a desnaon and source NAT to inbound trac. Desnaon NAT translates the FQDN ad-
dress object associated with the load-balancer public DNS name to the virtual machine or load-balancer on the private
network. The source NAT translates the source to be the IP address of the private interface of the rewall, ensuring
return trac ows symmetrically.
The rewall security policy allows appropriate applicaon trac to the resources in the private network while rewall
security proles prevent known malware and vulnerabilies from entering the network in trac allowed in the security
policy.
Outbound Trac
For outbound trac, an internal load-balancer distributes trac to the rewalls. User-dened routes on the private
subnets direct trac to the load-balancer’s frontend IP address, which shares a subnet with the rewall private inter-
faces. Load-balancer rules forward all TCP and UDP ports to the rewalls. Common ports required for outbound trac
include UDP/123 (NTP), TCP/80 (HTTP), and TCP/443 (HTTPS). DNS is not needed, because virtual machines com-
municate to Azure name services directly through the Azure network fabric. The internal load-balancer’s health probes
monitor rewall availability through the HTTPS service enabled in the interface management prole. Connecvity to
the HTTPS service is limited to trac sourced from the health probe IP address.
The private interface uses a dedicated virtual router. Stac routes are dened for the health probe IP address and
private network range out the private interface. Addionally, a stac default route forwards trac to the virtual router
dedicated to the public interface.
7Palo Alto Networks
Design Models
The rewall applies source NAT to outbound trac. When the outbound trac originates from a resource that is
associated with a public IP address, source NAT translates outbound trac to the FQDN address object. For private
resources not associated with a public IP address, the rewall translates the source address to its public interface. An
Azure public IP address is associated with each rewall’s public interface which is required when the interface is also
associated with an inbound public load-balancer’s backend pool.
Because bi-direconal NAT matches trac on any zone, do not enable bi-direconal
NAT in NAT policy rules. Otherwise, the NAT policy may incorrectly translate east-west
trac.
Caution
The rewall security policy allows appropriate applicaon trac from the resources in the private network to the inter-
net. You should implement the security policy by using posive security policies (whitelisng). Security proles prevent
known malware and vulnerabilies from entering the network in return trac allowed in the security policy. URL lter-
ing, le blocking, and data ltering protect against data exltraon.
East-West Trac
East-west trac, or trac between private subnets, uses the same internal load-balancer to distribute trac to the
rewalls as the outbound trac. User-dened routes to the private network subnets are applied to the private subnets
and direct trac to the load-balancer’s frontend IP address. The exisng load-balancer rules for outbound trac apply
to east-west trac as well, and apply to all TCP and UDP ports.
The rewall should not translate the desnaon for trac between private subnets. Like inbound trac, source NAT is
required for return trac to ow symmetrically. A posive control security policy should allow only appropriate applica-
on trac between private resources and requires that the default intrazone security policy rules be overridden and
modied to deny trac. Security proles should also be enabled to prevent known malware and vulnerabilies from
moving laterally in the private network through trac allowed in the security policy.
Backhaul and Management Trac
User-dened routes applied to the gateway subnet direct trac that has a desnaon in the private network range to
the internal load-balancer with an addional frontend IP dedicated to incoming trac from the backhaul connecon.
The load-balancer then distributes trac to a new backend pool with dedicated interfaces on the rewalls. Dedicated
rewall interfaces are used for the backhaul trac because they allow for enhanced security policies that can take zone
into account.
On the rewall, a dedicated virtual router for the backhaul interface and stac routes provides reachability to the on-
site networks and health probe IP address. Stac routes on both the backhaul and private virtual routers provide bi-di-
reconal trac ow between the on-site and private network ranges. Trac originang in private subnets and desned
to on-site networks follows the same path as east-west trac. All that is required is the addion of user-dened routes
that forward on-site network ranges to the outbound/east-west load-balancer frontend.
8Palo Alto Networks
Design Models
Trac from the on-site networks communicates to the management subnet directly. This allows on-site administrators
to manage the rewalls even when a misconguraon occurs in user-dened roung or load-balancers.
User-dened routes blackhole the trac to the on-site networks from public subnets by sending the trac to a next-
hop of none.
9Palo Alto Networks
Assumpons and Prerequisites
Assumpons and Prerequisites
Microso Azure:
• Your organizaon has a valid acve subscripon associated with your Azure user account.
• Two resources groups are used—one for Panorama and common resources and a separate resource group for
dataplane devices
• Uses Standard-SKU IP addresses and load-balancers, except where specically noted in the guide.
• Only IPv4 networking is used.
• Web servers are already deployed with their own dedicated load-balancer.
• Business and DB servers are already deployed.
Palo Alto Networks next-generaon rewalls and Panorama:
• Device conguraon is centrally managed with Panorama using templates and device groups.
• Panorama will be deployed on Azure in management-only mode.
• Firewall logging uses the Palo Alto Networks cloud-based Logging Service.
• The PAN-OS version tested in this deployment guide is 8.1.2 for all devices.
• The Cloud services plugin for Panorama is 1.1.0.
• The on-premise rewalls for backhaul trac are already deployed with a set of interfaces connected to the pub-
lic and private zones and integrated into the on-premise dynamic roung protocol.
Palo Alto Networks licensing:
• Your organizaon has a Panorama license for the current and expected number of managed VM-Series rewalls.
• Sucient VM-Series licensing for the current and expected number of VM-Series rewalls. This guide assumes
you are using the BYOL licensing opon.
• Requires a bundled auth-key for VM-Series if you intend to use bootstrapping.
• Logging Service instance is provisioned with sucient storage to support the required data retenon period and
auth-code has been issued.
• Logging Service region used is americas.
10Palo Alto Networks
Deployment Details for Panorama
Deployment Details for Panorama
Panorama is deployed in a new dedicated Azure Resource Group which includes the VNet used for the Shared Design
Model. You must complete two complementary procedure groups in order to deploy Panorama. The rst procedure
group congures the Azure environment. Once Azure is congured, then Panorama may be deployed.
Figure 4 Panorama high-availability mode deployed on Azure
Virtual Network
192.168.1.4
(active)
192.168.1.5
(p a ss ive)
Ma nagemen t – 192.168.1.0/24
High
Av ailability
Several of the resources created on Azure are used by procedures later in this guide When the resource already exists,
you will be instructed to modify an exisng resource rather than create a new resource.
Creang and Conguring Azure Common Resources
1.1 Create the Resource Group
1.2 Create the Virtual Network
1.3 Create the Public IP Address for Panorama
1.4 Create and Apply the Network Security Group
1.5 Create the Availability Set
1.6 Create the Storage Account
1.7 Verify Resource Creaon Completed
Procedures
The following procedures are completed using the Azure Resource Manager. Sign in to Azure at
hps://portal.azure.com
.
11Palo Alto Networks
Deployment Details for Panorama
Some Azure templates provide an opon to create a new resource when needed at de-
ployment me and other templates require resources to be created in advance. Where
possible, this guide creates the resource in advance and then references the exisng
resource at deployment me.
Note
This procedure group creates the resources listed in the following table as preparaon for deploying Panorama.
Table 1 Azure resources required for deployment
Parameter Value Comments
Resource group AzureRefArch —
Subscripon <value> Must have a valid Azure subscripon
Resource group locaon <locaon> Tested in West US
Virtual network AzureRefArch-VNET —
Public IP for Panorama management
(primary)
Azure-Panorama-1 Panorama, or primary Panorama when using
Panorama High Availability
Public IP for Panorama management
(secondary)
Azure-Panorama-2 Oponal—secondary Panorama when using
Panorama High Availability
Availability set AzureRefArch-AS Suggested if planning for Panorama High Avail-
ability
Diagnoscs storage account azurerefarchv2diag —
1.1 Create the Resource Group
All resources deployed in this guide should use the same locaon. The deployment in this guide was tested in West US.
Step 1: In Home > Resource groups, click Add.
12Palo Alto Networks
Deployment Details for Panorama
Step 2: In the Resource group name box, enter AzureRefArch and select the desired values for the Resource group
locaon. Click Create.
1.2 Create the Virtual Network
The virtual network (VNet) is created with an inial IP address space and a subnet that must be within the IP address
space. The VNet can be modied aer creaon to add addional IP address space and subnets. Only the rst entry in
the following table is congured in this procedure.
Table 2 Virtual network IP addressing and subnets
Address space Subnet Address range Comments
192.168.1.0/24 Management 192.168.1.0/24 Inial address space, subnet, and range
172.16.0.0/23 Shared-Public 172.16.1.0/24 Congured in a separate procedure
10.5.0.0/16 Shared-Private
Shared-Web
Shared-Business
Shared-DB
Shared-VPN
10.5.0.0/24
10.5.1.0/24
10.5.2.0/24
10.5.3.0/24
10.5.15.0/24
Congured in separate procedures
Step 1: In Home > Virtual networks, click Add.
Step 2: In the Name box, enter AzureRefArch-VNET.
Step 3: In the Address space box, enter 192.168.1.0/24.
13Palo Alto Networks
Deployment Details for Panorama
Azure Resource Manager provides a warning if the proposed address space overlaps
with address space already assigned in another VNet within the same subscripon.
These warnings can be ignored if communicaon between these VNets is not required.
Otherwise, choose a dierent non-overlapping address space.
Note
Step 4: In the Resource Group secon, choose Use Exisng and then select AzureRefArch.
Step 5: In the Subnet secon Name box, enter Management.
Step 6: In the Subnet secon Address Range box, enter 192.168.1.0/24.
Step 7: Click Create.
14Palo Alto Networks
Deployment Details for Panorama
1.3 Create the Public IP Address for Panorama
The Panorama virtual machines deployed on Azure are managed using public IP addresses unless on-site network con-
necvity has been established. The process to congure on-site network connecvity is included later in this guide.
This procedure creates a public IP address that is associated with the management interface of the primary Panorama
system at deployment me. If necessary, this procedure is repeated to create an addional public IP address for the
secondary Panorama system. The parameters listed in Table 1 are used to complete this procedure.
This guide uses Standard-SKU IP addresses in all procedures except where specically
noted.
Note
Take note of the fully qualied domain name (FQDN) that is dened by adding the locaon specic sux to your DNS
name label. We recommend managing your devices by using the DNS name rather than the public IP address, which
may change.
Step 1: In Home > Public IP addresses, click Add.
Step 2: In the Name box, enter Azure-Panorama-1.
Step 3: Select Standard SKU.
Step 4: In the DNS name label box, enter ara-panorama-1.
Step 5: In the Resource Group secon, choose Use Exisng, and then select AzureRefArch.
15Palo Alto Networks
Deployment Details for Panorama
Step 6: Click Create.
1.4 Create and Apply the Network Security Group
Azure requires that a network security group (NSG) must be applied on a subnet or NIC of your virtual machine re-
source or trac is not permied to reach the resource when Standard SKU public IP addresses are associated with the
resource.
This guide uses Standard-SKU IP addresses in all procedures except where specically
noted.
Note
16Palo Alto Networks
Deployment Details for Panorama
This procedure creates NSGs for use with the management subnet. Each NSG includes default rules that allow for traf-
c within the VNET and from the Azure Load Balancer health probes.
Step 1: In Home > Network Security groups, click Add.
Step 2: In the Name box, enter AllowManagement-Subnet.
Step 3: In the Resource Group secon, choose Use Exisng, and then select AzureRefArch.
Step 4: In Home > Network security groups > AllowManagement-Subnet, in the SETTINGS secon, click Inbound
security rules.
Step 5: Click Add. The Add inbound security rule pane appears.
Step 6: In the Desnaon port ranges box, enter 443.
Step 7: In the Protocol secon, select TCP.
Step 8: In the Name box, enter AllowHTTPS-Inbound.
17Palo Alto Networks
Deployment Details for Panorama
Step 9: Click Add.
Step 10: Repeat Step 4 through Step 9 with the following values:
• Desnaon port ranges—22
• Priority—110
• Name—AllowSSH-Inbound
Azure presents warning messages when the NSG rules expose various ports to the
Internet. We advise using more restricve rules outside of a tesng environment.
Note
18Palo Alto Networks
Deployment Details for Panorama
Step 11: In Home > Network security groups > AllowManagement-Subnet, in the SETTINGS secon, click Subnets.
Step 12: In the AllowAll-Subnet — Subnets pane, click Associate.
Step 13: Click on the Virtual network — Choose a virtual network secon. From the Choose virtual network list,
select AzureRefArch-VNET.
Step 14: Click on the Subnet — Choose a subnet secon. From the Choose subnet list, select Management, and then
click OK.
19Palo Alto Networks
Deployment Details for Panorama
1.5 Create the Availability Set
The Panorama high-availability model benets from the use of an availability set with two fault domains. This ensures
that the primary and secondary Panorama systems are deployed on dierent fault domains.
You can only congure an availability set on a virtual machine during its inial deploy-
ment. You can’t modify a virtual machine’s availability-set conguraon aer the virtual
machine is deployed.
Note
Step 1: In Home > Availability sets, click Add.
Step 2: In the Name box, enter AzureRefArch-AS.
Step 3: In the Resource Group secon, choose Use Exisng, and then select AzureRefArch.
Step 4: Click Create.
20Palo Alto Networks
Deployment Details for Panorama
1.6 Create the Storage Account
Panorama and other resources require general purpose storage for diagnoscs and bootstrapping.
Step 1: In Home > Storage accounts, click Add.
Step 2: In the Name box, enter azurerefarchv2diag.
Step 3: In the Account kind list, select StorageV2 (general purpose v2).
Step 4: In the Replicaon list, select Locally-redundant storage (LRS).
Step 5: In the Resource Group secon, choose Use Exisng, and then select AzureRefArch.
Step 6: Click Create.
21Palo Alto Networks
Deployment Details for Panorama
1.7 Verify Resource Creaon Completed
Some Azure deployments are me consuming, and if any resources are missing, the deployment fails. It is quicker to
verify that all of the necessary resources exist before proceeding with a deployment than waing unl a deployment
fails.
Step 1: In Home > Resource Groups, select AzureRefArch.
Step 2: Verify that the resource group, NSGs, public IP addresses, availability set, storage account, and VNet have been
successfully created.
Deploying Panorama on Azure
2.1 Create Panorama Virtual Machine
2.2 Change Azure Assigned IP Address from Dynamic to Stac
2.3 License Panorama on Azure
2.4 Update Panorama Soware to Recommended Version
2.5 Congure Panorama High Availability (oponal)
2.6 Acvate Logging Service
2.7 Install Cloud Service Plugin Version 1.1.0
Procedures
The following procedures use the Azure Resource Manager and the Panorama device portal. Sign in to Azure at
hps://
portal.azure.com
. Details on how to access Panorama aer deployment are included in the relevant procedures.
22Palo Alto Networks
Deployment Details for Panorama
This procedure deploys Panorama in management mode. Panorama defaults to management mode when it detects that
there is not sucient log storage capacity to run in Panorama mode.
Table 3 Panorama deployment parameters
Parameter Value Comments
Name Azure-Panorama-1
Azure-Panorama-2
Primary system
Secondary system (oponal for high availability)
VM disk type Standard HDD Required for D3_v2 Standard.
Username refarchadmin May not use “admin”
Authencaon type <password> Complex password required
Subscripon <value> Must have a valid Azure subscripon
Resource group name Use exisng
AzureRefArch
—
Locaon <locaon> Tested in West US
Panorama VM size D3_v2 Standard
Setup Prerequisites for the Panorama Virtual Appliance
Availability set AzureRefArch-AS Recommend to use Availability Set if planning for acve/
standby Panorama. Cannot change seng aer deploy-
ment.
Storage
Use managed disks
Yes —
Virtual Network AzureRefArch-VNET —
Subnet Management —
Public IP Azure-Panorama-1
Azure-Panorama-2
DNS congured as: ara-panorama-1
DNS congured as: ara-panorama-2
Network security group None NSG is applied at subnet level
Auto-shutdown No —
Monitoring
boot diagnoscs
On —
Diagnoscs storage account azurerefarchv2diag —
2.1 Create Panorama Virtual Machine
Use the parameters in Table 3 to deploy Panorama.
Step 1: In Home > Virtual machines, click Add.
Step 2: In the Search compute box, enter Panorama, and then and press Enter to search.
23Palo Alto Networks
Deployment Details for Panorama
Step 3: In the search results, click Panorama (BYOL).
Step 4: In Home > Virtual machines > Compute > Panorama (BYOL), click Create.
Step 5: In the Name box, enter Azure-Panorama-1.
Step 6: In the VM disk type list, select Standard HDD.
Step 7: In the Username box, enter refarchadmin.
Step 8: For Authencaon type, select Password.
Step 9: In the Password and Conrm Password boxes, enter the password.
Step 10: In the Resource Group secon, choose Use Exisng, and then select AzureRefArch and click OK.
Step 11: From the Available sizes, select D3_v2 Standard, and then click Select.
Step 12: Click the Availability set secon to modify the default seng. From the Change availability set list, select
AzureRefArch-AS.
Step 13: Click the Virtual network secon to modify the default seng. From the Choose virtual network list, select
AzureRefArch-VNET.
Step 14: Click the Subnet secon to modify the default seng. From the Choose subnet list, select Management.
Step 15: Click the Public IP address secon to modify the default seng. From the Choose public IP address list,
select Azure-Panorama-1. Dismiss the dialog box warning for “Your unsaved edits will be discarded.” by clicking OK.
Step 16: Click the Network security group (rewall) secon to modify the default seng. From the Choose network
security group list, select None. The subnet already has an associated NSG.
Step 17: Click the Diagnoscs storage account secon to modify the default seng. From the Choose storage ac-
count list, select azurerefarchv2diag, and then click OK.
Step 18: Aer validaon passes, review the Oer details, Summary, and Terms of use secons. If the informaon is
correct and acceptable, then click Create.
24Palo Alto Networks
Deployment Details for Panorama
2.2 Change Azure Assigned IP Address from Dynamic to Stac
You must congure Panorama with a stac IP address. Azure networking provides the IP address to Panorama using
DHCP but by default is congured to use dynamic assignment. If the current IP address is acceptable, convert the
address assignment to stac. To change the IP address, convert the assignment to stac and then assign an available
address. Any IP address changes require a restart of the Panorama virtual machine.
Step 1: In Home > Virtual machines > Azure-Panorama-1, click Networking.
Step 2: Click the Network interface name (example: azure-panorama-1268).
Step 3: Click IP conguraons.
25Palo Alto Networks
Deployment Details for Panorama
Step 4: Click the IP conguraon row to edit the sengs.
Step 5: In the Private IP address sengs secon, click Stac to convert from dynamic to stac conguraon.
Step 6: (Oponal—change the stac IP address to preferred value.) In the IP address box, enter a new IP address. The
chosen IP address must be unassigned in Azure.
Changing an IP address forces a restart of the virtual machine.
Caution
Step 7: Click Save. The virtual machine restarts if the IP address is changed.
26Palo Alto Networks
Deployment Details for Panorama
2.3 License Panorama on Azure
Panorama is now running on Azure but is unlicensed and using a factory default conguraon. Based on the size se-
lected for the Panorama virtual machine, the System Mode is management-only.
This procedure assumes that you have a valid serial number for your Panorama device(s) and that registraon on the
customer support portal (
hps://support.palotaltonetworks.com
) is complete.
Step 1: Log in to Panorama (example:
hps://ara-panorama-1.westus.cloudapp.azure.com
)
You will see a series of dialog boxes and warnings.
Step 2: Click OK to accept the There are no device groups dialog box.
Step 3: Click OK to accept the Retrieve Panorama License warning dialog box.
27Palo Alto Networks
Deployment Details for Panorama
Step 4: Click Complete Manually to accept the next Retrieve Panorama License warning dialog box.
Step 5: Click OK to accept the Oine Licensing Informaon dialog box.
28Palo Alto Networks
Deployment Details for Panorama
Step 6: In Panorama > Setup > Management > General Sengs, click the Edit cog.
Step 7: In the Domain box, enter the domain sux.
Step 8: In the Time Zone list, select the appropriate me zone (example: US/Pacic).
Step 9: In the Serial Number box, enter the serial number from the customer support portal, and then click OK.
Step 10: In Panorama > Setup > Services, click the Edit cog.
Step 11: In the Primary DNS Server box, enter 168.63.129.16.
Step 12: Change to the NTP tab. In the Primary NTP Server secon NTP Server Address box, enter 0.pool.ntp.org.
29Palo Alto Networks
Deployment Details for Panorama
Step 13: In the Secondary NTP Server secon NTP Server Address box, enter 1.pool.ntp.org, and then click OK.
Step 14: On the Commit menu, click Commit to Panorama.
Step 15: In Panorama > Licenses, click Retrieve license keys from license server.
Step 16: Verify Device Management License is acve.
2.4 Update Panorama Soware to Recommended Version
Step 1: Navigate to Panorama > Soware.
If you receive an Operaon Failed warning with the message No update informaon
available, you may click Close to acknowledge. No acon is required.
Note
Step 2: In Panorama > Soware, click Check Now.
Step 3: For version 8.1.2, in the Acons column, click Download. Click Close when complete.
Step 4: Aer the status in the Available column has changed to Downloaded, and then in the Acon column, click
Install.
Step 5: When prompted to Reboot Panorama, click Yes.
30Palo Alto Networks
Deployment Details for Panorama
2.5 Congure Panorama High Availability (oponal)
This procedure is necessary only to deploy Panorama in a high availability conguraon. Panorama supports an HA
conguraon in which one peer is the acve-primary and the other is the passive-secondary. If a failure occurs on the
primary peer, it automacally fails over and the secondary peer becomes acve.
The Panorama HA peers synchronize the running conguraon each me you commit changes on the acve Panorama
peer. The candidate conguraon is synchronized between the peers each me you save the conguraon on the ac-
ve peer or just before a failover occurs.
Sengs that are common across the pair, such as shared objects and policy rules, device group objects and rules, tem-
plate conguraon, and administrave access conguraon, are synchronized between the Panorama HA peers.
Perform Step 1 through Step 6 on the primary Panorama.
Step 1: In Panorama > High Availability > Setup, click the Edit cog.
Step 2: Select Enable HA.
Step 3: In the Peer HA IP Address box, enter 192.168.1.5, and then click OK.
Step 4: In Panorama > High Availability > Elecon Sengs, click the Edit cog.
Step 5: In the Priority list, select primary, and then click OK.
Step 6: On the Commit menu, click Commit to Panorama.
Perform Step 7 through Step 12 on the secondary Panorama.
Step 7: In Panorama > High Availability>Setup, click the Edit cog.
Step 8: Select Enable HA.
31Palo Alto Networks
Deployment Details for Panorama
Step 9: In the Peer HA IP Address box, enter 192.168.1.4, and then click OK.
Step 10: In Panorama > High Availability > Elecon Sengs, click the Edit cog.
Step 11: In the Priority list, select secondary, and then click OK.
Step 12: On the Commit menu, click Commit to Panorama.
Step 13: On the primary Panorama, in Dashboard > Widgets > System, click High Availability to enable the High Avail-
ability dashboard widget. This adds a dashboard pane that displays the status of the Panorama peers.
Step 14: Repeat Step 13 on the secondary Panorama.
Step 15: On the primary Panorama, in Dashboard > High Availability, click Sync to peer.
32Palo Alto Networks
Deployment Details for Panorama
Step 16: Click Yes to accept the Overwrite Peer Conguraon warning and proceed with the synchronizaon.
2.6 Acvate Logging Service
The Logging Service requires an authorizaon code, which is used to acvate the service. This procedure also assumes
that you have a valid serial number for your Panorama device(s) and that registraon on the customer support portal is
complete.
The Logging Service instance is associated with the serial number of the primary Panorama. This procedure is not re-
peated for the secondary Panorama.
Step 1: Log in to the Customer Support Portal at
hps://support.paloaltonetworks.com
.
Step 2: Select Assets > Cloud Services.
Step 3: Click Acvate Cloud Services Auth-Code.
Step 4: In the Cloud Services window, in the Authorizaon Code box, enter the authorizaon code (example:
I7654321), and then press Tab key to advance. The Panorama and Logging Region boxes appear.
Step 5: In the Cloud Services window, in the Panorama list, select the value that corresponds to the serial number as-
signed to your primary Panorama.
33Palo Alto Networks
Deployment Details for Panorama
Step 6: In the Cloud Services window, in the Logging Region list, select the value that corresponds to your region
(example: Americas).
Step 7: Accept the EULA by clicking on Agree and Submit.
2.7 Install Cloud Service Plugin Version 1.1.0
If running Panorama in high availability mode, perform this procedure on the primary Panorama rst. Then repeat this
procedure for the secondary Panorama.
Step 1: In Panorama > Plugins, click Check Now.
Step 2: For cloud _services-1.1.0, in the Acons column, click Download.
Step 3: Aer the download is completed, click Close.
Step 4: Aer the status in the Available column changes to a check, and then in the Acon column, click Install.
34Palo Alto Networks
Deployment Details for Panorama
Step 5: Click OK to close the dialog box that indicates a successful installaon.
Perform Step 6 through Step 8 on the customer support portal (
hps://support.paloaltonetworks.com
) to complete the
associaon of Panorama to the cloud service.
Step 6: In Assets > Cloud Services, click Generate OTP.
Step 7: In the Generate Cloud Services One Time Password window, in the Panorama list, select the serial number for
the primary Panorama, and then click Generate OTP.
35Palo Alto Networks
Deployment Details for Panorama
Step 8: In the Generate Cloud Services One Time Password window, click Copy to Clipboard.
Step 9: On Panorama, navigate to Panorama > Cloud Services > Status, and then click Verify.
36Palo Alto Networks
Deployment Details for Panorama
Step 10: In the One-Time Password box, paste the OTP that was generated from the Customer Support Portal.
Step 11: In Panorama > Cloud Service > Status, verify the status.
Step 12: If necessary, repeat this procedure for the secondary Panorama.
37Palo Alto Networks
Deployment Details for VM-Series
Deployment Details for VM-Series
The VM-Series rewalls are deployed in a new dedicated Azure Resource Group for the shared design model. Some
Azure resources, such as the VNet, have already been allocated within the Azure Resource Group used for Panorama.
You must complete mulple complementary procedure groups in order to deploy and congure the VM-Series.
The rst procedure group modies and congures the Azure environment. Aer Azure is congured, the second pro-
cedure group deploys the VM-Series and minimally congures each device to prepare for central management through
Panorama.
Figure 5 Shared model—VM-Series deployment parameters
192.168.1.6
192.168.1.7
Ma nagemen t – 192.168.1.0/24
172.16.1.6
(et h 1)
10.5.0.6
(et h 2)
Virtual Network
172.16.1.7
(et h 1)
10.5.0.7
(et h 2)
10.5.15.6
(et h 3)
10.5.15.7
(et h 3)
Shared-VPN - 10.5.15.0/24
Shared-Private
1 0. 5 .0. 0 / 24
Shared-Pub lic
1 72 . 16 .1 . 0/ 24
The third procedure group congures the Panorama conguraon templates used by the each of VM-Series devices. All
template based conguraon is common across all VM-Series devices and only takes eect once pushed from Panora-
ma to the VM-Series. Aer the templates are complete, the fourth procedure group registers the individual VM-Series
devices with Panorama, associates them with the templates and placeholder device groups, pushes the conguraons,
and refreshes the licenses.
38Palo Alto Networks
Deployment Details for VM-Series
Creang and Conguring Azure Common Resource for VM-Series
3.1 Create Whitelist Network Security Group
3.2 Add Address Space and Subnets to the Virtual Network
3.3 Create the Resource Group for the Shared Design Model
3.4 Create the Storage Account
3.5 Create the Availability Set
3.6 Create the Public IP Address for VM-Series
3.7 Verify Resource Creaon Completed
Procedures
Azure has removed the opon to select an exisng resource group for marketplace soluons that enable mulple NICs.
To deploy the rewall into an exisng resource group, use the ARM template in the
GitHub Repository
or your own
custom ARM template.
This procedure group creates the resources listed in the following table as preparaon for deploying the VM-Series
rewalls.
Table 4 Azure resources required for deployment
Parameter Value Comments
Virtual network AzureRefArch-VNET Exisng VNet in the AzureRefArch resource group, in
which Panorama is already deployed
Resource Group AzureRefArch-Shared New resource group specically for the shared design
model
Storage account azurerefarchv2shared General purpose storage for VM-Series virtual le sys-
tems
Availability set AzureRefArch-Shared-AS New availability set for the VM-Series in the shared
design model
Public IP for VM-Series 1 aras-vmfw1 Public IP for management interface
Public IP for VM-Series 2 aras-vmfw2 Public IP for management interface
39Palo Alto Networks
Deployment Details for VM-Series
3.1 Create Whitelist Network Security Group
Azure requires that an NSG must be applied on a subnet or NIC of your virtual machine resource, or trac is not per-
mied to reach the resource when Standard SKU public IP addresses are associated with the resource.
This guide uses Standard-SKU IP addresses in all procedures except where specically
noted.
Note
This procedure creates a whitelist NSG for use with tesng, which is applied to all dataplane subnets. The intent of this
NSG is to simplify the troubleshoong process during early stages of deployment and tesng.
An Allow-ALL NSG permits access to devices with public IP addresses from the Inter-
net. We advise using more restricve rules outside of a tesng environment.
Caution
Step 1: In Home > Network Security groups, click Add.
Step 2: In the Name box, enter AllowAll-Subnet.
Step 3: In the Resource Group secon, choose Use Exisng, and then select AzureRefArch.
Step 4: Click Create.
Step 5: In Home > Network Security groups, click Add.
Step 6: In the Name box, enter AllowAll-Subnet.
Step 7: In the Resource Group secon, choose Use Exisng, and then select AzureRefArch.
Step 8: In Home > Network security groups > AllowAll-Subnet, in the SETTINGS secon, click Inbound security rules.
Step 9: Click Add. The Add inbound security rule pane appears.
Step 10: In the Desnaon port ranges box, enter *.
40Palo Alto Networks
Deployment Details for VM-Series
Step 11: In the Name box, enter AllowAll-Inbound.
Step 12: Click Add.
Azure presents warning messages when the Network Security Group rules expose vari-
ous ports to the Internet.
Note
3.2 Add Address Space and Subnets to the Virtual Network
The exisng virtual network (VNet) is modied to add addional IP address space and subnets. The rst entry in Table 5
has already been congured in a prior procedure.
Table 5 Virtual network IP addressing and subnets
Address space Subnet Address range Comments
192.168.1.0/24 Management 192.168.1.0/24 Inial address space, subnet and range (already
congured).
172.16.0.0/23 Shared-Public 172.16.1.0/24 New subnet
10.5.0.0/16 Shared-Private
Shared-Web
Shared-Business
Shared-DB
Shared-VPN
10.5.0.0/24
10.5.1.0/24
10.5.2.0/24
10.5.3.0/24
10.5.15.0/24
New subnet
New subnet
New subnet
New subnet
New subnet
Step 1: In Home > Virtual networks > AzureRefArch-VNET, click Address space.
Step 2: In the Add addional address space box, enter 172.16.0.0/23. A new box appears below.
41Palo Alto Networks
Deployment Details for VM-Series
Step 3: In the Add addional address space box, enter 10.5.0.0/16, and then click Save.
Step 4: In Home > Virtual networks > AzureRefArch-VNET, click Subnets.
Step 5: Click Subnet to add a new subnet.
Step 6: In the Name box, enter Shared-Public.
Step 7: In the Address Range (CIDR block) box, enter 172.16.1.0/24.
Step 8: Click in the Network security group secon. In the Resource list, select AllowAll-Subnet, and click OK.
Step 9: Repeat Step 4 through Step 8 for all of the subnets listed as New subnet in Table 5.
An NSG is not explicitly assigned to newly created subnets. You must assign an NSG to
any subnet that uses an Azure Standard SKU public IP address.
Azure documentaon states “If you do not have an NSG on a subnet or NIC of your
virtual machine resource, trac is not allowed to reach this resource.”
During inial deployment and troubleshoong you may want to congure and use a
whitelist “Allow All” NSG to simplify vericaon.
This guide does not provide further recommendaons on how to properly cra and
congure the NSGs.
Caution
Step 10: Verify all subnets are created with the correct IP ranges and security group.
42Palo Alto Networks
Deployment Details for VM-Series
3.3 Create the Resource Group for the Shared Design Model
This guide uses two resource groups, one has already been created for Panorama and common resources. This proce-
dure creates a new resource group which contains all of the VM-Series devices and Azure load-balancer resources for
the Shared Design Model.
Resource groups are an administrave concept. Resources and devices in dierent
resource groups can communicate if they are located within a common VNet, or if their
VNets are interconnected.
Note
Step 1: In Home > Resource groups, click Add.
Step 2: In the Resource group name box, enter AzureRefArch-Shared and select the desired values for Subscripon
and Resource group locaon. Click Create.
3.4 Create the Storage Account
The VM-Series rewalls require general purpose storage for their virtual le systems and bootstrapping.
Step 1: In Home > Storage accounts, click Add.
Step 2: In the Name box, enter azurerefarchv2shared.
Step 3: In the Account kind list, select StorageV2 (general purpose v2).
Step 4: In the Replicaon box, select Locally-redundant storage (LRS).
Step 5: In the Resource Group secon, choose Use Exisng, and then select AzureRefArch-Shared.
43Palo Alto Networks
Deployment Details for VM-Series
Step 6: Click Create.
44Palo Alto Networks
Deployment Details for VM-Series
3.5 Create the Availability Set
The VM-Series resiliency model for Azure benets from the use of an availability set with two fault domains. This en-
sures that the VM-Series systems are distributed across dierent fault domains.
You can only congure an availability set on a virtual machine during its inial deploy-
ment. You can’t modify a virtual machine’s availability set conguraon aer the virtual
machine is deployed.
Note
Step 1: In Home > Availability sets, click Add.
Step 2: In the Name box, enter AzureRefArch-Shared-AS.
Step 3: In the Resource Group secon, choose Use Exisng, and then select AzureRefArch-Shared.
Step 4: In Use managed disks, select No (classic). This is required for the ARM template.
Step 5: Click Create.
3.6 Create the Public IP Address for VM-Series
The VM-Series devices deployed on Azure are managed using public IP addresses unless on-site network connecvity
has been established. The process to congure on-site network connecvity is included later in this guide.
This procedure creates a public IP address that is associated to the management interface of the VM-Series at deploy-
ment me. If necessary, this procedure is repeated to create addional public IP addresses for addional VM-Series
devices. The parameters listed in Table 4 are used to complete this procedure.
Take note of the FQDN that is dened by adding the locaon specic sux to your DNS name label. We recommend
managing your devices using the DNS name rather than the public IP address, which may change.
Step 1: In Home > Public IP addresses, click Add.
Step 2: In the Name box, enter aras-vmfw1.
Step 3: Select Standard SKU.
Step 4: In the DNS name label box, enter aras-vmfw1.
45Palo Alto Networks
Deployment Details for VM-Series
Step 5: In the Resource Group secon, choose Use Exisng, and then select AzureRefArch-Shared.
Step 6: Click Create.
3.7 Verify Resource Creaon Completed
Some Azure deployments are me consuming and if any resources are missing, the deployment fails. It is quicker to
verify that all of the necessary resources exist before proceeding with a deployment than waing unl a deployment
fails.
46Palo Alto Networks
Deployment Details for VM-Series
Step 1: In Home > Resource Groups, select AzureRefArch-Shared.
Step 2: Verify that the resource group, public IP addresses, availability set, and storage account have been successfully
created.
Deploying VM-Series on Azure
4.1 Deploy VM-Series using Custom ARM Template
4.2 License VM-Series on Azure
4.3 Update Device Soware
Procedures
The following procedures are completed using the Azure Resource Manager deployed from an Azure Resource Man-
ager Template posted at GitHub. If you are already signed in to Azure at
hps://portal.azure.com
, the deployment from
GitHub uses the same session authorizaon.
Table 6 VM-Series deployment parameters
Parameter Value Comments
Resource group AzureRefArch-Shared Exisng
Locaon —Tested in West US
VM name ARAS-VMFW1
ARAS-VMFW2
First device
Second device
Storage account name azurerefarchv2shared —
Storage account exisng RG AzureRefArch-Shared —
Fw Av Set AzureRefArch-Shared-AS —
Table connued on next page
47Palo Alto Networks
Deployment Details for VM-Series
Connued table
Parameter Value Comments
VM size Standard_D3_v2 hps://www.paloaltonetworks.com/docu-
mentaon/80/virtualizaon/virtualizaon/
set-up-the-vm-series-rewall-on-azure/about-
the-vm-series-rewall-on-azure/minimum-sys-
tem-requirements-for-the-vm-series-on-azure
Public IP type standard Standard IP SKU required for use with Azure
Standard load-balancer
Image version latest —
Image SKU byol —
Virtual network name AzureRefArch-VNET Uses AzureRefArch-VNET in resource group
AzureRefarch
Virtual network address
prex
192.168.1.0/24 Match the inial IP address space from AzureRe-
fArch-VNET
Virtual network exisng RG
name
AzureRefArch —
Subnet0Name Management —
Subnet1Name Shared-Public —
Subnet2Name Shared-Private —
Subnet3Name Shared-VPN —
Subnet0Prex 192.168.1.0/24 —
Subnet1Prex 172.16.1.0/24 —
Subnet2Prex 10.5.0.0/24 —
Subnet3Prex 10.5.15.0/24 —
Subnet0Start Address 192.168.1.6
192.168.1.7
First device
Second device
(start assignment from .6)
Subnet1Start Address 172.16.1.6
172.16.1.7
First device
Second device
(start assignment from .6)
Subnet2Start Address 10.5.0.6
10.5.0.7
First device
Second device
(start assignment from .6)
Subnet3Start address 10.5.15.6
10.5.15.7
First device
Second device
(start assignment from .6)
Admin username refarchadmin —
Admin password <password> —
Public IP address name aras-vmfw1
aras-vmfw2
First device
Second device
Nsg name None NSG is applied at subnet level
48Palo Alto Networks
Deployment Details for VM-Series
4.1 Deploy VM-Series using Custom ARM Template
Repeat this procedure for all VM-Series. This guide assumes that at least two VM-Series devices are created.
The custom Azure Resource Manager template used in this procedure has been developed and validated specically for
this deployment guide.
For template details and features, see :
hps://github.com/PaloAltoNetworks/ReferenceArchitectures/tree/master/Azure-1FW-4-interfaces-exisng-environment
Use the parameters in Table 6 to deploy each VM-Series.
Step 1: Deploy the VM-Series by clicking on the Deploy to Azure buon.
Step 2: In the Resource Group secon, choose Use Exisng, and then select AzureRefArch-Shared.
Step 3: In the Vm Name box, enter ARAS-VMFW1.
Step 4: In the Storage Account Name box, enter azurerefarchv2shared.
Step 5: In the Storage Account Exisng RG box, enter AzureRefArch-Shared.
Step 6: In the Fw Av Set box, enter AzureRefArch-Shared-AS.
Step 7: In the Vm Size list, select Standard_D3_v2.
Step 8: In the Public IP Type list, select standard.
Step 9: In the Image Version list, select latest.
Step 10: In the Image Sku list, select byol.
Step 11: In the Virtual Network Name box, enter AzureRefArch-VNET.
Step 12: In the Virtual Network Address Prex box, enter 192.168.1.0/24.
Step 13: In the Virtual Network Exisng RG Name box, enter AzureRefArch.
Step 14: In the Subnet0Name box, enter Management.
Step 15: In the Subnet1Name box, enter Shared-Public.
49Palo Alto Networks
Deployment Details for VM-Series
Step 16: In the Subnet2Name box, enter Shared-Private.
Step 17: In the Subnet3Name box, enter Shared-VPN.
Step 18: In the Subnet0Prex box, enter 192.168.1.0/24.
Step 19: In the Subnet1Prex box, enter 172.16.1.0/24.
Step 20: In the Subnet2Prex box, enter 10.5.0.0/24.
Step 21: In the Subnet3Prex box, enter 10.5.15.0/24.
Step 22: In the Subnet0Start Address box, enter 192.168.1.6.
Step 23: In the Subnet1Start Address box, enter 172.16.1.6.
Step 24: In the Subnet2Start Address box, enter 10.5.0.6.
Step 25: In the Subnet3Start Address box, enter 10.5.15.6.
Step 26: In the Admin Username box, enter refarchadmin.
Step 27: In the Admin Password box, enter the password.
Step 28: In the Public IP Address Name box, enter aras-vmfw1.
Step 29: In the Network Security Group box, enter None.
Step 30: Review the terms and condions. If they are acceptable, select I agree to the terms and condions.
Step 31: Click Purchase.
4.2 License VM-Series on Azure
Your VM-Series is now running on Azure but is unlicensed and using a factory default conguraon.
This procedure assumes that you have a valid authorizaon code for your VM-Series device(s) and have registered the
code on the Palo Alto Networks customer support portal (
hps://support.palotaltonetworks.com
).
Step 1: Log in to your VM-Series device (example:
hps://aras-vmfw1.westus.cloudapp.azure.com
).
50Palo Alto Networks
Deployment Details for VM-Series
Step 2: In Device > Setup > Management > General Sengs, click the edit cog.
Step 3: In the Domain box, enter the domain sux.
Step 4: In the Time Zone list, select the appropriate me zone (example: US/Pacic).
Step 5: In Device > Setup > Services > Services, click the edit cog.
Step 6: In the Primary DNS Server box, enter 168.63.129.16.
Step 7: Change to the NTP tab. In the Primary NTP Server secon NTP Server Address box, enter 0.pool.ntp.org.
Step 8: In the Secondary NTP Server secon NTP Server Address box, enter 1.pool.ntp.org, and then click OK.
Step 9: Click Commit.
Step 10: In Device > Licenses, click Acvate feature using authorizaon code.
Step 11: In the Update License window, in the Authorizaon Code box, enter the authorizaon code (example
I1234567), and then click OK.
51Palo Alto Networks
Deployment Details for VM-Series
Step 12: Click OK to acknowledge the PAN services restart warning.
The VM-Series services are restarted aer the license is installed. Your management
session to the VM-Series must be refreshed aer the restart; this may take a few min-
utes.
Note
4.3 Update Device Soware
Step 1: Navigate to Device > Soware.
If you receive an Operaon Failed warning with the message No update informaon
available, you may click Close to acknowledge. No acon is required.
Note
Step 2: In Device > Soware, click Check Now.
Step 3: For version 8.1.2, in the Acons column, click Download. Click Close when complete.
Step 4: Aer the status in the Available column has changed to Downloaded, in the Acon column, click Install.
52Palo Alto Networks
Deployment Details for VM-Series
Step 5: When prompted to reboot the device, click Yes.
Step 6: Aer the reboot, in Device > Dynamic Updates, click Check Now.
Preparing VM-Series Firewall Conguraons Using Panorama
5.1 Congure Device Group
5.2 Congure Panorama Templates and Device Group
5.3 Select Azure-3-Zone Template for Conguraon
5.4 Congure Device Parameters
5.5 Create Zones and Virtual Routers
5.6 Create Management Proles
5.7 Create Ethernet Interfaces
5.8 Add Stac Routes to Virtual Routers
5.9 Commit Changes
5.10 Retrieve and Verify Logging Service License
5.11 Congure Logging-Service Template
Procedures
53Palo Alto Networks
Deployment Details for VM-Series
Panorama provides a number of tools for centralized administraon:
• Hierarchical device groups—Panorama manages common policies and objects through hierarchical device
groups. Mul-level device groups are used to centrally manage the policies across all deployment locaons with
common requirements
• Templates/template stacks—Panorama manages common device and network conguraon through templates.
You can use templates to manage conguraon centrally and then push the changes to all managed rewalls.
This approach avoids your making the same individual rewall change repeatedly across many devices. To make
things easier, you can stack templates and use them as building blocks for device and network conguraon.
5.1 Congure Device Group
This guide uses a single device group specic to the shared design model. The objects and policies are created in the
procedures that require them.
Step 1: In Panorama > Device Groups, click Add.
Step 2: In the Name box, enter Azure-Shared.
Step 3: In the Descripon box, enter a valid descripon.
Step 4: In the Parent Device Group box, verify the value is set to Shared, and then click OK.
5.2 Congure Panorama Templates and Device Group
The templates include conguraon for all funcons that are common across all the VM-Series devices in the shared
design model.
Two templates are used. The Azure-3-Zone template includes rewall networking funcons including interfaces,
zones, and virtual routers. The Logging Service template includes device funcons to enable the Logging Service. Both
templates are applied to devices using a Panorama template stack, which logically merges the assigned templates and
associates them with the relevant devices.
This procedure creates the templates that are used for subsequent procedures in this guide. The specic conguraons
for these templates are created within the relevant procedures. You create the template stack later in this guide, when
associang the rst device to the templates.
Step 1: In Panorama > Templates, click Add.
Step 2: In the Name box, enter Azure-3-Zone.
54Palo Alto Networks
Deployment Details for VM-Series
Step 3: In the Descripon box, enter a valid descripon, and then click OK.
Step 4: In Panorama > Templates, click Add.
Step 5: In the Name box, enter Logging Service.
Step 6: In the Descripon box, enter a valid descripon, and then click OK.
Step 7: On the Commit menu, click Commit to Panorama.
Step 8: Verify the addional tabs for Device Groups (Policies and Objects) and Templates (Network and Device) are
now visible on the Panorama management portal.
You may need to refresh the screen on the secondary Panorama and navigate to a dif-
ferent tab before the addional tabs becomes visible.
Note
5.3 Select Azure-3-Zone Template for Conguraon
Step 1: Log in to your Panorama (example:
hps://ara-panorama-1.westus.cloudapp.azure.com
)
Step 2: Navigate to Templates > Device.
Step 3: In the Template list, select Azure-3-Zone.
5.4 Congure Device Parameters
This procedure ensures that DNS and NTP are congured consistently across all devices.
Step 1: In Templates > Device > Setup > Services > Global > Services, click the Edit cog.
Step 2: In the Primary DNS Server box, enter 168.63.129.16
55Palo Alto Networks
Deployment Details for VM-Series
Step 3: Change to the NTP tab. In the Primary NTP Server secon NTP Server Address box, enter 0.pool.ntp.org.
Step 4: In the Secondary NTP Server secon NTP Server Address box, enter 1.pool.ntp.org, and then click OK.
5.5 Create Zones and Virtual Routers
Table 7 Zone and virtual router sengs
Zone name Zone type Virtual router name
Public Layer3 VR-Public
Private Layer3 VR-Private
VPN Layer3 VR-VPN
Step 1: In Templates > Network > Zones, click Add. The Zone window appears.
Step 2: In the Name box, enter Public.
Step 3: In the Type list, select Layer3, and then click OK.
Step 4: In Templates > Network > Virtual Routers, click Add. The Virtual Router conguraon window appears.
56Palo Alto Networks
Deployment Details for VM-Series
Step 5: In the Name box, enter VR-Public, and then click OK.
Step 6: Repeat Step 1 through Step 5 for all rows in Table 7.
5.6 Create Management Proles
The load-balancer health-checks use HTTPS probes towards the rewall’s dataplane interfaces. The rewall blocks
responses to these probes by default. Interface management proles are used to override the default block operaon.
A single management prole may be applied to mulple interfaces. We recommend
separate management proles per interface, if required, to allow for dierent manage-
ment policies.
Note
Step 1: In Templates > Network > Network Proles > Interface Mgmt, click Add. The Interface Management Prole
conguraon window appears.
Step 2: In the Name box, enter MP-Public.
Step 3: In the Administrave Management Services secon, select HTTPS.
Step 4: In the Permied IP Addresses pane, click Add.
57Palo Alto Networks
Deployment Details for VM-Series
Step 5: Enter 168.63.129.16/32, and then click OK.
Step 6: Repeat Step 1 through Step 5 for MP-Private and MP-VPN.
5.7 Create Ethernet Interfaces
Although the VM-Series is not a modular hardware plaorm, assign interfaces to Slot 1
when using Panorama templates for the VM-Series.
Note
Table 8 Azure-3-zone template interface sengs
Slot Interface Interface type Virtual router Security zone IPv4
Management
profile
Slot 1 ethernet1/1 Layer3 VR-Public Public DHCP Client MP-Public
Slot 1 ethernet1/2 Layer3 VR-Private Private DHCP Client MP-Private
Slot 1 ethernet1/3 Layer3 VR-VPN VPN DHCP Client MP-VPN
58Palo Alto Networks
Deployment Details for VM-Series
Step 1: In Templates > Network > Interfaces > Ethernet, click Add Interface. The Ethernet Interface conguraon
window appears.
Step 2: In the Slot list, select Slot 1.
Step 3: In the Interface Name list, select ethernet1/1.
Step 4: In the Interface Type list, select Layer3.
Step 5: In the Assign Interface To Virtual Router list, select VR-Public.
Step 6: In the Assign Interface To Security Zone list, select Public.
Step 7: Change to the IPv4 tab.
Step 8: Select DHCP client.
Step 9: Select Enable and clear Automacally create default route poinng to default gateway provided by server.
Step 10: Change to the Advanced tab.
59Palo Alto Networks
Deployment Details for VM-Series
Step 11: In the Management Prole list, select MP-Public, and then click OK.
Step 12: Click Yes to accept the interface management prole Warning.
Step 13: Repeat Step 1 through Step 11 for all rows in Table 8.
5.8 Add Stac Routes to Virtual Routers
Each of the three virtual routers requires stac route conguraon. Repeat this procedure three mes, using the values
in the appropriate table:
• When conguring stac routes for VR-Public, use the values in Table 9.
• When conguring stac routes for VR-Private, use the values in Table 10.
• When conguring stac routes for VR-VPN, use the values in Table 11.
60Palo Alto Networks
Deployment Details for VM-Series
Table 9 VR-Public IPv4 stac routes
Name Destination prefix Interface Next-hop Next-hop value
default 0.0.0.0/0 ethernet1/1 IP Address 172.16.1.1
Azure-Probe 168.63.129.16/32 ethernet1/1 IP Address 172.16.1.1
Net-10.5.0.0 10.5.0.0/16 None Next VR VR-Private
Table 10 VR-Private IPv4 stac routes
Name Destination prefix Interface Next-hop Next-hop value
default 0.0.0.0/0 None Next VR VR-External
Azure-Probe 168.63.129.16/32 ethernet1/2 IP Address 10.5.0.1
Net-10.5.1.0 10.5.1.0/24 ethernet1/2 IP Address 10.5.0.1
Net-10.5.2.0 10.5.1.0/24 ethernet1/2 IP Address 10.5.0.1
Net-10.5.3.0 10.5.1.0/24 ethernet1/2 IP Address 10.5.0.1
Net-10.6.0.0 10.6.0.0/24 None Next VR VR-VPN
Table 11 VR-VPN IPv4 stac routes
Name Destination prefix Interface Next-hop Next-hop value
Azure-Probe 168.63.129.16/32 ethernet1/3 IP Address 10.5.15.1
Net-10.6.0.0 10.6.0.0/24 ethernet1/3 IP Address 10.5.15.1
Net-10.5.0.0 10.5.0.0/16 None Next VR VR-Private
Step 1: In Templates > Network > Virtual Routers, click VR-Public. The Virtual Router conguraon window appears.
Step 2: On the Stac Routes tab, click Add. The Virtual Router —Stac Route—IPv4 conguraon window appears.
Step 3: In the Name box, enter default.
Step 4: In the Desnaon box, enter 0.0.0.0/0.
Step 5: In the Interface list, select ethernet1/1.
Step 6: In the Next Hop list, select IP Address and enter 172.16.1.1, click OK, and then click OK again.
61Palo Alto Networks
Deployment Details for VM-Series
Step 7: Aer adding all routes for this virtual router, click OK to close the Virtual Router window.
5.9 Commit Changes
Step 1: On the Commit menu, click Commit to Panorama.
5.10 Retrieve and Verify Logging Service License
Step 1: In Panorama > Licenses, click Retrieve license keys from license server.
Step 2: Verify that the Logging Service license is acve.
62Palo Alto Networks
Deployment Details for VM-Series
5.11 Congure Logging-Service Template
Step 1: Navigate to Templates > Device.
Step 2: In the Template list, select Logging-Service.
Step 3: In Templates > Device > Setup > Management > Logging Service, click the Edit cog.
Step 4: Select Enable Logging Service.
Step 5: Select Enable Enhanced Applicaon Logging.
Step 6: In Region list, select americas, and then click OK.
Step 7: In Templates > Device > Log Sengs > System, click Add. The Log Sengs—System conguraon window
appears.
Step 8: In the Name box, enter System Logs.
63Palo Alto Networks
Deployment Details for VM-Series
Step 9: Select Panorama/Logging Service, and then click OK.
Step 10: In Templates > Device > Log Sengs > Conguraon, click Add. The Log Sengs—Conguraon window
appears.
Step 11: In the Name box, enter Conguraon Logs.
Step 12: Select Panorama/Logging Service, and then click OK.
Step 13: On the Commit menu, click Commit to Panorama.
Managing VM-Series with Panorama
6.1 Add VM-Series to Panorama
6.2 Add VM-Series to Template Stack and Device Group
6.3 Refresh License to Enable Logging Service
Procedures
6.1 Add VM-Series to Panorama
This procedure is required for each new VM-Series device that is added to Azure. Later in this guide, you perform the
procedure to automacally bootstrap the VM-Series to register with Panorama.
64Palo Alto Networks
Deployment Details for VM-Series
Step 1: Log in to your VM-Series device (example:
hps://aras-vmfw1.westus.cloudapp.azure.com
).
Step 2: In Dashboard > General Informaon, record the Serial #.
Step 3: In Device > Setup > Management > Panorama Sengs, click the edit cog.
Step 4: In the Panorama Servers secon, in the top box, enter 192.168.1.4.
Step 5: If you are using Panorama High Availability, in the boom box, enter 192.168.1.5, and then click OK.
Step 6: Click Commit.
Step 7: Log in to Panorama (example:
hps://ara-panorama-1.westus.cloudapp.azure.com
)
Step 8: In Panorama > Managed Devices > Summary, click Add.
65Palo Alto Networks
Deployment Details for VM-Series
Step 9: In the Devices box, enter the serial number from Step 2, and then click OK.
Step 10: On the Commit menu, click Commit to Panorama.
Step 11: In Panorama > Managed Devices > Summary, verify that the device state of the VM-Series is Connected. It
may take a few minutes for the state to change.
6.2 Add VM-Series to Template Stack and Device Group
This procedure adds devices to the template stack and device groups. The template stack is created and congured
when you add the rst VM-Series device only.
Step 1: Log in to Panorama (example:
hps://ara-panorama-1.westus.cloudapp.azure.com
).
Opon 1: Template stack does not already exist
This opon creates a template stack.
Step 1: In Panorama > Templates, click Add Stack.
Step 2: In the Name box, enter Azure-Shared-Model.
Step 3: In the Templates pane, click Add. Enter Azure-3-Zone.
Step 4: In the Templates pane, click Add. Enter Logging-Service.
66Palo Alto Networks
Deployment Details for VM-Series
Opon 2: Template stack has already been created
This opon modies the exisng template stack.
Step 1: In Panorama > Templates, click Azure-Shared-Model.
Proceed with conguring the template stack.
Step 2: In the Devices pane, select ARAS-VMFW1 to assign it to the template stack, and then click OK.
Step 3: On the Commit menu, click Commit and Push.
The local conguraon on each VM-Series should now reect the template-based conguraon that was created on
Panorama. This includes interfaces, zones, virtual routers, management proles, and Logging Service.
Step 4: In Panorama > Device Groups, click Azure-Shared.
67Palo Alto Networks
Deployment Details for VM-Series
Step 5: In the Devices pane, select ARAS-VMFW1 to assign it to the device group, and then click OK.
Step 6: On the Commit menu, click Commit and Push.
Device group policies and objects are created in procedures later in this guide. The policies and objects for the Azure-
Shared device group are automacally pushed to the local devices from Panorama as they are created.
6.3 Refresh License to Enable Logging Service
Step 1: Log in to Panorama (example:
hps://ara-panorama-1.westus.cloudapp.azure.com
).
Step 2: In Panorama > Device Deployment > Licenses, click Refresh. The Refresh License Deployment window ap-
pears.
68Palo Alto Networks
Deployment Details for VM-Series
Step 3: In the Device Name column, select the VM-Series, and then click Refresh.
Step 4: Verify the details include Successfully installed license ‘Logging Service,’ and then click Close.
69Palo Alto Networks
Deployment Details for Azure Networking and Firewall Policies
Deployment Details for Azure Networking and
Firewall Policies
The VM-Series devices do not acvely forward trac within Azure unl they have been integrated into Azure network-
ing and the rewall policies for each trac prole have been created. You must complete the complementary proce-
dure groups in order support the trac proles in the shared design model.
Resiliency for the trac proles is implemented using Azure user-dened routes and Azure Load-Balancer these pro-
cedures are included in the rst procedure group. The trac proles within the shared design model each require a
unique rewall policy. A second procedure group congures the policies required for each trac prole.
Figure 6 Azure networking for shared design model
192.168.1.6
192.168.1.7
Ma nagemen t – 192.168.1.0/24
172.16.1.6
(et h 1)
10.5.0.6
(et h 2)
Virtual Network
172.16.1.7
(et h 1)
10.5.0.7
(et h 2)
We b - 1 0. 5 . 1.0 / 24
Business - 1 0.5 . 2. 0 / 24
DB - 1 0. 5 .3. 0 / 24
10.5.15.6
(et h 3)
10.5.15.7
(et h 3)
VPN - 10.5.15.0/24
Private
1 0. 5 .0. 0 / 24
Pub lic
1 72 . 16 .1 . 0/ 24
10.5.0.21
aras-public-sh ar ed -we b
aras-public-sh ar ed -we b
aras-public-sh ar ed -we b
70Palo Alto Networks
Deployment Details for Azure Networking and Firewall Policies
Conguring Azure Networking and Services
7.1 Create the Public IP Address for the Azure Public Load-Balancer
7.2 Create the Azure Public Load-Balancer
7.3 Congure the Azure Public Load-Balancer
7.4 Create the Azure Internal Load-Balancer
7.5 Congure the Azure Internal Load-Balancer for Outbound Access
7.6 Congure the Azure Internal Load-Balancer for Inbound Access
7.7 Congure Azure User Dened Routes
7.8 Apply Route Tables to Subnets
Procedures
The following procedures are completed using the Azure Resource Manager. Sign in to Azure at
hps://portal.azure.com
.
7.1 Create the Public IP Address for the Azure Public Load-Balancer
This procedure creates a public IP address that is assigned as the frontend IP address for the Azure public load-balancer
for inbound trac to the web server resources.
Note the FQDN that is dened by adding the locaon specic sux to your DNS name label. You use this value in a
subsequent procedure when you create Panorama IP address objects for the Inbound Access trac prole.
Step 1: In Home > Public IP addresses, click Add.
Step 2: In the Name box, enter AzureRefArch-Public-Shared-Web.
Step 3: Select Standard SKU.
Step 4: In the DNS name label box, enter aras-public-shared-web.
Step 5: In the Resource Group secon, choose Use Exisng, and then select AzureRefArch-Shared.
Step 6: Click Create.
Step 7: Record the value for the FQDN (example: aras-public-shared-web.westus.cloudapp.azure.com).
71Palo Alto Networks
Deployment Details for Azure Networking and Firewall Policies
7. 2 Create the Azure Public Load-Balancer
You create the Azure Public Load-Balancer with a single public frontend IP address and associate it with the public
interfaces of a pair of VM-Series rewalls using oang IP.
Figure 7 Azure public load-balancer
172.16.1.6
(et h 1)
Virtual Network
172.16.1.7
(et h 1)
Pub lic
1 72 . 16 .1 . 0/ 24
aras-public-sh ar ed -we b
aras-public-sh ar ed -we b
aras-public-sh ar ed -we b
Step 1: In Home > Load Balancers, click Add.
Step 2: In the Name box, enter AzureRefArch-Shared-Public.
Step 3: In the Type secon, select Public.
Step 4: In the SKU secon, select Standard.
Step 5: Click the Public IP address secon, and then select AzureRefArch-Public-Shared-Web.
This address is associated with the default frontend IP conguraon (LoadBalancerFrontEnd). You may add addional
frontend IP addresses to the load-balancer if necessary aer it has been created.
Step 6: In the Resource Group secon, choose Use Exisng, and then select AzureRefArch-Shared.
72Palo Alto Networks
Deployment Details for Azure Networking and Firewall Policies
Step 7: Click Create.
7. 3 Congure the Azure Public Load-Balancer
This procedure assumes that all of the VM-Series rewalls that are to be associated to the load-balancer have already
been deployed and does not include the steps to add a new rewall to an exisng backend pool.
Step 1: In Home > Load Balancers > AzureRefArch-Shared-Public, click Health probes.
Step 2: Click Add.
Step 3: In the Name box, enter HTTPS-Probe.
Step 4: In the Port box, enter 443, and then click OK.
73Palo Alto Networks
Deployment Details for Azure Networking and Firewall Policies
Step 5: In Home > Load Balancers > AzureRefArch-Shared-Public, click Backend pools.
Step 6: Click Add.
Step 7: In the Name box, enter Firewall-Layer.
Step 8: In the Virtual network list, select azurerefarch-vnet (X VM), where X is the total number of VM-Series re-
walls and Panorama virtual machines already deployed in your VNet.
Step 9: In the VIRTUAL MACHINE column, select a VM-Series to be added to this backend pool (example: aras-vm-
fw1).
Step 10: In the IP ADDRESS column, select the IP conguraon that is associated to the Shared-Public subnet. (ex-
ample: ipcong-untrust).
Step 11: Repeat Step 9 and Step 10 for all VM-Series rewalls that are to be assigned to this backend pool.
Step 12: Click Add.
Next, you create a load balancing rule for each required TCP port (Example: TCP/80, TCP/443).
Step 13: In Home > Load Balancers > AzureRefArch-Shared-Public, click Load balancing rules.
Step 14: Click Add.
74Palo Alto Networks
Deployment Details for Azure Networking and Firewall Policies
Step 15: In the Name box, enter AzureRefArch-Shared-Public-Web-80.
Step 16: In the Frontend IP address list, select LoadBalancerFrontEnd.
Step 17: In the Port box, enter 80.
Step 18: In the Backend port box, enter 80.
Step 19: In the Backend pool list, select Firewall-Layer.
Step 20: In the Health probe list, select HTTPS-Probe.
Step 21: In the Floang IP (direct server return) secon, select Enabled, and then click OK.
75Palo Alto Networks
Deployment Details for Azure Networking and Firewall Policies
7.4 Create the Azure Internal Load-Balancer
You create the Azure Internal Load-Balancer with a single private frontend IP address and associate it with the private
interfaces of a pair of VM-Series rewalls.
Figure 8 Azure internal load-balancer for outbound access
10.5.0.6
(et h 2)
Virtual Network
10.5.0.7
(et h 2)
We b - 1 0. 5 .1. 0 / 24
Business - 1 0.5 . 2.0 / 24
DB - 1 0. 5 .3. 0 / 24
Private
1 0. 5 .0. 0 / 24
10.5.0.21
You use the frontend IP address as the roung next-hop for desnaon addresses on the public networks and the
internet.
Step 1: In Home > Load Balancers, click Add.
Step 2: In the Name box, enter AzureRefArch-Shared-Internal.
Step 3: In the Type secon, select Internal.
Step 4: In the SKU secon, select Standard.
Step 5: Click the Virtual network Choose a virtual network secon, and select AzureRefArch-VNET.
Step 6: Click the Subnet Choose a subnet secon, and select Shared-Private.
Step 7: In the IP address assignment secon, select Stac.
Step 8: In the Private IP address box, enter 10.5.0.21. This address is associated with the default frontend IP congu-
raon (LoadBalancerFrontEnd), which is used for outbound access. Addional frontend IP addresses may be added to
the load-balancer if necessary aer it has been created.
76Palo Alto Networks
Deployment Details for Azure Networking and Firewall Policies
Step 9: In the Resource Group secon, choose Use Exisng, and then select AzureRefArch-Shared.
Step 10: Click Create.
7. 5 Congure the Azure Internal Load-Balancer for Outbound Access
Step 1: In Home > Load Balancers > AzureRefArch-Shared-Internal, click Health probes.
Step 2: Click Add.
Step 3: In the Name box, enter HTTPS-Probe.
77Palo Alto Networks
Deployment Details for Azure Networking and Firewall Policies
Step 4: In the Port box, enter 443, and then click OK.
Step 5: In Home > Load Balancers > AzureRefArch-Shared-Internal, click Backend pools.
Step 6: Click Add.
Step 7: In the Name box, enter Firewall-Layer-Private.
Step 8: In the Virtual network list, select azurerefarch-vnet (X VM), where X is the total number of VM-Series re-
walls and Panorama virtual machines already deployed in your VNet.
Step 9: In the VIRTUAL MACHINE column, select a VM-Series to be added to this backend pool (example: aras-vm-
fw1).
Step 10: In the IP ADDRESS column, select the IP conguraon that is associated to the Shared-Private subnet. (ex-
ample: ipcong-trust).
Step 11: Repeat Step 9 and Step 10 for all VM-Series rewalls that are to be assigned to this backend pool.
Step 12: Click Add.
Step 13: In Home > Load Balancers > AzureRefArch-Shared-Internal, click Load balancing rules.
Step 14: Click Add.
Step 15: In the Name box, enter Private-All-Ports.
Step 16: In the Frontend IP address list, select LoadBalancerFrontEnd.
Step 17: Select HA ports.
Step 18: In the Backend pool list, select Firewall-Layer-Private.
78Palo Alto Networks
Deployment Details for Azure Networking and Firewall Policies
Step 19: In the Health probe list, select HTTPS-Probe, and then click OK.
7. 6 Congure the Azure Internal Load-Balancer for Inbound Access
This procedure is required only if you have resources in the Shared-Public subnet that need access to the private net-
works. Because this subnet uses Azure internal addressing, you cannot use the public load-balancer but instead use an
addional frontend IP address and backend pool on the internal load-balancer.
79Palo Alto Networks
Deployment Details for Azure Networking and Firewall Policies
Figure 9 Azure internal load-balancer for inbound access
172.16.1.6
(et h 1)
Virtual Network
172.16.1.7
(et h 1)
Pub lic
1 72 . 16 .1 . 0/ 24
172.16.1.21
The frontend IP address is used as the roung next-hop for desnaon address on the private networks.
Step 1: In Home > Load Balancers > AzureRefArch-Shared-Internal, click Frontend IP conguraon.
Step 2: Click Add.
Step 3: In the Name box, enter Internal-Frontend-Public.
Step 4: In the Subnet list, select Shared-Public.
Step 5: In the Assignment secon, select Stac.
Step 6: In the IP address box, enter 172.16.1.21.
Step 7: In Home > Load Balancers > AzureRefArch-Shared-Internal, click Backend pools.
Step 8: Click Add.
Step 9: In the Name box, enter Firewall-Layer-Public.
Step 10: In the Virtual network list, select azurerefarch-vnet (X VM), where X is the total number of VM-Series re-
walls and Panorama virtual machines already deployed in your VNet.
80Palo Alto Networks
Deployment Details for Azure Networking and Firewall Policies
Step 11: In the VIRTUAL MACHINE column, select a VM-Series to be added to this backend pool (example: aras-
vmfw1).
Step 12: In the IP ADDRESS column, select the IP conguraon that is associated to the Shared-Public subnet. (ex-
ample: ipcong-untrust).
Step 13: Repeat Step 11 and Step 12 for all VM-Series rewalls that are to be assigned to this backend pool.
Step 14: Click Add.
Step 15: In Home > Load Balancers > AzureRefArch-Shared-Internal, click Load balancing rules.
Step 16: Click Add.
Step 17: In the Name box, enter Public-All-Ports.
Step 18: In the Frontend IP address list, select Internal-Frontend-Public.
Step 19: Select HA ports.
Step 20: In the Backend pool list, select Firewall-Layer-Public.
Step 21: In the Health probe list, select HTTPS-Probe, and then click OK.
7.7 Congure Azure User Dened Routes
Azure Networking automacally creates system routes for the address space dened in the VNet. Addional system
routes are also added to the Azure route table, including a default route to the internet and null routes for RFC-1918
and RFC-6598 ranges.
Override the Azure system routes with user-dened routes (UDRs) in order to isolate subnets and to logically insert
virtual devices such as load-balancers and rewalls into the trac forwarding path.
Data trac is not forwarded to the rewalls within the VNet unl UDRs are created to
direct trac to the rewalls. In a resilient environment, data trac is directed to load-
balancers that act as frontends for the rewalls contained in their backend pools.
Note
81Palo Alto Networks
Deployment Details for Azure Networking and Firewall Policies
Table 12 Azure system routes
Address space Address prefix Next-hop type
VNet dened 192.168.1.0/24 Virtual Network
VNet dened 172.16.0.0/23 Virtual Network
VNet dened 10.5.0.0/16 Virtual Network
Default (Azure dened) 0.0.0.0/0 Internet
RFC-1918 (Azure dened) 10.0.0.0/8 None
RFC-1918 (Azure dened) 172.16.0.0/12 None
RFC-1918 (Azure dened) 192.168.0.0/16 None
RFC-6598 (Azure dened) 100.64.0.0/10 None
If you add a UDR with the same prex and prex-length as a system route, the UDR becomes the acve route, and the
state of the original system route changes to an Invalid state.
If you add a UDR with a more specic prex that falls within the address space of a system route, the UDR becomes an
acve route, and the original system route also remains in an Acve state.
The use of UDR summary routes may have unexpected consequences. If you apply
a UDR summary to a subnet that falls within the summary but does not have a more
specic UDR, trac within the subnet (host to host) is controlled by the UDR.
As an example, if you applied a UDR for 10.5.0.0/16 with a next-hop of 10.5.0.21 (re-
wall load-balancer) to the 10.5.1.0/24 subnet, then trac between host 10.5.1.4 and
host 10.5.1.5 is routed through the rewall as intrazone trac. This eecvely causes
microsegmentaon.
Caution
Azure networking does not have a concept of equal cost paths; you cannot add mulple UDRs with same prex and
prex-length with dierent next-hops to perform trac load-balancing. The only method by which you may perform
load-balancing is by using UDRs to forward trac to an Azure load-balancing resource.
The eecve roung table aer adding UDRs is evaluated using tradional roung rules based on longest match of the
desnaon address.
82Palo Alto Networks
Deployment Details for Azure Networking and Firewall Policies
Figure 10 User-dened routes with shared design model
Virtual Network
Additional Private UDRsP ri vate UDRP ub li c UD RMg mt U DR
Internet
0.0.0.0/0
Publi c Ra ng e
172.16.0.0/23
Mg mt R ange
192.168.1.0/24
10.5.0.6 10.5.0.6None Virtual Network
Syst em Route
Virtual Network
Syst em Route
10.5.0.6 10.5.0.6
Virtual Network
Syst em Route
Virtual Network
Syst em Route
NoneNone None
10.5.0.6 Virtual Network
Syst em Route
10.5.0.6
Virtual Network
Syst em Route
172.16.1.6
10.5.0.6 10.5.0.6 Virtual Network
Syst em Route
Virtual Network
Syst em Route
10.5.0.6
Internet
Syst em Route
Internet
Syst em Route
10.5.0.6
Private Range
10.5.0.0/20
Private Range
10.5.0.0/2 0
Mgmt Range
192.168.1.0/24
P ub li c Ra nge
172.16.0.0/23
Management
Subnet
192.168.1.0/24
P ub l i c
Subnet
172.16.1.0/24
P ri v at e -FW
Subnet
10.5.0.0/2 4
DB
Subnet
10.5.3.0/2 4
Business
Subnet
10.5.2.0/2 4
Web
Subnet
10.5.1.0/2 4
Web Ran ge
10.5.1.0/24
Business Range
10.5.2.0/24
DB R ange
10.5.3.0/24
None
Table 13 Azure route tables
Subnet Route table name Resource group Table of UDRs
Management AzureRefArch-Management AzureRefArch Table 14
Shared-Public AzureRefArch-Shared-Public AzureRefArch-Shared Table 15
Shared-Private AzureRefArch-Shared-Private AzureRefArch-Shared Table 16
Shared-Web AzureRefArch-Shared-Web AzureRefArch-Shared Table 17
Shared-Business AzureRefArch-Shared-Business AzureRefArch-Shared Table 18
Shared-DB AzureRefArch-Shared-DB AzureRefArch-Shared Table 19
Table 14 Management subnet UDRs (192.168.1.0/24)
Route name Address prefix Next-hop type
Next-hop
address Comments
Blackhole-Public 172.16.0.0/23 None —Block trac to Public IP address space
Blackhole-Private 10.5.0.0/20 None —Block trac to Private IP address space
Table 15 Public subnet UDRs (172.16.1.0/24)
Route name Address prefix Next-hop type
Next-hop
address Comments
Blackhole-Management 192.168.1.0/24 None —Block trac to Management IP
address space
Net-10.5.0.0 10.5.0.0/20 Virtual
Appliance
172.16.1.21 Frontend IP of load-balancer
83Palo Alto Networks
Deployment Details for Azure Networking and Firewall Policies
Table 16 Private subnet UDRs (10.5.0.0/24)
Route name Address prefix Next-hop type
Next-hop
address Comments
Blackhole-Management 192.168.1.0/24 None —Block trac to Management IP
address space
Net-172.16.0.0 172.16.0.0/23 Virtual
Appliance
10.5.0.21 Frontend IP of load-balancer
UDR-default 0.0.0.0/0 Virtual
Appliance
10.5.0.21 Frontend IP of load-balancer.
Overrides system route
Table 17 Web subnet UDRs (10.5.1.0/24)
Route name Address prefix Next-hop type
Next-hop
address Comments
Blackhole-Management 192.168.1.0/24 None —Block trac to Management IP
address space
Net-172.16.0.0 172.16.0.0/23 Virtual
Appliance
10.5.0.21 Frontend IP of load-balancer
UDR-default 0.0.0.0/0 Virtual
Appliance
10.5.0.21 Frontend IP of load-balancer
Overrides system route
Net-10.5.2.0
(oponal for intrazone)
10.5.2.0/24 Virtual
Appliance
10.5.0.21 Frontend IP of load-balancer
Net-10.5.3.0
(oponal for intrazone)
10.5.3.0/24 Virtual
Appliance
10.5.0.21 Frontend IP of load-balancer
Table 18 Business subnet UDRs (10.5.2.0/24)
Route name Address prefix Next-hop type
Next-hop
address Comments
Blackhole-Management 192.168.1.0/24 None —Block trac to Management IP
address space
Net-172.16.0.0 172.16.0.0/23 Virtual
Appliance
10.5.0.21 Frontend IP of load-balancer
UDR-default 0.0.0.0/0 Virtual
Appliance
10.5.0.21 Frontend IP of load-balancer. Over-
rides system route
Net-10.5.1.0
(oponal for intrazone)
10.5.1.0/24 Virtual
Appliance
10.5.0.21 Frontend IP of load-balancer
Net-10.5.3.0
(oponal for intrazone)
10.5.3.0/24 Virtual
Appliance
10.5.0.21 Frontend IP of load-balancer
84Palo Alto Networks
Deployment Details for Azure Networking and Firewall Policies
Table 19 DB subnet UDRs (10.5.3.0/24)
Route name Address Prefix Next-hop type
Next-hop
address Comment
Blackhole-Management 192.168.1.0/24 None —Block trac to Management IP
address space
Net-172.16.0.0 172.16.0.0/23 Virtual
Appliance
10.5.0.21 Frontend IP of load-balancer
UDR-default 0.0.0.0/0 Virtual
Appliance
10.5.0.21 Frontend IP of load-balancer. Over-
rides system route
Net-10.5.1.0
(oponal for intrazone)
10.5.1.0/24 Virtual
Appliance
10.5.0.21 Frontend IP of load-balancer
Net-10.5.2.0
(oponal for intrazone)
10.5.2.0/24 Virtual
Appliance
10.5.0.21 Frontend IP of load-balancer
Repeat this procedure for each entry in Table 13:
Step 1: In Home > Route tables, click Add.
Step 2: In the Name box, enter AzureRefArch-Management.
Step 3: In the Resource Group secon, choose Use Exisng, and then select AzureRefArch, then click Create.
Step 4: In Home > Route tables > AzureRefArch-Management, click Routes.
85Palo Alto Networks
Deployment Details for Azure Networking and Firewall Policies
Step 5: Repeat these substeps for all entries in the table of UDRs:
• In Home > Routes tables > AzureRefArch-Management—Routes, click Add.
• In the Route name box, enter Blackhole-Public.
• In the Address prex box, enter 172.16.0.0/23.
• In the Next hop type list, select None.
• If the Next-hop type is Virtual appliance, then enter the Next hop address value and click OK.
7. 8 Apply Route Tables to Subnets
The UDRs take eect only aer the route table is associated with the subnet.
Step 1: In Home > Virtual networks > AzureRefArch-VNET, click Subnets.
Step 2: Click Management.
Step 3: Click the Route table secon, and then in the Resource pane, select AzureRefArch-Management.
Step 4: Click Save, and then click X to Close.
Step 5: Repeat Step 2 through Step 4 for each entry in Table 13.
86Palo Alto Networks
Deployment Details for Azure Networking and Firewall Policies
Using Panorama to Congure Centralized Security Policy and NAT Policy
8.1 Create Logging Prole for Logging Service
8.2 Inbound Access—Create Address Objects
8.3 Inbound Access—Congure NAT Policy
8.4 Inbound Access—Congure Security Policy
8.5 Outbound Access—Create Public IP Address and Associate with Firewall
8.6 Outbound Access—Create Address Objects
8.7 Outbound Access—Congure NAT Policy
8.8 Outbound Access—Congure Security Policy
8.9 East/West Trac
Procedures
This procedure group includes the objects, NAT policy rules, and security policy rules for each of the trac proles in
the shared design model:
• Inbound access trac prole
• Outbound access trac prole
• East/West trac prole
Each trac prole is described and congured separately so that you can cover the signicant dierences in detail and
in context.
All procedures and steps in this procedure group are performed on Panorama.
Verify that you have selected the proper device group for the following procedures.
Note
8.1 Create Logging Prole for Logging Service
This procedure creates the log-forwarding prole to send security policy logs to Logging Service. This prole is associ-
ated to security policy rules used in each of three trac proles. Because the log forwarding prole is referenced in
every security policy rule, you must complete this procedure rst.
87Palo Alto Networks
Deployment Details for Azure Networking and Firewall Policies
Step 1: Log in to Panorama (example:
hps://ara-panorama-1.westus.cloudapp.azure.com
).
Step 2: Navigate to Device Groups > Objects.
Step 3: In the Device Group list, select Azure-Shared.
Step 4: In Device Groups > Objects > Log Forwarding, click Add.
Step 5: In the Name box, enter LoggingService-Prole.
Step 6: Select Enable enhanced applicaon logging to Logging Service (including trac and url logs), and then click
OK.
8.2 Inbound Access—Create Address Objects
This procedure assumes that you have already deployed a set of web server resources in the Shared-Web subnet. In
a resilient web server model, the web servers are in a backend pool of an Azure internal load-balancer. The load-bal-
ancer frontend IP is referenced by security and NAT policy rules and should be dened as an address object (example:
10.5.0.20). This guide does not include the procedure to create this load-balancer or to create the web server resourc-
es.
88Palo Alto Networks
Deployment Details for Azure Networking and Firewall Policies
Table 20 Inbound trac address objects
Object name Description Type Type value
Host-Shared-Public-Web FQDN of public web
server
FQDN aras-public-shared-web.westus.cloudapp.azure.
com
Host-Shared-Private-
Web-ILB
IP address of private
internal load-balancer
IP Netmask 10.5.0.20
Step 1: Log in to Panorama (example:
hps://ara-panorama-1.westus.cloudapp.azure.com
).
Step 2: Navigate to Device Groups > Objects.
Step 3: In the Device Group list, select Azure-Shared.
Step 4: In Device Groups > Objects > Addresses, click Add.
Step 5: In the Name box, enter Host-Shared-Public-Web.
Step 6: In the Type list, select FQDN.
Step 7: In the Type value box, enter aras-public-shared-web.westus.cloudapp.azure.com, and then click OK.
Step 8: Repeat Step 4 through Step 7 for all rows in Table 20.
8.3 Inbound Access—Congure NAT Policy
This procedure uses NAT Pre Rules. These rules are logically evaluated prior to local rules and cannot be locally overrid-
den on the local device.
Step 1: Log in to Panorama (example:
hps://ara-panorama-1.westus.cloudapp.azure.com
).
89Palo Alto Networks
Deployment Details for Azure Networking and Firewall Policies
Step 2: Navigate to Device Groups > Policies.
Step 3: In the Device Group list, select Azure-Shared.
Step 4: In Device Groups > Policies > NAT > Pre Rules, click Add.
Step 5: In the Name box, enter Inbound-Shared-Web.
Step 6: Change to the Original Packet tab.
Step 7: In the Source Zone pane, click Add and select Public.
Step 8: In the Desnaon Zone list, select Public.
Step 9: In the Desnaon Address pane, click Add and select Host-Shared-Public-Web.
Step 10: Change to the Translated Packet tab.
Step 11: In the Source Address Translaon secon, in the Translaon Type list, select Dynamic IP And Port.
Step 12: In the Source Address Translaon secon, in the Address Type list, select Interface Address.
Step 13: In the Source Address Translaon secon, in the Interface box, enter ethernet1/2.
Step 14: In the Desnaon Address Translaon secon, in the Translaon Type list, select Stac IP.
90Palo Alto Networks
Deployment Details for Azure Networking and Firewall Policies
Step 15: In the Desnaon Address Translaon secon, in the Translated Address list, select Host-Shared-Private-
Web-ILB.
Step 16: Change to the Ta rge t tab.
Step 17: Verify that Any (target to all devices) is selected.
Make sure to target all devices in the device group; otherwise, the policy rule will not be
automacally applied to new group members.
Caution
8.4 Inbound Access—Congure Security Policy
This procedure uses security Pre Rules. These rules are logically evaluated prior to local rules and cannot be locally
overridden on the local device.
The security policy example for the Inbound Access Prole permits these applicaons:
• web-browsing
• SSL (ssl)
Add addional applicaons to your policy as required.
Step 1: In Device Groups > Policies > Security > Pre Rules, click Add.
91Palo Alto Networks
Deployment Details for Azure Networking and Firewall Policies
Step 2: In the Name box, enter Inbound-Shared-Web.
Step 3: Change to the Source tab.
Step 4: In the Source Zone pane, click Add and select Public.
Step 5: Change to the Desnaon tab.
Step 6: In the Desnaon Zone pane, click Add and select Private.
Step 7: In the Desnaon Address pane, click Add and select Host-Shared-Public-Web.
Step 8: Change to the Applicaon tab.
Step 9: In the Applicaons pane, click Add and enter/search/select web-browsing.
Step 10: In the Applicaons pane, click Add and enter/search/select ssl.
Step 11: Change to the Service/URL Category tab.
Step 12: In the Service pane, select applicaon-default.
Step 13: Change to the Acons tab.
Step 14: In the Acon Seng secon, in the Acon list, select Allow.
Step 15: In the Log Seng secon, in the Log Forwarding list, select LoggingService-Prole.
Step 16: Change to the Ta rge t tab.
Step 17: Verify that Any (target to all devices) is selected, and then click OK.
92Palo Alto Networks
Deployment Details for Azure Networking and Firewall Policies
Make sure to target all devices (any) in the device group; otherwise, the policy rule will
not be automacally applied to new group members.
Caution
Step 18: On the Commit menu, click Commit and Push.
8.5 Outbound Access—Create Public IP Address and Associate with Firewall
For virtual machines behind the rewall to communicate to devices on the internet, the rewall must translate the
source IP address of the outbound trac to an IP address on the public subnet. The simplest method is to use dynamic
IP and port translaon to the rewall’s public interface IP address.
Azure then translates the source IP address again as the outbound trac leaves the VNet. Because the rewall’s public
interface is a member of the Azure public load-balancer backend pool, Azure networking performs translaon for only
TCP/UDP ports referenced in the acve load balancing rules. To support a broad range of services, create a new public
IP address for the public interface of each rewall used for outbound access. This method supports all TCP/UDP ports.
Step 1: In Home > Public IP addresses, click Add.
Step 2: In the Name box, enter aras-vmfw1-outbound.
Step 3: Select Standard SKU.
Step 4: In the DNS name label box, enter aras-vmfw1-outbound.
Step 5: In the Resource Group secon, choose Use Exisng, and then select AzureRefArch-Shared.
Step 6: Click Create.
Step 7: Aer the address has been successfully created, in Home > Public IP address > aras-vmfw1-outbound, click
Associate.
Step 8: In the Associate Public IP address pane, in the Resource type list, select Network interface.
Step 9: In the Choose Network Interface pane, select the public interface of aras-vmfw1 (example: aras-vmfw1-eth1),
and then click OK.
93Palo Alto Networks
Deployment Details for Azure Networking and Firewall Policies
Step 10: Repeat this procedure for any addional rewalls used for outbound access.
8.6 Outbound Access—Create Address Objects
Network objects are created to simplify the creaon of NAT and security policy rules.
Table 21 Outbound trac address objects
Object name Description Type Type value
Net-10.5.1.0 Web subnet IP Netmask 10.5.1.0/24
Net-10.5.2.0 Business subnet IP Netmask 10.5.2.0/24
Net-10.5.3.0 DB subnet IP Netmask 10.5.3.0/24
Step 1: Log in to Panorama (example:
hps://ara-panorama-1.westus.cloudapp.azure.com
).
Step 2: Navigate to Device Groups > Objects.
Step 3: In the Device Group list, select Azure-Shared.
Step 4: In Device Groups > Objects > Addresses, click Add.
Step 5: In the Name box, enter Net-10.5.1.0.
Step 6: In the Type list, select IP Netmask.
Step 7: In the Type value box, enter 10.5.1.0/24, and then click OK.
Step 8: Repeat Step 4 through Step 7 for all rows in Table 21.
8.7 Outbound Access—Congure NAT Policy
This procedure uses NAT Pre Rules. These rules are logically evaluated prior to local rules and cannot be locally overrid-
den on the local device.
Step 1: Log in to Panorama (example:
hps://ara-panorama-1.westus.cloudapp.azure.com
).
Step 2: Navigate to Device Groups > Policies.
94Palo Alto Networks
Deployment Details for Azure Networking and Firewall Policies
Step 3: In the Device Group list, select Azure-Shared.
Step 4: In Device Groups > Policies > NAT > Pre Rules, click Add.
Step 5: In the Name box, enter Outbound-Internet.
Step 6: Change to the Original Packet tab.
Step 7: In the Source Zone pane, click Add and select Private.
Step 8: In the Desnaon Zone list, select Public.
Step 9: In the Source Address pane, click Add and select Net-10.5.1.0. Repeat this step for all objects in Table 21.
Step 10: Change to the Translated Packet tab.
Step 11: In the Source Address Translaon secon, in the Translaon Type list, select Dynamic IP And Port.
Step 12: In the Source Address Translaon secon, in the Address Type list, select Interface Address.
95Palo Alto Networks
Deployment Details for Azure Networking and Firewall Policies
Step 13: In the Source Address Translaon secon, in the Interface box, enter ethernet1/1.
Step 14: Change to the Ta rge t tab.
Step 15: Verify that Any (target to all devices) is selected.
Make sure to target all devices in the device group. Otherwise, the policy rule will not
be automacally applied to new group members.
Caution
8.8 Outbound Access—Congure Security Policy
This procedure uses security Pre Rules. These rules are logically evaluated prior to local rules and cannot be locally
overridden on the local device. This example uses a common outbound policy for all private subnets. If you wish to use
a dierenated policy, create separate rules for each subnet.
The security policy example for the Outbound Access Prole permits these applicaons:
• web-browsing
• SSL (ssl)
• google-base
Add addional applicaons to your policy as required.
Step 1: In Device Groups > Policies > Security > Pre Rules, click Add.
Step 2: In the Name box, enter Outbound-Internet.
Step 3: Change to the Source tab.
96Palo Alto Networks
Deployment Details for Azure Networking and Firewall Policies
Step 4: In the Source Zone pane, click Add and select Private.
Step 5: In the Source Address pane, click Add and select Net-10.5.1.0. Repeat this step for all objects in Table 21
Step 6: Change to the Desnaon tab.
Step 7: In the Desnaon Zone pane, click Add and select Public.
Step 8: Change to the Applicaon tab.
Step 9: In the Applicaons pane, click Add and enter/search/select web-browsing.
Step 10: In the Applicaons pane, click Add and enter/search/select ssl.
Step 11: In the Applicaons pane, click Add and enter/search/select google-base.
Step 12: Change to the Service/URL Category tab.
Step 13: In the Service pane, select applicaon-default.
Step 14: Change to the Acons tab.
Step 15: In the Acon Seng secon, in the Acon list, select Allow.
Step 16: In the Log Seng secon, in the Log Forwarding list, select LoggingService-Prole.
Step 17: Change to the Ta rge t tab.
Step 18: Verify that Any (target to all devices) is selected, and then click OK.
Make sure to target all devices (any) in the device group; otherwise, the policy rule will
not be automacally applied to new group members.
Caution
Step 19: On the Commit menu, click Commit and Push.
97Palo Alto Networks
Deployment Details for Azure Networking and Firewall Policies
8.9 East/West Trac
Trac that originates from a virtual machine within a private subnet—and is desned to a virtual machine in dierent
private subnet—routes to the rewall through a user-dened route table applied to the virtual machine’s subnet. Virtual
machines that can communicate to each other without the need for a rewall to protect the trac can be on the same
subnet, and virtual machines that do need trac protecon should be on dierent subnets.
Because the trac ow for the East/West Trac Prole always stays within the Private zone, the rewall security
policy uses a Rule Type of intrazone.
Because both ends of the communicaon are within the VNet, the rewall should not apply a NAT policy to trac
between private subnets.
Azure networking does not require the use of source NAT on the rewall to enforce
symmetry if both direcons of the ow pass through the same Azure internal load-bal-
ancer. The private subnets have UDRs direcng East/West trac to the rewall layer,
so NAT is not required.
Note
This procedure reuses objects already created in Procedure 8.6. If necessary, create addional objects using the same
procedure.
This procedure uses security Pre Rules. These rules are logically evaluated prior to local rules and cannot be locally
overridden on the local device. The example policy assumes three subnets with a granular policy with each as a source
to the other two desnaons.
Table 22 East/West security policy rules (example)
Source Destination Rule
Net-10.5.1.0 (web) Net-10.5.2.0 (business) Web-to-Business
Net-10.5.1.0 (web) Net-10.5.3.0 (DB) Web-to-DB
Net-10.5.2.0 (business) Net-10.5.1.0 (web) Business-to-Web
Net-10.5.2.0 (business) Net-10.5.3.0 (DB) Business-to-DB
Net-10.5.3.0 (DB) Net-10.5.1.0 (web) DB-to-Web
Net-10.5.3.0 (DB) Net-10.5.2.0 (business) DB-Business
The example security policy for the East/West Access Prole permits these applicaons:
• SSH (ssh)
• RDP (ms-rdp)
98Palo Alto Networks
Deployment Details for Azure Networking and Firewall Policies
Add addional required applicaons to your policy as needed.
Step 1: In Device Groups > Policies > Security > Pre Rules, click Add.
Step 2: In the Name box, enter Web-to-Business.
Step 3: In the Rule Type list, select intrazone.
Step 4: Change to the Source tab.
Step 5: In the Source Zone pane, click Add and select Private.
Step 6: In the Source Address pane, click Add and select Net-10.5.1.0.
Step 7: Change to the Desnaon tab.
99Palo Alto Networks
Deployment Details for Azure Networking and Firewall Policies
Step 8: In the Desnaon Address pane, click Add and select Net-10.5.2.0.
Step 9: Change to the Applicaon tab.
Step 10: In the Applicaons pane, click Add and enter/search/select ssh.
Step 11: In the Applicaons pane, click Add and enter/search/select ms-rdp.
Step 12: Change to the Service/URL Category tab.
Step 13: In the Service pane, select applicaon-default.
Step 14: Change to the Acons tab.
Step 15: In the Acon Seng secon, in the Acon list, select Allow.
Step 16: In the Log Seng secon, in the Log Forwarding list, select LoggingService-Prole.
Step 17: Change to the Ta rge t tab.
100Palo Alto Networks
Deployment Details for Azure Networking and Firewall Policies
Step 18: Verify that Any (target to all devices) is selected, and then click OK.
Make sure to target all devices (any) in the device group; otherwise, the policy rule will
not be automacally applied to new group members.
Caution
Step 19: On the Commit menu, click Commit and Push.
101Palo Alto Networks
Deployment Details for Backhaul Connecon
Deployment Details for Backhaul Connecon
Use the following procedure groups to build an IPSec VPN connecon for backhaul between Azure and your on-site
network over the internet. The VPN endpoints used are the Azure Virtual Network Gateway (VNG) and an on-site Lo-
cal Network Gateway (LNG). The LNG used in this guide is a Palo Alto Networks next-generaon rewall.
Figure 11 Backhaul connecon to on-site network
192.168.1.6
192.168.1.7
Ma nagement – 192.168.1.0/24
10.5.0.6
(et h 2)
Virtual Network
10.5.0.7
(et h 2)
We b - 1 0. 5 . 1.0 / 24
Business - 1 0.5 . 2. 0 /24
DB - 1 0. 5 . 3. 0 / 24
10.5.15.6
(et h 3)
10.5.15.7
(et h 3)
VPN - 10.5.15.0/24
Private
1 0. 5 .0. 0 / 24
10.5.0.21
10.5.15.21
VNG
104.42.215.219
LNG
(firewall)
Gateway Sub ne t - 10.5.40.0/24
104.42.56.196
Internet
Local Network – 1 0. 6 .0. 0 / 16
The connecon from Azure to the on-site network was tested and validated only with a
specic design and includes two opons: stac roung and BGP roung. Other variants
to the backhaul design may work with similar conguraons but have not been explicitly
tested.
Note
A resilient design for the backhaul uses a pair of connecons from Azure to the on-site network and must use BGP
roung. An addional LNG is deployed on-site to terminate the second connecon from the Azure VNG. Roung will
be congured to prefer the rst connecon as acve and the second connecon as standby to ensure that trac is
routed symmetrically between the on-site network and Azure.
Every Azure VPN gateway consists of two instances in an acve-standby congura-
on. For any planned maintenance or unplanned disrupon that happens to the acve
instance, the standby instance would take over automacally and resume the VPN
connecons.
Note
102Palo Alto Networks
Deployment Details for Backhaul Connecon
Figure 12 Resilient backhaul connecon
Virtual Network
VNG
104.42.215.219
Gateway Sub ne t - 10.5.40.0/24
Internet
Local Network – 1 0. 6 .0. 0 / 16
LNG-2
(firewall)
104.42.56.197
LNG-1
(firewall)
104.42.56.196
Conguring Azure Networking for Backhaul Connecon
9.1 Congure the Azure Internal Load-Balancer for Backhaul
9.2 Congure Azure User Dened Routes
9.3 Apply Route Tables to Subnets
9.4 Modify Exisng Route Tables
9.5 Create the VPN Gateway Subnet.
9.6 Create Public IP for VPN Gateway
9.7 Deploy Virtual Network Gateway on Azure
9.8 Create Local Network Gateway
9.9 Create VPN Connecon from VNG to LNG
Procedures
103Palo Alto Networks
Deployment Details for Backhaul Connecon
This procedure group relies on the following assumpons:
• The on-site local network IP address block is 10.6.0.0/16.
• The exisng on-site rewall must have a stacally assigned public IP address.
• The Azure subnet reachable for Panorama and VM-Series management is 192.168.1.0/24.
• The Azure subnets reachable for in-band access (Web, DB, Business) included within the IP address range are
10.5.0.0/20.
Use the Azure Resource Manager to complete the following procedures. Sign in to Azure at
hps://portal.azure.com
.
9.1 Congure the Azure Internal Load-Balancer for Backhaul
Because the VPN gateway subnet uses Azure internal addressing, you use an addional frontend IP address and back-
end pool on the internal load-balancer.
Figure 13 Azure internal load-balancer for backhaul
Virtual Network
10.5.15.6
(et h 3)
10.5.15.7
(et h 3)
VPN - 10.5.15.0/24
10.5.15.21
VNG
104.42.215.219
LNG
(firewall)
Gateway Sub ne t - 10.5.40.0/24
104.42.56.196
Internet
Local Network – 1 0. 6 .0. 0 / 16
The frontend IP address is used as the roung next-hop for desnaon addresses on the private networks.
Step 1: In Home > Load Balancers > AzureRefArch-Shared-Internal, click Frontend IP conguraon.
Step 2: Click Add.
Step 3: In the Name box, enter Internal-Frontend-VPN.
Step 4: In the Subnet list, select Shared-VPN.
104Palo Alto Networks
Deployment Details for Backhaul Connecon
Step 5: In the Assignment secon, select Stac.
Step 6: In the IP address box, enter 10.5.15.21.
Step 7: In Home > Load Balancers > AzureRefArch-Shared-Internal, click Backend pools.
Step 8: Click Add.
Step 9: In the Name box, enter Firewall-Layer-VPN.
Step 10: In the Virtual network list, select azurerefarch-vnet (X VM), where X is the total number of VM-Series re-
walls and Panorama virtual machines already deployed in your VNet.
Step 11: In the VIRTUAL MACHINE column, select a VM-Series to be added to this backend pool (example: aras-
vmfw1).
Step 12: In the IP ADDRESS column, select the IP conguraon that is associated to the Shared-Public subnet. (ex-
ample: ipcong-dmz).
Step 13: Repeat Step 11 and Step 12 for all VM-Series rewalls that are to be assigned to this backend pool.
Step 14: Click Add.
Step 15: In Home > Load Balancers > AzureRefArch-Shared-Internal, click Load balancing rules.
Step 16: Click Add.
Step 17: In the Name box, enter VPN-All-Ports.
Step 18: In the Frontend IP address list, select Internal-Frontend-VPN.
Step 19: Select HA ports.
Step 20: In the Backend pool list, select Firewall-Layer-VPN.
Step 21: In the Health probe list, select HTTPS-Probe, and then click OK.
105Palo Alto Networks
Deployment Details for Backhaul Connecon
9. 2 Congure Azure User Dened Routes
This procedure relies on the following assumpons:
• The on-site local network IP address block is 10.6.0.0/16.
• The exisng on-site rewall BGP peer address (assigned to tunnel interface) is 10.6.2.255.
• The exisng on-site rewall must have a stacally assigned public IP address.
• The Azure subnet reachable for Panorama and VM-Series management is 192.168.1.0/24.
• The Azure subnets reachable for in-band access (Web, DB, Business) included within the IP address range are
10.5.0.0/20.
Table 23 Azure route tables
Subnet Route table name Resource group Table of UDRs
Shared-VPN AzureRefArch-Shared-VPN AzureRefArch-Shared Table 24
GatewaySubnet AzureRefArch-VPNGateway AzureRefArch Table 25
Table 24 VPN subnet UDRs (10.5.15.0/24)
Route name Address prefix Next-hop type
Next-hop
address Comments
Blackhole-Management 192.168.1.0/24 None —Block trac to Management IP
address space
Blackhole-Public 172.16.0.0/23 None —Block trac to Public IP address
space
Table 25 VPN gateway subnet UDRs (10.5.40.0/24)
Route name Address prefix Next-hop type
Next-hop
address Comments
Blackhole-Public 172.16.0.0/23 None —Block trac to Public IP address
space
Net-10.5.0.0 10.5.0.0/20 Virtual
Appliance
10.5.15.21 Frontend IP of load-balancer
106Palo Alto Networks
Deployment Details for Backhaul Connecon
Repeat this procedure for each entry in Table 23:
Step 1: In Home > Route tables, click Add.
Step 2: In the Name box, enter AzureRefArch-Shared-VPN.
Step 3: In the Resource Group secon, choose Use Exisng, select AzureRefArch-Shared, and then click Create.
Step 4: In Home > Route tables > AzureRefArch-Shared-VPN, click Routes.
Step 5: Repeat these substeps for all entries in the table of UDRs:
• In Home > Routes tables > AzureRefArch-VPN—Routes, click Add.
• In the Route name box, enter Blackhole-Public.
• In the Address prex box, enter 172.16.0.0/23.
• In the Next hop type list, select None.
• If the Next-hop type is Virtual appliance, then enter the Next-hop address value and click OK.
9.3 Apply Route Tables to Subnets
The UDRs only take eect aer the route table is associated with the subnet.
Step 1: In Home > Virtual networks > AzureRefArch-VNET, click Subnets.
Step 2: Click Shared-VPN.
Step 3: Click the Route table secon, and in the Resource pane, select AzureRefArch-Shared-VPN.
Step 4: Click Save, and then click X to Close.
9.4 Modify Exisng Route Tables
Azure networking routes trac from all subnets to the on-site network range directly to the VNG by default. This
design allows implicit access for the Management subnet to support in-band management of Panorama and the VM-
Series.
To block the trac or enforce a rewall policy requires that you create UDRs. Congure the UDRs to explicitly blocked
trac to the on-site network from the public subnet. Congure the UDRs to redirect trac from all other subnets to
the rewall layer for policy enforcement.
107Palo Alto Networks
Deployment Details for Backhaul Connecon
The route tables in Table 26 were originally created in Procedure 7.7. Modify the route tables listed in Table 26 by
adding the addional specied routes. If you have addional on-site prexes, then each prex requires a UDR in each
roung table.
When adding addional on-site networks, you must manually update the route tables
to block and redirect to the new prexes as they are added. This step is required even
when running dynamic BGP roung.
Caution
Table 26 Route table modicaons for backhaul
Route table name Route name
Address
prefix
Next-hop
type
Next-hop
address Comments
AzureRefArch-Shared-Public Blackhole-
OnSite
10.6.0.0/16 None —Block trac to On-site IP
address space
AzureRefArch-Shared-Private Net-10.6.0.0 10.6.0.0/16 Virtual
appliance
10.5.0.21 Frontend IP of load-
balancer
Access to on-site network
through the rewall layer
AzureRefArch-Shared-Web Net-10.6.0.0 10.6.0.0/16 Virtual
appliance
10.5.0.21 Frontend IP of load-
balancer
Access to on-site network
through the rewall layer
AzureRefArch-Shared-Busi-
ness
Net-10.6.0.0 10.6.0.0/16 Virtual
appliance
10.5.0.21 Frontend IP of load-
balancer
Access to on-site network
through the rewall layer
AzureRefArch-Shared-DB Net-10.6.0.0 10.6.0.0/16 Virtual
appliance
10.5.0.21 Frontend IP of load-
balancer
Access to on-site network
through the rewall layer
9. 5 Create the VPN Gateway Subnet.
This procedure adds a new subnet for the VPN Gateway to the exisng VNet.
Step 1: In Home > Virtual networks > AzureRefArch-VNET, click Subnets.
Step 2: Click Gateway subnet to add a new gateway subnet.
108Palo Alto Networks
Deployment Details for Backhaul Connecon
Step 3: In the Address Range (CIDR block) box, enter 10.5.40.0/24.
Step 4: Click the Route table secon, select AzureRefArch-VPNGateway, and then click OK.
9.6 Create Public IP for VPN Gateway
Step 1: In Home > Public IP addresses, click Add.
Step 2: In the Name box, enter AzureRefArch-VNG-Public.
Step 3: Select Basic SKU.
Do not choose a Standard IP SKU for the public IP address of your Virtual Network
Gateway. The Standard IP SKU uses only stac IP address assignment. Azure Resource
Manager does not permit this selecon and presents the following error: “Stac public
IP address can only be assigned to load-balancers.”
Note
Step 4: In the IP address assignment secon, select Dynamic.
In the DNS name label box, do not enter a value. Azure does not support dynamic reso-
luon of the FQDN for a VPN gateway.
Note
Step 5: In the Resource Group secon, choose Use Exisng, and then select AzureRefArch.
Step 6: Click Create.
The on-premise rewall requires a peer IP address for the Azure VNG. The actual IP address is not assigned by Azure
unl the VNG is created and the public IP address is associated.
9.7 Deploy Virtual Network Gateway on Azure
This procedure includes two roung opons, stac roung and dynamic roung with BGP. The stac roung opon
is simpler to congure but requires manual modicaon for any roung changes. The BGP opon is more complex to
inially congure but is easier to operate and maintain in a rapidly changing environment.
Refer to Figure 14 for this and the following procedures.
109Palo Alto Networks
Deployment Details for Backhaul Connecon
Figure 14 Backhaul roung opons—stac and BGP
Option 2: BGP Routing
Option 1: Static Routing
Red istribute routes
into BGP
VNG
LNG
Internet
P ub l i c I P:
104.42.215.219
BGP AS : 65 5 15
(10.5.40.254) BG P AS : 65 5 01
(10.6.1.255)
P ub l i c I P:
104.42.56.196
VN ET Ad dres s S pac e:
192.168.1.0/24
1 72 . 16 .1 . 0/ 23
10.5.0.0/16
LNG A ddre ss Space:
1 0. 6 .1. 2 5 5/ 32
VNG
LNG
Internet
P ub l i c I P:
104.42.215.219
P ub l i c I P:
104.42.56.196
VN ET Ad dres s S pac e:
192.168.1.0/24
1 72 . 16 .1 . 0/ 23
10.5.0.0/16
LNG A ddre ss Space:
10.6.0.0/16
Step 1: In Home > Virtual networks gateways, click Add.
Step 2: In the Name box, enter AzureRefArch-VNG.
Step 3: In the Gateway type secon, select VPN.
Step 4: In the VPN type secon, select Route-based.
Step 5: In the SKU list, select VpnGw1. The basic SKU does not support BGP or IKEv2.
Step 6: Click the Virtual Network secon, and then select AzureRefArch-VNET.
Step 7: Click the Public IP address secon, select Use exisng, and then select AzureRefArch-VNG-Public.
Step 8: If you’re conguring dynamic roung with BGP, select Congure BGP ASN, and then in the Autonomous sys-
tem number (ASN) box, accept the proposed default value of 65515.
110Palo Alto Networks
Deployment Details for Backhaul Connecon
Step 9: Click Create.
Step 10: In Home > Public IP addresses > AzureRefArch-VNG-Public, record the IP address (Example:
104.42.215.219).
Step 11: If you congured BGP, then in Home > Virtual network gateways > AzureRefArch-VNG, click Conguraon.
111Palo Alto Networks
Deployment Details for Backhaul Connecon
Step 12: Record the BGP peer IP address assigned to the virtual network gateway (Example: 10.5.40.254).
9.8 Create Local Network Gateway
The local network gateway corresponds to the on-premise rewall that terminates the IPSec VPN tunnel from Azure.
Step 1: In Home > Local network gateways, click Add.
Step 2: In the Name box, enter AzureRefArch-LNG-OnPrem.
Step 3: In the IP address box, enter the public IP address of the on-premise IPSec VPN peer (Example: 104.42.56.196).
Opon 1: Stac Roung
Step 1: In the Address space box, enter the IP prex that is reachable through the VPN tunnel. (Example: 10.6.0.0/16).
If mulple IP prexes are reachable, you must add the addional prexes by repeang this step mulple mes.
Step 2: In the Resource Group secon, choose Use Exisng, and then select AzureRefArch.
112Palo Alto Networks
Deployment Details for Backhaul Connecon
Step 3: Click Create.
Opon 2: Dynamic Roung with BGP
Step 1: In the Address space box, enter only the IP prex for the BGP peer address from the on-premise rewall this
LNG corresponds to. (Example: 10.6.1.255/32)
Step 2: Select Congure BGP sengs.
Step 3: In the Autonomous system number (ASN) box, enter 65501.
Step 4: In the BGP peer IP address box, enter 10.6.1.255.
Step 5: In the Resource Group secon, choose Use Exisng, and then select AzureRefArch.
Step 6: Click Create.
113Palo Alto Networks
Deployment Details for Backhaul Connecon
9.9 Create VPN Connecon from VNG to LNG
Step 1: In Home > Connecons, click Add.
Step 2: In Home > Connecons > Create connecon > Basics, in the Connecon type list, select Site-to-site (IPsec).
Step 3: In the Resource Group secon, choose Use Exisng, select AzureRefArch, and then click OK.
Step 4: In Home > Connecons > Create connecon > Sengs, click the Virtual network gateway secon, and then
select AzureRefArch-VNG.
Step 5: Click the Local network gateway secon, and then select AzureRefArch-LNG-OnPrem.
Step 6: In the Connecon name box, enter AzureRefarch-to-OnPrem.
Step 7: In the Shared key (PSK) box, enter the value for the pre-shared key (complex password).
Step 8: If you congured BGP, select Enable BGP.
Step 9: Click OK.
Step 10: Review the Summary and if acceptable, click OK.
Conguring On-site Firewall for VPN Access to Azure
10.1 Congure Objects and Interfaces
10.2 Congure IKEv2 and IPSec
10.3 Congure Roung
10.4 Congure BGP
Procedures
These procedures assume the on-site rewall is congured and running with a public interface reachable from the
internet and a private interface with access to internal subnets. The rewall is already congured with a default virtual
router. DNS and NTP are congured.
The following procedures are completed on the on-site next-generaon rewall or VM-Series device. If you are using a
second resilient on-site rewall, this procedure group is repeated.
114Palo Alto Networks
Deployment Details for Backhaul Connecon
10.1 Congure Objects and Interfaces
Step 1: In Objects > Addresses, click Add.
Step 2: In the Name box, enter AzureRefArch-VNG-Public.
Step 3: In the Type list, select IP Netmask.
Step 4: In the Type value box, enter the public IP address that was assigned by Azure (Example: 104.42.215.219), and
then click OK.
Step 5: In Network > Zones, click Add. The Zone conguraon window appears.
Step 6: In the Name box, enter VPN.
Step 7: In the Type list, select Layer3, and then click OK.
Step 8: In Network > Interfaces, change to the Tunnel tab, and then click Add. The Tunnel Interface conguraon
window appears.
Step 9: In the Interface Name.subinterface box, enter 10.
Step 10: In the Virtual Router list, select default.
115Palo Alto Networks
Deployment Details for Backhaul Connecon
Step 11: In the Security Zone list, select VPN.
If you are conguring the second device for resilient backhaul, use the value of
10.6.1.254/32 in Step 12.
Note
Step 12: If you congured BGP, change to the IPv4 tab. In the IP pane, click Add, enter 10.6.1.255/32, and then click
OK.
Step 13: Change to the Advanced tab.
Step 14: In the MTU box, enter 1424, and then click OK.
This value is used to minimize IP packet fragmentaon due to the tunnel and IPSec encapsulaon overhead.
Step 15: In Network Interfaces, click the public-facing Ethernet interface (example: ethernet1/1).
Step 16: Change to the Advanced tab.
Step 17: In the Other Info secon, select Adjust TCP MSS, and then click OK.
This feature is enabled to minimize IP packet fragmentaon due to the tunnel and IPSec encapsulaon overhead.
116Palo Alto Networks
Deployment Details for Backhaul Connecon
10.2 Congure IKEv2 and IPSec
Use the values specied in Table 27 for the steps in this procedure. The rewall can successfully negoate these values
with the Azure VNG without requiring any modicaon of the Azure default sengs. The strongest authencaon and
encrypon values that are compable with Azure are listed.
Table 27 IKEv2 and IPSec parameters
Parameter Value Description
IKEv2 DH group group2 Die-Helman Group 2
IKEv2 authencaon sha256 Secure Hash Algorithm 2 (SHA-2) with 256-bit digest
IKEv2 encrypon aes-256-cbc Advanced Encrypon Standard (AES) Cipher Block Chain-
ing (CBC) with 256-bit key
IKEv2 key lifeme mer 28800 Seconds —
IKEv2 mer authencaon mulple 3 —
IPSec encrypon aes-256-gcm AES Galois Counter Mode (GCM) with 256-bit key
IPSec authencaon sha512 Secure Hash Algorithm 2 (SHA-2) with 512-bit digest
IPSec DH group no-pfs Perfect Forward Secrecy disabled
IPSec lifeme 3600 Seconds —
Step 1: In Network > Network Proles > IKE Crypto, click Add. The IKE Crypto Prole conguraon window appears.
Step 2: In the Name box, enter Azure-IKEv2.
Step 3: In the DH Group pane, click Add and select group2.
Step 4: In the Authencaon pane, click Add and select sha256.
Step 5: In the Encrypon pane, click Add and select aes-256-cbc.
Step 6: In the Timers secon, in the Key Lifeme list, select Seconds and enter 28800.
117Palo Alto Networks
Deployment Details for Backhaul Connecon
Step 7: In the Timers secon, in the IKEv2 Authencaon Mulple box, enter 3, and then click OK.
Step 8: In Network > Network Proles > IPSec Crypto, click Add. The IPSec Crypto Prole conguraon window ap-
pears.
Step 9: In the Name box, enter Azure-IPSec.
Step 10: In the Encrypon pane, click Add and select aes-256-gcm.
Step 11: In the Authencaon pane, click Add and select sha512.
Step 12: In the DH Group list, select no-pfs.
Step 13: In the Lifeme list, select Seconds and enter 3600, and then click OK.
118Palo Alto Networks
Deployment Details for Backhaul Connecon
Step 14: In Network > Network Proles > IKE Gateways, click Add. The IKE Gateway conguraon window appears.
Step 15: In the Name box, enter OnPrem-to-AzureRefArch-IKEv2.
Step 16: In the Version list, select IKEv2 only mode.
Step 17: In the Interface list, select the public interface of the rewall (example: ethernet1/1).
Step 18: In the Peer IP Address Type secon, select IP.
Step 19: In the Peer Address list, select AzureRefArch-VNG-Public.
Step 20: In the Pre-shared Key box, enter the Shared key (PSK) that matches the VPN connecon congured on
Azure.
Step 21: In the Conrm Pre-shared Key box, re-enter the key.
Step 22: Change to the Advanced Opons tab.
Step 23: Select Enable NAT Traversal.
119Palo Alto Networks
Deployment Details for Backhaul Connecon
Step 24: In the IKE Crypto Prole list, select Azure-IKEv2, and then click OK.
Step 25: In Network > IPSec Tunnels, click Add.
Step 26: In the Name box, enter OnPrem-to-AzureRefArch.
Step 27: In the Tunnel Interface list, select tunnel.10.
Step 28: In the IKE Gateway list, select OnPrem-to-AzureRefArch-IKEv2.
Step 29: In the IPSec Crypto Prole list, select Azure-IPSec.
Step 30: Select Show Advanced Opons.
120Palo Alto Networks
Deployment Details for Backhaul Connecon
Step 31: Select Copy TOS Header, and then click OK.
10.3 Congure Roung
The stac roung opon requires the creaon of explicit stac routes for all Azure desnaon prexes. The dynamic
roung opon requires the creaon of a single stac route that corresponds to the Azure roung peer prex. All other
desnaons are dynamically learned using the roung protocol.
Table 28 Stac routes for on premise rewall
Name
Destination
prefix Interface Next-hop Next-hop value
Azure-192.168.1.0 192.168.1.0/24 tunnel.10 None —
Azure-10.5.0.0 10.5.0.0/16 tunnel.10 None —
Step 1: In Network > Virtual Routers, click default. The Virtual Router—default window appears.
Step 2: Change to the Stac Routes tab.
Opon 1: Stac Roung
Step 1: Click Add. The Virtual Router—Stac Route—IPv4 window appears.
Step 2: In the Name box, enter Azure-10.5.0.0.
Step 3: In the Desnaon box, enter 10.5.0.0/16.
121Palo Alto Networks
Deployment Details for Backhaul Connecon
Step 4: In the Interface list, select tunnel.10.
Step 5: In the Next Hop list, select None, and then click OK.
Step 6: Repeat Step 1 through Step 5 for all stac routes in Table 28.
Step 7: Aer adding all routes for this virtual router, click OK to close the Virtual Router window.
Step 8: Click Commit.
Opon 2: Dynamic Roung with BGP
The BGP opon requires a stac host route to reach the Azure BGP peer.
Step 1: Click Add. The Virtual Router —Stac Route—IPv4 window appears.
Step 2: In the Name box, enter Azure-BGP-Router-ID.
Step 3: In the Desnaon box, enter 10.5.40.254/32.
122Palo Alto Networks
Deployment Details for Backhaul Connecon
Step 4: In the Interface list, select tunnel.10.
Step 5: In the Next Hop list, select None, and then click OK.
Step 6: Click OK to close the Virtual Router window.
Step 7: Click Commit.
10.4 Congure BGP
(Oponal)
If you are using stac roung, skip this procedure.
This procedure requires that you have a BGP autonomous system number; the example uses 65501 for the on-site
rewall. The BGP peering conguraon uses the tunnel interface IP address of the rewall as the BGP Router ID.
Step 1: In Network > Virtual Routers, click default. The Virtual Router—default window appears.
Step 2: Change to the Redistribuon Prole tab, and click Add. The Redistribuon Prole IPv4 window appears.
This example redistributes the directly connected route for the subnet assigned to the
Private zone interface (ethernet1/2). If you are running a dynamic roung protocol in
your on-site network and rewall, then redistribute the routes from the roung protocol
instead of the connected route.
The use of a dynamic roung protocol is required to ensure symmetric roung when
using a resilient backhaul connecon.
Note
Step 3: In the Name box, enter Connected.
Step 4: In the Redistribute secon, select Redist.
Step 5: In the Priority box, enter 1.
Step 6: In the Source Type pane, select connect.
123Palo Alto Networks
Deployment Details for Backhaul Connecon
Step 7: In the Interface pane, click Add, select ethernet1/2, and click OK.
Step 8: Change to the BGP tab.
Step 9: Select Enable.
If you are conguring the second device for resilient backhaul, use the value of
10.6.1.254 in Step 10.
Note
Step 10: In the Router ID box, enter 10.6.1.255.
Step 11: In the AS Number box, enter 65501.
124Palo Alto Networks
Deployment Details for Backhaul Connecon
Step 12: In the Opons pane, select Install Route.
Step 13: Change to the Peer Group tab, and then click Add. The Virtual Router—BGP—Peer Group/Peer window ap-
pears.
Step 14: In the Name box, enter Azure.
Step 15: In the Peer pane, click Add. The Virtual Router—BGP—Peer Group—Peer window appears.
Step 16: In the Name box, enter AzureRefArch.
Step 17: In the Peer AS box, enter the autonomous system number assigned to the Azure virtual network gateway.
The default is 65515.
Step 18: In the Local Address pane, in the Interface list, select tunnel.10.
If you are conguring the second device for resilient backhaul, use the value of
10.6.1.254/32 in Step 19.
Note
Step 19: In the Local Address pane, in the IP list, select 10.6.1.255/32.
Step 20: In the Peer Address pane, in the IP box, enter the BGP peer IP address assigned by Azure to the virtual net-
work gateway (example: 10.5.40.254).
Step 21: Change to the Connecon Opons tab.
125Palo Alto Networks
Deployment Details for Backhaul Connecon
Step 22: In the Mul Hop box, enter 2, and then click OK.
Step 23: Click OK to close the Virtual Router—BGP—Peer Group/Peer window.
126Palo Alto Networks
Deployment Details for Backhaul Connecon
Step 24: Change to the Redist Rules tab, and then click Add. The Virtual Router—BGP—Redistribute Rules—Rule win-
dow appears.
Step 25: In the Name list, select Connected, and then click OK.
Step 26: Click OK to close the Virtual Router—default window.
Step 27: Click Commit.
Conguring Resilient Backhaul Connecon
11.1 Create the Second Local Network Gateway
11.2 Create VPN Connecon from VNG to LNG-2
11.3 Congure addional on-site rewall
Procedures
This procedure group includes the necessary steps to add a second backhaul connecon and congure BGP roung for
Azure to prefer the rst connecon if both LNGs are connected. The rst connecon must already be congured with
the BGP roung opon.
This procedure relies on the following assumpons:
• The exisng on-site rewall BGP peer address (assigned to tunnel interface) is 10.6.2.254.
• The second exisng on-site rewall must have a stacally assigned public IP address.
• The on-site network is congured to use dynamic roung between the on-site rewalls and the internal private
network. The downstream router learns the Azure routes from both on-site rewalls and is congured to use
roung metrics to select the preferred path through the rst connecon.
• BGP AS-Prepend is used to make the second connecon less preferred.
127Palo Alto Networks
Deployment Details for Backhaul Connecon
Figure 15 Resilient roung for backhaul connecon
LNG-1
BGP AS : 65 5 01
(10.6.1.255)
VN ET Ad dres s S pace:
192.168.1.0/24
1 72 . 16 .1 . 0/ 23
10.5.0.0/16
LNG-1 Ad dres s S pace:
1 0. 6 .1. 2 5 5/ 32
LNG-2
VNG
BGP AS : 65 5 15
(10.5.40.254)
BGP AS : 65 5 01
(10.6.1.254)
LNG-2 Ad dres s S pace:
1 0. 6 .1. 2 5 4/ 32
Dyn a mic
Ro uting
10.6.0.4
10.6.0.5
10.6.0.6
On-site Tran sit - 1 0. 6 .0. 0 / 24
11.1 Create the Second Local Network Gateway
The local network gateway corresponds to the second on-premise rewall that terminates the resilient IPSec VPN tun-
nel from Azure.
Step 1: In Home > Local network gateways, click Add.
Step 2: In the Name box, enter AzureRefArch-LNG-OnPrem-2.
Step 3: In the IP address box, enter the public IP address of the on-premise IPSec VPN peer (Example: 104.42.56.197).
Step 4: In the Address space box, enter only the IP prex for the BGP peer address from the on-premise rewall this
LNG corresponds to. (Example: 10.6.1.254/32)
Step 5: Select Congure BGP sengs.
Step 6: In the Autonomous system number (ASN) box, enter 65501.
Step 7: In the BGP peer IP address box, enter 10.6.1.254.
Step 8: In the Resource Group secon, choose Use Exisng, and then select AzureRefArch.
Step 9: Click Create.
128Palo Alto Networks
Deployment Details for Backhaul Connecon
11.2 Create VPN Connecon from VNG to LNG-2
Step 1: In Home > Connecons, click Add.
Step 2: In Home > Connecons > Create connecon > Basics, in the Connecon type list, select Site-to-site (IPsec).
Step 3: In the Resource Group secon, choose Use Exisng, select AzureRefArch, and then click OK.
Step 4: In Home > Connecons > Create connecon > Sengs, click the Virtual network gateway secon, and then
select AzureRefArch-VNG.
Step 5: Click the Local network gateway secon, and then select AzureRefArch-LNG-OnPrem-2.
Step 6: In the Connecon name box, enter AzureRefarch-to-OnPrem.
Step 7: In the Shared key (PSK) box, enter the value for the pre-shared key (complex password).
Step 8: If you congured BGP, select Enable BGP.
Step 9: Click OK.
Step 10: Review the Summary and if acceptable, click OK.
11.3 Congure addional on-site rewall
This procedure congures a second on-site rewall to be used for the resilient backhaul connecon. Aer this rewall
is congured by repeang earlier procedures, then BGP is congured to make the second connecon less preferred.
The BGP conguraon prepends a second AS number to the routes adversed from the second rewall. Azure re-
ceive all prexes from both LNGs and uses the AS-path length to make its roung decision. This roung conguraon
ensures that Azure chooses the rst connecon when both are available when sending trac from Azure to the on-site
networks. This does not inuence the path secon in the opposite direcon.
If you do not congure on-site roung to prefer the rst connecon then asymmetric
roung will occur. Network trac is dropped because the rewalls don’t see both direc-
ons of the ow.
Caution
129Palo Alto Networks
Deployment Details for Backhaul Connecon
Step 1: Repeat Procedure 10.1 through Procedure 10.4 to congure the second rewall using new values as specied
in the notes.
Step 2: In Network > Virtual Routers, click default. The Virtual Router—default window appears.
Step 3: Change to the BGP tab.
Step 4: Change to the Export tab.
Step 5: Click Add, The Virtual Router—BGP—Export Rule window appears.
Step 6: In the Rules box, enter AS-Prepend.
Step 7: In the Used By pane, click Add, and select Azure.
Step 8: Change to the Match tab.
130Palo Alto Networks
Deployment Details for Backhaul Connecon
Step 9: In the AS Path Regular Expression box, enter ^$. This regular expression matches all prexes that are local to
this autonomous system.
Step 10: Change to the Acon tab.
Step 11: In the AS Path secon, in the Type list, select Prepend. In the Type value box, enter 2.
Step 12: Click OK to close the Virtual Router—BGP—Export Rule window.
131Palo Alto Networks
Deployment Details for Backhaul Connecon
Step 13: Click OK to close the Virtual Router—default window.
Step 14: Click Commit.
Using Panorama to Congure Security and NAT for Backhaul Connecon
12.1 Backhaul Connecon—Create Address Objects
12.2 Backhaul Connecon—Congure NAT Policy
12.3 Backhaul Connecon—Congure Security Policy
Procedures
The security policy for the backhaul connecon is enforced at mulple locaons. The on-site rewall that terminates
the VPN tunnel to Azure can use security policy rules between the private zone and the VPN zone. The VM-Series
rewalls on Azure can use security policy rules between the VPN zone and the private zone.
Only the VM-Series policy is included in this guide.
12.1 Backhaul Connecon—Create Address Objects
This procedure reuses objects already created in Procedure 8.6. If necessary, create addional objects using the same
procedure. The table of objects (Table 21) is repeated here.
Table 29 Outbound trac address objects
Object name Description Type Type value
Net-10.5.1.0 Web subnet IP Netmask 10.5.1.0/24
Net-10.5.2.0 Business subnet IP Netmask 10.5.2.0/24
Net-10.5.3.0 DB subnet IP Netmask 10.5.3.0/24
Step 1: Log in to Panorama (example:
hps://ara-panorama-1.westus.cloudapp.azure.com
).
Step 2: Navigate to Device Groups > Objects.
Step 3: In the Device Group list, select Azure-Shared.
Step 4: In Device Groups > Objects > Addresses, click Add.
132Palo Alto Networks
Deployment Details for Backhaul Connecon
Step 5: In the Name box, enter Net-10.6.0.0.
Step 6: In the Type list, select IP Netmask.
Step 7: In the Type value box, enter 10.6.0.0/16, and then click OK.
12.2 Backhaul Connecon—Congure NAT Policy
This procedure uses NAT Pre Rules. These rules are logically evaluated prior to local rules and cannot be locally overrid-
den on the local device.
Step 1: Log in to Panorama (example:
hps://ara-panorama-1.westus.cloudapp.azure.com
).
Step 2: Navigate to Device Groups > Policies.
Step 3: In the Device Group list, select Azure-Shared.
Step 4: In Device Groups > Policies > NAT > Pre Rules, click Add.
Step 5: In the Name box, enter VPN-to-Private.
Step 6: Change to the Original Packet tab.
Step 7: In the Source Zone pane, click Add and select VPN.
Step 8: In the Desnaon Zone list, select Private.
Step 9: In the Source Address pane, click Add and select Net-10.6.0.0.
133Palo Alto Networks
Deployment Details for Backhaul Connecon
Step 10: In the Desnaon Address pane, click Add and select Net-10.5.1.0. Repeat this step for all objects in Table
29.
Step 11: Change to the Translated Packet tab.
Step 12: In the Source Address Translaon secon, in the Translaon Type list, select Dynamic IP And Port.
Step 13: In the Source Address Translaon secon, in the Address Type list, select Interface Address.
Step 14: In the Source Address Translaon secon, in the Interface box, enter ethernet1/2.
Step 15: Change to the Ta rge t tab.
134Palo Alto Networks
Deployment Details for Backhaul Connecon
Step 16: Verify that Any (target to all devices) is selected.
Make sure to target all devices in the device group; otherwise, the policy rule will not be
automacally applied to new group members.
Caution
12.3 Backhaul Connecon—Congure Security Policy
This procedure uses Security Pre Rules. These rules are logically evaluated prior to local rules and cannot be locally
overridden on the local device.
The security policy example for the Backhaul Connecon Prole permits these applicaons:
• SSH (ssh)
• RDP (ms-rdp)
• web-browsing
Add addional required applicaons to your policy as needed.
Step 1: In Device Groups > Policies > Security > Pre Rules, click Add.
Step 2: In the Name box, enter VPN-to-Private.
Step 3: Change to the Source tab.
Step 4: In the Source Zone pane, click Add and select VPN.
Step 5: In the Source Address pane, click Add and select 10.6.0.0.
Step 6: Change to the Desnaon tab.
Step 7: In the Desnaon Zone pane, click Add and select Private.
Step 8: In the Desnaon Address pane, click Add and select 10.5.1.0. Repeat this step for all objects in Table 29.
Step 9: Change to the Applicaon tab.
135Palo Alto Networks
Deployment Details for Backhaul Connecon
Step 10: In the Applicaons pane, click Add and enter/search/select ssh
Step 11: In the Applicaons pane, click Add and enter/search/select ms-rdp.
Step 12: In the Applicaons pane, click Add and enter/search/select web-browsing.
Step 13: Change to the Service/URL Category tab.
Step 14: In the Service pane, select applicaon-default.
Step 15: Change to the Acons tab.
Step 16: In the Acon Seng secon, in the Acon list, select Allow.
Step 17: In the Log Seng secon, in the Log Forwarding list, select LoggingService-Prole.
Step 18: Change to the Ta rge t tab.
Step 19: Verify that Any (target to all devices) is selected, and then click OK.
Make sure to target all devices (any) in the device group; otherwise, the policy rule will
not be automacally applied to new group members.
Caution
Step 20: On the Commit menu, click Commit and Push.
136Palo Alto Networks
Deployment Details for Automated Bootstrapping
Deployment Details for Automated Bootstrapping
Preparing For Bootstrapping
13.1 Create the Bootstrap Package
13.2 Deploy the Bootstrap Package to Azure Storage
13.3 Create the Public IP Address for VM-Series
Procedures
This procedure group provides an alternate deployment method to Procedure 4.1. In addion to deploying the VM-
Series using the ARM template, the automated bootstrap process licenses the VM-Series and registers the VM-Series
device with Panorama with the designated templates and device group. This opon would not typically be chosen to
deploy the inial devices, but it is an eecve opon for scaling performance by adding addional rewalls aer the
rst pair have been deployed.
Aer deployment using the bootstrap, a new VM-Series is added to the Azure public and internal load-balancers back-
end pools to complete the integraon and make the VM-Series acve.
13.1 Create the Bootstrap Package
Step 1: Generate VM Auth Key on Panorama.
The next step requires the use of the command line. (You can also do it via API, but that opon is not covered by this
guide.)
Step 2: Using SSH, log in to the Panorama command line.
Step 3: Request the VM auth key by using the following command. The lifeme of the key can vary between 1 hour
and 8760 hours (1 year). Aer the specied me, the key expires. Panorama does not register VM-Series rewalls with-
out a valid auth-key in the connecon request.
request bootstrap vm-auth-key generate lifetime 8760
VM auth key 123456789012345 generated. Expires at: 2019/06/07 14:15:56
Step 4: Create init-cfg.txt le.
137Palo Alto Networks
Deployment Details for Automated Bootstrapping
The following table includes the parameters required for successful bootstrap on Azure. The VM-Series registers with
Panorama and is assigned to the listed template stack and device group. Create the le by using a text editor and save
as init-cfg.txt
Table 30 Required parameters for Azure bootstrap
Description Parameter Value
Type of management IP address type dhcp-client
Virtual machine authencaon key vm-auth-key (generated on Panorama)
Panorama IP address panorama-server 192.168.1.4
Panorama IP address (secondary) panorama-server-2
(oponal for H/A only)
192.168.1.5
(oponal for H/A only)
Template stack name tplname Azure-Shared-Model
Device group name dgname Azure-Shared
Step 5: If you are using BYOL, create the authcodes le. An auth code bundle includes all of the VM-Series feature
licenses with a single auth code.
Example: I1234567
The lename for the authcodes le must not include any extension such as .txt. If you
save the le with an extension, the bootstrap process fails.
Caution
138Palo Alto Networks
Deployment Details for Automated Bootstrapping
Create the le using a text editor and save as authcodes.
13.2 Deploy the Bootstrap Package to Azure Storage
This procedure creates a new le share for the bootstrap package in an exisng storage account.
Step 1: In Home > Storage accounts > azurerefarchv2 > FILE SERVICE > Files, click File share.
Step 2: In the Name box, enter vmseries-bootstrap, and click OK.
Step 3: In Home > Storage accounts > azurerefarchv2 > FILE SERVICE > Files, click vmseries-bootstrap.
Table 31 Bootstrap package structure
Directory name File
cong init-cfg.txt
content —
license authcodes
soware —
139Palo Alto Networks
Deployment Details for Automated Bootstrapping
Step 4: Click Add directory.
Step 5: In the Name box, enter cong, and then click OK.
Step 6: If a File is listed for a corresponding directory in Table 31, then complete these substeps for the le:
• Click cong.
• Click Upload.
• In the Upload les pane, browse to your local lesystem and select init-cfg.txt.
• Click Upload.
Step 7: Repeat Step 4 through Step 6 for each entry in Table 31.
Step 8: In Home > Storage accounts > azurerefarchv2 > FILE SETTINGS > Access keys, record the access key for the
storage account (either key1 or key2) by using Click to copy.
You will need to provide the Storage Account, valid Storage Account access key, and File
Share at deployment me.
Example:
Storage Account Name: azurerefarchv2
Access Key: <key>
File Share Name: vmseries-bootstrap
Note
140Palo Alto Networks
Deployment Details for Automated Bootstrapping
13.3 Create the Public IP Address for VM-Series
This procedure is idencal to Procedure 3.6. It is repeated here for completeness.
The VM-Series devices deployed on Azure are managed using public IP addresses unless on-site network connecvity
has been established. The process to congure on-site network connecvity is included later in this guide.
This procedure creates a public IP address that is associated to the management interface of the VM-Series at deploy-
ment me. If necessary, this procedure is repeated to create addional public IP addresses for addional VM-Series
devices. The parameters listed in Table 4 are used to complete this procedure.
Take note of the fully qualied domain name (FQDN) that is dened by adding the locaon specic sux to your DNS
name label. We recommend managing your devices using the DNS name rather than the public IP address, which may
change.
Step 1: In Home > Public IP addresses, click Add.
Step 2: In the Name box, enter aras-vmfw3.
Step 3: Select Standard SKU.
Step 4: In the DNS name label box, enter aras-vmfw3.
Step 5: In the Resource Group secon, choose Use Exisng, and then select AzureRefArch-Shared.
Step 6: Click Create.
Deploying the VM-Series with Bootstrap
14.1 Deploy the VM-Series
14.2 Add VM-Series to Load-Balancer Backend Pools
Procedures
The following procedures are completed using the Azure Resource Manager deployed from an Azure Resource Man-
ager Template posted at GitHub. If you are already signed in to Azure at
hps://portal.azure.com
, then the deployment
from GitHub uses the same session authorizaon.
141Palo Alto Networks
Deployment Details for Automated Bootstrapping
14.1 Deploy the VM-Series
This procedure is essenally idencal to Procedure 4.1, with addional steps to provide the bootstrap informaon.
Table 32 VM-Series bootstrap deployment parameters
Parameter Value Comments
Resource group AzureRefArch-Shared Exisng
Locaon Tested in West US
VM name ARAS-VMFW3 First bootstrap device. Assumes two rewalls
already deployed
Storage account name azurerefarchv2shared —
Storage account exisng RG AzureRefArch-Shared —
Fw Av set AzureRefArch-Shared-AS —
VM size Standard_D3_v2 hps://www.paloaltonetworks.com/docu-
mentaon/80/virtualizaon/virtualizaon/
set-up-the-vm-series-rewall-on-azure/about-
the-vm-series-rewall-on-azure/minimum-sys-
tem-requirements-for-the-vm-series-on-azure
Public IP type standard Standard IP SKU required for use with Azure
Standard load-balancer
Image version latest —
Image Sku byol —
Bootstrap rewall yes —
Bootstrap storage account azurerefarchv2 The bootstrap storage account may be in any
resource group within the same Azure sub-
scripon and locaon.
Storage account access key <key> Use value recorded from Procedure 13.2, Step
8
Storage account le share vmseries-bootstrap Created in Procedure 13.2
Virtual network name AzureRefArch-VNET Uses AzureRefArch-VNET in resource group
AzureRefarch
Virtual network address prex 192.168.1.0/24 Match the inial IP address space from
AzureRefArch-VNET
Virtual network exisng RG name AzureRefArch —
Subnet0Name Management —
Subnet1Name Shared-Public —
Subnet2Name Shared-Private —
Subnet3Name Shared-VPN —
Table connued on next page
142Palo Alto Networks
Deployment Details for Automated Bootstrapping
Connued table
Parameter Value Comments
Subnet0Prex 192.168.1.0/24 —
Subnet1Prex 172.16.1.0/24 —
Subnet2Prex 10.5.0.0/24 —
Subnet3Prex 10.5.15.0/24 —
Subnet0Start Address 192.168.1.8 First bootstrap device
Subnet1Start Address 172.16.1.8 First bootstrap device
Subnet2Start Address 10.5.0.8 First bootstrap device
Subnet3Start Address 10.5.15.8 First bootstrap device.
Admin username refarchadmin —
Admin password <password> —
Public IP address name aras-vmfw3 First bootstrap device
Nsg name None NSG is applied at subnet level
The custom Azure Resource Manager template used in this procedure has been developed and validated specically for
this deployment guide.
For template details and features, see :
hps://github.com/PaloAltoNetworks/ReferenceArchitectures/tree/master/Azure-1FW-4-interfaces-exisng-environment-BS
Use the parameters in Table 32 to deploy each VM-Series with bootstrap conguraon.
Step 1: Deploy the VM-Series by clicking Deploy to Azure.
Step 2: In the Resource Group secon, choose Use Exisng, and then select AzureRefArch-Shared.
Step 3: In the Vm Name box, enter ARAS-VMFW3.
Step 4: In the Storage Account Name box, enter azurerefarchv2shared.
Step 5: In the Storage Account Exisng RG box, enter AzureRefArch-Shared.
Step 6: In the Fw Av Set box, enter AzureRefArch-Shared-AS.
Step 7: In the Vm Size list, select Standard_D3_v2.
Step 8: In the Public IP Type list, select standard.
143Palo Alto Networks
Deployment Details for Automated Bootstrapping
Step 9: In the Image Version list, select latest.
Step 10: In the Image Sku list, select byol.
Step 11: In the Bootstrap Firewall list, select yes.
Step 12: In the Bootstrap Storage Account box, enter azurerefarchv2.
Step 13: In the Storage Account Access Key box, enter the key value.
Step 14: In the Storage Account File Share box, enter vmseries-bootstrap.
Step 15: In the Virtual Network Name box, enter AzureRefArch-VNET.
Step 16: In the Virtual Network Address Prex box, enter 192.168.1.0/24.
Step 17: In the Virtual Network Exisng RG Name box, enter AzureRefArch.
Step 18: In the Subnet0Name box, enter Management.
Step 19: In the Subnet1Name box, enter Shared-Public.
Step 20: In the Subnet2Name box, enter Shared-Private.
Step 21: In the Subnet3Name box, enter Shared-VPN.
Step 22: In the Subnet0Prex box, enter 192.168.1.0/24.
Step 23: In the Subnet1Prex box, enter 172.16.1.0/24.
Step 24: In the Subnet2Prex box, enter 10.5.0.0/24.
Step 25: In the Subnet3Prex box, enter 10.5.15.0/24.
Step 26: In the Subnet0Start Address box, enter 192.168.1.8.
Step 27: In the Subnet1Start Address box, enter 172.16.1.8.
Step 28: In the Subnet2Start Address box, enter 10.5.0.8.
144Palo Alto Networks
Deployment Details for Automated Bootstrapping
Step 29: In the Subnet3Start Address box, enter 10.5.15.8.
Step 30: In the Admin Username box, enter refarchadmin.
Step 31: In the Admin Password box, enter the password.
Step 32: In the Public IP Address Name box, enter aras-vmfw3.
Step 33: In the Network Security Group box, enter None.
Step 34: Review the terms and condions. If they are acceptable, select I agree to the terms and condions.
Step 35: Click Purchase.
Aer deployment, the device registers with Panorama by using the provided bootstrap informaon. The device is au-
tomacally licensed using the bundled auth-code in the bootstrap package. Aer the services are restarted, the device
receives template and device group conguraon from Panorama and is ready to be managed.
The soware should be upgraded to the same version as other VM-Series rewalls. This procedure is idencal to Pro-
cedure 4.3 in this guide.
14.2 Add VM-Series to Load-Balancer Backend Pools
You already created the public and private load-balancers in Procedure 7.2 and Procedure 7.4, as well as performing
other conguraons and updates throughout the guide. Now you integrate addional rewall resources into the design
by adding the VM-Series devices to the load-balancer backend pools.
This procedure only includes the steps to add an addional VM-Series device to exisng backend pools. Repeat this
procedure for each VM-Series device as required.
Step 1: In Home > Load Balancers > AzureRefArch-Shared-Public, click Backend pools.
Step 2: Click Firewall-Layer.
Step 3: In the VIRTUAL MACHINE column, in the rst blank row, select a VM-Series to be added to this backend pool
(example: aras-vmfw3).
Step 4: In the IP ADDRESS column, select the IP conguraon that is associated to the Shared-Public subnet. (ex-
ample: ipcong-untrust).
Step 5: Click Save, and then click X to exit.
145Palo Alto Networks
Deployment Details for Automated Bootstrapping
Step 6: In Home > Load Balancers > AzureRefArch-Shared-Internal, click Backend pools.
Step 7: Click Internal-Firewall-Layer.
Step 8: In the VIRTUAL MACHINE column, in the rst blank row, select a VM-Series to be added to this backend pool
(example: aras-vmfw3).
Step 9: In the IP ADDRESS column, select the IP conguraon that is associated to the Shared-Private subnet. (ex-
ample: ipcong-trust).
Step 10: Click Save, and then click X to exit.
Step 11: If you have addional backend pools for your internal load-balancer for Inbound Access and Backhaul and
Management trac, then repeat Step 6 through Step 10 for the Public-Firewall-Layer backend pool on the Shared-
Public subnet and the VPN-Firewall-Layer backend pool on the Shared-VPN subnet.
146Palo Alto Networks
What’s New in This Release
What’s New in This Release
Palo Alto Networks made the following changes since the last version of this guide:
• This is a new guide.
Headquarters
Palo Alto Networks
4401 Great America Parkway
Santa Clara, CA 95054, USA
www.paloaltonetworks.com
© 2018 Palo Alto Networks, Inc. Palo Alto Networks is a registered trademark of Palo Alto Networks. A list of our trade-
marks can be found at
hp://www.paloaltonetworks.com/company/trademarks.html
. All other marks menoned herein may
be trademarks of their respecve companies. Palo Alto Networks reserves the right to change, modify, transfer, or other-
wise revise this publicaon without noce.
Phone: +1 (408) 753-4000
Sales: +1 (866) 320-4788
Fax: +1 (408) 753-4001
info@paloaltonetworks.com
You can use the
feedback form
to send comments
about this guide.
B-000116P-1 08/18
