DESIGN

GUIDE

Securing Applications in Azure

DECEMBER 2024
 Table of Contents

Table of Contents
Preface......................................................................................................................................................................................................... 3
Purpose of This Guide................................................................................................................................................................................ 5
Audience.............................................................................................................................................................................................. 5
Related Documentation........................................................................................................................................................................5
Introduction.................................................................................................................................................................................................. 7
Public Cloud Concepts............................................................................................................................................................................... 8
Scaling Methods.................................................................................................................................................................................. 8
Reduced Time to Deployment............................................................................................................................................................. 8
Network Security Integration................................................................................................................................................................9
Cloud Infrastructure Protection............................................................................................................................................................ 9
Azure Concepts and Services.................................................................................................................................................................. 11
Resource Manager.............................................................................................................................................................................11
Resource Groups...............................................................................................................................................................................11
Virtual Networks.................................................................................................................................................................................12
Resiliency Constructs.........................................................................................................................................................................17
Palo Alto Networks Design Details.......................................................................................................................................................... 22
VM-Series Firewall on Azure.............................................................................................................................................................. 22
VM-Series Firewall Integration to Azure............................................................................................................................................. 25
Management and Logging.................................................................................................................................................................44
Prisma Cloud for Azure..................................................................................................................................................................... 51
Design Model.............................................................................................................................................................................................54
Outbound Traffic................................................................................................................................................................................ 56
East-West Traffic................................................................................................................................................................................ 57
Inbound Traffic................................................................................................................................................................................... 58
Enterprise Network and Management Traffic..................................................................................................................................... 61
Summary.................................................................................................................................................................................................... 62
Feedback....................................................................................................................................................................................................63

Palo Alto Networks 2

 Preface

Preface
GUIDE TYPES

Overview guides provide high-level introductions to technologies or concepts.

Design guides provide an architectural overview for using Palo Alto Networks® technologies to provide visibility, control, and
protection to applications built in a specific environment. These guides are required reading prior to using their companion
deployment guides.

Deployment guides provide decision criteria for deployment scenarios, as well as procedures for combining Palo Alto
Networks technologies with third-party technologies in an integrated design.

Solution guides provide add-on solutions for post-deployment use cases.

DOCUMENT CONVENTIONS

Blue text indicates a configuration variable for which you need to substitute the correct value for your environment.

In the IP box, enter [Link]/24, and then click OK.

Bold text denotes:

• Command-line commands.

# show device-group branch-offices

• User-interface elements.

In the Interface Type list, choose Layer 3.

• Navigational paths.

Navigate to Network > Virtual Routers.

• A value to be entered.

Enter the password admin.

Palo Alto Networks 3

 Preface

Italic text denotes the introduction of important terminology.

An external dynamic list is a file hosted on an external web server so that the firewall can import objects.

Highlighted text denotes emphasis.

Total valid entries: 755

ABOUT PROCEDURES
These guides sometimes describe other companies’ products. Although steps and screen-shots were up-to-date at the time
of publication, those companies might have since changed their user interface, processes, or requirements.

GETTING THE LATEST VERSIONS OF GUIDES

We continually update reference architecture guides. You can access the latest version of this and all guides at this location:

[Link]

WHAT'S NEW IN THIS VERSION

Since the last version of this guide, Palo Alto Networks made the following changes:

• Improved guidance for securing the management interface

• Updated the health-check method from the external load-balancer and application gateway

• Changed phrasing, terminology, and diagrams for technical accuracy

Palo Alto Networks 4

 Purpose of This Guide

Purpose of This Guide

This guide describes how your organization can use Palo Alto Networks VM-Series firewalls to bring visibility, control, and
protection to applications built on Microsoft Azure.

This guide:

• Links the technical design aspects of Microsoft Azure and the Palo Alto Networks solutions and then explores several
technical design models. The design model includes two options that span the scale of enterprise-level operational
environments.

• Provides a framework for architectural discussions between Palo Alto Networks and your organization.

• Provides an overview of how Prisma® Cloud helps organizations manage security risks and compliance in a public-
cloud infrastructure.

• Is required reading prior to using the Palo Alto Networks Microsoft Azure deployment guides. The deployment guides
provide decision criteria for deployment scenarios, as well as procedures for enabling features of Microsoft Azure and
the Palo Alto Networks VM-Series firewalls in order to achieve an integrated design.

AUDIENCE
This guide is for technical readers, including system architects and design engineers, who want to deploy the Palo Alto
Networks VM-Series firewalls within a public cloud data center infrastructure. This guide assumes the reader is familiar with
the basic concepts of applications, networking, virtualization, security, and high availability. The reader should also possess 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 architecture guide:

• Zero Trust Enterprise: Design Guide—Provides design guidance for securing users, applications, and infrastructure
by using the Palo Alto Networks Zero Trust Enterprise approach to eliminate implicit trust and continuously validate
every stage of a digital interaction.

• Network Security for the Public Cloud: Overview—Introduces multiple Palo Alto Networks solutions for public-
cloud network security, enterprise connectivity, centralized management, logging, and telemetry.

• Securing Applications in Azure with VM-Series Firewalls and Panorama: Deployment Guide—Provides
implementation details for using VM-Series virtualized next-generation firewalls to secure resources deployed in
Azure. Includes high-level tasks and step-by-step configuration details for centralized management using Panorama®,
resource monitoring, and advanced logging capabilities.

Palo Alto Networks 5

 Purpose of This Guide

• Securing Applications in Azure with VM-Series Firewalls and Strata Cloud Manager: Deployment Guide—
Provides implementation details for using VM-Series virtualized next-generation firewalls to secure resources deployed
in Azure. Includes high-level tasks and step-by-step configuration details for centralized management using Strata™
Cloud Manager, resource monitoring, and advanced logging capabilities.

• Panorama on Azure: Deployment Guide—Provides implementation details for using Palo Alto Networks Panorama
virtual appliances, deployed on Azure, to monitor, configure, and automate security management.

• SASE for Securing Private Applications: Design Guide—Provides design and deployment guidance for using
Prisma Access and Prisma SD-WAN to secure access to private applications for mobile users and users located at
remote-site locations.

• SASE for Securing Private Applications: Deployment Guide—Provides implementation details for using Prisma
Access and Prisma SD-WAN to secure access to private applications for mobile users and users located at
remote-site locations. Includes decision criteria for deployment scenarios, as well as step-by-step procedures for
programming features to achieve an integrated design.

Palo Alto Networks 6

 Introduction

Introduction
Organizations are deploying applications and services on Microsoft Azure public-cloud infrastructure for a variety of reasons,
including:

• Business agility—Infrastructure resources are available when and where you need them, minimizing IT staffing
requirements and providing faster, predictable time-to-market. Virtualization in both public- and private-cloud
infrastructure has permitted IT organizations to respond to business requirements within minutes instead of days,
weeks, or months.

• Better use of resources—Projects are more efficient, and there are fewer operational issues, permitting employees
to spend more time adding business value. Employees have the resources they need, when they need them, to bring
value to the organization.

• Operational vs capital expenditure—Costs align directly with resource usage, providing a utility model for IT
infrastructure requiring little-to-no capital expense. Gone are the large capital expenditures and time delays associated
with building private data center infrastructure.

Although infrastructure-as-a-service (IaaS) providers are responsible for ensuring the security and availability of their
infrastructure, organizations are ultimately still responsible for the security of their applications and data. The security
requirements are similar to on-premises deployments, but the specific implementation details of how to properly architect and
deploy security technologies in a public-cloud environment, such as Azure, are different.

Figure 1 Security responsibility in the IaaS environment

The VM-Series firewall is an integral security-enforcement and intelligence-gathering component of the Palo Alto Networks
product portfolio. The Palo Alto Networks VM-Series firewall deployed on Azure has the same features, benefits, and
management as the PA-Series next-generation firewalls you might have deployed elsewhere in your organization. First and
foremost, the application-control and threat-prevention capabilities of the VM-Series firewalls protect your Azure workloads
and application deployments from threats, data loss, and business disruption. To improve threat prevention capabilities
collectively and continually, any observed and collected threat-intelligence information is shared across other portfolio
components.

Palo Alto Networks 7

 Public Cloud Concepts

Public Cloud Concepts

Organizations generally move to the public cloud with the goals of increasing scale and reducing time to deployment.
Achieving these goals requires application architectures that are built specifically for the public cloud. Before you can architect
for the public cloud, you must understand how it is different from traditional on-premises or enterprise environments.

SCALING METHODS
Traditionally, organizations scale on-premises deployments through the purchase of devices that have increased performance
capacity. Scaling up an on-premises deployment in this method makes sense because organizations typically purchase the
devices in order to satisfy the performance requirements during the devices' lifetime.

Public cloud environments focus on scaling out the deployment instead of scaling up. This architectural difference stems
primarily from the capability of public cloud environments to dynamically increase or decrease the number of resources
allocated to your environment. In the public cloud, infrastructure used to satisfy performance requirements can have a lifetime
in minutes instead of years. Instead of purchasing extra capacity for use at some time in the future, the dynamic nature of the
public cloud allows you to allocate just the right amount of resources required to service the application.

In practice, to architect an application for the cloud, you need to distribute functionality, and you should build each functional
area to scale out as necessary. Typically, this means a load balancer distributes traffic across a pool of identically configured
resources. When changes occur in the application traffic, the number of resources you have allocated to the pool can
dynamically increase or decrease. This design method provides scale and resiliency. However, the application architecture
must take into account that the resources are transient. For example, you should not store the application state in the
networking infrastructure or in the frontend application servers. Instead, store state information on the client or persistent
storage services.

The ability to scale a cloud architecture extends not only to the capacity of an application but also capacity to deploy
applications globally. Scaling an application to a new region in a traditional on-premises deployment requires significant
investment and planning. Public cloud architectures are location-agnostic, and you can deploy them globally in a consistent
amount of time.

REDUCED TIME TO DEPLOYMENT

To achieve the goals of a reduced time to deployment, you must have a development and deployment process that is
repeatable and reacts to changes quickly. DevOps workflows are the primary method for implementing this process. DevOps
workflows are highly dependent on the ability to automate, as much as possible, the process of deploying a resource
or application. In practice, this means you must be able to programmatically bootstrap, configure, update, and destroy
the cloud infrastructure, as well as the resources running on it. Compared to traditional on-premises deployments where
device deployment, configuration, and operation happen manually, automated workflows in a public cloud environment can
significantly reduce time to deployment.

Palo Alto Networks 8

 Public Cloud Concepts

Automation is so core to cloud design that many cloud application architectures deploy new capabilities through the
automated build-out of new resources instead of updating the existing ones. This type of cloud architecture provides several
benefits, not the least of which is the ability to phase in the changes to a subset of the traffic as well as the ability to quickly
roll back the changes by redirecting traffic from the new resources to the old.

NETWORK SECURITY INTEGRATION

VM-Series firewalls enable you to securely implement scalable cloud architectures and reduce time to deployment. To achieve
this, you leverage the following capabilities of VM-Series firewalls:

• Application visibility—VM-Series firewalls natively analyze all traffic in a single pass to determine the application,
content, and user identity. You use application, content, and user identities as core elements of your security policy
and for visibility, reporting, and incident investigation.

• Prevent advanced attacks at the application level—Attacks, much like many applications, can use any port,
rendering traditional prevention mechanisms ineffective. VM-Series firewalls allow you to use Threat Prevention and
the WildFire® cloud-based threat analysis service to apply application-specific threat prevention policies that block
exploits, malware, and previously unknown threats from infecting your cloud.

• Consistent policy and management—Centralized management enables you to manage your VM-Series
deployments across multiple cloud environments, along with your physical security appliances, thereby ensuring policy
consistency and cohesiveness. Rich, centralized logging and reporting capabilities provide visibility into virtualized
applications, users, and content.

• Automation features to reduce time to deployment—VM-Series firewalls include management features that enable
you to integrate security into your public cloud development projects. You can use bootstrapping to automatically
deploy firewalls. After bootstrapped firewalls deploy, Panorama appliances or Strata Cloud Manager can configure
the firewall and keep the firewall policy up to date. Alternatively, you can use automation tools, such as Terraform
and Ansible, to deploy and configure the VM-Series firewalls, as well as Azure project resources. You can use
firewall performance metrics and health information in order to create automated actions based on performance and
usage patterns. By allowing VM-Series firewalls to consume external data, you can automate policy updates when
workloads change by using the fully documented XML API and dynamic address groups. The result is that you can
deploy new applications and next-generation security simultaneously in an automated manner.

CLOUD INFRASTRUCTURE PROTECTION

Azure provides basic infrastructure components with a responsibility to ensure that each customer's workloads are
appropriately isolated from other workloads and that the underlying infrastructure and physical environment are secure.
However, the customer has the responsibility for securely configuring the instances, operating systems, and any necessary
applications, as well as maintaining the integrity of the data processed and stored by each virtual machine. This shared-
responsibility model is often a point of confusion for consumers of cloud services.

Services have default configurations that might be secure upon implementation, but it is up to the customer to make the
assessment and lock those service configurations down to ensure the integrity of the data itself.

Palo Alto Networks 9

 Public Cloud Concepts

Security and compliance risks in cloud computing threaten an organization's ability to drive digital business. The dynamic
nature of the cloud, coupled with the potential complexity of having multiple cloud service providers in the environment and
massive volume of cloud workloads, makes security and compliance cumbersome.

Public cloud environments use a decentralized administration framework that often suffers from a corresponding lack of any
centralized visibility. Additionally, compliance within these environments is complex to manage. Incident response requires the
ability to rapidly detect and respond to threats. However, public cloud capabilities are limited in these areas.

Prisma Cloud offers comprehensive and consistent cloud infrastructure protection that enables organizations to effectively
transition to the public cloud by managing security and compliance risks within their public cloud infrastructure.

Prisma Cloud threat defense enables your organization to:

• Improve the visibility of assets and applications.

• Provide security and compliance posture reporting.

• Enforce DevOps best practices, implemented using policy guardrails.

• Implement DevOps threat monitoring, which identifies risky configurations, network intrusions, and host vulnerabilities
for the management plane. This complements the capabilities of the VM-Series firewall to secure the in-line data
plane.

• Perform anomaly detection to identify compromised accounts and insider threats.

• Gain forensic capabilities that permit the investigation of current threats or past incidents to quickly determine the root
cause.

• Use contextual alerting in order to prioritize issues and respond appropriately.

Through proactive security assessment and configuration management that uses industry best practices, Prisma Cloud
makes cloud-computing assets harder to exploit. Prisma Cloud enables organizations to implement continuous monitoring of
the Azure infrastructure. It provides an essential, automated, and always up-to-date security posture status that organizations
can use to make cost-effective, risk-based decisions about service configuration and vulnerabilities inherent in cloud
deployments.

Organizations can also use Prisma Cloud to prevent any deployed Azure resource from falling out of compliance. Visibility into
the actual security posture of the cloud prevents failed audits and the subsequent fines associated with data breaches and
non-compliance.

Palo Alto Networks 10

 Azure Concepts and Services

Azure Concepts and Services

When deployed on Azure, VM-Series firewalls rely upon underlying Azure services and functionality to integrate into the
application traffic flow and protect the workload. The concepts covered in this section give an overview of Azure services
relevant to VM-Series firewalls. Microsoft Azure documentation is the definitive source of information on these topics and
should be consulted for additional detail.

RESOURCE MANAGER
You use Azure Resource Manager to deploy, manage, and monitor resources. In Azure, resources are the managed
components used to build applications and services. Resources include, but are not limited to, virtual machines, virtual
networks, load balancers, storage services, and non-Microsoft services.

Azure Resource Manager provides a variety of interface options for deploying and managing resources. Azure PowerShell
and CLI provide command-line control, the Azure portal provides a graphical frontend, and Azure’s Representational state
transfer (REST) API allows programmatic interaction. While all of these interfaces use a common API to interact with Resource
Manager, their capabilities can vary. For example, when new features are released, for a short period it is common that feature
deployment and configuration is available only through the CLI. Command-line options also allow for scriptable interactions
that are impossible in the portal.

Despite most users bring familiar with the direct deployment of resources through the portal, Resource Manager templates
are the most efficient way to deploy repeatable and tested resource configurations in Azure. Templates define resources
and their dependencies in a JavaScript Object Notation (JSON) file. You don’t have to create templates from scratch. When
you deploy resources manually in the portal, Azure sets up a model template. These automatically created templates are
good starting points for transforming manually built and tested proof-of-concepts into scalable and repeatable deployments.
The template order is not critical, because Azure does not process templates in a step-by-step order but ensures that all
dependencies are complete before deploying a resource.

RESOURCE GROUPS
Resource groups are logical collections of resources. Resource groups provide administrative hierarchy and define who
can manage and control resources. All resources (virtual machines, virtual networks, load balancers, etc.) must belong to a
resource group. More importantly, though, resources can belong to only one resource group. Simple deployments often use
a single resource group that contains all of the resources deployed in Azure. As deployments grow and requirements change,
most organizations choose to implement role-based access control (RBAC) to control who can create and manage specific
resources. Each organization has unique requirements in determining how to separate resources into RBAC domains, but
a common technique is to group resources based on function (application, infrastructure). Separating application resources
from the infrastructure resources is possible because resource groups do not control network communication between
application resources.

Palo Alto Networks 11

 Azure Concepts and Services

VIRTUAL NETWORKS
A virtual network (VNet) is a logically segmented network within Azure that allows connected resources to communicate with
each other. A VNet contains one or more public or private IP address ranges that you can then divide into subnets (/29 or
larger). VNet IP address space, both public and private, is reachable only within the VNet or through services connected to
the VNet, such as a VPN. Because VNets are isolated from each other, you can overlap IP network definition across VNets.

Figure 2 Single VNet

Virtual machine network interfaces receive IP addresses, default gateways, and DNS servers from the Azure DHCP service.
By default, when you start a virtual machine, DHCP dynamically assigns the first available IP address in the subnet to the
virtual machine’s interface. If you created a VM through the Resource Manager, the IP address does not change when the VM
reboots or remains in a stopped state. If you used a classic deployment, then the IP address could change after the VM is
restarted from being in a stopped state. In either case, the assigned address is released when the VM is deleted.

Static IP addressing is available when a persistent IP address is required. When there is only one IP on an interface, you
do not need to configure static IP addresses in the operating system running on the virtual machine. Instead, you configure
the IP address as static in the Azure portal or the template. When you configure a static IP address, the virtual machine still
receives the IP address through DHCP.

Azure reserves five internal IP addresses from each subnet. You cannot configure these IP
addresses on a resource: the first and last addresses of the address space (for the subnet
address and multicast) and three addresses reserved for internal use (for DHCP and DNS
purposes).

An alternative to static IP addressing for persistent connectivity is the use of name resolution to communicate between
resources within a VNet. The Azure DNS servers provide not only public name resolution but also internal name resolution
within the VNet. The addition or state change of a virtual machine automatically updates Azure name resolution. If a virtual
machine has multiple internal IP addresses, its name resolves to its primary IP address.

Although VNets do not contain publicly routable IP addresses, you can associate resources within a VNet with a publicly
routable IP address. You can map public IP addresses to internal IP addresses using a one-to-one assignment, and Azure
networking automatically translates the IP addressing of the network flow as it enters and leaves the VNet.

Depending on the configuration, public IP addresses can change as a virtual machine changes state. You can configure a
public IP address to be dynamic or static, but in most situations, configuring a DNS name label on the public IP address is
the preferred way to ensure persistent connectivity if the underlying IP address can change.

Palo Alto Networks 12

 Azure Concepts and Services

If you need multiple public IP addresses on a single network interface, you can configure one or more secondary IP
addresses. You can then associate a public IP address to each secondary IP address on the interface. Because DHCP
cannot assign multiple IP addresses to a single interface, you should statically define secondary IP addresses in Azure and
configure them in the virtual machine operating system.

All resources deployed in a VNet have unfiltered outbound access to the internet, even when
they do not have a public IP address directly assigned. Azure automatically translates the IP
addresses of outbound traffic to the internet. Assigning a public IP address enables inbound
connectivity to the resource using a known IP address or DNS name.

Virtual Network Peering

You can separate workloads across functional environments or administrative domains using multiple VNets. Virtual network
peering allows you to logically connect Azure VNets to provide resource connectivity. However, you cannot use overlapping IP
address space within the group of peered VNets.

Two types of peering are supported:

• VNet peering—The connected VNets are located within the same Azure region (example: West US).

• Global VNet peering—The connected VNets are located across multiple Azure regions (example: West US and East
US). Some Azure networking capabilities are restricted when using Global VNet peering. For more information, see the
Azure documentation for Virtual Network Peering.

You achieve full IP reachability between VNets after you establish the peering connection. All network traffic using VNet
peering remains within the Azure backbone. Azure supports 1000 virtual networks within a subscription and supports up to
500 peering connections for each virtual network.

Figure 3 Multiple peered VNets

Traffic Forwarding
Azure uses a Layer 3 overlay network fabric that does not operate in the same fashion as traditional Layer 2 packet
forwarding. However, the Azure network infrastructure attempts to make the operational differences transparent. For example,
even though you cannot ping the default router or use traceroute during troubleshooting, virtual machines still receive a
default route through DHCP.

Palo Alto Networks 13

 Azure Concepts and Services

All resources connected to a VNet communicate directly via the overlay network, even if they are on different IP subnets.
When you add or change a subnet, Azure automatically defines system routes to facilitate communication within the VNet as
well as to the internet. Traffic-forwarding behavior with peered VNets is essentially the same as within a single VNet. Azure
installs system routes for the defined address space of the peered VNets into the active forwarding table for each subnet.

Figure 4 Azure networking

Azure networking includes system routes with the following next-hop types:

• Virtual network—System route to a destination prefix within the local VNet address space. Azure automatically
creates this route type by default when an address space is defined. You may manually create additional routes of this
type as necessary.

• VNet peering—System route to a destination prefix within a peered VNet address space. Azure automatically creates
this route type by default when a peer connection is established.

• Internet—System route to the internet. When you create a VNet, Azure automatically creates a default system route
that matches any destination prefix using a wildcard match ([Link]/0). You can manually create additional, more-
specific routes to the internet as necessary.

• None—Special system route to drop traffic for a specified destination prefix. Azure automatically creates these system
routes for RFC-1918 and RFC-6598. You can manually create additional routes of this type in order to drop traffic to
other destination prefixes as necessary.

Palo Alto Networks 14

 Azure Concepts and Services

• Virtual appliance—Manually created system route for a specified destination prefix with a specified next-hop IP
address. You must assign the next-hop address to a virtual device deployed within a VNet (or peered VNet).

• Virtual network gateway—System route to a destination prefix assigned to a virtual network gateway connection.
Azure automatically creates this system route when you configure the connection.

Table 1 Azure routes example

Address space Address prefix Nexthop type

VNet defined [Link]/16 Virtual network

Peer VNet [Link]/16 VNet peering

Default (Azure defined) [Link]/0 Internet

RFC-1918 (Azure defined) [Link]/8 None

RFC-1918 (Azure defined) [Link]/12 None

RFC-1918 (Azure defined) [Link]/16 None

RFC-6598 (Azure defined) [Link]/10 None

User-Defined Routes
User-defined routes (UDRs) modify the default traffic-forwarding behavior of Azure networking. You primarily use a UDR to
direct traffic to a resource, such as a load balancer or a firewall, within the VNet or in a peered VNet. You can also configure
them to send traffic to a VPN connection or to be used as a null route to discard unwanted traffic.

You configure a UDR on a per-subnet basis, and it applies to traffic that is sent within the subnet. The destination for a route
can be a different subnet in the VNet, a different subnet in another VNet (with an existing peer connection), anywhere on
the internet, or a private network connected to the VNet. The next hop for the route can be any resource in the VNet or in a
peered VNet in the same region.

The use of UDR summary routes can have unexpected consequences. If you apply a UDR
summary route to a subnet that falls within the summary but does not have a more specific
UDR or system route, UDR controls traffic within the subnet (host to host).

To view the active system routes for a route table that you have applied to a subnet, you can use the Effective Routes
troubleshooting tool. The tool is available under the settings pane of any network interface.

Palo Alto Networks 15

 Azure Concepts and Services

Network Security Groups

Network security groups (NSGs) filter ingress and egress network traffic. You can associate an NSG to a subnet, to the
network interface of a virtual machine, or to both. For ease of configuration, when you apply the same policies to more than
one resource, you can associate a single network security group with multiple subnets or virtual machine network interfaces.
An NSG associated to the subnet with a common policy can be easier to manage than unique NSGs applied at the interface
level.

When you are using Standard SKU IP addresses, NSGs are required on the subnet or NIC in
order for traffic to reach the resource.

You create a prioritized list of rules that defines the behavior of a network security group. Rules are defined and matched by
the traffic source, destination, port, and protocol. In addition to IP addressing, you can set the source and destination of a
rule by using Azure service tags or application security groups. There are separate policies for inbound and outbound traffic
flows.

Network security groups are pre-configured with default inbound and outbound security rules that perform the following
tasks:

• Allowing all traffic within the VNet

• Allowing outbound traffic to the internet

• Allowing inbound traffic that is originating from Azure's load-balancer probe ([Link]/32)

• Denying all other traffic

You cannot modify or remove the default security rules. To override the behavior of a default rule, you must precede it with a
custom rule that has a higher priority. The default rules have priority values that begin at 65000, so you must assign a priority
value less than 65000 in order to override the default rules. You can view the active rules by using the Effective Security Rules
troubleshooting tool in the network security group or network interface settings.

Enterprise Network Connectivity

A virtual network gateway (VNG) provides connectivity between an Azure virtual network and your enterprise networks and
data centers. Site-to-site connectivity through a VNG can either be through IPSec VPN (also known as a VPN gateway) or a
dedicated private connection (also known as an ExpressRoute gateway). When you deploy a virtual network gateway as a
VPN gateway, it supports the configuration of IPSec VPN tunnels to one or more of your locations across the internet. When
deployed as an ExpressRoute gateway, the VNG provides connectivity to enterprise locations through a dedicated private
circuit facilitated by a service provider.

You can only deploy one virtual network gateway of each type in a virtual network, and you
deploy them in a dedicated gateway subnet.

Palo Alto Networks 16

 Azure Concepts and Services

A VPN gateway is composed of pair of virtual machines deployed, by default, in an active/standby configuration for resiliency.
You may configure IP routing between Azure and the enterprise network to be static or dynamically exchanged through IKEv2
or BGP. A VPN gateway supports configurations with multiple tunnels to a single location, providing additional connection
resiliency for deployments with resilient on-premises VPN devices. Active/active configuration is also possible on select VPN
gateway sizes.

Figure 5 VPN gateway

Connections through an Azure ExpressRoute gateway do not connect through or traverse the public internet. Instead, Azure
resources are accessed directly through colocation facilities, point-to-point Ethernet, or connectivity into your MPLS WAN
service. Microsoft recommends ExpressRoute connections for all enterprise customer connectivity and supports a range of
bandwidth options from 50 Mbps to 10 Gbps.

For resiliency, Azure terminates ExpressRoute connections on a pair of edge routers. Two BGP connections provide resilient,
dynamic IP routing between Azure and your enterprise networks. You can share ExpressRoute circuits across multiple
VNets. In each virtual network that requires backhaul over the ExpressRoute gateway, a VNG connects the VNet to the
ExpressRoute circuit.

RESILIENCY CONSTRUCTS

Availability Sets and Managed Disks

To ensure that maintenance and failures within the Azure data center do not affect the availability of an application or service,
you can place multiple virtual machines into an availability set. Availability sets distribute virtual machines across multiple
Azure fault and update domains. Separating fault domains places virtual machines that are members of the availability set
on hypervisors that do not share power, physical switching, or other Azure data center infrastructure. Separating update
domains stops concurrent reboots of hypervisors hosting the virtual machines in the availability set.

You can only configure an availability set on a virtual machine during its initial deployment.
You can’t modify a virtual machine's availability set configuration after you have deployed the
virtual machine.

Palo Alto Networks 17

 Azure Concepts and Services

Managed disks work in conjunction with virtual machine availability sets to provide enhanced resiliency. With managed disks,
Azure ensures that each member of the availability set uses a unique hardware for their backend disk store. This limits the
number of virtual machines that a hardware or software failure in the Azure storage system can affect.

Load Balancing
Load balancing distributes traffic across a set of resources, based on IP traffic criteria such as Layer 4 information, Layer
7, or DNS. Load balancers check the traffic targets for health and remove unhealthy resources, thereby enhancing the
application's resiliency. Azure offers several types of load balancers:

• Azure Load Balancer

• Azure Application Gateway

• Azure Traffic Manager

Azure Load Balancers

Azure Load Balancers distribute traffic based on TCP/UDP information. Load balancers listen on one or more frontend
virtual IP addresses (VIPs), and you configure rules (defined by a protocol and port number) to distribute traffic to a healthy
backend pool resource. The default load-balancing algorithm uses a 5-tuple hash consisting of the source IP address and
port number, destination IP address and port number, and protocol. Alternate algorithms include a 3-tuple and 2-tuple hash

There are two types of load balancers: internal and public. The difference between them is the source of the traffic. You use
the internal load balancer only for traffic originating within the Azure cloud or coming across a point-to-site VPN terminating
within Azure. The public load balancer is reachable from any device on the internet. The load balancers are available in both
the Basic and Standard SKUs. The Standard SKU load balancers have an expanded feature set and increased scale and is
the recommended resource for this guide.

Basic Load Balancer backend pools are composed only of the virtual machines that are members of availability sets.
Standard Load Balancer backend pools can be composed of any virtual machine in the VNet, but for the highest availability,
the virtual machines should be members of availability sets.

By default, the load balancer performs a destination NAT on the traffic before sending it to the backend pool. It translates
the destination IP address and port number of the incoming traffic to the IP address and port number of the virtual machine
selected from the backend pool. The load balancer does not translate the source IP address of the incoming traffic. The
virtual machines in the backend pool see the originating client’s IP address as the source. However, even though the return
traffic does not pass through the load balancer, Azure networking tracks the connection state and translates the source IP
address and port number of the return traffic to the load balancer’s VIP.

To support multiple applications using a single backend pool, you must configure each application to use a unique port
number in the backend pool. Also, each application must either use a unique VIP or a unique port number on a VIP that is
shared between multiple applications.

Alternatively, enabling floating IP on a load-balancing rule disables destination NAT and allows the virtual machines in the
backend pool to see the original destination. The backend pool resources can use both the IP and the port in order to identify
an application allowing for port reuse. However, a floating IP configuration requires that the backend resources listen for the
logical VIP address in addition to the interface address.

Palo Alto Networks 18

 Azure Concepts and Services

Figure 6 Azure Load Balancer configuration options

Azure Load Balancers monitor virtual machine health through guest agent, HTTP custom, and TCP custom probes. If a load
balancer does not receive an expected response (TCP Ack or HTTP 200) from the virtual machine, it removes the virtual
machine from the pool of available resources. Azure Load Balancers continue to monitor unhealthy resources so that when
they return to a healthy state, they reappear in the pool of available resources.

Guest agent probes determine if the virtual machine is in a ready state but they do not monitor the health of the services
running on the virtual machine. Even when a service, such as a web server, is running on the resource, probe responses
come from the guest agent only and not from the web server.

When you configure floating IP, the probe monitors the health of the backend virtual machine via its interface IP address.
Because the resource is listening for traffic on a logical VIP address, it is important to ensure the virtual machine interface IP
address reflects the health of the service associated with the logical address.

Azure Application Gateway

Azure Application Gateways use HTTP/HTTPS information to distribute traffic across resources within a data center.
Application gateways have a single public IP address but can host up to 20 websites, each with a separate backend pool.
Primarily, Application Gateway relies on HTTP host headers to differentiate between websites. When you enable SSL offload
on an Application Gateway, the gateway can also use server name indication to distinguish between websites. When SSL
offload is enabled, you can choose to pass cleartext traffic to the backend pool or re-encrypt the traffic before passing it to
the backend pool.

Also, for each website, URL path-based routing allows you to select a backend pool to serve content, based on the folder in
the URL path. For example, you could service the URLs [Link]/images/ and [Link]/video/ on two
different backend pools, even though it appears as a single website.

Both the inbound and the return traffic must flow through an Application Gateway. To ensure bi-directional traffic flows, you
must apply address translation to both the source and the destination IP addresses. The destination NAT forwards traffic
to the selected backend pool resource, and source NAT ensures the return traffic from the selected resource returns to the
Application Gateway.

Palo Alto Networks 19

 Azure Concepts and Services

Because Application Gateways employ VNet system routes to direct traffic, you must deploy the gateways in a dedicated
subnet. If it shares a subnet with other resources, return traffic from virtual machines in the subnet will not route back to the
Application Gateway.

Backend pools can leverage network interfaces, public IPs, internal IPs, and fully qualified domain names (FQDNs). After the
Application Gateway chooses a backend pool, it uses a round-robin load sharing algorithm in order to distribute requests
to the resources in the pool. To provide resiliency, Application Gateways monitor the health of the resources through HTTP/
HTTPS requests. If the Application Gateway does not receive an expected response from the resource (HTTP response
status code between 200 and 399), the resource is removed from the pool of available resources. An Application Gateway
continues to monitor unhealthy resources so that when they return to a healthy state, they return to the pool of available
resources.

Figure 7 Application gateway with multiple backend pools

Each application-gateway rule must include an HTTP setting, which corresponds to the protocol (HTTP or HTTPS) and
TCP port of the backend pool targets. Basic rules have a single backend pool with an HTTP setting. Path-based rules
have multiple rule entries, with a default rule entry that is identical to a basic rule. Each additional rule entry includes a path-
matching expression that maps to a backend pool and HTTP setting. The path-based rules provide the most flexibility
when you are creating your application gateway policy. Any of the following policies are valid, as long as the combination of
backend pool and HTTP setting are unique for each additional rule:

• Multiple backend pools, each with default HTTP setting (HTTP/80)

• Single backend pool with multiple HTTP settings (example: default HTTP/80 and HTTP/8081)

• Multiple backend pools, each with one or more HTTP settings

Figure 8 Application gateway with single backend pool and multiple HTTP settings

Palo Alto Networks 20

 Azure Concepts and Services

Optionally, you can deploy Application Gateways with Web Application Firewall (WAF) functionality in addition to load-
balancing. Azure implements Open Web Application Security Project (OWASP) core rule sets 2.29 and 3.0 by default, and
you can also write your own rules. The WAF functionality can run in either detection or prevention mode and integrates with
Azure Monitor and Azure Security Center.

Azure Traffic Manager

Azure Traffic Manager uses DNS to distribute traffic across multiple data centers. Traffic Manager integrates into DNS
requests through DNS CNAME records that alias the application to Traffic Manager.

Traffic Manager offers multiple traffic routing methods, including the following:

• Priority—Defines a set of resources to receive the traffic and a backup set in the event the primary endpoints are
unavailable

• Weighted—Distributes traffic across a set of resources based on a configured weight. You can define weights to
distribute traffic among the endpoints equally.

• Performance—Uses latency to direct traffic to the closest resource location

• Geographic—Directs traffic to endpoints based on the source of the user’s DNS query

After Traffic Manager determines which resource to route traffic toward, it sends a DNS response to the client, which directs
the traffic to the selected resource. Unlike the other load balancers, clients connect to the resource directly. Traffic Manager
does not interact with traffic passing between the client and the resource.

Traffic Manager monitors the health of all assigned resources through HTTP/HTTPS GET requests. If Traffic Manager does
not receive an expected response from the resource (return of a 200 OK), Traffic Manager changes the resource state to
degraded and removes the resource from the pool of available resources. Traffic Manager continues to monitor degraded
resources so that when they return to a healthy state, they return to the pool of available resources.

Palo Alto Networks 21

 Palo Alto Networks Design Details

Palo Alto Networks Design Details

VM-SERIES FIREWALL ON AZURE
The Palo Alto Networks VM-Series firewall is the virtual form-factor of a next-generation firewall. You can deploy it in a range
of private and public-cloud computing environments. The VM-Series firewall on Azure enables you to securely implement
a cloud-first methodology while transforming your data center into a hybrid architecture that combines the scalability and
agility of Azure with your enterprise resources. This allows you to move your applications and data to Azure while maintaining
a security posture that is consistent with the one you might have established on your physical network. To determine
application, content, and user identity, the VM-Series firewall on Azure natively analyzes all traffic in a single pass. The
application, content, and user identities are core elements of your security policy, as well as visibility, reporting, and incident
investigation.

VM-Series Firewall Models

VM-Series firewalls on Azure are available on a variety of configurations, varying only by overall capacity. A capacity license
configures the firewall with a model number and associated capacity limits.

Table 2 VM-Series firewall capacities and requirements

Description VM-100 equivalent VM-300 equivalent VM-500 equivalent VM-700 equivalent

Azure virtual DS3_v2 DS3_v2 DS4_v2 DS5_v2

machine size tested
(recommended)

Firewall throughput 1.4 Gbps 2.5 Gbps 5.2 Gbps 8.6 Gbps
(App-ID™ enabled)

Threat Prevention 0.6 Gbps 1.3 Gbps 3.2 Gbps 4.3 Gbps
throughput

IPSec VPN throughput 0.7 Gbps 1.0 Gbps 1.2 Gbps 1.8 Gbps

vCPUs 2 4 8 16

Memory (min) 6.5 GB 14 GB 28 GB 56 GB

Disk size (min) 60 GB 60 GB 60 GB 60 GB

Although the capacity license sets the VM-Series firewall performance limits, the size of the virtual machine on which you
deploy the firewall determines the firewall’s overall performance and functional capacity. In Table 2, the mapping of VM-Series
firewall to Azure virtual machine size is based on VM-Series model requirements for vCPU, memory, disk size, and network
interfaces. If you choose a virtual machine size that provides more CPUs than the model or deployment profile supports,
the VM-Series firewalls do not use the additional CPU cores. Although larger models of VM-Series firewalls offer increased
capacities, Azure Network Flow limits cap overall throughput.

Palo Alto Networks 22

 Palo Alto Networks Design Details

It might seem that a virtual machine size smaller than those listed in Table 2 would be appropriate for a smaller VM-Series
deployment, however, smaller virtual machine sizes might not have enough network interfaces. Azure provides virtual
machines with two, four, or eight network interfaces. Azure virtual machine sizes such the A2 might work if CPU, memory,
and disk capacity were the only concern, but they are limited by only having two network interfaces. Because VM-Series
firewalls reserve an interface for management functionality, two interface virtual machines are not a viable option. Four-
interface virtual machines meet the requirement of a management, public, and private interface.

For the latest detailed information, see the VM-Series on Microsoft Azure Performance and Capacity and VM-Series
Models on Azure Virtual Machines documentation. Many factors affect performance, and Palo Alto Networks recommends
you do additional testing in your environment to ensure the deployment meets your performance and capacity requirements.
In general, public cloud environments are more efficient when scaling out the number of resources versus scaling up to larger
virtual machine size.

License Options
You can license VM-Series firewalls on Azure with licenses purchased through the Azure Marketplace or regular Palo Alto
Networks channels.

Whichever licensing model you chose is permanent. After you deploy them, VM-Series
firewalls cannot switch between the pay-as-you-go (PAYG) and bring-your-own-license
(BYOL) licensing models. Switching between licensing models requires deploying a new
firewall and migrating the configuration. In the BYOL model, you can migrate between
licensing agreements, including evaluation, regular, and enterprise, because they are all part
of the same licensing model.

PAYG

A pay-as-you-go license model is also called a usage-based or pay-per-use license. You can purchase this type of license
from the Azure public Marketplace, and you are billed hourly.

With the PAYG license, a VM-Series firewall is licensed and ready for use as soon as you deploy it. You do not receive a
license authorization code. When the firewall is stopped or terminated in Azure, the usage-based licenses are suspended or
terminated.

PAYG licenses support the VM-100, VM-300, VM-500, and VM-700 capacity licenses. A PAYG license applies a VM-Series
capacity license based on the virtual machine size. The PAYG license checks the amount of hardware resources available
on the virtual machine and applies the largest VM-Series firewall capacity license allowed for the resources available. For
example, if the virtual machine has two vCPUs and 16 GB of memory, and a VM-100 capacity license is applied based on the
number of vCPUs. However, if the virtual machine has 16 vCPUs and 16 GB of memory, a VM-500 license is applied based
on the amount of memory.

Palo Alto Networks 23

 Palo Alto Networks Design Details

PAYG licenses are available in the following bundles:

• Bundle 1—Includes a VM-Series capacity license, Threat Prevention license (IPS, AV, malware prevention), and a
premium support entitlement

• Bundle 2—Includes a VM-Series capacity license, Threat Prevention license (IPS, AV, malware prevention), DNS
Security license, GlobalProtect® license, WildFire license, PAN-DB URL Filtering license, and a premium support
entitlement

• Bundle 3—Includes a VM-Series capacity license, Advanced Threat Prevention license (IPS, AV, malware prevention),
DNS Security license, GlobalProtect license, WildFire license, Advanced URL Filtering license, and a premium support
entitlement

BYOL

A bring-your-own license model allows you to purchase a license from a partner or reseller or directly from Palo Alto
Networks. In a BYOL model, VM-Series firewalls support all capacities, support entitlements, and subscription licenses. The
BYOL model uses Software NGFW Credits for licensing.

Software NGFW Credits are term-based credits. The term is between 1 and 5 years. You can use these credits to fund
software NGFWs (VM-Series and CN-Series, Cloud-Delivered Security Services, and virtual Panorama appliances).

You allocate credits by creating a deployment profile in the support portal. The profile’s capabilities are dependent on the
PAN-OS version you deploy:

• VM-Series firewalls on PAN-OS version 10.0.3 and earlier—Compatible with legacy licenses based on VM-Series
Models and security service bundles.

• VM-Series firewalls on PAN-OS version 10.0.4 and later—Flexible number of vCPUs (from 1-32) and flexible
selection of security services. You modify the deployment profile in order to add or decrease the number of vCPUs or
add new services as they become available.

If you stop using a firewall, a security service, or a Panorama deployment, the credits that were allocated to that resource are
refunded to the credit pool and you can reallocate them to a new resource.

You license VM-Series firewalls like a traditionally deployed appliance and apply a license authorization code. The license
authorization code maps the firewall to the deployment profile you created. After you apply the code to the device, the
device registers with the Palo Alto Networks support portal and obtains information about its capacity and subscriptions.
Subscription licenses include Threat Prevention, URL Filtering, GlobalProtect, WildFire, Enterprise Data Loss Prevention, DNS
Security, IoT Security, Intelligent Traffic Offload, and SD-WAN.

Palo Alto Networks 24

 Palo Alto Networks Design Details

VM-SERIES FIREWALL INTEGRATION TO AZURE

Launching a VM-Series Firewall on Azure

The Microsoft Azure Marketplace provides a wide variety of Linux, Windows, and specialized machine images, like a Palo
Alto Networks VM-Series firewall. There, you can find Palo Alto Networks VM-Series firewall with various licensing options.
After you select one, the product launch workflow provides a step-by-step guided workflow for all IP addressing, network
settings, and storage requirements.

You can also deploy VM-Series firewalls in Azure Resource Manager through templates. Predefined VM-Series templates
are available through Azure Marketplace and code repositories such as GitHub. The templates available in the marketplace
default to three interfaces (management, private, and public) and allow you to define settings including the administrator
information, resource group, virtual network, subnet, virtual machine size, and VM-Series software version. You can add
additional interfaces to the virtual machine through the CLI after deployment.

Bootstrapping
At deployment, VM-Series firewalls have the factory default configuration and a base software image that varies based on
which deployment method you have chosen. You can manually upgrade the software and update the configuration after
deploying the virtual machine, or you can use bootstrapping to license (if using BYOL), configure, and update the firewall
software at boot time. Bootstrapping allows you to create a repeatable process of deploying VM-Series firewalls. You can
bootstrap the VM-Series firewall with a basic configuration or a complete configuration.

You can use custom data in Azure to bootstrap a VM-Series with a basic configuration. A basic configuration includes just
enough information to get the firewall operational and connected to Panorama or Strata Cloud Manager. When the firewall is
registered and licensed, the additional configuration (required to make the firewall operational) downloads.

You bootstrap a complete configuration through a bootstrap package. The package can contain everything required to make
the firewall ready for production or just enough information to get the firewall operational and connected to Panorama or
Strata Cloud Manager. In Azure, you implement the bootstrap package through an Azure file share that contains directories
for configuration, content, license, and software. On the first boot, VM-Series firewalls mount the file share and use the
information in the directories to configure and upgrade the firewall. After the firewall is out of the factory default state, it stops
looking for a bootstrap package.

One of the fundamental design differences between traditional and public-cloud deployments is the lifetime of resources.
One method of achieving resiliency in public cloud deployments is through the quick deployment of new resources and quick
destruction of failed resources. One of the requirements for achieving quick resource build-out and tear-down is current and
readily available configuration information for the resource to use during initial deployment. When the configuration is static,
the simplest method of achieving this for VM-Series firewalls is to use bootstrapping to configure the firewall policies during
firewall deployment.

Palo Alto Networks 25

 Palo Alto Networks Design Details

Management Interface
The firewall's management interface is the first interface attached to the virtual machine (eth0). By default, the firewall uses
the management interface to access external services, such as DNS, external authentication servers, Palo Alto Networks
licensing, and cloud-delivered security services. Administrators can also reach the management interface remotely, allowing
them to access the firewall from any location for local management or troubleshooting.

To enable the firewall to reach external services on the internet, you must either associate a public IP with the instance
management interface or allow outbound access through an Azure NAT gateway. If you associate a public IP with the
instance, the management interface will be reachable from the internet. The management interface will remain private if you
use Azure NAT Gateway.

Effective control over administrative access to network devices is foundational to the security of any network system. You can
use multiple ways to connect to the management interface within the overall network architecture. Regardless of the access
method, you must configure the network security group attached to the management interface to allow only the IP addresses
and ports required for administrative and troubleshooting purposes. Network security group rules should restrict management
access from the internet or other untrusted zones inside your enterprise security boundary.

A network security group protects new devices immediately, especially during bootstrap, before a complete configuration
is deployed. A network security group also gives you the flexibility to modify management reachability. In the event that you
need temporary remote administrative access, the network security group can be quickly modified to include specific IP
addresses and reverted when complete.

For best-practice guidance for planning and securing your management network, see the
Administrative Access Best Practices TechDocs page.

Routing and Network Security Groups

Each Azure VNet supports multiple IP address ranges, which you can further divide into smaller subnets. Although you can
use a single large IP address range for the whole VNet, configuring different ranges can simplify the traffic forwarding and
network security group configuration. Consider using three separate IP address ranges: one each for the management
network, public network, and private network.

You must attach all of a firewall's interfaces to subnets within the same VNet.

Palo Alto Networks 26

 Palo Alto Networks Design Details

Figure 9 Virtual network IP address ranges and subnets

Although the next-generation firewall supports several network configurations such as virtual wire, Layer 2 and tap mode,
on Azure, VM-Series firewall interfaces are always configurated as Layer 3. In a Layer 3 deployment, each interface receives
an IP address. In Azure, you should always configure VM-Series firewall interfaces to obtain their IP address through DHCP.
Because user-defined route tables require a statically defined next-hop IP address, you should configure the firewall’s virtual
machine interfaces with static IP addresses in the Azure portal or template. The firewall continues to receive its IP address
through DHCP, even when you configure a static IP.

Typical operation for a VM-Series firewall interface is to obtain a default gateway from DHCP and install the route in the
routing table. When deployed in Azure the VM-Series only receives a DHCP default route on the first interface, which is the
management interface. To ensure proper traffic flow, you should modify the public and private firewall interface configurations
to ignore the default routes received via DHCP and manually configure a static default route entry in the routing table. To allow
the firewall to reach virtual machines and services within the VNet, set up additional static routes to the internal subnets on
the firewall’s private interface. Even though Azure networking leverages an overlay network and direct communication, you
still configure the route entry next hop as if the network has a default gateway. Azure reserves the first address in the subnet
(example: .1 in a /24) as the subnet’s default router address.

Figure 10 Firewall IP routing

Traffic within the VNet

You stop traffic from flowing directly to the internet, between VNets, or between devices in the same VNet create by creating
user defined routes to direct traffic to the VM-Series firewall and applying route tables to subnets to invoke the routing policy.
To enforce consistent security for all subnets in the VNet, each subnet must have a user-defined route table applied.

Palo Alto Networks 27

 Palo Alto Networks Design Details

At the minimum, you need user-defined route tables that direct traffic to the firewall for the following:

• The subnet attached to the firewall’s private interface should have a user-defined route table that directs all traffic
destined to the internet and public networks to the firewall’s private IP address.

• For any additional private subnets, the route tables should contain a default route which directs all traffic (destined to
the internet, to the private network range, and the public network range) to the firewall’s private interface IP address.

If you do not want the firewall in the middle of all east-west traffic between private subnets,
add routes only for the private subnets you want to protect. Do not use a summary route
that includes multiple private subnets. The summary route can have the unintended
consequence of enforcing a security policy on traffic within the subnet (host to host).

In addition to the directing the traffic flows using user defined routes, you should also configure network security groups to
control traffic entering and exiting a subnet. A network security group applied to the public subnet should permit inbound
internet traffic and deny any traffic destined for the other subnets in the transit VNet. Similar to the public subnet a network
security group applied to the management subnet should allow only management traffic from internal or external trusted
source addresses. The network security group applied to the private subnet and any application subnets should be
configured to allow all necessary application traffic flows to and from the firewalls.

Traffic between Peered VNets

When you use VNet peering to attach multiple VNets, only minor adjustments are required. To ensure that the firewall can
reach virtual machines and services in a peered VNet, you configure static routes to the peered VNet networks on the
firewall’s private interface with a next hop of the private subnet default router.

Figure 11 Firewall IP routing with peered VNets

You use a similar user-defined route scheme for the private subnet and all subnets in the peered VNets:

• The subnet attached to the firewall’s private interface should have a user-defined route table that directs all traffic
destined to the internet and public networks to the firewall’s private IP address.

• For every subnet in the peered VNet, the route tables should contain a default route that directs all traffic (destined to
the internet, to the private network range, and the public network range) to the firewall’s private interface IP address.

Palo Alto Networks 28

 Palo Alto Networks Design Details

The network security group configuration is also the same for peered VNets, with the only exception being the location where
you apply the application network security groups, which is now in the peered VNet subnets. Keep in mind that, for ease of
management, a single network security group with a common policy can be associated with multiple subnets.

Traffic Flows

Outbound

Traffic that originates from a virtual machine on a private subnet and is destined to the internet routes to the firewall through
the user-defined route table applied to the virtual machine's subnet.

For virtual machines behind the firewall to communicate to devices on the internet, the firewall must translate the source IP
address of the outbound traffic to an IP address on the public subnet. Azure then translates the source IP address again as
the outbound traffic leaves the VNet. When you associate a public IP address with an internal IP address used in the NAT
policy, Azure translates the outbound traffic to the public IP address.

The default behavior for Azure networking with outbound traffic is to use NAT to translate
the source address to an automatically designated public IP address. If your virtual machine
has an interface with an associated public IP address or has an interface that is a member
of a load balancer or application gateway backend pool, then the default behavior does not
apply.
In all cases where the default behavior does not apply, then you must associate an Azure
public IP address to the firewall's outbound interface.

The IP address used in the NAT policy can either be the public interface IP address or any other IP address on the public
subnet. When using non-interface IP addresses, ensure that there aren’t any IP address conflicts by statically assigning all IP
addresses used in the NAT policy as secondary IP addresses on the firewall’s virtual machine public interface.

Figure 12 Outbound IP address translation

In large-scale deployments, you can provide outbound access through a peered VNet, commonly referred to as a transit
VNet. This topology is similar to a hub-and-spoke design, with the transit VNet performing the hub role and the application
VNets as spokes. You share the firewall resources in the transit VNet across all of the application VNets.

Palo Alto Networks 29

 Palo Alto Networks Design Details

Figure 13 Outbound access with transit VNet

East-West in the Same VNet

Traffic that originates from a virtual machine within a private subnet and is destined to a virtual machine in a different private
subnet in the same VNet routes to the firewall through a user-defined route table applied to the virtual machine's subnet.
Virtual machines that can communicate to each other without the need for a firewall to protect the traffic can be on the
same subnet, and virtual machines that need traffic protection should be on different subnets. Because both ends of the
communication are within the VNet, the firewall should not apply a NAT policy to traffic between private subnets.

Figure 14 Traffic flow between private subnets in the same VNet

Because you use a UDR to forward traffic, traffic between private subnets ingresses and egresses the firewall on the same
interface and is assigned the same zone. To permit only limited traffic between private subnets, you must create a rule above
the default intrazone security policy rule. You should then modify the default intrazone security policy to deny traffic, because
it allows all traffic within a zone by default.

Palo Alto Networks 30

 Palo Alto Networks Design Details

To help with troubleshooting, consider modifying the default intrazone security policy to log
traffic.

East-West in Different VNets

Traffic that originates from a virtual machine within a private subnet in one VNet and is destined to a virtual machine in
different private subnet in a different VNet routes to the firewall through a user-defined route table applied to the virtual
machine's subnet. Because both ends of the communication are within peered VNets, the firewall should not apply a NAT
policy to traffic between private subnets.

Figure 15 Traffic flow between private subnets in different VNets

Because you use a UDR to forward traffic, traffic between private subnets in different VNets ingresses and egresses the
firewall on the same interface and is assigned the same zone. To permit only limited traffic between private subnets, you must
create a rule above the default intrazone security policy rule. You should then modify the default intrazone security policy to
deny traffic, because it allows all traffic within a zone by default.

Inbound

To provide communication between a client on the internet and a resource behind the firewall, you must associate a public IP
address with the resource. Although it is possible to associate public IP addresses directly with virtual machines in the private
subnets, for the firewall to be able to protect the private resources, you must associate the public IP address with the firewall.
The firewall then translates the destination IP address to the appropriate private resource.

Because Azure networking translates the destination IP address from the public IP address to the internal IP address when
the traffic enters the VNet, you must use internal IP addresses in the firewall’s security and NAT policies. Although you can
associate a public IP address to the primary internal IP address on the virtual machine's public interface, deploying this way

Palo Alto Networks 31

 Palo Alto Networks Design Details

requires port translation to support multiple private resources. To avoid port translation, you can have multiple secondary IP
addresses assigned to the firewall’s virtual machine public interface, one for each public IP address you associate with the
firewall.

Figure 16 Inbound IP address translation

Enterprise Network Connectivity

Delivered by Palo Alto Networks as a cloud-native service, Prisma Access is a complete security service for your mobile and
remote-site users. For both mobile users and remote sites, Prisma Access provides secure access to internet and business
applications, whether those applications are hosted in a corporate data center or a public cloud service provider.

Corporate and public-cloud data centers use VPN-capable devices, such as a firewall or a cloud-provider VPN service, to
connect to Prisma Access over the internet. Direct connectivity allows mobile and remote-site users to reach applications and
resources deployed in any of your enterprise-wide data centers and allows the network and system administrators to reach
instances and platforms that do not have public IP access.

Figure 17 Prisma Access

Palo Alto Networks 32

 Palo Alto Networks Design Details

To provide secure access your applications and resources in Azure, you create a Prisma Access service connection to the
Azure Virtual Network Gateway. In either scenario, you have the option of running a dynamic routing protocol (BGP) over the
tunnel or using static routes.

The preferred design uses a service connection between your Prisma Access instance and the Azure VNG service. With
this design, the VM-Series firewalls can inspect and control all VPN traffic but do not terminate the VPN tunnels. Traffic that
originates from Prisma Access and is destined to an application or workload in an application or management VNet routes to
the VM-Series firewall through a custom UDR.

The virtual network gateway connects enterprise networks to the Azure virtual network. You deploy the VNG in a dedicated
gateway subnet. In Azure, you define the IP address ranges that route to the enterprise networks when you configure a
connection between the virtual network gateway and Prisma Access from the enterprise networks side, or Azure can learn
them through the BGP routing protocol. By default, all resources within the VNet can communicate with the enterprise
network ranges. Azure automatically creates system routes to the enterprise network ranges during the deployment of the
virtual network gateway and when dynamically learned. The system routes for the enterprise network ranges have a next hop
of virtual network gateway.

You create a route table for the gateway subnet to direct traffic that is destined to the private subnets to the firewall. If you
want to manage the firewalls from your enterprise network, you can also route traffic to the management subnet directly
through the virtual network.

Because you must override each enterprise network range in the route table, you
should summarize the network ranges as much as possible. This reduces the amount of
configuration required.

Figure 18 Enterprise traffic using VNG in peered VNets

Palo Alto Networks 33

 Palo Alto Networks Design Details

When you are using the VNG for connectivity to enterprise networks, Azure automatically creates system routes for every
network prefix that is configured or learned. The user-defined route configuration for enterprise network ranges must include
discard routes with a destination of none applied to subnets in the public range to override the system routes. Managing the
list of user-defined discard routes becomes cumbersome when the number of enterprise network system routes increases.
If you enable BGP dynamic routing for your VNG, then you can disable automatic system route propagation for individual
subnets instead of creating discard routes.

If the transit VNet is used for outbound traffic to the internet, then a user-defined route that matches internet destinations is
already applied. This user-defined route might also be sufficient to direct traffic to the enterprise networks, as well. If not, then
subnets in the private range might require an additional user-defined route to the transit VNet.

Resiliency
Traditionally, you achieve firewall resiliency through a high availability (HA) configuration on the firewall. In a high availability
configuration, a pair of firewalls shares configuration and state information that allows the second firewall to take over for the
first if a failure occurs. Although you can configure high availability so that both firewalls are passing traffic, in the majority of
deployments, the firewalls operate as an active/passive pair where only one firewall is passing traffic at a time.

Unlike traditional implementations, this architecture achieves VM-Series resiliency in Azure through the use of native public
cloud services. The benefits of configuring resiliency through native public cloud services instead of firewall high availability are
faster failover and the ability to scale out the firewalls as needed. However, in a public cloud resiliency model, configuration
and state information is not shared between firewalls. Applications typically deployed in public cloud infrastructure, such as
web- and service-oriented architectures, do not rely on the network infrastructure to track session state. Instead, they track
session data within the application infrastructure, which allows the application to scale out and be resilient independent of the
network infrastructure.

For information about high availability in VM-Series on Azure, see the TechDocs topic Set Up
Active/Passive HA on Azure.

The Azure resources and services used to achieve resiliency for the firewall include:

• Availability sets—Ensure that a failure or maintenance event in Azure does not affect all VM-Series firewalls at the
same time.

• Load balancers—Distribute traffic across two or more independent firewalls that are members of a common
availability set. Every firewall in the load balancer’s pool of resources actively passes traffic, allowing firewall capacity
to scale out as required. The load balancer monitors the availability of the firewalls through TCP or HTTP probes and
updates the pool of resources as necessary.

Azure Load Balancer is available in both a Basic and Standard SKU. The Standard SKU
load balancer has an expanded feature set and increased scale and is the recommended
resource for this architecture guide.

Palo Alto Networks 34

 Palo Alto Networks Design Details

• Multiple application gateway instances—Distribute traffic across two or more independent firewalls that are
members of a common availability set. Every firewall in the application gateway’s pool of resources actively passes
traffic, allowing firewall capacity to scale out as required. The application gateway monitors the availability of the web
server backend resources through HTTP/HTTPS probes and updates the pool of resources as necessary.

Another way that firewall resiliency in Azure differs from traditional firewall high availability is that in Azure you do not
implement firewall resiliency at a device level. Instead, you implement firewall resiliency based on the direction of the traffic.
For example, it is possible to configure firewall resiliency for inbound traffic from the internet and its return traffic, but not for
outbound traffic originating from private virtual machines. In fact, the resiliency for inbound traffic differs from that of outbound
and east–west traffic.

Outbound, East-West, and Enterprise Traffic

You implement resiliency for traffic that originates inside the VNet (outbound to the internet, east-west traffic between
subnets, and enterprise networks) by using Azure user-defined routes and internal load balancers. Internal load balancers
have a frontend defined by one or more internal IP addresses and a backend pool defined by the private interfaces of the
firewalls.

To get internal traffic to the resilient firewalls, Azure user-defined routes direct traffic to the load balancer’s internal IP address.
To best support UDR, you should associate the load balancer’s internal IP addresses with the subnet that contains the
firewalls' private interfaces, and you should assign a static IP address.

All traffic that matches the user-defined route forwards to the load balancer. The Azure Standard Load Balancer with the HA
ports feature supports a more effective deployment option than the Azure Basic Load Balancer. HA ports rules simplify the
load-balancer configuration by supporting traffic on all TCP/UDP ports with a single rule.

When you use a single load balancer to provide resiliency for outbound, east-west, and enterprise traffic, the load-balancer
rules required to support one traffic profile might be too permissive for another. If this becomes an issue, you can use firewall
security policies to limit applications, or you can divide the different traffic profiles across additional frontend IP addresses
mapped to the backend pool.

Internal load balancers do not translate the source or destination IP address of the traffic, and floating IP is not necessary. In
most designs, the firewall does not need to translate the destination IP address. If the destination traffic is within the Azure
VNet, then the load balancer maintains session state to ensure that return traffic to the resource enters through the firewall
that processed the outgoing traffic. If the same frontend and backend pool of the load balancer see both directions of the
traffic flow, the load balancer maintains the session state. For destinations outside the VNet, the firewall must translate the
source IP address to the IP address of the egress interface. Without this source NAT, routing might send the return traffic to a
different firewall.

When east-west traffic between subnets traverses the firewall, both the incoming and
outgoing traffic is on the same interface and assigned to the same zone. You must create
a rule above the default intrazone security policy rule. You should then modify the default
intrazone security policy to deny traffic, because it allows all traffic within a zone by default.

Palo Alto Networks 35

 Palo Alto Networks Design Details

Figure 19 Standard SKU internal load-balancer traffic flow

Inbound Traffic

You implement resiliency for inbound internet traffic through the use of an Azure public load balancer or an Azure Application
Gateway.

Resiliency for Inbound Traffic with Azure Public Load Balancers

Public load balancers have one or more public IP addresses configured on the frontend and have a backend resource pool
associated to the public interfaces of the firewalls. Load-balancing rules direct traffic to the firewalls based on the destination
IP address and TCP or UDP port numbers. By default, the load balancer translates the destination IP address to the public
interface IP address of the firewall selected from the backend pool.

To get the traffic to a resource in the private zone, a NAT policy rule on the firewall must translate the destination IP address
from its public interface IP address to the resource IP address. To ensure traffic symmetry, or that return traffic from the
resource leaves through the firewall that processed the incoming traffic, the firewall must also translate the source IP address
to the IP address of its private interface. Without this source NAT, Azure uses routing to select the path out of the VNet.

Palo Alto Networks 36

 Palo Alto Networks Design Details

Figure 20 Public load-balancer traffic flow

Although you can use an interface in the source NAT configuration, NAT policy rules cannot
use an interface to define destination IP address match criteria.
Statically defining the firewall interface IP addresses in Azure is important to ensure that the
NAT policy rule stays valid through virtual machine reboots.

There are a few operational limitations when using the default load-balancer behavior. The first limitation is that, to support
multiple applications with the same destination port number, you must use port translation. This requirement stems from the
fact that each firewall in the backend pool is limited to one IP address. There is no differentiation in destination IP address
even when there are multiple frontend IP addresses receiving traffic. So, although the load balancer can receive traffic on two
different public IP addresses listening on the same TCP port, it cannot forward that traffic to a common set of firewalls without
translating the destination port. Load-balancing rules that share a backend pool must have different backend ports.

To support multiple applications while using the load balancer’s default behavior, the firewall NAT policy rules must use
the service (TCP port number) as part of the traffic match and translate the destination port to what the private resources
expect. You should also configure the service for security policy rules to include the specific service ports in use instead of
application-default.

Palo Alto Networks 37

 Palo Alto Networks Design Details

Figure 21 Public load balancer with multiple applications

The second operational limitation of the default Azure load-balancer behavior relates to health probes. Health probes
determine the health of the firewalls in the backend pool. The load balancer sends health probes to the IP address defined in
the backend pool, in this case, the primary internal IP address of the firewall’s public interface. Although you can configure the
health probes to monitor the full path to the private resources (because the firewall NAT and security policies use the public
interface IP address), directly monitoring the health of the firewalls might be preferable in designs where the health probe ends
up monitoring the same resource through multiple firewalls.

Because a TCP probe only expects an ACK, the simplest method of determining firewall health is to enable an interface
management profile on the firewall interface that permits access to the HTTPS service from the Azure health probe.

Azure always sources health probes from an IP address of [Link].

However, because the load balancer uses the firewall’s public IP address as the destination for traffic as well as the health
probes, you need to take care to ensure the services configured in the interface management profile don’t overlap with the
traffic sent to the firewall from the load balancer. For example, if the load balancer is sending HTTP traffic to the firewall, HTTP
should not be enabled in the interface management profile.

Palo Alto Networks 38

 Palo Alto Networks Design Details

Figure 22 Load-balancer health probes

If you want to avoid the operational limitations of the default load-balancer behavior, you can configure the load balancer to
use floating IP in the rule configuration. When set to use floating IP, the load balancer does not translate the destination IP
address before sending the traffic to resources in the backend pool.

To get the traffic to a resource in the private zone, a NAT policy rule on the firewall must translate the destination IP address
from the public IP address assigned to the load balancer to the private resource IP address. When using dynamic public
IP address assignment, use FQDN address objects in the firewall NAT and security policies. FQDN address objects resolve
hostnames to IP addresses on firewall boot up and periodically after that to keep firewall policies current.

Supporting multiple applications that use the same destination port number no longer poses an issue when using floating IP
because the firewall can use the unique destination IP address to differentiate applications. Also, when you use floating IP,
there won’t be any overlap between the services defined in the interface management profile and the services defined in the
firewall policies.

Figure 23 Traffic flow with floating IP

Palo Alto Networks 39

 Palo Alto Networks Design Details

Finally, beyond removing operational limitations, floating IP allows for simplified firewall configuration. Floating IP removes
firewall interface IP addresses from the policies and replaces it with IP addresses that are consistent across all devices. This
allows for consistent policies across firewalls.

Resiliency for Inbound Traffic with Azure Application Gateway

The application gateway requires that you deploy it in a dedicated subnet. You must create a new subnet in the public
network range that you use for the application gateway. You cannot deploy other resource types in this subnet.

Figure 24 Virtual network IP address ranges and subnets with application gateway

Application gateways used for inbound traffic have one or more frontends, each associated to a public IP address. You
can assign multiple FQDNs to a public IP address, and you can use information in the URL in the application gateway's
forwarding rules. The application gateway uses a backend pool associated to the public interfaces of the firewalls when used
for inbound resiliency. You configure routing rules to associate a frontend with a backend pool.

The application gateway is a proxy device and terminates inbound connections by using listeners. You configure the first
routing rule when you initially deploy the application gateway. The routing rule includes a listener that you configure for HTTP
or HTTPS on a TCP port you select. After the initial deployment, you can create additional routing rules and listeners using
HTTP or HTTPS on other TCP ports. The application gateway initiates backend connections sourced from its own instance
IP addresses in the application gateway subnet. The web server resources in the private zone can be individual servers or
servers configured as the backend pool of a separate internal load balancer.

The application gateway initiates sessions to the backend pool by using its own source IP
addresses (one per instance). The application gateway uses the X-Forwarded-For (XFF)
HTTP header field in order to add the original source IP address of the web client to the
HTTP packet header. The firewall logs the XFF information in addition to other session data
in order to retain information about the original source IP address for each session.

Basic forwarding rules direct traffic to the backend pool based on the port and protocol of the incoming connection
established to the listener and based on the destination port and protocol of the backend resource behind the firewall. Path-
based forwarding rules are similar to the basic forwarding rules but also use regular expression matching within the URL to
direct traffic.

Palo Alto Networks 40

 Palo Alto Networks Design Details

To get the traffic to a resource in the private zone, a NAT policy rule on the firewall must translate the destination address of
any traffic sourced from the application gateway from the firewall's public interface IP address to the backend resource IP
address. The backend resource can be a server or the frontend IP of an internal load balancer. To ensure traffic symmetry, the
firewall must also translate the source IP address to the IP address of its private interface.

Figure 25 Application gateway traffic flow

Health probes for the application gateway determine the health of the actual backend resources. Unlike the Azure load
balancer, the application gateway sources health probes from its IP addresses. You configure the firewall with NAT and
security policies that permit the probes to pass directly to the backend resources. A successful health probe verifies that both
the firewall and the actual backend resource are available.

Figure 26 Application gateway health probes

A limitation of the firewall operation with the application gateway is that the backend pool can only include the public
interfaces of the firewalls and their corresponding IP addresses. To support multiple web server resources behind the firewalls
requires the configuration of destination port NAT policy rules. Each application gateway HTTP or HTTPS backend requires
the assignment of unique TCP port.

Palo Alto Networks 41

 Palo Alto Networks Design Details

Figure 27 Application gateway with single backend pool (firewalls)

The example NAT policy shown in Table 3 requires that you create a new NAT policy rule on each firewall for each HTTP/
HTTPS backend on the application gateway. The example in the table assumes that two firewalls are in the application
gateway backend pool and each table entry lists a pair of rules. However, you configure each firewall with only the specific
NAT policy rules that correspond to its public interface IP address.

Table 3 Example application gateway configuration with destination port NAT

Frontend Path Use Backend Web server resource Firewall destination port NAT policy
listener protocol/port rules

HTTP/80 All Default HTTP/80 Web-1 [Link]:80 > [Link]:80

([Link] [Link]:80 > [Link]:80

HTTP/80 /images/* URL path- HTTP/8081 Web-2 [Link]:8081 > [Link]:80

based routing ([Link] [Link]:8081 > [Link]:80

HTTPS/443 All Re-encrypt HTTPS/443 Web-3 [Link]:443 > [Link]:443

([Link] [Link]:443 > [Link]:443

HTTPS/443 /images/* SSL offload HTTP/8443 Web-2 [Link]:8443 > [Link]:8443

([Link] [Link]:8443 > [Link]:8443

You can also use an internal load balancer as the frontend for the web server resources. With this option, you configure the
NAT policy on the firewall to reference the frontend IP of the load balancer. You configure the internal load balancer with web
server backend pool members and, optionally, to perform destination port-based NAT. A benefit of using the internal load
balancer for NAT is that the web servers can continue to use standard web ports (80/443), and you do not need to configure
the web servers to listen on a non-standard port (8081) unless the same web server resource has multiple usages.

Palo Alto Networks 42

 Palo Alto Networks Design Details

Figure 28 Application gateway with multiple listeners and an internal load balancer

The combination of the firewall NAT policy rules in Table 4 and the internal load balancer rules in Table 5 combines the
capabilities of the firewall-only configuration with an internal load-balancer configuration.

Table 4 Example application gateway configuration with destination NAT to load-balancer frontend

Frontend Path Use Backend Web server Firewall destination NAT policy rule
listener protocol/port resource

HTTP/80 All Default HTTP/80 Web-Pool-1 [Link]:80 > [Link]:80

[Link]:80 > [Link]:80

HTTP/80 /images/* URL path- HTTP/8081 Image-Pool-2 [Link]:8081 >

based routing [Link]:8081
[Link]:8081 >
[Link]:8081

HTTPS/443 All Re-encrypt HTTPS/443 SSL-Pool-3 [Link]:443 > [Link]:443

[Link]:443 > [Link]:443

HTTPS/443 /images/* SSL offload HTTP/8443 Image-Pool-2 [Link]:8443 >

[Link]:8443
[Link]:8443 >
[Link]:8443

Palo Alto Networks 43

 Palo Alto Networks Design Details

Table 5 Example internal load-balancer rules

Frontend IP Use Frontend port Backend pool Pool Backend port

members

[Link] Default TCP/80 Web-Pool-1 [Link] TCP/80

[Link]

[Link] URL path-based TCP/8081 Image-Pool-2 [Link] TCP/80

routing [Link]

[Link] Re-encrypt TCP/443 SSL-Pool-3 [Link] TCP/443

[Link]

[Link] SSL offload TCP/8443 Image-Pool-2 [Link] TCP/8443

[Link]

MANAGEMENT AND LOGGING

Palo Alto Networks Panorama and Strata Cloud Manager provide streamlined management, control, and oversight of firewalls
deployed across an enterprise network.

• Panorama is a centralized security-management system that you deploy and manage that allows you to manage your
Palo Alto Networks NGFWs at scale. You can deploy Panorama in your on-premises data center or in a public cloud
environment such as Azure.

• Strata Cloud Manager is an AI-powered, unified management and operations platform that Palo Alto Networks offers
as a SaaS service and hosts in the cloud. Strata Cloud Manager allows you to manage and monitor your NGFW and
SASE infrastructure from a single streamlined user interface.

Panorama
Panorama includes a variety of tools designed to enhance network security by streamlining the management of both physical
and virtual firewalls. These tools include configuration templates, device grouping, role-based access control (RBAC), log
collection, dynamic updates, monitoring, reporting, and analytics.

Panorama offers administrators consistent policy enforcement, easy deployment of configurations, and updates to
multiple firewalls and sites. Panorama enhances operational efficiency through automation, reduces complexity by unifying
management tasks, and offers detailed logging and reporting features that aid in quick response to threats, compliance
management, and forensic analysis.

Templates and Template Stacks

Panorama manages common building blocks for device and network configuration through templates. You can use templates
to centrally manage device configuration and then push the changes to selected firewalls. This approach prevents you from
having to making the same configuration change repeatedly across many firewalls. Adding multiple templates to a template
stack logically combines them. If there are no overlapping parameters, then the stack reflects the combination of all the

Palo Alto Networks 44

 Palo Alto Networks Design Details

individual templates. If there is overlap, then the settings from the highest-priority template take precedence. You can override
the template settings at the stack level, or if necessary, a local firewall administrator can perform overrides directly on an
individual firewall.

Firewall-specific settings such as IP addresses must be unique per device. Instead of using overrides, you can manage these
settings by using configuration variables within templates. Panorama manages the variable assignments at deployment time,
either on a per-device basis through manual assignment or in bulk by an imported spreadsheet containing the configuration
settings for multiple devices.

Figure 29 Panorama template stack and templates

Device Groups

Panorama manages common policies and objects through device groups. You use hierarchical device groups to centrally
manage policy and object configuration across all deployment locations that have a common set of requirements. For
example, you can create device groups using a geographical structure, such as Europe and North America. Also, each
device group can have a functional sub-device group (for example, perimeter or data center).

Palo Alto Networks 45

 Palo Alto Networks Design Details

Figure 30 Panorama device groups and policy evaluation

You can define shared policies for central control while granting your local firewall administrator the autonomy to make
specific local adjustments. At the device group level, you create common policies that are defined as the first set of rules (pre-
rules) and the last set of rules (post-rules) to be evaluated against match criteria. You can view pre-rules and post-rules on a
managed firewall, but you can edit them only in Panorama in the context of the defined administrative roles. Your local firewall
administrator or a Panorama administrator who has switched to a local firewall context can edit local device rules (those
between pre-rules and post-rules). In addition, in locally-managed device rules, you can reference shared objects defined by
a Panorama administrator.

Logging Options

Beyond management, you need to consider your firewall log collection and retention. Log collection, storage, and analysis
is an important cybersecurity best practice that organizations perform to correlate potential threats and prevent successful
cyber breaches.

The following three deployment mode options are available for Panorama which, if necessary, allows for the separation of
management and log collection:

• Log Collector mode—One or more log collectors collect and manage logs from the managed devices. This assumes
that another Panorama deployment is operating in Management-Only mode.

• Management-Only mode—Panorama manages configurations for the managed devices but does not collect or
manage logs.

• Panorama mode—Panorama controls both policy and log management functions for all the managed devices.

Palo Alto Networks 46

 Palo Alto Networks Design Details

On-Premises Panorama with Dedicated Log Collectors in the Cloud

Sending logging data to the on-premises Panorama can be inefficient and costly, and can pose data privacy and residency
issues in some regions. An alternative to sending the logging data back to your on-premises Panorama is to deploy
Panorama dedicated log collectors on Azure and to use the on-premises Panorama for management. Deploying a dedicated
log collector on Azure reduces the amount of logging data that leaves the cloud but still allows your on-premises Panorama
to manage the VM-Series firewalls in Azure and have full visibility to the logs as needed.

Figure 31 Panorama Log Collector mode on Azure

Panorama Management on Azure with Strata Logging Service

In the first of the two design options when you deploy Panorama management on Azure, you use Panorama for management
only and use Strata Logging Service (formerly Cortex® Data Lake) to store the logs generated by the VM-Series firewalls.
Strata Logging Service (SLS) emulates a traditional log collector.

About Strata Logging Service

SLS is a cloud-based log collector service that provides resilient storage and fast search capabilities for large amounts of
logging data. The VM-Series firewalls encrypt the logs and then send them to SLS over TLS/SSL connections. SLS allows
you to scale your logging storage as your Azure deployment scales, because licensing is based on storage capacity and not
the number of devices sending log data.

The benefit of using SLS goes well beyond scale and convenience when you also use the Palo Alto Networks Cortex AI-
based continuous security platform. Cortex is a scalable ecosystem of security applications that can apply advanced
analytics in concert with Palo Alto Networks enforcement points in order to prevent the most advanced attacks. Palo Alto
Networks analytics applications, such as Cortex XDR® and AutoFocus®, use SLS as the primary data repository for all Palo
Alto Networks offerings. Third-party analytics applications that you can choose also use SLS.

Palo Alto Networks 47

 Palo Alto Networks Design Details

Figure 32 Panorama management and Strata Logging Service

Panorama Management and Log Collection in the Cloud

In the second design option, you can use Panorama for both management and log collection. You can deploy the
management and log collection functionality as a shared virtual appliance or on dedicated virtual appliances. For smaller
deployments, you can deploy Panorama and the log collector as a single virtual appliance. For larger deployments, a
dedicated log collector per region allows traffic to stay within the region and reduce outbound data transfers.

Figure 33 Panorama management and log collection in Azure

Panorama is available as a virtual appliance for deployment on Azure and supports Management-Only mode, Panorama
mode, and Log Collector mode. Panorama on Azure is only available using a BYOL licensing model.

Resource Monitoring

Organizations typically build public-cloud application environments by using a continuous integration/continuous delivery
(CI/CD) pipeline. Using CI/CD, you deploy applications and updates quickly and build new infrastructure to accommodate
a revised application, as opposed to trying to upgrade the existing operational environment. When the new application or
update goes online, you remove the now-unused, older application environment. This amount of change presents a challenge
to enforcing security policy unless your security platform is compatible with an agile development and deployment process.

Palo Alto Networks firewalls, including the VM-Series, support dynamic address groups (DAGs). DAGS allow you to create
security policy that automatically adapts to compute resource additions, moves, or deletions. DAGs also enable the
operational flexibility for applying a security policy to a device based on its role.

Palo Alto Networks 48

 Palo Alto Networks Design Details

A dynamic address group uses tags as a filtering criterion in order to determine its members. You can define tags statically
or register them dynamically. You can dynamically register the IP address and associated tags for Azure virtual machines by
using the Azure plugin.

Figure 34 VM monitoring of Azure tag to dynamic address group mappings

When using Panorama and the Azure plugin, you can centralize the retrieval of tags from Azure and security policy
management in order to ensure consistent policies for hybrid and cloud-native architectures. Using a service principal with a
built-in or custom role that you create, the plugin polls your Azure subscriptions for resource tags and correlates the metadata
(IP address-to-tag mapping) into dynamic address groups. Panorama then relays the dynamic address group content to the
VM-Series firewalls, providing scale and flexibility.

The Panorama plugin for Azure allows you to monitor all your virtual machines, VNets, application gateways, and load-
balancers in up to 500 Azure subscriptions. With the plugin, Panorama can retrieve a total of 32 tags for each virtual machine:
11 predefined tags and up to 21 user-defined tags. The number of tags used impacts the total number of IP addresses
you can monitor. For example, Panorama can retrieve 7,000 IP addresses with 10 tags for each, or it can retrieve 6500 IP
addresses with 15 tags for each.

Strata Cloud Manager

Palo Alto Networks Strata Cloud Manager provides unified management across an organizations' entire Palo Alto Networks
Network Security infrastructure, both NGFWs and SASE environment, from a single, centralized user interface.

Strata Cloud Manager consolidates a variety of tools designed to streamline the management of both physical and virtual
firewalls to enhance network security. These include a hierarchical folder structure for configuration and policy, actionable
insights through several dashboards, and easy troubleshooting and problem resolution..

Strata Cloud Manager offers administrators consistent policy enforcement, easy deployment of configurations, and updates
to multiple firewalls and sites. Strata Cloud Manager identifies deployed security capabilities, and guides administrators
to enable additional features based on the best practices to strengthen your security posture. Strata Cloud Manager also
enhances operational efficiency through automation and reduces complexity by unifying management tasks. Many of the
available dashboards support scheduled report generation which show current operational states and can easily be share
with stakeholders.

Palo Alto Networks 49

 Palo Alto Networks Design Details

Folders and Snippets

Strata Cloud Manager includes a pre-defined folder structure where you can apply configuration settings and enforce policy
globally across your entire environment, or specifically target certain devices and services within your organization. The pre-
defined structure has at its root the Global folder. Settings at the Global level apply across all your network traffic.

Within the Global folder are the following folders:

• Prisma Access—Settings at this level apply across all your Prisma Access deployment.

Mobile Users Container—Settings apply across all mobile user connection types (GlobalProtect and Explicit
Proxy) or individually to each connection type.

Remote Networks—Settings apply to remote network sites (branch offices, retail locations, etc.).

Service Connections—Settings apply to service connection sites (HQ and data centers).

• All Firewalls—Settings apply across all your NGFWs. You create specific folders under this level to group together
NGFWs that require shared or specific configuration settings or policy enforcement.

In addition to creating configuration at the folder level, Strata Cloud Manager provides an additional method to apply
configuration to firewalls or deployments. A snippet is a configuration object, or a set of objects, that you can associate with
a folder, deployment, or device. You can use snippets to standardize a common base configuration for a set of firewalls. For
example, you onboard a new firewall in a CSP or a remote branch. You can associate a set of snippets that contain all the
required network and policy configurations with the folder the new firewall belongs to.

In the event of conflicting values, snippet associations have a top-down priority. This means that if the first and the last
associated snippets have different values for the same object, the value from the first snippet is inherited by the device or
deployment. Additionally, you can override at the child folder, deployment, or device level all configurations inherited from a
snippet.

Figure 35 Strata Cloud Manager folder structure

Palo Alto Networks 50

 Palo Alto Networks Design Details

Variables give you the flexibility to accommodate unique configuration values that are device specific or deployment specific.
You use variables in your standardized configurations to accommodate device-specific or deployment-specific configuration
objects. You can create variables at the folder, deployment, or firewall level. When you create a variable at a folder level, the
variable is inherited by all folders nested under the folder. In the event of conflicting variables throughout the folder structure,
the firewall or deployment inherits the variable value from the folder containing the nested folders. However, you can override
an inherited variable at the nested folder, deployment, or firewall level.

Strata Logging Service

Strata Cloud Manager uses SLS to store the logs generated by the VM-Series firewalls. Figure 36 shows how Strata Cloud
Manager and SLS connect.

Figure 36 Strata Cloud Manager with Strata Logging Service

PRISMA CLOUD FOR AZURE

Prisma Cloud is a cloud infrastructure security solution that provides complete visibility and control over risks within your
public-cloud infrastructure. To help ensure that your cloud infrastructure is protected from security threats, this service
continuously monitors your cloud environments.

Prisma Cloud provides cloud infrastructure protection across the following areas:

• Multi-cloud security—Achieve consistent implementation of security best practices across Azure, AWS, and GCP.
Prisma Cloud requires no agents, proxies, software, or hardware for deployment and integrates with a variety of threat
intelligence feeds. Prisma Cloud includes pre-packaged policies for securing multiple public-cloud environments.

• Continuous compliance—Maintain continuous compliance across CIS, NIST, PCI, FedRAMP, GDPR, ISO and SOC
2 standards by monitoring API-connected cloud resources across multiple cloud environments in real time. Prisma
Cloud can generate compliance documentation with one-click exportable, fully prepared reports.

Palo Alto Networks 51

 Palo Alto Networks Design Details

• Cloud forensics—Go back in time to the moment a resource was first created and see when every change was
made chronologically and by whom. Prisma Cloud provides forensic investigation and auditing capabilities of
potentially compromised resources across your Azure environment, as well as other public-cloud environments.
Historical information extends back to initial creation of each resource, and the detailed change records includes who
made each change.

• DevOps and automation—By setting architecture standards that provide prescribed policy guardrails, you enable
secure DevOps without adding friction. This methodology permits agile development teams to maintain their focus on
developing and deploying apps that support business requirements.

To analyze and produce concise actionable insights, Prisma Cloud connects to your cloud via APIs and aggregates raw
configuration data, user activities, and network traffic. Azure integration requires that you create and register an Azure
Application ID with a password-based key and reader permissions to your Azure subscription. Use this Application ID with
the associated key and the Azure Active Directory ID and Azure Subscription ID to connect your cloud to Prisma Cloud.
Additional permissions and configuration are required to ingest and analyze flow logs and collect other data. You perform
these steps manually using Azure Resource Manager, but you can also use a Prisma Cloud onboarding script to automate
the process.

Prisma Cloud performs a five-stage assessment of your cloud workloads. Contributions from each stage progressively
improve the overall security posture for your organization:

• Discovery—Prisma Cloud continuously aggregates configuration, user activity, and network traffic data from disparate
cloud APIs. It automatically discovers new workloads as soon as they are created.

• Contextualization—Prisma Cloud correlates the data and applies machine learning to understand the role and
behavior of each cloud workload.

• Enrichment—External data sources (such as vulnerability scanners, threat intelligence tools, and SIEMs) further enrich
the correlated data.

• Risk assessment—Prisma Cloud scores each cloud workload for risk based on the severity of business risks, policy
violations, and anomalous behavior. Aggregated risk scores enable you to benchmark and compare risk postures
across different departments and across the entire environment.

• Visualization—An interactive dependency map shows the entire cloud infrastructure environment, providing context
beyond the raw data.

Threat Defense
Prisma Cloud enables you to visualize your entire Azure environment, down to every component within the environment. The
platform dynamically discovers cloud resources and applications by continuously correlating configuration, user activity, and
network traffic data. Combining this deep understanding of the Azure environment with data from external sources, such as
threat intelligence feeds and vulnerability scanners, enables Prisma Cloud to produce context around risks.

Prisma Cloud includes policies that adhere to industry-standard best practices right out-of-the-box You can also create
custom policies based on your organization’s specific needs. Prisma Cloud continuously monitors for violations of these
policies by existing resources as well any new resources that are dynamically created. You can easily report on the
compliance posture of your Azure environment to auditors.

Palo Alto Networks 52

 Palo Alto Networks Design Details

Prisma Cloud automatically detects user and entity behavior within the Azure infrastructure and management plane. Prisma
Cloud establishes behavior baselines, and it flags any deviations. It also computes risk scores—similar to credit scores—for
every resource, based on the severity of business risks, violations, and anomalies. The risk score helps you to quickly identify
the riskiest resources and enables you to quantify your overall security posture.

Prisma Cloud reduces investigation-time from weeks or months to seconds. To quickly pinpoint issues and perform upstream
and downstream impact analysis, you can use Prisma Cloud graph analytics. Prisma Cloud provides you with a DVR-like
capability to view time-serialized activity for any given resource. You can review the history of changes for a resource and
better understand the root cause of an incident, past or present.

Prisma Cloud enables you to quickly respond to an issue based on contextual alerts. Alerts are triggered based on risk-
scoring methodology and provide context on all risk factors associated with a resource. This feature makes it simple to
prioritize the most important issues first. When a resource has a high risk score, you can choose to send alerts, orchestrate
policy, or perform auto-remediation. Prisma Cloud can also send alerts to Cortex XSOAR® and third-party tools such as
Slack, Splunk, and ServiceNow so that you can remediate the issue.

Prisma Cloud provides the following visibility, detection, and response capabilities:

• Host and container security—Configuration monitoring and vulnerable image detection.

• Network security—Real-time network visibility and incident investigations. Suspicious/malicious traffic detection.

• User and credential protection—Account and access key compromise detection. Anomalous insider activity
detection. Privileged activity monitoring.

• Configurations and control plane security—Compliance scanning. Storage, snapshots and image configuration
monitoring. Security group and firewall configuration monitoring. IP address management configuration monitoring.

Continuous Monitoring
The dynamic nature of the cloud creates challenges for risk and compliance professionals tasked with measuring and
demonstrating adherence to security and privacy controls. With the Prisma Cloud portal, you can view the collected
continuous security-monitoring data collected by Prisma Cloud and verify compliance of your resources to CIS v1.0, CSA
CCM v3.0.1, GDPR, HIPAA, ISO 27001:2013, NIST 800.53 R4, PCI DSS v3.2, and SOC2 standards. This capability
eliminates the manual component of compliance assessment.

Prisma Cloud provides security and compliance teams with a view into the risks across all their cloud accounts, services, and
regions by automating monitoring, inspection, and assessment of your cloud infrastructure services. With real-time visibility
into the security posture of your environment, you can identify issues that do not comply with your organization’s required
controls and settings and send automated alerts.

Palo Alto Networks 53

 Design Model

Design Model
There are many ways to use the concepts discussed in the previous sections to secure application deployments in Azure.
The options described in this section offer example architectures that secure inbound and outbound traffic flows, traffic
between virtual networks, and the connection to your enterprise networks.

This design model offers options for central management using Panorama or Strata Cloud Manager. If you manage your
deployment using Panorama, you create a separate management VNet to centralize management so that a single Panorama
deployment can manage VM-Series firewalls deployed across all your organization's virtual networks. You deploy Panorama
in Management-Only mode and securely access it through the enterprise network connection or over the public internet.

Bootstrapping speeds up the process of configuring and licensing the VM-Series firewalls and making them operational
on the network. This process allows you to deploy the firewall by using custom data with only a basic configuration. The
custom data provides information to reach Panorama or Strata Cloud Manager and options for template and device group
membership or folder associations. After deployment, the VM-Series connects to Panorama or Strata Cloud Manager and
obtains the complete operational configuration. After they are operational and securing outbound, east-west, and inbound
flows, the VM-Series firewalls encrypt and send all firewall logs to Strata Logging Service over TLS/SSL connections.

Figure 37 Centralized management options

In this model, you allocate the security and application functions and resources across multiple VNets that are connected
in a hub-and-spoke topology. The hub of the topology, or transit VNet, is the central point of connectivity for all inbound,
outbound, east-west, and enterprise traffic. You deploy all VM-Series firewalls within the transit VNet. The spokes contain
application workloads arranged in their own VNets. This model encompasses two different firewall deployment options. The
options presented here differ in how they provide resiliency, scale, and services.

Palo Alto Networks 54

 Design Model

Consider which option best fits your needs and use it as a starting point for your design:

• The dedicated inbound option separates traffic flows across two separate sets of VM-Series firewalls. One set of VM-
Series firewalls is dedicated to inbound traffic flows, allowing for greater flexibility and scaling of inbound traffic loads.
The second set of VM-Series firewalls services all outbound, east-west, and enterprise network traffic flows. This
deployment choice offers increased scale and operational resiliency and reduces the chances of high bandwidth use
from the inbound traffic flows affecting other traffic flows within the deployment. We recommend this model for your
production deployments.

• The common firewall option leverages a single set of VM-Series firewalls. The sole set of firewalls operates as a
shared resource and may present scale limitations with all traffic flowing through a single set of firewalls due to the
performance degradation that occurs when traffic crosses virtual routers. This option is suitable for proof-of-concepts
and smaller scale deployments because the number of firewalls low. However, the technical integration complexity is
high.

The transit VNet provides security for inbound, outbound, and enterprise traffic flows as a shared service and does not
typically contain any application virtual compute resources. The transit VNet also controls and secures east-west traffic flows
between application VNets. The model requires that you establish a VNet peering connection between each application VNet
and the transit VNet. You cannot use overlapping IP address space within the collection of peered VNets.

If you are using the dedicated inbound option, one set of VM-Series firewalls secures all inbound traffic from the internet.
Another set of firewalls provides visibility and control for outbound, east-west, and enterprise traffic flows. The separation of
functions allows you to scale inbound traffic volume independently and simplifies the configuration of the inbound firewalls.

If you are using the common firewall option, a single set of VM-Series firewalls provides visibility and control for all inbound
outbound, east-west, and enterprise traffic flows. Combining all traffic flows onto a single set of firewalls reduces the total
number of firewalls that the design requires. However, this reduces the overall scalability and increases the complexity of the
design because the deployment requires that you deploy multiple virtual routers on each firewall because both the public and
private interfaces receive health probes.

Regardless of the deployment option you choose, employing availability sets to distribute the VM-Series virtual machines
across the Azure physical infrastructure ensures that you avoid downtime caused by infrastructure maintenance or failure.

Palo Alto Networks 55

 Design Model

Figure 38 Transit VNet model—dedicated inbound option

Figure 39 Transit VNet model—common firewall option

OUTBOUND TRAFFIC
Each VM-Series firewall has an interface in the transit VNet public, private, and management subnet. The VM-Series public
interface contains a static default route to the internet. To reach any private or internal subnets, you configure static routes for
all peered application and enterprise network subnets.

Palo Alto Networks 56

 Design Model

User-defined routes in the private subnets of the peered application VNets direct traffic to the internal load balancer’s
frontend IP address, which shares a subnet with the firewall private interfaces. The internal load balancer distributes traffic
to a collection of VM-Series firewalls. Load-balancer rules forward all TCP and UDP ports to the firewalls. The internal load
balancer’s health probes monitor availability of each firewall through the HTTPS service, which you enable on the private
interface by using a interface management profile. A security policy entry allows only traffic sourced from the Azure health
probe IP address to connect to the HTTPS service.

Figure 40 Outbound and east-west traffic

To egress out of the private interface, you define static routes for the health probe IP address and for the application network
ranges. Additionally, a static default route forwards traffic out of the public interface. If you choose the common firewall
option, the same static routes are used but you configure them in different virtual routers.

The firewall applies source NAT to outbound internet traffic. The firewall translates the original source address to the IP
address of its public interface. Azure then automatically translates the interface IP address to the public IP address associated
to the firewall's public interface when the traffic leaves the transit VNet.

The firewall security policy allows appropriate application traffic from the resources in the application virtual networks to the
internet. You should implement the security policy by using positive security policies (allow listing). Security profiles prevent
known malware and vulnerabilities from entering the network in return traffic allowed by the security policy. URL filtering, data
loss prevention, file blocking, and data filtering protect against data exfiltration.

EAST-WEST TRAFFIC
The same internal load balancer that distributes outbound traffic to the firewalls also distributes the spoke-to-spoke east-
west traffic, which is the traffic between subnets in different application virtual networks. You apply user-defined routes for
the private network subnets to the private subnets and direct traffic to the transit VNet's internal load balancer’s frontend IP
address. The existing load-balancer rules for outbound traffic also apply to east-west traffic and to all TCP/UDP ports.

For traffic between private application subnets, the firewall does not translate either the source or destination. A positive
control security policy should allow only appropriate application traffic between private resources and requires that you create
corresponding security policy rules to permit specific traffic. You must then override the default intrazone security policy rule
and modify it to deny traffic. Security profiles should also be enabled to prevent known malware and vulnerabilities from
moving laterally in the private network through traffic allowed by the security policy.

Palo Alto Networks 57

 Design Model

INBOUND TRAFFIC
There are two options for inbound traffic:

• Public load balancer—Choose this option if you require load balancing at Layer 4 only (TCP/UDP). Health probes in
this design monitor the firewall resources and are not directly monitoring the health of the web server resources.

• Application gateway—Choose this option if you require load balancing at Layer 7 (application layer) for HTTP and
HTTPS. Capabilities include URL path-based routing and SSL offload. Health probes in this design directly monitor the
health of the web server resources.

Public Load Balancer

A public load balancer distributes incoming application traffic to the firewalls. To simplify firewall configuration, the frontend
public IP address is associated with a DNS name, and floating IP is enabled on the load-balancer rules. Load-balancer rules
forward the required web service ports to the firewalls. Common ports required for inbound traffic include TCP/80 (HTTP) and
TCP/443 (HTTPS). The public load balancer’s health probes monitor availability of each firewall through the HTTPS service
which you enable on the public interface using a interface management profile. A security policy entry only allows traffic
sourced from the Azure health probe IP address to connect to the HTTPS service.

If you are using the dedicated inbound option, a separate set of VM-Series firewalls secures all inbound traffic from the
internet. If you are using the common firewall option, inbound traffic is secured on the same set of firewalls as outbound,
east-west, and enterprise traffic and you must configure multiple virtual routers to support health probes from the Azure load
balancers on multiple interfaces. Dedicated virtual routers allow the firewall interface that received the health probe to source
responses. Additional static route entries define a default route out of the public interface as well as a route entries to all
private networks through the virtual router dedicated to the private interface.

Figure 41 Health probes using multiple virtual routers

Palo Alto Networks 58

 Design Model

The firewall applies both a destination and source NAT to inbound traffic. Destination NAT translates the FQDN address
object associated with the load-balancer public DNS name to the virtual machine or load balancer on the application network.
The source NAT translates the source to be the IP address of the private interface of the firewall, ensuring return traffic flows
symmetrically.

The firewall security policy allows appropriate application traffic to the resources in the private network while security profiles
prevent known malware and vulnerabilities from entering the network in traffic allowed by the security policy.

Network security groups applied to the public subnet permit inbound internet traffic and deny any traffic destined for the
other subnets in the transit VNet. This ensures that only inbound traffic forwarded through the public load balancer can
communicate to private application resources through the firewall.

Application Gateway
For inbound traffic, an application gateway with a public frontend terminates incoming connections and initiates
corresponding new connections to the configured HTTP/HTTPS backends. You assign unique TCP ports for all backends.
The application gateway sources all new connections from the private IP addresses of the application gateway instances
and distributes the connections to the public interfaces of the inbound firewalls, which you have configured as the backend
pool targets for the application gateway. The application gateway’s health probes monitor backend availability on all specified
HTTP/HTTPS ports.

You must create an additional public subnet for the application gateway. Specify a minimum of two application gateway
instances in order to ensure that you distribute the instances across Azure update and fault domains.

Figure 42 Transit VNet model - dedicated inbound option with application gateway

Palo Alto Networks 59

 Design Model

Figure 43 Transit VNet model - common firewall options with application gateway

You use application gateway destination NAT rules on the firewalls to map to backend resources directly or through one or
more internal load balancers.

This model supports any combination of the following methods:

• Firewall destination port NAT to backend resource—No internal load balancer required, uses port-based NAT
policy rules associated to the backend resource. The firewall NAT policy contains all resource-mapping parameters.

• Internal load balancer with one or more frontend IP addresses—Uses port-based NAT policy rules associated to
the load balancer's frontend IP addresses. You also configure port mapping on the load balancer. This option uses the
load-balancer for resiliency and scaling of the backend resources.

• Multiple internal load balancers—Uses port-based NAT policy rules associated to each load balancer's frontend IP
addresses. This option supports more granular separation of both the load balancers and the backend resources.

The firewall also applies a source NAT to inbound traffic. The source NAT translates the source to be the IP address of the
private interface of the firewall, ensuring return traffic flows symmetrically.

The firewall security policy allows HTTP/HTTPS application traffic from the application gateway instances to the resources
in the private network, and security profiles prevent known malware and vulnerabilities from entering the network in traffic
allowed by the security policy. To support the use of HTTP/HTTPS backends on ports other than 80/443, you should
configure the service for security policy rules to include the specific service ports in use instead of application-default.

Network security groups applied to the application gateway subnet permit inbound internet traffic, allow that traffic to exit to
the public subnet, and deny traffic destined for the other subnets in the transit VNet. This ensures that only inbound traffic
forwarded through the application gateway can communicate to private application resources through the firewall.

Palo Alto Networks 60

 Design Model

ENTERPRISE NETWORK AND MANAGEMENT TRAFFIC

A VNG deployed in the transit VNet connects the Azure virtual networks to your enterprise networks. You can enable BGP to
facilitate dynamic routing between the application networks deployed in Azure and your existing enterprise networks.

To get traffic from your remote site and mobile users to application VNets in Azure, you use a VNG in a dedicated subnet
along with a local network gateway (LNG). This VNG service establishes IPSec connectivity to Prisma Access via the LNG. In
Prisma Access, you configure a service connection to allow access to your enterprise resources in Azure. You can use one
or more IPSec tunnels between the Azure VNG and Prisma Access. BGP Dynamic routing is enabled between the VNG and
Prisma Access.

Figure 44 Enterprise network connections

The internal load balancer that distributes outbound and east-west traffic to the firewalls also distributes traffic to and from the
enterprise networks. Traffic originating from the application virtual network subnets and destined to enterprise networks follow
the same path as outbound and east-west traffic. User-defined routes applied to the gateway subnet direct traffic that has an
application virtual network destination to the internal load balancer. The existing load-balancer rules for outbound and east-
west traffic also apply to enterprise traffic for all TCP and UDP ports.

Traffic from the enterprise networks communicates to the transit management subnet and management VNet through the
Outbound/East-West firewalls. If you are using Panorama for centralized management, enterprise administrators will need to
ensure proper access is allowed for Panorama to and from the desired networks. Network security groups are also applied
to the management subnet to ensure that only management traffic from the peered management VNet and the enterprise
network subnets can reach Panorama and VM-Series management interfaces. The management NSG also contains rules
that limit internet management to a set of trusted public source addresses from within your organization.

Palo Alto Networks 61

 Summary

Summary
Moving applications to the cloud requires the same enterprise-class security as your private network. The shared-security
model in cloud deployments places the responsibility of protecting applications and data on your organization. Deploying
Palo Alto Networks VM-Series firewalls in your Microsoft Azure infrastructure provides a scalable secure infrastructure
with protections from known and unknown threats, complete application visibility, a common security policy, and native
cloud automation support. Your ability to move applications to the cloud securely helps you to meet challenging business
requirements.

Palo Alto Networks 62

 Feedback

Feedback
You can use the feedback form to send comments about this guide.

Palo Alto Networks 63

HEADQUARTERS
Palo Alto Networks Phone: +1 (408) 753-4000
3000 Tannery Way Sales: +1 (866) 320-4788
Santa Clara, CA 95054, USA Fax: +1 (408) 753-4001
[Link] info@[Link]

©2024 Palo Alto Networks, Inc. Palo Alto Networks is a registered trademark of Palo Alto Networks. A list of our trademarks can be
found at [Link] All other marks mentioned herein may be trademarks of their
respective companies. Palo Alto Networks reserves the right to change, modify, transfer, or otherwise revise this publication without notice.

You can use the feedback form to send comments about

this guide.

P-115P-20122024