NSX T Deployment Guide
NSX T Deployment Guide
M AY 2 0 2 0
Table of Contents
Table of Contents
Preface..................................................................................................................................................................... 1
Audience................................................................................................................................................................................................. 4
Related Documentation....................................................................................................................................................................... 4
Deployment Overview........................................................................................................................................... 5
Design Models........................................................................................................................................................6
North-South Tier-1 Deployment Model........................................................................................................................................... 8
Configuring Notify-Groups..............................................................................................................................................................76
Preface
GUIDE TYPES
Overview guides provide high-level introductions to technologies or concepts.
Reference architecture 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.
DOCUMENT CONVENTIONS
Cautions warn about possible data loss, hardware damage, or compromise of security.
Blue text indicates a configuration variable for which you need to substitute the correct value for your
environment.
• Command-line commands.
• User-interface elements.
• Navigational paths.
• A value to be entered.
An external dynamic list is a file hosted on an external web server so that the firewall can import objects.
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.
https://www.paloaltonetworks.com/referencearchitectures
• Provides architectural guidance and deployment details for using Palo Alto Networks VM-Series
firewalls to provide visibility, control, and protection to your applications built in NSX-T Data
Center.
• Requires that you first read the Securing Applications Deployed in a VMware NSX-T Data Center:
Reference Architecture Guide. The reference architecture guide provides architectural insight and
guidance for your organization to plan linkage of pertinent features with the VM-Series firewalls in
a scalable and resilient design.
• Provides decision criteria for deployment scenarios, as well as procedures for programming
features of NSX-T Data Center and the Palo Alto Networks VM-Series firewall in order to achieve an
integrated design.
OBJECTIVES
Completing the procedures in this guide, you can successfully deploy Palo Alto Networks VM-Series
firewalls on VMware NSX-T Data Center. The main objectives are to enable the following functionality:
• Protection and inspection of inbound and outbound traffic flows through a Tier-1 gateway and
east-west application traffic flows within an NSX-T application tenant
• Preparing the firewalls to participate in the full Security Operating Platform® with WildFire® ana-
lytics, URL filtering, identity-based services, and the full Threat Prevention services
• Resilient and scalable operation through integration with the NSX-T Manager
• Centralized reporting with Palo Alto Networks cloud-delivered Cortex™ Data Lake (formerly
Logging Service)
AUDIENCE
This deployment guide is for technical readers, including system architects and design engineers, who
want to deploy the Palo Alto Networks Security Operating Platform within a private cloud datacenter
infrastructure. It assumes the reader is familiar with the basic concepts of applications, networking,
virtualization, security, and high availability, as well as a basic understanding of network and data center
architectures.
To be successful, you must have a working knowledge of networking and policy in PAN-OS®.
RELATED DOCUMENTATION
The following documents support this guide:
• Securing Data in the Private Data Center and Public Cloud with Zero Trust—Describes how your orga-
nization can use the Palo Alto Networks Security Operating Platform in the design of a Zero Trust
security policy in order to protect your sensitive and critical data, applications, endpoints, and
systems.
• Securing Applications Deployed in a VMware NSX-T Data Center: Reference Architecture Guide—Pres-
ents a detailed discussion of the available design considerations and options for the next-genera-
tion VM-Series firewall on VMware NSX-T Data Center.
Deployment Overview
There are many ways to use the concepts discussed in Securing Applications Deployed in a VMware NSX-T
Data Center: Reference Architecture Guide to achieve an architecture that secures application deployments
in NSX-T Data Center. The design model in this deployment guide offers an example architecture that
secures:
Design Models
There are many ways to use the concepts discussed in the previous sections to build a secure architecture
for application deployment in VMware NSX-T Data Center. The design models in this section offer a
complete example architecture that leverages Panorama and the VM-Series next-generation firewalls to
secure both north-south and east-west traffic flows inside an NSX-T Data Center deployment.
Panorama streamlines and consolidates core tasks and capabilities, enabling you to view all your firewall
traffic, manage all aspects of device configuration, push global policies, and generate reports on traffic
patterns or security incidents. The NSX plugin connects simplifies deployment of VM-Series firewalls in
your NSX-T environment by providing partner services configuration directly to NSX-T Manager. You
deploy Panorama in management-only mode leveraging the cloud service plugin so all VM-Series firewall
logs are encrypted and sent directly from the firewalls to Cortex Data Lake over TLS/SSL connections.
The design models presented here differ slightly in how they create and secure tenant, application, or
trust zone boundaries. In this architecture guide, the two models are shown as complimentary deploy-
ments. If you chose to deploy a single model, consider which one best fits your needs and use it as a
starting point for your overall design.
• North-south—This design showcases protecting north-south traffic flows to two distinct types of
application tenants deployed as separate trust zones, each deployed under a Tier-1 gateway. The
first tenant hosts a typical three-tier application and the second tenant hosts a set of shared-ser-
vices applications.
Both design models are implemented in an NSX-T Data Center deployment hosted on a typical next-gen-
eration fabric architecture, as shown in Figure 1. The vCenter deployment uses several compute clusters to
illustrate different network functions. The models use the following vCenter clusters:
• Management cluster—The management cluster hosts all management VMs. These include vCenter,
the three NSX-T Manager appliances configured in an active/standby cluster, and active/standby
Panorama instances.
• Edge cluster—The edge cluster hosts the NSX-T edge node VMs and provides connectivity to exter-
nal networks.
• Security cluster—The security cluster hosts the north-south VM-Series next-generation firewalls.
• Application cluster—The application cluster hosts all the VMs for a three-tier application with web,
application, and db tiers. It also hosts the east-west VM-Series next-generation firewalls deployed
in a host-based configuration.
• Shared-Services Cluster—The shared cluster hosts applications such as Active Directory and DNS,
which may be shared to multiple Tier-1 application tenants.
Core
Network
Edge Cluster
Application Cluster
Security Cluster
Shared-Services Cluster
Management Cluster
An NSX-T Data Center logical topology is deployed on the physical infrastructure. This logical topology
includes a two-tier routing setup. The Tier-0 gateway connects to the northbound physical routers and
two southbound application zone Tier-1 gateways. One of the Tier-1 gateways hosts a three-tier appli-
cation with web, application, and database virtual machines hosted on a single overlay segment and the
other Tier-1 gateway hosts a set of shared-services applications, including Microsoft Active Directory and
DNS services also hosted on a single overlay segment. Figure 2 illustrates the NSX-T Data Center logical
deployment.
NSX-T Manager uses the information pushed from Panorama in the north-south service definition to
deploy the VM-Series firewall. In the north-south deployment model you deploy instances of the VM-Se-
ries firewall as a partner service in your VMware NSX-T Data Center. NSX-T supports a two-tiered routing
model, which allows flexibility in creating trust-zones for application and sensitive data deployments.
The resulting virtual network topology is like a physical hub-and-spoke network topology. A Tier-1
gateway hosts connections to overlay switching segments and provides an uplink connection to the
Tier-0 gateways. In this model, you attach a VM-Series firewall to each Tier-1 gateway uplink creating
an application tenant and trust zone boundary. NSX-T Manager deploys and attaches two VM-Series
firewalls in a high-availability (HA) pair to each Tier-1 gateway uplink in virtual wire mode. A virtual wire
deployment simplifies next-generation firewall installation and configuration because you can insert
the firewall into an existing network topology without assigning MAC or IP addresses to the interfaces,
redesigning the network, or reconfiguring surrounding network devices. The north-south VM-Series
firewalls are deployed on dedicated physical server hardware configured as a vCenter compute cluster
named Security Cluster.
The VM-Series firewalls provide visibility and security for inbound and outbound traffic to the application
zone and shared-services zone, including traffic between the zones. Figure 3 illustrates the north-south
Tier-1 insertion mode.
Physical Router
Tier-0 VLAN
N-VDS N-VDS
Gateway segment
EDGE EDGE
Edge Cluster
Downlink Downlink
Application Shared-Services
Tier-1
Gateway
VM VM VM VM VM VM
Inbound Traffic
After deploying the VM-Series firewalls, you configure a north-south traffic introspection policy on
NSX-T Manager and add redirection rules to send traffic to the VM-Series firewall when crossing the
Tier-1 router uplink. Inbound security policy rules are pushed from Panorama to the managed north-
south VM-Series firewalls and applied to inbound traffic passing through the VM-Series firewalls. Because
each of the virtual wire interfaces are configured in the same zone, the default intra-zone security policy
rules should be overridden and modified to deny traffic. The firewall security policy allows appropriate
application traffic to the instances in the Tier-1 connected overlay segments while firewall security
profiles prevent known malware and vulnerabilities from entering the network in traffic allowed by the
security policy.
Physical Router
Tier-0 VLAN
N-VDS N-VDS
Gateway segment
EDGE EDGE
Edge Cluster
Application Shared-Services
Inbound Inbound
Traffic Traffic
Redirect Rule
Security Cluster
Tier-1
Gateway
VM VM VM VM VM VM
Outbound Traffic
You can use the same north-south traffic introspection policy on NSX-T Manager to add redirection rules
to send traffic to the VM-Series firewall when crossing the Tier-1 router uplink in the outbound direction.
Outbound security policy rules are pushed from Panorama to the managed north-south VM-Series fire-
walls and applied to outbound traffic passing through the VM-Series firewalls. The outbound VM-Series
firewall security policy allows appropriate application traffic from the VM instances in the application
projects to the data center, corporate networks, or the internet. You should implement the outbound
security policy by using positive security policies (whitelisting). Security profiles prevent known malware
and vulnerabilities from entering the network in return traffic allowed by the outbound security policy
while URL filtering, file blocking, and data filtering protect against data exfiltration.
Physical Router
Tier-0 VLAN
N-VDS N-VDS
Gateway segment
EDGE EDGE
Edge Cluster
Application Shared-Services
Redirect Rule
Outbound Outbound
Traffic
Security Cluster Traffic
Tier-1
Gateway
VM VM VM VM VM VM
In the east-west deployment model, you deploy instances of the VM-Series firewall as a partner service
in your VMware NSX-T Data Center. NSX-T Manager uses the information pushed from Panorama in the
east-west service definition to deploy the VM-Series firewalls. After deploying the VM-Series firewalls,
you configure a service chain and an east-west traffic introspection policy on NSX-T Manager and add
redirection rules to send traffic to the VM-Series firewall when crossing the VM vNIC.
In this model, you will deploy the VM-Series firewalls in a host-based deployment model to secure east-
west traffic between tiers of a three-tier application deployed across VMs in a single overlay segment. The
advantage of having all VMs located on a unique L2 domain is a reduction in L3 subnet addresses—and a
simplification in the routing entity (no need to route between the tiers now)—while preserving the exact
same security posture. In a host-based deployment, NSX-T Manager deploys and attaches an instance of
the VM-Series firewall on each ESXi hypervisor transport node in the vCenter compute cluster in virtual
wire mode. A virtual wire deployment simplifies next-generation firewall installation and configuration
because you can insert the firewall into an existing network topology without assigning MAC or IP ad-
dresses to the interfaces, redesigning the network, or reconfiguring surrounding network devices.
After you deploy the VM-Series firewalls, you configure the service chain and east-west introspection
policy and add traffic redirect rules As part of the redirect rule definition you use NSX security groups to
specify source and destination of traffic flows. To add VMs to the security groups you either tag the VM or
use other group membership criteria like VM name or IP address. The group members are then sent from
NSX-T Manager back to Panorama where they are added to a dynamic address group and added to the
VM-Series security policy. The dynamic address group information can be sent to and used by the north-
south VM-Series firewalls in creation of the north-south security policies.
The VM-Series firewalls provide visibility and security for east-west traffic in the same application tier
and between application tiers. You can select the specific deployment model of the VM-Series to fit the
performance and capacity requirements of each vCenter compute cluster. You cannot mix VM-Series
models within a single cluster, but you can have separate deployments where a different VM-Series
models are deployed in different vCenter compute clusters. Figure 6 illustrates the host-based east-west
deployment model.
N-VDS N-VDS
VM VM VM VM
Application Cluster
East-West Traffic
NSX-T Manager uses the information pushed from Panorama in the service definition to deploy the
VM-Series firewall. After deploying the VM-Series firewalls, you configure a service chain and an
east-west traffic introspection policy on NSX-T Manager and add redirection rules to send traffic to
the VM-Series firewall when crossing the VM vNIC. Traffic that matches the redirect rule is sent to the
VM-Series firewall on the configured service segment.
The local VM-Series firewall inspects and secures application traffic between VMs on the same host,
traffic does not need to leave the host for inspection. Traffic leaving the host is redirected to the VM-Se-
ries firewall before reaching the N-VDS where it is then forwarded to its destination. The east-west
security policy rules that you configure on Panorama are pushed to managed VM-Series firewalls and then
applied to the traffic passing through the firewalls. You should implement the east-west security policy
by using positive security policies (whitelisting). Because each of the virtual wire interfaces reside in the
same zone, the default intra-zone security policy rules should be overridden and modified to deny traffic.
The VM-Series safely enables communications from WEB server to APP server as well as traffic from APP
server to DB server. Security profiles should also be enabled to prevent known malware and vulnerabilities
from moving laterally in the trusted network through traffic allowed in the security policy. Figure 7
illustrates the east-west traffic redirection and flows.
N-VDS N-VDS
Redirect Redirect
Rule Rule
EW VM VM EW VM VM
Traffic Traffic
WEB1 WEB2 APP DB
Application Cluster
• The tested vSphere and ESXi version in this guide is 6.7 Update 3.
• Your organization has an active licensing with VMware vSphere and NSX-T Data Center, and you
have the appropriate privileges for configuring compute, network, and storage resources.
• Your organization has licenses for Panorama and Cortex Data Lake.
vCenter
NSX NSX
Management Cluster
This section describes how to install and license Panorama on the management cluster, activate Cortex
Data Lake, configure templates, template stacks, and multiple device groups to support VM-Series
next-generation firewall insertion in the NSX-T Data Center deployment.
In preparation for VM-Series deployments in NSX-T, you first configure device groups to manage licens-
ing and security policy. The device groups enable VM-Series grouping based on NSX-T insertion location
and type. Using device groups, you can configure policy rules and the objects they reference. The device
groups allow you to push new policy to a group of VM-Series firewalls, reducing configuration deployment
time and improving consistency.
You then configure templates to define a common base configuration and specific interface and zone
configurations required for north-south and east-west VM-Series deployments. A template stack is a
combination of templates: the assigned VM-Series firewalls inherit the settings from every template in
the stack. This enables you to avoid the redundancy of adding every setting to every template.
The last group of procedures has you install and configure the Panorama NSX-T plugin to connect to the
NSX-T Manager and push service-definitions as final preparation for VM-Series deployments in NSX-T.
Procedures
In these procedures, you deploy Panorama in Management Only mode. Panorama defaults to management
mode when it detects that there is not enough log storage capacity to run in Panorama mode.
You need a BYOL license for the primary Panorama server and another for the optional secondary Panora-
ma server.
To deploy the Panorama virtual appliance on ESXi, you must download the Panorama base image file from
the Palo Alto Networks Customer Support portal, and then deploy the image on a compute host in the
management cluster.
Step 2: Navigate to Updates > Software Updates, and then in the Filter by list, choose Panorama Base
Images.
In this procedure, you deploy a primary and secondary Panorama VM instance by using the Panorama base
image you downloaded in Procedure 1.1.
Step 1: Connect to the VMware vCenter server and navigate to the management cluster or host where
Panorama will be deployed.
Step 3: In the Deploy OVF Template dialog box, select Local file and Choose Files, browse to the location
of the Panorama base image file, select it, choose Open, and then click Next.
Step 4: In the Name box, enter Panorama-A, and then click Next.
Step 5: Select a datastore location (system disk) on which to install the Panorama image. The system disk
must have exactly 81GB storage for the virtual appliance in Management Only mode. After selecting the
datastore, click Next.
Step 6: Select Thick Provision Lazy Zeroed as the disk format, and then click Next.
Step 7: Specify which network to use for the Panorama virtual appliance, and then click Next.
Step 8: Confirm the selected options, click Finish to start the installation process, and then when it
finishes, click Close. Do not power on the Panorama virtual appliance yet.
Step 9: Check the Setup Prerequisites, and then configure required resources for the Panorama virtual
appliance.
Step 10: Right-click the Panorama virtual appliance, and then click Edit Settings.
Step 11: Verify that the settings are correct, and then click Finish.
Step 12: In the vSphere Client, right-click the Panorama virtual appliance, and then select Power On. Wait
for Panorama to boot up before continuing.
Next, you connect to the Panorama console and set the admin password and management IP address.
Step 13: Right-click the Panorama virtual appliance, and then select Open Console.
Step 14: Enter the username and password to log in (the default is admin for both).
Note
Starting with PAN-OS 9.0.4, you must change the predefined, default ad-
ministrator password (admin/admin) on the first logon on a device. The new
password must be a minimum of eight characters and include a minimum of
one lowercase and one uppercase character, as well as one number or special
character.
Step 16: Enter the following commands to add IP address, gateway, and DNS information:
> configure
# set deviceconfig system ip-address 10.5.60.6 netmask 255.255.255.0
default-gateway 10.5.60.1 dns-setting servers primary 10.5.60.53
# commit
# exit
Step 17: Use your browser to connect to the first Panorama instance, using HTTPS to the IP address or
DNS name for Panorama-A (example: https://10.5.60.6 or https://panorama-a.example.local). Accept the
browser certificate warning.
Step 18: Repeat this procedure for the second Panorama instance with an IP address of 10.5.60.7.
This procedure assumes that you have a valid serial number for your Panorama devices and that registra-
tion on the customer support portal (https://support.paloaltonetworks.com) is complete.
Step 2: On the There are no device groups dialog box, click OK.
Step 3: On the Retrieve Panorama License dialog box, click OK.
Step 4: On the Retrieve Panorama License dialog box, click Complete Manually.
Step 5: On the Offline Licensing Information dialog box, click OK.
Step 6: In Panorama > Setup > Management > General Settings, click the Edit cog.
Step 8: In the Domain box, enter example.local or your domain name.
Step 9: In the Time Zone list, choose the appropriate time zone (Example: US/Pacific).
Step 10: In the Serial Number box, enter the serial number from the customer support portal, and then
click OK. When you license a Panorama system, you use the serial number assigned to your account for
that system. You can find the serial number in the Palo Alto Networks customer support portal.
Step 12: On the NTP tab, in the Primary NTP Server section, in the NTP Server Address box, enter 0.pool.
ntp.org.
Step 13: In the Secondary NTP Server section, in the NTP Server Address box, enter 1.pool.ntp.org, and
then click OK.
Note
Align the clock on Panorama and the managed firewalls to use the same time
zone (for example, GMT or UTC). If you plan to use Cortex Data Lake, you
must configure NTP or ensure that Panorama is getting the time from the ESXi
hypervisor host so that Panorama can stay in sync with Cortex Data Lake.
Timestamps are recorded when the managed firewalls generate the logs and
Panorama receives the logs. Aligning the time zones on Panorama and the
firewalls ensures that the timestamps are synchronized and the process of
querying logs and generating reports on Panorama is harmonious.
Step 14: On the Commit list, choose Commit to Panorama, and then click Commit.
Step 15: In Panorama > Licenses, click Retrieve license keys from license server.
Step 16: Verify in the status pane that Device Management License is active and has the correct device
count.
Repeat this procedure on the secondary Panorama server, Panorama-B. You must have a unique serial
number for the secondary Panorama system.
Note
Step 1: In Panorama > Software, click the Check Now button to retrieve the latest updates.
Step 2: Find 9.1.1, and then in the Action column, select Download.
Step 4: After a successful download, the Action column changes from Download to Install for that image.
Step 5: Select Install to install the downloaded image, and then click Yes to reboot.
This procedure is necessary only when deploying Panorama in a high-availability configuration. Panora-
ma supports an HA configuration in which one peer is the active-primary and the other is the passive-sec-
ondary. If a failure occurs on the primary peer, it automatically fails over and the secondary peer becomes
active.
The Panorama HA peers synchronize the running configuration each time you commit changes on the
active Panorama peer. The candidate configuration is synchronized between the peers each time you save
the configuration on the active peer or just before a failover occurs.
Settings that are common across the pair—such as shared objects and policy rules, device group objects
and rules, template configuration, and administrative access configuration—are synchronized between
the Panorama HA peers.
Step 1: In Panorama > High Availability > Setup, click the Edit cog.
Step 3: In the Peer HA IP Address box, enter 10.5.60.7, and then click OK.
Step 4: In Panorama > High Availability > Election Settings, click the Edit cog.
Step 5: In the Priority list, choose primary, and then click OK.
Step 6: On the Commit menu, choose Commit to Panorama, and then click Commit.
Step 9: In the Peer HA IP Address box, enter 10.5.60.6, and then click OK.
Step 10: In Panorama > High Availability > Election Settings, click the Edit cog.
Step 11: In the Priority list, choose secondary, and then click OK.
Step 12: On the Commit menu, choose Commit to Panorama, and then click Commit.
Step 13: On the primary Panorama server, in Dashboard > Widgets > System, click High Availability to
enable the High Availability dashboard widget. This adds a dashboard pane that displays the status of the
Panorama peers.
Step 15: On the primary Panorama server, in Dashboard > High Availability, click Sync to peer.
Step 16: Click Yes to accept the Overwrite Peer Configuration warning and proceed with the
synchronization.
Procedures
2.3 Configure Cortex Data Lake for Firewall Logging Storage Space
Panorama is now running, licensed, and configured for HA. Because this was a new installation, it is now
running with the default configuration. In the next steps, you activate Cortex Data Lake, install the Cloud
Services plugin, and configure Cortex Data Lake to receive VM-Series firewall logging information.
Cortex Data Lake requires an authorization code to activate the service. This procedure also assumes that
you have a valid serial number for your Panorama device(s) and that registration on the customer support
portal is complete.
The Cortex Data Lake instance is associated with the serial number of the primary Panorama server. You
do not repeat this procedure for the secondary Panorama server.
Step 4: In the Cloud Services window, in the Authorization Code box, enter the authorization code (Ex-
ample: I11223345), and then press TAB key to advance. The Panorama and Logging Region boxes appear.
Step 5: In the Cloud Services window, in the Panorama list, choose the value that corresponds to the
serial number assigned to your primary Panorama server.
Step 6: In the Cloud Services window, in the Logging Region list, choose the value that corresponds to
your region (for example, Americas).
Step 7: Select the checkbox to acknowledge the warning. You will perform this update later, in Procedure
2.3.
If you are running Panorama in high availability mode, perform this procedure on the primary Panorama
server first. You then repeat this procedure for the secondary Panorama server.
Step 1: In Panorama > Plugins, click Check Now to retrieve the latest updates.
Step 2: Find cloud_services-1.5.0, and then in the Actions column, click Download.
Step 4: After the status in the Available column changes to a checkmark, in the Action column, click
Install.
Step 5: On the dialog box that indicates a successful installation, click OK.
Step 6: In Panorama > Licenses, click Retrieve license keys from server.
Step 8: Open another browser window and navigate to the customer support portal (https://support.
paloaltonetworks.com). Complete step 9 through step 11 in the customer support portal.
Step 10: In the Generate Cloud Services One Time Password window, in the Panorama list, choose the
serial number for the primary Panorama server, and then click Generate OTP.
Step 11: In the Generate Cloud Services One Time Password window, click Copy to Clipboard.
Step 12: On the primary Panorama server, navigate to Panorama > Cloud Services > Status, and then click
Verify. If programming the secondary Panorama, verify on Panorama-b.
Step 13: In the One-Time Password box, paste the OTP that you generated from the Customer Support
Portal, and then click OK.
Step 14: In Panorama > Cloud Service > Status, verify the status. It may take a minute for the verification
to complete.
Step 15: If Panorama is running in HA mode, repeat this procedure for the secondary Panorama server. In
Step 10, you must generate a new OTP, this time for the secondary Panorama server serial number.
2.3 Configure Cortex Data Lake for Firewall Logging Storage Space
This procedure provisions storage space for firewall logs. In Procedure 2.1, Step 7, you acknowledged a
warning that you must allocate storage space for firewall logs, or they will be purged from Cortex Data
Lake.
Step 1: Navigate to the Palo Alto Networks Cortex hub, log in, and then click Cortex Data Lake.
Step 3: In the Firewall Log Type Size box, enter 5 TB, and then click Apply.
This firewall log type size is an example value. You are provisioning a portion of the total storage space for
firewall logs. For storage sizing, see this Knowledge Base Article.
Procedures
Next, you configure a common parent device group and then three device groups each representing a
specific deployment in NSX-T. Then you create a Log Forwarding Object and modify the default security
policy rules. In the last steps, you create and configure a common baseline template and individual
network templates representing each deployment type in NSX-T. Then you create a set of template stacks
that combine the baseline and network configurations across each NSX-T deployment group of VM-Series
firewalls.
Device groups contain VM-Series firewalls you want to manage as a group. A firewall can belong to only
one device group. Panorama treats each group as a single unit when applying policies.
Parent device
Device group name Description group
Step 1: On the primary Panorama server, navigate to Panorama > Device Groups, and then click Add.
Step 4: In the Parent Device Group list, verify that the value is set to Shared, and then click OK.
Step 5: Repeat this procedure for the remaining device groups in Table 1 with Parent Device Group of
NSX-T.
You use this procedure to configure a log forwarding object that security policies use to direct logging
information to the Cortex Data Lake instance you configured as part of the management project Panorama
deployment.
Step 1: On the primary Panorama server, in the Context list, choose Panorama.
Step 3: In the navigation pane, click Log Forwarding, and then click Add.
Step 5: Choose Enable enhanced application logging to Logging Service, and then click OK.
Step 6: On the Commit menu, select Commit to Panorama, and then click Commit. It is not mandatory to
commit currently but doing so periodically prevents you from losing work if an outage occurs.
Default rules instruct the firewall how to handle traffic that does not match any Pre Rules, Post Rules, or
local firewall rules. These rules are part of Panorama’s predefined configuration. You must override them
to enable editing of select settings in these rules. Because all peered project VPC networks are in the same
VM-Series private zone, this procedure overrides the default intrazone traffic rule from permit to deny.
Step 2: At the top of the page, in the Context list, choose Panorama.
Step 4: Navigate to Polices > Security > Default Rules, select the row for the intrazone-default rule, and
then click Override.
Step 6: Select Log at Session End, and then in the Log Forwarding list, choose
Forward-to-Cortex-Data-Lake.
Step 7: On the Target tab, select Any (target to all devices), and then click OK.
Caution
Make sure to target all devices (any) in the device group. Otherwise, the policy
rule will not be automatically applied to new group members.
Step 8: Repeat this procedure for the NS Tier-1 Shared-Services and EW Host-Based App1 device groups.
Step 9: On the Commit menu, choose Commit to Panorama, and then click Commit.
You use templates to configure functions that are common across groups of firewalls. In this procedure,
you create a baseline configuration template that you can use for all VM-series firewalls in the environ-
ment and a network template that is specific to each VM-Series group deployment in the model.
Step 3: In the Description box, enter a valid description, and then click OK.
Step 4: Repeat this procedure for NS Tier-1 Network Settings and EW Host-Based Network Settings.
Step 5: On the Commit menu, choose Commit to Panorama, and then click Commit.
You should now see tabs at the top of the Panorama page for device groups and templates.
Now you perform the baseline configuration template for the VM-Series firewalls. The bootstrap process
uses this template to configure common services such as DNS, NTP, and Cortex Data Lake as well as other
baseline settings.
Step 3: In Device > Setup > Management > General Settings, click the Edit cog.
Step 4: Enter the appropriate timezone (US/Pacific), and then click OK.
Step 5: In Device > Setup > Services > Global > Services, click the Edit cog.
Step 7: On the NTP tab, in the Primary NTP Server box, enter 0.pool.ntp.org.
Step 8: In the Secondary NTP Server box, enter 1.pool.ntp.org, and then click OK.
Step 11: In Network Services, select Ping, and then click OK.
Note
Step 12: On the Commit menu, select Commit to Panorama, and then click Commit. It is not mandatory to
commit currently but doing so periodically prevents you from losing work if an outage occurs.
Next, enable the Palo Alto Networks cloud-based logging to the Cortex Data Lake on the firewalls.
Step 13: In Panorama > Licenses, verify that the Cortex Data Lake license is active.
Step 14: Navigate to Device, and then in the Template list, select Baseline Settings.
Step 15: In Device > Setup > Management > Logging Service, click the Edit cog.
Step 16: Select Enable Logging Service, and then select Enable Enhanced Application Logging.
Step 17: In Region list, choose americas, and then click OK.
Step 18: In Device > Log Settings > System, click Add. The Log Settings—System configuration window
appears.
Step 21: In Device > Log Settings > Configuration, click Add. The Log Settings—Configuration window
appears.
Step 24: On the Commit menu, click Commit to Panorama, and then click Commit.
Now you perform the initial configuration template for the north-south Tier-1 VM-Series networking. The
bootstrap process uses this template to configure the VM-Series firewall interfaces and zones.
Step 8: In the Name box, enter south, and then click OK.
Next, you create the Virtual Wire and add the interfaces to it.
Step 17: On the Commit menu, click Commit to Panorama, and then click Commit.
Now you perform the initial configuration template for the east-west host-based VM-Series networking.
The bootstrap process uses this template to configure the interface zones. You need to define only a single
zone in this step; the virtual wire interfaces are configured automatically through the service definition
configuration and deployment process.
Step 5: In the Type list, choose Virtual Wire, and then click OK.
Step 6: On the Commit menu, click Commit to Panorama, and then click Commit.
You use template stacks to combine several templates into a group. You can also assign common settings
to the template stack. In this example, you use a template stack to group the baseline and network tem-
plates for each of the VM-Series firewall deployments.
Step 1: On the primary Panorama server, navigate to Panorama > Templates, and then click Add Stack.
Step 4: In the Templates pane, click Add, select Baseline Settings and NS Tier-1 Network Settings, and
then click OK.
Step 5: Repeat Step 1—Step 4 for the template stacks listed in Table 3.
Step 6: On the Commit menu, click Commit to Panorama, and then click Commit.
Procedures
First, you need to download the base VM-Series PAN-OS image. Then you must host the image and related
configuration files on a local server where vCenter can download the files via HTTP/HTTPS.
Next, you install the Panorama NSX Plugin, creating and configuring a service manager that provides the
communication channel between Panorama and the NSX-T Manager. The device groups and templates
that you previously created are used to create service definitions that are pushed to the NSX-T Manager.
The last steps are to download the PAN-OS version for device deployment and add VM-Series licensing
information to the device groups.
To deploy the VM-Series on NSX-T, you must download the base image file from the Palo Alto Networks
customer support portal and host the images and configuration files on a local server running HTTP or
HTTPS with download permissions.
Step 2: Navigate to Updates > Software Updates, and then in the Filter by list, choose PAN-OS for VM-
Series NSX Base Images.
Step 4: Unzip the file to extract and save the .ovf, .mf, and .vmdk files to the same directory on your
repository server. The .ovf and .vmdk files are used to deploy each instance of the firewall.
Step 5: Verify that the directory and files are reachable and downloadable from a web browser.
Note
You might need to modify the security settings on the server so that you can
download the file types. For example, on the IIS server modify the mime types
configuration; on an Apache server edit the .htaccess file.
Note
Step 1: In Panorama > Plugins, click Check Now to retrieve the latest updates.
Step 2: Find vmware_nsx-3.1.0, and then in the Actions column, click Download.
Step 4: After the status in the Available column changes to a checkmark, in the Action column, click
Install.
Step 5: On the dialog box that indicates a successful installation, click OK.
Complete the following procedure to enable communication between Panorama and NSX-T Manager.
Step 1: On the primary Panorama server, navigate to Panorama > VMware > NSX-T > Service Managers,
and then click Add.
Step 4: In the NSX Manager URL box, enter the NSX-T Manager cluster virtual IP address or FQDN—
https://10.5.60.67 or https://nsx-manager.example.local.
Step 5: In the NSX Manager Login box, enter the username and password so that Panorama can authenti-
cate to the NSX-T Manager.
Note
If you change your NSX-T Manager login password, ensure that you update
the password on Panorama immediately. An incorrect password breaks the
connection between Panorama and NSX-T Manager.
Step 7: On the Commit menu, choose Commit to Panorama, and then click Commit.
Step 8: Navigate to Panorama > VMware > NSX-T > Service Managers.
When the connection is successful, the status displays as Registered. This indicates that Panorama and
the NSX-T Manager are in sync.
• Out of sync: The configuration settings defined on Panorama are different from what is defined on
NSX-T Manager. Click the link for details on the reasons for failure. For example, NSXT Manager
may have a service definition with the same name as defined on Panorama. To fix the error, use
the service definition name listed in the error message to validate the service definition on NSX-T
Manager. Until the configuration on Panorama and the NSX-T Manager is synchronized, you cannot
add a new service definition on Panorama.
• Connection disabled—The connection between Panorama and the NSX-T Manager was manually
disabled.
Panorama populates and updates the dynamic address objects referenced in policy rules so that the
VM-Series firewalls in the specified device groups receive changes to the registered IP addresses in the
dynamic address groups.
Step 1: On the primary Panorama server, navigate to Panorama > VMware > Notify Groups, and then click
Add.
Step 2: In the Name box, enter NSX-T, and then click OK.
A service definition specifies the configuration for the VM-Series firewalls installed in your NSX-T data
center environment. The service definition must include the device group, a template stack, and an OVF
URL. You create service definitions for each of the VM-Series deployment types.
Notify Health
Name Device group Template stack group Insertion type check
Step 1: On the primary Panorama server, navigate to Panorama > VMware > NSX-T > Service Definitions,
and then click Add.
Note
Both http and https are supported protocols. You can use the same .ovf version
or different versions across service definitions. Using different .ovf versions
across service definitions allows you to vary the VM-Series model or PAN-OS
version deployed in different ESXi clusters.
Step 7: In the Insertion Type field, select NORTH_SOUTH, and then click OK.
Step 8: Repeat Step 1-Step 7 for each of the service definitions in Table 4.
Next, you add the service definitions to the NSX-T Service Manager.
Step 9: Navigate to Panorama > VMware > NSX-T > Service Managers, select the NSX-T Manager entry
created in Procedure 4.1.
Step 10: In the Service Definitions box, click Add, then select NS Tier-1 App1 from the list box.
Step 11: Click Add, then select NS Tier-1 Shared-Services from the list box.
Step 12: Click Add, then select EW Host-Based App1 from the list box.
In this procedure, you download the content packages, VM-Series plugin, and PAN-OS version to which
the VM-Series will be upgraded after deployment.
Step 1: On the primary Panorama server, navigate to Panorama > Device Deployment > Software, and
then click Check Now.
Step 2: Select PanOS_vm-9.1.1, and then in the Actions column, click Download.
Step 3: Navigate to Panorama > Device Deployment > Plugins, and then click Check Now.
Step 4: Select vm_series-1.0.10, and then in the Actions column, click Download.
Note
Step 5: Navigate to Panorama > Device Deployment > Dynamic Updates, and then click Check Now.
Step 6: In the Application and Threat section, in the row for the latest panv2-all-contents release (exam-
ple: panv2-all-contents-8253-6026), in the Actions column, click Download.
Step 7: After the download completes, click Close to close the Download Applications and Threats
window.
Note
If you receive an “Operation Failed” warning with the message “No update
information available,” you click Close to acknowledge. No action is required.
After adding the Service Definition entries to Service Manager, you must go back and add the firewall
authorization code to each device group.
Step 1: On the primary Panorama server, navigate to Panorama > Device Groups.
Step 2: Select the NS Tier-1 App1 device group that you created in Procedure 3.1.
Step 3: In the Dynamically Added Device Properties section, in the Authorization Code box, enter your
VM-Series authorization code (for example, I1234567).
Step 4: In the Dynamically Added Device Properties section, in the SW Version list, select PanOS_vm-
9.1.1, and then click OK.
Step 5: Repeat Step 1-Step 4 for the NS Tier-1 Shared-Services and EW Host-Based App1 device groups.
Step 6: On the Commit menu, choose Commit to Panorama, and then click Commit..
After the commit completes, you should see the authorization code and SW version listed in the
device group details.
Next, you verify the NSX-T Service Manager connection status on Panorama.
Step 8: Navigate to Panorama > VMware > NSX-T > Service Managers, and then verify that each service
definition shows as “In Sync” in the Service Definitions column.
Note
Tier-0 and Tier-1 gateways are virtual router instances, not VMs. Although it
is possible to deploy a single routing layer using only a Tier-0 gateway, most
NSX-T deployments have at least a single Tier-1 gateway deployed for future
expandability and network services support.
Physical Router
VLAN
segment
N-VDS N-VDS SR
Tier-0
EDGE EDGE Gateway
DR
Edge Cluster
VM VM VM VM VM VM
Procedures
In this section, you create the App1 and Shared-Services NSX-T Tier-1 gateways and overlay segments
for application deployment. This section assumes you have a properly configured and operational Tier-0
Gateway.
Step 2: Navigate to Networking > Tier-1 Gateways, and then click Add Tier-1 Gateway.
Step 3: In the Tier-1 Gateway Name box, enter App1 Gateway.
Step 4: In the Linked Tier-0 Gateway list, select Tier-0 Gateway.
Step 6: In the Tags box, enter App1, and then click the plus (+) icon.
Step 7: Expand the Route Advertisement section, and enable All Connected Segments and Service Ports,
and then click Save.
Step 8: Repeat this procedure for the Shared-Services Tier-1 gateway in Table 5.
In this procedure you deploy an overlay segment and attach it to a Tier-1 gateway.
Step 4: In the Connected Gateway and Type list, select App1 Gateway | Tier-1.
Step 5: In the Set Subnets column, click select Set Subnets.
Step 6: In the Set Subnets dialog box, click Add Subnet.
Step 7: In the Gateway IP/Prefix Length box, enter 10.5.101.1/24, and then click Add.
Step 9: In the Transport Zone list, select tz-overlay | Overlay, and then click Save.
The last step is attaching the application workloads to the Tier-1 gateway segments. In this procedure, you
connect the VM NICs to the overlay segments that are advertised from NSX-T Manager to vCenter.
Step 2: Navigate to Datacenter > Compute Cluster, right click App1-WEB-1 virtual machine, and then
select Edit Settings.
Step 3: In the Network Adapter 1 list, select App1 Segment, and then click OK.
Step 4: Repeat this procedure for all virtual machines listed in Table 7.
Physical Router
Tier-0 VLAN
N-VDS N-VDS
Gateway segment
EDGE EDGE
Edge Cluster
Downlink Downlink
Application Shared-Services
Tier-1
Gateway
VM VM VM VM VM VM
Procedures
In this section, you deploy north-south VM-Series firewalls to each Tier-1 gateway using the partner
service catalog items in NSX-T Manager. Lastly, you configure security policy for the north-south traffic
for each application trust zone.
First, you deploy two VM-Series firewalls in HA in the Security Cluster and attach them to the NSX-T App1
Tier-1 gateway. This procedure assumes that you have at least two VM-Series firewall licenses available
for each service definition deployment.
Note
Notify Health
Name Device group Template stack group Insertion type check
Step 2: Navigate to Advanced Networking & Security > Partner Services > Catalog.
Step 3: In the Registered Services tiles, find the entry for NS Tier-1 App1.
Step 4: Select the VM-Series firewall image from the Please select a file list. The image information
comes from the Ovf URL field in the service definition created in Procedure 4.5.
Step 5: Click DEPLOY to launch the deployment details pane, and then click Proceed.
Next, you enter the Partner Service details. This information tells NSX-T Manager which Partner Service
and gateway to use when deploying the VM-Series firewall.
NSX-T Manager prepopulates the Partner Service field. Selecting a Partner Service populates the Deploy-
ment Specification field.
Step 7: Click the Logical Router field, select App1 Gateway, and then click Next.
Step 8: Click in the Compute Manager field, and then select vCenter.
Step 9: Click in the Cluster field, and then select Security Cluster.
Note
You can deploy the VM-Series firewall on any cluster that does not include any
Edge VM Transport Nodes.
Step 10: (Optional) If you have created any on vCenter Server, select the Resource Pool.
Step 11: In the Datastore list, select a datastore. When deploying in High Availability mode, you must
deploy the VM-Series by using shared storage because specific hosts are not selectable for the deployment.
Step 13: In the Failure Policy list, select Block. The failure policy defines how NSX-T Manager handles
traffic directed to the VM-Series firewall if the firewall becomes unavailable.
Step 14: Enter the IP address, gateway, subnet mask, and port group for the VM-Series firewall manage-
ment port.
Step 15: If you are deploying the VM-Series firewall in HA mode, repeat the previous step for secondary
firewall instance.
Step 17: Click on the Deployment Template list and select the deployment template. Choosing a de-
ployment template automatically populates the template properties. Do not edit the Template Property
settings.
It can take several minutes for the deployment to complete. In NSX-T manager you can click the refresh
button at the bottom of page to refresh the deployment status. You can also view the deployment progress
in the vCenter Recent Tasks pane as NSX-T manager is deploying, configuring, and powering on the
VM-Series firewalls.
Step 19: Navigate to Advanced Networking & Security > Partner Services > Service Instances, and in the
Partner Service list, select NS Tier-1 App1.
Step 20: Navigate to System > Service Deployments > Deployment, and in the Partner Service list, select
NS Tier-1 App1.
Step 21: Verify that the VM-Series firewalls have registered to Panorama. It will take several minutes for
the VM-Series firewalls to become operational.
Step 24: Confirm that your deployed VM-Series firewalls are listed under the NS Tier-1 App1 device group
and the Device State shows Connected.
Step 25: Repeat this procedure for the NS Tier-1 Shared-Services service definition in Table 8.
Note
Starting with PAN-OS 9.0.4, you must change the predefined, default
administrator password (admin/admin) on the first login on a device. The new
password must be a minimum of eight characters and include a minimum of
one lowercase and one uppercase character, as well as one number or special
character.
Step 5: In the New Password box, enter the new password.
Step 6: In the Confirm New Password box, reenter the new password, and click OK.
Step 8: Select Commit, and then click Commit to save the new admin password.
Step 9: Repeat this procedure for each VM-Series in the NS Tier-1 App1 and NS Tier-1 Shared-Services
deployments.
Complete the following procedure to direct traffic to your VM-Series firewall. For north-south traffic,
redirection rules are stateless by default and cannot be changed. Additionally, NSX-T automatically
creates a corresponding reflexive rule for return traffic.
Step 2: Navigate to Security > Network Introspection (N-S) and click Add Policy.
Step 8: In the Action list, select Redirect. This sends traffic to your VM-Series firewall.
Step 9: Make sure the rule is enabled using the slider switch. It should be green.
Step 10: Click Publish. NSX-T Manager publishes the redirection rule you just created and automatically
creates a reflexive rule for return traffic.
Note
The reflexive rule does not appear in the NSX-T Manager web interface.
Step 11: Repeat this procedure for the NS Tier-1 Shared-Services policy and rule definition in Table 9.
Now that you have deployed the VM-Series firewall and created traffic redirection rules to send traffic to
the firewall, you can use Panorama to centrally manage security policy rules on the VM-Series firewall.
Security Pre Rules are added to the top of the rule order and are evaluated first. You cannot override Pre
Rules on the local device.
First, you create the inbound security policy rules the NS Tier-1 App1 device group.
Step 3: Navigate to Policies > Security > Pre Rules, and then click Add.
Step 5: On the Source tab, under Source Zone, click Add.
Step 7: On the Destination tab, in the Destination Zone pane, click Add.
Step 10: On the Application tab, in the Applications pane, click Add.
Step 11: In the search box, enter web-browsing, and then in the results list, select web-browsing.
Step 12: In the search box, enter ssl, and then in the results list, select ssl.
Step 13: On the Actions tab, in the Action list, choose Allow.
Step 16: On the Target tab, select Any (target to all devices), and then click OK.
Step 17: Navigate to Policies > Security > Pre Rules, and then click Add.
Step 19: On the Source tab, under Source Zone, click Add.
Step 21: On the Destination tab, in the Destination Zone pane, click Add.
Step 24: On the Application tab, in the Applications pane, click Add.
Step 25: In the search box, enter dns, and then in the results list, select dns.
Step 26: In the search box, enter apt-get, and then in the results list, select apt-get.
Step 27: In the search box, enter active-directory, and then in the results list, select active-directory.
Step 28: On the Actions tab, in the Action list, choose Allow.
Step 31: On the Target tab, select Any (target to all devices), and then click OK.
Next, you create the inbound security policy rules the NS Tier-1 Shared-Services device group.
Step 33: Navigate to Policies > Security > Pre Rules, and then click Add.
Step 35: On the Source tab, under Source Zone, click Add.
Step 37: On the Destination tab, in the Destination Zone pane, click Add.
Step 40: On the Application tab, in the Applications pane, click Add.
Step 41: In the search box enter dns, and then in the results list, select dns.
Step 42: In the search box, enter active-directory, and then in the results list, select active-directory.
Step 43: On the Actions tab, in the Action list, choose Allow.
Step 46: On the Target tab, select Any (target to all devices), and then click OK.
Step 47: Navigate to Policies > Security > Pre Rules, and then click Add.
Step 49: On the Source tab, under Source Zone, click Add.
Step 51: On the Destination tab, in the Destination Zone pane, click Add.
Step 54: On the Application tab, in the Applications pane, click Add.
Step 55: In the search box enter apt-get, and then in the results list, select apt-get.
Step 56: On the Actions tab, in the Action list, choose Allow.
Step 59: On the Target tab, select Any (target to all devices), and then click OK.
Step 60: On the Commit menu, click Commit and Push, and then click Commit and Push.
N-VDS N-VDS
VM VM VM VM
Application Cluster
Procedures
In this section, you create NSX-T Security Groups and apply tags to the VMs in the NSX_T inventory. You
then deploy VM-Series firewalls to each ESXi Hypervisor host in the compute cluster using the partner
service catalog items in NSX-T Manager. Next, you create east-west traffic introspection rules to direct
traffic to the VM-Series firewalls. Lastly, you configure security policy for the east-west traffic for each
application tier.
Add tags to the VMs in the NSX-T inventory. The tags are used to group virtual machines in NSX-T Securi-
ty Groups.
VM name Tag
App1-WEB-1 Web
App1-WEB-2
App1-App App
App1-DB DB
Step 3: You should see a list of virtual machines deployed in your vCenter compute clusters.
Step 4: Click the 3 vertical dots next to the App1-WEB-1 virtual machine, and then select Edit.
Step 5: In the Tag box, enter Web, click the plus (+) icon, and then click Save.
Step 6: Repeat this procedure for all virtual machines in Table 10.
Create NSX-T Security Groups. These groups are used to group virtual machines and create the east-west
traffic introspection policy.
Step 2: Navigate to Inventory > Groups, and then click Add Group.
Step 5: In the Select Members | App1-Web-Group dialog box, click Add Criteria.
Step 11: Repeat this procedure for the security groups in Table 11.
Next, you verify that the virtual machines tagged in Procedure 7.1 are added to the security groups.
Step 12: In the App1-Web-Group Compute Members column, click View Members.
Deploy VM-Series firewalls to all hosts in the compute cluster. This procedure assumes that you have at
least two VM-Series firewall licenses.
Note
Step 5: In the Service Deployment Name box enter EW Host-Based App1.
Note
Note
You need to set the agent datastore value on each of the ESXi compute hosts.
Log in to the vCenter Web Client and navigate to Host > Manage > Settings >
Virtual Machines > Agent VM Settings. Click Edit, select the datastore and
network, and save the changes.
If you don’t set the host datastore value, you see the following error when
trying to deploy host-based VM-Series: “No agent vm datastore. No agent
datastore configuration on host.”
For more information, see the knowledge base article Guest Introspection VM
Installation Fails.
Step 11: In the Network for eth0—Management Nic list, select Management Network.
Step 18: In the Transport Zone (Overlay) field, select tz-overlay from the list.
Step 25: Confirm that your deployed VM-Series firewalls are listed and that the Deployment Status
shows Up.
Next, you verify that your firewalls are connected to Panorama. It can take several minutes for the fire-
walls to become completely operational.
Step 28: Confirm that your deployed VM-Series firewalls are listed under the EW Host-Based App1 device
group and the Device State shows Connected.
Note
Starting with PAN-OS 9.0.4, you must change the predefined, default
administrator password (admin/admin) on the first login on a device. The new
password must be a minimum of eight characters and include a minimum of
one lowercase and one uppercase character, as well as one number or special
character.
Step 5: In the New Password box, enter the new password.
Step 6: In the Confirm New Password box, reenter the new password, and click OK.
Step 8: Select Commit and then click Commit to save the new admin password.
Repeat this procedure for each VM-Series in the EW Host-Based App1 deployment.
A service chain is a grouping of services set in logical sequence. When traffic is redirected to the service
chain, it moves through each service in the order you configure.
Step 1: Navigate to Security > Network Introspection (E-W) > Service Chains > Add Chain.
Now you set the forward path. The service chain is a logical sequence of service profiles, so traffic moves
through the services in the order you specify as the forward path.
Step 4: In the Forward Path column, click Set Forward Path.
Step 5: In the Set Forward Path dialog box, click Add Profile in Sequence.
Step 6: In the Profile list, select east-west, then click Add.
Step 8: In the Reverse Path column, check Inverse ForwardPath for return traffic to move through the
service chain in reverse order.
Step 9: In the Failure Policy column, select Block. This defines the action NSX-T takes if a service profile
fails.
Complete the following procedure to direct traffic to your East-West Host-Based VM-Series firewalls. You
configure policy rules to direct traffic between groups of virtual machines to the VM-Series firewalls.
App1-App-Group
App1-DB-Group
App1-DB-Group
App1-App-Group
Step 2: Navigate to Security > Network Introspection (E-W) > Rules, and then click Add Policy.
Step 7: In the Sources column, click the pencil icon and check the App1-Web-Group, and then click Apply.
Step 8: In the Destinations column, click the pencil icon and check the App1-Web-Group, App1-App-
Group, and App1-DB-Group, and then click Apply.
Step 9: In the Applied To column, click the pencil icon, and then in the Select Applied To button, select
Groups.
In this procedure, you map the NSX-T Security Groups into Panorama DAGs that you use to create east-
west security policy.
Step 1: On the primary Panorama server, at the top of the page, in the Context list, choose Panorama.
Note
Some browser extensions may block API calls between Panorama and NSX-T,
which prevents Panorama from receiving match criteria. If Panorama displays
no match criteria and you are using browser extensions, disable the extensions
and synchronize dynamic objects to populate the tags available to Panorama.
Step 7: Find east-west_App1-Web-Group then click the plus (+) icon next to the security group name to
add it to the dynamic address group.
Note
The security groups that display in the match criteria dialog are derived
from the groups you defined on NSX-T Manager. Only the groups that are
referenced in the security policies and from which traffic is redirected to the
VM-Series firewall are available here.
Step 9: Repeat these steps for each dynamic address group in Table 13.
Step 10: On the Commit menu, choose Commit to Panorama, and then click Commit.
Now that you have created the introspection rules on the NSX-T Manager and the dynamic address groups
in Panorama, you can create the security policies on the VM-Series firewalls.
First, you create security rules permitting web to application group traffic flows.
Step 1: At the top of the page, in the Context list, choose Panorama.
Step 3: Navigate to Policies > Security > Pre Rules, and then click Add.
Step 5: On the Source tab, under Source Zone, click Add.
Step 7: In the Source Address list, choose App1 Web Group.
Step 8: On the Destination tab, under Destination Zone, click Add.
Step 10: In the Destination Address list, choose App1 App Group.
Step 11: On the Application tab, in the Applications pane, click Add.
Step 12: In the search box, enter soap, and then in the results list, select soap.
Step 13: On the Actions tab, in the Action list, choose Allow.
Step 15: On the Target tab, select Any (target to all devices), and then click OK.
Caution
Make sure to target all devices (any) in the device group. Otherwise, the policy
rule will not be automatically applied to new group members.
Now you create security rules permitting application to database group traffic flows.
Step 16: At the top of the page, in the Context list, choose Panorama.
Step 18: Navigate to Policies > Security > Pre Rules, and then click Add.
Step 20: On the Source tab, under Source Zone, click Add.
Step 22: In the Source Address list, choose App1 App Group.
Step 23: On the Destination tab, under Destination Zone, click Add.
Step 26: On the Application tab, in the Applications pane, click Add.
Step 27: In the search box, enter mysql, and then in the results list, select mysql.
Step 28: On the Actions tab, in the Action list, choose Allow.
Step 30: On the Target tab, select Any (target to all devices), and then click OK.
Caution
Make sure to target all devices (any) in the device group. Otherwise, the policy
rule will not be automatically applied to new group members.
Step 31: On the Commit menu, click Commit and Push, and then click Commit and Push.
Configuring Notify-Groups
In this section, you add the NSX-T security groups VM information to north-south dynamic address
groups. Then you update the north-south security policy with more specific inbound destinations.
In this procedure, you map the NSX-T Security Groups into Panorama DAGs, which you use to create
update the north-south security policy with more specific destination information.
Step 1: On the primary Panorama server, at the top of the page, in the Context list, choose Panorama.
Step 3: Navigate to Objects > Address Groups, and then click Add.
Note
Some browser extensions may block API calls between Panorama and NSX-T,
which prevents Panorama from receiving match criteria. If Panorama displays
no match criteria and you are using browser extensions, disable the extensions
and synchronize dynamic objects to populate the tags available to Panorama.
Step 7: Find east-west_App1-Web-Group, and then click the plus (+) icon next to the security group
name to add it to the dynamic address group.
Note
The security groups that display in the match criteria dialog are derived from
the groups you defined on the NSX-T Manager. Only the groups that are
referenced in the security policies and from which traffic is redirected to the
VM-Series firewall are available here.
Step 9: Repeat these steps for each dynamic address group in Table 13.
Step 10: Repeat this procedure for the NS Tier-1 Shared-Services device group.
Step 11: On the Commit menu, select Commit to Panorama and then click Commit.
Now that you have added dynamic address groups to the north-south device group, you can update the
inbound security policy. In this procedure, you add a dynamic address group to the destination address of
the inbound security policy.
Step 4: Select the App1 Inbound rule you created in Procedure 6.4.
Step 5: On the Destination tab, under Destination Address, click Add.
Step 7: On the Commit menu, click Commit and Push, and then click Commit and Push.
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
http://www.paloaltonetworks.com [email protected]
© 2020 Palo Alto Networks, Inc. Palo Alto Networks is a registered trademark of Palo Alto Networks. A list of our
trademarks can be found at http://www.paloaltonetworks.com/company/trademarks.html. 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.
B-000176P-20a