Pan Os New Features

PAN-OS ® New Features Guide
10.2
docs.paloaltonetworks.com
Contact Informaon
Corporate Headquarters:
Palo Alto Networks
3000 Tannery Way
Santa Clara, CA 95054
www.paloaltonetworks.com/company/contact-support.html
About the Documentaon

• For the most recent version of this guide or for access to related documentaon, visit the
Technical Documentaon portal docs.paloaltonetworks.com.
• To search for a specific topic, go to our search page docs.paloaltonetworks.com/search.html.
• Have feedback or quesons for us? Leave a comment on any page in the portal, or write to us
at documentaon@paloaltonetworks.com.
Copyright
Palo Alto Networks, Inc.
www.paloaltonetworks.com
©2021–2022 Palo Alto Networks, Inc. Palo Alto Networks is a registered trademark of Palo
Alto Networks. A list of our trademarks can be found at www.paloaltonetworks.com/company/
trademarks.html. All other marks menoned herein may be trademarks of their respecve
companies.
Last Revised
June 6, 2022
PAN-OS ® New Features Guide Version 10.2 2 ©2022 Palo Alto Networks, Inc.
Table of Contents
Panorama Features.............................................................................................5
Administrator-Level Push...........................................................................................................6
Automac Content Push for VM-Series and CN-Series Firewalls................................... 8
Log Collector Health Monitoring on Panorama................................................................. 10
IoT Security Features.......................................................................................11

Simplified IoT Security Onboarding.......................................................................................12
Data Collecon for IoT Security............................................................................................ 15
Management Features.................................................................................... 25
AIOps for NGFW.......................................................................................................................26
Selecve Commit of Configuraon Changes......................................................................27
Simplified Soware Upgrade.................................................................................................. 28
Networking Features.......................................................................................29
Advanced Roung Engine....................................................................................................... 30
IPv4 Mulcast for Advanced Roung Engine.................................................................... 31
Policy Features..................................................................................................33
Security Policy Rule Top-Down Order When Wildcard Masks Overlap.......................34
Content Inspecon Features.........................................................................37

Advanced Threat Prevenon: Inline Cloud Analysis......................................................... 38
Domain Fronng Detecon.................................................................................................... 40
Decrypon Features........................................................................................41
Mulple Cerficate Support for SSL Inbound Inspecon................................................42
URL Filtering Features.................................................................................... 45

Inline Deep Learning Analysis for Advanced URL Filtering.............................................46
HTTP Header Expansion......................................................................................................... 48
Mobile Infrastructure Security Features.................................................... 51

New Deployment Opon for GTP Security in 3G/4G Networks.................................. 52
Mobile Network Security Support on New Mid-Range Hardware Plaorms..............54
Virtualizaon Features....................................................................................59
CN-Series Firewall as a Kubernetes CNF............................................................................60
High Availability Support for CN-Series Firewall as a Kubernetes CNF.......................61
High Availability Support for CN-Series Firewall on AWS EKS......................................62
DPDK Support for CN-Series Firewall................................................................................. 63
Table of Contents
Daemonset(vWire) IPv6 Support........................................................................................... 64

Panorama Plugin for Kubernetes 3.0.0................................................................................ 65
L3 IPV4 Support for CN-Series............................................................................................. 68
47 Dataplane Cores Support for VM-Series and CN-Series Firewalls.......................... 69
Memory Scaling of the VM-Series Firewall........................................................................ 70
PAN-OS SD-WAN Features.......................................................................... 71

Copy ToS Header Support.......................................................................................................72
Enterprise Data Loss Prevenon Features................................................ 73

Web Form Data Inspecon for Enterprise Data Loss Prevenon..................................74
Panorama Features
> Administrator-Level Push
> Automac Content Push for VM-Series and CN-Series Firewalls
> Log Collector Health Monitoring on Panorama
5
Panorama Features
Administrator-Level Push
PAN-OS 10.2 enables Panorama administrators to push just their own configuraon changes to
managed firewalls. Addionally, a Panorama administrator can specify one or more Panorama
administrators with commied configuraon changes to include in the push. Leveraging an
administrator-level push to managed firewalls reduces the risk of pushing incomplete device
group and template configuraons to managed firewalls by allowing you to explicitly exclude
incomplete configuraon changes when you push to managed firewalls. This helps migate and
avoid potenal outages and configuraon related issues that could cause network disrupons.
For mul-vsys managed firewalls running PAN-OS 10.2, configuraons in the Shared device group
are now pushed to a Shared configuraon context for all virtual systems rather than duplicang
the shared configuraon to each virtual system. This reduces the operaonal burden of scaling
configuraons for mul-vsys firewalls.
STEP 1 | Log in to the Panorama web interface.
STEP 2 | Aer you upgrade to PAN-OS 10.2, Commit and Push to Devices the enre Panorama
managed configuraon to your managed firewalls.
This is required to ulize the administrator-level push and leverage the improved shared
configuraon object management for mul-vsys firewalls managed by Panorama.
STEP 3 | (Oponal) Create a custom Panorama admin role to allow the Panorama administrator to
push configuraon changes for other admins.
The default Superuser or Panorama admin role privileges support full object level configuraon
privileges.
1. Select Panorama > Admin Roles and Add a new admin role.
2. Enter a descripve Name for the admin role.
3. Select the Panorama admin role.
4. Select Web UI and navigate to the Commit privileges.
5. Configure the object level configuraon privileges as needed.
All object level configuraon privileges are enabled by default.
• Push All Changes—Allow the administrator to push all changes made by all admins.
• Push For Other Admins—Allows the administrator select and push configuraon
changes made by other administrators.
• Object Level Changes—Allows the administrator to view individual configuraon
objects to push. If disabled, the list of configuraon objects is not displayed in the
Push Scope.
6. Click OK.
7. Configure a Panorama administrator and select the Admin Role you created.
8. Commit and Commit to Panorama.
STEP 4 | Perform device group and template stack configuraon changes and Commit > Commit to
Panorama.
See Selecve Commit of Configuraon Changes to make object-level selecons to commit.
Panorama Features
STEP 5 | Perform an administrator-level push to managed firewalls.

1. Select Commit > Push to Devices and select Commit Changes Made By to only push
your own configuraon changes.
2. (Oponal) Click the admin name displayed next to the Commit Changes Made By field to
modify the Admin Scope and include configuraon changes made by other admins in the
commit.
3. Expand the list of device groups and template stacks to review configuraon changes.
4. Push.
Panorama Features
Automac Content Push for VM-Series and CN-Series

Firewalls
PAN-OS 10.2 introduces the ability to automacally push the latest Anvirus and Applicaons
and Threats content updates on first connecon when onboarding a new VM-Series and CN-
Series firewall to the Panorama™ management server. When leveraging auto-scale, enabling this
seng allows you to maintain exisng images for VM-Series and CN-Series firewalls leveraging
dynamic content in their configuraons, such as in policies and App-ID. This helps eliminate the
operaonal overhead required to update VM-Series and CN-Series firewall images when new
dynamic content update versions are introduced.
Panorama aempts to push the installed dynamic content updates on the first connecon only
and does not aempt any subsequent pushes if the inial push fails for any reason.
For example, you add a VM-Series firewall to Panorama management and enable Auto Push on
1st Connect to automacally push the device group and template stack configuraon to the VM-
Series firewall on first connecon. However, the template stack contains an invalid configuraon
and the push to the VM-Series firewall fails. In this scenario, the automac content push to the
VM-Series firewall also fails because the configuraon push and dynamic content version push are
included in the same push operaon to the VM-Series firewall.
VM-Series firewalls deployed on NSX and hardware firewalls are not supported.
STEP 2 | Install the latest dynamic content updates on Panorama.

This is required to automacally push the Anvirus and Applicaons and Threats content
updates. Panorama only the Anvirus and Applicaons and Threats versions it has installed to
VM-Series and CN-Series firewalls.
STEP 3 | Configure Panorama to automacally push the latest dynamic content updates to VM-Series
and CN-Series firewalls on first connecon.
This step assumes you have already configured a template stack for your VM-Series and CN-
Series firewall configuraon.
1. Select Panorama > Templates and click the template stack that contains the VM-Series
and CN-Series firewall configuraon.
2. Check (enable) Automacally push content when soware device registers to
Panorama.
3. Click OK.
STEP 4 | Commit and Commit to Panorama.
STEP 5 | Add a Firewall as a Managed Device.

When adding the VM-Series or CN-Series firewall to Panorama management, be sure to
Associate Devices and assign the firewalls to the Template Stack where you enabled Panorama
Panorama Features
to automacally push the dynamic content updates installed on Panorama to the firewalls on
first connecon.
Panorama does not push the installed dynamic content updates if the VM-Series or CN-Series
firewall is not assigned to a Template Stack prior to first connecon.
STEP 6 | Verify the dynamic content version installed on the firewall.

1. Select Panorama > Managed Devices > Summary and locate the managed firewalls you
added.
2. Verify the Device State is Connected.
3. Verify the Anvirus and Apps and Threat versions match the versions installed on
Panorama.
Panorama Features
Log Collector Health Monitoring on Panorama

The Panorama management server now supports centralized visibility into the managed Log
Collector health status. The Log Collector health status is based on the health status of vital Log
Collector processes and you can view both the overall health status and the health status of each
log collecon process. You can monitor the status of these processes to help idenfy and resolve
issues impacng log collecon.
STEP 1 | Log in to the Panorama web inteface.
STEP 2 | Select Panorama > Managed Collectors and navigate to the Health column.
STEP 3 | Review the overall health status of the Log Collector.

A green circle ( ) indicates that the Log Collector is healthy and red circle ( ) indicates
that one or more log collecon processes are experiencing degraded health.
STEP 4 | View the Health Status details to view the health status of each log collecon process.
• logd— Process responsible for ingesng logs received from the managed firewall and for
transferring ingested logs to the vldmgr.
• vldmgr—Process responsible for managing the vld processes.
• vlds—Process responsible for managing individual logging disks, wring logs to the logging
disks, and ingesng logs into ElascSearch.
• es—ElascSearch process running on the Log Collector.
IoT Security Features
> Simplified IoT Security Onboarding
> Data Collecon for IoT Security
11
Simplified IoT Security Onboarding

When onboarding IoT Security, a part of the firewall setup involves creang a Log Forwarding
profile and applying it to Security policy rules. From PAN-OS 10.2, you simply select a predefined
Log Forwarding profile and apply it to as many rules as you like in bulk.
To use this workflow, you must have already configured Security policy rules, enabled
logging on the rules, and enabled logging services with enhanced applicaon logging.
STEP 1 | Apply a Log Forwarding profile for IoT Security to Security policy rules.
1. Log in to your next-generaon firewall, select Policies > Log Forwarding for Security
Services in the Policy Opmizer secon.
2. To view all your Security policy rules—including those with a Log Forwarding profile and
those without it—choose All for Log Forwarding Profile.
3. Select the rules for which you want to forward logs to the logging service and Aach Log
Forwarding Profile.
4. To apply the default Log Forwarding profile to your rules, choose IoT Security Default
Profile - EAL Enabled and then OK.
The default profile is preconfigured to provide IoT Security with all the log types it requires,
including enhanced applicaon logs (EALs).
You don’t have to select Enable Enhanced IoT Logging because enhanced
applicaon logging (EAL) is already enabled on IoT Security Default Profile.
or
To add the forwarding of EALs to an exisng Log Forwarding profile that doesn’t already
have it, choose it from the Log Forwarding Profile list, select Enable Enhanced IoT Logging,
and then OK.
When you select Enable Enhanced IoT Logging, PAN-OS updates the chosen Log
Forwarding profile itself and thereby enables enhanced log forwarding on all rules
that use the same Log Forwarding profile.
PAN-OS adds the chosen Log Forwarding profile to those rules that don’t already have one
and replaces previously assigned profiles with this one.
STEP 2 | Commit your changes.
Data Collecon for IoT Security

Unless device traffic is visible to a firewall, the firewall cannot include it in the logs it forwards
to IoT Security. When you need to collect data for devices whose traffic doesn't pass through a
firewall, mirror their traffic on network switches and use Encapsulated Remote Switched Port
Analyzer (ERSPAN) to send it to the firewall through a Generic Roung Encapsulaon (GRE)
tunnel. Aer the firewall decapsulates the traffic, it inspects it similar to traffic received on a TAP
port. The firewall then creates enhanced applicaon logs (EALs) and traffic, threat, WildFire, URL,
data, GTP (when GTP is enabled), SCTP (when SCTP is enabled), tunnel, auth, and decrypon logs.
It forwards them to the logging service where IoT Security can access and analyze the IoT device
data.
You can use this feature for any deployments where traffic from remote switches needs to
be inspected. IoT Security is just one use case.
This feature requires switches that support ERSPAN such as Catalyst 6500, 7600, Nexus,
and ASR 1000 plaorms.
STEP 1 | Configure a switch that supports ERSPAN to mirror traffic on one or more source ports or
VLANs, and forward it through a GRE tunnel to a desnaon port on a next-generaon
firewall.
For configuraon instrucons, see the Cisco documentaon for your switch.
STEP 2 | Enable ERSPAN support on the firewall.

By default, ERSPAN support is disabled.
1. Log in to the firewall and select Device > Session > Edit (for Session Sengs).
2. Enable ERSPAN Support and then OK.
The ERSPAN Support check box in the Session Sengs secon is now selected.
STEP 3 | Commit your change.
STEP 4 | Create a Layer 3 security zone specifically to terminate the GRE tunnel and receive mirrored
IoT device traffic from the source port on the network switch.
1. Select Network > Zones and Add a zone.
2. Enter the following and leave the other sengs at their default values:
Name: Enter a meaningful name for the zone such as ERSPAN-IoT-data.
Log Seng: Select IoT Security Default Profile or another log forwarding profile that sends
the required types of logs to the logging service for IoT Security.
You must already have logging services enabled on the firewall.
Type: Layer3
3. Click OK.
STEP 5 | Create a Layer 3 interface and bind it to the zone you just created.
1. Select Network > Interfaces > Ethernet and then click the Ethernet interface on which you
want to terminate the GRE tunnel from the switch. Oponally, use a subinterface.
Comment: Enter a meaningful note about the interface for later reference.
Interface Type: Layer3
Virtual Router: Choose the virtual router you want to route to the interface. Consider using
a separate virtual router exclusively for ERSPAN traffic.
Security Zone: Choose the zone you just created.
3. Click IPv4, select Stac for the address type, and Add an IP address for the interface.
The switch uses this in its GRE tunnel configuraon as the IP address of its peer.
4. Click Advanced and either add a New Management Profile or select a previously defined
profile that allows the Ethernet interface to accept different types of administrave traffic.
5. Click OK to save the new interface management profile and then click OK again to save the
Ethernet interface configuraon.
STEP 6 | Create a tunnel interface with an IP address in the same subnet as that of the corresponding
tunnel interface on the switch and bind it to the zone you just created.
1. Select Network > Interfaces > Tunnel and Add the logical tunnel interface for the GRE
tunnel from the switch.
Interface Name: The field on the le is read-only and contains the text “tunnel”. Enter a
number in the field on the right to complete the name. For example, enter 8 to make the
name tunnel.8.
Virtual Router: Choose the same router you used for the Layer 3 interface.
Security Zone: Choose the same zone to which you bound the Layer 3 interface.
3. Click IPv4 and Add an IP address that’s in the same subnet as the IP address of the logical
tunnel interface on the switch.
4. Click Advanced and either add a New Management Profile, or select a previously defined
profile, to allow the tunnel interface to accept different types of administrave traffic.
5. Click OK.
STEP 7 | Configure stac routes for the virtual router (VR) for ERSPAN.
1. Select Network > Virtual Routers and click the virtual router for ERSPAN.
2. Click Stac Routes and then click + Add.
Name: Enter a name for the stac route.
Desnaon: 0.0.0.0/0
If you know the subnets beyond the switch, create individual stac routes for each
of them. Otherwise, use a separate VR for ERSPAN and set a default route.
Interface: ethernet1/3 (the interface you previously configured)

Next Hop: None
4. Click OK.
STEP 8 | Configure a GRE tunnel with ERSPAN enabled.

1. Select Network > GRE Tunnels and click + Add.
Name: Enter a name for the GRE tunnel; for example, GRE-ESPAN-for-IoT-data
Interface: Choose the Layer 3 interface you configured for GRE tunnel terminaon.
Local Address: Choose IP and the IP address of the Layer 3 interface where the GRE tunnel
terminates.
Peer Address: Enter the IP address of the switch egress interface from which it iniates the
GRE tunnel.
Tunnel Interface: Choose the logical tunnel interface you configured for the GRE tunnel.
ERSPAN: (select)
3. Click OK.
The IP addresses of the Ethernet and tunnel interfaces in relaon to each other and the rest
of the network look like this.
Management Features
> AIOps for NGFW
> Selecve Commit of Configuraon Changes
> Simplified Soware Upgrade
25
Management Features
AIOps for NGFW

Available for all PAN-OS 10.0 and later devices, AIOps for NGFW is a new applicaon on the
hub that analyzes PAN-OS device telemetry and best pracce assessment results to give you a
comprehensive understanding of your deployment health and security posture.
AIOps is available as a Free er and a Premium er. Unl May 2022, you can evaluate the
Premium er at no cost.
Onboard your devices and get started with AIOps now.
Management Features
Selecve Commit of Configuraon Changes

To allow for greater control of configuraon changes, PAN-OS 10.2 enables you to specify
which administrator configuraon changes to include in a commit and allows you select
individual configuraon objects. Leveraging selecve commit allows you to maintain your defined
operaonal procedure while sll being able to successfully make independent configuraon
changes not defined in your operaonal scope. This helps migate and avoid potenal outages
and configuraon related issues that could cause network disrupons.
STEP 1 | Log in to the firewall web interface.
STEP 2 | Make any configuraon changes as needed.
STEP 3 | Perform a selecve commit.

1. Select Commit Commit > Commit to Panorama and select Commit Changes Made By to
commit only your own configuraon changes.
(Panorama managed firewalls) On Panorama, select Commit > Commit to

Panorama. Addionally, the Commit and Push operaon is also supported and
allows you to make the same object level configuraon selecons to commit.
2. (Oponal) Click the admin in displayed next to the Commit Changes Made By field to
modify the Admin Scope and include configuraon changes made by other admins in the
commit.
3. Expand the list of configuraon changes to review.
4. In the Include in Commit column, uncheck (clear) a configuraon object to not include in
the commit.
All configuraon changes made by admins in the Admin Scope are included by default.
5. Commit.
STEP 4 | (Panorama managed firewalls only) Perform an Administrator-Level Push.
Management Features
Simplified Soware Upgrade

You can now upgrade Panorama appliances running PAN-OS 10.2 and Panorama-managed
devices running earlier releases more quickly using a simplified soware upgrade process.
This process reduces the number of tasks and increases the efficiency of the soware install
by enabling you to validate the install prior to the maintenance window. Before installing the
target soware version, you can view the soware and applicaons and threats content version
dependencies that must be downloaded first, which helps you avoid mulple installaon aempts.
A mul-image download opon is now available so you can choose to download the dependencies
displayed during the validaon check. The soware upgrade history is also available on devices
running PAN-OS 10.2.
Networking Features
The networking features for PAN-OS 10.2 are documented in the 10.2 PAN-OS
Networking Administrator’s Guide.
> Advanced Roung Engine

> IPv4 Mulcast for Advanced Roung Engine
29
Networking Features
Advanced Roung Engine

PAN-OS 10.2 offers an advanced roung engine that uses an industry-standard configuraon
methodology to reduce your learning curve. It allows the creaon of profile-based filtering
lists and condional route maps, all of which can be used across logical routers. These profiles
provide finer granularity to filter routes for each dynamic roung protocol and improve route
redistribuon across mulple protocols.
The Advanced Roung Engine uses logical routers, rather than virtual routers, to parcipate
in Layer 3 roung. You must enable advanced roung and configure at least one logical router
to use the Advanced Roung Engine. Perform the addional tasks that suit your networking
requirements.
STEP 1 | Enable advanced roung.
STEP 2 | Learn about logical routers.
STEP 3 | Configure a logical router and add interfaces to it.
STEP 4 | Create a stac route.
STEP 5 | Configure BGP on an advanced roung engine.
STEP 6 | Create BGP roung profiles for authencaon, mers, address families, dampening, route
redistribuon to BGP, and BGP filtering.
STEP 7 | Create filters for the advanced roung engine, such as access lists, prefix lists, AS Path access
lists, community lists, and route maps.
STEP 8 | Configure OSPFv2 on an advanced roung engine.
STEP 9 | Create OSPFv2 roung profiles for mers, authencaon, and route redistribuon to
OSPFv2.
STEP 10 | Configure OSPFv3 on an advanced roung engine.
STEP 11 | Create OSPFv3 roung profiles for mers, authencaon, and route redistribuon to
OSPFv3.
STEP 12 | Configure RIPv2 on an advanced roung engine.
STEP 13 | Create RIPv2 roung profiles for mers, authencaon, and route redistribuon to RIPv2.
STEP 14 | Create BFD profiles
Networking Features
IPv4 Mulcast for Advanced Roung Engine

PAN-OS 10.2.2 supports IPv4 mulcast on the Advanced Roung Engine. You configure IPv4
mulcast using PIM interface mer profiles and IGMP interface query profiles.
You can also create IPv4 mroutes for Reverse-Path Forwarding checks if you want unicast packets
to take a different route from mulcast packets.
STEP 1 | Enable advanced roung.
STEP 2 | Configure a logical router and add interfaces to it.
STEP 3 | Configure IPv4 mulcast by configuring PIM and IGMP.
STEP 4 | Create PIM interface mer profiles.
STEP 5 | Create IGMP interface query profiles.
Networking Features
Policy Features
> Security Policy Rule Top-Down Order When Wildcard Masks Overlap
33
Policy Features
Security Policy Rule Top-Down Order When Wildcard

Masks Overlap
Security policy rules have supported the use of source and desnaon addresses using a wildcard
address (IP address and wildcard mask separated by a slash, such as 10.1.2.3/0.127.248.0). The
wildcard address can idenfy many source or desnaon addresses in a single Security policy rule.
In earlier releases, if an address matched rules that had overlapping wildcard masks, the firewall
always matched the rule having the longest prefix in the wildcard mask and no other rules were
examined. This is sll the default behavior.
However, there are use cases where you want to have broad rules that allow some sources access
to generic applicaons (such as Ping, Traceroute, and web-browsing), but have narrower rules that
allow a subset of these sources access to different applicaons (such as SSH, SCP) in addion to
the generic applicaons. In earlier releases, such a deployment did not work because only the
match to the rule with the longest prefix in the wildcard mask was processed and other rules were
not considered. The workaround was to copy applicaons from the broader rules to the narrower
rules, which created operaonal complexies.
Beginning with PAN-OS 10.2.1, you can enable Wildcard Top Down Match Mode so that if a
packet with an IP address matches prefixes in Security policy rules that have overlapping wildcard
masks, the firewall chooses the first fully matching rule in top-down order (instead of choosing the
matching rule with the longest prefix in a wildcard mask). Wildcard Top Down Match Mode means
more than one rule has the potenal to be enforced on different packets (not just the rule with the
longest matching prefix). Place your more specific rules toward the top of the list. For example,
you can allow a smaller range of matching addresses (a longer wildcard mask) to access certain
applicaons, and also, in a subsequent rule allow a larger range of IP addresses (a shorter wildcard
mask) to access a different (more generic) set of applicaons.
STEP 1 | Enable Security policy rules to be evaluated in top-down order when a packet matches rules
that have overlapping wildcard masks.
1. Select Device > Setup > Management.
2. Edit the Policy Rulebase Sengs and select Wildcard Top Down Match Mode (disabled
by default).
3. Click OK.
Policy Features
STEP 2 | Create a Security Policy Rule that has a Source IP Address or Desnaon IP Address that is
an IP address/wildcard mask.
STEP 3 | Create another Security policy rule that uses the same source or desnaon IP address as
the rule in the prior step, and uses an overlapping wildcard mask. Place the more specific rule
closer to the top of the list.
STEP 4 | Commit.
Policy Features
Content Inspecon Features
> Advanced Threat Prevenon: Inline Cloud Analysis
> Domain Fronng Detecon
37
Advanced Threat Prevenon: Inline Cloud Analysis

Palo Alto Networks now operates a series of ML-based detecon engines in the Advanced
Threat Prevenon cloud to analyze traffic for advanced C2 (command-and-control) and spyware
threats in real-me to protect users against zero-day threats. By operang cloud-based detecon
engines, you can access a wide array of detecon mechanisms that are updated and deployed
automacally without requiring the user to download update packages or operate process
intensive, firewall-based analyzers which can sap resources. The cloud-based detecon engine
logic is connuously monitored and updated using C2 traffic datasets from WildFire, with
addional support through manual updates by Palo Alto Networks threat researchers, who
provide human intervenon for highly accurized detecon enhancements. Inline cloud analysis
supports five analysis engines for C2-based threats over HTTP, HTTP2, SSL, unknown-UDP,
and unknown-TCP. Addional analysis models are delivered through content updates, however,
enhancements to exisng models are performed as a cloud-side update, requiring no firewall
update. Inline cloud analysis is enabled and configured using the an-spyware profile and requires
an acve Advanced Threat Prevenon license.
STEP 1 | Log in to the PAN-OS web interface.
STEP 2 | To take advantage of inline categorizaon, you must have an acve Advanced Threat
Prevenon subscripon.
To verify subscripons for which you have currently-acve licenses, select Device > Licenses
and verify that the appropriate licenses are available and have not expired.
STEP 3 | Update or create a new An-Spyware Security profile to enable inline cloud analysis.
1. Select an exisng An-Spyware Profile or Add a new one (Objects > Security Profiles >
An-Spyware).
2. Select your An-Spyware profile and then go to Inline Cloud Analysis and Enable inline
cloud analysis.
3. Specify an Acon to take when a threat is detected using a corresponding analysis engine.
The following opons are available:
The default acon for each analysis engine is alert.
• Allow—The request is allowed and no log entry is generated.

• Alert—The request is allowed and a Threat log entry is generated.
• Drop—Drops the request; a reset acon is not sent to the host/applicaon.
• Reset-Client—Resets the client-side connecon.
• Reset-Server—Resets the server-side connecon.
• Reset-Both—Resets the connecon on both the client and server ends.
4. Click OK to exit the An-Spyware Profile configuraon dialog and Commit your changes.
STEP 4 | Install an updated firewall device cerficate used to authencate to the Advanced Threat
Prevenon inline cloud analysis service. Repeat for all firewalls enabled for inline cloud
analysis.
For addional informaon about configuring inline Cloud Analysis, including adding excepons,
verifying connecvity to the service, and monitoring details, refer to Configure Inline Cloud
Analysis.
Domain Fronng Detecon

Firewalls equipped with Threat Prevenon can now detect domain fronng, a TLS evasion
technique that can circumvent URL filtering database soluons and facilitate data exfiltraon. A
malicious user with a craed packet can indicate a fake website in the SNI while surrepously
connecng to a different website via the HTTP Host Header. Websites that are expressed using
domain fronng are unlikely to be on the allow list for users, as per corporate security policies.
When the domain entry differs between what is presented in the SNI (server name indicaon)
and HTTP payloads, the firewall generates a threat log with a unique threat ID of 86467 (as a
Spyware signature). To provide a context for threat assessment purposes, the threat log contains
the spoofed SNI domain in the URL/Filename (misc) threat log field, which is expressed as URL in
the threat log. A corresponding URL log showing the HTTP host header in the URL field, is also
available, which can be found by searching for the matching session ID.
Enable SSL decrypon to detect domain fronng techniques. You must also enable
inspecon of SSL/TLS handshakes by CTD at Device > Setup Session > Decrypon
Sengs > SSL Decrypon Sengs > Send handshake messages to CTD for inspecon.
In cases where certain apps are excluded from decrypon by default (such as Signal), you
must disable Exclude from Decrypon for the specific apps under Device > Cerficate
Management > SSL Decrypon Exclusion.
Decrypon Features
> Mulple Cerficate Support for SSL Inbound Inspecon
41
Mulple Cerficate Support for SSL Inbound Inspecon

You can now configure SSL Inbound Inspecon policy rules with up to 12 server cerficates.
Newly added support for mulple cerficates enables you to update cerficates on your
protected servers without decrypon downme. You can also configure rules to decrypt and
inspect traffic to servers that host mulple domains, each with a different cerficate.
To ensure a valid cerficate is always available, import the new server cerficate and key on your
firewall and add it to your Decrypon policy rule before updang your web server. The firewall
uses the old but valid server cerficate to proxy the connecon between the client and your
internal server to decrypt and inspect inbound SSL/TLS traffic. Aer you install the new cerficate
on your server, the firewall will use it for new SSL/TLS connecons as long as the cerficate in
your SSL Inbound Inspecon policy rule matches the server cerficate. If a cerficate mismatch
occurs, the session ends, and the Decrypon log entry reports the session-end reason as a firewall
and server cerficate mismatch.
™
(Panorama ) Support for mulple cerficates in SSL Inbound Inspecon policy rules is
unavailable in PAN-OS versions earlier than 10.2. If you push an SSL Inbound Inspecon
policy rule with mulple cerficates from a Panorama management server running PAN-
®
OS 10.2 to a firewall running an earlier version, only one cerficate is preserved in the
policy rule on the firewall.
Before pushing your Decrypon policy rule from Panorama, we recommend you set up
different templates or device groups for firewalls running PAN-OS 10.1 and earlier to
ensure you push the correct policy rule and cerficate to the appropriate firewalls.
Perform the following steps to update your firewall and SSL Inbound Inspecon rule with a newly
issued server cerficate.
STEP 1 | Import the new cerficate and private key for the internal server whose inbound SSL traffic
you want to decrypt and inspect to the firewall.
Depending on the TLS version in use, you may need to upload the end-enty (leaf)
cerficate as part of a cerficate bundle (single file) to the firewall to prevent server
cerficate validaon errors.
STEP 2 | Add the cerficate to your Decrypon policy rule, then click OK.
Upon clicking OK, the firewall automacally sorts the cerficates alphabecally.
STEP 4 | When you are ready...

1. Load your web server with the new cerficate.
2. (Best Pracce) Remove expired or otherwise invalid cerficates from your Decrypon
policy rule and the firewall.
URL Filtering Features
> Inline Deep Learning Analysis for Advanced URL Filtering
> HTTP Header Expansion
45
Inline Deep Learning Analysis for Advanced URL

Filtering
Palo Alto Networks Advanced URL Filtering now operates a series of inline cloud-based deep
learning detectors that evaluate suspicious web page contents in real-me to protect users against
zero-day threats. This includes cloaked websites, mul-step aacks, CAPTCHA challenges, and
previously unseen one-me-use URLs. When the firewall processes a URL request containing
suspicious web page contents, it forwards the HTTP response data to the cloud and analyzes
the contents of the web page that are deemed suspicious and is categorized accordingly. The
deep learning detectors and analyzers used to categorize websites are updated and deployed
automacally as Palo Alto Networks threat researchers improve the detecon logic, and does not
require the administrator to download and deploy update packages. Cloud inline categorizaon
is enabled and configured through the URL Filtering Profile and requires an acve Advanced URL
Filtering license.
STEP 1 | Log in to the PAN-OS web interface.
STEP 2 | To take advantage of inline categorizaon, you must have an acve Advanced URL Filtering.
Verify that you have an Advanced URL Filtering subscripon. To verify subscripons for which
you have currently-acve licenses, select Device > Licenses and verify that the appropriate
licenses are available and have not expired.
STEP 3 | Update or create a new URL Filtering Security profile to enable cloud inline categorizaon.
The policy acon used by local and cloud inline categorizaon is dependent on the
configured sengs under the Categories tab.
1. Select an exisng URL Filtering Profile or Add a new one (Objects > Security Profiles > URL
Filtering).
2. Select your URL Filtering profile and then go to Inline Categorizaon and enable the cloud
inline categorizaon.
3. Click OK to exit the URL Filtering Profile configuraon dialog and Commit your changes.
STEP 4 | Install an updated firewall device cerficate used to authencate to the Advanced URL
Filtering cloud service. Repeat for all firewalls enabled for inline cloud categorizaon.
For addional informaon about configuring cloud inline categorizaon, including adding
excepons, verifying connecvity to the required servers, validaon processes, and monitoring
details, refer to Configure Inline Categorizaon.
HTTP Header Expansion

Palo Alto Networks HTTP header inseron entries now support header values up to 16K bytes.
The larger header value size enables you to manage access to SaaS applicaons that require
longer values and specify more tenants that users on your network can access. For example,
if you currently have tenant restricons configured for Microso Office 365 but could not list
some approved tenants under the Restrict-Access-To-Tenants HTTP header due to size
constraints, you can now include addional domains or directory IDs registered with tenants.
STEP 1 | Add or select a URL Filtering Profile to include the HTTP header inseron entry.
Select Objects > Security Profiles > URL Filtering > HTTP Header Inseron.
STEP 2 | Add an entry.

1. Specify a Name and a custom or predefined Type.
2. Select a Header and enter a Value (up to 16,000 bytes).
3. Click OK to save your changes.
STEP 3 | Click OK to save the URL Filtering Profile.
Mobile Infrastructure Security Features
> New Deployment Opon for GTP Security in 3G/4G Networks
> Mobile Network Security Support on New Mid-Range Hardware Plaorms
51
New Deployment Opon for GTP Security in 3G/4G

Networks
If you deploy the firewall for RAN security in a mobile network that uses both 3G and 4G/LTE
technologies, the firewall now supports a new deployment opon that enforces GTP security in
network topologies that contain a combo node of a Serving Gateway (SGW) and Packet Gateway
(PGW) known as S-PGW. In this network topology, the S5 interface is not exposed, so to support
migraon between 3G and 4G/LTE, PAN-OS 10.2.0 introduces support for the Gn (SGSN-MME)
interface.
GTP security supports the following procedures as defined in 3GPP TS 23.401 version 15.12.0:
• MME to 3G SGSN combined hard handover and SRNS relocaon procedure
• 3G SGSN to MME combined hard handover and SRNS relocaon procedure
• Roung Area Update
• Gn/Gp SGSN to MME Tracking Area Update
• E-UTRAN to GERAN A/Gb mode Inter RAT handover
• GERAN A/Gb mode to E-UTRAN Inter RAT handover
The firewall generates the following GTP messages to support this new capability when you
enable Tunnel Management for GTPv1-C allowed messages.
GTP Message Value Message Type

Decimal Hexadecimal
GTPv1-C 1 1 Forward Relocaon Request
2 2 Forward Relocaon Response
3 3 Forward Relocaon Complete
4 4 Forward Relocaon Complete

Acknowledge
5 5 SGSN Context Request
6 6 SGSN Context Response
7 7 SGSN Context Acknowledge
In the following network topology, to apply security policy to user and control traffic, the firewall
must be posioned on the 4G/LTE interfaces, including the Control Plane (S11) and User Plane
(S1-U), as well as the 3G interfaces which include the Control Plane (Gn [SGSN-MME]) and the
Control and User Plane (Gn [SGSN-GGSN]). You must enable enable GTP Security for complete
subscriber level and equipment level visibility and policy control for threat and traffic in their
network.
Mobile Network Security Support on New Mid-Range

Hardware Plaorms
Private 5G networks and mul-access edge compung (MEC) can present security concerns
for enterprises and can increase the aack surface for malicious actors. As a wider range of
enterprises, including manufacturing, energy, ulies, logiscs, real estate, and healthcare,
transion to private 5G technologies, the need for enterprise-grade security that can deploy zero-
trust architecture in 5G increases.
You can now protect your MEC and private 5G environments with the industry’s only 5G-nave
security using the Palo Alto Networks next-generaon firewall. On the latest mid-size next-
generaon firewalls, Palo Alto Networks now supports mobility protocols with mobile idenfiers
like subscriber ID (the Internaonal Mobile Subscriber Idenfier or IMSI) and equipment ID (the
Internaonal Mobile Equipment Idenfier or IMEI) for enhanced visibility and security policy
enforcement. This allows enterprise IT security teams to extend their enterprise-grade security to
their 5G or 4G/LTE mobile networks.
The new firewalls support the following mobility security features for MEC and private 5G
network deployments:
• 5G Equipment ID Security
• 5G Subscriber ID Security
• 5G MEC Security
• GTP Security
• SCTP Security
The following diagrams depict a selecon of supported scenarios that highlight some of the
potenal applicaons for this new capability.
In the following deployment scenario of a private 4G/LTE network, the 4G core is located on-
premises. To enforce security policy for user and control traffic, the firewall must be posioned on
the 4G/LTE interfaces, including the User Plane (S1-U) and the Control Plane (S11).
For complete subscriber-level and equipment-level visibility and security policy control for
network traffic threats, enable GTP Security.
The second firewall in this diagram is posioned on the perimeter (the SGI interface connected to
the internet and the enterprise IT datacenter).
In the following private 5G network deployment scenario, only the User Plane Funcon (UPF)
is located on-premises. The 5G Core is located remotely in a central core site or public cloud.
To enforce security policy for user and control traffic, the firewall must be posioned on the 5G
interfaces, including the User Plane (N3) and Control Plane (N4).
The second firewall in the diagram is posioned on the perimeter (the N6 interface connected to
In the following private 5G network deployment scenario, the 5G Core, including the User Plane
Funcon (UPF), is located on-premises. The 5G Core includes network funcons (NFs) such as
Session Management (SMF) and Access and Mobility Management Funcon (AMF), as well as
others. To enforce security policy for user and control traffic, the firewall must be posioned on
the 5G interfaces, including the User Plane (N3) and the Control Plane (N4).
network traffic threats, enable GTP Security. Apply security policy to the Control Plane
(N2) between the 5G RAN and the 5G Core for signaling protecon by enabling SCTP
Security.
In the following private 5G network deployment scenario, only the Radio Access Network (RAN) is
located on-premises.
To apply security policy to user traffic, enable Tunnel Content Inspecon.
The firewall must be posioned on the 5G interface for the User Plane (N3).
In the following 5G MEC deployment scenario, the User Plane Funcon (UPF) is located on the
MEC in the service provider’s edge locaon or on the public cloud edge and the 5G Core is located
remotely in a central core site or the public cloud. To enforce security policy for user and control
traffic, the firewall must be posioned on the 5G interfaces, including the User Plane (N3) and the
Control Plane (N4).
Virtualizaon Features
> CN-Series Firewall as a Kubernetes CNF
> High Availability Support for CN-Series Firewall as a Kubernetes CNF
> High Availability Support for CN-Series Firewall on AWS EKS
> DPDK Support for CN-Series Firewall
> Daemonset(vWire) IPv6 Support
> Panorama Plugin for Kubernetes 3.0.0
> L3 IPV4 Support for CN-Series
> 47 Dataplane Cores Support for VM-Series and CN-Series Firewalls
> Memory Scaling of the VM-Series Firewall
59
CN-Series Firewall as a Kubernetes CNF

You can now deploy the CN-Series as a Container Network Funcon (CNF) in your Kubernetes
environment.
CN-Series-as-a-daemonset and CN-Series-as-a-kubernetes-service deployment modes provide
an automated security deployment and leverage the auto-scaling capabilies of Kubernetes.
However, these deployment modes have limited inseron opons and don’t support I/O
acceleraon. In addion, they limit the achievable throughput for the applicaon pods that require
inspecon and use mulple network interfaces.
Deploying the CN-series-as-a-kubernetes-CNF resolves these challenges for traffic that uses
Service Funcon Chaining (SFC) through external enes such as cloud provider's nave roung,
vRouters, and Top of Rack (TOR) switches. The CN-series-as-a-kubernetes-CNF mode of
deployment does not impact the applicaon pods.
For more informaon, see Deploying the CN-Series Firewall as a Kubernetes-CNF.
High Availability Support for CN-Series Firewall as a

Kubernetes CNF
High availability (HA) is a configuraon in which two firewalls are placed in a group and their
configuraon is synchronized to prevent a single point of failure on your network. A heartbeat
connecon between the firewall peers ensures seamless failover in the event that a peer goes
down. Seng up the firewalls in a two-device cluster provides redundancy and allows you to
ensure business connuity.
You can now deploy the CN-series-as-a-kubernetes-CNF in HA. This mode of deployment
supports only acve/passive HA with session and configuraon synchronizaon.
When you deploy the CN-Series-as-a-Kubernetes CNF in HA, there will be two PAN-CN-MGMT-
CONFIGMAP, PAN-CN-MGMT, and PAN-CN-NGFW YAML files each for acve and passive
nodes.
For more informaon, High Availability Support for deploying the CN-Series Firewall as a
Kubernetes CNF.
High Availability Support for CN-Series Firewall on AWS

EKS
To ensure redundancy, you can deploy the CN-Series firewalls on AWS in an acve/passive high
availability (HA) configuraon. The acve peer connuously synchronizes its configuraon and
session informaon with the idencally configured passive peer. A heartbeat connecon between
the two devices ensures failover if the acve device goes down. You can deploy the CN-Series
firewall on AWS EKS in HA through Secondary IP move.
To ensure that all traffic to your internet-facing applicaons passes through the firewall, you
can configure AWS ingress roung. The AWS ingress roung capability allows you to associate
route tables with the AWS Internet gateway and add route rules to redirect the applicaon traffic
through the CN-Series firewall. This redirecon ensures that all internet traffic passes through the
firewall without having to reconfigure the applicaon endpoints.
When the acve peer goes down, the passive peer detects this failure and becomes acve.
Addionally, it triggers API calls to the AWS infrastructure to move the configured secondary IP
addresses from the dataplane interfaces of the failed peer to itself. Addionally, AWS updates the
route tables to ensure that traffic is directed to the acve firewall instance. These two operaons
ensure that inbound and outbound traffic sessions are restored aer failover. This opon allows
you to take advantage of DPDK to improve the performance of your CN-Series firewall instances.
AWS requires that all API requests must be cryptographically signed using credenals issued by
them. In order to enable API permissions for the CN-Series firewalls that will be deployed as an
HA pair, you must create a policy and aach that policy to a role in the AWS Identy and Access
Management (IAM) service. The role must be aached to the CN-Series firewalls at launch. The
policy gives the IAM role permissions for iniang API acons required to move interfaces or
secondary IP addresses from the acve peer to the passive peer when failover is triggered.
The devices in an HA pair can be assigned a device priority value to indicate a preference for which
device should assume the acve role and manage traffic upon failover. If you need to use a specific
device in the HA pair for acvely securing traffic, you must enable the preempve behavior on
both the firewalls and assign a device priority value for each device. The device with the lower
numerical value, and therefore higher priority, is designated as acve and manages all traffic on
the network. The other device is in a passive state, and synchronizes configuraon and state
informaon with the acve device so that it is ready to transion to an acve state should a
failure occur.
For more informaon, see High Availabiity support for CN-Series Firewall on AWS EKS.
DPDK Support for CN-Series Firewall

The Kubernetes CNF mode of CN-Series now supports Data Plane Development Kit (DPDK)
and allows the applicaon pods to use DPDK. DPDK enables fast packet processing in dataplane
applicaons by bypassing mulple layers of kernel networking stacks, and communicang directly
with the network hardware.
See Configure DPDK on CN-Series Firewall for instrucons to set up DPDK.
Daemonset(vWire) IPv6 Support

In the Kubernetes daemonset mode, applicaon pods can have IPv4 and IPv6 addresses on either
one or many interfaces with the Multus environment. If the applicaon pods have IPv6 addresses,
we can sll secure those interfaces using the Kubernetes daemonset mode.
Addionally, with the Kubernetes plugin supporng DAG to IPv6 address mapping, DAG can be
used for security policy.
IPv6 addresses are supported only on the k8s-daemonset and not on the k8s-CNF or k8s-
service mode.
For more informaon, see:

NPTv6
Deploy the CN-Series Firewall as a DaemonSet
Panorama Plugin for Kubernetes 3.0.0

The Kubernetes 3.0.0 plugin supports the following funconalies:
Retrieve IPv6 Addresses for Multus CNI Setup
In a Multus CNI setup, each pod has mulple interfaces and these interfaces can have IPv6 or
IPv4 addresses. The Kubernetes 3.0.0 Plugin queries and collects the IPv4 and IPv6 addresses for
Multus CNI.
Tag Pruning
Tag Pruning increases the scalability of the plugin and the number of tags collected by the plugin.
It enables the plugin to collect an increased number of tags and push them to Panorama without
IP addresses. Panorama has only a 10MB payload limitaon, and with Tag Pruning, the plugin
can send empty tags to Panorama and only send IP addresses for tags that are used in Security
Policies. In case of a shared DG on Panorama, the plugin cannot learn the DAGs and hence the IP
addresses will not be pushed.
Service Account Validaon
The Kubernetes 3.0.0 Plugin supports service account file validaon as a pre-commit, where the
validaon takes place aer the user adds a service account file and commits the credenals. By
using this method, the plugin can implement periodic checks for service accounts and update their
status accordingly.
Dashboard
For tags not used in DG security policies, Panorama only holds tags without IP addresses. With
Tag Pruning, the plugin pushes the IP/tag mappings on to the plugin UI and you will be able to
navigate the Dashboard to see the IP/tag mappings. You will have an opon to view IP addresses
(IPv4 and IPv6) associated to all tags learnt by the plugin and then, look for the tags associated to
each IP address when you click associated tags.
The Kubernetes 3.0.0 Plugin works only with Panorama 10.2 and Pan OS 10.2 devices. However,
it can manage 10.1 firewall devices on 10.2 Panorama.
• To upgrade to a Kubernetes 3.0.0 Plugin, download the Kubernetes 3.0.0 Plugin and
upgrade your Panorama to 10.2, which will automacally install the downloaded
Kubernetes 3.0.0 Plugin. However, if you have not downloaded the Kubernetes 3.0.0
Plugin before upgrading the Panorama, the upgrade will be stopped.
• You cannot use a Kubernetes 2.0.0 Plugin with Panorama 10.2.
• You will find four default templates on Panorama aer downgrading the Kubernetes
plugin from 3.0.0. The unnecessary templates can be deleted manually.
L3 IPV4 Support for CN-Series

With the Kubernetes CNF, CN-Series now supports the traffic through a vRouter, where stac
routes are configured to redirect traffic to the dataplane interfaces of the firewall. For reverse
direcon, the traffic is redirected to the same firewall using L3 Policy-based roung (PBR) with
IPv4 IP addresses. IP addresses to the interfaces in k8s environment are typically programmed
through the CNI using DHCP.
In kubernetes CNF mode, only one CN-NFGW pod is supported with an CN-MGMT pod.
CN-Series supports Stac and Connected routes and BGP protocol. OSPF is supported on Nave/
OnPrem environments, but not supported on Public clouds, due to the limitaon in the cloud
infrastructure. BFD and tunnel interfaces are not supported.
vWire can sll be used on dataplane ports where an external ToR is configured to manage
L1 PBR.
47 Dataplane Cores Support for VM-Series and CN-

Series Firewalls
Starng PAN-10.2, VM-Series and CN-Series firewalls support a maximum of 47 dataplane cores.
Increasing the number of dataplane cores improve performance.
For VM-Series, if you have NUMA performance opmizaon enabled with custom
dataplane core sengs, the NUMA seng takes precedence.
For example, for a 64 CPU VM with NUMA performance opmizaon enabled
and 47 dataplane core seng, the NUMA sengs take precedence. The command
—show plugins vm_series dp-cores displays—Current DP cores:31
configured custom DP cores: 47 (Current total cores: 64).
For more informaon, see Enable NUMA Performance Opmizaon on VM-Series.
Memory Scaling of the VM-Series Firewall

Beginning with PAN-OS 10.2, the maximum number of sessions supported on an individual VM-
Series firewall scales with the amount of memory allocated to the VM-Series instance. Because
memory increments are not locked in place, you can increase the amount of memory as needed
for your environment. For example, if your VM-Series is assigned 16GB of memory (2,000,000
sessions) but you need to support 3,000,000 sessions, you can increase the memory to 24GB
instead of having to jump all the way to 56GB as in previous PAN-OS releases. Therefore, in
deployments where resources are ght, you no longer need to stacally allocate more memory
than necessary to achieve the capacity you require.
For linear scaling, increments of memory are grouped into ers that represent the configuraon
capacity of the VM-Series firewall. Regardless of the amount of memory you assign to a VM-
Series firewall instance, the er that amount of memory falls into determine the limit for non-
sessions values, such as security rules, address objects, security profiles, etc.
This feature is enabled by default and requires no configuraon on the VM-Series firewall. VM-
Series firewall capacity scales dynamically with the allocated memory.
PAN-OS SD-WAN Features
> Copy ToS Header Support
71
PAN-OS SD-WAN Features
Copy ToS Header Support

You can tag applicaon traffic going from a source to a desnaon with Type of Service (ToS)
bits or Differenated Services Code Point (DSCP) markings (RFC 2474) so that network devices
along the way can provide QoS to the traffic. When that traffic goes through an SD-WAN virtual
interface, the traffic goes through a VPN tunnel, which requires encapsulaon. Therefore, each
packet’s ToS bits or DSCP markings must be copied from the inner IP header to the outer VPN
header so that the networking devices between the originang firewall and terminang firewall
can apply the proper QoS to each packet.
To sasfy that requirement, beginning with PAN-OS 10.2.1 and SD-WAN Plugin 3.0.1, you can
have an SD-WAN hub or branch copy the ToS field from the inner IPv4 header to the outer VPN
header of encapsulated packets going through the VPN tunnel. The ToS field can contain ToS bits
or DSCP markings. The Copy ToS Header opon also copies the Explicit Congeson Noficaon
(ECN) field.
STEP 1 | Log in to the Panorama Web Interface.
STEP 2 | Select Panorama > SD-WAN > Devices and select a branch or hub.
STEP 3 | Select the VPN Tunnel tab.
STEP 4 | Select Copy ToS Header (disabled by default).
STEP 5 | Click OK.
STEP 6 | Commit.
Enterprise Data Loss Prevenon
Features
> Web Form Data Inspecon for Enterprise Data Loss Prevenon
73
Enterprise Data Loss Prevenon Features
Web Form Data Inspecon for Enterprise Data Loss

Prevenon
Enterprise data loss prevenon (DLP) now supports inspecon of non-filed format traffic to
prevent exfiltraon of sensive informaon in data exchanged in collaboraon applicaons, web
forms, Cloud applicaons, custom applicaons, and social media.
Managed firewalls leveraging Enterprise DLP send all non-file based traffic that match data
filtering profile criteria to the DLP cloud service to render a verdict. However, use URL categories
and applicaon filters to determine which applicaon traffic is excluded from inspecon.
Enterprise DLP includes a predefined DLP App Exclusion Filter filter containing common
applicaons that cannot be inspected or do not require inspecon. You can leverage the
predefined applicaon filter or create a custom applicaon filter specify applicaons to exclude
from inspecon. You can modify exisng data filtering profiles to scan both file based and non-
file based traffic. Inspecon of non-file based traffic is supported on Panorama, Prisma Access
(Panorama Managed), and Prisma Access (Cloud Managed).
Enterprise DLP supports inspecon of non-file based traffic of sensive data for the following
HTTP content types:
• JSON
• URL encoded form
• Mulpurpose Internet Mail Extensions (MIME)
Web form inspecon for non-file based traffic is supported only for the HTTP/1.x network
protocol. Web form inspecon for non-file based traffic is not supported for the HTTP/2
network protocol.
The steps below describe how to configure web form inspecon Enterprise DLP on Panorama and
Prisma Access (Panorama Managed).
STEP 2 | Create a Data Paern on Panorama.
STEP 3 | (Oponal) Create a custom URL category for URL or domain traffic you do not want to send
to the DLP cloud service for inspecon.
STEP 4 | (Oponal) Create a custom applicaon filter for applicaon traffic you do not want to send to
the DLP cloud service for inspecon.
1. Select Objects > Applicaon Filters and Add a new applicaon filter.
You can also select and Clone the predefined DLP App Exclusion Filter
to create a custom applicaon filter.
2. Check (enabled) Shared.
3. Configure the applicaon filter as needed.
See Create an Applicaon Filter for more informaon.
4. Click OK.
5. Select Commit and Commit to Panorama.
STEP 5 | Create a data filtering profile to inspect non-filed based traffic.

See Create a Data Filtering Profile on Panorama for addional details on creang a data
filtering profile.
1. Select Objects > DLP > Data Filtering Profile and Add a data filtering profile.
2. Enter descripve Name for the data filtering profile.
3. For Non Filed Based, select Yes.
4. Enable (check) Shared.
5. Add the Primary Paern and Secondary Paern match criteria as needed.
6. (Oponal) Select URL Category and Add a URL category to exclude from inspecon.
You can add one or more external dynamic lists, custom URL category, and predefined
URL category
7. Select Applicaon List and Add an applicaon list to exclude from inspecon.
At least one applicaon filter is required to successfully create a data filtering profile for
non-file based traffic.
8. Configure the Acon.
9. Configure the Log Severity.
10. Click OK.
STEP 6 | Aach the data filtering profile to a Security policy rule.

1. Select Policies > Security and specify the Device Group.
2. Select the Security policy rule to which you want to add the data filtering profile.
3. Select Acons and set the Profile Type to Profiles.
4. Select the Data Filtering profile you created previously.
5. Click OK to save your
STEP 7 | Commit and push your configuraon changes to your managed firewalls that are leveraging
Enterprise DLP.
The Commit and Push command is not recommended for Enterprise DLP configuraon
changes. Using the Commit and Push command requires the addional and
unnecessary overheard of manually selecng the impacted templates and managed
firewalls in the Push Scope Selecon.
1. Select Commit > Commit to Panorama and Commit.

2. Select Commit > Push to Devices and Edit Selecons.
3. Select Device Groups and Include Device and Network Templates.
4. Click OK.
5. Push your configuraon changes to your managed firewalls that are leveraging Enterprise
DLP.

Pan Os New Features

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Pan Os New Features

Uploaded by

Copyright:

Available Formats

PAN-OS ® New Features Guide

About the Documentaon

IoT Security Features.......................................................................................11

Content Inspecon Features.........................................................................37

URL Filtering Features.................................................................................... 45

Mobile Infrastructure Security Features.................................................... 51

Daemonset(vWire) IPv6 Support........................................................................................... 64

PAN-OS SD-WAN Features.......................................................................... 71

Enterprise Data Loss Prevenon Features................................................ 73

STEP 5 | Perform an administrator-level push to managed ﬁrewalls.

Automac Content Push for VM-Series and CN-Series

STEP 1 | Log in to the Panorama web interface.

STEP 2 | Install the latest dynamic content updates on Panorama.

STEP 4 | Commit and Commit to Panorama.

STEP 5 | Add a Firewall as a Managed Device.

STEP 6 | Verify the dynamic content version installed on the ﬁrewall.

Log Collector Health Monitoring on Panorama

STEP 3 | Review the overall health status of the Log Collector.

Simpliﬁed IoT Security Onboarding

STEP 2 | Commit your changes.

Data Collecon for IoT Security

STEP 2 | Enable ERSPAN support on the ﬁrewall.

STEP 3 | Commit your change.

You must already have logging services enabled on the ﬁrewall.

Interface: ethernet1/3 (the interface you previously conﬁgured)

STEP 8 | Conﬁgure a GRE tunnel with ERSPAN enabled.

STEP 9 | Commit your changes.

AIOps for NGFW

Onboard your devices and get started with AIOps now.

Selecve Commit of Conﬁguraon Changes

STEP 2 | Make any conﬁguraon changes as needed.

STEP 3 | Perform a selecve commit.

(Panorama managed ﬁrewalls) On Panorama, select Commit > Commit to

STEP 4 | (Panorama managed ﬁrewalls only) Perform an Administrator-Level Push.

Simpliﬁed Soware Upgrade

> Advanced Roung Engine

Advanced Roung Engine

STEP 2 | Learn about logical routers.

STEP 3 | Conﬁgure a logical router and add interfaces to it.

STEP 4 | Create a stac route.

STEP 5 | Conﬁgure BGP on an advanced roung engine.

STEP 8 | Conﬁgure OSPFv2 on an advanced roung engine.

STEP 10 | Conﬁgure OSPFv3 on an advanced roung engine.

STEP 12 | Conﬁgure RIPv2 on an advanced roung engine.

STEP 14 | Create BFD proﬁles

IPv4 Mulcast for Advanced Roung Engine

STEP 2 | Conﬁgure a logical router and add interfaces to it.

STEP 3 | Conﬁgure IPv4 mulcast by conﬁguring PIM and IGMP.

STEP 4 | Create PIM interface mer proﬁles.

STEP 5 | Create IGMP interface query proﬁles.

Security Policy Rule Top-Down Order When Wildcard

Advanced Threat Prevenon: Inline Cloud Analysis

The default acon for each analysis engine is alert.

• Allow—The request is allowed and no log entry is generated.

Domain Fronng Detecon

Mulple Cerﬁcate Support for SSL Inbound Inspecon

STEP 3 | Commit your changes.

STEP 4 | When you are ready...

Inline Deep Learning Analysis for Advanced URL

HTTP Header Expansion

STEP 2 | Add an entry.

STEP 3 | Click OK to save the URL Filtering Proﬁle.

New Deployment Opon for GTP Security in 3G/4G