Pan Os Admin 10.1

PAN-OS® Administrator’s Guide
Version 10.1
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[email protected].
Copyright
Palo Alto Networks, Inc.
www.paloaltonetworks.com
©2021 Palo Alto Networks, Inc. Palo Alto Networks is a registered trademark of Palo Alto
Networks. A list of our trademarks can be found at www.paloaltonetworks.com/company/
trademarks.html. All other marks menoned herein may be trademarks of their respecve
companies.
Last Revised
December 14, 2021
PAN-OS® Administrator’s Guide Version Version 10.1 2 ©2021 Palo Alto Networks, Inc.
Table of Contents
Geng Started................................................................................................. 21
Integrate the Firewall into Your Management Network.................................................. 22
Determine Your Management Strategy....................................................................22
Perform Inial Configuraon...................................................................................... 23
Set Up Network Access for External Services........................................................30
Register the Firewall................................................................................................................. 37
Create a New Support Account and Register a Firewall...................................... 37
Register a Firewall......................................................................................................... 39
(Oponal) Perform Day 1 Configuraon.................................................................. 42
Register the Firewall Line Cards................................................................................ 45
Segment Your Network Using Interfaces and Zones........................................................46
Network Segmentaon for a Reduced Aack Surface......................................... 46
Configure Interfaces and Zones................................................................................. 47
Set Up a Basic Security Policy............................................................................................... 51
Assess Network Traffic.............................................................................................................56
Enable Free WildFire Forwarding.......................................................................................... 58
Best Pracces for Compleng the Firewall Deployment.................................................61
Subscripons..................................................................................................... 63
Subscripons You Can Use With the Firewall....................................................................64
Acvate Subscripon Licenses.............................................................................................. 68
What Happens When Licenses Expire?............................................................................... 70
Enhanced Applicaon Logs for Palo Alto Networks Cloud Services.............................73
Firewall Administraon.................................................................................. 77
Management Interfaces........................................................................................................... 78
Use the Web Interface.............................................................................................................79
Launch the Web Interface........................................................................................... 79
Configure Banners, Message of the Day, and Logos.............................................80
Use the Administrator Login Acvity Indicators to Detect Account
Misuse...............................................................................................................................82
Manage and Monitor Administrave Tasks............................................................. 84
Commit, Validate, and Preview Firewall Configuraon Changes........................ 85
Export Configuraon Table Data............................................................................... 87
Use Global Find to Search the Firewall or Panorama Management
Server................................................................................................................................ 88
Manage Locks for Restricng Configuraon Changes.......................................... 90
Manage Configuraon Backups.............................................................................................92
Save and Export Firewall Configuraons................................................................. 92
Table of Contents
Revert Firewall Configuraon Changes.................................................................... 94

Manage Firewall Administrators............................................................................................ 96
Administrave Role Types........................................................................................... 96
Configure an Admin Role Profile................................................................................97
Administrave Authencaon................................................................................. 104
Configure Administrave Accounts and Authencaon....................................105
Configure Tracking of Administrator Acvity....................................................... 112
Reference: Web Interface Administrator Access.............................................................114
Web Interface Access Privileges..............................................................................114
Panorama Web Interface Access Privileges.......................................................... 186
Reference: Port Number Usage...........................................................................................191
Ports Used for Management Funcons................................................................. 191
Ports Used for HA.......................................................................................................192
Ports Used for Panorama.......................................................................................... 193
Ports Used for GlobalProtect................................................................................... 195
Ports Used for User-ID.............................................................................................. 195
Ports Used for IPSec.................................................................................................. 197
Ports Used for Roung.............................................................................................. 197
Ports Used for DHCP.................................................................................................198
Ports Used for Infrastructure................................................................................... 198
Reset the Firewall to Factory Default Sengs................................................................ 200
Bootstrap the Firewall........................................................................................................... 201
USB Flash Drive Support...........................................................................................201
Sample init-cfg.txt Files............................................................................................. 202
Prepare a USB Flash Drive for Bootstrapping a Firewall................................... 204
Bootstrap a Firewall Using a USB Flash Drive..................................................... 206
Device Telemetry........................................................................................... 209

Device Telemetry Overview................................................................................................. 210
Device Telemetry Collecon and Transmission Intervals.............................................. 211
Manage Device Telemetry.................................................................................................... 212
Enable Device Telemetry........................................................................................... 212
Disable Device Telemetry..........................................................................................212
Manage the Data the Device Telemetry Collects................................................ 213
Manage Historical Device Telemetry......................................................................213
Monitor Device Telemetry.................................................................................................... 215
Sample the Data that Device Telemetry Collects........................................................... 216
Authencaon................................................................................................217
Authencaon Types............................................................................................................. 218
External Authencaon Services............................................................................ 218
Table of Contents
Mul-Factor Authencaon..................................................................................... 218

SAML.............................................................................................................................. 220
Kerberos.........................................................................................................................220
TACACS+....................................................................................................................... 221
RADIUS.......................................................................................................................... 222
LDAP...............................................................................................................................224
Local Authencaon...................................................................................................224
Plan Your Authencaon Deployment.............................................................................. 225
Configure Mul-Factor Authencaon............................................................................. 227
Configure MFA Between RSA SecurID and the Firewall................................... 231
Configure MFA Between Okta and the Firewall..................................................239
Configure MFA Between Duo and the Firewall...................................................249
Configure SAML Authencaon......................................................................................... 258
Configure Kerberos Single Sign-On....................................................................................263
Configure Kerberos Server Authencaon...................................................................... 266
Configure TACACS+ Authencaon.................................................................................. 267
Configure RADIUS Authencaon..................................................................................... 270
Configure LDAP Authencaon..........................................................................................274
Connecon Timeouts for Authencaon Servers.......................................................... 276
Guidelines for Seng Authencaon Server Timeouts.....................................276
Modify the PAN-OS Web Server Timeout............................................................277
Modify the Authencaon Portal Session Timeout............................................277
Configure Local Database Authencaon........................................................................ 279
Configure an Authencaon Profile and Sequence....................................................... 280
Test Authencaon Server Connecvity.......................................................................... 284
Authencaon Policy.............................................................................................................286
Authencaon Timestamps...................................................................................... 286
Configure Authencaon Policy..............................................................................287
Troubleshoot Authencaon Issues................................................................................... 291
Cerficate Management.............................................................................. 293

Keys and Cerficates............................................................................................................. 294
Default Trusted Cerficate Authories (CAs).................................................................. 297
Cerficate Revocaon........................................................................................................... 298
Cerficate Revocaon List (CRL).............................................................................298
Online Cerficate Status Protocol (OCSP)............................................................ 299
Cerficate Deployment......................................................................................................... 300
Set Up Verificaon for Cerficate Revocaon Status....................................................301
Configure an OCSP Responder................................................................................301
Configure Revocaon Status Verificaon of Cerficates...................................302
Table of Contents
Configure Revocaon Status Verificaon of Cerficates Used for SSL/TLS

Decrypon.....................................................................................................................302
Configure the Master Key.................................................................................................... 304
Master Key Encrypon..........................................................................................................307
Configure Master Key Encrypon Level................................................................ 308
Master Key Encrypon on a Firewall HA Pair......................................................309
Master Key Encrypon Logs.....................................................................................309
Unique Master Key Encrypons for AES-256-GCM...........................................310
Obtain Cerficates..................................................................................................................311
Create a Self-Signed Root CA Cerficate..............................................................311
Generate a Cerficate................................................................................................312
Import a Cerficate and Private Key...................................................................... 313
Obtain a Cerficate from an External CA............................................................. 314
Install a Device Cerficate........................................................................................ 315
Deploy Cerficates Using SCEP.............................................................................. 316
Export a Cerficate and Private Key................................................................................. 320
Configure a Cerficate Profile............................................................................................. 321
Configure an SSL/TLS Service Profile................................................................................ 324
Configure an SSH Service Profile........................................................................................326
Create an SSH Management Profile....................................................................... 326
Create an SSH HA Profile......................................................................................... 335
Replace the Cerficate for Inbound Management Traffic............................................. 345
Configure the Key Size for SSL Forward Proxy Server Cerficates............................ 346
Revoke and Renew Cerficates...........................................................................................347
Revoke a Cerficate....................................................................................................347
Renew a Cerficate.................................................................................................... 347
Secure Keys with a Hardware Security Module.............................................................. 348
Set Up Connecvity with an HSM..........................................................................348
Encrypt a Master Key Using an HSM.....................................................................354
Store Private Keys on an HSM................................................................................ 355
Manage the HSM Deployment................................................................................ 356
High Availability.............................................................................................359
HA Overview........................................................................................................................... 360
HA Concepts............................................................................................................................ 361
HA Modes..................................................................................................................... 361
HA Links and Backup Links...................................................................................... 362
Device Priority and Preempon.............................................................................. 367
Failover........................................................................................................................... 368
LACP and LLDP Pre-Negoaon for Acve/Passive HA.................................. 369
Floang IP Address and Virtual MAC Address.................................................... 370
Table of Contents
ARP Load-Sharing........................................................................................................371
Route-Based Redundancy......................................................................................... 373
HA Timers..................................................................................................................... 374
Session Owner............................................................................................................. 377
Session Setup............................................................................................................... 377
NAT in Acve/Acve HA Mode..............................................................................379
ECMP in Acve/Acve HA Mode.......................................................................... 380
Set Up Acve/Passive HA....................................................................................................381
Prerequisites for Acve/Passive HA.......................................................................381
Configuraon Guidelines for Acve/Passive HA.................................................382
Configure Acve/Passive HA................................................................................... 385
Define HA Failover Condions................................................................................ 390
Verify Failover...............................................................................................................393
Set Up Acve/Acve HA......................................................................................................394
Prerequisites for Acve/Acve HA........................................................................ 394
Configure Acve/Acve HA.....................................................................................395
Determine Your Acve/Acve Use Case.............................................................. 401
HA Clustering Overview....................................................................................................... 417
HA Clustering Best Pracces and Provisioning............................................................... 420
Configure HA Clustering....................................................................................................... 422
Refresh HA1 SSH Keys and Configure Key Opons...................................................... 425
HA Firewall States.................................................................................................................. 434
Reference: HA Synchronizaon...........................................................................................436
What Sengs Don’t Sync in Acve/Passive HA?............................................... 436
What Sengs Don’t Sync in Acve/Acve HA?.................................................438
Synchronizaon of System Runme Informaon................................................ 442
Monitoring....................................................................................................... 445
Use the Dashboard.................................................................................................................446
Use the Applicaon Command Center..............................................................................448
ACC—First Look........................................................................................................... 448
ACC Tabs....................................................................................................................... 450
ACC Widgets................................................................................................................ 452
Widget Descripons................................................................................................... 454
ACC Filters.................................................................................................................... 460
Interact with the ACC................................................................................................ 461
Use Case: ACC—Path of Informaon Discovery..................................................465
Use the App Scope Reports................................................................................................. 472
Summary Report.......................................................................................................... 472
Change Monitor Report............................................................................................. 473
Threat Monitor Report...............................................................................................474
Table of Contents
Threat Map Report......................................................................................................475

Network Monitor Report...........................................................................................476
Traffic Map Report...................................................................................................... 477
Use the Automated Correlaon Engine............................................................................ 479
Automated Correlaon Engine Concepts..............................................................479
View the Correlated Objects....................................................................................480
Interpret Correlated Events...................................................................................... 481
Use the Compromised Hosts Widget in the ACC............................................... 483
Take Packet Captures.............................................................................................................484
Types of Packet Captures..........................................................................................484
Disable Hardware Offload.........................................................................................485
Take a Custom Packet Capture................................................................................ 486
Take a Threat Packet Capture.................................................................................. 490
Take an Applicaon Packet Capture....................................................................... 492
Take a Packet Capture on the Management Interface....................................... 495
Monitor Applicaons and Threats...................................................................................... 498
View and Manage Logs......................................................................................................... 499
Log Types and Severity Levels................................................................................. 499
View Logs...................................................................................................................... 506
Filter Logs......................................................................................................................507
Export Logs................................................................................................................... 508
Configure Log Storage Quotas and Expiraon Periods...................................... 509
Schedule Log Exports to an SCP or FTP Server.................................................. 509
Monitor Block List.................................................................................................................. 511
View and Manage Reports................................................................................................... 512
Report Types.................................................................................................................512
View Reports................................................................................................................ 513
Configure the Expiraon Period and Run Time for Reports..............................514
Disable Predefined Reports...................................................................................... 514
Custom Reports........................................................................................................... 514
Generate Custom Reports.........................................................................................517
Generate Botnet Reports.......................................................................................... 520
Generate the SaaS Applicaon Usage Report...................................................... 522
Manage PDF Summary Reports...............................................................................525
Generate User/Group Acvity Reports..................................................................527
Manage Report Groups..............................................................................................529
Schedule Reports for Email Delivery...................................................................... 529
Manage Report Storage Capacity............................................................................530
View Policy Rule Usage.........................................................................................................532
Use External Services for Monitoring................................................................................ 536
Configure Log Forwarding.................................................................................................... 537
Table of Contents
Configure Email Alerts........................................................................................................... 540

Use Syslog for Monitoring.................................................................................................... 542
Configure Syslog Monitoring.................................................................................... 542
Syslog Field Descripons...........................................................................................546
SNMP Monitoring and Traps................................................................................................620
SNMP Support............................................................................................................. 620
Use an SNMP Manager to Explore MIBs and Objects....................................... 621
Enable SNMP Services for Firewall-Secured Network Elements..................... 624
Monitor Stascs Using SNMP............................................................................... 624
Forward Traps to an SNMP Manager.....................................................................626
Supported MIBs........................................................................................................... 628
Forward Logs to an HTTP/S Desnaon..........................................................................637
NetFlow Monitoring............................................................................................................... 640
Configure NetFlow Exports...................................................................................... 640
NetFlow Templates..................................................................................................... 642
Firewall Interface Idenfiers in SNMP Managers and NetFlow Collectors............... 648
Monitor Transceivers..............................................................................................................651
User-ID............................................................................................................. 653
User-ID Overview................................................................................................................... 654
User-ID Concepts....................................................................................................................656
Group Mapping............................................................................................................ 656
User Mapping............................................................................................................... 656
Enable User-ID.........................................................................................................................661
Map Users to Groups.............................................................................................................665
Map IP Addresses to Users.................................................................................................. 672
Create a Dedicated Service Account for the User-ID Agent.............................673
Configure User Mapping Using the Windows User-ID Agent.......................... 692
Configure User Mapping Using the PAN-OS Integrated User-ID Agent.........706
Configure Server Monitoring Using WinRM.........................................................710
Configure User-ID to Monitor Syslog Senders for User Mapping....................718
Map IP Addresses to Usernames Using Authencaon Portal.........................728
Configure User Mapping for Terminal Server Users............................................734
Send User Mappings to User-ID Using the XML API......................................... 744
Enable User- and Group-Based Policy...............................................................................745
Enable Policy for Users with Mulple Accounts............................................................. 746
Verify the User-ID Configuraon........................................................................................748
Deploy User-ID in a Large-Scale Network....................................................................... 751
Deploy User-ID for Numerous Mapping Informaon Sources......................... 751
Insert Username in HTTP Headers......................................................................... 755
Redistribute Data and Authencaon Timestamps............................................ 757
Table of Contents
Share User-ID Mappings Across Virtual Systems................................................ 764
App-ID.............................................................................................................. 767
App-ID Overview.................................................................................................................... 768
Streamlined App-ID Policy Rules........................................................................................ 769
Create an Applicaon Filter Using Tags.................................................................769
Create an Applicaon Filter Based on Custom Tags...........................................770
App-ID and HTTP/2 Inspecon.......................................................................................... 772
Manage Custom or Unknown Applicaons......................................................................774
Manage New and Modified App-IDs................................................................................. 775
Workflow to Best Incorporate New and Modified App-IDs............................. 775
See the New and Modified App-IDs in a Content Release................................776
See How New and Modified App-IDs Impact Your Security Policy.................778
Ensure Crical New App-IDs are Allowed............................................................ 778
Monitor New App-IDs................................................................................................779
Disable and Enable App-IDs..................................................................................... 781
Use Applicaon Objects in Policy.......................................................................................782
Create an Applicaon Group....................................................................................782
Create an Applicaon Filter......................................................................................783
Create a Custom Applicaon................................................................................... 784
Resolve Applicaon Dependencies.........................................................................788
Safely Enable Applicaons on Default Ports....................................................................790
Applicaons with Implicit Support..................................................................................... 792
Security Policy Rule Opmizaon...................................................................................... 796
Policy Opmizer Concepts........................................................................................797
Migrate Port-Based to App-ID Based Security Policy Rules............................. 804
Rule Cloning Migraon Use Case: Web Browsing and SSL Traffic...................811
Add Applicaons to an Exisng Rule..................................................................... 815
Idenfy Security Policy Rules with Unused Applicaons.................................. 817
High Availability for Applicaon Usage Stascs................................................820
How to Disable Policy Opmizer............................................................................ 820
App-ID Cloud Engine............................................................................................................. 822
Prepare to Deploy App-ID Cloud Engine.............................................................. 824
Enable or Disable the App-ID Cloud Engine........................................................ 828
App-ID Cloud Engine Processing and Usage........................................................ 828
New App Viewer (Policy Opmizer)....................................................................... 832
Add Apps to an Applicaon Filter with Policy Opmizer.................................. 833
Add Apps to an Applicaon Group with Policy Opmizer................................ 836
Add Apps Directly to a Rule with Policy Opmizer............................................ 839
Replace an RMA Firewall (ACE)...............................................................................842
Impact of License Expiraon or Disabling ACE....................................................843
Table of Contents
Commit Failure Due to Cloud Content Rollback..................................................843

Troubleshoot App-ID Cloud Engine........................................................................ 844
SaaS App-ID Policy Recommendaon............................................................................... 847
Import SaaS Policy Recommendaon.....................................................................848
Import Updated SaaS Policy Recommendaon....................................................850
Remove Deleted SaaS Policy Recommendaon.................................................. 851
Applicaon Level Gateways................................................................................................. 853
Disable the SIP Applicaon-level Gateway (ALG)...........................................................855
Use HTTP Headers to Manage SaaS Applicaon Access..............................................856
Understand SaaS Custom Headers......................................................................... 856
Domains used by the Predefined SaaS Applicaon Types.................................859
Create HTTP Header Inseron Entries using Predefined Types.......................860
Create Custom HTTP Header Inseron Entries...................................................861
Maintain Custom Timeouts for Data Center Applicaons............................................863
Device-ID......................................................................................................... 865
Device-ID Overview...............................................................................................................866
Prepare to Deploy Device-ID...............................................................................................869
Configure Device-ID...............................................................................................................873
Manage Device-ID.................................................................................................................. 876
CLI Commands for Device-ID..............................................................................................878
Threat Prevenon..........................................................................................881
Best Pracces for Securing Your Network from Layer 4 and Layer 7 Evasions........882
Set Up Anvirus, An-Spyware, and Vulnerability Protecon.....................................893
DNS Security............................................................................................................................896
About DNS Security................................................................................................... 896
Cloud-Delivered DNS Signatures and Protecons..............................................897
DNS Security Analycs..............................................................................................898
Enable DNS Security.................................................................................................. 901
DNS Security Data Collecon and Logging.......................................................... 908
Use DNS Queries to Idenfy Infected Hosts on the Network.................................... 910
How DNS Sinkholing Works.....................................................................................910
Configure DNS Sinkholing.........................................................................................911
Configure DNS Sinkholing for a List of Custom Domains................................. 912
Configure the Sinkhole IP Address to a Local Server on Your Network......... 914
See Infected Hosts that Aempted to Connect to a Malicious Domain.........917
Data Filtering........................................................................................................................... 921
Create a Data Filtering Profile................................................................................. 921
Predefined Data Filtering Paerns..........................................................................924
WildFire Inline ML.................................................................................................................. 927
Table of Contents
Configure WildFire Inline ML................................................................................... 927

Set Up File Blocking...............................................................................................................931
Prevent Brute Force Aacks................................................................................................ 934
Customize the Acon and Trigger Condions for a Brute Force Signature...............935
Enable Evasion Signatures.................................................................................................... 939
Monitor Blocked IP Addresses............................................................................................ 940
Threat Signature Categories.................................................................................................943
Create Threat Excepons......................................................................................................951
Custom Signatures..................................................................................................................953
Monitor and Get Threat Reports........................................................................................ 954
Monitor Acvity and Create Custom Reports Based on Threat
Categories......................................................................................................................954
Learn More About Threat Signatures..................................................................... 956
AutoFocus Threat Intelligence for Network Traffic............................................. 959
Share Threat Intelligence with Palo Alto Networks........................................................966
Threat Prevenon Resources............................................................................................... 967
Decrypon.......................................................................................................969
Decrypon Overview.............................................................................................................970
Decrypon Concepts............................................................................................................. 972
Keys and Cerficates for Decrypon Policies...................................................... 972
SSL Forward Proxy...................................................................................................... 974
SSL Forward Proxy Decrypon Profile...................................................................976
SSL Inbound Inspecon............................................................................................. 979
SSL Inbound Inspecon Decrypon Profile.......................................................... 980
SSL Protocol Sengs Decrypon Profile.............................................................. 981
SSH Proxy......................................................................................................................983
SSH Proxy Decrypon Profile.................................................................................. 985
Profile for No Decrypon..........................................................................................986
SSL Decrypon for Ellipcal Curve Cryptography (ECC) Cerficates............. 987
Perfect Forward Secrecy (PFS) Support for SSL Decrypon.............................987
SSL Decrypon and Subject Alternave Names (SANs).................................... 988
TLSv1.3 Decrypon.................................................................................................... 989
High Availability Support for Decrypted Sessions...............................................991
Decrypon Mirroring..................................................................................................992
Prepare to Deploy Decrypon............................................................................................ 993
Work with Stakeholders to Develop a Decrypon Deployment Strategy......993
Develop a PKI Rollout Plan.......................................................................................995
Size the Decrypon Firewall Deployment.............................................................997
Plan a Staged, Priorized Deployment...................................................................998
Define Traffic to Decrypt....................................................................................................1000
Table of Contents
Create a Decrypon Profile....................................................................................1001

Create a Decrypon Policy Rule........................................................................... 1003
Configure SSL Forward Proxy............................................................................................1007
Configure SSL Inbound Inspecon...................................................................................1013
Configure SSH Proxy........................................................................................................... 1016
Configure Server Cerficate Verificaon for Undecrypted Traffic............................1017
Decrypon Exclusions......................................................................................................... 1018
Palo Alto Networks Predefined Decrypon Exclusions...................................1019
Exclude a Server from Decrypon for Technical Reasons...............................1020
Local Decrypon Exclusion Cache........................................................................1021
Create a Policy-Based Decrypon Exclusion..................................................... 1023
Block Private Key Export....................................................................................................1027
Generate a Private Key and Block It.................................................................... 1027
Import a Private Key and Block It.........................................................................1028
Import a Private Key for IKE Gateway and Block It......................................... 1029
Verify Private Key Blocking.................................................................................... 1032
Enable Users to Opt Out of SSL Decrypon.................................................................1034
Temporarily Disable SSL Decrypon............................................................................... 1036
Configure Decrypon Port Mirroring.............................................................................. 1037
Verify Decrypon................................................................................................................. 1040
Troubleshoot and Monitor Decrypon........................................................................... 1044
Decrypon Applicaon Command Center Widgets......................................... 1045
Decrypon Log.......................................................................................................... 1049
Custom Report Templates for Decrypon.......................................................... 1064
Unsupported Parameters by Proxy Type and TLS Version..............................1065
Decrypon Troubleshoong Workflow Examples............................................ 1066
Acvate Free Licenses for Decrypon Features...........................................................1087
URL Filtering.................................................................................................1089
About Palo Alto Networks URL Filtering Soluon....................................................... 1090
How Advanced URL Filtering Works...............................................................................1091
URL Filtering Inline ML.......................................................................................................1093
URL Filtering Use Cases..................................................................................................... 1094
URL Categories..................................................................................................................... 1097
Security-Focused URL Categories........................................................................ 1097
Malicious URL Categories.......................................................................................1098
Verified URL Categories.......................................................................................... 1100
Policy Acons You Can Take Based on URL Categories..................................1101
Plan Your URL Filtering Deployment...............................................................................1104
URL Filtering Best Pracces.............................................................................................. 1107
Acvate The Advanced URL Filtering Subscripon..................................................... 1109
Table of Contents
Configure URL Filtering...................................................................................................... 1111

Test URL Filtering Configuraon...................................................................................... 1115
Verify URL Filtering.................................................................................................. 1115
Verify Advanced URL Filtering.............................................................................. 1115
Configure URL Filtering Inline ML....................................................................................1118
Monitor Web Acvity..........................................................................................................1122
Monitor Web Acvity of Network Users............................................................1122
View the User Acvity Report.............................................................................. 1124
Configure Custom URL Filtering Reports............................................................1126
Log Only the Page a User Visits....................................................................................... 1130
Create a Custom URL Category....................................................................................... 1131
URL Category Excepons...................................................................................................1133
Basic Guidelines For URL Category Excepon Lists.........................................1133
Wildcard Guidelines for URL Category Excepon Lists...................................1133
URL Category Excepon List—Wildcard Examples...........................................1134
Use an External Dynamic List in a URL Filtering Profile............................................. 1136
Allow Password Access to Certain Sites.........................................................................1138
Prevent Credenal Phishing...............................................................................................1141
Methods to Check for Corporate Credenal Submissions..............................1141
Configure Credenal Detecon with the Windows User-ID Agent..............1143
Set Up Credenal Phishing Prevenon............................................................... 1145
Safe Search Enforcement....................................................................................................1149
Safe Search Sengs for Search Providers.......................................................... 1149
Block Search Results when Strict Safe Search is not Enabled........................ 1152
Transparently Enable Safe Search for Users.......................................................1155
URL Filtering Response Pages...........................................................................................1161
Customize the URL Filtering Response Pages...............................................................1165
HTTP Header Logging......................................................................................................... 1167
Request to Change the Category for a URL.................................................................. 1168
Make a Change Request Online............................................................................1168
Make a Bulk Change Request................................................................................1169
Make a Change Request from the Firewall........................................................ 1170
Troubleshoot URL Filtering................................................................................................ 1172
Problems Acvang Advanced URL Filtering.................................................... 1172
PAN-DB Cloud Connecvity Issues..................................................................... 1172
URLs Classified as Not-Resolved.......................................................................... 1173
Incorrect Categorizaon..........................................................................................1174
PAN-DB Private Cloud........................................................................................................1177
M-600 Appliance for PAN-DB Private Cloud.................................................... 1177
Set Up the PAN-DB Private Cloud.......................................................................1179
Enable SSL/TLS Handshake Inspecon...........................................................................1189
Table of Contents
Quality of Service....................................................................................... 1193

QoS Overview....................................................................................................................... 1194
QoS Concepts........................................................................................................................1196
QoS for Applicaons and Users............................................................................ 1196
QoS Policy...................................................................................................................1196
QoS Profile..................................................................................................................1197
QoS Classes................................................................................................................ 1197
QoS Priority Queuing...............................................................................................1198
QoS Bandwidth Management................................................................................1198
QoS Egress Interface................................................................................................1199
QoS for Clear Text and Tunneled Traffic............................................................. 1200
Configure QoS....................................................................................................................... 1201
Configure QoS for a Virtual System................................................................................ 1208
Enforce QoS Based on DSCP Classificaon.................................................................. 1215
QoS Use Cases......................................................................................................................1218
Use Case: QoS for a Single User...........................................................................1218
Use Case: QoS for Voice and Video Applicaons............................................. 1220
VPNs............................................................................................................... 1225
VPN Deployments................................................................................................................1226
Site-to-Site VPN Overview................................................................................................ 1227
Site-to-Site VPN Concepts.................................................................................................1228
IKE Gateway...............................................................................................................1228
Tunnel Interface.........................................................................................................1228
Tunnel Monitoring.....................................................................................................1229
Internet Key Exchange (IKE) for VPN.................................................................. 1229
IKEv2............................................................................................................................ 1232
Set Up Site-to-Site VPN..................................................................................................... 1236
Set Up an IKE Gateway...........................................................................................1236
Define Cryptographic Profiles................................................................................1243
Set Up an IPSec Tunnel...........................................................................................1247
Set Up Tunnel Monitoring...................................................................................... 1250
Enable/Disable, Refresh or Restart an IKE Gateway or IPSec Tunnel...........1251
Test VPN Connecvity............................................................................................ 1253
Interpret VPN Error Messages...............................................................................1254
Site-to-Site VPN Quick Configs........................................................................................1256
Site-to-Site VPN with Stac Roung...................................................................1256
Site-to-Site VPN with OSPF.................................................................................. 1260
Site-to-Site VPN with Stac and Dynamic Roung..........................................1266
Large Scale VPN (LSVPN)......................................................................... 1273
Table of Contents
LSVPN Overview.................................................................................................................. 1274

Create Interfaces and Zones for the LSVPN................................................................. 1275
Enable SSL Between GlobalProtect LSVPN Components.......................................... 1277
About Cerficate Deployment...............................................................................1277
Deploy Server Cerficates to the GlobalProtect LSVPN Components........ 1277
Deploy Client Cerficates to the GlobalProtect Satellites Using SCEP........ 1280
Configure the Portal to Authencate Satellites............................................................ 1283
Configure GlobalProtect Gateways for LSVPN............................................................. 1285
Configure the GlobalProtect Portal for LSVPN............................................................. 1289
GlobalProtect Portal for LSVPN Prerequisite Tasks..........................................1289
Configure the Portal.................................................................................................1289
Define the Satellite Configuraons...................................................................... 1290
Prepare the Satellite to Join the LSVPN.........................................................................1294
Verify the LSVPN Configuraon.......................................................................................1297
LSVPN Quick Configs..........................................................................................................1298
Basic LSVPN Configuraon with Stac Roung............................................... 1298
Advanced LSVPN Configuraon with Dynamic Roung................................. 1301
Advanced LSVPN Configuraon with iBGP....................................................... 1303
Policy.............................................................................................................. 1311
Policy Types........................................................................................................................... 1312
Security Policy....................................................................................................................... 1313
Components of a Security Policy Rule................................................................ 1313
Security Policy Acons............................................................................................ 1316
Create a Security Policy Rule.................................................................................1317
Policy Objects........................................................................................................................1321
Security Profiles.................................................................................................................... 1323
Create a Security Profile Group............................................................................ 1330
Set Up or Override a Default Security Profile Group.......................................1331
Track Rules Within a Rulebase..........................................................................................1334
Rule Numbers............................................................................................................ 1334
Rule UUIDs................................................................................................................. 1336
Enforce Policy Rule Descripon, Tag, and Audit Comment........................................1341
Move or Clone a Policy Rule or Object to a Different Virtual System..................... 1344
Use an Address Object to Represent IP Addresses..................................................... 1346
Address Objects........................................................................................................ 1346
Create an Address Object.......................................................................................1347
Use Tags to Group and Visually Disnguish Objects...................................................1349
Create and Apply Tags.............................................................................................1349
Modify Tags................................................................................................................ 1350
View Rules by Tag Group........................................................................................1351
Table of Contents
Use an External Dynamic List in Policy.......................................................................... 1353

External Dynamic List.............................................................................................. 1353
Formang Guidelines for an External Dynamic List........................................ 1356
Built-in External Dynamic Lists............................................................................. 1358
Configure the Firewall to Access an External Dynamic List............................1359
Configure the Firewall to Access an External Dynamic List from the EDL
Hosng Service..........................................................................................................1362
Retrieve an External Dynamic List from the Web Server................................1369
View External Dynamic List Entries..................................................................... 1369
Exclude Entries from an External Dynamic List.................................................1370
Enforce Policy on an External Dynamic List.......................................................1371
Find External Dynamic Lists That Failed Authencaon.................................1374
Disable Authencaon for an External Dynamic List...................................... 1375
Register IP Addresses and Tags Dynamically.................................................................1377
Use Dynamic User Groups in Policy................................................................................1379
Use Auto-Tagging to Automate Security Acons.........................................................1382
Monitor Changes in the Virtual Environment................................................................1386
Enable VM Monitoring to Track Changes on the Virtual Network................1386
Aributes Monitored on Virtual Machines in Cloud Plaorms......................1388
Use Dynamic Address Groups in Policy.............................................................. 1393
CLI Commands for Dynamic IP Addresses and Tags................................................... 1397
Enforce Policy on Endpoints and Users Behind an Upstream Device...................... 1400
Use XFF Values for Policy Based on Source Users........................................... 1400
Use XFF IP Address Values in Security Policy and Logging............................ 1401
Use the IP Address in the XFF Header to Troubleshoot Events.................... 1404
Policy-Based Forwarding.................................................................................................... 1406
PBF............................................................................................................................... 1406
Create a Policy-Based Forwarding Rule.............................................................. 1408
Use Case: PBF for Outbound Access with Dual ISPs.......................................1411
Test Policy Rules................................................................................................................... 1421
Virtual Systems............................................................................................ 1423

Virtual Systems Overview.................................................................................................. 1424
Virtual System Components and Segmentaon................................................ 1424
Benefits of Virtual Systems.................................................................................... 1425
Use Cases for Virtual Systems...............................................................................1425
Plaorm Support and Licensing for Virtual Systems........................................ 1426
Administrave Roles for Virtual Systems............................................................1426
Shared Objects for Virtual Systems......................................................................1427
Communicaon Between Virtual Systems..................................................................... 1428
Inter-VSYS Traffic That Must Leave the Firewall...............................................1428
Table of Contents
Inter-VSYS Traffic That Remains Within the Firewall....................................... 1429

Inter-VSYS Communicaon Uses Two Sessions................................................ 1431
Shared Gateway....................................................................................................................1432
External Zones and Shared Gateway................................................................... 1432
Networking Consideraons for a Shared Gateway.......................................... 1433
Configure Virtual Systems.................................................................................................. 1434
Configure Inter-Virtual System Communicaon within the Firewall........................1440
Configure a Shared Gateway.............................................................................................1441
Customize Service Routes for a Virtual System............................................................1442
Customize Service Routes to Services for Virtual Systems.............................1442
Configure a PA-7000 Series Firewall for Logging Per Virtual System...........1444
Configure Administrave Access Per Virtual System or Firewall...................1446
Virtual System Funconality with Other Features....................................................... 1448
Zone Protecon and DoS Protecon.....................................................1449

Network Segmentaon Using Zones...............................................................................1450
How Do Zones Protect the Network?............................................................................ 1451
Zone Defense........................................................................................................................ 1452
Zone Defense Tools..................................................................................................1452
How Do the Zone Defense Tools Work?............................................................ 1454
Firewall Placement for DoS Protecon............................................................... 1455
Baseline CPS Measurements for Seng Flood Thresholds............................ 1455
Zone Protecon Profiles..........................................................................................1457
Packet Buffer Protecon.........................................................................................1461
DoS Protecon Profiles and Policy Rules............................................................1463
Configure Zone Protecon to Increase Network Security......................................... 1470
Configure Reconnaissance Protecon................................................................. 1470
Configure Packet Based Aack Protecon.........................................................1471
Configure Protocol Protecon............................................................................... 1472
Configure Packet Buffer Protecon..................................................................... 1476
Configure Packet Buffer Protecon Based on Latency....................................1477
Configure Ethernet SGT Protecon..................................................................... 1478
DoS Protecon Against Flooding of New Sessions..................................................... 1480
Mulple-Session DoS Aack................................................................................. 1480
Single-Session DoS Aack......................................................................................1484
Configure DoS Protecon Against Flooding of New Sessions....................... 1484
End a Single Session DoS Aack.......................................................................... 1487
Idenfy Sessions That Use Too Much of the On-Chip Packet Descriptor... 1488
Discard a Session Without a Commit.................................................................. 1491
Cerficaons................................................................................................ 1493
Table of Contents
Enable FIPS and Common Criteria Support...................................................................1494

Access the Maintenance Recovery Tool (MRT)..................................................1494
Change the Operaonal Mode to FIPS-CC Mode............................................ 1496
FIPS-CC Security Funcons...............................................................................................1499
Scrub the Swap Memory on Firewalls or Appliances Running in FIPS-CC Mode.. 1501
Table of Contents
Geng Started
The following topics provide detailed steps to help you deploy a new Palo Alto
Networks next-generaon firewall. They provide details for integrang a new
firewall into your network and how to set up a basic security policy. For guidance on
connuing to deploy the security plaorm features to address your network security
needs, review the Best Pracces for Compleng the Firewall Deployment.
> Integrate the Firewall into Your Management Network

> Register the Firewall
> Segment Your Network Using Interfaces and Zones
> Set Up a Basic Security Policy
> Assess Network Traffic
> Enable Free WildFire Forwarding
> Best Pracces for Compleng the Firewall Deployment
21
Geng Started
Integrate the Firewall into Your Management Network

All Palo Alto Networks firewalls provide an out-of-band management port (MGT) that you can
use to perform the firewall administraon funcons. By using the MGT port, you separate the
management funcons of the firewall from the data processing funcons, safeguarding access
to the firewall and enhancing performance. When using the web interface, you must perform
all inial configuraon tasks from the MGT port even if you plan to use an in-band data port for
managing your firewall going forward.
Some management tasks, such as retrieving licenses and updang the threat and applicaon
signatures on the firewall require access to the Internet. If you do not want to enable external
access to your MGT port, you will need to either set up an in-band data port to provide access to
required external services (using service routes) or plan to manually upload updates regularly.
Do not enable access to your management interface from the internet or from other
untrusted zones inside your enterprise security boundary. This applies whether you use the
dedicated management port (MGT) or you configured a data port as your management
interface. When integrang your firewall into your management network, follow the
Adminstrave Access Best Pracces to ensure that you are securing administrave
access to your firewalls and other security devices in a way that prevents successful
aacks.
The following topics describe how to perform the inial configuraon steps that are necessary
to integrate a new firewall into the management network and deploy it in a basic security
configuraon.
• Determine Your Management Strategy
• Perform Inial Configuraon
• Set Up Network Access for External Services
The following topics describe how to integrate a single Palo Alto Networks next-generaon
firewall into your network. However, for redundancy, consider deploying a pair of firewalls
in a High Availability configuraon.
Determine Your Management Strategy

The Palo Alto Networks firewall can be configured and managed locally or it can be managed
centrally using Panorama, the Palo Alto Networks centralized security management system. If
you have six or more firewalls deployed in your network, use Panorama to achieve the following
benefits:
• Reduce the complexity and administrave overhead in managing configuraon, policies,
soware and dynamic content updates. Using device groups and templates on Panorama, you
can effecvely manage firewall-specific configuraon locally on a firewall and enforce shared
policies across all firewalls or device groups.
• Aggregate data from all managed firewalls and gain visibility across all the traffic on your
network. The Applicaon Command Center (ACC) on Panorama provides a single glass pane
for unified reporng across all the firewalls, allowing you to centrally analyze, invesgate and
report on network traffic, security incidents and administrave modificaons.
Geng Started
The procedures that follow describe how to manage the firewall using the local web interface. If
you want to use Panorama for centralized management, first Perform Inial Configuraon and
verify that the firewall can establish a connecon to Panorama. From that point on you can use
Panorama to configure your firewall centrally.
Perform Inial Configuraon

By default, the PA-Series firewall has an IP address of 192.168.1.1 and a username/password of
admin/admin. For security reasons, you must change these sengs before connuing with other
firewall configuraon tasks. You must perform these inial configuraon tasks either from the
MGT interface, even if you do not plan to use this interface for your firewall management, or using
a direct serial connecon to the console port on the firewall.
STEP 1 | Install your firewall and connect power to it.
If your firewall model has dual power supplies, connect the second power supply for
redundancy. Refer to the hardware reference guide for your model for details.
STEP 2 | Gather the required informaon from your network administrator.

• IP address for MGT port
• Netmask
• Default gateway
• DNS server address
STEP 3 | Connect your computer to the firewall.

You can connect to the firewall in one of the following ways:
• Connect a serial cable from your computer to the Console port and connect to the firewall
using terminal emulaon soware (9600-8-N-1). Wait a few minutes for the boot-up
sequence to complete; when the firewall is ready, the prompt changes to the name of the
firewall, for example PA-220 login.
• Connect an RJ-45 Ethernet cable from your computer to the MGT port on the firewall. From
a browser, go to https://192.168.1.1.
You may need to change the IP address on your computer to an address in the
192.168.1.0/24 network, such as 192.168.1.2, to access this URL.
STEP 4 | When prompted, log in to the firewall.

You must log in using the default username and password (admin/admin). The firewall will
begin to inialize.
Geng Started
STEP 5 | Set a secure password for the admin account.
Starng with PAN-OS 9.0.4, the predefined, default administrator password (admin/
admin) must be changed 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.
Be sure to use the best pracces for password strength to ensure a strict password
and review the password complexity sengs.
1. Select Device > Administrators.

2. Select the admin role.
3. Enter the current default password and the new password.
4. Click OK to save your sengs.
Geng Started
STEP 6 | Configure the MGT interface.

1. Select Device > Setup > Interfaces and edit the Management interface.
2. Configure the address sengs for the MGT interface using one of the following
methods:
• To configure stac IP address sengs for the MGT interface, set the IP Type to Stac
and enter the IP Address, Netmask, and Default Gateway.
• To dynamically configure the MGT interface address sengs, set the IP Type to DHCP
Client. To use this method, you must Configure the Management Interface as a DHCP
Client.
To prevent unauthorized access to the management interface, it is a an

administrave best pracce to Add the Permied IP Addresses from which an
administrator can access the MGT interface.
3. Set the Speed to auto-negoate.
4. Select which management services to allow on the interface.
Make sure Telnet and HTTP are not selected because these services use
plaintext and are not as secure as the other services and could compromise
administrator credenals.
5. Click OK.
Geng Started
STEP 7 | Configure DNS, update server, and proxy server sengs.
You must manually configure at least one DNS server on the firewall or it will not be
able to resolve hostnames; it will not use DNS server sengs from another source, such
as an ISP.
1. Select Device > Setup > Services.

• For mul-virtual system plaorms, select Global and edit the Services secon.
• For single virtual system plaorms, edit the Services secon.
2. On the Services tab, for DNS, select one of the following:
• Servers—Enter the Primary DNS Server address and Secondary DNS Server address.
• DNS Proxy Object—From the drop-down, select the DNS Proxy that you want to use
to configure global DNS services, or click DNS Proxy to configure a new DNS proxy
object.
3. Click OK.
Geng Started
STEP 8 | Configure date and me (NTP) sengs.

• For mul-virtual system plaorms, select Global and edit the Services secon.
• For single virtual system plaorms, edit the Services secon.
2. On the NTP tab, to use the virtual cluster of me servers on the Internet, enter the
hostname pool.ntp.org as the Primary NTP Server or enter the IP address of your
primary NTP server.
3. (Oponal) Enter a Secondary NTP Server address.

4. (Oponal) To authencate me updates from the NTP server(s), for Authencaon Type,
select one of the following for each server:
• None—(Default) Disables NTP authencaon.
• Symmetric Key—Firewall uses symmetric key exchange (shared secrets) to
authencate me updates.
• Key ID—Enter the Key ID (1-65534).
• Algorithm—Select the algorithm to use in NTP authencaon (MD5 or SHA1).
• Autokey—Firewall uses autokey (public key cryptography) to authencate me
updates.
5. Click OK.
STEP 9 | (Oponal) Configure general firewall sengs as needed.

1. Select Device > Setup > Management and edit the General Sengs.
2. Enter a Hostname for the firewall and enter your network Domain name. The domain
name is just a label; it will not be used to join the domain.
3. Enter Login Banner text that informs users who are about to log in that they require
authorizaon to access the firewall management funcons.
As a best pracce, avoid using welcoming verbiage. Addionally, you should ask
your legal department to review the banner message to ensure it adequately
warns that unauthorized access is prohibited.
4. Enter the Latude and Longitude to enable accurate placement of the firewall on the
world map.
5. Click OK.
Geng Started
STEP 10 | Commit your changes.
When the configuraon changes are saved, you lose connecvity to the web interface
because the IP address has changed.
Click Commit at the top right of the web interface. The firewall can take up to 90 seconds to
save your changes.
STEP 11 | Connect the firewall to your network.

1. Disconnect the firewall from your computer.
2. Connect the MGT port to a switch port on your management network using an RJ-45
Ethernet cable. Make sure that the switch port you cable the firewall to is configured for
auto-negoaon.
STEP 12 | Open an SSH management session to the firewall.

Using a terminal emulaon soware, such as PuTTY, launch an SSH session to the firewall using
the new IP address you assigned to it.
Geng Started
STEP 13 | Verify network access to external services required for firewall management, such as the Palo
Alto Networks Update Server.
You can do this in one of the following ways:
• If you do not want to allow external network access to the MGT interface, you will need to
set up a data port to retrieve required service updates. Connue to Set Up Network Access
for External Services.
• If you do plan to allow external network access to the MGT interface, verify that you have
connecvity and then proceed to Register the Firewall and Acvate Subscripon Licenses.
1. Use update server connecvity test to verify network connecvity to the Palo Alto
Networks Update server as shown in the following example:
1. Select Device > Troubleshoong, and select Update Server Connecvity from the
Select Test drop-down.
2. Execute the update server connecvity test.
2. Use the following CLI command to retrieve informaon on the support entlement for
the firewall from the Palo Alto Networks update server:
request support
check
If you have connecvity, the update server will respond with the support status for your
firewall. If your firewall is not yet registered, the update server returns the following
message:
Contact Us
https://www.paloaltonetworks.com/company/contact-us.html
Support Home
https://www.paloaltonetworks.com/support/tabs/overview.html
Device not found on this update server
Geng Started
Set Up Network Access for External Services

By default, the firewall uses the MGT interface to access remote services, such as DNS servers,
content updates, and license retrieval. If you do not want to enable external network access to
your management network, you must set up an in-band data port to provide access to required
external services and set up service routes to instruct the firewall what port to use to access the
external services.
Do not enable management access from the internet or from other untrusted zones inside
your enterprise security boundary. Follow the Adminstrave Access Best Pracces to
ensure that you are properly securing your firewall.
This task requires familiarity with firewall interfaces, zones, and policies. For more
informaon on these topics, see Configure Interfaces and Zones and Set Up a Basic
Security Policy.
STEP 1 | Decide which interface you want to use for access to external services and connect it to your
switch or router port.
The interface you use must have a stac IP address.
STEP 2 | Log in to the web interface.

Using a secure connecon (hps) from your web browser, log in using the new IP address
and password you assigned during inial configuraon (hps://<IP address>). You will see a
cerficate warning; that is okay. Connue to the web page.
STEP 3 | (Oponal) The firewall comes preconfigured with a default virtual wire interface between
ports Ethernet 1/1 and Ethernet 1/2 (and a corresponding default security policy and
zones). If you do not plan to use this virtual wire configuraon, you must manually delete the
configuraon to prevent it from interfering with other interface sengs you define.
You must delete the configuraon in the following order:
1. To delete the default security policy, select Policies > Security, select the rule, and click
Delete.
2. To delete the default virtual wire, select Network > Virtual Wires, select the virtual wire
and click Delete.
3. To delete the default trust and untrust zones, select Network > Zones, select each zone
and click Delete.
4. To delete the interface configuraons, select Network > Interfaces and then select each
interface (ethernet1/1 and ethernet1/2) and click Delete.
5. Commit the changes.
Geng Started
STEP 4 | Configure the interface you plan to use for external access to management services.
1. Select Network > Interfaces and select the interface that corresponds to the interface
you cabled in Step 1.
2. Select the Interface Type. Although your choice here depends on your network topology,
this example shows the steps for Layer3.
3. On the Config tab, expand the Security Zone drop-down and select New Zone.
4. In the Zone dialog, enter a Name for new zone, for example Management, and then click
OK.
5. Select the IPv4 tab, select the Stac radio buon, and click Add in the IP secon,
and enter the IP address and network mask to assign to the interface, for example
192.168.1.254/24. You must use a stac IP address on this interface.
6. Select Advanced > Other Info, expand the Management Profile drop-down, and select
New Management Profile.
7. Enter a Name for the profile, such as allow_ping, and then select the services you want
to allow on the interface. For the purposes of allowing access to the external services,
you probably only need to enable Ping and then click OK.
Geng Started
These services provide management access to the firewall, so only select the
services that correspond to the management acvies you want to allow on this
interface. For example, don’t enable HTTP or Telnet because those protocols
transmit in plaintext and therefore aren’t secure. Or if you plan to use the MGT
interface for firewall configuraon tasks through the web interface or CLI, you
don’t enable HTTP, HTTPS, SSH, or Telnet so that you prevent unauthorized
access through the interface (if you must allow HTTPS or SSH in this scenario,
limit access to a specific set of Permied IP Addresses). For details, see Use
Interface Management Profiles to Restrict Access.
8. To save the interface configuraon, click OK.
Geng Started
STEP 5 | Configure the Service Routes.

By default, the firewall uses the MGT interface to access the external services it requires. To
change the interface the firewall uses to send requests to external services, you must edit the
service routes.
This example shows how to set up global service routes. For informaon on seng up
network access to external services on a virtual system basis rather than a global basis,
see Customize Service Routes to Services for Virtual Systems.
1. Select Device > Setup > Services > Global and click Service Route Configuraon.
For the purposes of acvang your licenses and geng the most recent content
and soware updates, you will want to change the service route for DNS, Palo
Alto Networks Services, URL Updates, and AutoFocus.
2. Click the Customize radio buon, and select one of the following:
• For a predefined service, select IPv4 or IPv6 and click the link for the service. To
limit the drop-down list for Source Address, select Source Interface and select the
interface you just configured. Then select a Source Address (from that interface) as
the service route.
If more than one IP address is configured for the selected interface, the Source
Address drop-down allows you to select an IP address.
• To create a service route for a custom desnaon, select Desnaon, and click Add.
Enter a Desnaon IP address. An incoming packet with a desnaon address that
matches this address will use as its source the Source Address you specify for this
service route. To limit the drop-down for Source Address, select a Source Interface. If
Geng Started
more than one IP address is configured for the selected interface, the Source Address
drop-down allows you to select an IP address.
3. Click OK to save the sengs.

4. Repeat Steps 5.2 - 5.3 above for each service route you want to modify.
5. Commit your changes.
STEP 6 | Configure an external-facing interface and an associated zone and then create a security
policy rule to allow the firewall to send service requests from the internal zone to the
external zone.
1. Select Network > Interfaces and then select the external-facing interface. Select Layer3
as the Interface Type, Add the IP address (on the IPv4 or IPv6 tab), and create the
associated Security Zone (on the Config tab), such as Internet. This interface must have a
stac IP address; you do not need to set up management services on this interface.
2. To set up a security rule that allows traffic from your internal network to the Palo Alto
Networks update server, select Policies > Security and click Add.
As a best pracce when creang Security policy rules, use applicaon-based rules
instead of port-based rules to ensure that you are accurately idenfying the underlying
applicaon regardless of the port, protocol, evasive taccs, or encrypon in use. Always
leave the Service set to applicaon-default. In this case, create a security policy rule
that allows access to the update server (and other Palo Alto Networks services).
Geng Started
STEP 7 | Create a NAT policy rule.

1. If you are using a private IP address on the internal-facing interface, you will need to
create a source NAT rule to translate the address to a publicly routable address. Select
Policies > NAT and then click Add. At a minimum you must define a name for the rule
(General tab), specify a source and desnaon zone, Management to Internet in this
case (Original Packet tab), and define the source address translaon sengs (Translated
Packet tab) and then click OK.
STEP 8 | Select Device > Troubleshoong and verify that you have connecvity from the data port
to the external services, including the default gateway, using the Ping connecvity test, and
the Palo Alto Networks Update Server using the Update Server Connecvity test. In this
example, the firewall connecvity to the Palo Alto Networks Update Server is tested.
Aer you verify you have the required network connecvity, connue to Register the Firewall
and Acvate Subscripon Licenses.
1. Select Update Server from the Select Test drop-down.
2. Execute the Palo Alto Networks Update Server connecvity test.
3. Access the firewall CLI, and use the following command to retrieve informaon on the
support entlement for the firewall from the Palo Alto Networks update server:
request support
check
If you have connecvity, the update server will respond with the support status for
your firewall. Because your firewall is not registered, the update server will return the
following message:
Contact Us
https://www.paloaltonetworks.com/company/contact-us.html
Support Home
https://www.paloaltonetworks.com/support/tabs/overview.html
Geng Started
Device not found on this update server
Geng Started
Register the Firewall

Before you can acvate support and other licenses and subscripons, you must first register the
firewall. Before you can register a firewall, though, you must first have an acve support account.
Perform one of the following tasks depending on whether you have an acve support account:
• If you don’t have an acve support account, then Create a New Support Account and Register a
Firewall.
• If you already have an acve support account, then you are ready to Register a Firewall.
• (Oponal) Perform Day 1 Configuraon on a registered firewall.
• If your firewall uses line cards such as an NPC (Network Processing Card), then Register the
Firewall Line Cards.
If you are registering a VM-Series firewall, refer to the VM-Series Deployment Guide
for instrucons.
Create a New Support Account and Register a Firewall

If you do not already have an acve Palo Alto Networks support account, then you need to
register your firewall when you create your new support account.
STEP 1 | Go to the Palo Alto Networks Customer Support Portal.
STEP 2 | Click Create my account.
Geng Started
STEP 3 | Enter Your Email Address, check I’m not a robot, and click Submit.
STEP 4 | Select Register device using Serial Number or Authorizaon Code and click Next.
Geng Started
STEP 5 | Complete the registraon form.

1. Enter the contact details for the person in your organizaon who will own this account.
Required fields are indicated by red asterisks.
2. Create a UserID and Password for the account. Required fields are indicated by red
asterisks.
3. Enter the Device Serial Number or Auth Code.
4. Enter your Sales Order Number or Customer Id.
5. To ensure that you are always alerted to the latest updates and security advisories,
Subscribe to Content Update Emails, Subscribe to Security Advisories, and Subscribe to
Soware Update Emails.
6. Select the check box to agree to the End User Agreement and Submit.
Register a Firewall
If you already have an acve Palo Alto Networks Customer Support account, perform the
following task to register your firewall.
Geng Started
STEP 1 | Log in to the firewall web interface.

Using a secure connecon (HTTPS) from your web browser, log in using the new IP address
and password you assigned during inial configuraon (hps://<IP address>).
STEP 2 | Locate your serial number and copy it to the clipboard.

On the Dashboard, locate your Serial Number in the General Informaon secon of the screen.
STEP 3 | Go to the Palo Alto Networks Customer Support Portal and, if not already logged in, Sign In
now.
Geng Started
STEP 4 | Register the firewall.

1. On the Support Home page, click Register a Device.
2. Select Register device using Serial Number or Authorizaon Code, and then click Next.
3. Enter the firewall Serial Number (you can copy and paste it from the firewall Dashboard).
4. (Oponal) Enter the Device Name and Device Tag.
5. (Oponal) If the device will not have a connecon to the internet, select the Device will
be used offline check box and then, from the drop-down, select the OS Release you plan
to use.
6. Provide informaon about where you plan to deploy the firewall including the Address,
City, Postal Code, and Country.
7. Read the End User License Agreement (EULA) and the Support Agreement, then Agree
and Submit.
Geng Started
You can view the entry for the firewall you just registered under Devices.
STEP 5 | (Firewalls with line cards) To ensure that you receive support for your firewall’s line cards,
make sure to Register the Firewall Line Cards.
(Oponal) Perform Day 1 Configuraon

Aer you register your firewall, you have the opon of running Day 1 Configuraon. The Day
1 Configuraon tool provides configuraon templates informed by Palo Alto Networks best
pracces, which you can use as a starng point to build the rest of your configuraon.
The benefits of Day 1 Configuraon templates include:
• Faster implementaon me
• Reduced configuraon errors
• Improved security posture
Perform Day 1 Configuraon by following these steps:
Geng Started
STEP 1 | From the page that displays aer you have registered your firewall, select Run Day 1
Configuraon.
If you’ve already registered your firewall but haven’t run Day 1 Configuraon, you can
also run it from the Customer Support Portal home page by selecng Tools > Run Day
1 Configuraon.
STEP 2 | Enter the Hostname and Pan OS Version for your new device, and oponally, the Serial
Number and Device Type.
Geng Started
STEP 3 | Under Management, select either Stac or DHCP Client for your Management Type.
Selecng Stac will require you fill out the IPV4, Subnet Mask, and Default Gateway fields.
Selecng DHCP Client only requires that you enter the Primary DNS and Secondary DNS. A
device configured in DHCP client mode will ensure the management interface receives an IP
address from the local DHCP server, or it will fill out all the parameters if they are known.
STEP 4 | Fill out all fields under Logging.
STEP 5 | Click Generate Config File.
Geng Started
STEP 6 | To import and load the Day 1 Configuraon file you just downloaded to your firewall:
1. Log into your firewall web interface.
2. Select Device > Setup > Operaons.
3. Click Import named configuraon snapshot.
4. Select the file.
Register the Firewall Line Cards

The following firewalls use line cards that must be registered to receive support with
troubleshoong and returns:
• PA-7000 Series firewalls
• PA-5450 firewall
If you do not have a Palo Alto Networks Customer Support account, create one by following the
steps at Create a New Support Account and Register a Firewall. Return to these instrucons aer
creang your Customer Support account and registering your firewall.
STEP 1 | Go to the Palo Alto Networks Customer Support Portal and, if not already logged in, Sign In
now.
STEP 2 | Select Assets > Line Cards/Opcs/FRUs.
STEP 3 | Register Components.
STEP 4 | Enter the Palo Alto Networks Sales Order Number of the line cards into the Sales Order
Number field to display the line cards eligible for registraon.
STEP 5 | Register the line cards to your firewall by entering its chassis serial number in the Serial
Number field. The Locaon Informaon below auto-populates based on the registraon
informaon of your firewall.
STEP 6 | Click Agree and Submit to accept the legal terms. The system updates to display the
registered line cards under Assets > Line Cards/Opcs/FRUs.
Geng Started
Segment Your Network Using Interfaces and Zones

Traffic must pass through the firewall in order for the firewall to manage and control it. Physically,
traffic enters and exits the firewall through interfaces. The firewall determines how to act on a
packet based on whether the packet matches a Security policy rule. At the most basic level, each
Security policy rule must idenfy where the traffic came from and where it is going. On a Palo
Alto Networks next-generaon firewall, Security policy rules are applied between zones. A zone
is a grouping of interfaces (physical or virtual) that represents a segment of your network that
is connected to, and controlled by, the firewall. Because traffic can only flow between zones if
there is a Security policy rule to allow it, this is your first line of defense. The more granular the
zones you create, the greater control you have over access to sensive applicaons and data and
the more protecon you have against malware moving laterally throughout your network. For
example, you might want to segment access to the database servers that store your customer data
into a zone called Customer Data. You can then define security policies that only permit certain
users or groups of users to access the Customer Data zone, thereby prevenng unauthorized
internal or external access to the data stored in that segment.
• Network Segmentaon for a Reduced Aack Surface
• Configure Interfaces and Zones
Network Segmentaon for a Reduced Aack Surface

The following diagram shows a very basic example of Network Segmentaon Using Zones. The
more granular you make your zones (and the corresponding security policy rules that allows traffic
between zones), the more you reduce the aack surface on your network. This is because traffic
can flow freely within a zone (intra-zone traffic), but traffic cannot flow between zones (inter-
zone traffic) unl you define a Security policy rule that allows it. Addionally, an interface cannot
process traffic unl you have assigned it to a zone. Therefore, by segmenng your network into
granular zones you have more control over access to sensive applicaons or data and you can
prevent malicious traffic from establishing a communicaon channel within your network, thereby
reducing the likelihood of a successful aack on your network.
Geng Started
Configure Interfaces and Zones

Aer you idenfy how you want to segment your network and the zones you will need to create
to achieve the segmentaon (as well as the interfaces to map to each zone), you can begin
configuring the interfaces and zones on the firewall. Configure interfaces on the firewall the to
support the topology of each part of the network you are connecng to. The following workflow
shows how to configure Layer 3 interfaces and assign them to zones. For details on integrang the
firewall using a different type of interface deployments (for example as virtual wire interfaces or as
Layer 2 interfaces), see the PAN-OS Networking Adminstrator’s Guide.
The firewall comes preconfigured with a default virtual wire interface between ports
Ethernet 1/1 and Ethernet 1/2 (and a corresponding default security policy and virtual
router). If you do not plan to use the default virtual wire, you must manually delete the
configuraon and commit the change before proceeding to prevent it from interfering with
other sengs you define. For instrucons on how to delete the default virtual wire and its
associated security policy and zones, see Step 3 in Set Up Network Access for External
Services.
STEP 1 | Configure a default route to your Internet router.

1. Select Network > Virtual Router and then select the default link to open the Virtual
Router dialog.
2. Select the Stac Routes tab and click Add. Enter a Name for the route and enter the
route in the Desnaon field (for example, 0.0.0.0/0).
3. Select the IP Address radio buon in the Next Hop field and then enter the IP address
and netmask for your Internet gateway (for example, 203.0.113.1).
4. Click OK twice to save the virtual router configuraon.
Geng Started
STEP 2 | Configure the external interface (the interface that connects to the Internet).
1. Select Network > Interfaces and then select the interface you want to configure. In this
example, we are configuring Ethernet1/8 as the external interface.
2. Select the Interface Type. Although your choice here depends on interface topology, this
example shows the steps for Layer3.
3. On the Config tab, select New Zone from the Security Zone drop-down. In the Zone
dialog, define a Name for new zone, for example Internet, and then click OK.
4. In the Virtual Router drop-down, select default.
5. To assign an IP address to the interface, select the IPv4 tab, click Add in the IP secon,
203.0.113.23/24.
6. To enable you to ping the interface, select Advanced > Other Info, expand the
Management Profile drop-down, and select New Management Profile. Enter a Name for
the profile, select Ping and then click OK.
Geng Started
STEP 3 | Configure the interface that connects to your internal network.
In this example, the interface connects to a network segment that uses private IP
addresses. Because private IP addresses cannot be routed externally, you have to
configure NAT.
1. Select Network > Interfaces and select the interface you want to configure. In this
example, we are configuring Ethernet1/15 as the internal interface our users connect to.
2. Select Layer3 as the Interface Type.
3. On the Config tab, expand the Security Zone drop-down and select New Zone. In the
Zone dialog, define a Name for new zone, for example Users, and then click OK.
4. Select the same Virtual Router you used previously, default in this example.
192.168.1.4/24.
6. To enable you to ping the interface, select the management profile that you just created.
STEP 4 | Configure the interface that connects to your data center applicaons.
Make sure you define granular zones to prevent unauthorized access to sensive
applicaons or data and eliminate the possibility of malware moving laterally within
your data center.
1. Select the interface you want to configure.

2. Select Layer3 from the Interface Type drop-down. In this example, we are configuring
Ethernet1/1 as the interface that provides access to your data center applicaons.
3. On the Config tab, expand the Security Zone drop-down and select New Zone. In the
Zone dialog, define a Name for new zone, for example Data Center Applicaons, and
then click OK.
4. Select the same Virtual Router you used previously, default in this example.
10.1.1.1/24.
6. To enable you to ping the interface, select the management profile that you created.
Geng Started
STEP 5 | (Oponal) Create tags for each zone.

Tags allow you to visually scan policy rules.
1. Select Objects > Tags and Add.
2. Select a zone Name.
3. Select a tag Color and click OK.
STEP 6 | Save the interface configuraon.

Click Commit.
STEP 7 | Cable the firewall.

Aach straight through cables from the interfaces you configured to the corresponding switch
or router on each network segment.
STEP 8 | Verify that the interfaces are acve.

Select Dashboard and verify that the interfaces you configured show as green in the Interfaces
widget.
Geng Started
Set Up a Basic Security Policy

Now that you defined some zones and aached them to interfaces, you are ready to begin
creang your Security Policy. The firewall will not allow any traffic to flow from one zone to
another unless there is a Security policy rule that allows it. When a packet enters a firewall
interface, the firewall matches the aributes in the packet against the Security policy rules to
determine whether to block or allow the session based on aributes such as the source and
desnaon security zone, the source and desnaon IP address, the applicaon, user, and the
service. The firewall evaluates incoming traffic against the Security policy rulebase from le to
right and from top to boom and then takes the acon specified in the first Security rule that
matches (for example, whether to allow, deny, or drop the packet). This means that you must
order the rules in your Security policy rulebase so that more specific rules are at the top of the
rulebase and more general rules are at the boom to ensure that the firewall is enforcing policy as
expected.
Even though a Security policy rule allows a packet, this does not mean that the traffic is free of
threats. To enable the firewall to scan the traffic that it allows based on a Security policy rule, you
must also aach Security Profiles—including URL Filtering, Anvirus, An-Spyware, File Blocking,
and WildFire Analysis—to each rule (the profiles you can use depend on which Subscripons
you purchased). When creang your basic Security policy, use the predefined security profiles to
ensure that the traffic you allow into your network is being scanned for threats. You can customize
these profiles later as needed for your environment.
Use the following workflow set up a very basic Security policy that enables access to the network
infrastructure, to data center applicaons, and to the internet. This enables you to get the firewall
up and running so that you can verify that you have successfully configured the firewall. However,
this inial policy is not comprehensive enough to protect your network. Aer you verify that you
successfully configured the firewall and integrated it into your network, proceed with creang
a Best Pracce Internet Gateway Security Policy that safely enables applicaon access while
protecng your network from aack.
STEP 1 | (Oponal) Delete the default Security policy rule.
By default, the firewall includes a Security policy rule named rule1 that allows all traffic from
Trust zone to Untrust zone. You can either delete the rule or modify the rule to reflect your
zone-naming convenons.
Geng Started
STEP 2 | Allow access to your network infrastructure resources.

1. Select Policies > Security and click Add.
2. In the General tab, enter a descripve Name for the rule.
3. In the Source tab, set the Source Zone to Users.
4. In the Desnaon tab, set the Desnaon Zone to IT Infrastructure.
As a best pracce, use address objects in the Desnaon Address field to enable
access to specific servers or groups of servers only, parcularly for services such
as DNS and SMTP that are commonly exploited. By restricng users to specific
desnaon server addresses, you can prevent data exfiltraon and command
and control traffic from establishing communicaon through techniques such as
DNS tunneling.
5. In the Applicaons tab, Add the applicaons that correspond to the network services
you want to safely enable. For example, select dns, ntp, ocsp, ping, and smtp.
6. In the Service/URL Category tab, keep the Service set to applicaon-default.
7. In the Acons tab, set the Acon Seng to Allow.
8. Set Profile Type to Profiles and select the following security profiles to aach to the
policy rule:
• For Anvirus, select default
• For Vulnerability Protecon, select strict
• For An-Spyware, select strict
• For URL Filtering, select default
• For File Blocking, select basic file blocking
• For WildFire Analysis, select default
9. Verify that Log at Session End is enabled. Only traffic that matches a Security policy rule
will be logged.
10. Click OK.
Geng Started
STEP 3 | Enable access to general internet applicaons.
This is a temporary rule that allows you to gather informaon about the traffic on your
network. Aer you have more insight into which applicaons your users need to access,
you can make informed decisions about which applicaons to allow and create more
granular applicaon-based rules for each user group.
1. Select Policies > Security and Add a rule.

4. In the Desnaon tab, set the Desnaon Zone to Internet.
5. In the Applicaons tab, Add an Applicaon Filter and enter a Name. To safely enable
access to legimate web-based applicaons, set the Category in the applicaon filter
to general-internet and then click OK. To enable access to encrypted sites, Add the ssl
applicaon.
policy rule:
• For Vulnerability Protecon, select strict
• For An-Spyware, select strict
• For URL Filtering, select default
• For File Blocking, select strict file blocking
• For WildFire Analysis, select default
9. Verify that Log at Session End is enabled. Only traffic that matches a security rule will be
logged.
10. Click OK.
Geng Started
STEP 4 | Enable access to data center applicaons.

1. Select Policies > Security and Add a rule.
2. In the General tab, Enter a descripve Name for the rule.
4. In the Desnaon tab, set the Desnaon Zone to Data Center Applicaons.
5. In the Applicaons tab, Add the applicaons that correspond to the network services
you want to safely enable. For example, select acvesync, imap, kerberos, ldap, ms-
exchange, and ms-lync.
policy rule:
• For Vulnerability Protecon select strict
• For An-Spyware select strict
• For URL Filtering select default
• For File Blocking select basic file blocking
• For WildFire Analysis select default
9. Verify that Log at Session End is enabled. Only traffic that matches a security rule will be
logged.
10. Click OK.
STEP 5 | Save your policy rules to the running configuraon on the firewall.
Click Commit.
Geng Started
STEP 6 | To verify that you have set up your basic policies effecvely, test whether your Security
policy rules are being evaluated and determine which Security policy rule applies to a traffic
flow.
For example, to verify the policy rule that will be applied for a client in the user zone with the
IP address 10.35.14.150 when it sends a DNS query to the DNS server in the data center:
1. Select Device > Troubleshoong and select Security Policy Match (Select Test).
2. Enter the Source and Desnaon IP addresses.
3. Enter the Protocol.
4. Select dns (Applicaon)
5. Execute the Security policy match test.
Geng Started
Assess Network Traffic

Now that you have a basic security policy, you can review the stascs and data in the Applicaon
Command Center (ACC), traffic logs, and the threat logs to observe trends on your network. Use
this informaon to idenfy where you need to create more granular security policy rules.
Use the Applicaon Command Center and Use the Automated Correlaon Engine.
In the ACC, review the most used applicaons and the high-risk applicaons on your network.
The ACC graphically summarizes the log informaon to highlight the applicaons traversing the
network, who is using them (with User-ID enabled), and the potenal security impact of the
content to help you idenfy what is happening on the network in real me. You can then use
this informaon to create appropriate security policy rules that block unwanted applicaons,
while allowing and enabling applicaons in a secure manner.
The Compromised Hosts widget in ACC > Threat Acvity displays potenally compromised
hosts on your network and the logs and match evidence that corroborates the events.
Determine what updates/modificaons are required for your network security policy rules and
implement the changes.
For example:
• Evaluate whether to allow web content based on schedule, users, or groups.
• Allow or control certain applicaons or funcons within an applicaon.
• Decrypt and inspect content.
• Allow but scan for threats and exploits.
For informaon on refining your security policies and for aaching custom security profiles, see
how to Create a Security Policy Rule and Security Profiles.
View Logs.
Specifically, view the traffic and threat logs (Monitor > Logs).
Traffic logs are dependent on how your security policies are defined and set up to log
traffic. The Applicaon Usage widget in the ACC, however, records applicaons and
stascs regardless of policy configuraon; it shows all traffic that is allowed on your
network, therefore it includes the inter-zone traffic that is allowed by policy and the
same zone traffic that is allowed implicitly.
Configure Log Storage Quotas and Expiraon Periods.

Review the AutoFocus intelligence summary for arfacts in your logs. An arfact is an item,
property, acvity, or behavior associated with logged events on the firewall. The intelligence
summary reveals the number of sessions and samples in which WildFire detected the arfact.
Geng Started
Use WildFire verdict informaon (benign, grayware, malware) and AutoFocus matching tags to
look for potenal risks in your network.
AutoFocus tags created by Unit 42, the Palo Alto Networks threat intelligence team,
call aenon to advanced, targeted campaigns and threats in your network.
From the AutoFocus intelligence summary, you can start an AutoFocus search for arfacts and
assess their pervasiveness within global, industry, and network contexts.
Monitor Web Acvity of Network Users.

Review the URL filtering logs to scan through alerts, denied categories/URLs. URL logs are
generated when a traffic matches a security rule that has a URL filtering profile aached with
an acon of alert, connue, override or block.
Geng Started
Enable Free WildFire Forwarding

WildFire is a cloud-based virtual environment that analyzes and executes unknown samples
(files and email links) and determines the samples to be malicious, phishing, grayware, or benign.
With WildFire enabled, a Palo Alto Networks firewall can forward unknown samples to WildFire
for analysis. For newly-discovered malware, WildFire generates a signature to detect the
malware, which is made available for retrieval in real-me for all firewalls with an acve WildFire
subscripon. This enables all Palo Alto next-generaon firewalls worldwide to detect and prevent
malware found by a single firewall. Malware signatures oen match mulple variants of the same
malware family, and as such, block new malware variants that the firewall has never seen before.
The Palo Alto Networks threat research team uses the threat intelligence gathered from malware
variants to block malicious IP addresses, domains, and URLs.
A basic WildFire service is included as part of the Palo Alto Networks next-generaon firewall
and does not require a WildFire subscripon. With the basic WildFire service, you can enable
the firewall to forward portable executable (PE) files. Addionally, if you do not have a WildFire
subscripon, but you do have a Threat Prevenon subscripon, you can receive signatures for
malware WildFire idenfies every 24- 48 hours (as part of the Anvirus updates).
Beyond the basic WildFire service, a WildFire subscripon is required for the firewall to:
• Get the latest WildFire signatures in real-me.
• Prevent malicious portable executables, PowerShell scripts, and ELF files from entering your
network in real-me using WildFire Inline ML.
• Forward advanced file types and email links for analysis.
• Use the WildFire API.
• Use a WildFire appliance to host a WildFire private cloud or a WildFire hybrid cloud.
If you have a WildFire subscripon, go ahead and get started with WildFire to get the most out of
your subscripon. Otherwise, take the following steps to enable basic WildFire forwarding:
STEP 1 | Confirm that your firewall is registered and that you have a valid support account as well as
any subscripons you require.
1. Log in to the Palo Alto Networks Customer Support Portal(CSP) and on the le-hand side
navigaon pane, select Assets > Devices.
2. Verify that the firewall is listed. If it is not listed, select Register New Device and
connue to Register the Firewall.
3. (Oponal) If you have a Threat Prevenon subscripon, be sure to Acvate Subscripon
Licenses.
Geng Started
STEP 2 | Log in to the firewall and configure WildFire forwarding sengs.

1. Select Device > Setup > WildFire and edit the General Sengs.
2. Set the WildFire Public Cloud field to forward files to the WildFire global cloud (U.S.) at:
wildfire.paloaltonetworks.com.
You can also forward files to a WildFire regional cloud or a private cloud based
on your locaon and your organizaonal requirements.
3. Review the File Size Limits for PEs the firewall forwards for WildFire analysis. set the
Size Limit for PEs that the firewall can forward to the maximum available limit of 10 MB.
As a WildFire best pracce, set the Size Limit for PEs to the maximum available
limit of 10 MB.
4. Click OK to save your changes.
STEP 3 | Enable the firewall to forward PEs for analysis.

1. Select Objects > Security Profiles > WildFire Analysis and Add a new profile rule.
2. Name the new profile rule.
3. Add a forwarding rule and enter a Name for it.
4. In the File Types column, add pe files to the forwarding rule.
5. In the Analysis column, select public-cloud to forward PEs to the WildFire public cloud.
6. Click OK.
STEP 4 | Apply the new WildFire Analysis profile to traffic that the firewall allows.
1. Select Policies > Security and either select an exisng policy rule or create a new policy
rule as described in Set Up a Basic Security Policy.
2. Select Acons and in the Profile Sengs secon, set the Profile Type to Profiles.
3. Select the WildFire Analysis profile you just created to apply that profile rule to all traffic
this policy rule allows.
4. Click OK.
STEP 5 | Enable the firewall to forward decrypted SSL traffic for WildFire analysis.
STEP 6 | Review and implement WildFire best pracces to ensure that you are geng the most of
WildFire detecon and prevenon capabilies.
STEP 7 | Commit your configuraon updates.
STEP 8 | Verify that the firewall is forwarding PE files to the WildFire public cloud.
Select Monitor > Logs > WildFire Submissions to view log entries for PEs the firewall
successfully submied for WildFire analysis. The Verdict column displays whether WildFire
found the PE to be malicious, grayware, or benign. (WildFire only assigns the phishing verdict
to email links). The Acon column indicates whether the firewall allowed or blocked the
sample. The Severity column indicates how much of a threat a sample poses to an organizaon
using the following values: crical, high, medium, low, informaon.
Geng Started
STEP 9 | (Threat Prevenon subscripon only) If you have a Threat Prevenon subscripon, but do
not have a WildFire subscripon, you can sll receive WildFire signature updates every 24-
48 hours.
1. Select Device > Dynamic Updates.
2. Check that the firewall is scheduled to download, and install Anvirus updates.
Geng Started
Best Pracces for Compleng the Firewall Deployment

Now that you have integrated the firewall into your network and enabled the basic security
features, you can begin configuring more advanced features. Here are some things to consider
next:
Follow the Adminstrave Access Best Pracces to make sure you are properly securing the
management interfaces.
Configure a best-pracce security policy rulebase to safely enable applicaons and protect
your network from aack. Go to the Best Pracces page and select security policy best
pracce for your firewall deployment.
Set up High Availability—High availability (HA) is a configuraon in which two firewalls are
placed in a group and their configuraon and session tables are synchronized to prevent a
single point to 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 a two-firewall cluster
provides redundancy and allows you to ensure business connuity.
Enable User Idenficaon (User-ID)—User-ID is a Palo Alto Networks next-generaon firewall
feature that allows you to create policies and perform reporng based on users and groups
rather than individual IP addresses.
Enable Decrypon—Palo Alto Networks firewalls provide the capability to decrypt and inspect
traffic for visibility, control, and granular security. Use decrypon on a firewall to prevent
malicious content from entering your network or sensive content from leaving your network
concealed as encrypted or tunneled traffic.
Follow the Best Pracces for Securing Your Network from Layer 4 and Layer 7 Evasions.
Share Threat Intelligence with Palo Alto Networks—Permit the firewall to periodically collect
and send informaon about applicaons, threats, and device health to Palo Alto Networks.
Telemetry includes opons to enable passive DNS monitoring and to allow experimental
test signatures to run in the background with no impact to your security policy rules, firewall
logs, or firewall performance. All Palo Alto Networks customers benefit from the intelligence
gathered from telemetry, which Palo Alto Networks uses to improve the threat prevenon
capabilies of the firewall.
Geng Started
Subscripons
Learn about all the subscripons and services that work with the firewall, and get
started by acvang subscripon licenses:
> Subscripons You Can Use With the Firewall

> Acvate Subscripon Licenses
> What Happens When Licenses Expire?
> Enhanced Applicaon Logs for Palo Alto Networks Cloud Services
Certain cloud services, like Cortex XDR™, do not integrate with the firewall directly, but rely on
data stored in Cortex Data Lake for visibility into network acvity. Enhanced applicaon logging
is a feature that comes with a Cortex Data Lake subscripon—it allows the firewall to collect data
specifically for Cortex XDR to use to detect anomalous network acvity. Turning on enhanced
applicaon logging is a Cortex XDR best pracce.
63
Subscripons
Subscripons You Can Use With the Firewall

The following Palo Alto Networks subscripons unlock certain firewall features or enable
the firewall to leverage a Palo Alto Networks cloud-delivered service (or both). Here you can
read more about each service or feature that requires a subscripon to work with the firewall.
To enable a subscripon, you must first Acvate Subscripon Licenses; once acve, most
subscripon services can use Dynamic Content Updates to provide new and updated funconality
to the firewall.
IoT Security The IoT Security soluon works with next-generaon firewalls
to dynamically discover and maintain a real-me inventory of
the IoT devices on your network. Through AI and machine-
learning algorithms, the IoT Security soluon achieves a high
level of accuracy, even classifying IoT device types encountered
for the first me. And because it’s dynamic, your IoT device
inventory is always up to date. IoT Security also provides the
automac generaon of policy recommendaons to control IoT
device traffic, as well as the automac creaon of IoT device
aributes for use in firewall policies.
• Get Started with IoT Security.
SD-WAN Provides intelligent and dynamic path selecon on top of

the industry-leading security that PAN-OS soware already
delivers. Managed by Panorama, the SD-WAN implementaon
includes:
• Centralized configuraon management
• Automac VPN topology creaon
• Traffic distribuon
• Monitoring and troubleshoong
• Get Started with SD-WAN
Threat Prevenon Threat Prevenon provides:

• Anvirus, an-spyware (command-and-control), and
vulnerability protecon.
• Built-in external dynamic lists that you can use to secure
your network against malicious hosts.
• Ability to idenfy infected hosts that try to connect to
malicious domains.
• Get Started with Threat Prevenon
DNS Security Provides enhanced DNS sinkholing capabilies by querying

DNS Security, an extensible cloud-based service capable of
Subscripons

generang DNS signatures using advanced predicve analycs
and machine learning. This service provides full access to
the connuously expanding DNS-based threat intelligence
produced by Palo Alto Networks.
To set up DNS Security, you must first purchase and install a
Threat Prevenon license.
• Get Started with DNS Security
URL Filtering Provides the ability to not only control web-access, but how
users interact with online content based on dynamic URL
categories. You can also prevent credenal the by controlling
the sites to which users can submit their corporate credenals.
To set up URL Filtering, you must purchase and install a
subscripon for the supported URL filtering database, PAN-
DB. With PAN-DB, you can set up access to the PAN-DB
public cloud or to the PAN-DB private cloud.
URL filtering is no longer available as a standalone

subscripon. All features contained in URL filtering
are included with the Advanced URL filtering
subscripon.
• Get Started with URL Filtering
Advanced URL Filtering Advanced URL Filtering uses a cloud-based ML-powered web
security engine to perform ML-based inspecon of web traffic
in real-me. This reduces reliance on URL databases and out-
of-band web crawling to detect and prevent advanced, file-
less web-based aacks including targeted phishing, web-
delivered malware and exploits, command-and-control, social
engineering, and other types of web aacks.
• Get Started with Advanced URL Filtering
WildFire Although basic WildFire® support is included as part of the

Threat Prevenon license, the WildFire subscripon service
provides enhanced services for organizaons that require
immediate coverage for threats, frequent WildFire signature
updates, advanced file type forwarding (APK, PDF, Microso
Office, and Java Applet), as well as the ability to upload files
using the WildFire API. A WildFire subscripon is also required
if your firewalls will be forwarding files to an on-premise
WF-500 appliance.
• Get Started with WildFire
AutoFocus Provides a graphical analysis of firewall traffic logs and

idenfies potenal risks to your network using threat
Subscripons

intelligence from the AutoFocus portal. With an acve license,
you can also open an AutoFocus search based on logs recorded
on the firewall.
• Get Started with AutoFocus
Cortex Data Lake Provides cloud-based, centralized log storage and aggregaon.
The Cortex Data Lake is required or highly-recommended
to support several other cloud-delivered services, including
Cortex XDR, IoT Security, and Prisma Access, and Traps
management service.
• Get Started with Cortex Data Lake
GlobalProtect Provides mobility soluons and/or large-scale VPN capabilies.

By default, you can deploy GlobalProtect portals and gateways
(without HIP checks) without a license. If you want to use
advanced GlobalProtect features (HIP checks and related
content updates, the GlobalProtect Mobile App, IPv6
connecons, or a GlobalProtect Clientless VPN) you will need a
GlobalProtect license (subscripon) for each gateway.
• Get Started with GlobalProtect
Virtual Systems This is a perpetual license, and is required to enable support

for mulple virtual systems on PA-3200 Series firewalls. In
addion, you must purchase a Virtual Systems license if you
want to increase the number of virtual systems beyond the
base number provided by default on PA-5200 Series, and
PA-7000 Series firewalls (the base number varies by plaorm).
The PA-800 Series, PA-220, and VM-Series firewalls do not
support virtual systems.
• Get Started with Virtual Systems
Enterprise Data Loss Provides cloud-based protecon against unauthorized access,

Prevenon (DLP) misuse, extracon, and sharing of sensive informaon.
Enterprise DLP provides a single engine for accurate detecon
and consistent policy enforcement for sensive data at rest
and in moon using machine learning-based data classificaon,
hundreds of data paerns using regular expressions or
keywords, and data profiles using Boolean logic to scan for
collecve types of data.
• Get Started with Enterprise Data loss Prevenon
SaaS Security Inline The SaaS Security soluon works with Cortex Data Lake to
discover all of the SaaS applicaons in use on your network.
SaaS Security Inline can discover thousands of Shadow IT
applicaons and their users and usage details. SaaS Security
Inline also enforces SaaS policy rule recommendaons
Subscripons

seamlessly across your exisng Palo Alto Networks firewalls.
App-ID Cloud Engine (ACE) also requires SaaS Security Inline.
• Get Started with Prisma SaaS
Subscripons
Acvate Subscripon Licenses

Follow these steps to acvate a new license on the firewall.
The Decrypon Mirroring feature requires you to acvate a free license to unlock feature
funconality. For those features, you should instead follow the steps to Acvate Free Licenses for
Decrypon Features.
STEP 1 | Locate the acvaon codes for the licenses you purchased.
When you purchased your subscripons you should have received an email from Palo Alto
Networks customer service lisng the acvaon code associated with each subscripon. If you
cannot locate this email, contact Customer Support to obtain your acvaon codes before you
proceed.
STEP 2 | Acvate your Support license.

You will not be able to update your PAN-OS soware if you do not have a valid Support
license.
1. Log in to the web interface and then select Device > Support.
2. Click Acvate support using authorizaon code.
3. Enter your Authorizaon Code and then click OK.
STEP 3 | Acvate each license you purchased.

Select Device > Licenses and then acvate your licenses and subscripons in one of the
following ways:
• Retrieve license keys from license server—Use this opon if you acvated your license on
the Customer Support portal.
• Acvate feature using authorizaon code—Use this opon to enable purchased
subscripons using an authorizaon code for licenses that have not been previously
acvated on the support portal. When prompted, enter the Authorizaon Code and then
click OK.
• Manually upload license key—Use this opon if your firewall does not have connecvity to
the Palo Alto Networks Customer Support Portal. In this case, you must download a license
key file from the support site on an internet-connected computer and then upload to the
firewall.
STEP 4 | Verify that the license is successfully acvated

On the Device > Licenses page, verify that the license is successfully acvated. For example,
aer acvang the WildFire license, you should see that the license is valid:
Subscripons
STEP 5 | (WildFire subscripons only) Perform a commit to complete WildFire subscripon acvaon.
Aer acvang a WildFire subscripon, a commit is required for the firewall to begin
forwarding advanced file types. You should either:
• Commit any pending changes.
• Check that the WildFire Analysis profile rules include the advanced file types that are now
supported with the WildFire subscripon. If no change to any of the rules is required, make
a minor edit to a rule descripon and perform a commit.
Subscripons
What Happens When Licenses Expire?

Palo Alto Networks subscripons provide the firewall with added funconality and/or access
to a Palo Alto Networks cloud-delivered service. When a license is within 30 days of expiraon,
a warning message displays in the system log daily unl the subscripon is renewed or expires.
Upon license expiraon, some subscripons connue to funcon in a limited capacity, and others
stop operang completely. Here you can find out what happens when each subscripon expires.
The precise moment of license expiry is at the beginning of the following day at 12:00 AM
(GMT). For example, if your license is scheduled to end on 1/20 you will have funconality
for the remainder of that day. At the start of the new day on 1/21 at 12:00 AM (GMT),
the license will expire. All license-related funcons operate on Greenwich Mean Time
(GMT), regardless of the configured me zone on the firewall.
Subscripon Expiry Behavior
Threat Prevenon Alerts appear in the System Log indicang that the license has
expired.
You can sll:
• Use signatures that were installed at the me the license
expired, unless you install a new Applicaons-only content
update either manually or as part of an automac schedule.
If you do, the update will delete your exisng threat
signatures and you will no longer receive protecon against
them.
• Use and modify Custom App-ID™ and threat signatures.
You can no longer:
• Install new signatures.
• Roll signatures back to previous versions.
DNS Security You can sll:

• Use local DNS signatures if you have an acve Threat
Prevenon license.
You can no longer:
• Get new DNS signatures.
Advanced URL Filtering / URL You can sll:

Filtering
• Enforce policy using custom URL categories.
• Enforce policy using PAN-DB categories that were in your
local cache when the license expired.
You can no longer:
• Get updates to cached PAN-DB categories.
Subscripons

• Connect to the PAN-DB URL filtering database.
• Get PAN-DB categories of uncached URLs.
• Analyze URL requests in real-me using advanced URL
filtering.
WildFire You can sll:

• Forward PEs for analysis.
• Get signature updates every 24-48 hours if you have an
acve Threat Prevenon subscripon.
You can no longer:
• Get five-minute updates through the WildFire public and
private clouds.
• Forward advanced file types such as APKs, Flash files,
PDFs, Microso Office files, Java Applets, Java files (.jar
and .class), and HTTP/HTTPS email links contained in SMTP
and POP3 email messages.
• Use the WildFire API.
• Use the WildFire appliance to host a WildFire private cloud
or a WildFire hybrid cloud.
AutoFocus You can sll:

• Use an external dynamic list with AutoFocus data for a
grace period of three months.
You can no longer:
• Access the AutoFocus portal.
• View the AutoFocus Intelligence Summary for Monitor log
or ACC arfacts.
Cortex Data Lake You can sll:

• Store log data for a 30-day grace period, aer which it is
deleted.
• Forward logs to Cortex Data Lake unl the end of the 30-
day grace period.
GlobalProtect You can sll:

• Use the app for endpoints running Windows and macOS.
• Configure single or mulple internal/external gateways.
You can no longer:
• Access the Linux OS app and mobile app for iOS, Android,
Chrome OS, and Windows 10 UWP.
Subscripons

• Use IPv6 for external gateways.
• Run HIP checks.
• Use Clientless VPN.
• Enforce split tunneling based on desnaon domain, client
process, and video streaming applicaon.
VM-Series You can sll:

• Configure and use the firewall(s) you had deployed when
the license expired.
Support You can no longer:

• Receive soware updates.
• Download VM images.
• Benefit from technical support.
Subscripons
Enhanced Applicaon Logs for Palo Alto Networks Cloud

Services
The firewall can collect data that increases visibility into network acvity for Palo Alto Networks
apps and services, like Cortex XDR. These enhanced applicaon logs are designed strictly for Palo
Alto Networks apps and services to consume and process; you cannot view enhanced applicaon
logs on the firewall or Panorama. Only firewalls sending logs to Cortex Data Lake can generate
enhanced applicaon logs.
Examples of the types of data that enhanced applicaon logs gather includes records of DNS
queries, the HTTP header User Agent field that specifies the web browser or tool used to access
a URL, and informaon about DHCP automac IP address assignment. With DHCP informaon,
for example, Cortex XDR™ can alert on unusual acvity based on hostname instead of IP address.
This allows the security analyst using Cortex XDR to meaningfully assess whether the user’s
acvity is within the scope of his or her role, and if not, to more quickly take acon to stop the
acvity.
To benefit from the most comprehensive set of enhanced applicaon logs, you should enable
User-ID; deployments for the Windows-based User-ID agent and the PAN-OS integrated User-
ID agent both collect some data that is not reflected in the firewall User-ID logs but that is useful
towards associang network acvity with specific users.
To start forwarding enhanced applicaon logs to Cortex Data Lake, turn on enhanced applicaon
logging globally, and then enable it on a per-security rule basis (using a Log Forwarding profile).
The global seng is required and captures data for traffic that is not session-based (ARP requests,
for example). The per-security policy rule seng is strongly recommended; the majority of
enhanced applicaon logs are gathered from the session-based traffic that your security policy
rules enforce.
STEP 1 | Enhanced applicaon logging requires a Cortex Data Lake subscripon and User-ID is also
recommended. Here are steps to get started with Cortex Data Lake and enable User-ID.
Subscripons
STEP 2 | To Enable Enhanced Applicaon Logging on the firewall, select Device > Setup >
Management > Cortex Data Lake and edit Cortex Data Lake Sengs.
Subscripons
STEP 3 | Connue to enable enhanced applicaon logging for the security policy rules that control the
traffic into which you want extended visibility.
1. Select Objects > Log Forwarding and Add or modify a log forwarding profile.
2. Update the profile to Enable enhanced applicaon logging to Cortex Data Lake
(including traffic and url logs).
Noce that when you enable enhanced applicaon logging in a Log Forwarding profile,
match lists that specify the log types required for enhanced applicaon logging are
automacally added to the profile.
3. Click OK to save the profile and connue to update as many profiles as needed.
4. Ensure that the Log Forwarding profile that you’ve updated is aached to a security
policy rule, to trigger log generaon and forwarding for the traffic matched to the rule.
1. Select Policies > Security to view the profiles aached to each security policy rule.
2. To update the log forwarding profile aached to a rule, Add or edit a rule and select
Policies > Security > Acons > Log Forwarding and select the Log Forwarding profile
enabled with enhanced applicaon logging.
Subscripons
Firewall Administraon
Administrators can configure, manage, and monitor Palo Alto Networks firewalls using
the web interface, CLI, and API management interface. You can customize role-based
administrave access to the management interfaces to delegate specific tasks or
permissions to certain administrators.
See Administrave Access Best Pracces for how to safeguard your management
network and the firewall and Panorama management interfaces.
> Management Interfaces

> Use the Web Interface
> Manage Configuraon Backups
> Manage Firewall Administrators
> Reference: Web Interface Administrator Access
> Reference: Port Number Usage
> Reset the Firewall to Factory Default Sengs
> Bootstrap the Firewall
77
Firewall Administraon
Management Interfaces
You can use the following user interfaces to manage the Palo Alto Networks firewall:
Do not enable management access from the internet or from other untrusted zones inside
your enterprise security boundary. Follow the Adminstrave Access Best Pracces to
ensure that you are properly securing your firewall.
• Use the Web Interface to perform configuraon and monitoring tasks with relave ease. This
graphical interface allows you to access the firewall using HTTPS (recommended) or HTTP and
it is the best way to perform administrave tasks.
• Use the Command Line Interface (CLI) to perform a series of tasks by entering commands in
rapid succession over SSH (recommended), Telnet, or the console port. The CLI is a no-frills
interface that supports two command modes, operaonal and configure, each with a disnct
hierarchy of commands and statements. When you become familiar with the nesng structure
and syntax of the commands, the CLI provides quick response mes and administrave
efficiency.
• Use the XML API to streamline your operaons and integrate with exisng, internally
developed applicaons and repositories. The XML API is a web service implemented using
HTTP/HTTPS requests and responses.
• Use Panorama to perform web-based management, reporng, and log collecon for mulple
firewalls. The Panorama web interface resembles the firewall web interface but with addional
funcons for centralized management.
Use the Web Interface

The following topics describe how to use the firewall web interface. For detailed informaon
about specific tabs and fields in the web interface, refer to the Web Interface Reference Guide.
• Launch the Web Interface
• Configure Banners, Message of the Day, and Logos
• Use the Administrator Login Acvity Indicators to Detect Account Misuse
• Manage and Monitor Administrave Tasks
• Commit, Validate, and Preview Firewall Configuraon Changes
• Export Configuraon Table Data
• Use Global Find to Search the Firewall or Panorama Management Server
• Manage Locks for Restricng Configuraon Changes
Launch the Web Interface

The following web browsers are supported for access to the web interface:
• Internet Explorer 11+
• Firefox 3.6+
• Safari 5+
• Chrome 11+
Perform the following tasks to launch the web interface.
STEP 1 | Launch an Internet browser and enter the IP address of the firewall in the URL field (hps://
<IP address>).
By default, the management (MGT) interface allows only HTTPS access to the web
interface. To enable other protocols, select Device > Setup > Interfaces and edit the
Management interface.
STEP 2 | Log in to the firewall according to the type of authencaon used for your account. If logging
in to the firewall for the first me, use the default value admin for your username and
password.
• SAML—Click Use Single Sign-On (SSO). If the firewall performs authorizaon (role
assignment) for administrators, enter your Username and Connue. If the SAML identy
provider (IdP) performs authorizaon, Connue without entering a Username. In both cases,
the firewall redirects you to the IdP, which prompts you to enter a username and password.
Aer you authencate to the IdP, the firewall web interface displays.
• Any other type of authencaon—Enter your user Name and Password. Read the login
banner and select I Accept and Acknowledge the Statement Below if the login page has the
banner and check box. Then click Login.
STEP 3 | Read and Close the messages of the day.
Configure Banners, Message of the Day, and Logos

A login banner is oponal text that you can add to the login page so that administrators will see
informaon they must know before they log in. For example, you could add a message to nofy
users of restricons on unauthorized use of the firewall.
You can add colored bands that highlight overlaid text across the top (header banner) and boom
(footer banner) of the web interface to ensure administrators see crical informaon, such as the
classificaon level for firewall administraon.
A message of the day dialog automacally displays aer you log in. The dialog displays messages
that Palo Alto Networks embeds to highlight important informaon associated with a soware or
content release. You can also add one custom message to ensure administrators see informaon,
such as an impending system restart, that might affect their tasks.
You can replace the default logos that appear on the login page and in the header of the web
interface with the logos of your organizaon.
STEP 1 | Configure the login banner.
2. Enter the Login Banner (up to 3,200 characters).
3. (Oponal) Select Force Admins to Acknowledge Login Banner to force administrators to
select an I Accept and Acknowledge the Statement Below check box above the banner
text to acvate the Login buon.
4. Click OK.
STEP 2 | Set the message of the day.

1. Select Device > Setup > Management and edit the Banners and Messages sengs.
2. Enable the Message of the Day.
3. Enter the Message of the Day (up to 3,200 characters).
Aer you enter the message and click OK, administrators who subsequently
log in, and acve administrators who refresh their browsers, see the new or
updated message immediately; a commit isn’t necessary. This enables you to
inform other administrators of an impending commit that might affect their
configuraon changes. Based on the commit me that your message specifies,
the administrators can then decide whether to complete, save, or undo their
changes.
4. (Oponal) Select Allow Do Not Display Again (default is disabled) to give administrators
the opon to suppress a message of the day aer the first login session. Each
administrator can suppress messages only for his or her own login sessions. In the
message of the day dialog, each message will have its own suppression opon.
5. (Oponal) Enter a header Title for the message of the day dialog (default is Messageof
the Day).
STEP 3 | Configure the header and footer banners.
A bright background color and contrasng text color can increase the likelihood that
administrators will noce and read a banner. You can also use colors that correspond to
classificaon levels in your organizaon.
1. Enter the Header Banner (up to 3,200 characters).

2. (Oponal) Clear Same Banner Header and Footer (enabled by default) to use different
header and footer banners.
3. Enter the Footer Banner (up to 3,200 characters) if the header and footer banners differ.
4. Click OK.
STEP 4 | Replace the logos on the login page and in the header.
The maximum size for any logo image is 128KB. The supported file types are png and
jpg. The firewall does not support image files that are interlaced, images that contain
alpha channels, and gif file types because such files interfere with PDF generaon.
1. Select Device > Setup > Operaons and click Custom Logos in the Miscellaneous
secon.
2. Perform the following steps for both the Login Screen logo and the Main UI (header)
logo:
1. Click upload .
2. Select a logo image and click Open.
You can preview the image to see how PAN-OS will crop it to fit by clicking
the magnifying glass icon.
3. Click Close.
STEP 5 | Verify that the banners, message of the day, and logos display as expected.
1. Log out to return to the login page, which displays the new logos you selected.
2. Enter your login credenals, review the banner, select I Accept and Acknowledge the
Statement Below to enable the Login buon, and then Login.
A dialog displays the message of the day. Messages that Palo Alto Networks embedded
display on separate pages in the same dialog. To navigate the pages, click the right or le
arrows along the sides of the dialog or click a page selector at the boom of
the dialog.
3. (Oponal) You can select Do not show again for the message you configured and for any
messages that Palo Alto Networks embedded.
4. Close the message of the day dialog to access the web interface.
Header and footer banners display in every web interface page with the text and colors
that you configured. The new logo you selected for the web interface displays below the
header banner.
Use the Administrator Login Acvity Indicators to Detect Account

Misuse
The last login me and failed login aempts indicators provide a visual way to detect misuse of
your administrator account on a Palo Alto Networks firewall or Panorama management server. Use
the last login informaon to determine if someone else logged in using your credenals and use
the failed login aempts indicator to determine if your account is being targeted in a brute-force
aack.
STEP 1 | View the login acvity indicators to monitor recent acvity on your account.
1. Log in to the web interface on your firewall or Panorama management server.
2. View the last login details located at the boom le of the window and verify that the
mestamp corresponds to your last login.
3. Look for a cauon symbol to the right of the last login me informaon for failed login
aempts.
The failed login indicator appears if one or more failed login aempts occurred using
your account since the last successful login.
1. If you see the cauon symbol, hover over it to display the number of failed login
aempts.
2. Click the cauon symbol to view the failed login aempts summary. Details include
the admin account name, the reason for the login failure, the source IP address, and
the date and me.
Aer you successfully log in and then log out, the failed login counter resets
to zero so you will see new failed login details, if any, the next me you log in.
STEP 2 | Locate hosts that are connually aempng to log in to your firewall or Panorama
management server.
1. Click the failed login cauon symbol to view the failed login aempts summary.
2. Locate and record the source IP address of the host that aempted to log in. For
example, the following figure shows mulple failed login aempts.
3. Work with your network administrator to locate the user and host that is using the IP
address that you idenfied.
If you cannot locate the system that is performing the brute-force aack, consider
renaming the account to prevent future aacks.
STEP 3 | Take the following acons if you detect an account compromise.

1. Select Monitor > Logs > Configuraon and view the configuraon changes and commit
history to determine if your account was used to make changes without your knowledge.
2. Select Device > Config Audit to compare the current configuraon and the configuraon
that was running just prior to the configuraon you suspect was changed using your
credenals. You can also do this using Panorama.
If your administrator account was used to create a new account, performing

a configuraon audit helps you detect changes that are associated with any
unauthorized accounts, as well.
3. Revert the configuraon to a known good configuraon if you see that logs were deleted
or if you have difficulty determining if improper changes were made using your account.
Before you commit to a previous configuraon, review it to ensure that it

contains the correct sengs. For example, the configuraon that you revert to
may not contain recent changes, so apply those changes aer you commit the
backup configuraon.
Use the following best pracces to help prevent brute-force aacks on privileged
accounts.
• Limit the number of failed aempts allowed before the firewall locks a
privileged account by seng the number of Failed Aempts and the Lockout
Time (min) in the authencaon profile or in the Authencaon Sengs for
the Management interface (Device > Setup > Management > Authencaon
Sengs).
• Use Interface Management Profiles to Restrict Access.
• Enforce complex passwords for privileged accounts.
Manage and Monitor Administrave Tasks

The Task Manager displays details about all the operaons that you and other administrators
iniated (such as manual commits) or that the firewall iniated (such as scheduled report
generaon) since the last firewall reboot. You can use the Task Manager to troubleshoot failed
operaons, invesgate warnings associated with completed commits, view details about queued
commits, or cancel pending commits.
You can also view System Logs to monitor system events on the firewall or view Config
Logs to monitor firewall configuraon changes.
STEP 1 | Click Tasks at the boom of the web interface.
STEP 2 | Show only Running tasks (in progress) or All tasks (default). Oponally, filter the tasks by
type:
• Jobs—Administrator-iniated commits, firewall-iniated commits, and soware or content
downloads and installaons.
• Reports—Scheduled reports.
• Log Requests—Log queries that you trigger by accessing the Dashboard or a Monitor page.
STEP 3 | Perform any of the following acons:

• Display or hide task details—By default, the Task Manager displays the Type, Status, Start
Time, and Messages for each task. To see the End Time and Job ID for a task, you must
manually configure the display to expose those columns. To display or hide a column, open
the drop-down in any column header, select Columns, and select or deselect the column
names as needed.
• Invesgate warnings or failures—Read the entries in the Messages column for task details.
If the column says Too many messages, click the corresponding entry in the Type column
to see more informaon.
• Display a commit descripon—If an administrator entered a descripon when configuring
a commit, you can click Commit Descripon in the Messages column to display the
descripon.
• Check the posion of a commit in the queue—The Messages column indicates the queue
posion of commits that are in progress.
• Cancel pending commits—Click Clear Commit Queue to cancel all pending commits
(available only to predefined administrave roles). To cancel an individual commit, click x
in the Acon column for that commit (the commit remains in the queue unl the firewall
dequeues it). You cannot cancel commits that are in progress.
Commit, Validate, and Preview Firewall Configuraon Changes

A commit is the process of acvang pending changes to the firewall configuraon. You can filter
pending changes by administrator or locaon and then preview, validate, or commit only those
changes. The locaons can be specific virtual systems, shared policies and objects, or shared
device and network sengs.
The firewall queues commit requests so that you can iniate a new commit while a previous
commit is in progress. The firewall performs the commits in the order they are iniated but
priorizes auto-commits that are iniated by the firewall (such as FQDN refreshes). However, if
the queue already has the maximum number of administrator-iniated commits, you must wait for
the firewall to finish processing a pending commit before iniang a new one. To cancel pending
commits or view details about commits of any status, see Manage and Monitor Administrave
Tasks.
When you iniate a commit, the firewall checks the validity of the changes before acvang
them. The validaon output displays condions that either block the commit (errors) or that are
important to know (warnings). For example, validaon could indicate an invalid route desnaon
that you need to fix for the commit to succeed. The validaon process enables you to find and fix
errors before you commit (it makes no changes to the running configuraon). This is useful if you
have a fixed commit window and want to be sure the commit will succeed without errors.
When enabled and managed by a Panorama™ management server, managed firewalls locally test
the configuraon commied locally or pushed from Panorama to verify that the new changes
do not break the connecon between Panorama and the managed firewall. If the commied
configuraon breaks the connecon between Panorama and a managed firewall, then the
firewall automacally fails the commit and the configuraon is reverted to the previous running
configuraon. Addionally, firewalls managed by a Panorama management server test their
connecon to Panorama every 60 minutes and if a managed firewalls detects that it can no
longer successfully connect to Panorama, then it reverts its configuraon to the previous running
configuraon.
The commit, validate, preview, save, and revert operaons apply only to changes made
aer the last commit. To restore configuraons to the state they were in before the last
commit, you must load a previously backed up configuraon.
To prevent mulple administrators from making configuraon changes during concurrent
sessions, see Manage Locks for Restricng Configuraon Changes.
STEP 1 | Configure the scope of configuraon changes that you will commit, validate, or preview.
1. Click Commit at the top of the web interface.
2. Select one of the following opons:
• Commit All Changes (default)—Applies the commit to all changes for which you have
administrave privileges. You cannot manually filter the commit scope when you
select this opon. Instead, the administrator role assigned to the account you used to
log in determines the commit scope.
• Commit Changes Made By—Enables you to filter the commit scope by administrator
or locaon. The administrave role assigned to the account you used to log in
determines which changes you can filter.
To commit the changes of other administrators, the account you used to log in
must be assigned the Superuser role or an Admin Role profile with the Commit
For Other Admins privilege enabled.
3. (Oponal) To filter the commit scope by administrator, select Commit Changes Made By,
click the adjacent link, select the administrators, and click OK.
4. (Oponal) To filter by locaon, select Commit Changes Made By and clear any changes
that you want to exclude from the Commit Scope.
If dependencies between the configuraon changes you included and excluded

cause a validaon error, perform the commit with all the changes included. For
example, when you commit changes to a virtual system, you must include the
changes of all administrators who added, deleted, or reposioned rules for the
same rulebase in that virtual system.
STEP 2 | Preview the changes that the commit will acvate.

This can be useful if, for example, you don’t remember all your changes and you’re not sure you
want to acvate all of them.
The firewall compares the configuraons you selected in the Commit Scope to the running
configuraon. The preview window displays the configuraons side-by-side and uses color
coding to indicate which changes are addions (green), modificaons (yellow), or deleons
(red).
Preview Changes and select the Lines of Context, which is the number of lines from the
compared configuraon files to display before and aer each highlighted difference. These
addional lines help you correlate the preview output to sengs in the web interface. Close
the preview window when you finish reviewing the changes.
Because the preview results display in a new browser window, your browser must allow
pop-ups. If the preview window does not open, refer to your browser documentaon
for the steps to allow pop-ups.
STEP 3 | Preview the individual sengs for which you are comming changes.
This can be useful if you want to know details about the changes, such as the types of sengs
and who changed them.
1. Click Change Summary.
2. (Oponal) Group By a column name (such as the Type of seng).
3. Close the Change Summary dialog when you finish reviewing the changes.
STEP 4 | Validate the changes before you commit to ensure the commit will succeed.
1. Validate Changes.
The results display all the errors and warnings that an actual commit would display.
2. Resolve any errors that the validaon results idenfy.
STEP 5 | Commit your configuraon changes.

Commit your changes to validate and acvate them.
To view details about commits that are pending (which you can sll cancel), in progress,
completed, or failed, see Manage and Monitor Administrave Tasks.
Export Configuraon Table Data

Export policy rules, configuraon objects, and IPS signatures from Panorama™ and firewalls
to demonstrate regulatory compliance to external auditors, to conduct periodic reviews of the
firewall configuraon, and to generate reports on firewall policies. This prevents you from having
to give auditors direct access to your firewalls and appliances, to take screen shots or to access
the XML API to generate configuraon reports. From the web interface, you can export the
configuraon table data for policies, objects, network, firewall, and Panorama configuraons, as
well as Signature excepons in the Anvirus, An-Spyware, and Vulnerability Protecon Security
profiles, in either a PDF or CSV file.
Configuraon table export works like a print funcon—you cannot import generated files back
into Panorama or the firewall. When you export data as a PDF file and the table data exceeds
50,000 rows, the data is split in to mulple PDF files (for example, <report-name>_part1.pdf and
<report-name>_part2.pdf) When you export data as a CSV file, the data is exported as a single file.
These export formats allow you to apply filters that match your report criteria and search within
PDF reports to quickly find specific data. Addionally, when you export the configuraon table
data, a system log is generated to record the event.
STEP 1 | Launch the Web Interface and idenfy the configuraon data you need to export.
STEP 2 | Apply filters as needed to produce the configuraon data you need to export and click PDF/
CSV.
STEP 3 | Configure the Configuraon Table Export report:

1. Enter a File Name.
2. Select the File Type.
3. (Oponal) Enter a report Descripon.
4. Confirm the configuraon table data matches the filters you applied.
Select Show All Columns to show all filters applied.
STEP 4 | Export the configuraon table data.

Configuraon table export works like a print funcon—you cannot import generated files back
in to Panorama or the firewall.
STEP 5 | Select a locaon to save the exported file.
Use Global Find to Search the Firewall or Panorama Management

Server
Global Find enables you to search the candidate configuraon on a firewall or on Panorama
for a parcular string, such as an IP address, object name, policy rule name, threat ID, UUID, or
applicaon name. In addion to searching for configuraon objects and sengs, you can search
by job ID or job type for manual commits that administrators performed or auto-commits that the
firewall or Panorama performed. The search results are grouped by category and provide links to
the configuraon locaon in the web interface, so that you can easily find all of the places where
the string is referenced. The search results also help you idenfy other objects that depend on
or make reference to the search term or string. For example, when deprecang a security profile
enter the profile name in Global Find to locate all instances of the profile and then click each
instance to navigate to the configuraon page and make the necessary change. Aer all references
are removed, you can then delete the profile. You can do this for any configuraon item that has
dependencies.
Watch the video.
Global Find does not search dynamic content (such as logs, address ranges, or allocated
DHCP addresses). In the case of DHCP, you can search on a DHCP server aribute, such
as the DNS entry, but you cannot search for individual addresses allocated to users. Global
Find also does not search for individual user or group names idenfied by User-ID unless
the user/group is defined in a policy. In general, you can only search content that the
firewall writes to the configuraon.
Launch Global Find by clicking the Search icon located on the upper right of the web interface.
To access the Global Find from within a configuraon area, click the drop-down next to an item
and select Global Find:
For example, click Global Find on a zone named Users to search the candidate configuraon
for each locaon where the zone is referenced. The following screen capture shows the search
results for the zone Users:
Search ps:
• If you iniate a search on a firewall that has mulple virtual systems enabled or if custom
Administrave Role Types are defined, Global Find will only return results for areas of the
firewall in which the administrator has permissions. The same applies to Panorama device
groups.
• Spaces in search terms are handled as AND operaons. For example, if you search on
corp policy, the search results include instances where corp and policy exist in the
configuraon.
• To find an exact phrase, enclose the phrase in quotaon marks.
• Enter no more than five keywords or use an exact phrase match with quotaon marks.
• To rerun a previous search, click Search (located on the upper right of the web interface) to
see a list of the last 20 searches. Click an item in the list to rerun that search. Search history
is unique to each administrator account.
• To search for a UUID, you must copy and paste the UUID.
Manage Locks for Restricng Configuraon Changes

You can use configuraon locks to prevent other administrators from changing the candidate
configuraon or from comming configuraon changes unl you manually remove the lock or
the firewall automacally removes it (aer a commit). Locks ensure that administrators don’t
make conflicng changes to the same sengs or interdependent sengs during concurrent login
sessions.
The firewall queues commit requests and performs them in the order that administrators
iniate the commits. For details, see Commit, Validate, and Preview Firewall
Configuraon Changes. To view the status of queued commits, see Manage and Monitor
Administrave Tasks.
View details about current locks.

For example, you can check whether other administrators have set locks and read comments
they entered to explain the locks.
Click the lock at the top of the web interface. An adjacent number indicates the number of
current locks.
Lock a configuraon.
1. Click the lock at the top of the web interface.
The lock image varies based on whether exisng locks are or are not set.
2. Take a Lock and select the lock Type:

• Config—Blocks other administrators from changing the candidate configuraon.
• Commit—Blocks other administrators from comming changes made to the
candidate configuraon.
3. (Firewall with mulple virtual systems only) Select a Locaon to lock the configuraon
for a specific virtual system or the Shared locaon.
4. (Oponal) As a best pracce, enter a Comment so that other administrators will
understand the reason for the lock.
5. Click OK and Close.
Unlock a configuraon.
Only a superuser or the administrator who locked the configuraon can manually unlock it.
However, the firewall automacally removes a lock aer compleng the commit operaon.
1. Click the lock at the top of the web interface.
2. Select the lock entry in the list.
3. Click Remove Lock, OK, and Close.
Configure the firewall to automacally apply a commit lock when you change the candidate
configuraon. This seng applies to all administrators.
2. Select Automacally Acquire Commit Lock and then click OK and Commit.
Manage Configuraon Backups

The running configuraon on the firewall comprises all sengs you have commied and that
are therefore acve, such as policy rules that currently block or allow various types of traffic
in your network. The candidate configuraon is a copy of the running configuraon plus any
inacve changes that you made aer the last commit. Saving backup versions of the running or
candidate configuraon enables you to later restore those versions. For example, if a commit
validaon shows that the current candidate configuraon has more errors than you want to
fix, you can restore a previous candidate configuraon. You can also revert to the current
running configuraon without saving a backup first. If you need to export specific parts of the
configuraon for internal review or audit, you can Export Configuraon Table Data.
See Commit, Validate, and Preview Firewall Configuraon Changes for details about
commit operaons.
• Save and Export Firewall Configuraons

• Revert Firewall Configuraon Changes
Save and Export Firewall Configuraons

Saving a backup of the candidate configuraon to persistent storage on the firewall enables
you to later revert to that backup (see Revert Firewall Configuraon Changes). This is useful for
preserving changes that would otherwise be lost if a system event or administrator acon causes
the firewall to reboot. Aer reboong, PAN-OS automacally reverts to the current version of the
running configuraon, which the firewall stores in a file named running-config.xml. Saving backups
is also useful if you want to revert to a firewall configuraon that is earlier than the current
running configuraon. The firewall does not automacally save the candidate configuraon to
persistent storage. You must manually save the candidate configuraon as a default snapshot file
(.snapshot.xml) or as a custom-named snapshot file. The firewall stores the snapshot file locally but
you can export it to an external host.
You don’t have to save a configuraon backup to revert the changes made since the last
commit or reboot; just select Config > Revert Changes (see Revert Firewall Configuraon
Changes).
When you edit a seng and click OK, the firewall updates the candidate configuraon but
does not save a backup snapshot.
Addionally, saving changes does not acvate them. To acvate changes, perform a
commit (see Commit, Validate, and Preview Firewall Configuraon Changes).
Palo Alto Networks recommends that you back up any important configuraon to a host
external to the firewall.
STEP 1 | Save a local backup snapshot of the candidate configuraon if it contains changes that you
want to preserve in the event the firewall reboots.
These are changes you are not ready to commit—for example, changes you cannot finish in the
current login session.
To overwrite the default snapshot file (.snapshot.xml) with all the changes that all
administrators made, perform one of the following steps:
• Select Device > Setup > Operaons and Save candidate configuraon.
• Log in to the firewall with an administrave account that is assigned the Superuser role or
an Admin Role profile with the Save For Other Admins privilege enabled. Then select Config
> Save Changes at the top of the web interface, select Save All Changes and Save.
To create a snapshot that includes all the changes that all administrators made but without
overwring the default snapshot file:
1. Select Device > Setup > Operaons and Save named configuraon snapshot.
2. Specify the Name of a new or exisng configuraon file.
3. Click OK and Close.
To save only specific changes to the candidate configuraon without overwring any part of
the default snapshot file:
1. Log in to the firewall with an administrave account that has the role privileges required
to save the desired changes.
2. Select Config > Save Changes at the top of the web interface.
3. Select Save Changes Made By.
4. To filter the Save Scope by administrator, click <administrator-name>, select the
administrators, and click OK.
5. To filter the Save Scope by locaon, clear any locaons that you want to exclude. The
locaons can be specific virtual systems, shared policies and objects, or shared device
and network sengs.
6. Click Save, specify the Name of a new or exisng configuraon file, and click OK.
STEP 2 | Export a candidate configuraon, a running configuraon, or the firewall state informaon to
a host external to the firewall.
Select Device > Setup > Operaons and click an export opon:
• Export named configuraon snapshot—Export the current running configuraon, a named
candidate configuraon snapshot, or a previously imported configuraon (candidate or
running). The firewall exports the configuraon as an XML file with the Name you specify.
• Export configuraon version—Select a Version of the running configuraon to export as an
XML file. The firewall creates a version whenever you commit configuraon changes.
• Export device state—Export the firewall state informaon as a bundle. Besides the running
configuraon, the state informaon includes device group and template sengs pushed
from Panorama. If the firewall is a GlobalProtect portal, the informaon also includes
cerficate informaon, a list of satellites, and satellite authencaon informaon. If you
replace a firewall or portal, you can restore the exported informaon on the replacement by
imporng the state bundle.
Revert Firewall Configuraon Changes

Revert operaons replace sengs in the current candidate configuraon with sengs from
another configuraon. Reverng changes is useful when you want to undo changes to mulple
sengs as a single operaon instead of manually reconfiguring each seng.
You can revert pending changes that were made to the firewall configuraon since the last
commit. The firewall provides the opon to filter the pending changes by administrator or locaon.
The locaons can be specific virtual systems, shared policies and objects, or shared device and
network sengs. If you saved a snapshot file for a candidate configuraon that is earlier than the
current running configuraon (see Save and Export Firewall Configuraons), you can also revert
to that snapshot. Reverng to a snapshot enables you to restore a candidate configuraon that
existed before the last commit. The firewall automacally saves a new version of the running
configuraon whenever you commit changes, and you can restore any of those versions.
Revert to the current running configuraon (file named running-config.xml).

This operaon undoes changes you made to the candidate configuraon since the last commit.
To revert all the changes that all administrators made, perform one of the following steps:
• Select Device > Setup > Operaons, Revert to running configuraon, and click Yes to
confirm the operaon.
• Log in to the firewall with an administrave account that is assigned the Superuser role or
an Admin Role profile with the Commit For Other Admins privilege enabled. Then select
Config > Revert Changes at the top of the web interface, select Revert All Changes and
Revert.
To revert only specific changes to the candidate configuraon:
1. Log in to the firewall with an administrave account that has the role privileges required
to revert the desired changes.
The privileges that control commit operaons also control revert operaons.
2. Select Config > Revert Changes at the top of the web interface.
3. Select Revert Changes Made By.
4. To filter the Revert Scope by administrator, click <administrator-name>, select the
administrators, and click OK.
5. To filter the Revert Scope by locaon, clear any locaons that you want to exclude.
6. Revert the changes.
Revert to the default snapshot of the candidate configuraon.

This is the snapshot that you create or overwrite when you click Config > Save Changes at the
top of the web interface.
1. Select Device > Setup > Operaons and Revert to last saved configuraon.
2. Click Yes to confirm the operaon.
3. (Oponal) Click Commit to overwrite the running configuraon with the snapshot.
Revert to a previous version of the running configuraon that is stored on the firewall.
The firewall creates a version whenever you commit configuraon changes.
1. Select Device > Setup > Operaons and Load configuraon version.
2. Select a configuraon Version and click OK.
3. (Oponal) Click Commit to overwrite the running configuraon with the version you just
restored.
Revert to one of the following:

• Custom-named version of the running configuraon that you previously imported
• Custom-named candidate configuraon snapshot (instead of the default snapshot)
1. Select Device > Setup > Operaons and click Load named configuraon snapshot.
2. Select the snapshot Name and click OK.
3. (Oponal) Click Commit to overwrite the running configuraon with the snapshot.
Revert to a running or candidate configuraon that you previously exported to an external

host.
1. Select Device > Setup > Operaons, click Import named configuraon snapshot, Browse
to the configuraon file on the external host, and click OK.
2. Click Load named configuraon snapshot, select the Name of the configuraon file you
just imported, and click OK.
3. (Oponal) Click Commit to overwrite the running configuraon with the snapshot you
just imported.
Restore state informaon that you exported from a firewall.

Besides the running configuraon, the state informaon includes device group and template
sengs pushed from Panorama. If the firewall is a GlobalProtect portal, the informaon also
includes cerficate informaon, a list of satellites, and satellite authencaon informaon. If
you replace a firewall or portal, can you can restore the informaon on the replacement by
imporng the state bundle.
Import state informaon:
1. Select Device > Setup > Operaons, click Import device state, Browse to the state
bundle, and click OK.
2. (Oponal) Click Commit to apply the imported state informaon to the running
configuraon.
Manage Firewall Administrators

Administrave accounts specify roles and authencaon methods for the administrators of Palo
Alto Networks firewalls. Every Palo Alto Networks firewall has a predefined default administrave
account (admin) that provides full read-write access (also known as superuser access) to the
firewall.
As a best pracce, create a separate administrave account for each person who needs
access to the administrave or reporng funcons of the firewall. This enables you to
beer protect the firewall from unauthorized configuraon and enables logging of the
acons of individual administrators. Make sure you are following the Adminstrave
Access Best Pracces to ensure that you are securing administrave access to your
firewalls and other security devices in a way that prevents successful aacks.
• Administrave Role Types

• Configure an Admin Role Profile
• Administrave Authencaon
• Configure Administrave Accounts and Authencaon
• Configure Tracking of Administrator Acvity
Administrave Role Types

A role defines the type of access that an administrator has to the firewall. The Administrator Types
are:
• Role Based—Custom roles you can configure for more granular access control over the
funconal areas of the web interface, CLI, and XML API. For example, you can create an
Admin Role profile for your operaons staff that provides access to the firewall and network
configuraon areas of the web interface and a separate profile for your security administrators
that provides access to security policy definions, logs, and reports. On a firewall with mulple
virtual systems, you can select whether the role defines access for all virtual systems or specific
virtual systems. When new features are added to the product, you must update the roles
with corresponding access privileges: the firewall does not automacally add new features to
custom role definions. For details on the privileges you can configure for custom administrator
roles, see Reference: Web Interface Administrator Access.
• Dynamic—Built-in roles that provide access to the firewall. When new features are added, the
firewall automacally updates the definions of dynamic roles; you never need to manually
update them. The following table lists the access privileges associated with dynamic roles.
Dynamic Role Privileges
Superuser Full access to the firewall, including defining new

administrator accounts and virtual systems. You must have
Superuser privileges to create an administrave user with
Superuser privileges.
Dynamic Role Privileges
Superuser (read-only) Read-only access to the firewall.
Device administrator Full access to all firewall sengs except for defining new
accounts or virtual systems.
Device administrator (read- Read-only access to all firewall sengs except password
only) profiles (no access) and administrator accounts (only the
logged in account is visible).
Virtual system administrator Access to selected virtual systems on the firewall to create
and manage specific aspects of virtual systems. A virtual
system administrator doesn’t have access to network
interfaces, VLANs, virtual wires, virtual routers, IPSec
tunnels, GRE tunnels, DHCP, DNS Proxy, QoS, LLDP, or
network profiles.
Virtual system administrator Read-only access to selected virtual systems on the firewall
(read-only) and specific aspects of virtual systems. A virtual system
administrator with read-only access doesn’t have access to
network interfaces, VLANs, virtual wires, virtual routers,
IPSec tunnels, GRE tunnels, DHCP, DNS Proxy, QoS, LLDP, or
network profiles.
Configure an Admin Role Profile

Admin Role profiles enable you to define granular administrave access privileges to ensure
protecon for sensive company informaon and privacy for end users.
Follow the principle of least privilege access to create Admin Role profiles that enable
administrators to access only the areas of the management interface that they need to
access to perform their jobs and follow Administrave Access Best Pracces.
STEP 1 | Select Device > Admin Roles and click Add.
STEP 2 | Enter a Name to idenfy the role.
STEP 3 | For the scope of the Role, select Device or Virtual System.
STEP 4 | In the Web UI and REST API tabs, click the icon for each funconal area to toggle it to the
desired seng: Enable, Read Only or Disable. For the XML API tab select, Enable or Disable.
For details on the Web UI opons, see Web Interface Access Privileges.
STEP 5 | Select the Command Line tab and select a CLI access opon. The Role scope controls the
available opons:
• Device role:
• None—CLI access is not permied (default).
• superuser—Full access. Can define new administrator accounts and virtual systems. Only
a superuser can create administrator users with superuser privileges.
• superreader—Full read-only access.
• deviceadmin—Full access to all sengs except defining new accounts or virtual systems.
• devicereader—Read-only access to all sengs except password profiles (no access) and
administrator accounts (only the logged in account is visible).
• Virtual System role:
• None—Access is not permied (default).
• vsysadmin—Access to specific virtual systems to create and manage specific aspects
of virtual systems. Does not enable access to firewall-level or network-level funcons
including stac and dynamic roung, interface IP addresses, IPSec tunnels, VLANs, virtual
wires, virtual routers, GRE tunnels, DCHP, DNS Proxy, QoS, LLDP, or network profiles.
• vsysreader—Read-only access to specific virtual systems to specific aspects of virtual
systems. Does not enable access to firewall-level or network-level funcons including
stac and dynamic roung, interface IP addresses, IPSec tunnels, VLANs, virtual wires,
virtual routers, GRE tunnels, DCHP, DNS Proxy, QoS, LLDP, or network profiles.
STEP 6 | Click OK to save the profile.
STEP 7 | Assign the role to an administrator. See Configure a Firewall Administrator Account.
Example Admin Role Profile Construcon

This example shows an Admin Role profile for a Security Operaons Center (SOC) manager who
needs access to invesgate potenal issues. The SOC Manager needs read access to many areas
of the firewall, but generally doesn’t need write access. The example covers all four of the Admin
Role Profile’s tabs and each step describes why the profile enables or disables a parcular area of
access to the SOC manager.
This is an example profile for a ficonal SOC manager. Configure Admin Role profiles
for your administrators based on the funcons they manage and the access required
to do their job. Do not enable unnecessary access. Create separate profiles for each
administrave group that shares the same dues and for administrators who have unique
dues. Each administrator should have the exact level of access required to perform their
dues and no access beyond that.
STEP 1 | Configure Web UI access permissions. Each snip of the Web UI screen shows a different area
of Web UI permissions. Permissions are listed by firewall tab, in the order you see the tabs in
the Web UI, followed by permissions for other acons.
The Dashboard, ACC, and Monitor > Logs areas of the firewall don’t contain configuraon
elements—all of the objects are informaonal (you can only toggle them between enable and
disable because they are already read only). Because the SOC Manager needs to invesgate
potenal issues, the SOC Manager needs access to the informaon on these tabs.
The profile name and descripon make it easy to understand the profile’s objecve. This snip
doesn’t show all of the Logs permissions, but all of them are enabled for this profile.
The next snip shows permissions for more informaonal objects on the Monitor tab. The SOC
Manager uses these tools to invesgate potenal issues and therefore requires access.
The next two snips show permissions for PDF Reports, Custom Reports, and predefined
reports on the Monitor tab. While the SOC Manager needs access to PDF reports to gather
informaon, in this example, the SOC Manager does not need to configure reports, so access
is set to read-only (summary reports are not configurable). However, the SOC Manager needs
to manage custom reports to invesgate specific potenal issues, so full access permissions are
granted for all custom reports (including those not shown in the snip). Finally the SOC Manager
requires access to predefined reports for invesgang potenal issues.
Because the SOC Manager is an invesgator and not an administrator who configures the
firewall, permissions for the Policies tab are read-only, with the excepon of reseng the rule
hit count. Reseng the rule hit count is not one of the SOC Manager’s dues (and changing
the hit count could adversely affect or confuse other administrators), so access is disabled.
Read access enables the SOC Manager to invesgate the construcon of a policy that the SOC
Manager suspects may have caused an issue.
Permissions for the Objects tab are also read-only for the same reason—the SOC Manager’s
job doesn’t require configuraon, so no configuraon permissions are assigned. For areas
that aren’t included in the SOC Manager’s dues, access is disabled. In this example, the SOC
Manager has read-only access to invesgate objects configuraons for all objects except URL
Filtering, SD-WAN Link Management and Schedules, which are under the control of different
administrators in this example.
For Network tab permissions, the scenario is similar: the SOC Manager doesn’t need to
configure any of the objects, but may need informaon to invesgate issues, so read-only
access is assigned to the areas that the SOC Manager may need to invesgate. In this example,
access is disabled for QoS, LLDP, Network Profiles, or SD-WAN Interface profiles because
these items are not part of the SOC Manager’s dues.
In this example, the SOC Manager needs no access to the Device tab capabilies for
invesgave purposes, so all Device tab permissions are blocked. In addion, invesgaon
doesn’t require commit acons or access to any of the remaining acons, so those permissions
are also blocked.
STEP 2 | Configure XML API access permissions.

The following snip shows that all XML API permissions are disabled for the SOC Manager
because the SOC Manager doesn’t access the firewall using XML API commands.
STEP 3 | Configure Command Line (CLI) access permissions.

CLI access permissions are read-only for the SOC Manager because the SOC Manager
needs access to logs and other monitoring tools and also needs to be able to see certain
configuraons in order to invesgate potenal issues. However, the SOC Manager doesn’t
configure the firewall, so no configuraon permissions are assigned. The access level is set
to devicereader instead of to superreader because the SOC Manager doesn’t need access to
password profiles or to other administrave accounts.
STEP 4 | Configure REST API access permissions.

The SOC Manager doesn’t access the firewall using REST API commands, so all REST API
access is disabled.
Administrave Authencaon
You can configure the following types of authencaon and authorizaon (role and access domain
assignment) for firewall administrators:
AuthencaonAuthorizaon Descripon
Method Method
Local Local The administrave account credenals and authencaon

mechanisms are local to the firewall. You can define the accounts
with or without a user database that is local to the firewall—
see Local Authencaon for the advantages and disadvantages
of using a local database. You use the firewall to manage role
assignments but access domains are not supported. For details,
see Configure Local or External Authencaon for Firewall
Administrators.
SSH Keys Local The administrave accounts are local to the firewall, but
authencaon to the CLI is based on SSH keys. You use the
firewall to manage role assignments but access domains are
not supported. For details, see Configure SSH Key-Based
Administrator Authencaon to the CLI.
Cerficates Local The administrave accounts are local to the firewall, but
authencaon to the web interface is based on client cerficates.
You use the firewall to manage role assignments but access
domains are not supported. For details, see Configure Cerficate-
Based Administrator Authencaon to the Web Interface.
AuthencaonAuthorizaon Descripon
Method Method
External Local The administrave accounts you define locally on the firewall
service serve as references to the accounts defined on an external Mul-
Factor Authencaon, SAML, Kerberos, TACACS+, RADIUS, or
LDAP server. The external server performs authencaon. You
use the firewall to manage role assignments but access domains
are not supported. For details, see Configure Local or External
Authencaon for Firewall Administrators.
External External The administrave accounts are defined on an external SAML,

service service TACACS+, or RADIUS server. The server performs both
authencaon and authorizaon. For authorizaon, you define
Vendor-Specific Aributes (VSAs) on the TACACS+ or RADIUS
server, or SAML aributes on the SAML server. PAN-OS maps the
aributes to administrator roles, access domains, user groups, and
virtual systems that you define on the firewall. For details, see:
• Configure SAML Authencaon
• Configure TACACS+ Authencaon
• Configure RADIUS Authencaon
Configure Administrave Accounts and Authencaon

If you have already configured an authencaon profile (see Configure an Authencaon Profile
and Sequence) or you don’t require one to authencate administrators, you are ready to Configure
a Firewall Administrator Account. Otherwise, perform one of the other procedures listed below to
configure administrave accounts for specific types of authencaon.
• Configure a Firewall Administrator Account
• Configure Local or External Authencaon for Firewall Administrators
• Configure Cerficate-Based Administrator Authencaon to the Web Interface
• Configure SSH Key-Based Administrator Authencaon to the CLI
• Configure API Key Lifeme
Configure a Firewall Administrator Account

Administrave accounts specify roles and authencaon methods for firewall administrators.
The service that you use to assign roles and perform authencaon determines whether you add
the accounts on the firewall, on an external server, or both (see Administrave Authencaon).
If the authencaon method relies on a local firewall database or an external service, you must
configure an authencaon profile before adding an administrave account (see Configure
Administrave Accounts and Authencaon). If you already configured the authencaon profile
or you will use Local Authencaon without a firewall database, perform the following steps to
add an administrave account on the firewall.
Create a separate administrave account for each person who needs access to the
administrave or reporng funcons of the firewall. This enables you to beer protect the
firewall from unauthorized configuraon and enables logging of the acons of individual
administrators.
Make sure you are following the Adminstrave Access Best Pracces to ensure that you
are securing administrave access to your firewalls and other security devices in a way
that prevents successful aacks.
STEP 1 | Modify the number of supported administrator accounts.

Configure the total number of supported concurrent administrave accounts sessions for
a firewall in the normal operaonal mode or in FIPS-CC mode. You can allow up to four
concurrent administrave account sessions or configure the firewall to support an unlimited
number of concurrent administrave account sessions.
1. Select Device > Setup > Management and edit the Authencaon Sengs.
2. Edit the Max Session Count to specify the number of supported concurrent sessions
(range is 0 to 4) allowed for all administrator and user accounts.
Enter 0 to configure the firewall to support an unlimited number of administrave
accounts.
3. Edit the Max Session Time in minutes for an administrave account. Default is 720
minutes.
4. Click OK.
5. Commit.
You can also configure the total number of supported concurrent sessions by logging in
to the firewall CLI.
admin> configure
admin# set deviceconfig setting management admin-session

max-session-count <0-4>
admin# set deviceconfig setting management admin-session

max-session-time <0, 60-1499>
admin# commit
STEP 2 | Select Device > Administrators and Add an account.
STEP 3 | Enter a user Name.

If the firewall uses a local user database to authencate the account, enter the name that you
specified for the account in the database (see Add the user group to the local database.)
STEP 4 | Select an Authencaon Profile or sequence if you configured either for the administrator.
If the firewall uses Local Authencaon without a local user database for the account, select
None (default) and enter a Password.
STEP 5 | Select the Administrator Type.

If you configured a custom role for the user, select Role Based and select the Admin Role
Profile. Otherwise, select Dynamic (default) and select a dynamic role. If the dynamic role
is virtual system administrator, add one or more virtual systems that the virtual system
administrator is allowed to manage.
STEP 6 | (Oponal) Select a Password Profile for administrators that the firewall authencates locally
without a local user database. For details, see Define a Password Profile.
STEP 7 | Click OK and Commit.
Configure Local or External Authencaon for Firewall Administrators

You can use Local Authencaon and External Authencaon Services to authencate
administrators who access the firewall. These authencaon methods prompt administrators to
respond to one or more authencaon challenges, such as a login page for entering a username
and password.
If you use an external service to manage both authencaon and authorizaon (role and
access domain assignments), see:
• Configure SAML Authencaon
• Configure TACACS+ Authencaon
• Configure RADIUS Authencaon
To authencate administrators without a challenge-response mechanism, you can
Configure Cerficate-Based Administrator Authencaon to the Web Interface and
Configure SSH Key-Based Administrator Authencaon to the CLI.
STEP 1 | (External authencaon only) Enable the firewall to connect to an external server for
authencang administrators.
Configure a server profile:
• Add a RADIUS server profile.
If the firewall integrates with a Mul-Factor Authencaon (MFA) service through RADIUS,
you must add a RADIUS server profile. In this case, the MFA service provides all the
authencaon factors (challenges). If the firewall integrates with an MFA service through
a vendor API, you can sll use a RADIUS server profile for the first factor but MFA server
profiles are required for addional factors.
• Add an MFA server profile.
• Add a TACACS+ server profile.
• Add a SAML IdP server profile. You cannot combine Kerberos single sign-on (SSO) with
SAML SSO; you can use only one type of SSO service.
• Add a Kerberos server profile.
• Add an LDAP server profile.
STEP 2 | (Local database authencaon only) Configure a user database that is local to the firewall.
1. Add the user account to the local database.
2. (Oponal) Add the user group to the local database.
STEP 3 | (Local authencaon only) Define password complexity and expiraon sengs.
These sengs help protect the firewall against unauthorized access by making it harder for
aackers to guess passwords.
1. Define global password complexity and expiraon sengs for all local administrators.
The sengs don’t apply to local database accounts for which you specified a password
hash instead of a password (see Local Authencaon).
1. Select Device > Setup > Management and edit the Minimum Password Complexity
sengs.
2. Select Enabled.
3. Define the password sengs and click OK.
2. Define a Password Profile.
You assign the profile to administrator accounts for which you want to override the
global password expiraon sengs. The profiles are available only to accounts that are
not associated with a local database (see Local Authencaon).
1. Select Device > Password Profiles and Add a profile.
2. Enter a Name to idenfy the profile.
3. Define the password expiraon sengs and click OK.
STEP 4 | (Kerberos SSO only) Create a Kerberos keytab.

A keytab is a file that contains Kerberos account informaon for the firewall. To support
Kerberos SSO, your network must have a Kerberos infrastructure.
STEP 5 | Configure an authencaon profile.
If your administrave accounts are stored across mulple types of servers, you
can create an authencaon profile for each type and add all the profiles to an
authencaon sequence.
Configure an Authencaon Profile and Sequence. In the authencaon profile, specify the
Type of authencaon service and related sengs:
• External service—Select the Type of external service and select the Server Profile you
created for it.
• Local database authencaon—Set the Type to Local Database.
• Local authencaon without a database—Set the Type to None.
• Kerberos SSO—Specify the Kerberos Realm and Import the Kerberos Keytab.
STEP 6 | Assign the authencaon profile or sequence to an administrator account.

1. Configure a Firewall Administrator Account.
• Assign the Authencaon Profile or sequence that you configured.
• (Local database authencaon only) Specify the Name of the user account you added
to the local database.
3. (Oponal) Test Authencaon Server Connecvity to verify that the firewall can use the
authencaon profile to authencate administrators.
Configure Cerficate-Based Administrator Authencaon to the Web Interface

As a more secure alternave to password-based authencaon to the firewall web interface,
you can configure cerficate-based authencaon for administrator accounts that are local to
the firewall. Cerficate-based authencaon involves the exchange and verificaon of a digital
signature instead of a password.
Configuring cerficate-based authencaon for any administrator disables the username/

password logins for all administrators on the firewall; administrators thereaer require the
cerficate to log in.
STEP 1 | Generate a cerficate authority (CA) cerficate on the firewall.

You will use this CA cerficate to sign the client cerficate of each administrator.
Create a Self-Signed Root CA Cerficate.
Alternavely, Import a Cerficate and Private Key from your enterprise CA or a third-
party CA.
STEP 2 | Configure a cerficate profile for securing access to the web interface.
Configure a Cerficate Profile.
• Set the Username Field to Subject.
• In the CA Cerficates secon, Add the CA Cerficate you just created or imported.
STEP 3 | Configure the firewall to use the cerficate profile for authencang administrators.
2. Select the Cerficate Profile you created for authencang administrators and click OK.
STEP 4 | Configure the administrator accounts to use client cerficate authencaon.

For each administrator who will access the firewall web interface, Configure a Firewall
Administrator Account and select Use only client cerficate authencaon.
If you have already deployed client cerficates that your enterprise CA generated, skip to Step
8. Otherwise, go to Step 5.
STEP 5 | Generate a client cerficate for each administrator.

Generate a Cerficate. In the Signed By drop-down, select a self-signed root CA cerficate.
STEP 6 | Export the client cerficate.

1. Export a Cerficate and Private Key.
2. Commit your changes. The firewall restarts and terminates your login session. Thereaer,
administrators can access the web interface only from client systems that have the client
cerficate you generated.
STEP 7 | Import the client cerficate into the client system of each administrator who will access the
web interface.
Refer to your web browser documentaon.
STEP 8 | Verify that administrators can access the web interface.

1. Open the firewall IP address in a browser on the computer that has the client cerficate.
2. When prompted, select the cerficate you imported and click OK. The browser displays
a cerficate warning.
3. Add the cerficate to the browser excepon list.
4. Click Login. The web interface should appear without prompng you for a username or
password.
Configure SSH Key-Based Administrator Authencaon to the CLI

For administrators who use Secure Shell (SSH) to access the CLI of a Palo Alto Networks firewall,
SSH keys provide a more secure authencaon method than passwords. SSH keys almost
eliminate the risk of brute-force aacks, provide the opon for two-factor authencaon (key and
passphrase), and don’t send passwords over the network. SSH keys also enable automated scripts
to access the CLI.
STEP 1 | Use an SSH key generaon tool to create an asymmetric keypair on the client system of the
administrator.
The supported key formats are IETF SECSH and Open SSH. The supported algorithms are DSA
(1,024 bits) and RSA (768-4,096 bits).
For the commands to generate the keypair, refer to your SSH client documentaon.
The public key and private key are separate files. Save both to a locaon that the firewall can
access. For added security, enter a passphrase to encrypt the private key. The firewall prompts
the administrator for this passphrase during login.
STEP 2 | Configure the administrator account to use public key authencaon.

1. Configure a Firewall Administrator Account.
• Configure the authencaon method to use as a fallback if SSH key authencaon
fails. If you configured an Authencaon Profile for the administrator, select it in the
drop-down. If you select None, you must enter a Password and Confirm Password.
• Select Use Public Key Authencaon (SSH), then Import Key, Browse to the public
key you just generated, and click OK.
STEP 3 | Configure the SSH client to use the private key to authencate to the firewall.
Perform this task on the client system of the administrator. For the steps, refer to your SSH
client documentaon.
STEP 4 | Verify that the administrator can access the firewall CLI using SSH key authencaon.
1. Use a browser on the client system of the administrator to go to the firewall IP address.
2. Log in to the firewall CLI as the administrator. Aer entering a username, you will see the
following output (the key value is an example):
Authenticating with public key “dsa-key-20130415”
3. If prompted, enter the passphrase you defined when creang the keys.
Configure API Key Lifeme

The API keys on the firewall and Panorama enable you to authencate API calls to the XML API
and REST API. Because these keys grant access to the firewall and Panorama that are crical
elements of your security posture, as a best pracce, specify an API key lifeme to enforce regular
key rotaon. Aer you specify the key lifeme, when you regenerate an API key, each key is
unique.
In addion to seng a key lifeme that prompts you to regenerate new keys periodically, you can
also revoke all currently valid API keys in the event one or more keys are compromised. Revoking
keys is a way to expire all currently valid keys.
STEP 1 | Select Device > Setup > Management.
STEP 2 | Edit Authencaon Sengs to specify the API Key Lifeme (min).
Set the API key lifeme to protect against compromise and to reduce the effects of an
accidental exposure. By default, the API key lifeme is set to 0, which means that the keys
will never expire. To ensure that your keys are frequently rotated and each key is unique when
regenerated, you must specify a validity period that ranges between 1—525600 minutes. Refer
to the audit and compliance policies for your enterprise to determine how you should specify
the lifeme for which your API keys are valid.
STEP 3 | Commit the changes.
STEP 4 | (To revoke all API keys) Select Expire all API Keys to reset currently valid API keys.
If you have just set a key lifeme and want to reset all API keys to adhere to the new term, you
can expire all exisng keys.
On confirmaon, the keys are revoked and you can view the mestamp for when the API Keys
Last Expired.
Configure Tracking of Administrator Acvity

Track administrator acvity on the firewall web interface and CLI to achieve real me reporng
of acvity across your firewall. If you have reason to believe an administrator account is
compromised, you have a full history of where this administrator account navigated throughout
the web interface or what operaonal commands they executed so you can analyze in detail and
respond to all acons the compromised administrator took.
When an event occurs, an audit log is generated and forwarded to the specified syslog server each
me an administrator navigates through the web interface or when an operaonal command is
executed in the CLI. An audit log is generated for each navigaon or commend executed. Take for
example if you want to create a new address object. An audit log is generated when you click on
Objects, and a second audit log is generated when you then click on Addresses.
Audit logs are only visible as syslogs forwarded to your syslog server and cannot be viewed in the
firewall web interface. Audit logs can only be forwarded to a syslog server, cannot be forwarded to
Cortex Data Lake (CDL), and are not stored locally on the firewall.
STEP 1 | Configure a syslog server profile to forward audit logs of administrator acvity on the
firewall.
This step is required to successfully store audit logs for tracking administrator acvity on the
firewall.
1. Log in to the firewall web interface.
2. Configure a syslog server profile.
STEP 2 | Configure tracking of administrator acvity.

1. Select Device > Setup > Management and edit the Logging and Reporng Sengs.
2. Select Log Export and Reporng.
3. In the Log Admin Acvity secon, configure what administrator acvity to track.
• Operaonal Commands—Generate an audit log when an administrator executes an
operaonal or debug command in the CLI or an operaonal command triggered from
the web interface. See the CLI Operaonal Command Hierarchy for a full list of PAN-
OS operaonal and debug commands.
• UI Acons—Generate an audit log when an administrator navigates throughout
the web interface. This includes navigaon between configuraon tabs, as well as
individual objects within a tab.
For example, an audit log is generated when an administrator navigates from the
ACC to the Policies tab. Addionally, an audit log is generated when an administrator
navigates from Objects > Addresses to Objects > Tags.
• Syslog Server—Select a target syslog server profile to forward audit logs.
4. Click OK
5. Select Commit.
Reference: Web Interface Administrator Access

You can configure privileges for an enre firewall or for one or more virtual systems (on plaorms
that support mulple virtual systems). Within that Device or Virtual System designaon, you
can configure privileges for custom administrator roles, which are more granular than the fixed
privileges associated with a dynamic administrator role.
Configuring privileges at a granular level ensures that lower level administrators cannot access
certain informaon. You can create custom roles for firewall administrators (see Configure
a Firewall Administrator Account), Panorama administrators, or Device Group and Template
administrators (refer to the Panorama Administrator’s Guide). You apply the admin role to a
custom role-based administrator account where you can assign one or more virtual systems. The
following topics describe the privileges you can configure for custom administrator roles.
• Web Interface Access Privileges
• Panorama Web Interface Access Privileges
Web Interface Access Privileges

If you want to prevent a role-based administrator from accessing specific tabs on the web
interface, you can disable the tab and the administrator will not even see it when logging in using
the associated role-based administrave account. For example, you could create an Admin Role
Profile for your operaons staff that provides access to the Device and Network tabs only and a
separate profile for your security administrators that provides access to the Object, Policy, and
Monitor tabs.
An admin role can apply at the Device level or Virtual System level as defined by the Device
or Virtual System radio buon. If you select Virtual System, the admin assigned this profile is
restricted to the virtual system(s) he or she is assigned to. Furthermore, only the Device > Setup >
Services > Virtual Systems tab is available to that admin, not the Global tab.
The following topics describe how to set admin role privileges to the different parts of the web
interface:
• Define Access to the Web Interface Tabs
• Provide Granular Access to the Monitor Tab
• Provide Granular Access to the Policy Tab
• Provide Granular Access to the Objects Tab
• Provide Granular Access to the Network Tab
• Provide Granular Access to the Device Tab
• Define User Privacy Sengs in the Admin Role Profile
• Restrict Administrator Access to Commit and Validate Funcons
• Provide Granular Access to Global Sengs
• Provide Granular Access to the Panorama Tab
• Provide Granular Access to Operaons Sengs
Define Access to the Web Interface Tabs

The following table describes the top-level access privileges you can assign to an admin role
profile (Device > Admin Roles). You can enable, disable, or define read-only access privileges at
the top-level tabs in the web interface.
Access Level Descripon Enable Read Disable

Only
Dashboard Controls access to the Dashboard Yes No Yes

tab. If you disable this privilege, the
administrator will not see the tab and will
not have access to any of the Dashboard
widgets.
ACC Controls access to the Applicaon Yes No Yes

Command Center (ACC). If you disable
this privilege, the ACC tab will not display
in the web interface. Keep in mind that if
you want to protect the privacy of your
users while sll providing access to the
ACC, you can disable the Privacy > Show
Full IP Addresses opon and/or the Show
User Names In Logs And Reports opon.
Monitor Controls access to the Monitor tab. If you Yes No Yes

disable this privilege, the administrator
will not see the Monitor tab and will not
have access to any of the logs, packet
captures, session informaon, reports or
to App Scope. For more granular control
over what monitoring informaon the
administrator can see, leave the Monitor
opon enabled and then enable or disable
specific nodes on the tab as described in
Provide Granular Access to the Monitor
Tab.
Policies Controls access to the Policies tab. If you Yes No Yes

will not see the Policies tab and will not
have access to any policy informaon. For
more granular control over what policy
informaon the administrator can see,
for example to enable access to a specific
type of policy or to enable read-only
access to policy informaon, leave the
Policies opon enabled and then enable
or disable specific nodes on the tab as

Only
described in Provide Granular Access to
the Policy Tab.
Objects Controls access to the Objects tab. If you Yes No Yes

disable this privilege, the administrator will
not see the Objects tab and will not have
access to any objects, security profiles, log
forwarding profiles, decrypon profiles, or
schedules. For more granular control over
what objects the administrator can see,
leave the Objects opon enabled and then
enable or disable specific nodes on the tab
as described in Provide Granular Access to
the Objects Tab.
Network Controls access to the Network tab. If you Yes No Yes

will not see the Network tab and will
not have access to any interface, zone,
VLAN, virtual wire, virtual router, IPsec
tunnel, DHCP, DNS Proxy, GlobalProtect,
or QoS configuraon informaon
or to the network profiles. For more
granular control over what objects the
administrator can see, leave the Network
Provide Granular Access to the Network
Tab.
Device Controls access to the Device tab. If you Yes No Yes

will not see the Device tab and will
not have access to any firewall-wide
configuraon informaon, such as User-
ID, high availability, server profile or
cerficate configuraon informaon. For
more granular control over what objects
the administrator can see, leave the
Objects opon enabled and then enable
the Device Tab.

Only
You cannot enable access
to the Admin Roles or
Administrators nodes for a
role-based administrator even
if you enable full access to the
Device tab.
Provide Granular Access to the Monitor Tab

In some cases you might want to enable the administrator to view some but not all areas of the
Monitor tab. For example, you might want to restrict operaons administrators to the Config and
System logs only, because they do not contain sensive user data. Although this secon of the
administrator role definion specifies what areas of the Monitor tab the administrator can see,
you can also couple privileges in this secon with privacy privileges, such as disabling the ability
to see usernames in logs and reports. One thing to keep in mind, however, is that any system-
generated reports will sll show usernames and IP addresses even if you disable that funconality
in the role. For this reason, if you do not want the administrator to see any of the private user
informaon, disable access to the specific reports as detailed in the following table.
The following table lists the Monitor tab access levels and the administrator roles for which they
are available.
Device Group and Template roles can see log data only for the device groups that are
within the access domains assigned to those roles.
Access Descripon Administrator Role Enable Read Disable

Level Availability Only
Monitor Enables or disables access to Firewall: Yes Yes No Yes

the Monitor tab. If disabled, the
Panorama: Yes
administrator will not see this
tab or any of the associated logs Device Group/
or reports. Template: Yes
Logs Enables or disables access to Firewall: Yes Yes No Yes

all log files. You can also leave
Panorama: Yes
this privilege enabled and then
disable specific logs that you Device Group/
do not want the administrator Template: Yes
to see. Keep in mind that if you
want to protect the privacy of
your users while sll providing
access to one or more of the
logs, you can disable the Privacy
> Show Full IP Addresses opon

and/or the Show User Names In
Logs And Reports opon.
Traffic Specifies whether the Firewall: Yes Yes No Yes

administrator can see the traffic
Panorama: Yes
logs.
Device Group/
Template: Yes
Threat Specifies whether the Firewall: Yes Yes No Yes

administrator can see the threat
Panorama: Yes
logs.
Device Group/
Template: Yes
URL Specifies whether the Firewall: Yes Yes No Yes

Filtering administrator can see the URL
Panorama: Yes
filtering logs.
Device Group/
Template: Yes
WildFire Specifies whether the Firewall: Yes Yes No Yes

Submissions administrator can see the
Panorama: Yes
WildFire logs. These logs are
only available if you have a Device Group/
WildFire subscripon. Template: Yes
Data Specifies whether the Firewall: Yes Yes No Yes

Filtering administrator can see the data
Panorama: Yes
filtering logs.
Device Group/
Template: Yes
HIP Match Specifies whether the Firewall: Yes Yes No Yes

administrator can see the
Panorama: Yes
HIP Match logs. HIP Match
logs are available only if you Device Group/
have a GlobalProtect license Template: Yes
(subscripon).
GlobalProtectSpecifies whether the Firewall: Yes Yes No Yes

Panorama: Yes
GlobalProtect logs. These
logs are available only if you Device Group/
have a GlobalProtect license Template: Yes
(subscripon).

User-ID Specifies whether the Firewall: Yes Yes No Yes

administrator can see the User-
Panorama: Yes
ID logs.
Device Group/
Template: Yes
GTP Specifies whether the mobile Firewall: Yes Yes No Yes

network operator can see GTP
Panorama: Yes
logs.
Device Group/
Template: Yes
Tunnel Specifies whether the Firewall: Yes Yes No Yes

Inspecon administrator can see the Tunnel
Panorama: Yes
Inspecon logs.
Device Group/
Template: Yes
SCTP Specifies whether the mobile Firewall: Yes Yes No Yes

network operator can see
Panorama: Yes
Stream Control Transmission
Protocol (SCTP) logs. Device Group/
Template: Yes
You must enable
SCTP on Panorama
(Device > Setup
> Management)
before you
can control
Administrator
access to SCTP
logs, custom
reports, or
predefined reports
for Panorama and
Device Group/
Template.
ConfiguraonSpecifies whether the Firewall: Yes Yes No Yes

Panorama: Yes
configuraon logs.
Device Group/
Template: No

System Specifies whether the Firewall: Yes Yes No Yes

Panorama: Yes
system logs.
Device Group/
Template: No
Alarms Specifies whether the Firewall: Yes Yes No Yes

administrator can see system-
Panorama: Yes
generated alarms.
Device Group/
Template: Yes
Authencaon
Specifies whether the Firewall: Yes Yes No Yes
Panorama: Yes
Authencaon logs.
Device Group/
Template: No
Automated Enables or disables access to Firewall: Yes Yes No Yes

Correlaon the correlaon objects and
Panorama: Yes
Engine correlated event logs generated
on the firewall. Device Group/
Template: Yes
Correlaon Specifies whether the Firewall: Yes Yes No Yes

Objects administrator can view and
Panorama: Yes
enable/disable the correlaon
objects. Device Group/
Template: Yes
Correlated Specifies whether the Firewall: Yes Yes No Yes

Events administrator can view and
Panorama: Yes
enable/disable the correlaon
events. Device Group/
Template: Yes
Packet Specifies whether the Firewall: Yes Yes Yes Yes

Capture administrator can see packet
Panorama: No
captures (pcaps) from the
Monitor tab. Keep in mind that Device Group/
packet captures are raw flow Template: No
data and as such may contain
user IP addresses. Disabling
the Show Full IP Addresses
privileges will not obfuscate
the IP address in the pcap and

you should therefore disable
the Packet Capture privilege if
you are concerned about user
privacy.
App Scope Specifies whether the Firewall: Yes Yes No Yes

administrator can see the App
Panorama: Yes
Scope visibility and analysis
tools. Enabling App Scope Device Group/
enables access to all of the App Template: Yes
Scope charts.
Session Specifies whether the Firewall: Yes Yes No Yes

Browser administrator can browse and
Panorama: No
filter current running sessions
on the firewall. Keep in mind Device Group/
that the session browser shows Template: No
raw flow data and as such
may contain user IP addresses.
Disabling the Show Full IP
Addresses privileges will not
obfuscate the IP address in the
session browser and you should
therefore disable the Session
Browser privilege if you are
concerned about user privacy.
Block IP Specifies whether the Firewall: Yes Yes Yes Yes

List administrator can view the
Panorama: under
block list (Enable or Read Only)
Context Switch UI: Yes
and delete entries from the
list (Enable). If you disable the Template: Yes
seng, the administrator won’t
be able to view or delete entries
from the block list.
Botnet Specifies whether the Firewall: Yes Yes Yes Yes

administrator can generate and
Panorama: No
view botnet analysis reports
or view botnet reports in read- Device Group/
only mode. Disabling the Show Template: No
Full IP Addresses privileges will
not obfuscate the IP address in
scheduled botnet reports and

the Botnet privilege if you are
concerned about user privacy.
PDF Enables or disables access to Firewall: Yes Yes No Yes

Reports all PDF reports. You can also
Panorama: Yes
leave this privilege enabled
and then disable specific PDF Device Group/
reports that you do not want Template: Yes
the administrator to see. Keep in
mind that if you want to protect
the privacy of your users while
sll providing access to one or
more of the reports, you can
disable the Privacy > Show Full
IP Addresses opon and/or the
Show User Names In Logs And
Reports opon.
Manage Specifies whether the Firewall: Yes Yes Yes Yes

PDF administrator can view, add or
Panorama: Yes
Summary delete PDF summary report
definions. With read-only Device Group/
access, the administrator can Template: Yes
see PDF summary report
definions, but not add or
delete them. If you disable
this opon, the administrator
can neither view the report
definions nor add/delete them.
PDF Specifies whether the Firewall: Yes Yes No Yes

Summary administrator can see the
Panorama: Yes
Reports generated PDF Summary
reports in Monitor > Reports. If Device Group/
you disable this opon, the PDF Template: Yes
Summary Reports category will
not display in the Reports node.
User Specifies whether the Firewall: Yes Yes Yes Yes

Acvity administrator can view, add
Panorama: Yes
Report or delete User Acvity report
definions and download the Device Group/
reports. With read-only access, Template: Yes
the administrator can see User
Acvity report definions, but
not add, delete, or download
them. If you disable this opon,

the administrator cannot see
this category of PDF report.
SaaS Specifies whether the Firewall: Yes Yes Yes Yes

Applicaon administrator can view, add or
Panorama: Yes
Usage delete a SaaS applicaon usage
Report report. With read-only access, Device Group/
the administrator can see the Template: Yes
SaaS applicaon usage report
definions, but cannot add
or delete them. If you disable
this opon, the administrator
can neither view the report
definions nor add or delete
them.
Report Specifies whether the Firewall: Yes Yes Yes Yes

Groups administrator can view, add or
Panorama: Yes
delete report group definions.
With read-only access, the Device Group/
administrator can see report Template: Yes
group definions, but not add or
delete them. If you disable this
opon, the administrator cannot
see this category of PDF report.
Email Specifies whether the Firewall: Yes Yes Yes Yes

Scheduler administrator can schedule
Panorama: Yes
report groups for email. Because
the generated reports that get Device Group/
emailed may contain sensive Template: Yes
user data that is not removed
by disabling the Privacy > Show
Full IP Addresses opon and/
or the Show User Names In
Logs And Reports opons
and because they may also
show log data to which the
administrator does not have
access, you should disable the
Email Scheduler opon if you
have user privacy requirements.
Manage Enables or disables access to Firewall: Yes Yes No Yes

Custom all custom report funconality.
Panorama: Yes
Reports You can also leave this
privilege enabled and then

disable specific custom report Device Group/
categories that you do not Template: Yes
want the administrator to be
able to access. Keep in mind
that if you want to protect the
privacy of your users while
sll providing access to one or
more of the reports, you can
disable the Privacy > Show Full
IP Addresses opon and/or the
Show User Names In Logs And
Reports opon.
Reports that are

scheduled to run
rather than run on
demand will show
IP address and user
informaon. In this
case, be sure to
restrict access to
the corresponding
report areas. In
addion, the
custom report
feature does not
restrict the ability
to generate reports
that contain log
data contained
in logs that are
excluded from the
administrator role.
Applicaon Specifies whether the Firewall: Yes Yes No Yes

Stascs administrator can create a
Panorama: Yes
custom report that includes data
from the applicaon stascs Device Group/
database. Template: Yes
Data Specifies whether the Firewall: Yes Yes No Yes

Filtering administrator can create a
Panorama: Yes
Log custom report that includes data
from the Data Filtering logs. Device Group/
Template: Yes

Threat Log Specifies whether the Firewall: Yes Yes No Yes

administrator can create a
Panorama: Yes
from the Threat logs. Device Group/
Template: Yes
Threat Specifies whether the Firewall: Yes Yes No Yes

Summary administrator can create a
Panorama: Yes
custom report that includes
data from the Threat Summary Device Group/
Traffic Log Specifies whether the Firewall: Yes Yes No Yes

Panorama: Yes
from the Traffic logs. Device Group/
Template: Yes
Traffic Specifies whether the Firewall: Yes Yes No Yes

Panorama: Yes
data from the Traffic Summary Device Group/
URL Log Specifies whether the Firewall: Yes Yes No Yes

Panorama: Yes
from the URL Filtering logs. Device Group/
Template: Yes
HIP Match Specifies whether the Firewall: Yes Yes No Yes

Panorama: Yes
from the HIP Match logs. Device Group/
Template: Yes
GlobalProtectSpecifies whether the Firewall: Yes Yes No Yes

Panorama: Yes
from the GlobalProtect logs. Device Group/
Template: Yes
WildFire Specifies whether the Firewall: Yes Yes No Yes

Log administrator can create a
Panorama: Yes

custom report that includes data Device Group/
from the WildFire logs. Template: Yes
GTP Log Specifies whether the mobile Firewall: Yes Yes No Yes
network operator can create a
Panorama: Yes
from GTP logs. Device Group/
Template: Yes
GTP Specifies whether the mobile Firewall: Yes Yes No Yes

Summary network operator can create a
Panorama: Yes
from GTP logs. Device Group/
Template: Yes
Tunnel Log Specifies whether the Firewall: Yes Yes No Yes

Panorama: Yes
from tunnel inspecon logs. Device Group/
Template: Yes
Tunnel Specifies whether the Firewall: Yes Yes No Yes

Panorama: Yes
data from the Tunnel Summary Device Group/
SCTP Log Specifies whether the mobile Firewall: Yes Yes No Yes
network operator can create a
Panorama: Yes
from SCTP logs. Device Group/
Template: Yes
SCTP Specifies whether the mobile Firewall: Yes Yes No Yes

Summary network operator can create
Panorama: Yes
a custom report that includes
data from the SCTP Summary Device Group/
Userid Specifies whether the Firewall: Yes Yes No Yes

Panorama: Yes
from the User-ID logs. Device Group/
Template: Yes

Auth Specifies whether the Firewall: Yes Yes No Yes

Panorama: Yes
from the Authencaon logs. Device Group/
Template: Yes
View Specifies whether the Firewall: Yes Yes No Yes

Scheduled administrator can view a custom
Panorama: Yes
Custom report that has been scheduled
Reports to generate. Device Group/
Template: Yes

Predefined administrator can view
Panorama: Yes
Applicaon Applicaon Reports. Privacy
Reports privileges do not impact reports Device Group/
available on the Monitor > Template: Yes
Reports node and you should
therefore disable access to the
reports if you have user privacy
requirements.

Predefined administrator can view Threat
Panorama: Yes
Threat Reports. Privacy privileges do
Reports not impact reports available on Device Group/
the Monitor > Reports node and Template: Yes
access to the reports if you have
user privacy requirements.

Predefined administrator can view URL
Panorama: Yes
URL Filtering Reports. Privacy
Filtering privileges do not impact reports Device Group/
Reports available on the Monitor > Template: Yes
Reports node and you should
therefore disable access to the
reports if you have user privacy
requirements.

Predefined administrator can view Traffic
Panorama: Yes
Traffic Reports. Privacy privileges do

View Specifies whether the mobile Firewall: Yes Yes No Yes

Predefined network operator can view GTP
Panorama: Yes
GTP Reports. Privacy privileges do
View Specifies whether the mobile Firewall: Yes Yes No Yes

Predefined network operator can view
Panorama: Yes
SCTP SCTP Reports. Privacy privileges
Reports do not impact reports available Device Group/
on the Monitor > Reports node Template: Yes
and you should therefore disable
Provide Granular Access to the Policy Tab

If you enable the Policy opon in the Admin Role profile, you can then enable, disable, or provide
read-only access to specific nodes within the tab as necessary for the role you are defining. By
enabling access to a specific policy type, you enable the ability to view, add, or delete policy
rules. By enabling read-only access to a specific policy, you enable the administrator to view the
corresponding policy rule base, but not add or delete rules. Disabling access to a specific type of
policy prevents the administrator from seeing the policy rule base.
Because policy that is based on specific users (by username or IP address) must be explicitly
defined, privacy sengs that disable the ability to see full IP addresses or usernames do not apply
to the Policy tab. Therefore, you should only allow access to the Policy tab to administrators that
are excluded from user privacy restricons.

Only
Security Enable this privilege to allow the Yes Yes Yes

administrator to view, add, and/or delete
security rules. Set the privilege to read-
only if you want the administrator to
be able to see the rules, but not modify
them. To prevent the administrator from

Only
seeing the security rulebase, disable this
privilege.
NAT Enable this privilege to allow the Yes Yes Yes

NAT rules. Set the privilege to read-only
if you want the administrator to be able
to see the rules, but not modify them. To
prevent the administrator from seeing the
NAT rulebase, disable this privilege.
QoS Enable this privilege to allow the Yes Yes Yes

QoS rules. Set the privilege to read-only
if you want the administrator to be able
to see the rules, but not modify them. To
prevent the administrator from seeing the
QoS rulebase, disable this privilege.
Policy Based Enable this privilege to allow the Yes Yes Yes
Forwarding administrator to view, add, and/or delete
Policy-Based Forwarding (PBF) rules. Set
the privilege to read-only if you want
the administrator to be able to see the
rules, but not modify them. To prevent
the administrator from seeing the PBF
rulebase, disable this privilege.
Decrypon Enable this privilege to allow the Yes Yes Yes

decrypon rules. Set the privilege to read-
only if you want the administrator to
seeing the decrypon rulebase, disable
this privilege.
Network Packet Enable this privilege to allow the Yes Yes Yes
Broker administrator to view, add, and/or delete
Network Packet Broker policy rules. Set
the privilege to read-only if you want
the administrator to be able to see the
rules, but not modify them. To prevent the
administrator from seeing the Network
Packet Broker rulebase in the interface,
disable this privilege.

Only
Tunnel Inspecon Enable this privilege to allow the Yes Yes Yes
Tunnel Inspecon rules. Set the privilege
to read-only if you want the administrator
to be able to see the rules, but not modify
seeing the Tunnel Inspecon rulebase,
Applicaon Enable this privilege to allow the Yes Yes Yes

Override administrator to view, add, and/or delete
applicaon override policy rules. Set the
privilege to read-only if you want the
administrator to be able to see the rules,
but not modify them. To prevent the
administrator from seeing the applicaon
override rulebase, disable this privilege.
Authencaon Enable this privilege to allow the Yes Yes Yes

administrator to view, add, and/or
delete Authencaon policy rules.
Set the privilege to read-only if you
want the administrator to be able to
see the rules, but not modify them. To
prevent the administrator from seeing
the Authencaon rulebase, disable this
privilege.
DoS Protecon Enable this privilege to allow the Yes Yes Yes
DoS protecon rules. Set the privilege to
read-only if you want the administrator to
seeing the DoS protecon rulebase,
SD-WAN Enable this privilege to allow the Yes Yes Yes

SD-WAN policy rules. Set the privilege to
read-only if you want the administrator to
seeing the SD-WAN policy rulebase,
Provide Granular Access to the Objects Tab

An object is a container that groups specific policy filter values—such as IP addresses, URLs,
applicaons, or services—for simplified rule definion. For example, an address object might
contain specific IP address definions for the web and applicaon servers in your DMZ zone.
When deciding whether to allow access to the objects tab as a whole, determine whether the
administrator will have policy definion responsibilies. If not, the administrator probably does not
need access to the tab. If, however, the administrator will need to create policy, you can enable
access to the tab and then provide granular access privileges at the node level.
By enabling access to a specific node, you give the administrator the privilege to view, add, and
delete the corresponding object type. Giving read-only access allows the administrator to view the
already defined objects, but not create or delete any. Disabling a node prevents the administrator
from seeing the node in the web interface.

Only
Addresses Specifies whether the administrator can Yes Yes Yes

view, add, or delete address objects for
use in security policy.
Address Groups Specifies whether the administrator can Yes Yes Yes
view, add, or delete address group objects
for use in security policy.
Regions Specifies whether the administrator can Yes Yes Yes

view, add, or delete regions objects for
use in security, decrypon, or DoS policy.
Applicaons Specifies whether the administrator can Yes Yes Yes

view, add, or delete applicaon objects for
use in policy.
Applicaon Specifies whether the administrator can Yes Yes Yes

Groups view, add, or delete applicaon group
objects for use in policy.
Applicaon Specifies whether the administrator can Yes Yes Yes

Filters view, add, or delete applicaon filters for
simplificaon of repeated searches.
Services Specifies whether the administrator can Yes Yes Yes

view, add, or delete service objects for use
in creang policy rules that limit the port
numbers an applicaon can use.

Only
Service Groups Specifies whether the administrator can Yes Yes Yes
view, add, or delete service group objects
Tags Specifies whether the administrator can Yes Yes Yes

view, add, or delete tags that have been
defined on the firewall.
GlobalProtect Specifies whether the administrator can Yes No Yes

view, add, or delete HIP objects and
profiles. You can restrict access to both
types of objects at the GlobalProtect
level, or provide more granular control
by enabling the GlobalProtect privilege
and restricng HIP Object or HIP Profile
access.
HIP Objects Specifies whether the administrator can Yes Yes Yes
view, add, or delete HIP objects, which are
used to define HIP profiles. HIP Objects
also generate HIP Match logs.
Clientless Apps Specifies whether the administrator can Yes Yes Yes
view, add, modify, or delete GlobalProtect
VPN Clientless applicaons.
Clientless App Specifies whether the administrator can Yes Yes Yes
Groups view, add, modify, or delete GlobalProtect
VPN Clientless applicaon groups.
HIP Profiles Specifies whether the administrator can Yes Yes Yes
view, add, or delete HIP Profiles for use in
security policy and/or for generang HIP
Match logs.
External Dynamic Specifies whether the administrator can Yes Yes Yes
Lists view, add, or delete external dynamic lists
Custom Objects Specifies whether the administrator can Yes No Yes

see the custom spyware and vulnerability
signatures. You can restrict access to
either enable or disable access to all
custom signatures at this level, or provide
more granular control by enabling the
Custom Objects privilege and then

Only
restricng access to each type of
signature.
Data Paerns Specifies whether the administrator can Yes Yes Yes
view, add, or delete custom data paern
signatures for use in creang custom
Vulnerability Protecon profiles.
Spyware Specifies whether the administrator can Yes Yes Yes

view, add, or delete custom spyware
Vulnerability Specifies whether the administrator can Yes Yes Yes

view, add, or delete custom vulnerability
URL Category Specifies whether the administrator Yes Yes Yes

can view, add, or delete custom URL
categories for use in policy.
Security Profiles Specifies whether the administrator can Yes No Yes

see security profiles. You can restrict
access to either enable or disable access
to all security profiles at this level, or
provide more granular control by enabling
the Security Profiles privilege and then
restricng access to each type of profile.
Anvirus Specifies whether the administrator can Yes Yes Yes

view, add, or delete anvirus profiles.
An-Spyware Specifies whether the administrator can Yes Yes Yes

view, add, or delete An-Spyware profiles.
Vulnerability Specifies whether the administrator Yes Yes Yes

Protecon can view, add, or delete Vulnerability
Protecon profiles.
URL Filtering Specifies whether the administrator can Yes Yes Yes
view, add, or delete URL filtering profiles.
File Blocking Specifies whether the administrator can Yes Yes Yes
view, add, or delete file blocking profiles.

Only
WildFire Analysis Specifies whether the administrator can Yes Yes Yes
view, add, or delete WildFire analysis
profiles.
Data Filtering Specifies whether the administrator can Yes Yes Yes
view, add, or delete data filtering profiles.
DoS Protecon Specifies whether the administrator Yes Yes Yes

can view, add, or delete DoS protecon
profiles.
GTP Protecon Specifies whether the mobile network Yes Yes Yes
operator can view, add, or delete GTP
SCTP Protecon Specifies whether the mobile network Yes Yes Yes
operator can view, add, or delete Stream
Control Transmission Protocol (SCTP)
Security Profile Specifies whether the administrator Yes Yes Yes

Groups can view, add, or delete security profile
groups.
Log Forwarding Specifies whether the administrator Yes Yes Yes

can view, add, or delete log forwarding
profiles.
Authencaon Specifies whether the administrator Yes Yes Yes

can view, add, or delete authencaon
enforcement objects.
Decrypon Specifies whether the administrator can Yes Yes Yes

Profile view, add, or delete decrypon profiles.
SD-WAN Link Specifies whether the administrator can Yes No Yes

Management add or delete Path Quality, SaaS Quality,
Traffic Distribuon, and Error Correcon
profiles.
Path Quality Specifies whether the administrator can Yes Yes Yes
Profile view, add, or delete SD-WAN Path Quality
profiles.

Only
SaaS Quality Specifies whether the administrator Yes Yes Yes

Profile can view, add, or delete SD-WAN SaaS
Quality profiles.
Traffic Specifies whether the administrator can Yes Yes Yes

Distribuon view, add, or delete SD-WAN Traffic
Profile Distribuon profiles.
Error Correcon Specifies whether the administrator Yes Yes Yes

Profile can view, add, or delete SD-WAN Error
Correcon profiles.
Packet Broker Specifies whether the administrator can Yes Yes Yes
Profile view, add, or delete Packet Broker profiles.
Schedules Specifies whether the administrator can Yes Yes Yes

view, add, or delete schedules for liming
a security policy to a specific date and/or
me range.
Provide Granular Access to the Network Tab

When deciding whether to allow access to the Network tab as a whole, determine whether
the administrator will have network administraon responsibilies, including GlobalProtect
administraon. If not, the administrator probably does not need access to the tab.
You can also define access to the Network tab at the node level. By enabling access to a specific
node, you give the administrator the privilege to view, add, and delete the corresponding network
configuraons. Giving read-only access allows the administrator to view the already-defined
configuraon, but not create or delete any. Disabling a node prevents the administrator from
seeing the node in the web interface.

Only
Interfaces Specifies whether the administrator Yes Yes Yes

can view, add, or delete interface
configuraons.
Zones Specifies whether the administrator can Yes Yes Yes

view, add, or delete zones.
VLANs Specifies whether the administrator can Yes Yes Yes

view, add, or delete VLANs.

Only
Virtual Wires Specifies whether the administrator can Yes Yes Yes
view, add, or delete virtual wires.
Virtual Routers Specifies whether the administrator can Yes Yes Yes
view, add, modify or delete virtual routers.
IPSec Tunnels Specifies whether the administrator can Yes Yes Yes
view, add, modify, or delete IPSec Tunnel
configuraons.
GRE Tunnels Specifies whether the administrator can Yes Yes Yes
view, add, modify, or delete GRE Tunnel
configuraons.
DHCP Specifies whether the administrator can Yes Yes Yes

view, add, modify, or delete DHCP server
and DHCP relay configuraons.
DNS Proxy Specifies whether the administrator can Yes Yes Yes
view, add, modify, or delete DNS proxy
configuraons.
GlobalProtect Specifies whether the administrator Yes No Yes

can view, add, modify GlobalProtect
portal and gateway configuraons. You
can disable access to the GlobalProtect
funcons enrely, or you can enable the
GlobalProtect privilege and then restrict
the role to either the portal or gateway
configuraon areas.
Portals Specifies whether the administrator can Yes Yes Yes

portal configuraons.
Gateways Specifies whether the administrator can Yes Yes Yes

gateway configuraons.
MDM Specifies whether the administrator can Yes Yes Yes

MDM server configuraons.

Only
Device Block List Specifies whether the administrator can Yes Yes Yes
view, add, modify, or delete device block
lists.
Clientless Apps Specifies whether the administrator can Yes Yes Yes
Clientless VPN applicaons.
Clientless App Specifies whether the administrator can Yes Yes Yes
Groups view, add, modify, or delete GlobalProtect
Clientless VPN applicaon groups.
QoS Specifies whether the administrator Yes Yes Yes

can view, add, modify, or delete QoS
configuraons.
LLDP Specifies whether the administrator Yes Yes Yes

can view add, modify, or delete LLDP
configuraons.
Network Profiles Sets the default state to enable or disable Yes No Yes
for all of the Network sengs described
below.
GlobalProtect Controls access to the Network Profiles > Yes Yes Yes
IPSec Crypto GlobalProtect IPSec Crypto node.
If you disable this privilege, the
administrator will not see that node, or
configure algorithms for authencaon
and encrypon in VPN tunnels between a
GlobalProtect gateway and clients.
If you set the privilege to read-only,
the administrator can view exisng
GlobalProtect IPSec Crypto profiles but
cannot add or edit them.
IKE Gateways Controls access to the Network Profiles Yes Yes Yes
> IKE Gateways node. If you disable
this privilege, the administrator will not
see the IKE Gateways node or define
gateways that include the configuraon
informaon necessary to perform IKE
protocol negoaon with peer gateway.

Only
If the privilege state is set to read-only,
you can view the currently configured
IKE Gateways but cannot add or edit
gateways.
IPSec Crypto Controls access to the Network Profiles Yes Yes Yes
> IPSec Crypto node. If you disable this
privilege, the administrator will not see
the Network Profiles > IPSec Crypto
node or specify protocols and algorithms
for idenficaon, authencaon, and
encrypon in VPN tunnels based on IPSec
SA negoaon.
IPSec Crypto configuraon but cannot add
or edit a configuraon.
IKE Crypto Controls how devices exchange Yes Yes Yes

informaon to ensure secure
communicaon. Specify the protocols
and algorithms for idenficaon,
authencaon, and encrypon in VPN
tunnels based on IPsec SA negoaon
(IKEv1 Phase-1).
Monitor Controls access to the Network Profiles > Yes Yes Yes
Monitor node. If you disable this privilege,
the administrator will not see the Network
Profiles > Monitor node or be able to
create or edit a monitor profile that
is used to monitor IPSec tunnels and
monitor a next-hop device for policy-
based forwarding (PBF) rules.
monitor profile configuraon but cannot
add or edit a configuraon.
Interface Mgmt Controls access to the Network Profiles > Yes Yes Yes
Interface Mgmt node. If you disable this
the Network Profiles > Interface Mgmt
node or be able to specify the protocols
that are used to manage the firewall.

Only
If the privilege state is set to read-
only, you can view the currently
configured Interface management profile
configuraon but cannot add or edit a
configuraon.
Zone Protecon Controls access to the Network Profiles > Yes Yes Yes
Zone Protecon node. If you disable this
the Network Profiles > Zone Protecon
node or be able to configure a profile that
determines how the firewall responds to
aacks from specified security zones.
Zone Protecon profile configuraon but
cannot add or edit a configuraon.
QoS Profile Controls access to the Network Profiles Yes Yes Yes
> QoS node. If you disable this privilege,
Profiles > QoS node or be able to
configure a QoS profile that determines
how QoS traffic classes are treated.
QoS profile configuraon but cannot add
LLDP Profile Controls access to the Network Profiles Yes Yes Yes
> LLDP node. If you disable this privilege,
Profiles > LLDP node or be able to
configure an LLDP profile that controls
whether the interfaces on the firewall can
parcipate in the Link Layer Discovery
Protocol.
LLDP profile configuraon but cannot add
BFD Profile Controls access to the Network Profiles Yes Yes Yes
> BFD Profile node. If you disable this

Only
the Network Profiles > BFD Profile node
or be able to configure a BFD profile.
A Bidireconal Forwarding Detecon
(BFD) profile allows you to configure BFD
sengs to apply to one or more stac
routes or roung protocols. Thus, BFD
detects a failed link or BFD peer and
allows an extremely fast failover.
BFD profile but cannot add or edit a BFD
profile.
SD-WAN Controls access to the SD-WAN Interface Yes Yes Yes

Interface Profile Profile node. If you disable this privilege,
the administrator will not see the SD-
WAN Interface Profile node or be able to
configure an SD-WAN Interface Profile.
An SD-WAN Interface Profile defines
the characteriscs of ISP connecons
and specifies the link speed and how
frequently the firewall monitors the link.
you can view the currently configured SD-
WAN Interface Profile but cannot add or
edit one.
Provide Granular Access to the Device Tab

To define granular access privileges for the Device tab, when creang or eding an admin role
profile (Device > Admin Roles), scroll down to the Device node on the WebUI tab.

Only
Setup Controls access to the Setup node. If you Yes Yes Yes
will not see the Setup node or have access
to firewall-wide setup configuraon
informaon, such as Management,
Operaons, Service, Content-ID, WildFire
or Session setup informaon.

Only
you can view the current configuraon
but cannot make any changes.
Management Controls access to the Management Yes Yes Yes

node. If you disable this privilege, the
administrator will not be able to configure
sengs such as the hostname, domain,
mezone, authencaon, logging and
reporng, Panorama connecons, banner,
message, and password complexity
sengs, and more.
Operaons Controls access to the Operaons Yes Yes Yes

and Telemetry and Threat Intelligence
nodes. If you disable this privilege, the
administrator cannot:
• Load firewall configuraons.
• Save or revert the firewall
configuraon.
This privilege applies

only to the Device >
Operaons opons.
The Save and Commit
privileges control whether
the administrator can save
or revert configuraons
through the Config >
Save and Config > Revert
opons.
• Create custom logos.
• Configure SNMP monitoring of firewall
sengs.
• Configure the Stascs Service feature.
• Configure Telemetry and Threat
Intelligence sengs.
Only administrators with the predefined
Superuser role can export or import

Only
firewall configuraons and shut down the
firewall.
Superuser or Device Administrator role
can reboot the firewall or restart the
dataplane.
Administrators with a role that allows
access only to specific virtual systems
cannot load, save, or revert firewall
configuraons through the Device >
Operaons opons.
Services Controls access to the Services Yes Yes Yes

services for DNS servers, an update
server, proxy server, or NTP servers, or set
up service routes.
Content-ID Controls access to the Content-ID Yes Yes Yes

URL filtering or Content-ID.
WildFire Controls access to the WildFire Yes Yes Yes

WildFire sengs.
Session Controls access to the Session node. Yes Yes Yes

session sengs or meouts for TCP, UDP
or ICMP, or configure decrypon or VPN
session sengs.

Only
HSM Controls access to the HSM node. If you Yes Yes Yes
will not be able to configure a Hardware
Security Module.
High Availability Controls access to the High Availability Yes Yes Yes
node. If you disable this privilege,
the administrator will not see the
High Availability node or have access
to firewall-wide high availability
configuraon informaon such as General
setup informaon or Link and Path
Monitoring.
If you set this privilege to read-only, the
administrator can view High Availability
configuraon informaon for the firewall
but is not allowed to perform any
configuraon procedures.
Config Audit Controls access to the Config Audit Yes No Yes

administrator will not see the Config Audit
node or have access to any firewall-wide
configuraon informaon.
Administrators Controls access to the Administrators No Yes Yes

node. This funcon can only be allowed
for read-only access.
administrator will not see the
Administrators node or have access to
informaon about their own administrator
account.
administrator can view the configuraon
informaon for their own administrator
account. They will not see any informaon

Only
about other administrator accounts
configured on the firewall.
Admin Roles Controls access to the Admin Roles node. No Yes Yes
This funcon can only be allowed for
read-only access.
administrator will not see the Admin
Roles node or have access to any firewall-
wide informaon concerning Admin Role
profiles configuraon.
If you set this privilege to read-only, you
can view the configuraon informaon for
all administrator roles configured on the
firewall.
Authencaon Controls access to the Authencaon Yes Yes Yes

Profile Profile node. If you disable this privilege,
Authencaon Profile node or be
able to create or edit authencaon
profiles that specify RADIUS, TACACS
+, LDAP, Kerberos, SAML, mul-factor
authencaon (MFA), or local database
authencaon sengs. PAN-OS uses
authencaon profiles to authencate
firewall administrators and Authencaon
Portal or GlobalProtect end users.
administrator can view the Authencaon
Profile informaon but cannot create or
edit authencaon profiles.
Authencaon Controls access to the Authencaon Yes Yes Yes

Sequence Sequence node. If you disable this
the Authencaon Sequence node or be
able to create or edit an authencaon
sequence.
administrator can view the Authencaon
Profile informaon but cannot create or
edit an authencaon sequence.

Only
Virtual Systems Controls access to the Virtual Systems Yes Yes Yes
administrator will not see or be able to
configure virtual systems.
virtual systems but cannot add or edit a
configuraon.
Shared Gateways Controls access to the Shared Gateways Yes Yes Yes
node. Shared gateways allow virtual
systems to share a common interface for
external communicaons.
administrator will not see or be able to
configure shared gateways.
shared gateways but cannot add or edit a
configuraon.
User Controls access to the User Idenficaon Yes Yes Yes

Idenficaon node. If you disable this privilege, the
administrator will not see the User
Idenficaon node or have access
to firewall-wide User Idenficaon
configuraon informaon, such as User
Mapping, Connecon Security, User-ID
Agents, Terminal Server Agents, Group
Mappings Sengs, or Authencaon
Portal Sengs.
administrator can view configuraon
informaon for the firewall but is not
allowed to perform any configuraon
procedures.
VM Informaon Controls access to the VM Informaon Yes Yes Yes

Source Source node that allows you to configure
the firewall/Windows User-ID agent to
collect VM inventory automacally. If you
not see the VM Informaon Source node.

Only
If you set this privilege to read-only,
the administrator can view the VM
informaon sources configured but cannot
add, edit, or delete any sources.
This privilege is not available

to Device Group and
Template administrators.
Cerficate Sets the default state to enable or disable Yes No Yes

Management for all of the Cerficate sengs described
below.
Cerficates Controls access to the Cerficates Yes Yes Yes

administrator will not see the Cerficates
node or be able to configure or access
informaon regarding Device Cerficates
or Default Trusted Cerficate Authories.
the administrator can view Cerficate
configuraon informaon for the firewall
but is not allowed to perform any
configuraon procedures.
Cerficate Profile Controls access to the Cerficate Profile Yes Yes Yes
administrator will not see the Cerficate
Profile node or be able to create
cerficate profiles.
administrator can view Cerficate Profiles
that are currently configured for the
firewall but is not allowed to create or edit
a cerficate profile.
OCSP Responder Controls access to the OCSP Responder Yes Yes Yes
administrator will not see the OCSP
Responder node or be able to define
a server that will be used to verify the
revocaon status of cerficates issues by
the firewall.
the administrator can view the OCSP

Only
Responder configuraon for the firewall
but is not allowed to create or edit an
OCSP responder configuraon.
SSL/TLS Service Controls access to the SSL/TLS Service Yes Yes Yes
Profile Profile node.
administrator will not see the node
or configure a profile that specifies a
cerficate and a protocol version or range
of versions for firewall services that use
SSL/TLS.
administrator can view exisng SSL/TLS
Service profiles but cannot create or edit
them.
SCEP Controls access to the SCEP node. If you Yes Yes Yes
will not see the node or be able to define
a profile that specifies simple cerficate
enrollment protocol (SCEP) sengs for
issuing unique device cerficates.
administrator can view exisng SCEP
profiles but cannot create or edit them.
SSL Decrypon Controls access to the SSL Decrypon Yes Yes Yes
Exclusion Exclusion node. If you disable this
privilege, the administrator will not
see the node or be able see the SSL
decrypon add custom exclusions.
the administrator can view exisng SSL
decrypon excepons but cannot create
or edit them.
Response Pages Controls access to the Response Pages Yes Yes Yes
administrator will not see the Response
Page node or be able to define a custom
HTML message that is downloaded and
displayed instead of a requested web page
or file.

Only
administrator can view the Response Page
configuraon for the firewall but is not
allowed to create or edit a response page
configuraon.
Log Sengs Sets the default state to enable or disable Yes No Yes
for all of the Log sengs described below.
System Controls access to the Log Sengs > Yes Yes Yes
System node. If you disable this privilege,
the administrator cannot see the Log
Sengs > System node or specify which
System logs the firewall forwards to
Panorama or external services (such as a
syslog server).
administrator can view the Log Sengs >
System sengs for the firewall but cannot
add, edit, or delete the sengs.
Configuraon Controls access to the Log Sengs > Yes Yes Yes
Configuraon node. If you disable this
privilege, the administrator cannot see
the Log Sengs > Configuraon node
or specify which Configuraon logs the
firewall forwards to Panorama or external
services (such as a syslog server).
Configuraon sengs for the firewall but
cannot add, edit, or delete the sengs.
User-ID Controls access to the Log Sengs > Yes Yes Yes
User-ID node. If you disable this privilege,
the administrator cannot see the Log
Sengs > User-ID node or specify which
User-ID logs the firewall forwards to
Panorama or external services (such as a
syslog server).
administrator can view the Log Sengs
> User-ID sengs for the firewall but

Only
HIP Match Controls access to the Log Sengs > Yes Yes Yes
HIP Match node. If you disable this
the Log Sengs > HIP Match node or
specify which Host Informaon Profile
(HIP) match logs the firewall forwards to
Panorama or external services (such as
a syslog server). HIP match logs provide
informaon on Security policy rules that
apply to GlobalProtect endpoints.
> HIP sengs for the firewall but cannot
add, edit, or delete the sengs.
GlobalProtect Controls access to the Log Sengs > Yes Yes Yes
GlobalProtect node. If you disable this
the Log Sengs > GlobalProtect node
or specify which GlobalProtect logs the
firewall forwards to Panorama or external
services (such as a syslog server).
GlobalProtect sengs for the firewall but
Correlaon Controls access to the Log Sengs > Yes Yes Yes
Correlaon node. If you disable this
the Log Sengs > Correlaon node or
add, delete, or modify correlaon log
forwarding sengs or tag source or
desnaon IP addresses.
> Correlaon sengs for the firewall but
Alarm Sengs Controls access to the Log Sengs > Yes Yes Yes
Alarm Sengs node. If you disable this
the Log Sengs > Alarm Sengs node
or configure noficaons that the firewall
generates when a Security policy rule (or

Only
group of rules) is hit repeatedly within a
configurable me period.
Alarm Sengs for the firewall but cannot
edit the sengs.
Manage Logs Controls access to the Log Sengs > Yes Yes Yes
Manage Logs node. If you disable this
privilege, the administrator cannot see the
Log Sengs > Manage Logs node or clear
the indicated logs.
Manage Logs informaon but cannot clear
any of the logs.
Server Profiles Sets the default state to enable or disable Yes No Yes
for all of the Server Profiles sengs
described below.
SNMP Trap Controls access to the Server Profiles Yes Yes Yes
> SNMP Trap node. If you disable this
the Server Profiles > SNMP Trap node
or be able to specify one or more SNMP
trap desnaons to be used for system
log entries.
administrator can view the Server Profiles
> SNMP Trap Logs informaon but cannot
specify SNMP trap desnaons.
Syslog Controls access to the Server Profiles > Yes Yes Yes
Syslog node. If you disable this privilege,
the administrator will not see the Server
Profiles > Syslog node or be able to
specify one or more syslog servers.
> Syslog informaon but cannot specify
syslog servers.
Email Controls access to the Server Profiles > Yes Yes Yes
Email node. If you disable this privilege,

Only
Profiles > Email node or be able to
configure an email profile that can be used
to enable email noficaon for system and
configuraon log entries.
> Email informaon but cannot configure
an email server profile.
HTTP Controls access to the Server Profiles > Yes Yes Yes
HTTP node. If you disable this privilege,
Profiles > HTTP node or be able to
configure an HTTP server profile that can
be used to enable log forwarding to HTTP
desnaons any log entries.
> HTTP informaon but cannot configure
an HTTP server profile.
Nelow Controls access to the Server Profiles > Yes Yes Yes
Nelow node. If you disable this privilege,
Profiles > Nelow node or be able to
define a NetFlow server profile, which
specifies the frequency of the export
along with the NetFlow servers that will
receive the exported data.
> Nelow informaon but cannot define a
Nelow profile.
RADIUS Controls access to the Server Profiles > Yes Yes Yes
RADIUS node. If you disable this privilege,
Profiles > RADIUS node or be able to
configure sengs for the RADIUS servers
that are idenfied in authencaon
profiles.
the administrator can view the Server

Only
Profiles > RADIUS informaon but cannot
configure sengs for the RADIUS servers.
TACACS+ Controls access to the Server Profiles > Yes Yes Yes
TACACS+ node.
administrator will not see the node
or configure sengs for the TACACS
+ servers that authencaon profiles
reference.
administrator can view exisng TACACS
+ server profiles but cannot add or edit
them.
LDAP Controls access to the Server Profiles > Yes Yes Yes
LDAP node. If you disable this privilege,
Profiles > LDAP node or be able to
configure sengs for the LDAP servers
to use for authencaon by way of
authencaon profiles.
> LDAP informaon but cannot configure
sengs for the LDAP servers.
Kerberos Controls access to the Server Profiles Yes Yes Yes

> Kerberos node. If you disable this
the Server Profiles > Kerberos node or
configure a Kerberos server that allows
users to authencate navely to a domain
controller.
> Kerberos informaon but cannot
configure sengs for Kerberos servers.
SAML Identy Controls access to the Server Profiles Yes Yes Yes
Provider > SAML Identy Provider node. If you
cannot see the node or configure SAML
identy provider (IdP) server profiles.

Only
> SAML Identy Provider informaon but
cannot configure SAML IdP server profiles.
Mul Factor Controls access to the Server Profiles >

Authencaon Mul Factor Authencaon node. If you
cannot see the node or configure mul-
factor authencaon (MFA) server
profiles.
> SAML Identy Provider informaon but
cannot configure MFA server profiles.
Local User Sets the default state to enable or disable Yes No Yes
Database for all of the Local User Database sengs
described below.
Users Controls access to the Local User Yes Yes Yes

Database > Users node. If you disable
this privilege, the administrator will
not see the Local User Database >
Users node or set up a local database
on the firewall to store authencaon
informaon for remote access users,
firewall administrators, and Authencaon
Portal users.
administrator can view the Local User
Database > Users informaon but cannot
set up a local database on the firewall to
store authencaon informaon.
User Groups Controls access to the Local User Yes Yes Yes
Database > Users node. If you disable this
the Local User Database > Users node or
be able to add user group informaon to
the local database.
administrator can view the Local User
Database > Users informaon but cannot

Only
add user group informaon to the local
database.
Access Domain Controls access to the Access Domain Yes Yes Yes
administrator will not see the Access
Domain node or be able to create or edit
an access domain.
the administrator can view the Access
Domain informaon but cannot create or
edit an access domain.
Scheduled Log Controls access to the Scheduled Log Yes No Yes

Export Export node. If you disable this privilege,
Scheduled Log Export node or be able
schedule exports of logs and save them
to a File Transfer Protocol (FTP) server
in CSV format or use Secure Copy (SCP)
to securely transfer data between the
firewall and a remote host.
administrator can view the Scheduled
Log Export Profile informaon but cannot
schedule the export of logs.
Soware Controls access to the Soware Yes Yes Yes

administrator will not see the Soware
node or view the latest versions of the
PAN-OS soware available from Palo Alto
Networks, read the release notes for each
version, and select a release to download
and install.
administrator can view the Soware
informaon but cannot download or
install soware.
GlobalProtect Controls access to the GlobalProtect Yes Yes Yes

Client Client node. If you disable this privilege,
GlobalProtect Client node or view
available GlobalProtect releases, download

Only
the code or acvate the GlobalProtect
app.
administrator can view the available
GlobalProtect Client releases but cannot
download or install the app soware.
Dynamic Updates Controls access to the Dynamic Updates Yes Yes Yes
administrator will not see the Dynamic
Updates node or be able to view the latest
updates, read the release notes for each
update, or select an update to upload and
install.
administrator can view the available
Dynamic Updates releases, read the
release notes but cannot upload or install
the soware.
Licenses Controls access to the Licenses Yes Yes Yes

administrator will not see the Licenses
node or be able to view the licenses
installed or acvate licenses.
the administrator can view the installed
Licenses, but cannot perform license
management funcons.
Support Controls access to the Support node. Yes Yes Yes

administrator cannot see the Support
node, acvate support, or access
producon and security alerts from Palo
Alto Networks.
administrator can see the Support node
and access producon and security alerts
but cannot acvate support.
Superuser role can use the Support node
to generate tech support files or generate
and download stats dump and core files.

Only
Master Key and Controls access to the Master Key and Yes Yes Yes
Diagnoscs Diagnoscs node. If you disable this
the Master Key and Diagnoscs node or
be able to specify a master key to encrypt
private keys on the firewall.
the administrator can view the Master
Key and Diagnoscs node and view
informaon about master keys that have
been specified but cannot add or edit a
new master key configuraon.
Policy Controls access to IoT and SaaS policy rule Yes Yes Yes
Recommendaon recommendaons. If you disable these
privileges, the administrator can’t see the
Policy Recommendaon > IoT node, the
Policy Recommendaon > SaaS node, or
both, depending on which privileges you
disable.
If you set these privileges to read-only,
the administrator can view the nodes
but cannot import policy rules or edit
informaon.
Define User Privacy Sengs in the Admin Role Profile

To define what private end user data an administrator has access to, when creang or eding an
admin role profile (Device > Admin Roles), scroll down to the Privacy opon on the WebUI tab.

Only
Privacy Sets the default state to enable or disable Yes N/A Yes
for all of the privacy sengs described
below.
Show Full IP When disabled, full IP addresses obtained Yes N/A Yes
addresses by traffic running through the Palo Alto
firewall are not shown in logs or reports.
In place of the IP addresses that are
normally displayed, the relevant subnet is
displayed.

Only
Scheduled reports that are
displayed in the interface
through Monitor > Reports
and reports that are sent
via scheduled emails will
sll display full IP addresses.
Because of this excepon, we
recommend that the following
sengs within the Monitor
tab be set to disable: Custom
Reports, Applicaon Reports,
Threat Reports, URL Filtering
Reports, Traffic Reports and
Email Scheduler.
Show User When disabled, usernames obtained Yes N/A Yes

Names in Logs by traffic running through the Palo Alto
and Reports Networks firewall are not shown in logs
or reports. Columns where the usernames
would normally be displayed are empty.
Scheduled reports that are

displayed in the interface
through Monitor > Reports
or reports that are sent via
the email scheduler will
sll display usernames.
Because of this excepon, we
recommend that the following
sengs within the Monitor
tab be set to disable: Custom
Reports, Applicaon Reports,
Threat Reports, URL Filtering
Reports, Traffic Reports and
Email Scheduler.
View PCAP Files When disabled, packet capture files that Yes N/A Yes
are normally available within the Traffic,
Threat and Data Filtering logs are not
displayed.
Restrict Administrator Access to Commit and Validate Funcons

To restrict access to commit (and revert), save, and validate funcons when creang or eding an
Admin Role profile (Device > Admin Roles), scroll down to the Commit, Save, and Validate opons
on the WebUI tab.

Only
Commit Sets the default state to enabled or Yes N/A Yes

disabled for all of the commit and revert
privileges described below.
Device When disabled, an administrator cannot Yes N/A Yes

commit or revert changes that any
administrator made to the firewall
configuraon, including his or her own
changes.
Commit For When disabled, an administrator cannot Yes N/A Yes

Other Admins commit or revert changes that other
administrators made to the firewall
configuraon.
Save Sets the default state to enabled or Yes N/A Yes

disabled for all of the save operaon
privileges described below.
Paral save When disabled, an administrator cannot Yes N/A Yes

save changes that any administrator made
to the firewall configuraon, including his
or her own changes.
Save For Other When disabled, an administrator cannot Yes N/A Yes
Admins save changes that other administrators
made to the firewall configuraon.
Validate When disabled, an administrator cannot Yes N/A Yes

validate a configuraon.
Provide Granular Access to Global Sengs

To define what global sengs and administrator has access to, when creang or eding an admin
role profile (Device > Admin Roles), scroll down to the Global opon on the WebUI tab.

Only
Global Sets the default state to enable or disable Yes N/A Yes
for all of the global sengs described
below. In effect, this seng is only for
System Alarms at this me.
System Alarms When disabled, an administrator cannot Yes N/A Yes

view or acknowledge alarms that are
generated.
Provide Granular Access to the Panorama Tab

The following table lists the Panorama tab access levels and the custom Panorama administrator
roles for which they are available. Firewall administrators cannot access any of these privileges.
Access Level Descripon Administrator Role Enable Read Disable

Availability Only
Setup Specifies whether the Panorama: Yes Yes Yes Yes

administrator can view or edit
Device Group/
Panorama setup informaon,
Template: No
including Management,
Operaons and Telemetry,
Services, Content-ID, WildFire,
Session, or HSM.
If you set the privilege to:
• read-only, the administrator
can see the informaon but
cannot edit it.
• disable this privilege, the
administrator cannot see or
edit the informaon.
High Specifies whether the Panorama: Yes Yes Yes Yes

Availability administrator can view and
Device Group/
manage high availability (HA)
Template: No
sengs for the Panorama
management server.
If you set this privilege to
read-only, the administrator
can view HA configuraon
informaon for the Panorama
management server but can’t
manage the configuraon.

Availability Only
If you disable this privilege,
the administrator can’t see
or manage HA configuraon
sengs for the Panorama
management server.
Config Specifies whether the Panorama: Yes Yes No Yes

Audit administrator can run
Device Group/
Panorama configuraon audits.
Template: No
the administrator can’t run
Panorama configuraon audits.
AdministratorsSpecifies whether the Panorama: Yes No Yes Yes

administrator can view
Device Group/
Panorama administrator
Template: No
account details.
You can’t enable full access
to this funcon: just read-
only access. (Only Panorama
administrators with a dynamic
role can add, edit, or delete
Panorama administrators.)
With read-only access,
the administrator can see
informaon about his or her
own account but no other
accounts.
the administrator can’t
see informaon about any
account, including his or her
own.
Admin Specifies whether the Panorama: Yes No Yes Yes

Roles administrator can view
Device Group/
Panorama administrator roles.
Template: No
You can’t enable full access
to this funcon: just read-
only access. (Only Panorama
administrators with a dynamic
role can add, edit, or delete
custom Panorama roles.)

Availability Only
With read-only access,
the administrator can see
role configuraons but can’t
manage them.
see or manage Panorama
administrator roles.
Access Specifies whether the Panorama: Yes Yes Yes Yes

Domain administrator can view, add,
Device Group/
edit, delete, or clone access
Template: No
domain configuraons for
Panorama administrators.
You
(This privilege controls access
assign
only to the configuraon of
access
access domains, not access to
domains
the device groups, templates,
to Device
and firewall contexts that are
Group
assigned to access domains.)
and
If you set this privilege to Template
read-only, the administrator administrators
can view Panorama access so they
domain configuraons but can’t can
manage them. access the
configuraon
and
monitoring
or manage Panorama access
data
domain configuraons.
within the
device
groups,
templates,
and
firewall
contexts
that are
assigned
to those
access
domains.
AuthencaonSpecifies whether the Panorama: Yes Yes Yes Yes

Profile administrator can view,

Availability Only
add, edit, delete, or clone Device Group/
authencaon profiles for Template: No
If you set this privilege to read-
only, the administrator can
view Panorama authencaon
profiles but can’t manage them.
authencaon profiles.
AuthencaonSpecifies whether the Panorama: Yes Yes Yes Yes

Sequence administrator can view,
Device Group/
add, edit, delete, or clone
Template: No
authencaon sequences for
view Panorama authencaon
sequences but can’t manage
them.
authencaon sequences.
User Specifies whether the Panorama: Yes Yes Yes Yes

Idenficaon administrator can configure
Device Group/
User-ID connecon security
Template: No
and view, add, edit, or delete
data redistribuon points (such
as User-ID agents).
can view sengs for User-
ID connecon security and
redistribuon points but can’t
manage the sengs.
or manage sengs for User-

Availability Only
ID connecon security or
redistribuon points.
Managed Specifies whether the Panorama: Yes Yes Yes Yes

Devices administrator can view, add,
Device Group/ (No
edit, or delete firewalls as
Template: Yes for
managed devices, and install
Device
soware or content updates on
Group
them.
and
If you set this privilege to read- Template
only, the administrator can roles)
see managed firewalls but
can’t add, delete, tag, or install
updates on them.
the administrator can’t view,
add, edit, tag, delete, or install
updates on managed firewalls.
An administrator
with Device
Deployment
privileges can sll
select Panorama
> Device
Deployment to
install updates on
managed firewalls.
Templates Specifies whether the Panorama: Yes Yes Yes Yes

administrator can view, edit,
Device Group/ (No
add, or delete templates and
Template: Yes for
template stacks.
Device
Group

Availability Only
If you set the privilege to Device and
read-only, the administrator Group Template
can see template and stack and admins)
configuraons but can’t Template
manage them. administrators
can see
only the
the administrator can’t see or
templates
manage template and stack
and
configuraons.
stacks
that are
within the
access
domains
assigned
to those
administrators.
Device Specifies whether the Panorama: Yes Yes Yes Yes

Groups administrator can view, edit,
Device Group/
add, or delete device groups.
Template: Yes
only, the administrator can see Device
device group configuraons but Group
can’t manage them. and
Template
administrators
can
or manage device group
access
configuraons.
only the
device
groups
that are
within the
access
domains
assigned
to those
administrators.
Managed Specifies whether the Panorama: Yes Yes Yes Yes

Collectors administrator can view, edit,
Device Group/
add, or delete managed
Template: No
collectors.

Availability Only
can see managed collector
configuraons but can’t
manage them.
edit, add, or delete managed
collector configuraons.
An administrator
with Device
Deployment
privileges can sll
use the Panorama
> Device
Deployment
opons to
install updates
on managed
collectors.
Collector Specifies whether the Panorama: Yes Yes Yes Yes

Groups administrator can view, edit,
Device Group/
add, or delete Collector
Template: No
Groups.
see Collector Groups but can’t
manage them.
manage Collector Groups.
VMware Specifies whether the Panorama: Yes Yes Yes Yes

Service administrator can view and
Device Group/
Manager edit VMware Service Manager
Template: No
sengs.
only, the administrator can see
the sengs but can’t perform
any related configuraon or
operaonal procedures.

Availability Only
the administrator can’t see the
sengs or perform any related
configuraon or operaonal
procedures.
Cerficate Sets the default state, Panorama: Yes Yes No Yes

Management enabled or disabled, for all
Device Group/
of the Panorama cerficate
Template: No
management privileges.
Cerficates Specifies whether the Panorama: Yes Yes Yes Yes

administrator can view, edit,
Device Group/
generate, delete, revoke, renew,
Template: No
or export cerficates. This
privilege also specifies whether
the administrator can import or
export HA keys.
Panorama cerficates but can’t
manage the cerficates or HA
keys.
manage Panorama cerficates
or HA keys.
Cerficate Specifies whether the Panorama: Yes Yes Yes Yes

Profile administrator can view, add,
Device Group/
edit, delete or clone Panorama
Template: No
cerficate profiles.
Panorama cerficate profiles
but can’t manage them.
manage Panorama cerficate
profiles.
SSL/TLS Specifies whether the Panorama: Yes Yes Yes Yes

Service administrator can view, add,
Device Group/
Profile edit, delete or clone SSL/TLS
Template: No
Service profiles.

Availability Only
SSL/TLS Service profiles but
can’t manage them.
or manage SSL/TLS Service
profiles.
Log Sets the default state, enabled Panorama: Yes Yes No Yes
Sengs or disabled, for all the log
Device Group/
seng privileges.
Template: No
System Specifies whether the Panorama: Yes Yes Yes Yes

administrator can see and
Device Group/
configure the sengs that
Template: No
control the forwarding of
System logs to external services
(syslog, email, SNMP trap, or
HTTP servers).
see the System log forwarding
sengs but can’t manage them.

Availability Only
This privilege
pertains only to
System logs that
Panorama and
Log Collectors
generate. The
Collector
Groups privilege
(Panorama
> Collector
Groups) controls
forwarding for
System logs that
Log Collectors
receive from
firewalls. The
Device > Log
Sengs >
System privilege
controls log
forwarding from
firewalls directly
to external
services (without
aggregaon on
Log Collectors).
Config Specifies whether the Panorama: Yes Yes Yes Yes

Device Group/
Template: No
Config logs to external services
HTTP servers).
see the Config log forwarding

Availability Only
This privilege
pertains only to
Config logs that
Panorama and
Log Collectors
generate. The
Collector
Groups privilege
(Panorama
> Collector
Groups) controls
forwarding for
Config logs that
Log Collectors
receive from
firewalls. The
Device > Log
Sengs >
Configuraon
privilege
controls log
forwarding from
firewalls directly
to external
services (without
aggregaon on
Log Collectors).
User-ID Specifies whether the Panorama: Yes Yes Yes Yes

Device Group/
Template: No
control the forwarding of User-
ID logs to external services
HTTP servers).
see the Config log forwarding

Availability Only
This privilege
pertains only
to User-ID logs
that Panorama
generates.
The Collector
Groups privilege
(Panorama
> Collector
Groups) controls
forwarding for
User-ID logs that
Log Collectors
receive from
firewalls. The
Device > Log
Sengs > User-
ID privilege
controls log
forwarding from
firewalls directly
to external
services (without
aggregaon on
Log Collectors).
HIP Match Specifies whether the Panorama: Yes Yes Yes Yes
Device Group/
Template: No
control the forwarding of HIP
Match logs from a Panorama
virtual appliance in Legacy
mode to external services
HTTP servers).
the forwarding sengs of HIP
Match logs but can’t manage
them.

Availability Only
The Collector
Groups privilege
(Panorama
> Collector
Groups) controls
forwarding for HIP
Match logs that
Log Collectors
receive from
firewalls. The
Device > Log
Sengs > HIP
Match privilege
controls log
forwarding from
firewalls directly
to external
services (without
aggregaon on
Log Collectors).
GlobalProtect Specifies whether the Panorama: Yes Yes Yes Yes

Device Group/
Template: No
GlobalProtect logs from a
Panorama virtual appliance
in Legacy mode to external
services (syslog, email, SNMP
trap, or HTTP servers).
see the forwarding sengs of
GlobalProtect logs but can’t
manage them.

Availability Only
The Collector
Groups privilege
(Panorama
> Collector
Groups) controls
forwarding for
GlobalProtect
logs that Log
Collectors receive
from firewalls.
The Device >
Log Sengs >
GlobalProtect
privilege
controls log
forwarding from
firewalls directly
to external
services (without
aggregaon on
Log Collectors).
Correlaon Specifies whether the Panorama: Yes Yes Yes Yes

Device Group/
Template: No
Correlaon logs from a
Panorama virtual appliance
in Legacy mode to external
services (syslog, email, SNMP
trap, or HTTP servers).
the Correlaon log forwarding

Availability Only
The Collector
Groups privilege
(Panorama
> Collector
Groups) controls
forwarding of
Correlaon
logs from a
Panorama M-
Series appliance or
Panorama virtual
appliance in
Panorama mode.
Traffic Specifies whether the Panorama: Yes Yes Yes Yes

Device Group/
Template: No
control the forwarding of Traffic
logs from a Panorama virtual
appliance in Legacy mode to
external services (syslog, email,
SNMP trap, or HTTP servers).
Traffic logs but can’t manage
them.

Availability Only
The Collector
Groups privilege
(Panorama
> Collector
Groups) controls
forwarding for
Traffic logs that
Log Collectors
receive from
firewalls. The
Log Forwarding
privilege (Objects
> Log Forwarding)
controls
forwarding from
firewalls directly
to external
services (without
aggregaon on
Log Collectors).
Threat Specifies whether the Panorama: Yes Yes Yes Yes

Device Group/
Template: No
Threat logs from a Panorama
HTTP servers).
Threat logs but can’t manage
them.

Availability Only
The Collector
Groups privilege
(Panorama
> Collector
Groups) controls
forwarding for
Threat logs that
Log Collectors
receive from
firewalls. The
Log Forwarding
privilege (Objects
> Log Forwarding)
controls
forwarding from
firewalls directly
to external
services (without
aggregaon on
Log Collectors).
WildFire Specifies whether the Panorama: Yes Yes Yes Yes

Device Group/
Template: No
WildFire logs from a Panorama
HTTP servers).
WildFire logs but can’t manage
them.

Availability Only
The Collector
Groups privilege
(Panorama >
Collector Groups)
controls the
forwarding for
WildFire logs that
Log Collectors
receive from
firewalls. The
Log Forwarding
privilege (Objects
> Log Forwarding)
controls
forwarding from
firewalls directly
to external
services (without
aggregaon on
Log Collectors).
Server Sets the default state, enabled Panorama: Yes Yes No Yes
Profiles or disabled, for all the server
Device Group/
profile privileges.
Template: No

Availability Only
These privileges
pertain only to
the server profiles
that are used for
forwarding logs
from Panorama or
Log Collectors and
the server profiles
that are used for
authencang
Panorama
administrators.
The Device >
Server Profiles
privileges control
access to the
server profiles
that are used
for forwarding
logs directly
from firewalls
to external
services and for
authencang
firewall
administrators.
SNMP Trap Specifies whether the Panorama: Yes Yes Yes Yes
Device Group/
configure SNMP trap server
Template: No
profiles.
SNMP trap server profiles but
or manage SNMP trap server
profiles.
Syslog Specifies whether the Panorama: Yes Yes Yes Yes

Device Group/
configure Syslog server profiles.
Template: No

Availability Only
Syslog server profiles but can’t
manage them.
manage Syslog server profiles.
Email Specifies whether the Panorama: Yes Yes Yes Yes

Device Group/
configure email server profiles.
Template: No
email server profiles but can’t
manage them.
manage email server profiles.
RADIUS Specifies whether the Panorama: Yes Yes Yes Yes

Device Group/
configure the RADIUS server
Template: No
profiles that are used to
authencate Panorama
administrators.
the RADIUS server profiles but
manage the RADIUS server
profiles.
TACACS+ Specifies whether the Panorama: Yes Yes Yes Yes

Device Group/
configure the TACACS+
Template: No
server profiles that are used
to authencate Panorama
administrators.
the node or configure sengs
for the TACACS+ servers
that authencaon profiles
reference.

Availability Only
view exisng TACACS+ server
profiles but can’t add or edit
them.
LDAP Specifies whether the Panorama: Yes Yes Yes Yes

Device Group/
configure the LDAP server
Template: No
profiles that are used to
authencate Panorama
administrators.
the LDAP server profiles but
or manage the LDAP server
profiles.
Kerberos Specifies whether the Panorama: Yes Yes Yes Yes

Device Group/
configure the Kerberos
Template: No
server profiles that are used
to authencate Panorama
administrators.
the Kerberos server profiles but
manage the Kerberos server
profiles.
SAML Specifies whether the Panorama: Yes Yes Yes Yes

Identy administrator can see and
Device Group/
Provider configure the SAML Identy
Template: No
Provider (IdP) server profiles
that are used to authencate

Availability Only
the SAML IdP server profiles
but can’t manage them.
manage the SAML IdP server
profiles.
Scheduled Specifies whether the Panorama: Yes Yes No Yes

Config administrator can view, add,
Device Group/
Export edit, delete, or clone scheduled
Template: No
Panorama configuraon
exports.
view the scheduled exports but
manage the scheduled exports.
Soware Specifies whether the Panorama: Yes Yes Yes Yes

administrator can: view
Device Group/
informaon about soware
Template: No
updates installed on the
Panorama management server;
download, upload, or install
the updates; and view the
associated release notes.
can view informaon about
Panorama soware updates
and view the associated release
notes but can’t perform any
related operaons.
Panorama soware updates,
see the associated release
notes, or perform any related
operaons.

Availability Only
The Panorama
> Device
Deployment
> Soware
privilege controls
access to PAN-OS
soware deployed
on firewalls
and Panorama
soware deployed
on Dedicated Log
Collectors.
Dynamic Specifies whether the Panorama: Yes Yes Yes Yes

Updates administrator can: view
Device Group/
informaon about content
Template: No
updates installed on the
Panorama management server
(for example, WildFire updates);
download, upload, install, or
revert the updates; and view
the associated release notes.
can view informaon about
Panorama content updates and
view the associated release
notes but can’t perform any
related operaons.
Panorama content updates, see
the associated release notes, or
perform any related operaons.

Availability Only
The Panorama
> Device
Deployment
> Dynamic
Updates privilege
controls access to
content updates
deployed on
firewalls and
Dedicated Log
Collectors.
Support Specifies whether the Panorama: Yes Yes Yes Yes

Device Group/
Panorama support license
Template: No
informaon, product alerts,
and security alerts; acvate a
support license, and manage
cases. Only a superuser admin
can generate Tech Support
files.
can view Panorama support
informaon, product alerts,
and security alerts, but can’t
acvate a support license,
generate Tech Support files, or
manage cases.
the administrator can’t: see
Panorama support informaon,
product alerts, or security
alerts; acvate a support
license, generate Tech Support
files, or manage cases.
Device Sets the default state, enabled Panorama: Yes Yes No Yes
Deployment or disabled, for all the privileges
Device Group/
associated with deploying
Template: Yes
licenses and soware or
content updates to firewalls
and Log Collectors.

Availability Only
The Panorama
> Soware
and Panorama
> Dynamic
Updates privileges
control the
soware and
content updates
installed on
a Panorama
management
server.
Soware Specifies whether the Panorama: Yes Yes Yes Yes

Device Group/
informaon about the soware
Template: Yes
updates installed on firewalls
and Log Collectors; download,
upload, or install the updates;
notes.
see informaon about the
soware updates and view
the associated release notes
but can’t deploy the updates
to firewalls or dedicated Log
Collectors.
informaon about the soware
updates, see the associated
release notes, or deploy
the updates to firewalls or
Dedicated Log Collectors.
GlobalProtect Specifies whether the Panorama: Yes Yes Yes Yes

Client administrator can: view
Device Group/
informaon about
Template: Yes
GlobalProtect app soware
updates on firewalls; download,
upload, or acvate the updates;
notes.

Availability Only
can see informaon about
updates and view the
associated release notes but
can’t acvate the updates on
firewalls.
see informaon about
release notes, or acvate the
updates on firewalls.
Dynamic Specifies whether the Panorama: Yes Yes Yes Yes

Updates administrator can: view
Device Group/
informaon about the
Template: Yes
content updates (for example,
Applicaons updates) installed
on firewalls and Dedicated Log
Collectors; download, upload,
or install the updates; and view
the associated release notes.
see informaon about the
content updates and view
the associated release notes
but can’t deploy the updates
to firewalls or Dedicated Log
Collectors.
informaon about the content
release notes, or deploy
the updates to firewalls or
Licenses Specifies whether the Panorama: Yes Yes Yes Yes

administrator can view, refresh,
Device Group/
and acvate firewall licenses.
Template: Yes

Availability Only
can view firewall licenses but
can’t refresh or acvate those
licenses.
refresh, or acvate firewall
licenses.
Master Specifies whether the Panorama: Yes Yes Yes Yes

Key and administrator can view and
Device Group/
Diagnoscs configure a master key by
Template: No
which to encrypt private keys
on Panorama.
view the Panorama master key
configuraon but can’t change
it.
edit the Panorama master key
configuraon.
Provide Granular Access to Operaons Sengs

To define which operaons sengs an administrator has access to, when creang or eding an
admin role profile for a firewall (Device > Admin Roles), scroll down to the Operaons opon on
the Web UI tab.

Only
Reboot Restart the firewall. The firewall logs out Yes N/A Yes
all users, reloads the PAN-OS soware
and acve configuraon, closes and logs
exisng sessions, and creates a system
log entry that shows the name of the
administrator that iniated the reboot.
Generate Tech Generate a tech support system file that Yes N/A Yes
Support File the Palo Alto Networks support team can

Only
use to troubleshoot issues that you may
be experiencing with the firewall.
Generate Stats Generate and download a set of XML Yes N/A Yes
Dump File reports that summarizes network traffic
over the last seven days for the firewall.
Download Core If the firewall experiences a system Yes N/A Yes

Files process failure, a core file is automacally
generated that contains details about
the process and why it failed. You can
download this core file to upload to your
Palo Alto Networks support case to obtain
further assistance in resolving the issue.
Panorama Web Interface Access Privileges

The custom Panorama administrator roles allow you to define access to the opons on Panorama
and the ability to only allow access to Device Groups and Templates (Policies, Objects, Network,
Device tabs).
The administrator roles you can create are Panorama and Device Group and Template. You can’t
assign CLI access privileges to a Device Group and Template Admin Role profile. If you assign
superuser privileges for the CLI to a Panorama Admin Role profile, administrators with that role
can access all features regardless of the web interface privileges you assign.

Only
Dashboard Controls access to the Dashboard Yes No Yes

administrator will not see the tab and will
not have access to any of the Dashboard
widgets.
ACC Controls access to the Applicaon Yes No Yes

Command Center (ACC). If you disable
this privilege, the ACC tab will not display
in the web interface. Keep in mind that if
you want to protect the privacy of your
users while sll providing access to the
ACC, you can disable the Privacy > Show
Full IP Addresses opon and/or the Show
User Names In Logs And Reports opon.

Only
Monitor Controls access to the Monitor tab. If you Yes No Yes

will not see the Monitor tab and will not
have access to any of the logs, packet
captures, session informaon, reports or
to App Scope. For more granular control
over what monitoring informaon the
administrator can see, leave the Monitor
Provide Granular Access to the Monitor
Tab.
Policies Controls access to the Policies tab. If you Yes No Yes

will not see the Policies tab and will not
have access to any policy informaon. For
more granular control over what policy
informaon the administrator can see,
for example to enable access to a specific
type of policy or to enable read-only
access to policy informaon, leave the
Policies opon enabled and then enable
the Policy Tab.
Objects Controls access to the Objects tab. If you Yes No Yes

not see the Objects tab and will not have
access to any objects, security profiles, log
forwarding profiles, decrypon profiles, or
schedules. For more granular control over
what objects the administrator can see,
leave the Objects opon enabled and then
the Objects Tab.
Network Controls access to the Network tab. If you Yes No Yes

will not see the Network tab and will
not have access to any interface, zone,
VLAN, virtual wire, virtual router, IPsec
tunnel, DHCP, DNS Proxy, GlobalProtect,
or QoS configuraon informaon

Only
or to the network profiles. For more
administrator can see, leave the Network
Provide Granular Access to the Network
Tab.
Device Controls access to the Device tab. If you Yes No Yes

not see the Device tab and will not have
access to any firewall-wide configuraon
informaon, such as User-ID, High
Availability, server profile or cerficate
configuraon informaon. For more
administrator can see, leave the Device
Provide Granular Access to the Device
Tab.
You can’t enable access

to the Admin Roles or
Administrators nodes for a
role-based administrator even
if you enable full access to the
Device tab.
Panorama Controls access to the Panorama Yes No Yes

administrator will not see the Panorama
tab and will not have access to any
Panorama-wide configuraon informaon,
such as Managed Devices, Managed
Collectors, or Collector Groups.
For more granular control over what
objects the administrator can see, leave
the Panorama opon enabled and then
the Panorama Tab.

Only
Privacy Controls access to the privacy sengs Yes No Yes

described in Define User Privacy Sengs
in the Admin Role Profile.
Validate When disabled, an administrator cannot Yes No Yes

validate a configuraon.
Save Sets the default state (enabled or disabled) Yes No Yes

for all the save privileges described below
(Paral Save and Save For Other Admins).
• Paral Save When disabled, an administrator cannot Yes No Yes

save changes that any administrator made
to the Panorama configuraon.
• Save For When disabled, an administrator cannot Yes No Yes

Other Admins save changes that other administrators
made to the Panorama configuraon.
Commit Sets the default state (enabled or disabled) Yes No Yes

for all the commit, push, and revert
privileges described below (Panorama,
Device Groups, Templates, Force Template
Values, Collector Groups, WildFire
Appliance Clusters).
• Panorama When disabled, an administrator cannot Yes No Yes

commit or revert configuraon changes
that any administrators made, including
his or her own changes.
• Commit for When disabled, an administrator cannot Yes No Yes

Other Admins commit or revert configuraon changes
that other administrators made.
Device Groups When disabled, an administrator cannot Yes No Yes

push changes to device groups.
Templates When disabled, an administrator cannot Yes No Yes

push changes to templates.
Force Template This privilege controls access to the Force Yes No Yes
Values Template Values opon in the Push Scope
Selecon dialog.

Only
When disabled, an administrator cannot
replace overridden sengs in local
firewall configuraons with sengs that
Panorama pushes from a template.
If you push a configuraon

with Force Template Values
enabled, all overridden
values on the firewall are
replaced with values from the
template. Before you use this
opon, check for overridden
values on the firewalls to
ensure your commit does
not result in any unexpected
network outages or issues
caused by replacing those
overridden values.
Collector Groups When disabled, an administrator cannot Yes No Yes

push changes to Collector Groups.
WildFire When disabled, an administrator cannot Yes No Yes

Appliance push changes to WildFire appliance
Clusters clusters.
Tasks When disabled, an administrator cannot Yes No Yes

access the Task Manager.
Global Controls access to the global sengs Yes No Yes

(system alarms) described in Provide
Granular Access to Global Sengs.
Reference: Port Number Usage

The following tables list the ports that firewalls and Panorama use to communicate with each
other, or with other services on the network.
• Ports Used for Management Funcons
• Ports Used for HA
• Ports Used for Panorama
• Ports Used for GlobalProtect
• Ports Used for User-ID
• Ports Used for IPSec
• Ports Used for Roung
• Ports Used for DHCP
• Ports Used for Infrastructure
Ports Used for Management Funcons

The firewall and Panorama use the following ports for management funcons.
Desnaon Protocol Descripon

Port
22 TCP Used for communicaon from a client system to the firewall CLI
interface.
80 TCP The port the firewall listens on for Online Cerficate Status
Protocol (OCSP) updates when acng as an OCSP responder.
123 UDP Port the firewall uses for NTP updates.
443 TCP Used for communicaon from a client system to the firewall web
interface. This is also the port the firewall and User-ID agent
listens on for updates when you Enable VM Monitoring to Track
Changes on the Virtual Network.
For monitoring an AWS environment, this is the only port that is
used.
For monitoring a VMware vCenter/ESXi environment, the
listening port defaults to 443, but it is configurable.
4443 TCP Used as an alternave SSL port for HTTPS.
162 UDP Port the firewall, Panorama, or a Log Collector uses to Forward
Traps to an SNMP Manager.

Port
This port doesn’t need to be open on the Palo
Alto Networks firewall. You must configure the
Simple Network Management Protocol (SNMP)
manager to listen on this port. For details, refer to the
documentaon of your SNMP management soware.
161 UDP Port the firewall listens on for polling requests (GET messages)
from the SNMP manager.
514 TCP Port that the firewall, Panorama, or a Log Collector uses to
send logs to a syslog server if you Configure Syslog Monitoring,
514 UDP
and the ports that the PAN-OS integrated User-ID agent or
6514 SSL Windows-based User-ID agent listens on for authencaon
syslog messages.
2055 UDP Default port the firewall uses to send NetFlow records to a
NetFlow collector if you Configure NetFlow Exports, but this is
configurable.
5008 TCP Port the GlobalProtect Mobile Security Manager listens on for HIP
requests from the GlobalProtect gateways.
If you are using a third-party MDM system, you can configure the
gateway to use a different port as required by the MDM vendor.
6080 TCP Ports used for User-ID™ Authencaon Portal:

6081 TLS 1.2 • 6080 for NT LAN Manager (NTLM) authencaon
6082 TCP • 6081 for Authencaon Portal without an SSL/TLS Server
Profile
• 6082 for Authencaon Portal with an SSL/TLS Server Profile
10443 SSL Port that the firewall and Panorama use to provide contextual
informaon about a threat or to seamlessly shi your threat
invesgaon to the Threat Vault and AutoFocus.
Ports Used for HA

Firewalls configured as High Availability (HA) peers must be able to communicate with each other
to maintain state informaon (HA1 control link) and synchronize data (HA2 data link). In Acve/
Acve HA deployments the peer firewalls must also forward packets to the HA peer that owns the
session. The HA3 link is a Layer 2 (MAC-in-MAC) link and it does not support Layer 3 addressing
or encrypon.

Port
28769 TCP Used for the HA1 control link for clear text communicaon
between the HA peer firewalls. The HA1 link is a Layer 3 link and
28260 TCP
requires an IP address.
28 TCP Used for the HA1 control link for encrypted communicaon (SSH
over TCP) between the HA peer firewalls.
28770 TCP Listening port for HA1 backup links.
28771 TCP Used for heartbeat backups. Palo Alto Networks recommends
enabling heartbeat backup on the MGT interface if you use an in-
band port for the HA1 or the HA1 backup links.
99 IP Used for the HA2 link to synchronize sessions, forwarding tables,

IPSec security associaons and ARP tables between firewalls in
29281 UDP
an HA pair. Data flow on the HA2 link is always unidireconal
(except for the HA2 keep-alive); it flows from the acve firewall
(Acve/Passive) or acve-primary (Acve/Acve) to the passive
firewall (Acve/Passive) or acve-secondary (Acve/Acve).
The HA2 link is a Layer 2 link, and it uses ether type 0x7261 by
default.
The HA data link can also be configured to use either IP (protocol
number 99) or UDP (port 29281) as the transport, and thereby
allow the HA data link to span subnets.
Ports Used for Panorama

Panorama uses the following ports.

Port
22 TCP Used for communicaon from a client system to the

Panorama CLI interface.
443 TCP Used for communicaon from a client system to the

Panorama web interface.
444 TCP Used for communicaon between Panorama and Cortex

Data Lake.
3978 TCP Used for communicaon between Panorama and

managed firewalls or managed collectors, as well as for

Port
communicaon among managed collectors in a Collector
Group:
• For communicaon between Panorama and firewalls.
This connecon is iniated from the managed firewall to
Panorama and facilitates a bi-direconal data exchange
on which the firewalls forward logs to Panorama and
Panorama pushes configuraon changes to the firewalls.
Context switching commands are sent over the same
connecon.
• Log Collectors use this desnaon port to forward logs
to Panorama.
• For communicaon with the default Log Collector on
an M-Series appliance in Panorama mode and with
28443 TCP Used for managed devices (firewalls and Log Collectors) to
retrieve soware and content updates from Panorama.
Only devices that run PAN-OS 8.x and later

releases retrieve updates from Panorama over
this port. For devices running earlier releases,
Panorama pushes the update packages over
port 3978.
28769 (5.1 TCP Used for the HA connecvity and synchronizaon between
and later) Panorama HA peers using clear text communicaon.
TCP
Communicaon can be iniated by either peer.
28260 (5.0
TCP
and later)
49160 (5.0
and earlier)
28 TCP Used for the HA connecvity and synchronizaon between

Panorama HA peers using encrypted communicaon (SSH
over TCP). Communicaon can be iniated by either peer.
Used for communicaon between Log Collectors in a
Collector Group for log distribuon.
28270 (6.0 TCP Used for communicaon among Log Collectors in a

and later) Collector Group for log distribuon.
49190 (5.1
and earlier)

Port
2049 TCP Used by the Panorama virtual appliance to write logs to the
NFS datastore.
10443 SSL Port that Panorama uses to provide contextual informaon

about a threat or to seamlessly shi your threat
invesgaon to the Threat Vault and AutoFocus.
23000 to TCP, UDP, or Used for Syslog communicaon between Panorama and
23999 SSL the Traps ESM components.
Ports Used for GlobalProtect

GlobalProtect uses the following ports.
Desnaon Port Protocol Descripon
443 TCP Used for communicaon between GlobalProtect apps and

portals, or GlobalProtect apps and gateways and for SSL tunnel
connecons.
GlobalProtect gateways also use this port to collect host
informaon from GlobalProtect apps and perform host
informaon profile (HIP) checks.
4501 UDP Used for IPSec tunnel connecons between GlobalProtect apps
and gateways.
For ps on how to use a loopback interface to provide access to GlobalProtect on different ports
and addresses, refer to Can GlobalProtect Portal Page be Configured tobe Accessed on any Port?
Ports Used for User-ID

User-ID is a feature that enables mapping of user IP addresses to usernames and group
memberships, enabling user- or group-based policy and visibility into user acvity on your
network (for example, to be able to quickly track down a user who may be the vicm of a threat).
To perform this mapping, the firewall, the User-ID agent (either installed on a Windows-based
system or the PAN-OS integrated agent running on the firewall), and/or the Terminal Server agent
must be able to connect to directory services on your network to perform Group Mapping and
User Mapping. Addionally, if the agents are running on systems external to the firewall, they
must be able to connect to the firewall to communicate the IP address to username mappings to
the firewall. The following table lists the communicaon requirements for User-ID along with the
port numbers required to establish connecons.

Port
389 TCP Port the firewall uses to connect to an LDAP server (plaintext or
Start Transport Layer Security (Start TLS) to Map Users to Groups.
3268 TCP Port the firewall uses to connect to an Acve Directory global
catalog server (plaintext or Start TLS) to Map Users to Groups.
636 TCP Port the firewall uses for LDAP over SSL connecons with an
LDAP server to Map Users to Groups.
3269 TCP Port the firewall uses for LDAP over SSL connecons with an
Acve Directory global catalog server to Map Users to Groups.
514 TCP Port the User-ID agent listens on for authencaon syslog
messages if you Configure User-ID to Monitor Syslog Senders
6514 UDP
for User Mapping. The port depends on the type of agent and
SSL protocol:
• PAN-OS integrated User-ID agent—Port 6514 for SSL and port
514 for UDP.
• Windows-based User-ID agent—Port 514 for both TCP and
UDP.
5007 TCP Port the firewall listens on for user mapping informaon from
the User-ID or Terminal Server agent. The agent sends the IP
address and username mapping along with a mestamp whenever
it learns of a new or updated mapping. In addion, it connects to
the firewall at regular intervals to refresh known mappings.
5006 TCP Port the User-ID agent listens on for XML API requests. The
source for this communicaon is typically the system running a
script that invokes the API.
88 UDP/TCP Port the User-ID agent uses to authencate to a Kerberos server.

The firewall tries UDP first and falls back to TCP.
1812 UDP Port the User-ID agent uses to authencate to a RADIUS server.
49 TCP Port the User-ID agent uses to authencate to a TACACS+ server.
135 TCP Port the User-ID agent uses to establish TCP-based WMI
connecons with the Microso Remote Procedure Call (RPC)
Endpoint Mapper. The Endpoint Mapper then assigns the agent
a randomly assigned port in the 49152-65535 port range. The
agent uses this connecon to make RPC queries for Exchange
Server or AD server security logs, session tables. This is also the
port used to access Terminal Servers.

Port
The User-ID agent also uses this port to connect to client systems
to perform Windows Management Instrumentaon (WMI)
probing.
139 TCP Port the User-ID agent uses to establish TCP-based NetBIOS
connecons to the AD server so that it can send RPC queries for
security logs and session informaon.
The User-ID agent also uses this port to connect to client systems
for NetBIOS probing (supported on the Windows-based User-ID
agent only).
445 TCP Port the User-ID agent uses to connect to the Acve Directory
(AD) using TCP-based SMB connecons to the AD server for
access to user logon informaon (print spooler and Net Logon).
5985 HTTP Port the User-ID agent uses to monitor security logs and session
informaon with the WinRM protocol over HTTP.
5986 HTTPS Port the User-ID agent uses to monitor security logs and session
informaon with the WinRM protocol over HTTPS.
5009 TCP Port the firewall uses to connect to the Terminal Server Agent.
Ports Used for IPSec

The firewall and Panorama use the following ports for IPSec funcons.

Port
500 UDP Port used by IKE on the management plane to connect with
remote IKE peers.
4500 UDP Port used by IKE on the management plane to connect with
remote IKE peers.
4510 UDP Port used by the dataplane to send requests to IKE.
4511 UDP Port used by the dataplane to send requests to keymgr.
Ports Used for Roung

The firewall and Panorama use the following ports for roung funcons.

Port
179 TCP Port used by BGP to connect to peers.
3784 UDP Ports used by BGP to connect to peers.

3785
4784
520 UDP Port used for RIPv2.
89 IP Port used for OSPF.
103 IP Port used for Protocol Independent Mulcast (PIM).
Ports Used for DHCP

The firewall and Panorama use the following ports for DHCP funcons.

Port
67 UDP Ports used as DHCP server listening ports.

68
546
547
Ports Used for Infrastructure

The firewall and Panorama use the following ports for infrastructure funcons.

Port
111 TCP/UDP Port used as a port mapper.
23 TCP/UDP Port used for the Telnet applicaon protocol.
69 TCP/UDP Port used for TFTP.
2049 TCP/UDP Port used for the Network File System (NFS).

Port
28260 TCP Port used by internal sysd IPC communicaon for internal
processes.
28261 TCP Port used by internal masterd applicaons to manage internal

processes.
Reset the Firewall to Factory Default Sengs

Reseng the firewall to factory defaults will result in the loss of all configuraon sengs and logs.
STEP 1 | Set up a console connecon to the firewall.
1. Connect a serial cable from your computer to the Console port and connect to the
firewall using terminal emulaon soware (9600-8-N-1).
If your computer does not have a 9-pin serial port, use a USB-to-serial port
connector.
2. Enter your login credenals.
3. Enter the following CLI command:
debug system maintenance-mode
The firewall will reboot in the maintenance mode.
STEP 2 | Reset the system to factory default sengs.

1. When the firewall reboots, press Enter to connue to the maintenance mode menu.
2. Select Factory Reset and press Enter.
3. Select Factory Reset and press Enter again.
The firewall will reboot without any configuraon sengs. The default username and
password to log in to the firewall is admin/admin.
To perform inial configuraon on the firewall and to set up network connecvity, see
Integrate the Firewall into Your Management Network.
Bootstrap the Firewall

Bootstrapping speeds up the process of configuring and licensing the firewall to make it
operaonal on the network with or without Internet access. Bootstrapping allows you to choose
whether to configure the firewall with a basic configuraon file (init-cfg.txt) so that it can connect
to Panorama and obtain the complete configuraon or to fully configure the firewall with the basic
configuraon and the oponal bootstrap.xml file.
• USB Flash Drive Support
• Sample init-cfg.txt Files
• Prepare a USB Flash Drive for Bootstrapping a Firewall
• Bootstrap a Firewall Using a USB Flash Drive
USB Flash Drive Support

The USB flash drive that bootstraps a hardware-based Palo Alto Networks firewall must support
one of the following:
• File Allocaon Table 32 (FAT32)
• Third Extended File System (ext3)
The firewall can bootstrap from the following flash drives with USB2.0 or USB3.0 connecvity:
Supported USB Flash Drives
Kingston
• Kingston SE9 8GB (2.0)
SanDisk
• SanDisk Cruzer Fit CZ33 8GB (2.0)
• SanDisk Cruzer Fit CZ33 16GB (2.0)
• SanDisk Cruzer CZ36 16GB (2.0)
• SanDisk Cruzer CZ36 32GB (2.0)
• SanDisk Extreme CZ80 32GB (3.0)
Silicon Power
• Silicon Power Jewel 32GB (3.0)
• Silicon Power Blaze 16GB (3.0)
PNY
• PNY Aache 16GB (2.0)
Supported USB Flash Drives

• PNY Turbo 32GB (3.0)
Sample init-cfg.txt Files

An init-cfg.txt file is required for the bootstrap process; this file is a basic configuraon file that
you create using a text editor. To create this file, see 5 The following sample init-cfg.txt files show
the parameters that are supported in the file; the parameters that you must provide are in bold.
Sample init-cfg.txt (Stac IP Address) Sample init-cfg.txt (DHCP Client)
type=static type=dhcp-client
ip-address=10.5.107.19 ip-address=
default-gateway=10.5.107.1 default-gateway=
netmask=255.255.255.0 netmask=
ipv6-address=2001:400:f00::1/64 ipv6-address=
ipv6-default- ipv6-default-gateway=
gateway=2001:400:f00::2 hostname=Ca-FW-DC1
hostname=Ca-FW-DC1 panorama-server=10.5.107.20
panorama-server=10.5.107.20 panorama-server-2=10.5.107.21
panorama-server-2=10.5.107.21 tplname=FINANCE_TG4
tplname=FINANCE_TG4 dgname=finance_dg
dgname=finance_dg dns-primary=10.5.6.6
dns-primary=10.5.6.6 dns-secondary=10.5.6.7
dns-secondary=10.5.6.7 op-command-modes=multi-
op-command-modes=multi- vsys,jumbo-frame
vsys,jumbo-frame dhcp-send-hostname=yes
dhcp-send-hostname=no dhcp-send-client-id=yes
dhcp-send-client-id=no dhcp-accept-server-
dhcp-accept-server-hostname=no hostname=yes
dhcp-accept-server-domain=no dhcp-accept-server-domain=yes
The following table describes the fields in the init-cfg.txt file. The type is required; if the type is
stac, the IP address, default gateway and netmask are required, or the IPv6 address and IPv6
default gateway are required.
Field Descripon
type (Required) Type of management IP address: stac or dhcp-client.
ip-address (Required for IPv4 stac management address) IPv4 address. The
firewall ignores this field if the type is dhcp-client.
default-gateway (Required for IPv4 stac management address) IPv4 default

gateway for the management interface. The firewall ignores this
field if the type is dhcp-client.
Field Descripon
netmask (Required for IPv4 stac management address) IPv4 netmask. The
firewall ignores this field if the type is dhcp-client.
ipv6-address (Required for IPv6 stac management address) IPv6 address and /
prefix length of the management interface. The firewall ignores this
ipv6-default-gateway (Required for IPv6 stac management address) IPv6 default

gateway for the management interface. The firewall ignores this
hostname (Oponal) Host name for the firewall.
panorama-server (Recommended) IPv4 or IPv6 address of the primary Panorama

server.
panorama-server-2 (Oponal) IPv4 or IPv6 address of the secondary Panorama server.
tplname (Recommended) Panorama template name.
dgname (Recommended) Panorama device group name.
dns-primary (Oponal) IPv4 or IPv6 address of the primary DNS server.
dns-secondary (Oponal) IPv4 or IPv6 address of the secondary DNS server.
vm-auth-key (VM-Series firewalls only) Virtual machine authencaon key.
op-command-modes (Oponal) Enter mul-vsys, jumbo-frame, or both separated by a

comma only. Enables mulple virtual systems and jumbo frames
while bootstrapping.
dhcp-send-hostname (DHCP client type only) The DHCP server determines a value of yes
or no. If yes, the firewall sends its hostname to the DHCP server.
dhcp-send-client-id (DHCP client type only) The DHCP server determines a value of yes
or no. If yes, the firewall sends its client ID to the DHCP server.
dhcp-accept-server- (DHCP client type only) The DHCP server determines a value of
hostname yes or no. If yes, the firewall accepts its hostname from the DHCP
server.
dhcp-accept-server- (DHCP client type only) The DHCP server determines a value of
domain yes or no. If yes, the firewall accepts its DNS server from the DHCP
server.
Prepare a USB Flash Drive for Bootstrapping a Firewall

You can use a USB flash drive to bootstrap a physical firewall. However, to do so you must be
running a PAN-OS 7.1.0 or later image and Reset the Firewall to Factory Default Sengs. For
security reasons, you can bootstrap a firewall only when it is in factory default state or has all
private data deleted.
STEP 1 | Obtain serial numbers (S/Ns) and auth codes for support subscripons from your order
fulfillment email.
STEP 2 | Register S/Ns of new firewalls on the Customer Support portal.

1. Go to support.paloaltonetworks.com, log in, and select Assets > Devices > Register New
Device > Register device using Serial Number or Authorizaon Code.
2. Follow the steps to Register the Firewall.
3. Click Submit.
STEP 3 | Acvate authorizaon codes on the Customer Support portal, which creates license keys.
1. Go to support.paloaltonetworks.com, log in, and select the Assets > Devices on the le-
hand navigaon pane.
2. For each device S/N you just registered, click the Acon link (the pencil icon).
3. Under Acvate Licenses, select Acvate Auth-Code.
4. Enter the Authorizaon code and click Agree and Submit.
STEP 4 | Add the S/Ns in Panorama.

Complete Step 1 in Add a Firewall as a Managed Device in the Panorama Administrator’s
Guide.
STEP 5 | Create the init-cfg.txt file.

Create the init-cfg.txt file, a mandatory file that provides bootstrap parameters. The fields are
described in Sample init-cfg.txt Files.
If the init-cfg.txt file is missing, the bootstrap process will fail and the firewall will boot
up with the default configuraon in the normal boot-up sequence.
There are no spaces between the key and value in each field; do not add spaces because they
cause failures during parsing on the management server side.
You can have mulple init-cfg.txt files—one each for different remote sites—by prepending the
S/N to the file name. For example:
0008C200105-init-cfg.txt
0008C200107-init-cfg.txt
If no prepended filename is present, the firewall uses the init-cfg.txt file and proceeds with
bootstrapping.
STEP 6 | (Oponal) Create the bootstrap.xml file.

The oponal bootstrap.xml file is a complete firewall configuraon that you can export from an
exisng producon firewall.
1. Select Device > Setup > Operaons > Export named configuraon snapshot.
2. Select the Name of the saved or the running configuraon.
3. Click OK.
4. Rename the file as bootstrap.xml.
STEP 7 | Create and download the bootstrap bundle from the Customer Support portal.
For a physical firewall, the bootstrap bundle requires only the /license and /config directories.
Use one of the following methods to create and download the bootstrap bundle:
• Use Method 1 to create a bootstrap bundle specific to a remote site (you have only one init-
cfg.txt file).
• Use Method 2 to create one bootstrap bundle for mulple sites.
Method 1
1. On your local system, go to support.paloaltonetworks.com and log in.
2. Select Assets.
3. Select the S/N of the firewall you want to bootstrap.
4. Select Bootstrap Container.
5. Click Select.
6. Upload and Open the init-cfg.txt file you created.
7. (Oponal) Select the bootstrap.xml file you created and Upload Files.
You must use a bootstrap.xml file from a firewall of the same model and PAN-OS
version.
8. Select Bootstrap Container Download to download a tar.gz file named bootstrap_<S/
N>_<date>.tar.gz to your local system. This bootstrap container includes the license
keys associated with the S/N of the firewall.
Method 2
Create a tar.gz file on your local system with two top-level directories: /license and /config.
Include all licenses and all init-cfg.txt files with S/Ns prepended to the filenames.
The license key files you download from the Customer Support portal have the S/N in the
license file name. PAN-OS checks the S/N in the file name against the firewall S/N while
execung the bootstrap process.
STEP 8 | Import the tar.gz file you created (to a firewall running a PAN-OS 7.1.0 or later image) using
Secure Copy (SCP) or TFTP.
Access the CLI and enter one of the following commands:
• tftp import bootstrap-bundle file <path and filename> from <host IP
address>
For example:
tftp import bootstrap-bundle file /home/userx/bootstrap/devices/
pa5000.tar.gz from 10.1.2.3
• scp import bootstrap-bundle from <<user>@<host>:<path to file>>
For example:
scp import bootstrap-bundle from [email protected]:/home/userx/
bootstrap/devices/pa200_bootstrap_bundle.tar.gz
STEP 9 | Prepare the USB flash drive.

1. Insert the USB flash drive into the firewall that you used in the prior step.
2. Enter the following CLI operaonal command, using your tar.gz filename in place of
“pa5000.tar.gz”. This command formats the USB flash drive, unzips the file, and
validates the USB flash drive:
request system bootstrap-usb prepare from pa5000.tar.gz
3. Press y to connue. The following message displays when the USB drive is ready:
USB prepare completed successfully.
4. Remove the USB flash drive from the firewall.
5. You can prepare as many USB flash drives as needed.
STEP 10 | Deliver the USB flash drive to your remote site.

If you used Method 2 to create the bootstrap bundle, you can use the same USB flash drive
content for bootstrapping firewalls at mulple remote sites. You can translate the content into
mulple USB flash drives or a single USB flash drive used mulple mes.
Bootstrap a Firewall Using a USB Flash Drive

Aer you receive a new Palo Alto Networks firewall and a USB flash drive loaded with bootstrap
files, you can bootstrap the firewall.
Microso Windows and Apple Mac operang systems are unable to read the bootstrap
USB flash drive because the drive is formaed using an ext4 file system. You must install
third-party soware or use a Linux system to read the USB drive.
STEP 1 | The firewall must be in a factory default state or must have all private data deleted.
STEP 2 | To ensure connecvity with your corporate headquarters, cable the firewall by connecng
the management interface (MGT) using an Ethernet cable to one of the following:
• An upstream modem
• A port on the switch or router
• An Ethernet jack in the wall
STEP 3 | Insert the USB flash drive into the USB port on the firewall and power on the firewall. The
factory default firewall bootstraps itself from the USB flash drive.
The firewall Status light turns from yellow to green when the firewall is configured; autocommit
is successful.
STEP 4 | Verify bootstrap compleon. You can see basic status logs on the console during the
bootstrap and you can verify that the process is complete.
1. If you included Panorama values (panorama-server, tplname, and dgname) in your init-
cfg.txt file, check Panorama managed devices, device group, and template name.
2. Verify the general system sengs and configuraon by accessing the web interface and
selecng Dashboard > Widgets > System or by using the CLI operaonal commands
show system info and show config running.
3. Verify the license installaon by selecng Device > Licenses or by using the CLI
operaonal command request license info.
4. If you have Panorama configured, manage the content versions and soware versions
from Panorama. If you do not have Panorama configured, use the web interface to
manage content versions and soware versions.
Device Telemetry
Device telemetry collects data about your next-generaon firewall or Panorama, and
shares it with Palo Alto Networks by uploading the data to Cortex Data Lake. This data
is used to power telemetry apps, and for sharing threat intelligence.
> Device Telemetry Overview

> Device Telemetry Collecon and Transmission Intervals
> Manage Device Telemetry
> Monitor Device Telemetry
> Sample the Data that Device Telemetry Collects
209
Device Telemetry
Device Telemetry Overview

Device telemetry collects data about your next-generaon firewall or Panorama and shares it
with Palo Alto Networks by uploading the data to Cortex Data Lake. This data is used to power
telemetry apps, which are cloud-based applicaons that make it easy to monitor and manage your
next-generaon firewalls and Panoramas. These apps improve your visibility into device health,
performance, capacity planning, and configuraon. Through these apps, you can maximize the
benefits you enjoy from the products and services that Palo Alto Networks delivers.
Telemetry data is also used for sharing threat intelligence, providing enhanced intrusion
prevenon, evaluaon of threat signatures, as well as improved malware detecon within PAN-DB
URL filtering, DNS-based command-and-control (C2) signatures, and WildFire.
Telemetry data is collected and stored locally on your device for a limited period of me. This data
is shared with Palo Alto Networks only if you configure a desnaon region for the data. If your
organizaon has a Cortex Data Lake license, then you can only send the data to the same region
as where your Cortex Data Lake instance resides. If your organizaon does not have a Cortex Data
Lake license, then you must install a device cerficate in order to share this data. In this case, you
can choose any available region, although you must conform to all applicable local laws regarding
privacy and data storage.
Telemetry data is collected and shared with Palo Alto Networks on predefined collecon intervals.
You can control whether data is collected and shared by enabling/disabling categories of data. You
can also monitor the current status of data collecon and transmission.
Finally, you can obtain a live sample of the data that your firewall is collecng for telemetry
purposes. For a complete descripon of all the telemetry metrics that can be shared with Palo Alto
Networks, including the privacy implicaon for each metric, see the PAN-OS Device Telemetry
Metrics Reference Guide.
The automacally created user _cliadmin may appear under Logged in Admins on the
dashboard while telemetry is enabled. This user is created only for telemetry collecon.
Device Telemetry
Device Telemetry Collecon and Transmission Intervals

PAN-OS collects and sends telemetry data on fixed intervals. Collecon is defined on a metric by
metric basis, and can be one of:
• Every 20 minutes.
• Every 4 hours.
• Once per week.
Telemetry is collected into data bundles. Each bundle is an aggregaon of all the data collected
up to the point of data transmission. These bundles are stored on the device unl a transmission
event, which occur once every 4 hours. When a bundle has been successfully sent to Palo Alto
Networks, it is deleted from the device.
If an error occurs while sending a bundle to Palo Alto Networks, the firewall waits 10 minutes and
then tries again. The firewall will connue to try to send the bundle unl it is either successful, or
it needs the storage space to collect new telemetry data.
At every regular transmission interval, the firewall begins by sending the bundles scheduled for
that event. Aer a successful transfer of those bundles, the firewall sends any failed bundles that
it might have stored from previous transmission events.
Device Telemetry
Manage Device Telemetry

To manage device telemetry you can:
• Enable Device Telemetry
• Disable Device Telemetry
• Manage the Data that Device Telemetry Collects
• Manage Historical Device Telemetry
Enable Device Telemetry

By default, your device does not share data with Palo Alto Networks. If sharing is enabled, you can
stop sharing all device telemetry by: Device > Setup > Telemetry, uncheck the Enable Telemetry
box, and then commit your change.
To enable Device Telemetry so that data is shared with Palo Alto Networks:
STEP 1 | Enable Cortex Data Lake.
1. If your organizaon does not have a Cortex Data Lake license, install a device cerficate
if one is not already installed on your device.
If your organizaon does have a Cortex Data Lake license, make sure it is acvated.
2. Make sure that your network is properly configured so that the firewall can send data to
Cortex Data Lake.
STEP 2 | Navigate to Device > Setup > Telemetry
STEP 3 | Edit the Telemetry widget.
STEP 4 | In Telemetry Desnaon, select your region. If your organizaon is using Cortex Data Lake,
you must use the region that your Cortex Data Lake is configured to use.
STEP 5 | Click OK, and then commit your changes.
Disable Device Telemetry

If your next-generaon firewall is configured to share data with Palo Alto Networks, you can
disable this sharing by:
STEP 1 | Navigate to Device > Setup > Telemetry
STEP 2 | Edit the Telemetry widget.
STEP 3 | Uncheck the Enable Telemetry box.
STEP 4 | Click OK, and then commit your changes.
STEP 5 | Any telemetry data currently stored in Cortex Data Lake is automacally purged one year
aer your firewall uploaded it. Oponally, if you do not want the data to reside in Cortex
Data Lake for this amount of me aer you disable telemetry, open a support cket and ask
Palo Alto Networks to purge your telemetry data.
Device Telemetry
Manage the Data the Device Telemetry Collects

Select Device > Setup > Telemetry to see the currently collected telemetry categories. To change
these categories, edit the Telemetry widget. Deselect any categories that you don't want the
firewall to collect, OK, and then commit the change.
To stop sharing all device telemetry, uncheck the Enable Telemetry box, and then commit
your change.
Manage Historical Device Telemetry

Device Telemetry changed significantly for the PAN-OS 10.1 release. Prior to 10.0, telemetry
data was mostly of interest for threat intelligence purposes. As of 10.0, threat intelligence metrics
are sll a large poron the data collected by the device, but a great deal more data involving the
health, performance, and configuraon of the device is collected as well.
In other words, PAN-OS 10.1 device telemetry extends the data that was collected for previous
releases. PAN-OS 10.1 also sends telemetry data to a different cloud locaon than did prior
releases. But the historical telemetry support sll exists for next-generaon firewalls running
PAN-OS 10.0. The only difference is that the 10.1 device telemetry user interface is not capable of
managing this historical data collecon.
Device Telemetry
If you have an exisng next-generaon firewall, and you have any of the historical telemetry data
categories enabled, then when you upgrade to PAN-OS 10.1 your firewall will connue to collect
and share this informaon. If you want to turn this telemetry data sharing off, use the following
CLI commands:
set deviceconfig system update-schedule statistics-service

application-reports no
set deviceconfig system update-schedule statistics-service threat-
prevention-reports no
prevention-information no
prevention-pcap no
set deviceconfig system update-schedule statistics-service passive-
dns-monitoring no
set deviceconfig system update-schedule statistics-service url-
reports no
set deviceconfig system update-schedule statistics-service health-
performance-reports no
set deviceconfig system update-schedule statistics-service file-
identification-reports no
If you have a 10.1 firewall and this telemetry sharing is turned off, but you want to share this data
with Palo Alto Networks, then you can turn it on using:
set deviceconfig system update-schedule statistics-service

application-reports yes
prevention-reports yes
prevention-information yes
prevention-pcap yes
set deviceconfig system update-schedule statistics-service passive-
dns-monitoring yes
set deviceconfig system update-schedule statistics-service url-
reports yes
set deviceconfig system update-schedule statistics-service health-
performance-reports yes
set deviceconfig system update-schedule statistics-service file-
identification-reports yes
You can see whether your device is collecng and sharing this historical telemetry data using the
following CLI command:
show deviceconfig system update-schedule statistics-service
Device Telemetry
Monitor Device Telemetry

PAN-OS shows you the sharing status for each telemetry category. Widgets for each metrics
category are available at Device > Setup > Telemetry.
In the event of a failure, your device will retry the send aempt at the next transmission me. If
the problem persists, check to make sure that your devices are properly configured to send data to
Cortex Data Lake:
• If your organizaon has a Cortex Data Lake license, then make sure your Cortex Data Lake
license has been acvated, and that your firewall is configured to use Cortex Data Lake.
• If your organizaon does not have a Cortex Data Lake license, then make sure you have
installed a device cerficate, and that your network is configured to allow traffic to Cortex
Data Lake.
Device Telemetry
Sample the Data that Device Telemetry Collects

You can download a live example of the data that device telemetry collects and shares with Palo
Alto Networks. To do this, go to Device > Setup > Telemetry, and edit the Telemetry widget. Then
click Generate Telemetry File.
The data collecon will take a few minutes, depending on the speed of your firewall. When the
process completes, click Download Device Telemetry Data. The telemetry bundle is a compressed
tar ball, and it is placed in your default browser download directory.
For a descripon of every metric that device telemetry collects and shares with Palo Alto
Networks, see the PAN-OS Device Telemetry Metrics Reference Guide.
Authencaon
Authencaon is a method for protecng services and applicaons by verifying the
idenes of users so that only legimate users have access. Several firewall and
Panorama features require authencaon. Administrators authencate to access the
web interface, CLI, or XML API of the firewall and Panorama. End users authencate
through Authencaon Portal or GlobalProtect to access various services and
applicaons. You can choose from several authencaon services to protect your
network and to accommodate your exisng security infrastructure while ensuring a
smooth user experience.
If you have a public key infrastructure, you can deploy cerficates to enable
authencaon without users having to manually respond to login challenges (see
Cerficate Management). Alternavely, or in addion to cerficates, you can
implement interacve authencaon, which requires users to authencate using
one or more methods. The following topics describe how to implement, test, and
troubleshoot the different types of interacve authencaon:
> Authencaon Types > Configure LDAP Authencaon
> Plan Your Authencaon > Connecon Timeouts for
Deployment Authencaon Servers
> Configure Mul-Factor > Configure Local Database
Authencaon Authencaon
> Configure SAML Authencaon > Configure an Authencaon Profile
> Configure Kerberos Single Sign-On and Sequence
> Configure Kerberos Server > Test Authencaon Server

Authencaon Connecvity
> Configure TACACS+ Authencaon > Authencaon Policy
> Configure RADIUS Authencaon > Troubleshoot Authencaon Issues
217
Authencaon
Authencaon Types
• External Authencaon Services
• Mul-Factor Authencaon
• SAML
• Kerberos
• TACACS+
• RADIUS
• LDAP
• Local Authencaon
External Authencaon Services

The firewall and Panorama can use external servers to control administrave access to the
web interface and end user access to services or applicaons through Authencaon Portal
and GlobalProtect. In this context, any authencaon service that is not local to the firewall or
Panorama is considered external, regardless of whether the service is internal (such as Kerberos)
or external (such as a SAML identy provider) relave to your network. The server types that
the firewall and Panorama can integrate with include Mul-Factor Authencaon (MFA), SAML,
Kerberos, TACACS+, RADIUS, and LDAP. Although you can also use the Local Authencaon
services that the firewall and Panorama support, usually external services are preferable because
they provide:
• Central management of all user accounts in an external identy store. All the supported
external services provide this opon for end users and administrators.
• Central management of account authorizaon (role and access domain assignments). SAML,
TACACS+, and RADIUS support this opon for administrators.
• Single sign-on (SSO), which enables users to authencate only once for access to mulple
services and applicaons. SAML and Kerberos support SSO.
• Mulple authencaon challenges of different types (factors) to protect your most sensive
services and applicaons. MFA services support this opon.
Authencaon through an external service requires a server profile that defines how the firewall
connects to the service. You assign the server profile to authencaon profiles, which define
sengs that you customize for each applicaon and set of users. For example, you can configure
one authencaon profile for administrators who access the web interface and another profile for
end users who access a GlobalProtect portal. For details, see Configure an Authencaon Profile
and Sequence.
Mul-Factor Authencaon
You can Configure Mul-Factor Authencaon (MFA) to ensure that each user authencates using
mulple methods (factors) when accessing highly sensive services and applicaons. For example,
you can force users to enter a login password and then enter a verificaon code that they receive
by phone before allowing access to important financial documents. This approach helps to prevent
aackers from accessing every service and applicaon in your network just by stealing passwords.
Authencaon
Of course, not every service and applicaon requires the same degree of protecon, and MFA
might not be necessary for less sensive services and applicaons that users access frequently.
To accommodate a variety of security needs, you can Configure Authencaon Policy rules that
trigger MFA or a single authencaon factor (such as login credenals or cerficates) based on
specific services, applicaons, and end users.
When choosing how many and which types of authencaon factors to enforce, it’s important
to understand how policy evaluaon affects the user experience. When a user requests a service
or applicaon, the firewall first evaluates Authencaon policy. If the request matches an
Authencaon policy rule with MFA enabled, the firewall displays a Authencaon Portal web
form so that users can authencate for the first factor. If authencaon succeeds, the firewall
displays an MFA login page for each addional factor. Some MFA services prompt the user
to choose one factor out of two to four, which is useful when some factors are unavailable. If
authencaon succeeds for all factors, the firewall evaluates Security policy for the requested
service or applicaon.
To reduce the frequency of authencaon challenges that interrupt the user workflow,
configure the first factor to use Kerberos or SAML single sign-on (SSO) authencaon.
To implement MFA for GlobalProtect, refer to Configure GlobalProtect to facilitate mul-
factor authencaon noficaons.
You cannot use MFA authencaon profiles in authencaon sequences.
For end-user authencaon via Authencaon Policy, the firewall directly integrates with several
MFA plaorms (Duo v2, Okta Adapve, PingID, and RSA SecurID), as well as integrang through
RADIUS or SAML for all other MFA plaorms. For remote user authencaon to GlobalProtect
portals and gateways and for administrator authencaon to the Panorama and PAN-OS web
interface, the firewall integrates with MFA vendors using RADIUS and SAML only.
The firewall supports the following MFA factors:
Factor Descripon
Push An endpoint device (such as a phone or tablet) prompts the user to

allow or deny authencaon.
Short message An SMS message on the endpoint device prompts the user to allow
service (SMS) or deny authencaon. In some cases, the endpoint device provides a
code that the user must enter in the MFA login page.
Voice An automated phone call prompts the user to authencate by pressing

a key on the phone or entering a code in the MFA login page.
One-me password An endpoint device provides an automacally generated alphanumeric

(OTP) string, which the user enters in the MFA login page to enable
authencaon for a single transacon or session.
Authencaon
SAML
You can use Security Asseron Markup Language (SAML) 2.0 to authencate administrators who
access the firewall or Panorama web interface and end users who access web applicaons that
are internal or external to your organizaon. In environments where each user accesses many
applicaons and authencang for each one would impede user producvity, you can configure
SAML single sign-on (SSO) to enable one login to access mulple applicaons. Likewise, SAML
single logout (SLO) enables a user to end sessions for mulple applicaons by logging out of just
one session. SSO is available to administrators who access the web interface and to end users
who access applicaons through GlobalProtect or Authencaon Portal. SLO is available to
administrators and GlobalProtect end users, but not to Authencaon Portal end users. When you
configure SAML authencaon on the firewall or on Panorama, you can specify SAML aributes
for administrator authorizaon. SAML aributes enable you to quickly change the roles, access
domains, and user groups of administrators through your directory service, which is oen easier
than reconfiguring sengs on the firewall or Panorama.
Administrators cannot use SAML to authencate to the CLI on the firewall or Panorama.
You cannot use SAML authencaon profiles in authencaon sequences.
SAML authencaon requires a service provider (the firewall or Panorama), which controls access
to applicaons, and an identy provider (IdP) such as PingFederate, which authencates users.
When a user requests a service or applicaon, the firewall or Panorama intercepts the request and
redirects the user to the IdP for authencaon. The IdP then authencates the user and returns
a SAML asseron, which indicates authencaon succeeded or failed. SAML Authencaon for
Authencaon Portal End Users illustrates SAML authencaon for an end user who accesses
applicaons through Authencaon Portal.
Figure 1: SAML Authentication for Authentication Portal End Users
Kerberos
Kerberos is an authencaon protocol that enables a secure exchange of informaon between
pares over an insecure network using unique keys (called ckets) to idenfy the pares. The
Authencaon
firewall and Panorama support two types of Kerberos authencaon for administrators and end
users:
• Kerberos server authencaon—A Kerberos server profile enables users to navely
authencate to an Acve Directory domain controller or a Kerberos V5-compliant
authencaon server. This authencaon method is interacve, requiring users to enter
usernames and passwords. For the configuraon steps, see Configure Kerberos Server
Authencaon.
• Kerberos single sign-on (SSO)—A network that supports Kerberos V5 SSO prompts a user to
log in only for inial access to the network (such as logging in to Microso Windows). Aer this
inial login, the user can access any browser-based service in the network (such as the firewall
web interface) without having to log in again unl the SSO session expires. (Your Kerberos
administrator sets the duraon of SSO sessions.) If you enable both Kerberos SSO and another
external authencaon service (such as a TACACS+ server), the firewall first tries SSO and, only
if that fails, falls back to the external service for authencaon. To support Kerberos SSO, your
network requires:
• A Kerberos infrastructure, including a key distribuon center (KDC) with an authencaon
server (AS) and cket-granng service (TGS).
• A Kerberos account for the firewall or Panorama that will authencate users. An account
is required to create a Kerberos keytab, which is a file that contains the principal name and
hashed password of the firewall or Panorama. The SSO process requires the keytab.
For the configuraon steps, see Configure Kerberos Single Sign-On.
Kerberos SSO is available only for services and applicaons that are internal to your
Kerberos environment. To enable SSO for external services and applicaons, use SAML.
TACACS+
Terminal Access Controller Access-Control System Plus (TACACS+) is a family of protocols
that enable authencaon and authorizaon through a centralized server. TACACS+ encrypts
usernames and passwords, making it more secure than RADIUS, which encrypts only passwords.
TACACS+ is also more reliable because it uses TCP, whereas RADIUS uses UDP. You can configure
TACACS+ authencaon for end users or administrators on the firewall and for administrators
on Panorama. Oponally, you can use TACACS+ Vendor-Specific Aributes (VSAs) to manage
administrator authorizaon. TACACS+ VSAs enable you to quickly change the roles, access
domains, and user groups of administrators through your directory service instead of reconfiguring
sengs on the firewall and Panorama.
The firewall and Panorama support the following TACACS+ aributes and VSAs. Refer to your
TACACS+ server documentaon for the steps to define these VSAs on the TACACS+ server.
Name Value
service This aribute is required to idenfy the VSAs as

specific to Palo Alto Networks. You must set the value
to PaloAlto.
Authencaon
Name Value
protocol This aribute is required to idenfy the VSAs as

specific to Palo Alto Networks devices. You must set
the value to firewall.
PaloAlto-Admin-Role A default (dynamic) administrave role name or a

custom administrave role name on the firewall.
PaloAlto-Admin-Access-Domain The name of an access domain for firewall

administrators (configured in the Device > Access
Domains page). Define this VSA if the firewall has
mulple virtual systems.
PaloAlto-Panorama-Admin-Role A default (dynamic) administrave role name or a

custom administrave role name on Panorama.
PaloAlto-Panorama-Admin-Access- The name of an access domain for Device Group and

Domain Template administrators (configured in the Panorama >
Access Domains page).
PaloAlto-User-Group The name of a user group in the Allow List of an

authencaon profile.
RADIUS
Remote Authencaon Dial-In User Service (RADIUS) is a broadly supported networking
protocol that provides centralized authencaon and authorizaon. You can configure RADIUS
authencaon for end users or administrators on the firewall and for administrators on Panorama.
Oponally, you can use RADIUS Vendor-Specific Aributes (VSAs) to manage administrator
authorizaon. RADIUS VSAs enable you to quickly change the roles, access domains, and user
groups of administrators through your directory service instead of reconfiguring sengs on the
firewall and Panorama. You can also configure the firewall to use a RADIUS server for:
• Collecng VSAs from GlobalProtect endpoints.
• Implemenng Mul-Factor Authencaon.
When sending authencaon requests to a RADIUS server, the firewall and Panorama use the
authencaon profile name as the network access server (NAS) idenfier, even if the profile is
assigned to an authencaon sequence for the service (such as administrave access to the web
interface) that iniates the authencaon process.
The firewall and Panorama support the following RADIUS VSAs. To define VSAs on a RADIUS
server, you must specify the vendor code (25461 for Palo Alto Networks firewalls or Panorama)
and the VSA name and number. Some VSAs also require a value. Refer to your RADIUS server
documentaon for the steps to define these VSAs.
Alternavely, you can download the Palo Alto Networks RADIUS diconary, which defines
the authencaon aributes that the Palo Alto Networks firewall and a RADIUS server use to
Authencaon
communicate with each other, and install it on your RADIUS server to map the aributes to the
RADIUS binary data.
When you predefine dynamic administrator roles for users on the server, use lower-case to
specify the role (for example, enter superuser, not SuperUser).
When configuring the advanced vendor opons on a Cisco Secure Access Control Server
(ACS), you must set both the Vendor Length Field Size and Vendor Type Field Size to 1.
Otherwise, authencaon will fail.
Name Number Value
VSAs for administrator account management and authencaon
PaloAlto-Admin-Role 1 A default (dynamic) administrave role name or a

custom administrave role name on the firewall.
PaloAlto-Admin-Access-Domain 2 The name of an access domain for firewall

administrators (configured in the Device > Access
Domains page). Define this VSA if the firewall has
PaloAlto-Panorama-Admin-Role 3 A default (dynamic) administrave role name or a

custom administrave role name on Panorama.
PaloAlto-Panorama-Admin- 4 The name of an access domain for Device Group

Access-Domain and Template administrators (configured in the
Panorama > Access Domains page).
PaloAlto-User-Group 5 The name of a user group that an authencaon

profile references.
VSAs forwarded from GlobalProtect endpoints to the RADIUS server
PaloAlto-User-Domain 6 Don’t specify a value when you define these

VSAs.
PaloAlto-Client-Source-IP 7
PaloAlto-Client-OS 8
PaloAlto-Client-Hostname 9
PaloAlto-GlobalProtect-Client- 10
Version
Authencaon
LDAP
Lightweight Directory Access Protocol (LDAP) is a standard protocol for accessing informaon
directories. You can Configure LDAP Authencaon for end users and for firewall and Panorama
administrators.
Configuring the firewall to connect to an LDAP server also enables you to define policy rules
based on users and user groups instead of just IP addresses. For the steps, see Map Users to
Groups and Enable User- and Group-Based Policy.
Local Authencaon
Although the firewall and Panorama provide local authencaon for administrators and end
users, External Authencaon Services are preferable in most cases because they provide
central account management. However, you might require special user accounts that you don’t
manage through the directory servers that your organizaon reserves for regular accounts. For
example, you might define a superuser account that is local to the firewall so that you can access
the firewall even if the directory server is down. In such cases, you can use the following local
authencaon methods:
• (Firewall only) Local database authencaon—To Configure Local Database Authencaon,
you create a database that runs locally on the firewall and contains user accounts (usernames
and passwords or hashed passwords) and user groups. This type of authencaon is useful
for creang user accounts that reuse the credenals of exisng Unix accounts in cases where
you know only the hashed passwords, not the plaintext passwords. Because local database
authencaon is associated with authencaon profiles, you can accommodate deployments
where different sets of users require different authencaon sengs, such as Kerberos
single sign-on (SSO) or Mul-Factor Authencaon (MFA). (For details, see Configure an
Authencaon Profile and Sequence). For administrator accounts that use an authencaon
profile, password complexity and expiraon sengs are not applied. This authencaon
method is available to administrators who access the firewall (but not Panorama) and end users
who access services and applicaons through Authencaon Portal or GlobalProtect.
• Local authencaon without a database—You can configure firewall administrave accounts
or Panorama administrave accounts without creang a database of users and user groups
that runs locally on the firewall or Panorama. Because this method is not associated with
authencaon profiles, you cannot combine it with Kerberos SSO or MFA. However, this is
the only authencaon method that allows password profiles, which enable you to associate
individual accounts with password expiraon sengs that differ from the global sengs. (For
details, see Define password complexity and expiraon sengs)
Authencaon
Plan Your Authencaon Deployment

The following are key quesons to consider before you implement an authencaon soluon
for administrators who access the firewall and end users who access services and applicaons
through Authencaon Portal.
For both end users and administrators, consider:
How can you leverage your exisng security infrastructure? Usually, integrang the firewall
with an exisng infrastructure is faster and cheaper than seng up a new, separate soluon
just for firewall services. The firewall can integrate with Mul-Factor Authencaon, SAML,
Kerberos, TACACS+, RADIUS, and LDAP servers. If your users access services and applicaons
that are external to your network, you can use SAML to integrate the firewall with an identy
provider (IdP) that controls access to both external and internal services and applicaons.
How can you opmize the user experience? If you don’t want users to authencate manually
and you have a public key infrastructure, you can implement cerficate authencaon. Another
opon is to implement Kerberos or SAML single sign-on (SSO) so that users can access mulple
services and applicaons aer logging in to just one. If your network requires addional
security, you can combine cerficate authencaon with interacve (challenge-response)
authencaon.
Do you require special user accounts that you don’t manage through the directory servers that
your organizaon reserves for regular accounts? For example, you might define a superuser
account that is local to the firewall so that you can access the firewall even if the directory
server is down. You can configure Local Authencaon for these special-purpose accounts.
External Authencaon Services are usually preferable to local authencaon

because they provide central account management, reliable authencaon services,
and usually logging and troubleshoong features.
Are the user names for your user accounts properly formaed? Leveraging SAML, Kerberos,
TACACS+, RADIUS, and LDAP authencaon requires all user names adhere to the regular
expression Linux login name rule. User names must have the format [a-zA-Z0-9_.][a-zA-
Z0-9_.-]{0,30}[a-zA-Z0-9_.$-].
This means that:
• The first character of the user name must be an upper or lower case alphabecal leer, a
number (0-9), or either _ (underscore) or . (period).
• Other than the first and last characters, the user name may contain upper or lower case
alphabecal characters, numbers (0-9), and _ (underscore),. (period), or - (dash). The
maximum length is 30 characters excluding the first and last characters.
• The last character of the user name may be an upper or lower case alphabecal leer, a
number (0-9), or _ (underscore), . (period), $, or - (dash).
Adhering to the regular expression Linux login name rule is required for PAN-OS administrators
only. It is not required for GlobalProtect and Capve Portal users.
For end users only, consider:
Which services and applicaons are more sensive than others? For example, you might
want stronger authencaon for key financial documents than for search engines. To protect
Authencaon
your most sensive services and applicaons, you can configure Mul-Factor Authencaon
(MFA) to ensure that each user authencates using mulple methods (factors) when accessing
those services and applicaons. To accommodate a variety of security needs, Configure
Authencaon Policy rules that trigger MFA or single factor authencaon (such as login
credenals or cerficates) based on specific services, applicaons, and end users. Other ways
to reduce your aack surface include network segmentaon and user groups for allowed
applicaons.
For administrators only, consider:
Do you use an external server to centrally manage authorizaon for all administrave
accounts? By defining Vendor-Specific Aributes (VSAs) on the external server, you can quickly
change administrave role assignments through your directory service instead of reconfiguring
sengs on the firewall. VSAs also enable you to specify access domains for administrators
of firewalls with mulple virtual systems. SAML, TACACS+, and RADIUS support external
authorizaon.
Authencaon
Configure Mul-Factor Authencaon

To use Mul-Factor Authencaon (MFA) for protecng sensive services and applicaons, you
must configure Authencaon Portal to display a web form for the first authencaon factor and
to record Authencaon Timestamps. The firewall uses the mestamps to evaluate the meouts
for Authencaon Policy rules. To enable addional authencaon factors, you can integrate
the firewall with MFA vendors through RADIUS or vendor APIs. Aer evaluang Authencaon
policy, the firewall evaluates Security policy, so you must configure rules for both policy types.
Palo Alto Networks provides support for MFA vendors through Applicaons content
updates. This means that if you use Panorama to push device group configuraons
to firewalls, you must install the same Applicaons updates on the firewalls as on
Panorama to avoid mismatches in vendor support.
MFA vendor API integraons are supported for end-user authencaon through
Authencaon Policy only. For remote user authencaon to GlobalProtect portals or
gateways or for administrator authencaon to the PAN-OS or Panorama web interface,
you can only use MFA vendors supported through RADIUS or SAML; MFA services through
vendor APIs are not supported in these use cases.
STEP 1 | Configure Authencaon Portal in Redirect mode to display a web form for the first
authencaon factor, to record authencaon mestamps, and to update user mappings.
STEP 2 | Configure one of the following server profiles to define how the firewall will connect to the
service that authencates users for the first authencaon factor.
• Add a RADIUS server profile. This is required if the firewall integrates with an MFA
vendor through RADIUS. In this case, the MFA vendor provides the first and all addional
authencaon factors, so you can skip the next step (configuring an MFA server profile).
If the firewall integrates with an MFA vendor through an API, you can sll use a RADIUS
server profile for the first factor but MFA server profiles are required for the addional
factors.
• Add a SAML IdP server profile.
In most cases, an external service is recommended for the first authencaon factor.
However, you can configure Configure Local Database Authencaon as an
alternave.
STEP 3 | Add an MFA server profile.

The profile defines how the firewall connects to the MFA server. Add a separate profile for
each authencaon factor aer the first factor. The firewall integrates with these MFA servers
Authencaon
through vendor APIs. You can specify up to three addional factors. Each MFA vendor provides
one factor, though some vendors let users choose one factor out of several.
1. Select Device > Server Profiles > Mul Factor Authencaon and Add a profile.
2. Enter a Name to idenfy the MFA server.
3. Select the Cerficate Profile that the firewall will use to validate the MFA server
cerficate when establishing a secure connecon to the MFA server.
4. Select the MFA Vendor you deployed.
5. Configure the Value of each vendor aribute.
The aributes define how the firewall connects to the MFA server. Each vendor Type
requires different aributes and values; refer to your vendor documentaon for details.
6. Click OK to save the profile.

The profile defines the order of the authencaon factors that users must respond to.
1. Select Device > Authencaon Profile and Add a profile.
2. Enter a Name to idenfy the authencaon profile.
3. Select the Type for the first authencaon factor and select the corresponding Server
Profile.
4. Select Factors, Enable Addional Authencaon Factors, and Add the MFA server
profiles you configured.
The firewall will invoke each MFA service in the listed order, from top to boom.
5. Click OK to save the authencaon profile.
STEP 5 | Configure an authencaon enforcement object.

The object associates each authencaon profile with an Authencaon Portal method.
The method determines whether the first authencaon challenge (factor) is transparent or
requires a user response.
Select the Authencaon Profile you configured and enter a Message that tells users how to
authencate for the first factor. The message displays in the Authencaon Portal web form.
If you set the Authencaon Method to browser-challenge, the Authencaon Portal

web form displays only if Kerberos SSO authencaon fails. Otherwise, authencaon
for the first factor is automac; users won’t see the web form.
Authencaon
STEP 6 | Configure an Authencaon policy rule.

The rule must match the services and applicaons you want to protect and the users who must
authencate.
1. Select Policies > Authencaon and Add a rule.
2. Enter a Name to idenfy the rule.
3. Select Source and Add specific zones and IP addresses or select Any zones or IP
addresses.
The rule applies only to traffic coming from the specified IP addresses or from interfaces
in the specified zones.
4. Select User and select or Add the source users and user groups to which the rule applies
(default is any).
5. Select Desnaon and Add specific zones and IP addresses or select any zones or IP
addresses.
The IP addresses can be resources (such as servers) for which you want to control access.
6. Select Service/URL Category and select or Add the services and service groups for
which the rule controls access (default is service-hp).
7. Select or Add the URL Categories for which the rule controls access (default is any).
For example, you can create a custom URL category that specifies your most sensive
internal sites.
8. Select Acons and select the Authencaon Enforcement object you created.
9. Specify the Timeout period in minutes (default 60) during which the firewall prompts the
user to authencate only once for repeated access to services and applicaons.
Timeout is a tradeoff between ghter security (less me between authencaon

prompts) and the user experience (more me between authencaon prompts).
More frequent authencaon is oen the right choice for access to crical
systems and sensive areas such as a data center. Less frequent authencaon
is oen the right choice at the network perimeter and for businesses for which
the user experience is key.
10. Click OK to save the rule.
STEP 7 | Customize the MFA login page.

The firewall displays this page to tell users how to authencate for MFA factors and to indicate
the authencaon status (in progress, succeeded, or failed).
1. Select Device > Response Pages and select MFA Login Page.
2. Select the Predefined response page and Export the page to your client system.
3. On your client system, use an HTML editor to customize the downloaded response page
and save it with a unique filename.
4. Return to the MFA Login Page dialog on the firewall, Import your customized page,
Browse to select the Import File, select the Desnaon (virtual system or shared
locaon), click OK, and click Close.
Authencaon
STEP 8 | Configure a Security policy rule that allows users to access the services and applicaons that
require authencaon.
1. Create a Security Policy Rule.
The automated correlaon engine on the firewall uses several correlaon

objects to detect events on your network that could indicate credenal abuse
relang to MFA. To review the events, select Monitor > Automated Correlaon
Engine > Correlated Events.
STEP 9 | Verify that the firewall enforces MFA.

1. Log in to your network as one of the source users specified in the Authencaon rule.
2. Request a service or applicaon that matches one of the services or applicaons
specified in the rule.
The firewall displays the Authencaon Portal web form for the first authencaon
factor. The page contains the message you entered in the authencaon enforcement
object. For example:
3. Enter your user credenals for the first authencaon challenge.

The firewall then displays an MFA login page for the next authencaon factor. For
example, the MFA service might prompt you to select the Voice, SMS, push, or PIN code
Authencaon
(OTP) authencaon method. If you select push, your phone prompts you to approve the
authencaon.
4. Authencate for the next factor.

The firewall displays an authencaon success or failure message. If authencaon
succeeded, the firewall displays an MFA login page for the next authencaon factor, if
any.
Repeat this step for each MFA factor. Aer you authencate for all the factors, the
firewall evaluates Security policy to determine whether to allow access to the service or
applicaon.
5. End the session for the service or applicaon you just accessed.
6. Start a new session for the same service or applicaon. Be sure to perform this step
within the Timeout period you configured in the Authencaon rule.
The firewall allows access without re-authencang.
7. Wait unl the Timeout period expires and request the same service or applicaon.
The firewall prompts you to re-authencate.
Configure MFA Between RSA SecurID and the Firewall

Mul-factor authencaon allows you to protect company assets by using mulple factors to
verify a user’s identy before allowing them to access network resources. To enable mul-factor
authencaon (MFA) between the firewall and the RSA SecurID Access Cloud Authencaon
Service, you must first configure the RSA SecurID Service so that you have the details that
you need to configure the firewall to authencate users using mulple factors. Aer you have
performed the required configuraon on the RSA SecurID Access Console, you can configure the
firewall to integrate with RSA SecurID.
The Palo Alto Networks next-generaon firewall integrates with the RSA SecurID Access
Cloud Authencaon Service. The MFA API integraon with RSA SecurID is supported
for cloud-based services only and does not support two-factor authencaon for the on-
premise Authencaon Manager when the second factor uses the Vendor Specific API.
The minimum content version required for this integraon is 752 and PAN-OS 8.0.2.
• Get the RSA SecurID Access Cloud Authencaon Service Details

• Configure the Firewall for MFA with RSA SecurID
Get the RSA SecurID Access Cloud Authencaon Service Details

In order to securely pass user authencaon requests to and from the firewall and the RSA
SecurID Access Cloud Authencaon Service, you must first go to the RSA SecurID Access
Authencaon
Console and configure the RSA Access ID, the authencaon service URL, and the client API key
that the firewall needs to authencate to and interact with the service. The firewall also needs the
Access Policy ID that uses either the RSA Approve or RSA Tokencode authencaon method to
authencate to the identy source.
Generate the RSA SecurID API key—Log on to RSA SecurID Access Console and select My
Account > Company Sengs > Authencaon API Keys. Add a new key and then Save
Sengs and Publish Changes.
Get the RSA SecurID Access endpoint API (Authencaon Service Domain) to which the
firewall must connect—Select Plaorm > Identy Routers, pick an Identy Router to Edit
and jot down the Authencaon Service Domain. In this example it is hps://rsaready.auth-
demo.auth.
Get the Access Policy ID—Select Access > Policies and jot down the name of the access policy
that will allow the firewall to act as an authencaon client to the RSA SecurID service. The
policy must be configured to use either the RSA Approve or the RSA Tokencode authencaon
methods only.
Authencaon
Configure the Firewall for MFA with RSA SecurID

Aer you Get the RSA SecurID Access Cloud Authencaon Service Details, you can configure
the firewall to prompt users for an RSA SecurID token when MFA is invoked.
STEP 1 | Configure the firewall to trust the SSL cerficate provided by the RSA SecurID Access
endpoint API.
1. Export the SSL cerficate from the RSA SecurID Access endpoint and import it into the
firewall.
To enable trust between the firewall and the RSA SecurID Access endpoint API, you must
either import a self-signed cerficate, or the CA cerficate used to sign the cerficate.
2. Configure a Cerficate Profile (Device > Cerficate Management > Cerficate Profile
and click Add).
STEP 2 | Configure Authencaon Portal (Device > User Idenficaon > Authencaon Portal
Sengs) in Redirect mode to display a web form for authencang to RSA SecureID. Make
sure to specify the Redirect Host as an IP address or a hostname (with no periods in its name)
that resolves to the IP address of the Layer 3 interface on the firewall to which web requests
are redirected.
Authencaon
STEP 3 | Configure a mul-factor authencaon server profile to specify how the firewall must
connect with the RSA SecurID cloud service (Device > Server Profiles > Mul Factor
Authencaon and click Add).
1. Enter a Name to idenfy the MFA server profile.
2. Select the Cerficate Profile that you created earlier, rsa-cert-profile in this example. The
firewall will use this cerficate when establishing a secure connecon with RSA SecurID
cloud service.
3. In the MFA Vendor drop-down, select RSA SecurID Access.
4. Configure the Value for each aribute that you noted in Get the RSA SecurID Access
Cloud Authencaon Service Details:
• API Host—Enter the hostname or IP address of the RSA SecurID Access API endpoint
to which the firewall must connect, rsaready.auth-demo.auth in this example.
• Base URI —Do not modify the default value (/mfa/v1_1)
• Client Key—Enter the RSA SecurID Client Key.
• Access ID—Enter the RSA SecurID Access ID.
• Assurance Policy—Enter the RSA SecurID Access Policy name, mfa-policy in this
example.
• Timeout—The default is 30 seconds.
5. Save the profile.
Authencaon
STEP 4 | Configure an authencaon profile (Device > Authencaon Profile and click Add).
The profile defines the order of the authencaon factors that users must respond to.
1. Select the Type for the first authencaon factor and select the corresponding Server
Profile.
2. Select Factors, Enable Addional Authencaon Factors, and Add the rsa-mfa server
profile you created earlier in this example.
STEP 5 | Configure an authencaon enforcement object. (Objects > Authencaon and click Add).
Make sure to select the authencaon profile you just defined called RSA in this example.
STEP 6 | Configure an Authencaon policy rule. (Policies > Authencaon and click Add)
Your authencaon policy rule must match the services and applicaons you want to protect,
specify the users who must authencate, and include the authencaon enforcement object
that triggers the authencaon profile. In this example, RSA SecurID Access authencates all
users who accessing HTTP, HTTPS, SSH, and VNC traffic with the authencaon enforcement
Authencaon
object called RSA Auth Enforcement (in Acons, select the Authencaon Enforcement
object).
STEP 7 | Commit your changes on the firewall.
Authencaon
STEP 8 | Verify that users on your network are being secured using RSA SecurID using the Push or
PIN Code authencaon method you enabled.
1. Push authencaon
1. Ask a user on your network to launch a web browser and access a website. The
Authencaon Portal page with the IP address or hostname for the Redirect Host you
defined earlier should display.
2. Verify that the user enters the credenals for the first authencaon factor and then
connues to the secondary authencaon factor, and selects Push.
3. Check for a Sign-In request on the RSA SecurID Access applicaon on the user’s
mobile device.
4. Ask the user to Accept the Sign-In Request on the mobile device, and wait for a few
seconds for the firewall to receive the noficaon of successful authencaon. The
user should be able to access the requested website.
Authencaon
To test an authencaon failure, Decline the sign-in request on the mobile

device.
2. PIN Code authencaon
1. Ask a user on your network to launch a web browser and access a website. The
Authencaon Portal page with the IP address or hostname for the redirect host you
defined earlier should display.
2. Verify that the user enters the credenals for the first authencaon factor and then
connues to the secondary authencaon factor, and selects PIN Code.
3. Check that a PIN Code displays on the RSA SecurID Access applicaon on the user’s
mobile device.
Authencaon
4. Ask the user to copy the PIN code in the Enter the PIN... prompt of the web browser
and click Submit. Wait for a few seconds for the firewall to receive the noficaon of
successful authencaon. The user should be able to access the requested website.
Configure MFA Between Okta and the Firewall

Mul-factor authencaon allows you to protect company assets by using mulple factors to
verify the identy of users before allowing them to access network resources.
To enable mul-factor authencaon (MFA) between the firewall and the Okta identy
management service:
• Configure Okta
• Configure the firewall to integrate with Okta
• Verify MFA with Okta
Configure Okta
Log in to the Okta Admin Portal to create your user accounts, define your Okta MFA policy, and
obtain the token informaon required to configure MFA with Okta on the firewall.
Authencaon
STEP 1 | Create your Okta Admin user account.

1. Submit your email address and name, then click Get Started.
2. Click the link in the confirmaon email and use the included temporary password to log
in to the Okta Admin Portal.
3. Create a new password that includes at least 8 characters, one lowercase leer, one
uppercase leer, a number, and does not include any part of your username.
4. Select a password reminder queson and enter the answer.
5. Select a security image, then Create My Account.
Authencaon
STEP 2 | Configure your Okta service.
If you log in and are not redirected to the Okta Admin Portal, select Admin at the upper
right.
1. From the Okta Dashboard, log in with your Okta Admin credenals, then select
Applicaons > Applicaons.
2. Select Add Applicaon.

3. Search for Okta Verify.
4. Select Add, then Done.
Authencaon
STEP 3 | Create one or more user groups to categorize your users (for example, by device, by policy, or
by department) and assign the Okta Verify applicaon.
1. Select Directory > Groups.
2. Click Add Group.
3. Enter a group Name and oponally a Group Descripon, then Add Group.
The default group Everyone includes all users configured for your organizaon
during the first step in Configure Okta.
4. Select the group you created, then select Manage Apps.
5. Assign the Okta Verify applicaon you added in Step 2.
Authencaon
6. Aer the applicaon has been Assigned, click Done.

7. Repeat this process for all groups that will use the Okta Verify applicaon for MFA.
STEP 4 | Add users and assign them to a group.

1. From the Okta Dashboard, select Directory > People > Add Person.
2. Enter the user’s First Name, Last Name, and Username. The username must match the
Primary email, which populates automacally, and the username entered on the firewall.
You can oponally enter an alternate email address for the user as the Secondary Email.
3. Enter the name of the group or Groups to associate with this user. When you start
typing, the group name populates automacally.
4. Check Send user acvaon email now, then Save to add a single user or Save and Add
Another to connue adding users.
Authencaon
STEP 5 | Assign a test policy to users.

1. Select Security > Authencaon > Sign On.
There is a Default Policy with a Default Rule that does not prompt users to log in with
MFA.
2. Enter the Rule Name and check Prompt for Factor to enforce the MFA prompt, and
select the type of prompt (Per Device, Every Time, or Per Session), then Create Rule.
Authencaon
STEP 6 | Record the Okta authencaon token informaon in a safe place because it is only displayed
once.
1. Select Security > API > Tokens.
2. Select Create Token.
3. Enter a name for the token, then Create Token.
4. Copy the Token Value.

You can click the Copy to clipboard buon to copy the Token Value to your clipboard.
5. In the URL for the Okta Admin Dashboard, copy the poron of the URL aer https://
up to /admin to use as the API host.
6. Omit the domain okta.com from this URL to use as the Organizaon.
Authencaon
For example, in the example Okta Admin Dashboard URL above, https://
paloaltonetworks-doc-admin.okta.com/admin/dashboard:
• The API hostname is paloaltonetworks-doc-admin.okta.com.
• The Organizaon is paloaltonetworks-doc-admin.
STEP 7 | Export all cerficates in the cerficate chain using Base-64 encoding:
1. Depending on your browser, use one of the following methods to export all cerficates
in the chain.
• Chrome—Press F12, then select Security > View Cerficate > Details > Copy to File.
• Firefox—Select Opons > Privacy & Security > View Cerficates > Export.
• Internet Explorer—Select Sengs > Internet Opons > Content > Cerficates >
Export.
2. Use the Cerficate Export Wizard to export all cerficates in the chain and select
Base-64 encoded X.509 as the format.
Configure the firewall to integrate with Okta

As a prerequisite, confirm that you have mapped all users that you want to authencate using
Okta.
STEP 1 | Import all cerficates in the cerficate chain on the firewall and add the imported CA
cerficates (root and intermediate) to a Cerficate Profile.
Authencaon
STEP 2 | Add a Mul Factor Authencaon Server Profile for Okta.

1. Select Device > Server Profiles > Mul Factor Authencaon.
2. Add an MFA server profile.
3. Enter a Profile Name.

4. Select the Cerficate Profile you created in Step 1 in Configure the firewall to integrate
with Okta.
5. Select Okta Adapve as the MFA Vendor.
6. Enter the API Host, Token, and Organizaon from Step 4 in Configure the firewall to
integrate with Okta.
STEP 3 | Configure Authencaon Portal using Redirect Mode to redirect users to the MFA vendor’s
challenge.
Authencaon
STEP 4 | Enable response pages on the Interface Management Profile to redirect users to the response
page challenge.
STEP 5 | Create an Authencaon Profile and add the MFA vendor as a Factor (see Configure Mul-
Factor Authencaon, Step 3.)
Authencaon
STEP 6 | Enable User-ID on the source zone to require idenfied users to respond to the challenge
using your MFA vendor.
STEP 7 | Create an Authencaon Enforcement Object to use the MFA vendor and create an
Authencaon policy rule (see Configure Authencaon Policy, Steps 4 and 5).
Verify MFA with Okta

STEP 1 | Verify your users received their enrollment emails, have acvated their accounts, and have
downloaded the Okta Verify app on their devices.
STEP 2 | Go to a website that will prompt the response page challenge.
If you are using a self-signed cerficate instead of a PKI-assigned cerficate from your
organizaon, a security warning displays that users must click through to access the
challenge.
STEP 3 | Log in to the response page using your Okta credenals.
STEP 4 | Confirm the device receives the challenge push noficaon.
STEP 5 | Confirm users can successfully access the page aer authencang the challenge by
accepng the push noficaon on their devices.
Configure MFA Between Duo and the Firewall

Mul-factor authencaon (MFA) allows you to protect company assets by using mulple factors
to verify the identy of users before allowing them to access network resources. There are
mulple ways to use the Duo identy management service to authencate with the firewall:
• Two-factor authencaon for VPN logins using the GlobalProtect Gateway and a RADIUS
server profile (supported on PAN-OS 7.0 and later).
• API-based integraon using Authencaon Portal and an MFA server profile (does not require
a Duo Authencaon Proxy or SAML IdP - supported on PAN-OS 8.0 and later).
• SAML integraon for on-premise servers (supported on PAN-OS 8.0 and later).
To enable SAML MFA between the firewall and Duo to secure administrave access to the
firewall:
• Configure Duo for SAML MFA with Duo Access Gateway
• Configure the Firewall to Integrate with Duo
• Verify MFA with Duo
Configure Duo for SAML MFA with Duo Access Gateway

Before you begin, verify that you have deployed the DuoAccessGateway (DAG) on an on-premise
server in your DMZ zone.
Create your Duo administrator account and configure the Duo Access Gateway to authencate
your users before they can access resources.
Authencaon
STEP 1 | Create your Duo administrator account.

1. On the Duo account creaon page, enter your First Name, Last Name, Email Address,
Cell Phone Number, Company / Account Name, and select the number of employees in
the organizaon.
2. Agree to the Terms and Privacy Policy and respond to the reCAPTCHA challenge to
Create My Account.
STEP 2 | Verify your Duo administrator account.

1. Select the authencaon verificaon method (Duo Push, Text Me, or Calling...).
2. Enter the Passcode you receive and Submit it to verify your account.
Authencaon
STEP 3 | Configure your Duo service for SAML.

Aer creang your configuraon, download the configuraon file at the top of the page.
1. In the Duo Admin Panel, select Applicaons > Protect an Applicaon.
2. Enter Palo Alto Networks to search the applicaons.
3. Locate SAML - Palo Alto Networks in the list of results, then Protect this Applicaon.
4. Enter the Domain.

5. Select Admin UI as the Palo Alto Networks Service.
6. Configure your Policy and other Sengs, and Save Configuraon.
Authencaon
7. Download your configuraon file.

The link to download the file is at the top of the page.
STEP 4 | Upload the configuraon file to the Duo Access Gateway (DAG).
1. In the DAG admin console, select Applicaons.
2. Click Choose File and select the configuraon file you downloaded, then Upload it.
3. In Sengs > Session Management, disable User agent binding, then Save Sengs.
Authencaon
STEP 5 | In the DAG admin console, configure your Acve Directory or OpenLDAP server as the
authencaon source and download the metadata file.
1. Log in to the DAG admin console.
2. In Authencaon Source > Set Acve Source, select your Source type (Acve Directory
or OpenLDAP) and Set Acve Source.
3. In Configure Sources, enter the Aributes.
• For Acve Directory, enter
mail,sAMAccountName,userPrincipalName,objectGUID.
• For OpenLDAP, enter mail,uid.
• For any custom aributes, append them to the end of the list and separate each
aribute with a comma. Do not delete any exisng aributes.
4. Save Sengs to save the configuraon.
5. Select Applicaons > Metadata, then click Download XML metadata to download the
XML metadata you will need to import into the firewall.
The file will be named dag.xml. Because this file includes sensive informaon to
authencate your Duo account with the firewall, make sure to keep the file in a secure
locaon to avoid the risk of compromising this informaon.
Configure the Firewall to Integrate with Duo
STEP 1 | Import the Duo metadata.

1. Log on to the firewall web interface.
2. On the firewall, select Device > Server Profiles > SAML Identy Provider > Import.
3. Enter the Profile Name.
4. Browse to the Identy Provider Metadata file (dag.xml).
5. If the Duo Access Gateway provides a self-signed cerficate as the signing cerficate for
the IdP, you cannot Validate Identy Provider Cerficate. In this case, ensure that you
are using PAN-OS 10.1 to migate exposure to CVE-2020-2021.
Authencaon
STEP 2 | Add an authencaon profile.

The authencaon profile allows Duo as the identy provider that validates administrator login
credenals.
1. Add an Authencaon Profile.
2. Enter the profile Name.
3. Select SAML as the authencaon Type.
4. Select Duo Access Gateway Profile as the IdP Server Profile.
5. Select the cerficate you want to use for SAML communicaon with the Duo Access
Gateway for the Cerficate for Signing Requests.
6. Enter duo_username as the Username Aribute.
7. Select Advanced to Add an allow list.

8. Select all, then click OK.
Authencaon
Authencaon
STEP 3 | Specify the authencaon sengs that the firewall uses for SAML authencaon with Duo.
1. Select Device > Setup > Management and edit the Authencaon Sengs.
2. Select Duo Access Gateway as the Authencaon Profile, then click OK.
Authencaon
STEP 4 | Add accounts for administrators who will authencate to the firewall using Duo.
1. Select Device > Administrators and Add an account.
2. Enter a user Name.
3. Select Duo Access Gateway as the Authencaon Profile.
4. Select the Administrator Type, then click OK.
Select Role Based if you want to use a custom role for the user. Otherwise, select
Dynamic. To require administrators to log in using SSO with Duo, assign the
authencaon profile to all current administrators.
Verify MFA with Duo
STEP 1 | Log in to the web interface on the firewall.
STEP 2 | Select Use Single Sign-On and Connue.
STEP 3 | Enter your login credenals on the Duo Access Gateway login page.
STEP 4 | Select an authencaon method (push noficaon, phone call, or passcode entry).
When you authencate successfully, you will be redirected to the firewall web interface.
Authencaon
Configure SAML Authencaon

To configure SAML single sign-on (SSO) and single logout (SLO), you must register the firewall and
the IdP with each other to enable communicaon between them. If the IdP provides a metadata
file containing registraon informaon, you can import it onto the firewall to register the IdP and
to create an IdP server profile. The server profile defines how to connect to the IdP and specifies
the cerficate that the IdP uses to sign SAML messages. You can also use a cerficate for the
firewall to sign SAML messages. Using cerficates is a requirement to secure communicaons
between the firewall and the IdP.
Palo Alto Networks requires HTTPS to ensure the confidenality of all SAML transacons instead
of alternave approaches such as encrypted SAML asserons. To ensure the integrity of all
messages processed in a SAML transacon, Palo Alto Networks requires digital cerficates to
cryptographically sign all messages.
The following procedure describes how to configure SAML authencaon for end users and
firewall administrators. You can also configure SAML authencaon for Panorama administrators.
SSO is available to administrators and to GlobalProtect and Authencaon Portal

end users. SLO is available to administrators and GlobalProtect end users, but not to
Authencaon Portal end users.
Administrators can use SAML to authencate to the firewall web interface, but not to the
CLI.
STEP 1 | Obtain the cerficates that the IdP and firewall will use to sign SAML messages.
If the cerficates don’t specify key usage aributes, all usages are allowed by default, including
signing messages. In this case, you can Obtain Cerficates by any method.
If the cerficates do specify key usage aributes, one of the aributes must be Digital
Signature, which is not available on cerficates that you generate on the firewall or Panorama.
In this case, you must import the cerficates:
• Cerficate the firewall uses to sign SAML messages—Import the cerficate from your
enterprise cerficate authority (CA) or a third-party CA.
• Cerficate the IdP uses to sign SAML messages (Required for all deployments)—Import a
metadata file containing the cerficate from the IdP (see the next step). The IdP cerficate is
limited to the following algorithms:
Public key algorithms—RSA (1,024 bits or larger) and ECDSA (all sizes). A firewall in FIPS/CC
mode supports RSA (2,048 bits or larger) and ECDSA (all sizes).
Signature algorithms—SHA1, SHA256, SHA384, and SHA512. A firewall in FIPS/CC mode
supports SHA256, SHA384, and SHA512.
Authencaon
STEP 2 | Add a SAML IdP server profile.

The server profile registers the IdP with the firewall and defines how they connect.
In this example, you import a SAML metadata file from the IdP so that the firewall can
automacally create a server profile and populate the connecon, registraon, and IdP
cerficate informaon.
If the IdP doesn’t provide a metadata file, select Device > Server Profiles > SAML
Identy Provider, Add the server profile, and manually enter the informaon (consult
your IdP administrator for the values).
1. Export the SAML metadata file from the IdP to a client system from which you can
upload the metadata to the firewall.
The cerficate specified in the file must meet the requirements listed in the preceding
step. Refer to your IdP documentaon for instrucons on exporng the file.
2. Select Device > Server Profiles > SAML Identy Provider or Panorama > Server Profiles
> SAML Identy Provider on Panorama™ and Import the metadata file onto the firewall.
3. Enter a Profile Name to idenfy the server profile.
4. Browse to the Identy Provider Metadata file.
5. Select Validate Identy Provider Cerficate (default) to validate the chain of trust and
oponally the revocaon status of the IdP cerficate.
To enable this opon, a Cerficate Authority (CA) must issue your IdP’s signing
cerficate. You must create a Cerficate Profile that has the CA that issued the IdP’s
signing cerficate. In the Authencaon Profile, select the SAML Server profile and
Cerficate Profile to validate the IdP cerficate.
If your IdP signing cerficate is a self-signed cerficate, there is no chain of trust; as
a result, you cannot enable this opon. The firewall always validates the signature of
the SAML Responses or Asserons against the Identy Provider cerficate that you
configure whether or not you enable the Validate Identy Provider Cerficate opon.
If your IdP provides a self-signed cerficate, ensure that you are using PAN-OS 10.1 to
migate exposure to CVE-2020-2021.
Validate the cerficate to ensure it hasn’t been compromised and to improve

security.
6. Enter the Maximum Clock Skew, which is the allowed difference in seconds between
the system mes of the IdP and the firewall at the moment when the firewall validates
IdP messages (default is 60; range is 1 to 900). If the difference exceeds this value,
authencaon fails.
7. Click OK to save the server profile.
8. Click the server profile Name to display the profile sengs. Verify that the imported
informaon is correct and edit it if necessary.
9. Whether you import the IdP metadata or manually enter the IdP informaon, always
ensure that the signing cerficate of your SAML identy provider is the Identy
Provider Cerficate for your server profile and your IdP sends signed SAML Responses,
Asserons, or both.
Authencaon

The profile defines authencaon sengs that are common to a set of users.
3. Set the Type to SAML.
4. Select the IdP Server Profile you configured.
5. Select the Cerficate for Signing Requests.
The firewall uses this cerficate to sign messages it sends to the IdP. You can import a
cerficate generated by your enterprise CA or you can generate a cerficate using the
root CA that was generated on the firewall or Panorama.
6. (Oponal) Enable Single Logout (disabled by default).
7. Select the Cerficate Profile that the firewall will use to validate the Identy Provider
Cerficate.
8. Enter the Username Aribute that IdP messages use to idenfy users (default
username).
When you predefine dynamic administrator roles for users, use lower-case to
specify the role (for example, enter superreader, not SuperReader). If you
manage administrator authorizaon in the IdP identy store, specify the Admin
Role Aribute and Access Domain Aribute also.
9. Select Advanced and Add the users and user groups that are allowed to authencate
with this authencaon profile.
STEP 4 | Assign the authencaon profile to firewall applicaons that require authencaon.
1. Assign the authencaon profile to:
• Administrator accounts that you manage locally on the firewall. In this example,
Configure a Firewall Administrator Account before you verify the SAML configuraon
later in this procedure.
• Administrator accounts that you manage externally in the IdP identy store. Select
Device > Setup > Management, edit the Authencaon Sengs, and select the
Authencaon Profile you configured.
• Authencaon policy rules that secure the services and applicaons that end users
access through Authencaon Portal. See Configure Authencaon Policy.
• GlobalProtect portals and gateways that end users access.
The firewall validates the Identy Provider Cerficate that you assigned to the SAML IdP
server profile.
Authencaon
STEP 5 | Create a SAML metadata file to register the firewall applicaon (management access,
Authencaon Portal, or GlobalProtect) on the IdP.
1. Select Device > Authencaon Profile and, in the Authencaon column for the
authencaon profile you configured, click Metadata.
2. In the Service drop-down, select the applicaon you want to register:
• management (default)—Administrave access to the web interface.
• authencaon-portal—End user access to services and applicaons through
Authencaon Portal.
• global-protect—End user access to services and applicaons through GlobalProtect.
3. (Authencaon Portal or GlobalProtect only) for the Vsysname Combo, select the virtual
system in which the Authencaon Portal sengs or GlobalProtect portal are defined.
4. Enter the interface, IP address, or hostname based on the applicaon you will register:
• management—For the Management Choice, select Interface (default) and select an
interface that is enabled for management access to the web interface. The default
selecon is the IP address of the MGT interface.
• authencaon-portal—For the IP Hostname, enter the IP address or hostname of the
Redirect Host (see Device > User Idenficaon > Authencaon Portal Sengs).
• global-protect—For the IP Hostname, enter the hostname or IP address of the
GlobalProtect portal or gateway.
5. Click OK and save the metadata file to your client system.
6. Import the metadata file into the IdP server to register the firewall applicaon. Refer to
your IdP documentaon for instrucons.
Authencaon
STEP 6 | Verify that users can authencate using SAML SSO.

For example, to verify that SAML is working for access to the web interface using a local
administrator account:
1. Go to the URL of the firewall web interface.
2. Click Use Single Sign-On.
3. Enter the username of the administrator.
4. Click Connue.
The firewall redirects you to authencate to the IdP, which displays a login page. For
example:
5. Log in using your SSO username and password.

Aer you successfully authencate on the IdP, it redirects you back to the firewall, which
displays the web interface.
6. Use your firewall administrator account to request access to another SSO applicaon.
Successful access indicates SAML SSO authencaon succeeded.
Authencaon
Configure Kerberos Single Sign-On

Palo Alto Networks firewalls and Panorama support Kerberos V5 single sign-on (SSO) to
authencate administrators to the web interface and end users to Authencaon Portal. With
Kerberos SSO enabled, the user needs to log in only for inial access to your network (such as
logging in to Microso Windows). Aer this inial login, the user can access any browser-based
service in the network (such as the firewall web interface) without having to log in again unl the
SSO session expires.
STEP 1 | Create a Kerberos keytab.
The keytab is a file that contains the principal name and password of the firewall, and is
required for the SSO process. When you configure Kerberos in your Authencaon Profile and
Sequence, the firewall first checks for a Kerberos SSO hostname. If you provide a hostname,
the firewall searches the keytabs for a service principal name that matches the hostname
and uses only that keytab for decrypon. If you do not provide a hostname, the firewall tries
Authencaon
each keytab in the authencaon sequence unl it is able to successfully authencate using
Kerberos.
If the Kerberos SSO hostname is included in the request sent to the firewall, then
the hostname must match the service principal name of the keytab; otherwise, the
Kerberos authencaon request is not sent.
1. Log in to the Acve Directory server and open a command prompt.

2. Enter the following command to register the service principal name (SPN)
for GlobalProtect or Authencaon Portal, where <portal_fqdn> and
<service_account_username> are variables.
setspn -s HTTP/<portal_fqdn> <service_account_username>
3. Create Kerberos account for the firewall. Refer to your Kerberos documentaon for the
steps.
4. Log in to the KDC and open a command prompt.
5. Enter the following command, where <portal_fqdn>, <kerberos_realm>, <netbios_name>,
<service_account_username>, <password>, <filename>, and <algorithm> are variables.
ktpass /princ HTTP <portal_fqdn>@<kerberos_realm> /mapuser
<netbios_name>\<service_account_username> /pass <password>/out
<filename>.keytab /ptype KRB5_NT_PRINCIPAL /crypto <algorithm>
The <kerberos_realm> value must be in all uppercase characters (for example,

enter AD1.EXAMPLE.COM, not ad1.example.com).
If the firewall is in FIPS/CC mode, the algorithm must be aes128-cts-hmac-

sha1-96 or aes256-cts-hmac-sha1-96. Otherwise, you can also use
des3-cbc-sha1 or arcfour-hmac. To use an Advanced Encrypon
Standard (AES) algorithm, the funconal level of the KDC must be Windows
Server 2012 or later and you must enable AES encrypon for the firewall
account.
The algorithm in the keytab must match the algorithm in the service cket
that the TGS issues to clients. Your Kerberos administrator determines which
algorithms the service ckets use.
STEP 2 | Configure an Authencaon Profile and Sequence to define Kerberos sengs and other
authencaon opons that are common to a set of users.
• Enter the Kerberos Realm (usually the DNS domain of the users, except that the realm is
uppercase).
• Import the Kerberos Keytab that you created for the firewall.
STEP 3 | Assign the authencaon profile to the firewall applicaon that requires authencaon.
• Administrave access to the web interface—Configure a Firewall Administrator Account and
assign the authencaon profile you configured.
• End user access to services and applicaons—Assign the authencaon profile you
configured to an authencaon enforcement object. When configuring the object, set
the Authencaon Method to browser-challenge. Assign the object to Authencaon
Authencaon
policy rules. For the full procedure to configure authencaon for end users, see Configure
Authencaon Policy.
Authencaon
Configure Kerberos Server Authencaon

You can use Kerberos to navely authencate end users and firewall or Panorama administrators
to an Acve Directory domain controller or a Kerberos V5-compliant authencaon server. This
authencaon method is interacve, requiring users to enter usernames and passwords.
To use a Kerberos server for authencaon, the server must be accessible over an IPv4
address. IPv6 addresses are not supported.
STEP 1 | Add a Kerberos server profile.

The profile defines how the firewall connects to the Kerberos server.
1. Select Device > Server Profiles > Kerberos or Panorama > Server Profiles > Kerberos on
Panorama™ and Add a server profile.
3. Add each server and specify a Name (to idenfy the server), IPv4 address or FQDN
of the Kerberos Server, and oponal Port number for communicaon with the server
(default 88).
If you use an FQDN address object to idenfy the server and you subsequently
change the address, you must commit the change in order for the new server
address to take effect.
4. Click OK to save your changes to the profile.
STEP 2 | Assign the server profile to an Configure an Authencaon Profile and Sequence.
The authencaon profile defines authencaon sengs that are common to a set of users.
• Administrave access to the web interface—Configure a Firewall Administrator Account and
assign the authencaon profile you configured.
• End user access to services and applicaons—Assign the authencaon profile you
configured to an authencaon enforcement object and assign the object to Authencaon
policy rules. For the full procedure to configure authencaon for end users, see Configure
STEP 4 | Verify that the firewall can Test Authencaon Server Connecvity to authencate users.
Authencaon
Configure TACACS+ Authencaon

You can configure TACACS+ authencaon for end users and firewall or Panorama administrators.
You can also use a TACACS+ server to manage administrator authorizaon (role and access
domain assignments) by defining Vendor-Specific Aributes (VSAs). For all users, you must
configure a TACACS+ server profile that defines how the firewall or Panorama connects to the
server. You then assign the server profile to an authencaon profile for each set of users who
require common authencaon sengs. What you do with the authencaon profile depends on
which users the TACACS+ server authencates:
• End users—Assign the authencaon profile to an authencaon enforcement object
and assign the object to Authencaon policy rules. For the full procedure, see Configure
• Administrave accounts with authorizaon managed locally on the firewall or Panorama—
Assign the authencaon profile to firewall administrator or Panorama administrator accounts.
• Administrave accounts with authorizaon managed on the TACACS+ server—The following
procedure describes how to configure TACACS+ authencaon and authorizaon for firewall
administrators. For Panorama administrators, refer to Configure TACACS+ Authencaon for
PanoramaAdministrators.
STEP 1 | Add a TACACS+ server profile.
The profile defines how the firewall connects to the TACACS+ server.
1. Select Device > Server Profiles > TACACS+ or Panorama > Server Profiles > TACAS+ on
Panorama™ and Add a profile.
3. (Oponal) Select Administrator Use Only to restrict access to administrators.
4. Enter a Timeout interval in seconds aer which an authencaon request mes out
(default is 3; range is 1–20).
5. Select the Authencaon Protocol (default is CHAP) that the firewall uses to
authencate to the TACACS+ server.
Select CHAP if the TACACS+ server supports that protocol; it is more secure
than PAP.
6. Add each TACACS+ server and enter the following:
• Name to idenfy the server
• TACACS+ Server IP address or FQDN. If you use an FQDN address object to idenfy
the server and you subsequently change the address, you must commit the change for
the new server address to take effect.
• Secret/Confirm Secret (a key to encrypt usernames and passwords)
• Server Port for authencaon requests (default is 49)
Authencaon
STEP 2 | Assign the TACACS+ server profile to an authencaon profile.

3. Set the Type to TACACS+.
4. Select the Server Profile you configured.
5. Select Retrieve user group from TACACS+ to collect user group informaon from VSAs
defined on the TACACS+ server.
The firewall matches the group informaon against the groups you specify in the Allow
List of the authencaon profile.
6. Select Advanced and, in the Allow List, Add the users and groups that are allowed to
authencate with this authencaon profile.
STEP 3 | Configure the firewall to use the authencaon profile for all administrators.
2. Select the Authencaon Profile you configured and click OK.
STEP 4 | Configure the roles and access domains that define authorizaon sengs for administrators.
If you already defined TACACS+ VSAs on the TACACS+ server, the names you specify for roles
and access domains on the firewall must match the VSA values.
1. Configure an Admin Role Profile if the administrator will use a custom role instead of a
predefined (dynamic) role.
2. Configure an access domain if the firewall has more than one virtual system—Select
Device > Access Domain, Add an access domain, enter a Name to idenfy the access
domain, and Add each virtual system that the administrator will access, and then click
OK.
STEP 5 | Commit your changes to acvate them on the firewall.
STEP 6 | Configure the TACACS+ server to authencate and authorize administrators.

Refer to your TACACS+ server documentaon for the specific instrucons to perform these
steps:
1. Add the firewall IP address or hostname as the TACACS+ client.
2. Add the administrator accounts.
If you selected CHAP as the Authencaon Protocol, you must define accounts
with reversibly encrypted passwords. Otherwise, CHAP authencaon will fail.
3. Define TACACS+ VSAs for the role, access domain, and user group of each administrator.
When you predefine dynamic administrator roles for users, use lower-case to
specify the role (for example, enter superuser, not SuperUser).
Authencaon
STEP 7 | Verify that the TACACS+ server performs authencaon and authorizaon for
administrators.
1. Log in the firewall web interface using an administrator account that you added to the
TACACS+ server.
2. Verify that you can access only the web interface pages that are allowed for the role you
associated with the administrator.
3. In the Monitor, Policies, and Objects tabs, verify that you can access only the virtual
systems that are allowed for the access domain you associated with the administrator.
Authencaon
Configure RADIUS Authencaon

You can configure RADIUS authencaon for end users and firewall or Panorama administrators.
For administrators, you can use RADIUS to manage authorizaon (role and access domain
assignments) by defining Vendor-Specific Aributes (VSAs). You can also use RADIUS to
implement Mul-Factor Authencaon (MFA) for administrators and end users. To enable RADIUS
authencaon, you must configure a RADIUS server profile that defines how the firewall or
Panorama connects to the server (see Step 1 below). You then assign the server profile to an
authencaon profile for each set of users who require common authencaon sengs (see Step
5 below). What you do with the authencaon profile depends on which users the RADIUS server
authencates:
• End users—Assign the authencaon profile to an authencaon enforcement object
and assign the object to Authencaon policy rules. For the full procedure, see Configure
You can also configure client systems to send RADIUS Vendor-Specific Aributes (VSAs)
to the RADIUS server by assigning the authencaon profile to a GlobalProtect portal or
gateway. RADIUS administrators can then perform administrave tasks based on those
VSAs.
• Administrave accounts with authorizaon managed locally on the firewall or Panorama—

Assign the authencaon profile to firewall administrator or Panorama administrator accounts.
• Administrave accounts with authorizaon managed on the RADIUS server—The following
procedure describes how to configure RADIUS authencaon and authorizaon for firewall
administrators. For Panorama administrators, refer to Configure RADIUS Authencaon for
PanoramaAdministrators.
Authencaon
STEP 1 | Add a RADIUS server profile.

The profile defines how the firewall connects to the RADIUS server.
1. Select Device > Server Profiles > RADIUS or Panorama > Server Profiles > RADIUS on
Panorama™and Add a profile.
4. Enter a Timeout interval in seconds aer which an authencaon request mes out
(default is 3; range is 1–120).
If you use the server profile to integrate the firewall with an MFA service, enter
an interval that gives users enough me to authencate. For example, if the MFA
service prompts for a one-me password (OTP), users need me to see the OTP
on their endpoint device and then enter the OTP in the MFA login page.
5. Enter the number of Retries.
6. Select the Authencaon Protocol (default is PEAP-MSCHAPv2) that the firewall uses
to authencate to the RADIUS server.
Depending on which factors you want to use to authencate users within your mul-
factor authencaon (MFA) environment, select the appropriate authencaon protocol:
• Username, password, and push (an automacally triggered out-of-band request):
Supported with all authencaon protocols
• Push, password, token, and PIN (when password or token or PIN are provided
together): Supported with PAP, PEAP with GTC, and EAP-TTLS with PAP
• Username, password, token, and PIN, and challenge-response (when password or
token or PIN are provided together): Supported with PAP and PEAP with GTC
If you select an EAP authencaon method (PEAP-MSCHAPv2, PEAP with GTC,
or EAP-TTLS with PAP), confirm that your RADIUS server supports Transport Layer
Security (TLS) 1.1 or higher and that the root and intermediate cerficate authories
(CAs) for your RADIUS server are included in the cerficate profile associated with the
RADIUS server profile. If you select an EAP method and you do not associate a correctly
configured cerficate profile with the RADIUS profile, authencaon fails.
7. Add each RADIUS server and enter the following:
• Name to idenfy the server
• RADIUS Server IP address or FQDN. If you use an FQDN to idenfy the server and
you subsequently change the address, you must commit the change for the new
server address to take effect.
• Secret/Confirm Secret is a key to encrypt passwords and can be up to 64 characters
in length.
• Server Port for authencaon requests (default is 1812)
For redundancy, add mulple RADIUS servers in the sequence you want the firewall to use.
If you have selected an EAP method, configure an authencaon sequence to ensure that
users will be able to successfully respond to the authencaon challenge. There is no alternate
authencaon method with EAP: if the user fails the authencaon challenge and you have
Authencaon
not configured an authencaon sequence that allows another authencaon method,

authencaon fails.
STEP 2 | If you are using PEAP-MSCHAPv2 with GlobalProtect, select Allow users to change
passwords aer expiry to allow GlobalProtect users to changed expired passwords to log in.
STEP 3 | (PEAP-MSCHAPv2, PEAP with GTC, or EAP-TTLS with PAP only) To anonymize the user’s
identy in the outer tunnel that is created aer authencang with the server, select Make
Outer Identy Anonymous.
You must configure the RADIUS server so that the enre chain allows access for
anonymous users. Some RADIUS server configuraons may not support anonymous
outer IDs, and you may need to clear the opon. When cleared, the RADIUS server
transmits usernames in cleartext.
STEP 4 | If you select an EAP authencaon method, select a Cerficate Profile.
STEP 5 | Assign the RADIUS server profile to an authencaon profile.

3. Set the Type to RADIUS.
4. Select the Server Profile you configured.
5. Select Retrieve user group from RADIUS to collect user group informaon from VSAs
defined on the RADIUS server.
The firewall matches the group informaon against the groups you specify in the Allow
List of the authencaon profile.
6. Select Advanced and, in the Allow List, Add the users and groups that are allowed to
authencate with this authencaon profile.
STEP 6 | Configure the firewall to use the authencaon profile for all administrators.
2. Select the Authencaon Profile you configured and click OK.
STEP 7 | Configure the roles and access domains that define authorizaon sengs for administrators.
If you already defined RADIUS VSAs on the RADIUS server, the names you specify for roles
and access domains on the firewall must match the VSA values.
1. Configure an Admin Role Profile if the administrator uses a custom role instead of a
predefined (dynamic) role.
2. Configure an access domain if the firewall has more than one virtual system:
1. Select Device > Access Domain, Add an access domain, and enter a Name to idenfy
the access domain.
2. Add each virtual system that the administrator will access, and then click OK.
Authencaon
STEP 8 | Commit your changes to acvate them on the firewall.
STEP 9 | Configure the RADIUS server to authencate and authorize administrators.

Refer to your RADIUS server documentaon for the specific instrucons to perform these
steps:
1. Add the firewall IP address or hostname as the RADIUS client.
2. Add the administrator accounts.
If the RADIUS server profile specifies CHAP as the Authencaon Protocol, you
must define accounts with reversibly encrypted passwords. Otherwise, CHAP
authencaon will fail.
3. Define the vendor code for the firewall (25461) and define the RADIUS VSAs for the
role, access domain, and user group of each administrator.
When you predefine dynamic administrator roles for users, use lower-case to specify the
role (for example, enter superuser, not SuperUser).
When configuring the advanced vendor opons on the ACS, you must set both
the Vendor Length Field Size and Vendor Type Field Size to 1. Otherwise,
authencaon will fail.
4. If you have selected an EAP method, the firewall validates the server but not the client.
To ensure client validity, restrict clients by IP address or subdomain.
STEP 10 | Verify that the RADIUS server performs authencaon and authorizaon for administrators.
1. Log in the firewall web interface using an administrator account that you added to the
RADIUS server.
2. Verify that you can access only the web interface pages that are allowed for the role you
associated with the administrator.
3. In the Monitor, Policies, and Objects tabs, verify that you can access only the virtual
systems that are allowed for the access domain you associated with the administrator.
4. In Monitor > Authencaon, verify the Authencaon Protocol.
5. Test the connecon and the validity of the cerficate profile using the following CLI
command:
admin@PA-220 > test authentication authentication-profile

auth-profile username <username> password <password>
Authencaon
Configure LDAP Authencaon

You can use LDAP to authencate end users who access applicaons or services through
Authencaon Portal and authencate firewall or Panorama administrators who access the web
interface.
You can also connect to an LDAP server to define policy rules based on user groups. For
details, see Map Users to Groups.
STEP 1 | Add an LDAP server profile.

The profile defines how the firewall connects to the LDAP server.
1. Select Device > Server Profiles > LDAP or Panorama > Server Profiles > LDAP on
Panorama™ and Add a server profile.
3. (Mul-vsys only) Select the Locaon in which the profile is available.
5. Add the LDAP servers (up to four). For each server, enter a Name (to idenfy the server),
LDAP Server IP address or FQDN, and server Port (default 389).
If you use an FQDN address object to idenfy the server and you subsequently
change the address, you must commit the change for the new server address to
take effect.
6. Select the server Type.
7. Select the Base DN.
To idenfy the Base DN of your directory, open the Acve Directory Domains and
Trusts Microso Management Console snap-in and use the name of the top-level
domain.
8. Enter the Bind DN and Password to enable the authencaon service to authencate
the firewall.
The Bind DN account must have permission to read the LDAP directory.
9. Enter the Bind Timeout and Search Timeout in seconds (default is 30 for both).
10. Enter the Retry Interval in seconds (default is 60).
11. Enable the opon to Require SSL/TLS secured connecon (enabled by default). The
protocol that the endpoint uses depends on the server port:
• 389 (default)—TLS (Specifically, the device uses the StartTLS operaon, which
upgrades the inial plaintext connecon to TLS.)
• 636—SSL
• Any other port—The device first aempts to use TLS. If the directory server doesn’t
support TLS, the device falls back to SSL.
12. (Oponal) For addional security, enable to the opon to Verify Server Cerficate
for SSL sessions so that the endpoint verifies the cerficate that the directory server
Authencaon
presents for SSL/TLS connecons. To enable verificaon, you must also enable the
opon to Require SSL/TLS secured connecon. For verificaon to succeed, the
cerficate must meet one of the following condions:
• It is in the list of device cerficates: Device > Cerficate Management > Cerficates >
Device Cerficates. If necessary, import the cerficate into the device.
• The cerficate signer is in the list of trusted cerficate authories: Device >
Cerficate Management > Cerficates > Default Trusted Cerficate Authories.
STEP 2 | Assign the server profile to Configure an Authencaon Profile and Sequence to define
various authencaon sengs.
• Administrave access to the web interface—Configure a Firewall Administrator Account
and assign the authencaon profile you configured.
• End user access to services and applicaons—For the full procedure to configure
authencaon for end users, see Configure Authencaon Policy.
Authencaon
Connecon Timeouts for Authencaon Servers

You can configure the firewall to use External Authencaon Services for authencang
administrators who access the firewall or Panorama and end users who access services or
applicaons through Authencaon Portal. To ensure that the firewall does not waste resources
by connuously trying to reach an authencaon server that is unreachable, you can set a meout
interval aer which the firewall stops trying to connect. You set the meout in the server profiles
that define how the firewall connects to the authencaon servers. When choosing meout
values, your goal is to strike a balance between the need to conserve firewall resources and to
account for normal network delays that affect how quickly authencaon servers respond to the
firewall.
• Guidelines for Seng Authencaon Server Timeouts
• Modify the PAN-OS Web Server Timeout
• Modify the Authencaon Portal Session Timeout
Guidelines for Seng Authencaon Server Timeouts

The following are some guidelines for seng the meouts for firewall aempts to connect with
External Authencaon Services.
In addion to the meouts you set in server profiles for specific servers, the firewall has a
global PAN-OS web server meout. This global meout applies when the firewall connects
to any external server for authencang administrave access to the firewall web interface
or PAN-OS XML API and end user access to applicaons or services through Authencaon
Portal. The global meout is 30 seconds by default (range is 3 to 125). It must be the same as
or greater than the total me that any server profile allows for connecon aempts. The total
me in a server profile is the meout value mulplied by the number of retries and the number
of servers. For example, if a RADIUS server profile specifies a 3-second meout, 3 retries, and 4
servers, the total me that the profile allows for connecon aempts is 36 seconds (3 x 3 x 4).
Modify the PAN-OS Web Server Timeout if necessary.
Do not change the PAN-OS web server meout unless you see authencaon
failures. Seng the meout too high could degrade the performance of the firewall
or cause it to drop authencaon requests. You can review authencaon failures in
Authencaon logs.
The firewall applies an Authencaon Portal session meout that defines how long end users
can take to respond to the authencaon challenge in a Authencaon Portal web form. The
web form displays when users request services or applicaons that match an Authencaon
policy rule. The session meout is 30 seconds by default (range is 1 to 1,599,999). It must
be the same as or greater than the PAN-OS web server meout. Modify the Authencaon
Portal Session Timeout if necessary. Keep in mind that increasing the PAN-OS web server and
Authencaon Portal session meouts might degrade the performance of the firewall or cause
it to drop authencaon requests.
The Authencaon Portal session meout is not related to the mers that determine
how long the firewall retains IP address-to-username mappings.
Authencaon
Timeouts are cumulave for authencaon sequences. For example, consider the case of
an authencaon sequence with two authencaon profiles. One authencaon profile
specifies a RADIUS server profile with a 3-second meout, 3 retries, and 4 servers. The other
authencaon profile specifies a TACACS+ server profile with a 3-second meout and 2
servers. The longest possible period in which the firewall can try to authencate user accounts
with that authencaon sequence is 42 seconds: 36 seconds for the RADIUS server profile
plus 6 seconds for the TACACS+ server profile.
The non-configurable meout for Kerberos servers is 17 seconds for each server specified in
the Kerberos server profile.
To configure the meouts and related sengs for other server types, see:
Modify the PAN-OS Web Server Timeout

The PAN-OS web server meout must be the same as or greater than the meout in any
authencaon server profile mulplied by the number of retries and the number of servers in that
profile.
Do not change the PAN-OS web server meout unless you see authencaon failures.
Seng the meout too high could degrade the performance of the firewall or cause it to
drop authencaon requests. You can review authencaon failures in Authencaon
logs.
STEP 1 | Access the firewall CLI.
STEP 2 | Set the PAN-OS web server meout by entering the following commands, where <value> is
the number of seconds (default is 30; range is 3 to 125).
> configure
# set deviceconfig setting l3-service timeout <value>
# commit
Modify the Authencaon Portal Session Timeout

The Authencaon Portal session meout must be the same as or greater than the PAN-OS web
server meout. For details, see Connecon Timeouts for Authencaon Servers.
The more you raise the PAN-OS web server and Authencaon Portal session meouts,
the slower Authencaon Portal will respond to users.
STEP 1 | Select Device > Setup > Session and edit the Session Timeouts.
Authencaon
STEP 2 | Enter a new Authencaon Portal value in seconds (default is 30; range is 1 to 1,599,999)
and click OK.
Authencaon
Configure Local Database Authencaon

You can configure a user database that is local to the firewall to authencate administrators
who access the firewall web interface and to authencate end users who access applicaons
through Authencaon Portal or GlobalProtect. Perform the following steps to configure Local
Authencaon with a local database.
External Authencaon Services are usually preferable to local authencaon because

they provide the benefit of central account management.
You can also configure local authencaon without a database, but only for firewall or
STEP 1 | Add the user account to the local database.

1. Select Device > Local User Database > Users and click Add.
2. Enter a user Name for the administrator.
3. Enter a Password and Confirm Password or enter a Password Hash.
4. Enable the account (enabled by default) and click OK.
STEP 2 | Add the user group to the local database.

Required if your users require group membership.
1. Select Device > Local User Database > User Groups and click Add.
2. Enter a Name to idenfy the group.
3. Add each user who is a member of the group and click OK.

Set the authencaon Type to Local Database.
STEP 4 | Assign the authencaon profile to an administrator account or to an Authencaon policy

rule for end users.
• Administrators—Configure a Firewall Administrator Account:
Specify the Name of a user you defined earlier in this procedure.
Assign the Authencaon Profile that you configured for the account.
• End users—For the full procedure to configure authencaon for end users, see Configure
Authencaon
Configure an Authencaon Profile and Sequence

An authencaon profile defines the authencaon service that validates the login credenals
of administrators who access the firewall web interface and end users who access applicaons
through Authencaon Portal or GlobalProtect. The service can be Local Authencaon that
the firewall provides or External Authencaon Services. The authencaon profile also defines
opons such as Kerberos single sign-on (SSO).
Some networks have mulple databases (such as TACACS+ and LDAP) for different users and user
groups. To authencate users in such cases, configure an authencaon sequence—a ranked order
of authencaon profiles that the firewall matches a user against during login. The firewall checks
against each profile in sequence unl one successfully authencates the user. A user is denied
access only if authencaon fails for all the profiles in the sequence. The sequence can specify
authencaon profiles that are based on any authencaon service that the firewall supports
excepts Mul-Factor Authencaon (MFA) and SAML.
STEP 1 | (External service only) Enable the firewall to connect to an external server for authencang
users:
1. Set up the external server. Refer to your server documentaon for instrucons.
2. Configure a server profile for the type of authencaon service you use.
If the firewall integrates with an MFA service through RADIUS, you must
add a RADIUS server profile. In this case, the MFA service provides all the
authencaon factors. If the firewall integrates with an MFA service through a
vendor API, you can sll use a RADIUS server profile for the first factor but MFA
server profiles are required for addional factors.

STEP 2 | (Local database authencaon only) Configure a user database that is local to the firewall.
Perform these steps for each user and user group for which you want to configure Local
Authencaon based on a user identy store that is local to the firewall:
1. Add the user account to the local database.
2. (Oponal) Add the user group to the local database.
STEP 3 | (Kerberos SSO only) Create a Kerberos keytab for the firewall if Kerberos single sign-on (SSO)
is the primary authencaon service.
Create a Kerberos keytab. A keytab is a file that contains Kerberos account informaon for the
firewall. To support Kerberos SSO, your network must have a Kerberos infrastructure.
Authencaon

Define one or both of the following:
• Kerberos SSO—The firewall first tries SSO authencaon. If that fails, it falls back to the
specified authencaon Type.
• External authencaon or local database authencaon—The firewall prompts the user to
enter login credenals, and uses an external service or local database to authencate the
user.
1. Select Device > Authencaon Profile and Add the authencaon profile.
3. Select the Type of authencaon service.
• If you use Mul-Factor Authencaon, the selected type applies only to the first
authencaon factor. You select services for addional MFA factors in the Factors
tab.
• If you select RADIUS, TACACS+, LDAP, or Kerberos, select the Server Profile.
• If you select LDAP, select the Server Profile and define the Login Aribute. For Acve
Directory, enter sAMAccountName as the value.
• If you select SAML, select the IdP Server Profile.
• If you select Cloud Authencaon Service, configure a Cloud Identy Engine instance
to communicate with the firewall. For more informaon on the Cloud Identy Engine,
see the Cloud Identy Engine Geng Started guide.
4. If you want to enable Kerberos SSO, enter the Kerberos Realm (usually the DNS domain
of the users, except that the realm is UPPERCASE) and Import the Kerberos Keytab that
you created for the firewall or Panorama.
5. (MFA only) Select Factors, Enable Addional Authencaon Factors, and Add the MFA
server profiles you configured.
The firewall will invoke each MFA service in the listed order, from top to boom.
6. Select Advanced and Add the users and groups that can authencate with this profile.
You can select users and groups from the local database or, if you configured the firewall
to Map Users to Groups, from an LDAP-based directory service such as Acve Directory.
By default, the list is empty, meaning no users can authencate.
You can also select custom groups defined in a group mapping configuraon.
7. (Oponal) To modify the user informaon before the firewall sends the authencaon
request to the server, configure a Username Modifier.
• %USERDOMAIN%\%USERINPUT%—If the source does not include the domain
(for example, it uses the sAMAccountName), the firewall adds the User Domain you
specify before the username. If the source includes the domain, the firewall replaces
that domain with the User Domain. If the User Domain is empty, the firewall removes
Authencaon
the domain from the user informaon that the firewall receives from source before
the firewall sends the request to the authencaon server.
Because LDAP servers do not support backslashes in the sAMAccountName,

do not use this opon to authencate with an LDAP server.
• %USERINPUT%—(Default) The firewall sends the user informaon to the
authencaon server in the format it receives from the source.
• %USERINPUT%@%USERDOMAIN%—If the source does not include the domain,
the firewall adds the User Domain value aer the username. If the source includes
domain, the firewall replaces that domain with the User Domain value. If the User
Domain is empty, the firewall removes the domain from the user informaon that
the firewall receives from the source before the firewall sends the request to the
authencaon server.
• None—If you manually enter None:
• For LDAP and Kerberos server profiles, the firewall uses the domain it receives
from the source to select the appropriate authencaon profile, then removes
the domain when it sends the authencaon request to the server. This allows
you to include the User Domain during the authencaon sequence but remove
the domain before the firewall sends the authencaon request to the server. For
example, if you are using an LDAP server profile and the samAccountName as
the aribute, use this opon so that the firewall does not send the domain to the
authencaon server that expects only a username and not a domain.
• For RADIUS server profiles:
• If the source sends the user informaon in domain\username format, the
firewall sends the user informaon to the server in the same format.
• If the source sends the user informaon in username@domain format, the
firewall normalizes the user informaon to the domain\username format
before sending it to the server.
• If the source sends only the username, the firewall adds the User Domain you
specify before sending the informaon to the server in domain\username
format.
• For local databases, TACACS+, and SAML, the firewall sends the user informaon
to the authencaon server in the format it receives from the source.
Authencaon
STEP 5 | Configure an authencaon sequence.

Required if you want the firewall to try mulple authencaon profiles to authencate
users. The firewall evaluates the profiles in top-to-boom order unl one profile successfully
authencates the user.
1. Select Device > Authencaon Sequence and Add the authencaon sequence.
2. Enter a Name to idenfy the authencaon sequence.
To expedite the authencaon process, Use domain to determine

authencaon profile: the firewall matches the domain name that a user enters
during login with the User Domain or Kerberos Realm of an authencaon
profile in the sequence, and then uses that profile to authencate the user. If the
firewall does not find a match, or if you disable the opon, the firewall tries the
profiles in the top-to-boom sequence.
3. Add each authencaon profile. To change the evaluaon order of the profiles, select a
profile and Move Up or Move Down.
4. Click OK to save the authencaon sequence.
STEP 6 | Assign the authencaon profile or sequence to an administrave account for firewall
administrators or to Authencaon policy for end users.
• Administrators—Assign the authencaon profile based on how you manager administrator
authorizaon:
Authorizaon managed locally on the firewall—Configure a Firewall Administrator Account.
Authorizaon managed on a SAML, TACACS+, or RADIUS server—Select Device > Setup >
Management, edit the Authencaon Sengs, and select the Authencaon Profile.
• End users—For the full procedure to configure authencaon for end users, see Configure
Authencaon
Test Authencaon Server Connecvity

The test authencaon feature enables you to verify whether the firewall or Panorama can
communicate with the authencaon server specified in an authencaon profile and whether
an authencaon request succeeds for a specific user. You can test authencaon profiles
that authencate administrators who access the web interface or that authencate end users
who access applicaons through GlobalProtect or Authencaon Portal. You can perform
authencaon tests on the candidate configuraon to verify the configuraon is correct before
comming.
STEP 1 | Configure an authencaon profile. You do not need to commit the authencaon profile or
server profile configuraon before tesng.
STEP 2 | Log into the firewall CLI.
STEP 3 | (Firewalls with mulple virtual systems) Define the target virtual system that the test
command will access.
This is required on firewalls with mulple virtual systems so that the test authencaon
command can locate the user you will test.
Define the target virtual system by entering:
admin@PA-325060> set system setting target-vsys <vsys-name>
For example, if the user is defined in vsys2, enter:
admin@PA-3250> set system setting target-vsys vsys2
The target-vsys opon is per login session; the firewall clears the opon when you
log off.
Authencaon
STEP 4 | Test the authencaon profile by entering the following command:
admin@PA-3250> test authentication authentication-

profile <authentication-profile-name> username <username> password
For example, to test an authencaon profile named my-profile for a user named
bsimpson, enter:
admin@PA-3250> test authentication authentication-profile my-

profile username bsimpson password
When running the test command, the names of authencaon profiles and server
profiles are case sensive. Also, if an authencaon profile has a username modifier
defined, you must enter the modifier with the username. For example, if you add the
username modifier %USERINPUT%@%USERDOMAIN% for a user named bsimpson
and the domain name is mydomain.com, enter [email protected]
as the username. This ensures that the firewall sends the correct credenals to the
authencaon server. In this example, mydomain.com is the domain that you define in
the User Domain field in the authencaon profile.
STEP 5 | View the test output.

If the authencaon profile is configured correctly, the output displays Authentication
succeeded. If there is a configuraon issue, the output displays informaon to help you
troubleshoot the configuraon.
The output results vary based on several factors related to the authencaon type that
you are tesng as well as the type of issue. For example, RADIUS and TACACS+ use
different underlying libraries, so the same issue that exists for both of these types will
produce different errors. Also, if there is a network problem, such as using an incorrect
port or IP address in the authencaon server profile, the output error is not specific.
This is because the test command cannot perform the inial handshake between the
firewall and the authencaon server to determine details about the issue.
Authencaon
Authencaon Policy
Authencaon policy enables you to authencate end users before they can access services and
applicaons. Whenever a user requests a service or applicaon (such as by vising a web page),
the firewall evaluates Authencaon policy. Based on the matching Authencaon policy rule, the
firewall then prompts the user to authencate using one or more methods (factors), such as login
and password, Voice, SMS, Push, or One-me Password (OTP) authencaon. For the first factor,
users authencate through a Authencaon Portal web form. For any addional factors, users
authencate through a Mul-Factor Authencaon (MFA) login page.
To implement Authencaon policy for GlobalProtect, refer to Configure GlobalProtect to

facilitate mul-factor authencaon noficaons.
Aer the user authencates for all factors, the firewall evaluates Security Policy to determine
whether to allow access to the service or applicaon.
To reduce the frequency of authencaon challenges that interrupt the user workflow, you can
specify a meout period during which a user authencates only for inial access to services and
applicaons, not for subsequent access. Authencaon policy integrates with Authencaon
Portal to record the mestamps used to evaluate the meout and to enable user-based policies
and reports.
Based on user informaon that the firewall collects during authencaon, User-ID creates a
new IP address-to-username mapping or updates the exisng mapping for that user (if the
mapping informaon has changed). The firewall generates User-ID logs to record the addions
and updates. The firewall also generates an Authencaon log for each request that matches an
Authencaon rule. If you favor centralized monitoring, you can configure reports based on User-
ID or Authencaon logs and forward the logs to Panorama or external services as you would for
any other log types.
• Authencaon Timestamps
• Configure Authencaon Policy
Authencaon Timestamps
When configuring an Authencaon policy rule, you can specify a meout period during which a
user authencates only for inial access to services and applicaons, not for subsequent access.
Your goal is to specify a meout that strikes a balance between the need to secure services
and applicaons and the need to minimize interrupons to the user workflow. When a user
authencates, the firewall records a mestamp for the first authencaon challenge (factor)
and a mestamp for any addional Mul-Factor Authencaon (MFA) factors. When the user
subsequently requests services and applicaons that match an Authencaon rule, the firewall
evaluates the meout specified in the rule relave to each mestamp. This means the firewall
reissues authencaon challenges on a per-factor basis when meouts expire. If you Redistribute
User Mappings and Authencaon Timestamps, all your firewalls will enforce Authencaon
policy meouts consistently for all users.
Authencaon
The firewall records a separate mestamp for each MFA vendor. For example, if you use
Duo v2 and PingID servers to issue challenges for MFA factors, the firewall records one
mestamp for the response to the Duo factor and one mestamp for the response to the
PingID factor.
Within the meout period, a user who successfully authencates for one Authencaon rule
can access services or applicaons that other rules protect. However, this portability applies
only to rules that trigger the same authencaon factors. For example, a user who successfully
authencates for a rule that triggers TACACS+ authencaon must authencate again for a rule
that triggers SAML authencaon, even if the access requests are within the meout period for
both rules.
When evaluang the meout in each Authencaon rule and the global mer defined in the
Authencaon Portal sengs (see Configure Authencaon Portal), the firewall prompts the user
to re-authencate for whichever seng expires first. Upon re-authencang, the firewall records
new authencaon mestamps for the rules and resets the me count for the Authencaon
Portal mer. Therefore, to enable different meout periods for different Authencaon rules, set
the Authencaon Portal mer to a value that is the same as or higher than the meout in any
rule.
Configure Authencaon Policy

Perform the following steps to configure Authencaon policy for end users who access services
through Authencaon Portal. Before starng, ensure that your Security Policy allows users to
access the services and URL categories that require authencaon.
STEP 1 | Configure Authencaon Portal. If you use Mul-Factor Authencaon (MFA) services to
authencate users, you must set the Mode to Redirect.
STEP 2 | Configure the firewall to use one of the following services to authencate users.
• External Authencaon Services—Configure a server profile to define how the firewall
connects to the service.
• Local database authencaon—Add each user account to the local user database on the
firewall.
• Kerberos single sign-on (SSO)—Create a Kerberos keytab for the firewall. Oponally, you can
configure the firewall to use Kerberos SSO as the primary authencaon service and, if SSO
failures occur, fall back to an external service or local database authencaon.
STEP 3 | Configure an Authencaon Profile and Sequence for each set of users and Authencaon
policy rules that require the same authencaon services and sengs.
Select the Type of authencaon service and related sengs:
• External service—Select the Type of external server and select the Server Profile you
created for it.
• Local database authencaon—Set the Type to Local Database. In the Advanced sengs,
Add the Authencaon Portal users and user groups you created.
• Kerberos SSO—Specify the Kerberos Realm and Import the Kerberos Keytab.
Authencaon
STEP 4 | Configure an authencaon enforcement object.

The object associates each authencaon profile with an Authencaon Portal method.
The method determines whether the first authencaon challenge (factor) is transparent or
requires a user response.
1. Select Objects > Authencaon and Add an object.
2. Enter a Name to idenfy the object.
3. Select an Authencaon Method for the authencaon service Type you specified in
the authencaon profile:
• browser-challenge—Select this method if you want the client browser to respond to
the first authencaon factor instead of having the user enter login credenals. For
this method, you must configure Kerberos SSO in the authencaon profile. If the
browser challenge fails, the firewall falls back to the web-form method.
• web-form—Select this method if you want the firewall to display a Authencaon
Portal web form for users to enter login credenals.
4. Select the Authencaon Profile you configured.
5. Enter the Message that the Authencaon Portal web form will display to tell users how
to authencate for the first authencaon factor.
6. Click OK to save the object.
Authencaon
STEP 5 | Configure an Authencaon policy rule.

Create a rule for each set of users, services, and URL categories that require the same
authencaon services and sengs.
The firewall does not apply the Authencaon Portal meout if your authencaon
policy uses default authencaon enforcement objects (for example, default-browser-
challenge).To require users to re-authencate aer the Authencaon Portal meout,
clone the rule for the default authencaon object and move it before the exisng rule
for the default authencaon object.
1. Select Policies > Authencaon and Add a rule.

2. Enter a Name to idenfy the rule.
3. Select Source and Add specific zones and IP addresses or select Any zones or IP
addresses.
The rule applies only to traffic coming from the specified IP addresses or from interfaces
in the specified zones.
4. Select User and select or Add the source users and user groups to which the rule applies
(default is any).
5. Select or Add the Host Informaon Profiles to which the rule applies (default is any).
6. Select Desnaon and Add specific zones and IP addresses or select any zones or IP
addresses.
The IP addresses can be resources (such as servers) for which you want to control access.
7. Select Service/URL Category and select or Add the services and service groups for
which the rule controls access (default is service-hp).
8. Select or Add the URL Categories for which the rule controls access (default is any).
For example, you can create a custom URL category that specifies your most sensive
internal sites.
9. Select Acons and select the Authencaon Enforcement object you created.
10. Specify the Timeout period in minutes (default 60) during which the firewall prompts the
user to authencate only once for repeated access to services and applicaons.
Timeout is a tradeoff between ghter security (less me between authencaon

prompts) and the user experience (more me between authencaon prompts).
More frequent authencaon is oen the right choice for access to crical
systems and sensive areas such as a data center. Less frequent authencaon
is oen the right choice at the network perimeter and for businesses for which
the user experience is key.
STEP 6 | (MFA only) Customize the MFA login page.

The firewall displays this page so that users can authencate for any addional MFA factors.
Authencaon
STEP 7 | Verify that the firewall enforces Authencaon policy.

1. Log in to your network as one of the source users specified in an Authencaon policy
rule.
2. Request a service or URL category that matches one specified in the rule.
The firewall displays the Authencaon Portal web form for the first authencaon
factor. For example:
If you configured the firewall to use one or more MFA services, authencate for
the addional authencaon factors.
3. End the session for the service or URL you just accessed.
4. Start a new session for the same service or applicaon. Be sure to perform this step
within the Timeout period you configured in the Authencaon rule.
The firewall allows access without re-authencang.
5. Wait unl the Timeout period expires and request the same service or applicaon.
The firewall prompts you to re-authencate.
STEP 8 | (Oponal) Redistribute Data and Authencaon Timestamps to other firewalls that enforce
Authencaon policy to ensure they all apply the meouts consistently for all users.
Authencaon
Troubleshoot Authencaon Issues

When users fail to authencate to a Palo Alto Networks firewall or Panorama, or the
Authencaon process takes longer than expected, analyzing authencaon-related informaon
can help you determine whether the failure or delay resulted from:
• User behavior—For example, users are locked out aer entering the wrong credenals or a high
volume of users are simultaneously aempng access.
• System or network issues—For example, an authencaon server is inaccessible.
• Configuraon issues—For example, the Allow List of an authencaon profile doesn’t have all
the users it should have.
The following CLI commands display informaon that can help you troubleshoot these issues:
Task Command
Display the number of locked user accounts

associated with the authencaon profile PA-220> show authentication lock
(auth-profile), authencaon sequence ed-users
(is-seq), or virtual system (vsys). {
vsys <value> |
auth-profile <value> |
To unlock users, use the following is-seq
operaonal command: {yes | no}
{auth-profile | vsys} <val
ue>
> request }
authentication [unlock-admin | u
nlock-user]
Use the debug authentication command

to troubleshoot authencaon events. PA-220> debug authentication
{
Use the show opons to display on {debug | dump | error | in
authencaon request stascs and the fo | warn} |
current debugging level: show |
show-active-requests |
• show displays the current debugging level show-pending-requests |
for the authencaon service (authd). connection-show |
{
• show-active-requests displays the connection-id |
number of acve checks for authencaon protocol-type
requests, allow lists, locked user accounts, {
and Mul-Factor Authencaon (MFA) Kerberos connection-id
requests. <value> |
LDAP connection-id <val
• show-pending-requests displays ue> |
the number of pending checks for RADIUS connection-id <v
authencaon requests, allow lists, locked alue> |
user accounts, and MFA requests. TACACS+ connection-id <
value> |
}
Authencaon
Task Command
• connection-show displays connection-debug-on |
authencaon request and response {
stascs for all authencaon servers or connection-id |
debug-prefix |
for a specific protocol type. protocol-type
Use the connection-debug opons to {
enable or disable authencaon debugging: Kerberos connection-id
<value> |
• Use the on opon to enable or the off LDAP connection-id <val
opon to disable debugging for authd. ue> |
RADIUS connection-id <v
• Use the connection-debug-on opon alue> |
to enable or the connection-debug- TACACS+ connection-id <
off opon to disable debugging for all value> |
authencaon servers or for a specific }
connection-debug-off |
protocol type.
{
connection-id |
protocol-type
{
Kerberos connection-id
<value> |
LDAP connection-id <val
ue> |
RADIUS connection-id <v
alue> |
TACACS+ connection-id <
value> |
}
connection-debug-on
}
Test the connecon and validity of the

cerficate profile. PA-220> test authentication auth
entication-profile auth-profile
username <username>password <pas
sword>
Troubleshoot a specific authencaon using

the Authencaon ID displayed in Monitor > PA-220> grep <Authentication ID>
Logs > Authencaon.
Cerficate Management
The following topics describe the different keys and cerficates that Palo Alto
Networks® firewalls and Panorama use, and how to obtain and manage them:
> Keys and Cerficates > Export a Cerficate and Private Key
> Default Trusted Cerficate > Configure a Cerficate Profile
Authories (CAs) > Configure an SSL/TLS Service Profile
> Cerficate Revocaon > Configure an SSH Service Profile
> Cerficate Deployment > Replace the Cerficate for Inbound
> Set Up Verificaon for Cerficate Management Traffic
Revocaon Status > Configure the Key Size for SSL
> Configure the Master Key Forward Proxy Server Cerficates
> Master Key Encrypon > Revoke and Renew Cerficates
> Obtain Cerficates > Secure Keys with a Hardware
Security Module
293
Cerficate Management
Keys and Cerficates

To ensure trust between pares in a secure communicaon session, Palo Alto Networks firewalls
and Panorama use digital cerficates. Each cerficate contains a cryptographic key to encrypt
plaintext or decrypt ciphertext. Each cerficate also includes a digital signature to authencate
the identy of the issuer. The issuer must be in the list of trusted cerficate authories (CAs) of
the authencang party. Oponally, the authencang party verifies the issuer did not revoke the
cerficate (see Cerficate Revocaon).
Palo Alto Networks firewalls and Panorama use cerficates in the following applicaons:
• User authencaon for Authencaon Portal, mul-factor authencaon (MFA), and web
interface access to a firewall or Panorama.
• Device authencaon for GlobalProtect VPN (remote user-to-site or large scale).
• Device authencaon for IPSec site-to-site VPN with Internet Key Exchange (IKE).
• External dynamic list (EDL) validaon.
• User-ID agent and TS agent access.
• Decrypng inbound and outbound SSL traffic.
A firewall decrypts the traffic to apply policy rules, then re-encrypts it before forwarding the
traffic to the final desnaon. For outbound traffic, the firewall acts as a forward proxy server,
establishing an SSL/TLS connecon to the desnaon server. To secure a connecon between
itself and the client, the firewall uses a signing cerficate to automacally generate a copy of the
desnaon server cerficate.
The following table describes the keys and cerficates that Palo Alto Networks firewalls and
Panorama use. As a best pracce, use different keys and cerficates for each usage.
Table 1: Palo Alto Networks Device Keys/Certificates
Key/Cerficate Descripon
Usage
Administrave Secure access to firewall or Panorama administraon interfaces

Access (HTTPS access to the web interface) requires a server cerficate for
the MGT interface (or a designated interface on the dataplane if the
firewall or Panorama does not use MGT) and, oponally, a cerficate to
authencate the administrator.
Authencaon In deployments where Authencaon policy idenfies users who access

Portal HTTPS resources, designate a server cerficate for the Authencaon
Portal interface. If you configure Authencaon Portal to use
cerficates for idenfying users (instead of, or in addion to, interacve
authencaon), deploy client cerficates also. For more informaon
on Authencaon Portal, see Map IP Addresses to Usernames Using
Authencaon Portal.
Usage
Forward Trust For outbound SSL/TLS traffic, if a firewall acng as a forward proxy
trusts the CA that signed the cerficate of the desnaon server, the
firewall uses the forward trust CA cerficate to generate a copy of the
desnaon server cerficate to present to the client. To set the private
key size, see Configure the Key Size for SSL Forward Proxy Server
Cerficates. For added security, store the key on a hardware security
module (for details, see Secure Keys with a Hardware Security Module).
Forward Untrust For outbound SSL/TLS traffic, if a firewall acng as a forward proxy
does not trust the CA that signed the cerficate of the desnaon
server, the firewall uses the forward untrust CA cerficate to generate a
copy of the desnaon server cerficate to present to the client.
SSL Inbound The keys that decrypt inbound SSL/TLS traffic for inspecon and policy
Inspecon enforcement. For this applicaon, import onto the firewall a private
key for each server that is subject to SSL/TLS inbound inspecon. See
Configure SSL Inbound Inspecon.
Beginning in PAN-OS 8.0, firewalls use the Ellipc-Curve

Diffie-Hellman Ephemeral (ECDHE) algorithm to perform
strict cerficate checking. This means that if the firewall
uses an intermediate cerficate, you must reimport the
cerficate from your web server to the firewall aer you
upgrade to a PAN-OS 8.0 or later release and combine the
server cerficate with the intermediate cerficate (install
a chained cerficate). Otherwise, SSL Inbound Inspecon
sessions that have an intermediate cerficate in the chain
will fail. To install a chained cerficate:
1. Open each cerficate (.cer) file in a plain-text editor such
as Notepad.
2. Paste each cerficate end-to-end with the Server
Cerficate at the top with each signer included below.
3. Save the file as a text (.txt) or cerficate (.cer) file (the
name of the file cannot contain blank spaces).
4. Import the combined (chained) cerficate into the firewall.
SSL Exclude Cerficates for servers to exclude from SSL/TLS decrypon. For
Cerficate example, if you enable SSL decrypon but your network includes
servers for which the firewall should not decrypt traffic (for example,
web services for your HR systems), import the corresponding
cerficates onto the firewall and configure them as SSL Exclude
Cerficates. See Decrypon Exclusions.
Usage
GlobalProtect All interacon among GlobalProtect components occurs over SSL/

TLS connecons. Therefore, as part of the GlobalProtect deployment,
deploy server cerficates for all GlobalProtect portals, gateways,
and Mobile Security Managers. Oponally, deploy cerficates for
authencang users also.
The GlobalProtect Large Scale VPN (LSVPN) feature

requires a CA signing cerficate.
Site-to-Site VPNs In a site-to-site IPSec VPN deployment, peer devices use Internet Key
(IKE) Exchange (IKE) gateways to establish a secure channel. IKE gateways
use cerficates or preshared keys to authencate the peers to each
other. You configure and assign the cerficates or keys when defining
an IKE gateway on a firewall. See Site-to-Site VPN Overview.
Master Key The firewall uses a master key to encrypt all private keys and
passwords. If your network requires a secure locaon for storing private
keys, you can use an encrypon (wrapping) key stored on a hardware
security module (HSM) to encrypt the master key. For details, see
Encrypt a Master Key Using an HSM.
Secure Syslog The cerficate to enable secure connecons between the firewall and a
syslog server. See Syslog Field Descripons.
Trusted Root CA The designaon for a root cerficate issued by a CA that the firewall
trusts. The firewall can use a self-signed root CA cerficate to
automacally issue cerficates for other applicaons (for example, SSL
Forward Proxy).
Also, if a firewall must establish secure connecons with other firewalls,
the root CA that issues their cerficates must be in the list of trusted
root CAs on the firewall.
Inter-Device By default, Panorama, firewalls, and Log Collectors use a set of

Communicaon predefined cerficates for the SSL/TLS connecons used for
management and log forwarding. However, you can enhance these
connecon by deploying custom cerficates to the devices in your
deployment. These cerficates can also be used to secure the SSL/TLS
connecon between Panorama HA peers.
Default Trusted Cerficate Authories (CAs)

The firewall trusts the most common and trusted authories (CAs) by default. These trusted
cerficate providers are responsible for issuing the cerficates the firewall requires to secure
connecons to the internet.
To view and manage the list of CAs that the firewall trusts by default, select Device > Cerficate
Management > Cerficates > Default Trusted Cerficate Authories:
The only addional CAs you might want to add are trusted enterprise CAs that your organizaon
requires—see Obtain Cerficates.
Cerficate Revocaon
Palo Alto Networks firewalls and Panorama use digital cerficates to ensure trust between pares
in a secure communicaon session. Configuring a firewall or Panorama to check the revocaon
status of cerficates provides addional security. A party that presents a revoked cerficate is not
trustworthy. When a cerficate is part of a chain, the firewall or Panorama checks the status of
every cerficate in the chain except the root CA cerficate, for which it cannot verify revocaon
status.
Various circumstances can invalidate a cerficate before the expiraon date. Some examples are
a change of name, change of associaon between subject and cerficate authority (for example,
an employee terminates employment), and compromise (known or suspected) of the private key.
Under such circumstances, the cerficate authority that issued the cerficate must revoke it.
The firewall and Panorama support the following methods for verifying cerficate revocaon
status. If you configure both methods, the firewall or Panorama first tries the OCSP method; if the
OCSP server is unavailable, it uses the CRL method.
• Cerficate Revocaon List (CRL)
• Online Cerficate Status Protocol (OCSP)
In PAN-OS, cerficate revocaon status verificaon is an oponal feature. It is a best

pracce to enable it for cerficate profiles, which define user and device authencaon for
Authencaon Portal, GlobalProtect, site-to-site IPSec VPN, and web interface access to
the firewall or Panorama, to verify that the cerficate hasn’t been revoked.
Cerficate Revocaon List (CRL)

Each cerficate authority (CA) periodically issues a cerficate revocaon list (CRL) to a public
repository. The CRL idenfies revoked cerficates by serial number. Aer the CA revokes a
cerficate, the next CRL update will include the serial number of that cerficate. The firewall
supports CRLs in Disnguished Encoding Rules (DER) and Privacy Enhanced Mail (PEM) formats.
The Palo Alto Networks firewall downloads and caches the last-issued CRL for every CA listed
in the trusted CA list of the firewall. Caching only applies to validated cerficates; if a firewall
never validated a cerficate, the firewall cache does not store the CRL for the issuing CA. Also, the
cache only stores a CRL unl it expires.
If you configure mulple CRL distribuon points (CDPs) and the firewall cannot reach the
first CDP, the firewall does not check the remaining CDPs. To redirect invalid CRL requests,
configure a DNS proxy as an alternate server.
To use CRLs for verifying the revocaon status of cerficates used for the decrypon of inbound
and outbound SSL/TLS traffic, see Configure Revocaon Status Verificaon of Cerficates Used
for SSL/TLS Decrypon.
To use CRLs for verifying the revocaon status of cerficates that authencate users and devices,
configure a cerficate profile and assign it to the interfaces that are specific to the applicaon:
Authencaon Portal, GlobalProtect (remote user-to-site or large scale), site-to-site IPSec VPN,
or web interface access to Palo Alto Networks firewalls or Panorama. For details, see Configure
Revocaon Status Verificaon of Cerficates.
Online Cerficate Status Protocol (OCSP)

When establishing an SSL/TLS session, clients can use Online Cerficate Status Protocol (OCSP)
to check the revocaon status of the authencaon cerficate. The authencang client sends
a request containing the serial number of the cerficate to the OCSP responder (server). The
responder searches the database of the cerficate authority (CA) that issued the cerficate and
returns a response containing the status (good, revoked or unknown) to the client. The advantage
of the OCSP method is that it can verify status in real-me, instead of depending on the issue
frequency (hourly, daily, or weekly) of CRLs.
The Palo Alto Networks firewall downloads and caches OCSP status informaon for every CA
listed in the trusted CA list of the firewall. Caching only applies to validated cerficates; if a
firewall never validated a cerficate, the firewall cache does not store the OCSP informaon for
the issuing CA. If your enterprise has its own public key infrastructure (PKI), you can configure the
firewall as an OCSP responder (see Configure an OCSP Responder).
To use OCSP for verifying the revocaon status of cerficates when the firewall funcons as
an SSL forward proxy, perform the steps under Configure Revocaon Status Verificaon of
Cerficates Used for SSL/TLS Decrypon.
The following applicaons use cerficates to authencate users and/or devices: Authencaon
Portal, GlobalProtect (remote user-to-site or large scale), site-to-site IPSec VPN, and web interface
access to Palo Alto Networks firewalls or Panorama. To use OCSP for verifying the revocaon
status of the cerficates:
Configure an OCSP responder (if you are configuring the firewall as an OCSP responder).
Enable the HTTP OCSP service on the firewall (if you are configuring the firewall as an OCSP
responder).
Create or obtain a cerficate for each applicaon.
Configure a cerficate profile for each applicaon.
Assign the cerficate profile to the relevant applicaon.
To cover situaons where the OCSP responder is unavailable, configure CRL as a fall-back method.
For details, see Configure Revocaon Status Verificaon of Cerficates.
Cerficate Deployment
The basic approaches to deploy cerficates for Palo Alto Networks firewalls or Panorama are:
• Obtain cerficates from a trusted third-party CA—The benefit of obtaining a cerficate from
a trusted third-party cerficate authority (CA) such as VeriSign or GoDaddy is that end clients
will already trust the cerficate because common browsers include root CA cerficates from
well-known CAs in their trusted root cerficate stores. Therefore, for applicaons that require
end clients to establish secure connecons with the firewall or Panorama, purchase a cerficate
from a CA that the end clients trust to avoid having to pre-deploy root CA cerficates to
the end clients. (Some such applicaons are a GlobalProtect portal or GlobalProtect Mobile
Security Manager.) However, most third-party CAs cannot issue signing cerficates. Therefore,
this type of cerficate is not appropriate for applicaons (for example, SSL/TLS decrypon and
large-scale VPN) that require the firewall to issue cerficates. See Obtain a Cerficate from an
External CA.
• Obtain cerficates from an enterprise CA—Enterprises that have their own internal CA can use
it to issue cerficates for firewall applicaons and import them onto the firewall. The benefit is
that end clients probably already trust the enterprise CA. You can either generate the needed
cerficates and import them onto the firewall, or generate a cerficate signing request (CSR)
on the firewall and send it to the enterprise CA for signing. The benefit of this method is that
the private key does not leave the firewall. An enterprise CA can also issue a signing cerficate,
which the firewall uses to automacally generate cerficates (for example, for GlobalProtect
large-scale VPN or sites requiring SSL/TLS decrypon). See Import a Cerficate and Private
Key.
• Generate self-signed cerficates—You can Create a Self-Signed Root CA Cerficate on the
firewall and use it to automacally issue cerficates for other firewall applicaons.
If you use this method to generate cerficates for an applicaon that requires an end
client to trust the cerficate, end users will see a cerficate error because the root
CA cerficate is not in their trusted root cerficate store. To prevent this, deploy the
self-signed root CA cerficate to all end user systems. You can deploy the cerficates
manually or use a centralized deployment method such as an Acve Directory Group
Policy Object (GPO).
Set Up Verificaon for Cerficate Revocaon Status

To verify the revocaon status of cerficates, the firewall uses Online Cerficate Status Protocol
(OCSP) and/or cerficate revocaon lists (CRLs). For details on these methods, see Cerficate
Revocaon If you configure both methods, the firewall first tries OCSP and only falls back to
the CRL method if the OCSP responder is unavailable. If your enterprise has its own public key
infrastructure (PKI), you can configure the firewall to funcon as the OCSP responder.
The following topics describe how to configure the firewall to verify cerficate revocaon status:
• Configure an OCSP Responder
• Configure Revocaon Status Verificaon of Cerficates
• Configure Revocaon Status Verificaon of Cerficates Used for SSL/TLS Decrypon
Configure an OCSP Responder

To use Online Cerficate Status Protocol (OCSP) for verifying the revocaon status of cerficates,
you must configure the firewall to access an OCSP responder (server). The enty that manages
the OCSP responder can be a third-party cerficate authority (CA). If your enterprise has its own
public key infrastructure (PKI), you can use external OCSP responders or you can configure the
firewall itself as an OCSP responder. For details on OCSP, see Cerficate Revocaon.
Configure an OCSP responder Cerficate Profile only when you generate a new cerficate
(Device > Cerficate Management > Cerficates). Specify the OCSP Responder when you
generate a new cerficate so that the firewall populates the Authority Informaon Access
(AIA) field with the appropriate URL and then specify the new cerficate in the Cerficate
Profile. Configuring a Cerficate Profile does not override the Cerficate Profile for exisng
cerficates or Root CAs.
You can enable OCSP validaon or override the AIA field of cerficate in the Cerficate
Profile. The Cerficate Profile configuraon determines which cerficate validaon
mechanisms are used on cerficates that authencate to services hosted on the firewall,
such as GlobalProtect.
STEP 1 | Define an external OCSP responder or configure the firewall itself as an OCSP responder.
1. Select Device > Cerficate Management > OCSP Responder and click Add.
2. Enter a Name to idenfy the responder (up to 31 characters). The name is case-sensive.
It must be unique and use only leers, numbers, spaces, hyphens, and underscores.
3. If the firewall has more than one virtual system (vsys), select a Locaon (vsys or Shared)
for the cerficate.
4. In the Host Name field, enter the host name (recommended) or IP address of the OCSP
responder. You can enter an IPv4 or IPv6 address. From this value, PAN-OS automacally
derives a URL and adds it to the cerficate being verified.
If you configure the firewall itself as an OCSP responder, the host name must resolve to
an IP address in the interface that the firewall uses for OCSP services.
5. Click OK.
STEP 2 | If you want the firewall to use the management interface for the OCSP responder interface,
enable OCSP communicaon on the firewall. Otherwise, connue to the next step to
configure an alternate interface.
1. Select Device > Setup > Interfaces > Management.
2. In the Network Services secon, select the HTTP OCSP check box, then click OK.
STEP 3 | To use an alternate interface as the OCSP responder interface, add an Interface Management
Profile to the interface used for OCSP services.
1. Select Network > Network Profiles > Interface Mgmt.
2. Click Add to create a new profile or click the name of an exisng profile.
3. Select the HTTP OCSP check box and click OK.
4. Select Network > Interfaces and click the name of the interface that the firewall will
use for OCSP services. The OCSP Host Name specified in Step 1 must resolve to an IP
address in this interface.
5. Select Advanced > Other info and select the Interface Management Profile you
configured.
6. Click OK and Commit.
Configure Revocaon Status Verificaon of Cerficates

The firewall and Panorama use cerficates to authencate users and devices for such applicaons
as Authencaon Portal, GlobalProtect, site-to-site IPSec VPN, and web interface access to the
firewall/Panorama. To improve security, it is a best pracce to configure the firewall or Panorama
to verify the revocaon status of cerficates that it uses for device/user authencaon.
STEP 1 | Configure a Cerficate Profile for each applicaon.
Assign one or more root CA cerficates to the profile and select how the firewall verifies
cerficate revocaon status.
For details on the cerficates that various applicaons use, see Keys and Cerficates
STEP 2 | Assign the cerficate profiles to the relevant applicaons.

The steps to assign a cerficate profile depend on the applicaon that requires it.
Configure Revocaon Status Verificaon of Cerficates Used for

SSL/TLS Decrypon
The firewall decrypts inbound and outbound SSL/TLS traffic to inspect the traffic for threats.
When you create a Security policy rule that allows traffic and apply Security profiles to the rule,
create an analogous Decrypon policy rule to decrypt that traffic. If you don’t decrypt the traffic,
the firewall can’t use the Security profiles to inspect the traffic (you can’t inspect what you can’t
see). The firewall re-encrypts the traffic before forwarding it. (See SSL Inbound Inspecon and SSL
Forward Proxy.) You can configure the firewall to verify the revocaon status of cerficates used
for decrypon as follows.
Enabling revocaon status verificaon for SSL/TLS decrypon cerficates will add me to
the process of establishing the session. The first aempt to access a site might fail if the
verificaon does not finish before the session mes out. For these reasons, verificaon is
disabled by default.
STEP 1 | Define the service-specific meout intervals for revocaon status requests.
1. Select Device > Setup > Session and, in the Session Features secon, select Decrypon
Cerficate Revocaon Sengs.
2. Perform one or both of the following steps, depending on whether the firewall will use
Online Cerficate Status Protocol (OCSP) or the Cerficate Revocaon List (CRL) method
to verify the revocaon status of cerficates. If the firewall will use both, it first tries
OCSP; if the OCSP responder is unavailable, the firewall then tries the CRL method.
• In the CRL secon, select the Enable check box and enter the Receive Timeout. This
is the interval (1-60 seconds) aer which the firewall stops waing for a response
from the CRL service.
• In the OCSP secon, select the Enable check box and enter the Receive Timeout.
This is the interval (1-60 seconds) aer which the firewall stops waing for a response
from the OCSP responder.
Depending on the Cerficate Status Timeout value you specify in Step 2, the firewall
might register a meout before either or both of the Receive Timeout intervals pass.
STEP 2 | Define the total meout interval for revocaon status requests.
Enter the Cerficate Status Timeout. This is the interval (1-60 seconds) aer which the
firewall stops waing for a response from any cerficate status service and applies the session-
blocking logic you oponally define in Step 3. The Cerficate Status Timeout relates to the
OCSP/CRL Receive Timeout as follows:
• If you enable both OCSP and CRL—The firewall registers a request meout aer the lesser
of two intervals passes: the Cerficate Status Timeout value or the aggregate of the two
Receive Timeout values.
• If you enable only OCSP—The firewall registers a request meout aer the lesser of two
intervals passes: the Cerficate Status Timeout value or the OCSP Receive Timeout value.
• If you enable only CRL—The firewall registers a request meout aer the lesser of two
intervals passes: the Cerficate Status Timeout value or the CRL Receive Timeout value.
STEP 3 | Define the blocking behavior for unknown cerficate status or a revocaon status request
meout.
If you want the firewall to block SSL/TLS sessions when the OCSP or CRL service returns a
cerficate revocaon status of unknown, select the Block Session With Unknown Cerficate
Status check box. Otherwise, the firewall proceeds with the session.
If you want the firewall to block SSL/TLS sessions aer it registers a request meout, select
the Block Session On Cerficate Status Check Timeout check box. Otherwise, the firewall
proceeds with the session.
Configure the Master Key

Every firewall and Panorama management server has a default master key that encrypts all the
private keys and passwords in the configuraon to secure them (such as the private key used for
SSL Forward Proxy Decrypon).
Change the default master key as soon as possible to ensure that you use a unique master
key for encrypon.
In a high availability (HA) configuraon, you must use the same master key on both firewalls
because the master key is not synchronized across HA peers. Otherwise, HA synchronizaon will
not work properly.
If you are using Panorama to manage your firewalls, you can configure the same master key on
Panorama and all managed firewalls or configure a unique master key for each managed firewall.
For managed firewalls in an HA configuraon, you must configure the same master key for each
HA peer. See Manage the Master Key from Panorama if the firewall is managed by a Panorama™
management server.
Be sure to store the master key in a safe locaon. You cannot recover the master key and the only
way to restore the default master key is to Reset the Firewall to Factory Default Sengs.
STEP 1 | Backup the configuraon.
STEP 2 | (HA only) Disable Config Sync.

This step is required before deploying a new master key to any firewall HA pair
Before you deploy a new master key to any firewall HA pair, you must disable Config Sync. For
Panorama-managed firewalls, if you do not disable Config Sync before deploying a new master
key, Panorama loses connecvity to the primary firewall.
1. Select Device > High Availability > General and edit the Setup.
2. Disable (clear) Enable Config Sync and then click OK.
3. Commit your configuraon changes.
STEP 3 | Select Device > Master Key and Diagnoscs and edit the Master Key secon.
STEP 4 | Enter the Current Master Key if one exists.
STEP 5 | Define a new New Master Key and then Confirm New Master Key. The key must contain
exactly 16 characters.
STEP 6 | To specify the master key Lifeme, enter the number of Days and/or Hours aer which the
key will expire.
You must configure a new master key before the current key expires. If the master key expires,
the firewall or Panorama automacally reboots in Maintenance mode. You must then Reset the
Firewall to Factory Default Sengs.
Set the Lifeme to two years or less, depending on how many encrypons the device
performs. The more encrypons a device performs, the shorter the Lifeme you should
set. The crical consideraon is to not run out of unique encrypons before you change
32
the master key. Each master key can provide up to 2 unique encrypons based on the
32
master key value and the Inializaon Vector (IV) value. Aer 2 unique encrypons,
encrypons repeat (are no longer unique), which is a security risk.
Set a Time for Reminder value (see next step) for the master key and when the
reminder noficaon occurs, change the master key.
STEP 7 | Enter a Time for Reminder that specifies the number of Days and Hours before the master
key expires when the firewall generates an expiraon alarm. The firewall automacally opens
the System Alarms dialog to display the alarm.
Set the reminder so that it gives you plenty of me to configure a new master key
before it expires in a scheduled maintenance window. When the Time for Reminder
expires and the firewall or Panorama sends a noficaon log, change the master key,
don’t wait for the Lifeme to expire. For grouped devices, track every device (e.g.,
firewalls that Panorama manages and firewall HA pairs) and when the reminder value
expires for the any device in the group, change the master key.
To ensure the expiraon alarm displays, select Device > Log Sengs, edit the Alarm
Sengs, and Enable Alarms.
STEP 8 | Enable Auto Renew Master Key to configure the firewall to automacally renew the master
key. To configure Auto Renew With Same Master Key, specify the number of Days and/
or Hours to renew the same master key. The key extension allows the firewall to remain
operaonal and connue securing your network; it is not a replacement for configuring a new
key if the exisng master key lifeme expires soon.
Automacally renewing the master key has benefits and risks. The benefit is that extending
the master key Lifeme protects against failure to change the master key before its lifeme
expires. The risk is that encrypons will repeat and cause a security risk if the number
of encrypons the device performs with the master key exceeds the number of unique
32
encrypons the master key can generate (2 unique encrypons).
If the Master Key expires (you do not automacally renew it and you do not replace it
in a mely manner), the device goes into maintenance mode.
If you enable Auto Renew Master Key, set it so that the total me (lifeme plus the
auto renew me) does not cause the device to run out of unique encrypons. For
example, if you believe the device will consume the master key’s number of unique
encrypons in two and a half years, you could set the Lifeme for two years, set the
Time for Reminder to 60 days, and set the Auto Renew Master Key for 60-90 days
to provide the extra me to configure a new master key before the Lifeme expires.
However, the best pracce is sll to change the master key before the lifeme expires
to ensure that no device repeats encrypons.
Consider the number of days unl your next available maintenance window when
configuring the master key to automacally renew aer the lifeme of the key expires.
STEP 9 | (Oponal) For added security, select whether to use an HSM to encrypt the master key. For
details, see Encrypt a Master Key Using an HSM.
STEP 11 | (HA only) Re-enable Config Sync.

1. Select Device > High Availability > General and edit the Setup.
2. Enable (check) Enable Config Sync and then click OK.
Master Key Encrypon

On physical and virtual Palo Alto Networks devices, you can configure the master key to use the
AES-256-CBC or the AES-256-GCM (introduced in PAN-OS 10.0) encrypon algorithm to encrypt
data such as keys and passwords. AES-256-GCM provides stronger encrypon than AES-256-
CBC and improves your security posture. It also includes a built-in integrity check. The master key
uses the configured encrypon algorithm to encrypt sensive data stored on the firewall and on
Panorama. When you set the encrypon algorithm to AES-256-GCM, you can sll use an HSM to
encrypt the master key with an encrypon key that is stored on the HSM.
The default encrypon algorithm that the master key uses to encrypt data is AES-256-CBC—
the same algorithm that the master key used prior to PAN-OS 10.0. AES-256-CBC is the default
encrypon level because when you manage firewalls with Panorama, the managed firewalls may
be on different PAN-OS releases, and firewalls on PAN-OS releases earlier than PAN-OS 10.1 do
not support AES-256-GCM. This is why Panorama must use the lowest level of encrypon that its
managed devices can use. For example, if some managed devices run PAN-OS 10.1 and some run
earlier versions, Panorama must use AES-256-CBC. However, if all managed devices run PAN-OS
10.1 or later, then Panorama and all of its managed devices can use AES-256-GCM.
Use the same encrypon level on Panorama and its managed devices and use the same
encrypon level on firewall pairs. Upgrade devices to use the strongest possible encrypon
algorithm. If all Panorama-managed devices run PAN-OS 10.0, use AES-256-GCM on
all devices. The configuraon of managed or paired devices that use different encrypon
levels may become out of sync.
When you change the encrypon algorithm to AES-256-GCM, devices use it instead of AES-256-
CBC to encrypt sensive data. When you change from one algorithm to another, you can also
specify whether to:
• Re-encrypt exisng encrypted data with the new algorithm.
• Leave exisng data encrypted with the old encrypon algorithm and use the new algorithm
only for new (future) encrypons.
By default, when you change the encrypon algorithm, the device uses the new algorithm
to re-encrypt exisng encrypted data as well as to encrypt new data. If you manage
devices with Panorama, they may be on different versions of PAN-OS and may not support
the newest encrypon algorithms. Be sure you understand which encrypon algorithms
Panorama and its managed devices support before you change the encrypon algorithm or
re-encrypt data that has already been encrypted.
• Configure Master Key Encrypon Level

• Master Key Encrypon on a Firewall HA Pair
• Master Key Encrypon Logs
• Unique Master Key Encrypons for AES-256-GCM
Configure Master Key Encrypon Level

You configure the master key encrypon algorithm level and whether to re-encrypt all currently
encrypted data with a new encrypon algorithm level using the CLI. Depending on the order of
the keywords, you can change the encrypon level or you can change the encrypon level and
also specify whether to re-encrypt previously encrypted data.
The following operaonal CLI command changes the encrypon level and automacally re-
encrypts all currently encrypted data with the specified encrypon level:
admin@PA-NGFW>request encryption-level level <0|1|2>
The following operaonal CLI command changes the encrypon level and specifies whether to re-
encrypt all currently encrypted data with the new encrypon level:
admin@PA-NGFW>request encryption-level re-encrypt <yes|no> level <0|

1|2>
Keyword Opons
level 0 = Use the default algorithm (AES-256-CBC) to encrypt

data
1 = Use the AES-256-CBC algorithm to encrypt data
2 = Use the AES-256-GCM algorithm to encrypt data
The firewall re-encrypts all currently encrypted data
and encrypts new sensive data using the specified
algorithm. If you don’t want to re-encrypt exisng
encrypted data with the new algorithm, specify re-
encrypt no in the command string. This prevents the
firewall from automacally re-encrypng data that the
firewall has already encrypted.
Only use AES-256-GCM when Panorama

and all of its managed devices (or both
devices in an HA pair) run PAN-OS 10.1
or greater and configure all of the devices
to use AES-256-GCM. Managed or paired
devices that use different encrypon levels
may become out of sync.
re-encrypt no = Do not re-encrypt currently encrypted data.

The firewall does not re-encrypt currently encrypted
data. Currently encrypted data remains encrypted
with whichever algorithm the firewall originally used
to encrypt the data. The firewall uses the specified
algorithm only to encrypt sensive data in the future.
Keyword Opons
yes = Re-encrypt currently encrypted data with the
specified algorithm and use that algorithm to encrypt
sensive data in the future.
Use the operaonal CLI command show system masterkey-properties to verify the
encrypon algorithm (level) currently configured on the device, for example:
admin@PA-NGFW>show system masterkey-properties
Master key expires at: unspecified

Reminders will begin at: unspecified
Master key on hsm: no
Automatically renew master key lifetime: 0
Encryption Level: 1
The output shows that the current encrypon level is 1, which is AES-256-CBC.
If you downgrade to an earlier version of PAN-OS, the device automacally reverts the encrypon
algorithm to a level that the downgraded PAN-OS version supports and automacally re-encrypts
encrypted data using that level so that the device can decrypt and use the data as needed. For
example, if your device is on PAN-OS 10.1 and uses AES-256-GCM as the encrypon algorithm
(which is not supported on earlier versions of PAN-OS), and you downgrade to PAN-OS 9.1, then
the device re-encrypts the encrypted data to AES-256-CBC, which is supported in PAN-OS 9.1.
Master Key Encrypon on a Firewall HA Pair

To use the AES-256-GCM encrypon level on a firewall high availability (HA) pair, both firewalls
must run PAN-OS 10.0 so that both firewalls support AES-256-GCM. If either firewall in the HA
pair runs an earlier version than PAN-OS 10.0, you can’t use AES-256-GCM. When both firewalls
are on PAN-OS 10.0, both firewalls can decode AES-256-CBC or AES-256-GCM encrypon
keys, so they can use the either encrypon level. However, both firewalls should use the same
encrypon level to avoid the possibility of becoming out of sync.
Use AES-256-GCM encrypon on both firewalls in the HA pair. Whether you use
AES-256-GCM or AES-256-CBC, use the same algorithm on both firewalls.
You do not need to disable HA to change the encrypon level on a firewall in an HA pair in which
both firewalls run PAN-OS 10.0.
Master Key Encrypon Logs

The firewall generates a System Log (Monitor > Logs > System) when you change the master key
encrypon algorithm (level).
To view all of the System Logs for master key encrypon, create a filter that shows all logs of the
Type crypto: (subtype eq crypto).
Unique Master Key Encrypons for AES-256-GCM

The master key can only generate a finite number of unique encrypons before it runs out of
unique combinaons and must repeat encrypons. The firewall creates unique encrypons using
the AES-256-GCM encrypon algorithm with an Inializaon Vector (IV). An IV is an arbitrary
number that should only be used one me to create an encrypon to ensure that each encrypon
is unique.
Each encrypon using the master key and IV must be unique to prevent forgery aacks. The
firewall meets the uniqueness requirement that the probability that the authencated encrypon
is ever created with the same IV and the same key on two or more disnct sets of input data is no
32
greater than 2 .
When the IV runs through all of its unique values, the IV value repeats. When the IV value
repeats, using the same master key and the repeated IV value to encrypt data means that the
encrypon is the same as an encrypon previously used on other data. Change the Master Key
before the system runs out of unique encrypons to prevent the firewall from using the same
encrypon (master key and IV value combinaon) on more than one piece of sensive data.
Unique encrypon combinaons should never be repeated or reused.
To track when you need to change the master key, set the master key Lifeme and Reminder
values on each appliance (Device > Master Key and Diagnoscs and edit the master key). Set the
values conservavely, based on the expected volume of master key encrypons, to ensure that all
encrypons are unique and no encrypon combinaons are repeated or reused.
Obtain Cerficates
• Create a Self-Signed Root CA Cerficate
• Generate a Cerficate
• Import a Cerficate and Private Key
• Obtain a Cerficate from an External CA
• Install a Device Cerficate
• Deploy Cerficates Using SCEP
Create a Self-Signed Root CA Cerficate

A self-signed root cerficate authority (CA) cerficate is the top-most cerficate in a cerficate
chain. A firewall can use this cerficate to automacally issue cerficates for other uses. For
example, the firewall issues cerficates for SSL/TLS decrypon and for satellites in a GlobalProtect
large-scale VPN.
When establishing a secure connecon with the firewall, the remote client must trust the root CA
that issued the cerficate. Otherwise, the client browser will display a warning that the cerficate
is invalid and might (depending on security sengs) block the connecon. To prevent this, aer
generang the self-signed root CA cerficate, import it into the client systems.
On a Palo Alto Networks firewall or Panorama, you can generate self-signed cerficates
only if they are CA cerficates.
STEP 1 | Select Device > Cerficate Management > Cerficates > Device Cerficates.
STEP 2 | If the firewall has more than one virtual system (vsys), select a Locaon (vsys or Shared) for
the cerficate.
STEP 3 | Click Generate.
STEP 4 | Enter a Cerficate Name, such as GlobalProtect_CA. The name is case-sensive and
can have up to 63 characters on the firewall or up to 31 characters on Panorama. It must be
unique and use only leers, numbers, hyphens, and underscores.
STEP 5 | In the Common Name field, enter the FQDN (recommended) or IP address of the interface
where you will configure the service that will use this cerficate.
STEP 6 | If the firewall has more than one vsys and you want the cerficate to be available to every
vsys, select the Shared check box.
STEP 7 | Leave the Signed By field blank to designate the cerficate as self-signed.
STEP 8 | (Required) Select the Cerficate Authority check box.
STEP 9 | Leave the OCSP Responder field blank; revocaon status verificaon doesn’t apply to root
CA cerficates.
STEP 10 | Click Generate and Commit.
Generate a Cerficate
Palo Alto Networks firewalls and Panorama use cerficates to authencate clients, servers,
users, and devices in several applicaons, including SSL/TLS decrypon, Authencaon Portal,
GlobalProtect, site-to-site IPSec VPN, and web interface access to the firewall/Panorama.
Generate cerficates for each usage: for details, see Keys and Cerficates.
To generate a cerficate, you must first Create a Self-Signed Root CA Cerficate or import one
(Import a Cerficate and Private Key) to sign it. To use Online Cerficate Status Protocol (OCSP)
for verifying cerficate revocaon status, Configure an OCSP Responder before generang the
cerficate.
the cerficate.
STEP 3 | Click Generate.
STEP 4 | Select Local (default) as the Cerficate Type unless you want to deploy SCEP cerficates to
GlobalProtect endpoints.
STEP 5 | Enter a Cerficate Name. The name is case-sensive and can have up to 63 characters on
the firewall or up to 31 characters on Panorama. It must be unique and use only leers,
numbers, hyphens, and underscores.
STEP 6 | In the Common Name field, enter the FQDN (recommended) or IP address of the interface
where you will configure the service that will use this cerficate.
STEP 7 | If the firewall has more than one vsys and you want the cerficate to be available to every
vsys, select the Shared check box.
STEP 8 | In the Signed By field, select the root CA cerficate that will issue the cerficate.
STEP 9 | (Oponal) Select an OCSP Responder.
STEP 10 | For the key generaon Algorithm, select RSA (default) or Ellipcal Curve DSA (ECDSA).
ECDSA is recommended for client browsers and operang systems that support it.
Firewalls that run PAN-OS 6.1 and earlier releases will delete any ECDSA cerficates
that you push from Panorama™, and any RSA cerficates signed by an ECDSA
cerficate authority (CA) will be invalid on those firewalls.
You cannot use a hardware security module (HSM) to store ECDSA keys used for SSL/TLS
Decrypon.
STEP 11 | Select the Number of Bits to define the cerficate key length. Higher numbers are more
secure but require more processing me.
STEP 12 | Select the Digest algorithm. From most to least secure, the opons are: sha512, sha384,
sha256 (default), sha1, and md5.
Client cerficates that are used when requesng firewall services that rely on TLSv1.2
(such as administrator access to the web interface) cannot have sha512 as a digest
algorithm. The client cerficates must use a lower digest algorithm (such as sha384) or
you must limit the Max Version to TLSv1.1 when you Configure an SSL/TLS Service
Profile for the firewall services.
STEP 13 | For the Expiraon, enter the number of days (default is 365) for which the cerficate is valid.
STEP 14 | (Oponal) Add the Cerficate Aributes to uniquely idenfy the firewall and the service that
will use the cerficate.
If you add a Host Name (DNS name) aribute, it is a best pracce for it to match the
Common Name, because the host name populates the Subject Alternate Name (SAN)
field of the cerficate and some browsers require the SAN to specify the domains
the cerficate protects; in addion, the Host Name matching the Common Name is
mandatory for GlobalProtect.
STEP 15 | Click Generate and, in the Device Cerficates page, click the cerficate Name.
Regardless of the me zone on the firewall, it always displays the corresponding
Greenwich Mean Time (GMT) for cerficate validity and expiraon dates/mes.
STEP 16 | Select the check boxes that correspond to the intended use of the cerficate on the firewall.
For example, if the firewall will use this cerficate to secure forwarding of syslogs to an
external syslog server, select the Cerficate for Secure Syslog check box.
Import a Cerficate and Private Key

If your enterprise has its own public key infrastructure (PKI), you can import a cerficate and
private key into the firewall from your enterprise cerficate authority (CA). Enterprise CA
cerficates (unlike most cerficates purchased from a trusted, third-party CA) can automacally
issue CA cerficates for applicaons such as SSL/TLS decrypon or large-scale VPN.
On a Palo Alto Networks firewall or Panorama, you can import self-signed cerficates only
if they are CA cerficates.
Instead of imporng a self-signed root CA cerficate into all the client systems, it is a best
pracce to import a cerficate from the enterprise CA because the clients will already have
a trust relaonship with the enterprise CA, which simplifies the deployment.
If the cerficate you will import is part of a cerficate chain, it is a best pracce to import
the enre chain.
STEP 1 | From the enterprise CA, export the cerficate and private key that the firewall will use for
authencaon.
When exporng a private key, you must enter a passphrase to encrypt the key for transport.
Ensure the management system can access the cerficate and key files. When imporng the
key onto the firewall, you must enter the same passphrase to decrypt it.
the cerficate.
STEP 4 | Click Import and enter a Cerficate Name. The name is case-sensive and can have up to
63 characters on the firewall or up to 31 characters on Panorama. It must be unique and use
only leers, numbers, hyphens, and underscores.
STEP 5 | To make the cerficate available to all virtual systems, select the Shared check box. This
check box appears only if the firewall supports mulple virtual systems.
STEP 6 | Enter the path and name of the Cerficate File received from the CA, or Browse to find the
file.
STEP 7 | Select a File Format:

• Encrypted Private Key and Cerficate (PKCS12)—This is the default and most common
format, in which the key and cerficate are in a single container (Cerficate File). If a
hardware security module (HSM) will store the private key for this cerficate, select the
Private key resides on Hardware Security Module check box.
• Base64 Encoded Cerficate (PEM)—You must import the key separately from the
cerficate. If a hardware security module (HSM) stores the private key for this cerficate,
select the Private key resides on Hardware Security Module check box and skip the next
step. Otherwise, select the Import Private Key check box, enter the Key File or Browse to it,
then connue to the next step.
STEP 8 | Enter and re-enter (confirm) the Passphrase used to encrypt the private key.
STEP 9 | Click OK. The Device Cerficates page displays the imported cerficate.
Obtain a Cerficate from an External CA

The advantage of obtaining a cerficate from an external cerficate authority (CA) is that the
private key does not leave the firewall. To obtain a cerficate from an external CA, generate a
cerficate signing request (CSR) and submit it to the CA. Aer the CA issues a cerficate with
the specified aributes, import it onto the firewall. The CA can be a well-known, public CA or an
enterprise CA.
To use Online Cerficate Status Protocol (OCSP) for verifying the revocaon status of the
cerficate, Configure an OCSP Responder before generang the CSR.
STEP 1 | Request the cerficate from an external CA.

1. Select Device > Cerficate Management > Cerficates > Device Cerficates.
3. Click Generate.
4. Enter a Cerficate Name. The name is case-sensive and can have up to 63 characters
on the firewall or up to 31 characters on Panorama. It must be unique and use only
leers, numbers, hyphens, and underscores.
5. In the Common Name field, enter the FQDN (recommended) or IP address of the
interface where you will configure the service that will use this cerficate.
6. If the firewall has more than one vsys and you want the cerficate to be available to
every vsys, select the Shared check box.
7. In the Signed By field, select External Authority (CSR).
8. If applicable, select an OCSP Responder.
9. (Oponal) Add the Cerficate Aributes to uniquely idenfy the firewall and the service
that will use the cerficate.
If you add a Host Name aribute, it should match the Common Name (this is
mandatory for GlobalProtect). The host name populates the Subject Alternave
Name field of the cerficate.
10. Click Generate. The Device Cerficates tab displays the CSR with a Status of pending.
STEP 2 | Submit the CSR to the CA.

1. Select the CSR and click Export to save the .csr file to a local computer.
2. Upload the .csr file to the CA.
STEP 3 | Import the cerficate.

1. Aer the CA sends a signed cerficate in response to the CSR, return to the Device
Cerficates tab and click Import.
2. Enter the Cerficate Name used to generate the CSR.
3. Enter the path and name of the PEM Cerficate File that the CA sent, or Browse to it.
4. Click OK. The Device Cerficates tab displays the cerficate with a Status of valid.
STEP 4 | Configure the cerficate.

1. Click the cerficate Name.
2. Select the check boxes that correspond to the intended use of the cerficate on the
firewall. For example, if the firewall will use this cerficate to secure forwarding of
syslogs to an external syslog server, select the Cerficate for Secure Syslog check box.
Install a Device Cerficate

Your next-generaon firewall can leverage cloud services such as Device Telemetry and IoT. To
do this, you must install a device cerficate to successfully authencate the firewall with the Palo
Alto Networks Customer Support Portal (CSP) to leverage these cloud services. The circumstances
under which a device cerficate is required will differ from feature to feature, so install a device
cerficate only if the feature's setup documentaon tells you that this needs to be done.
You only need to install a device cerficate once. Every feature that uses device cerficates will
use the cerficate installed on your firewall if it already exists.
You can install a device cerficate to firewalls that are managed by Panorama. If you want to
install a device cerficate directly to a single next-generaon firewall (that is, you are not using
Panorama):
STEP 1 | Generate the One Time Password (OTP).
1. Log in to the Customer Support Portal.
2. Select Assets > Device Cerficates and Generate OTP.
3. For the Device Type, select Generate OTP for Next-Gen Firewalls.
4. Select your PAN OS Device serial number.
5. Generate OTP and copy the OTP.
STEP 2 | Log in to your next-generaon firewall as an admin user.
STEP 3 | Select Device > Setup > Management > Device Cerficate and Get cerficate.
STEP 4 | Paste the One-me Password you generated and click OK.
STEP 5 | Your next-generaon firewall successfully retrieves and installs the cerficate.
Deploy Cerficates Using SCEP

If you have a Simple Cerficate Enrollment Protocol (SCEP) server in your enterprise PKI, you can
configure a SCEP profile to automate the generaon and distribuon of unique client cerficates.
SCEP operaon is dynamic in that the enterprise PKI generates a user-specific cerficate when
the SCEP client requests it and sends the cerficate to the SCEP client. The SCEP client then
transparently deploys the cerficate to the client device.
You can use a SCEP profile with GlobalProtect to assign user-specific client cerficates to each
GlobalProtect user. In this use case, the GlobalProtect portal acts as a SCEP client to the SCEP
server in your enterprise PKI. Addionally, you can use a SCEP profile to assign client cerficates
to Palo Alto Networks devices for mutual authencaon with other Palo Alto Networks devices
for management access and inter-device communicaon.
STEP 1 | Create a SCEP profile.
1. Select Device > Cerficate Management > SCEP and then Add a new profile.
2. Enter a Name to idenfy the SCEP profile.
3. If this profile is for a firewall with mulple virtual systems capability, select a virtual
system or Shared as the Locaon where the profile is available.
STEP 2 | (Oponal) To make the SCEP-based cerficate generaon more secure, configure a SCEP
challenge-response mechanism between the PKI and portal for each cerficate request.
Aer you configure this mechanism, its operaon is invisible, and no further input from you is
necessary.
To comply with the U.S. Federal Informaon Processing Standard (FIPS), use a Dynamic SCEP
challenge and specify a Server URL that uses HTTPS.
Select one of the following opons:
• None—(Default) The SCEP server does not challenge the portal before it issues a cerficate.
• Fixed—Obtain the enrollment challenge password from the SCEP server in the PKI
infrastructure and then enter the password into the Password field.
• Dynamic—Enter a username and password of your choice (possibly the credenals
of the PKI administrator) and the SCEP Server URL where the portal-client submits
these credenals. The uses the credenals to authencate with the SCEP server
which transparently generates an OTP password for the portal upon each cerficate
request. (You can see this OTP change aer a screen refresh in The enrollment
challengepassword is field aer each cerficate request.) The PKI transparently
passes each new password to the portal, which then uses the password for its cerficate
request.
STEP 3 | Specify the sengs for the connecon between the SCEP server and the portal to enable the
portal to request and receive client cerficates.
You can include addional informaon about the client device or user by specifying tokens in
the Subject name of the cerficate.
The portal includes the token value and host ID in the CSR request to the SCEP server.
1. Configure the Server URL that the portal uses to reach the SCEP server in the PKI (for
example, http://10.200.101.1/certsrv/mscep/).
2. Enter a string (up to 255 characters in length) in the CA-IDENT Name field to idenfy
the SCEP server.
3. Enter the Subject name to use in the cerficates generated by the SCEP server. The
subject must be a disnguished name in the <attribute>=<value> format and
must include a common name (CN) aribute (CN=<variable>). The CN supports the
following dynamic tokens:
• $USERNAME—Use this token to enable the portal to request cerficates for a specific
user. To use this variable with GlobalProtect, you must also Enable Group Mapping.
The username entered by the user must match the name in the user-group mapping
table.
• $EMAILADDRESS—Use this token to request cerficates associated with a specific
email address. To use this variable, you must also Enable Group Mapping and
configure the Mail Aributes in the Mail Domains secon of the Server Profile. If
GlobalProtect cannot idenfy an email address for the user, it generates a unique ID
and populates the CN with that value.
• $HOSTID—To request cerficates for the device only, specify the host ID token.
When a user aempts to log in to the portal, the endpoint sends idenfying
informaon that includes its host ID value. The host ID value varies by device type,
either GUID (Windows) MAC address of the interface (Mac), Android ID (Android
devices), UDID (iOS devices), or a unique name that GlobalProtect assigns (Chrome).
• $UDID—Use the UDID common name aribute to request cerficates based on
the client’s device UDID for GlobalProtect or device serial number for mutual
authencaon between Palo Alto Networks devices.
When the GlobalProtect portal pushes the SCEP sengs to the agent, the CN poron of
the subject name is replaced with the actual value (username, host ID, or email address)
of the cerficate owner (for example, O=acme,CN=johndoe).
4. Select the Subject Alternave Name Type:
Use stac entries for the Subject Alternave Name Type. The firewall does not
support dynamic tokens such as $USERNAME.
• RFC 822 Name—Enter the email name in a cerficate’s subject or Subject Alternave
Name extension.
• DNS Name—Enter the DNS name used to evaluate cerficates.
• Uniform Resource Idenfier—Enter the name of the resource from which the client
will obtain the cerficate.
• None—Do not specify aributes for the cerficate.
STEP 4 | (Oponal) Configure cryptographic sengs for the cerficate.

• Select the key length (Number of Bits) for the cerficate.
If the firewall is in FIPS-CC mode and the key generaon algorithm is RSA. The RSA keys
must be 2,048 bits or larger.
• Select the Digest for CSR which indicates the digest algorithm for the cerficate signing
request (CSR): sha1, sha256, or sha384.
STEP 5 | (Oponal) Configure the permied uses of the cerficate, either for signing or encrypon.
• To use this cerficate for signing, select the Use as digital signature check box. This enables
the endpoint use the private key in the cerficate to validate a digital signature.
• To use this cerficate for encrypon, select the Use for key encipherment check box. This
enables the client use the private key in the cerficate to encrypt data exchanged over the
HTTPS connecon established with the cerficates issued by the SCEP server.
STEP 6 | (Oponal) To ensure that the portal is connecng to the correct SCEP server, enter the
CA Cerficate Fingerprint. Obtain this fingerprint from the SCEP server interface in the
Thumbprint field.
1. Enter the URL for the SCEP server’s administrave UI (for example, http://
<hostname or IP>/CertSrv/mscep_admin/).
2. Copy the thumbprint and enter it in the CA Cerficate Fingerprint field.
STEP 7 | Enable mutual SSL authencaon between the SCEP server and the firewall. This is required
to comply with the U.S. Federal Informaon Processing Standard (FIPS).
FIPS-CC operaon is indicated on the firewall login page and in its status bar.
Select the SCEP server’s root CA Cerficate. Oponally, you can enable mutual SSL
authencaon between the SCEP server and the firewall by selecng a Client Cerficate.
STEP 8 | Save and commit the configuraon.

1. Click OK to save the sengs and close the SCEP configuraon.
2. Commit the configuraon.
The portal aempts to request a CA cerficate using the sengs in the SCEP profile and
saves it to the firewall hosng the portal. If successful, the CA cerficate is shown in Device >
Cerficate Management > Cerficates.
STEP 9 | (Oponal) If aer saving the SCEP profile, the portal fails to obtain the cerficate, you can
manually generate a cerficate signing request (CSR) from the portal.
1. Select Device > Cerficate Management > Cerficates > Device Cerficates and then
click Generate.
2. Enter a Cerficate Name. This name cannot contain spaces.
3. Select the SCEP Profile to use to submit a CSR to your enterprise PKI.
4. Click OK to submit the request and generate the cerficate.
Export a Cerficate and Private Key

Palo Alto Networks recommends that you use your enterprise public key infrastructure (PKI)
to distribute a cerficate and private key in your organizaon. However, if necessary, you can
also export a cerficate and private key from the firewall or Panorama. You can use an exported
cerficate and private key in the following cases:
• Configure Cerficate-Based Administrator Authencaon to the Web Interface
• Enable SSL Between GlobalProtect LSVPN Components to configure GlobalProtect agent/app
authencaon to portals and gateways
• SSL Forward Proxy decrypon
• Obtain a Cerficate from an External CA
STEP 2 | If the firewall has more than one virtual system (vsys), select a Locaon (a specific vsys or
Shared) for the cerficate.
STEP 3 | Select the cerficate, click Export, and select a File Format:
• Base64 Encoded Cerficate (PEM)—This is the default format. It is the most common and
has the broadest support on the Internet. If you want the exported file to include the private
key, select the Export Private Key check box.
• Encrypted Private Key and Cerficate (PKCS12)—This format is more secure than PEM but
is not as common or as broadly supported. The exported file will automacally include the
private key.
• Binary Encoded Cerficate (DER)—More operang system types support this format than
the others. You can export only the cerficate, not the key: ignore the Export Private Key
check box and passphrase fields.
STEP 4 | Enter a Passphrase and Confirm Passphrase to encrypt the private key if the File Format is
PKCS12 or if it is PEM and you selected the Export Private Key check box. You will use this
passphrase when imporng the cerficate and key into client systems.
STEP 5 | Click OK and save the cerficate/key file to your computer.
Configure a Cerficate Profile

Cerficate profiles define user and device authencaon for Authencaon Portal, mul-factor
authencaon (MFA), GlobalProtect, site-to-site IPSec VPN, external dynamic list (EDL) validaon,
Dynamic DNS (DDNS), User-ID agent and TS agent access, and web interface access to Palo Alto
Networks firewalls or Panorama. The profiles specify which cerficates to use, how to verify
cerficate revocaon status, and how that status constrains access. Configure a cerficate profile
for each applicaon.
It is a best pracce to enable Online Cerficate Status Protocol (OCSP) and Cerficate
Revocaon List (CRL) status verificaon for cerficate profiles to verify that the cerficate
hasn’t been revoked. Enable both OCSP and CRL so that if the OCSP server isn’t available,
the firewall uses CRL. For details on these methods, see Cerficate Revocaon.
STEP 1 | Obtain the cerficate authority (CA) cerficates you will assign.
Perform one of the following steps to obtain the CA cerficates you will assign to the profile.
You must assign at least one.
• Generate a Cerficate.
• Export a cerficate from your enterprise CA and then import it onto the firewall (see step to
3).
STEP 2 | Idenfy the cerficate profile.

1. Select Device > Cerficate Management > Cerficate Profile and click Add.
2. Enter a Name to idenfy the profile. The name is case-sensive, must be unique and can
use up to 63 characters on the firewall or up to 31 characters on Panorama that include
only leers, numbers, spaces, hyphens, and underscores.
STEP 3 | Assign one or more cerficates.

Perform the following steps for each CA cerficate:
1. In the CA Cerficates table, click Add.
2. Select a CA Cerficate. Alternavely, to import a cerficate, click Import, enter a
Cerficate Name, Browse to the Cerficate File you exported from your enterprise CA,
and click OK.
3. (Oponal) If the firewall uses OCSP to verify cerficate revocaon status, configure the
following fields to override the default behavior. For most deployments, these fields do
not apply.
• By default, the firewall uses the “Authority Informaon Access” (AIA) informaon
from the cerficate to extract the OCSP responder informaon. To override the AIA
informaon, enter a Default OCSP URL (starng with http:// or https://).
• By default, the firewall uses the cerficate selected in the CA Cerficate field to
validate OCSP responses. To use a different cerficate for validaon, select it in the
OCSP Verify CA Cerficate field.
4. Click OK. The CA Cerficates table displays the assigned cerficate.
STEP 4 | Define the methods for verifying cerficate revocaon status and the associated blocking
behavior.
1. Select Use CRL and/or Use OCSP. If you select both, the firewall first tries OCSP and
falls back to the CRL method only if the OCSP responder is unavailable.
2. Depending on the verificaon method, enter the CRL Receive Timeout and/or OCSP
Receive Timeout. These are the intervals (1-60 seconds) aer which the firewall stops
waing for a response from the CRL/OCSP service.
3. Enter the Cerficate Status Timeout. This is the interval (1-60 seconds) aer which the
firewall stops waing for a response from any cerficate status service and applies any
session-blocking logic you define. The Cerficate Status Timeout relates to the OCSP/
CRL Receive Timeout as follows:
• If you enable both OCSP and CRL—The firewall registers a request meout aer the
lesser of two intervals passes: the Cerficate Status Timeout value or the aggregate
of the two Receive Timeout values.
• If you enable only OCSP—The firewall registers a request meout aer the lesser
of two intervals passes: the Cerficate Status Timeout value or the OCSP Receive
Timeout value.
• If you enable only CRL—The firewall registers a request meout aer the lesser of two
intervals passes: the Cerficate Status Timeout value or the CRL Receive Timeout
value.
4. If you want the firewall to block sessions when the OCSP or CRL service returns a
cerficate revocaon status of unknown, select Block session if cerficate status is
unknown. Otherwise, the firewall allows the sessions.
5. If you want the firewall to block sessions aer it registers an OCSP or CRL request
meout, select Block session if cerficate status cannot be retrieved within meout.
Otherwise, the firewall allows the sessions.
6. (GlobalProtect only) If you want the firewall to block sessions when the serial number
aribute in the subject of the client cerficate does not match the host ID that the
GlobalProtect app reports for the endpoint, select Block sessions if the cerficate was
not issued to the authencang device.
STEP 5 | Click OK and Commit
Configure an SSL/TLS Service Profile

Palo Alto Networks firewalls and Panorama use SSL/TLS service profiles to specify a cerficate
and the allowed protocol versions for SSL/TLS services. The firewall and Panorama use SSL/TLS
for Authencaon Portal, GlobalProtect portals and gateways, inbound traffic on the management
(MGT) interface, the URL Admin Override feature, and the User-ID™ syslog listening service.
By defining the protocol versions, you can use a profile to restrict the cipher suites that are
available for securing communicaon with the clients requesng the services. This improves
network security by enabling the firewall or Panorama to avoid SSL/TLS versions that have known
weaknesses. If a service request involves a protocol version that is outside the specified range, the
firewall or Panorama downgrades or upgrades the connecon to a supported version.
In the client systems that request firewall services, the cerficate trust list (CTL) must
include the cerficate authority (CA) cerficate that issued the cerficate specified in
the SSL/TLS service profile. Otherwise, users will see a cerficate error when requesng
firewall services. Most third-party CA cerficates are present by default in client browsers.
If an enterprise or firewall-generated CA cerficate is the issuer, you must deploy that CA
cerficate to the CTL in client browsers.
STEP 1 | For each desired service, generate or import a cerficate on the firewall (see Obtain
Cerficates).
Use only signed cerficates, not CA cerficates, in SSL/TLS service profiles.
STEP 2 | Select Device > Cerficate Management > SSL/TLS Service Profile.
STEP 3 | If the firewall has more than one virtual system (vsys), select the Locaon (vsys or Shared)
where the profile is available.
STEP 4 | Click Add and enter a Name to idenfy the profile.
STEP 5 | Select the Cerficate you just obtained.
STEP 6 | Define the range of protocols that the service can use:
• For the Min Version, select the earliest allowed TLS version: TLSv1.0 (default), TLSv1.1, or
TLSv1.2.
• For the Max Version, select the latest allowed TLS version: TLSv1.0, TLSv1.1, TLSv1.2, or
Max (latest available version). The default is Max.
As a best pracce, set the Min Version to TLSv1.2 and the Max Version to Max.
On firewalls in FIPS/CC mode running PAN-OS 8.0 or a later release, TLSv1.1 is the earliest
supported TLS version; do not select TLSv1.0.
Client cerficates that are used when requesng firewall services that rely on TLSv1.2 cannot
have SHA512 as a digest algorithm. The client cerficates must use a lower digest algorithm
(such as SHA384) or you must limit the Max Version to TLSv1.1 for the firewall services.
Configure an SSH Service Profile

SSH service profiles enable you to customize SSH parameters to enhance the security and
integrity of SSH connecons to your Palo Alto Networks management and high availability
(HA) appliances. By default, SSH supports all ciphers, key exchange algorithms, and message
authencaon codes, which leaves your connecon vulnerable to aack. With an SSH service
profile, you can restrict the algorithms your SSH server supports. You can also generate a new
host key and specify data volume, me, and packet-based thresholds for SSH session key
regeneraon and exchange.
Depending on the SSH server instance, configure either a management or HA SSH service profile.
You can configure profiles from the firewall or Panorama™ web interface (if applying sengs
across mulple firewalls or appliances) or the CLI.
You can configure a maximum of four management and four HA server profiles.
To use the same SSH connecon sengs for each Dedicated Log Collector (M-series or
Panorama virtual appliance in Log Collector mode) in a Collector Group, configure an SSH
service profile from the Panorama management server, Commit the changes to Panorama,
and then Push the configuraon to the Log Collectors. You can also perform these steps
from the CLI using set log-collector-group <name> general-setting
management ssh commands.
• Create an SSH Management Profile

• Create an SSH HA Profile
Create an SSH Management Profile

You must create an SSH management profile to customize SSH sengs for management
connecons.
You can configure or update an exisng management profile from your CLI.
STEP 1 | Create a Management - Server Profile.

1. Select Device > Cerficaon Management > SSH Service Profile.
2. Add a Management - Server Profile.

4. (Oponal) Add the ciphers, message authencaon codes, or key exchange algorithms
the profile will support.
5. (Oponal) Select a Hostkey and key length.
6. (Oponal) Enter values for the SSH session rekey parameters: Data, Interval, and
Packets.
STEP 2 | Select a management profile to apply.

1. Select Device > Setup > Management. Under SSH Management Profiles Sengs, select
an exisng profile.
2. Click OK and Commit the changes.
STEP 3 | Restart management SSH service from the CLI to apply the profile.
You must restart the connecon each me you apply a new profile or make changes to a profile
in use; this reboots the appliance. The new configuraons will not affect acve sessions. The
profile will apply to subsequent connecons (or sessions).
1. admin@PA-3260> set ssh service-restart mgmt
Create an SSH HA Profile

To secure SSH communicaons between appliances in an HA pair, you should create an SSH
HA profile. Before you can create a profile, you must establish an HA connecon between the
appliances. If an HA connecon has not been established, you must enable encrypon on the
control link connecon, export the HA key to a network locaon, and import the HA key on the
peer. (See Configure Acve/Passive HA or Configure Acve/Acve HA.)
You can configure or update an exisng HA profile from your CLI.
STEP 1 | Create an HA Profile.

1. Select Device > Cerficaon Management > SSH Service Profile.
2. Add an HA Profile.

4. (Oponal) Add the ciphers, message authencaon codes, or key exchange algorithms
the profile will support.
5. (Oponal) Select a Hostkey and key length.
6. (Oponal) Enter values for the SSH session rekey parameters: Data, Interval, and
Packets.
STEP 2 | Select an HA Profile to apply.

1. Select Device > High Availability > General. Under SSH HA Profile Seng, select an
exisng profile.
2. Click OK and Commit the changes.
STEP 3 | Restart HA1 SSH service from the CLI to apply the profile.
You must restart the connecon each me you apply a new profile or make changes to a profile
in use; this reboots the appliance. The new configuraon will not affect acve sessions. The
profile will apply to subsequent connecons (or sessions).
1. admin@PA-3260> set ssh service-restart ha
You can use the following commands if connecon between the HA pair has
been established and you’d like to minimize the downme that accompanies an
SSH service restart. If no HA connecon has been established, you must restart
SSH service.
• (HA1 Backup is configured) admin@PA-3260> request high-
availability session-reestablish
• (No HA1 Backup is configured or HA1 Backup link is down)
admin@PA-3260> request high-availability session-
reestablish force
You can force the firewall to reestablish HA1 sessions if there is no HA1
backup, which causes a brief split-brain condion between the HA peers.
(Using the force opon when an HA1 backup is configured has no effect.)
Replace the Cerficate for Inbound Management Traffic

When you first boot up the firewall or Panorama, it automacally generates a default cerficate
that enables HTTPS access to the web interface and XML API over the management (MGT)
interface and (on the firewall only) over any other interface that supports HTTPS management
traffic (for details, see Use Interface Management Profiles to Restrict Access). To improve the
security of inbound management traffic, replace the default cerficate with a new cerficate
issued specifically for your organizaon.
You cannot view, modify, or delete the default cerficate.

To secure management traffic, you must also Configure Administrave Accounts and
Authencaon.
STEP 1 | Obtain the cerficate that will authencate the firewall or Panorama to the client systems of
administrators.
You can simplify your Cerficate Deployment by using a cerficate that the client systems
already trust. Therefore, we recommend that you Import a Cerficate and Private Key from
your enterprise cerficate authority (CA) or Obtain a Cerficate from an External CA; the
trusted root cerficate store of the client systems is likely to already have the associated root
CA cerficate that ensures trust.
If you Generate a Cerficate on the firewall or Panorama, administrators will see a

cerficate error because the root CA cerficate is not in the trusted root cerficate
store of client systems. To prevent this, deploy the self-signed root CA cerficate to all
client systems.
Regardless of how you obtain the cerficate, we recommend a Digest algorithm of

sha256 or higher for enhanced security.
STEP 2 | Configure an SSL/TLS Service Profile.

Select the Cerficate you just obtained.
For enhanced security, we recommend that you set the Min Version (earliest allowed
TLS version) to TLSv1.2 for inbound management traffic. We also recommend that you
use a different SSL/TLS Service Profile for each firewall or Panorama service instead of
reusing this profile for all services.
STEP 3 | Apply the SSL/TLS Service Profile to inbound management traffic.

2. Select the SSL/TLS Service Profile you just configured.
Configure the Key Size for SSL Forward Proxy Server

Cerficates
When responding to a client in an SSL Forward Proxy session, the firewall creates a copy of the
cerficate that the desnaon server presents and uses the copy to establish a connecon with
the client. By default, the firewall generates cerficates with the same key size as the cerficate
that the desnaon server presented. However, you can change the key size for the firewall-
generated cerficate as follows:
STEP 1 | Select Device > Setup > Session and, in the Decrypon Sengs secon, click SSL Forward
Proxy Sengs.
STEP 2 | Select a Key Size:

• Defined by desnaon host—The firewall determines the key size and the hashing
algorithm for the cerficates it generates to establish SSL proxy sessions with clients based
on the desnaon server cerficate. If the desnaon server uses a 1,024-bit RSA key, the
firewall generates a cerficate with a 1,024-bit RSA key. If the desnaon server uses a key
size larger than 1,024 bits (for example, 2,048 bits or 4,096 bits), the firewall generates a
cerficate that uses a 2,048-bit RSA key. If the desnaon server uses the SHA-1 hashing
algorithm, the firewall generates a cerficate with the SHA-1 hashing algorithm. If the
desnaon server uses a hashing algorithm stronger than SHA-1, the firewall generates a
cerficate with the SHA-256 algorithm. This is the default seng.
• 1024-bit RSA—The firewall generates cerficates that use a 1,024-bit RSA key and
SHA-256 hashing algorithm regardless of the key size of the desnaon server cerficates.
As of December 31, 2013, public cerficate authories (CAs) and popular browsers have
limited support for X.509 cerficates that use keys of fewer than 2,048 bits. In the future,
depending on security sengs, when presented with such keys the browser might warn the
user or block the SSL/TLS session enrely.
• 2048-bit RSA—The firewall generates cerficates that use a 2,048-bit RSA key and
SHA-256 hashing algorithm regardless of the key size of the desnaon server cerficates.
Public CAs and popular browsers support 2,048-bit keys, which provide beer security than
the 1,024-bit keys.
Changing the key size seng clears the current cerficate cache.
Revoke and Renew Cerficates

• Revoke a Cerficate
• Renew a Cerficate
Revoke a Cerficate
Various circumstances can invalidate a cerficate before the expiraon date. Some examples are
a change of name, change of associaon between subject and cerficate authority (for example,
an employee terminates employment), and compromise (known or suspected) of the private key.
Under such circumstances, the cerficate authority (CA) that issued the cerficate must revoke it.
The following task describes how to revoke a cerficate for which the firewall is the CA.
STEP 2 | If the firewall supports mulple virtual systems, the tab displays a Locaon drop-down.
Select the virtual system to which the cerficate belongs.
STEP 3 | Select the cerficate to revoke.
STEP 4 | Click Revoke. PAN-OS immediately sets the status of the cerficate to revoked and adds the
serial number to the Online Cerficate Status Protocol (OCSP) responder cache or cerficate
revocaon list (CRL). You need not perform a commit.
Renew a Cerficate
If a cerficate expires, or soon will, you can reset the validity period. If an external cerficate
authority (CA) signed the cerficate and the firewall uses the Online Cerficate Status Protocol
(OCSP) to verify cerficate revocaon status, the firewall uses the OCSP responder informaon
to update the cerficate status (see Configure an OCSP Responder). If the firewall is the CA that
issued the cerficate, the firewall replaces it with a new cerficate that has a different serial
number but the same aributes as the old cerficate.
the cerficate.
STEP 3 | Select a cerficate to renew and click Renew.
STEP 4 | Enter a New Expiraon Interval (in days).
Secure Keys with a Hardware Security Module

A hardware security module (HSM) is a physical device that manages digital keys. An HSM
provides secure storage and generaon of digital keys. It provides both logical and physical
protecon of these materials from non-authorized use and potenal adversaries.
HSM clients integrated with Palo Alto Networks firewalls and Panorama enable enhanced security
for the private keys used in SSL/TLS decrypon (both SSL forward proxy and SSL inbound
inspecon). In addion, you can use the HSM to encrypt master keys.
The following topics describe how to integrate an HSM with your firewall or Panorama:
• Set Up Connecvity with an HSM
• Encrypt a Master Key Using an HSM
• Store Private Keys on an HSM
• Manage the HSM Deployment
Set Up Connecvity with an HSM

HSM clients are integrated with PA-3200 Series, PA-5200 Series, PA-7000 Series, and VM-Series
firewalls and with the Panorama management server (both virtual and M-Series appliances) for use
with the following HSM vendors:
• nCipher nShield Connect—The supported client versions depend on the PAN-OS release:
• PAN-OS 10.1 supports client version 12.40.2 (backward compable up to client version
11.50 for older appliances).
• PAN-OS 9.1, 9.0, and 8.1 support client version 12.30.
• PAN-OS 8.0 and earlier releases support client version 11.62.
• SafeNet Network—The supported client versions depend on the PAN-OS release:
• PAN-OS 10.1 supports client versions 5.4.2 and 7.2.
• PAN-OS 9.1 and 9.0 support client versions 5.4.2 and 6.3.
• PAN-OS 8.1 supports client versions 5.4.2 and 6.2.2.
• PAN-OS 8.0.2 and later PAN-OS 8.0 releases (also PAN-OS 7.1.10 and later PAN-OS 7.1
releases) support client versions 5.2.1, 5.4.2, and 6.2.2.
The HSM server version must be compable with these client versions. Refer to the HSM vendor
documentaon for the client-server version compability matrix. On the firewall or Panorama, use
the following procedure to select the SafeNet Network client version that is compable with your
SafeNet HSM server.
Downgrading HSM servers might not be an opon aer you upgrade them.
• Set Up Connecvity with a SafeNet Network HSM

• Set Up Connecvity with an nCipher nShield Connect HSM
Install the SafeNet Client RPM Packet Manager.

1. Select Device > Setup > HSM and Select HSM Client Version (Hardware Security
Operaons sengs).
2. Select Version 5.4.2 (default) or 7.2 as appropriate for your HSM server version.
3. Click OK.
4. (Required only if you change the HSM version on the firewall) If the version change
succeeds, the firewall prompts you to reboot to change to the new HSM version. If
prompted, click Yes.
5. If the master key isn’t on the firewall, the client version upgrade will fail. Close the
message and make the master key local to the firewall:
• Edit the Hardware Security Module Provider and disable (clear) the Master Key
Secured by HSM opon.
• Click OK.
• Select Device > Master Key and Diagnoscs to edit the Master Key.
• Enter the Current Master Key; you can then enter that same key to be the New
Master Key and then Confirm New Master Key.
• Click OK.
• Repeat the first four steps to Select HSM Client Version and reboot again.
Set Up Connecvity with a SafeNet Network HSM

To set up connecvity between the Palo Alto Networks firewall (HSM client) and a SafeNet
Network HSM server, you must specify the IP address of the server, enter a password for
authencang the firewall to the server, and then register the firewall with the server. Before you
being configuring your HSM client, create a paron for the firewall on the HSM server and then
confirm that the SafeNet Network client version on the firewall is compable with your SafeNet
Network HSM server (see Set Up Connecvity with an HSM).
Before the HSM and firewall connect, the HSM authencates the firewall based on the firewall
IP address. Therefore, you must configure the firewall to use a stac IP address—not a dynamic
address assigned through DHCP. Operaons on the HSM stop working if the firewall IP address
changes during runme.
HSM configuraons are not synchronized between high availability (HA) firewall peers.
Consequently, you must configure the HSM separately on each peer. In acve/passive HA
configuraons, you must manually perform one failover to individually configure and
authencate each HA peer to the HSM. Aer this inial manual failover, user interacon is
not required for failover to funcon properly.
STEP 1 | Define connecon sengs for each SafeNet Network HSM.

1. Log in to the firewall web interface and select Device > Setup > HSM.
2. Edit the Hardware Security Module Provider sengs and set the Provider Configured to
SafeNet Network HSM.
3. Add each HSM server as follows. A high availability (HA) HSM configuraon requires at
least two servers; you can have a cluster of up to 16 HSM servers. All HSM servers in
the cluster must run the same SafeNet version and must authencate separately. You
should use a SafeNet cluster only when you want to replicate the keys across the cluster.
Alternavely, you can add up to 16 SafeNet HSM servers to funcon independently.
1. Enter a Module Name (an ASCII string of up to 31 characters) for the HSM server.
2. Enter an IPv4 address for the HSM Server Address.
4. (HA only) Select High Availability, specify the Auto Recovery Retry value (maximum
number of mes the HSM client tries to recover its connecon to an HSM server before
failing over to an HSM HA peer server; range is 0 to 500; default is 0), and enter a High
Availability Group Name (an ASCII string up to 31 characters long).
If you configure two or more HSM servers, the best pracce is to enable High
Availability. Otherwise the firewall does not use the addional HSM servers.
5. Click OK and Commit your changes.
STEP 2 | (Oponal) Configure a service route to connect to the HSM if you don’t want the firewall to
connect through the Management interface (default).
If you configure a service route for the HSM, running the clear session all
CLI command clears all exisng HSM sessions, which brings all HSM states down and
then up again. During the several seconds required for HSM to recover, all SSL/TLS
operaons will fail.
1. Select Device > Setup > Services and click Service Route Configuraon.
2. Customize a service route. The IPv4 tab is acve by default.
3. Click HSM in the Service column.
4. Select a Source Interface for the HSM.
STEP 3 | Configure the firewall to authencate to the HSM.

1. Select Device > Setup and Setup Hardware Security Module.
2. Select the HSM Server Name.
3. Select Automac or Manual for your authencaon and trust cerficate.
4. Enter the Administrator Password to authencate the firewall to the HSM.
5. Click OK.
The firewall tries to authencate to the HSM and displays a status message.
6. Click OK again.
STEP 4 | Register the firewall as an HSM client with the HSM server and assign the firewall to a
paron on the HSM server.
If the HSM has a firewall with the same <cl-name> already registered, you must first
remove the duplicate registraon by running the client delete -client <cl-
name> command, where <cl-name> is the name of the registered client (firewall) you
want to delete.
1. Log in to the HSM from a remote system.

2. Register the firewall using the client register -c <cl-name> -ip <fw-ip-
addr> CLI command, where <cl-name> is a name that you assign to the firewall for use
on the HSM and <fw-ip-addr> is the IP address for that firewall.
3. Assign a paron to the firewall using the client assignpartition -c <cl-
name> -p <partition-name> CLI command, where <cl-name> is the name you
assigned to the firewall using the client register command and <paron-name> is
the name of a previously configured paron that you want to assign to this firewall.
STEP 5 | Configure the firewall to connect to the HSM paron.

1. Select Device > Setup > HSM and refresh ( ) the display.
2. Setup HSM Paron (Hardware Security Operaons sengs).
3. Enter the Paron Password to authencate the firewall to the paron on the HSM.
4. Click OK.
STEP 6 | (HA only) Repeat the previous authencaon, registraon, and paron connecon steps to
add another HSM to the exisng HA group.
If you remove an HSM from your configuraon, repeat the previous paron
connecon step to remove the deleted HSM from the HA group.
STEP 7 | Verify firewall connecvity and authencaon with the HSM.

1. Select Device > Setup > HSM and check the authencaon and connecon Status:
• Green—The firewall is successfully authencated and connected to the HSM.
• Red—The firewall failed to authencate to the HSM or network connecvity to the
HSM is down.
2. View the following columns in Hardware Security Module Status to determine the
authencaon status:
• Serial Number—The serial number of the HSM paron if the firewall successfully
authencated to the HSM.
• Paron—The paron name on the HSM that is assigned to the firewall.
• Module State—The current state of the HSM connecon. This value is always
Authenticated if the Hardware Security Module Status displays the HSM.
Set Up Connecvity with an nCipher nShield Connect HSM

You must set up a remote file system (RFS) as a hub to synchronize key data for all firewalls (HSM
clients) in your organizaon that use the nCipher nShield Connect HSM. To ensure the nShield
Connect client version on your firewalls is compable with your nShield Connect server, see Set
Up Connecvity with an HSM.
Before the HSM and firewalls connect, the HSM authencates the firewalls based on their IP
addresses. Therefore, you must configure the firewalls to use stac IP addresses—not dynamic
addresses assigned through DHCP. (Operaons on the HSM stop working if a firewall IP address
changes during runme).
HSM configuraons are not synchronized between high availability (HA) firewall peers.
Consequently, you must configure the HSM separately on each peer. In acve/passive HA
configuraons, you must manually perform one failover to individually configure and
authencate each HA peer to the HSM. Aer this inial manual failover, user interacon is
not required for failover to funcon properly.
STEP 1 | Define connecon sengs for each nCipher nShield Connect HSM.
1. Log in to the firewall web interface and select Device > Setup > HSM.
2. Edit the Hardware Security Module Provider sengs and set the Provider Configured to
nShield Connect.
3. Add each HSM server as follows. An HA HSM configuraon requires two servers.
1. Enter a Module Name for the HSM server. This can be any ASCII string of up to 31
characters.
2. Enter an IPv4 address for the HSM Server Address.
4. Enter an IPv4 address for the Remote Filesystem Address.
STEP 2 | (Oponal) Configure a service route to connect to the HSM if you don’t want the firewall to
connect through the Management interface (default).
If you configure a service route for the HSM, running the clear session all
CLI command clears all exisng HSM sessions, which brings all HSM states down and
then up again. During the several seconds required for HSM to recover, all SSL/TLS
operaons will fail.
1. Select Device > Setup > Services and click Service Route Configuraon.
2. Customize a service route. The IPv4 tab is acve by default.
3. Click HSM in the Service column.
4. Select a Source Interface for the HSM.
STEP 3 | Register the firewall as an HSM client with the HSM server.
This step briefly describes the procedure for using the front panel interface of the nShield
Connect HSM. For more details, refer to nCipher documentaon.
1. Log in to the front panel display of the nCipher nShield Connect HSM.
2. Use the right-hand navigaon buon to select System > System configuraon > Client
config > New client.
3. Enter the firewall IP address.
4. Select System > System configuraon > Client config > Remote file system and enter
the IP address of the client computer where you set up the RFS.
STEP 4 | Configure the RFS to accept connecons from the firewall.

1. Log in to the RFS from a Linux client.
2. Obtain the electronic serial number (ESN) and the hash of the KNETI key, which
authencates the HSM to clients, by running the anonkneti <ip-address> CLI
command, where <ip-address> is the HSM IP address.
For example:
anonkneti 192.0.2.1
B1E2-2D4C-E6A2 5a2e5107e70d525615a903f6391ad72b1c03352c
In this example, B1E2-2D4C-E6A2 is the ESN and

5a2e5107e70d525615a903f6391ad72b1c03352c is the hash of the KNETI key.
3. Use the following command from a superuser account to set up the RFS:
rfs-setup --force <ip-address> <ESN> <hash-Kneti-key>
The <ip-address> is the IP address of the HSM, <ESN> is the electronic serial number, and
<hash-Kne-key> is the hash of the KNETI key.
The following example uses the values obtained in this procedure:
rfs-setup --force 192.0.2.1 B1E2-2D4C-E6A2

5a2e5107e70d525615a903f6391ad72b1c03352c
4. Use the following command to permit HSM client submissions on the RFS:
rfs-setup --gang-client --write-noauth <FW-IPaddress>
where <FW-IPaddress> is the firewall IP address.
STEP 5 | Authencate the firewall to the HSM.

1. In the firewall web interface, select Device > Setup > HSM and Setup Hardware Security
Module.
2. Click OK.
The firewall tries to authencate to the HSM and displays a status message.
3. Click OK.
STEP 6 | Synchronize the firewall with the RFS by selecng Device > Setup > HSM and Synchronize
with Remote Filesystem.
STEP 7 | Verify firewall connecvity and authencaon with the HSM.

1. Select Device > Setup > HSM and check the authencaon and connecon Status:
• Green—The firewall is successfully authencated and connected to the HSM.
• Red—The firewall failed to authencate to the HSM or network connecvity to the
HSM is down.
2. Check the Hardware Security Module Status to determine the authencaon status.
• Name—The name of the HSM.
• IP address—The IP address of the HSM.
• Module State—The current state of the HSM connecon: Authenticated or
NotAuthenticated.
Encrypt a Master Key Using an HSM

A master key encrypts all private keys and passwords on the firewall and Panorama. If you have
security requirements to store your private keys in a secure locaon, you can encrypt the master
key using an encrypon key that is stored on an HSM. The firewall or Panorama then requests the
HSM to decrypt the master key whenever it is required to decrypt a password or private key on
the firewall. Typically, the HSM is in a highly secure locaon that is separate from the firewall or
Panorama for greater security.
The HSM encrypts the master key using a wrapping key. To maintain security, you must
occasionally change (refresh) this wrapping key.
Firewalls configured in FIPS/CC mode do not support master key encrypon using an
HSM.
The following topics describe how to encrypt the master key inially and how to refresh the
master key encrypon:
• Encrypt the Master Key
• Refresh the Master Key Encrypon
Encrypt the Master Key

If you have not previously encrypted the master key on a firewall, use the following procedure to
encrypt it. Use this procedure for first me encrypon of a key, or if you define a new master key
and you want to encrypt it. If you want to refresh the encrypon on a previously encrypted key,
see Refresh the Master Key Encrypon.
STEP 1 | Select Device > Master Key and Diagnoscs.
STEP 2 | Specify the key that is currently used to encrypt all of the private keys and passwords on the
firewall in the Master Key field.
STEP 3 | If changing the master key, enter the new master key and confirm.
STEP 4 | Select the HSM check box.

• Life Time—The number of days and hours aer which the master key expires (range 1-730
days).
• Time for Reminder—The number of days and hours before expiraon when the user is
nofied of the impending expiraon (range 1–365 days).
STEP 5 | Click OK.
Refresh the Master Key Encrypon

As a best pracce, periodically refresh the master key encrypon by rotang the wrapping key
that encrypts it. The frequency of the rotaon depends on your applicaon. The wrapping key
resides on your HSM. The following command is the same for SafeNet Network and nCipher
nShield Connect HSMs.
STEP 1 | Log in to the firewall CLI.
STEP 2 | Use the following CLI command to rotate the wrapping key for the master key on an HSM:
> request hsm mkey-wrapping-key-rotation
If the master key is encrypted on the HSM, the CLI command will generate a new wrapping key
on the HSM and encrypt the master key with the new wrapping key.
If the master key is not encrypted on the HSM, the CLI command will generate new wrapping
key on the HSM for future use.
The old wrapping key is not deleted by this command.
Store Private Keys on an HSM

For added security, you can use an HSM to secure the private keys used in SSL/TLS decrypon
for:
• SSL Forward Proxy—The HSM can store the private key of the Forward Trust cerficate
that signs cerficates in SSL/TLS forward proxy operaons. The firewall will then send the
cerficates that it generates during such operaons to the HSM for signing before forwarding
the cerficates to the client.
• SSL Inbound Inspecon—The HSM can store the private keys for the internal servers for which
you are performing SSL/TLS inbound inspecon.
If you use the DHE or ECDHE key exchange algorithms to enable perfect forward secrecy (PFS)
support for SSL decrypon, you can use an HSM to store the private keys for SSL Inbound
Inspecon. You can also use an HSM to store ECDSA keys used for SSL Forward Proxy or SSL
Inbound Inspecon decrypon unless you are using TLSv1.3. For TLSv1.3 traffic, PAN-OS
supports HSMs only for SSL Forward Proxy. It does not support HSMs for SSL Inbound Inspecon.
STEP 1 | On the HSM, import or generate the cerficate and private key used in your decrypon
deployment.
For instrucons on imporng or generang a cerficate and private key on the HSM, refer to
your HSM documentaon.
STEP 2 | (nCipher nShield Connect only) Synchronize the key data from the nCipher nShield remote
file system to the firewall.
Synchronizaon with the SafeNet Network HSM is automac.
1. Access the firewall web interface and select Device > Setup > HSM.
2. Synchronize with Remote Filesystem (Hardware Security Operaons sengs).
STEP 3 | Import the cerficate that corresponds to the HSM-stored key.

1. Select Device > Cerficate Management > Cerficates > Device Cerficates and click
Import.
2. Enter the Cerficate Name.
3. Browse to the Cerficate File on the HSM.
4. Select a File Format.
5. Select Private Key resides on Hardware Security Module.
STEP 4 | (Forward Trust cerficates only) Enable the cerficate for use in SSL/TLS Forward Proxy.
1. Open the cerficate you imported in Step 3 for eding.
2. Select Forward Trust Cerficate.
STEP 5 | Verify that you successfully imported the cerficate onto the firewall.
Locate the cerficate you imported in Step 3 and check the icon in the Key column:
• Lock icon—The private key for the cerficate is on the HSM.
• Error icon—The private key is not on the HSM or the HSM is not properly authencated or
connected.
Manage the HSM Deployment

You can perform the following tasks to manage your HSM deployment:
View the HSM configuraon sengs.

Select Device > Setup > HSM.
Display detailed HSM informaon.

Select Show Detailed Informaon from the Hardware Security Operaons secon.
Informaon regarding the HSM servers, HSM HA status, and HSM hardware is displayed.
Export Support file.

Select Export Support File from the Hardware Security Operaons secon.
A test file is created to help customer support when addressing a problem with an HSM
configuraon on the firewall.
Reset HSM configuraon.

Select Reset HSM Configuraon from the Hardware Security Operaons secon.
Selecng this opon removes all HSM connecons. All authencaon procedures must be
repeated aer using this opon.
High Availability
High availability (HA) is a deployment in which two firewalls are placed in a group or
up to 16 firewalls are placed in an HA cluster 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 HA provides redundancy and allows you to ensure business connuity.
> HA Overview > Configure HA Clustering
> HA Concepts > Refresh HA1 SSH Keys and
> Set Up Acve/Passive HA Configure Key Opons
> Set Up Acve/Acve HA > HA Firewall States
> HA Clustering Overview > Reference: HA Synchronizaon
> HA Clustering Best Pracces and > CLI Cheat Sheet - HA

Provisioning
359
High Availability
HA Overview
You can configure two Palo Alto Networks firewalls as an HA pair or configure up to 16 firewalls
as peer members of an HA cluster. The peers in the cluster can be HA pairs or standalone
firewalls. HA allows you to minimize downme by making sure that an alternate firewall
is available in the event that a peer firewall fails. The firewalls in an HA pair or cluster use
dedicated or in-band HA ports on the firewall to synchronize data—network, object, and policy
configuraons—and to maintain state informaon. Firewall-specific configuraon such as
management interface IP address or administrator profiles, HA specific configuraon, log data, and
the Applicaon Command Center (ACC) informaon is not shared between peers.
For a consolidated applicaon and log view across an HA pair, you must use Panorama, the Palo
Alto Networks centralized management system. See Context Switch—Firewall or Panorama
in the Panorama Administrator’s Guide. Consult the Prerequisites for Acve/Passive HA and
Prerequisites for Acve/Acve HA. It is highly recommended that you use Panorama to provision
HA cluster members. Consult the HA Clustering Best Pracces and Provisioning.
When a failure occurs on a firewall in an HA pair or HA cluster and a peer firewall takes over the
task of securing traffic, the event is called a Failover. The condions that trigger a failover are:
• One or more of the monitored interfaces fail. (Link Monitoring)
• One or more of the desnaons specified on the firewall cannot be reached. (Path Monitoring)
• The firewall does not respond to heartbeat polls. (Heartbeat Polling and Hello messages)
• A crical chip or soware component fails, known as packet path health monitoring.
Palo Alto Networks firewalls support stateful acve/passive or acve/acve high availability with
session and configuraon synchronizaon with a few excepons:
• The VM-Series firewall on Azure and VM-Series firewall on AWS support acve/passive HA
only.
On AWS, when you deploy the firewall with the Amazon Elasc Load Balancing (ELB) service, it
does not support HA (in this case, ELB service provides the failover capabilies).
• The VM-Series firewall on Google Cloud Plaorm does not support HA.
Begin by understanding the HA Concepts and the HA Clustering Overview if you are going to
configure HA clustering.
High Availability
HA Concepts
The following topics provide conceptual informaon about how HA works on a Palo Alto
Networks firewall:
• HA Modes
• HA Links and Backup Links
• Device Priority and Preempon
• Failover
• LACP and LLDP Pre-Negoaon for Acve/Passive HA
• Floang IP Address and Virtual MAC Address
• ARP Load-Sharing
• Route-Based Redundancy
• HA Timers
• Session Owner
• Session Setup
• NAT in Acve/Acve HA Mode
• ECMP in Acve/Acve HA Mode
HA Modes
You can set up the firewalls in an HA pair in one of two modes:
• Acve/Passive— One firewall acvely manages traffic while the other is synchronized and
ready to transion to the acve state, should a failure occur. In this mode, both firewalls share
the same configuraon sengs, and one acvely manages traffic unl a path, link, system, or
network failure occurs. When the acve firewall fails, the passive firewall transions to the
acve state and takes over seamlessly and enforces the same policies to maintain network
security. Acve/passive HA is supported in the virtual wire, Layer 2, and Layer 3 deployments.
• Acve/Acve— Both firewalls in the pair are acve and processing traffic and work
synchronously to handle session setup and session ownership. Both firewalls individually
maintain session tables and roung tables and synchronize to each other. Acve/acve HA is
supported in virtual wire and Layer 3 deployments.
In acve/acve HA mode, the firewall does not support DHCP client. Furthermore, only the
acve-primary firewall can funcon as a DHCP Relay. If the acve-secondary firewall receives
DHCP broadcast packets, it drops them.
An acve/acve configuraon does not load-balance traffic. Although you can load-
share by sending traffic to the peer, no load balancing occurs. Ways to load share
sessions to both firewalls include using ECMP, mulple ISPs, and load balancers.
When deciding whether to use acve/passive or acve/acve mode, consider the following
differences:
High Availability
• Acve/passive mode has simplicity of design; it is significantly easier to troubleshoot roung

and traffic flow issues in acve/passive mode. Acve/passive mode supports a Layer 2
deployment; acve/acve mode does not.
• Acve/acve mode requires advanced design concepts that can result in more complex
networks. Depending on how you implement acve/acve HA, it might require addional
configuraon such as acvang networking protocols on both firewalls, replicang NAT pools,
and deploying floang IP addresses to provide proper failover. Because both firewalls are
acvely processing traffic, the firewalls use addional concepts of session owner and session
setup to perform Layer 7 content inspecon. Acve/acve mode is recommended if each
firewall needs its own roung instances and you require full, real-me redundancy out of both
firewalls all the me. Acve/acve mode has faster failover and can handle peak traffic flows
beer than acve/passive mode because both firewalls are acvely processing traffic.
In acve/acve mode, the HA pair can be used to temporarily process more traffic
than what one firewall can normally handle. However, this should not be the norm
because a failure of one firewall causes all traffic to be redirected to the remaining
firewall in the HA pair. Your design must allow the remaining firewall to process the
maximum capacity of your traffic loads with content inspecon enabled. If the design
oversubscribes the capacity of the remaining firewall, high latency and/or applicaon
failure can occur.
For informaon on seng up your firewalls in acve/passive mode, see Set Up Acve/Passive
HA. For informaon on seng up your firewalls in acve/acve mode, see Set Up Acve/Acve
HA.
In an HA cluster, all members are considered acve; there is no concept of passive firewalls except
for HA pairs in the clusters, which can keep their acve/passive relaonship aer you add them to
an HA cluster.
HA Links and Backup Links

The firewalls in an HA pair use HA links to synchronize data and maintain state informaon. Some
models of the firewall have dedicated HA ports—Control link (HA1) and Data link (HA2), while
others require you to use the in-band ports as HA links.
• For firewalls with dedicated HA ports, use these ports to manage communicaon and
synchronizaon between the firewalls. For details, see HA Ports on Palo Alto Networks
Firewalls.
• For firewalls without dedicated HA ports such as the PA-220 and PA-220R firewalls, as a best
pracce use the management port for the HA1 port, and use the dataplane port for the HA1
backup.
For firewalls without dedicated HA ports, decide which ports to use for HA1 and HA1
backup based on your environment and understanding which are the least used and
least congested. Assign HA1 to the best interface and HA1 backup to the other one.
HA peers in an HA cluster can be a combinaon of standalone members and HA pairs. HA cluster
members use an HA4 link and HA4 backup link to perform session state syncronizaon. HA1
(control link), HA2 (data link), and HA3 (packet-forwarding link) are not supported between cluster
members that aren’t HA pairs.
High Availability
HA Links and Backup Descripon

Links
Control Link The HA1 link is used to exchange hellos, heartbeats, and HA state
informaon, and management plane sync for roung, and User-
ID informaon. The firewalls also use this link to synchronize
configuraon changes with its peer. The HA1 link is a Layer 3 link and
requires an IP address.
ICMP is used to exchange heartbeats between HA peers.
Ports used for HA1—TCP port 28769 and 28260 for clear text
communicaon; port 28 for encrypted communicaon (SSH over TCP).
If you enable encrypon on the HA1 link, you can also Refresh HA1
SSH Keys and Configure Key Opons.
Data Link The HA2 link is used to synchronize sessions, forwarding tables, IPSec
security associaons and ARP tables between firewalls in an HA pair.
Data flow on the HA2 link is always unidireconal (except for the HA2
keep-alive); it flows from the acve or acve-primary firewall to the
passive or acve-secondary firewall. The HA2 link is a Layer 2 link, and
it uses ether type 0x7261 by default.
Ports used for HA2—The HA data link can be configured to use either
IP (protocol number 99) or UDP (port 29281) as the transport, and
thereby allow the HA data link to span subnets.
HA1 and HA2 Provide redundancy for the HA1 and the HA2 links. In-band ports
Backup Links can be used for backup links for both HA1 and HA2 connecons
when dedicated backup links are not available. Consider the following
guidelines when configuring backup HA links:
• The IP addresses of the primary and backup HA links must not
overlap each other.
• HA backup links must be on a different subnet from the primary HA
links.
• HA1-backup and HA2-backup ports must be configured on
separate physical ports. The HA1-backup link uses port 28770 and
28260.
• PA-3200 Series firewalls don’t support an IPv6 address for the
HA1-backup link; use an IPv4 address.
Palo Alto Networks recommends enabling heartbeat backup

(uses port 28771 on the MGT interface) if you use an in-
band port for the HA1 or the HA1 backup links.
Packet-Forwarding In addion to HA1 and HA2 links, an acve/acve deployment also

Link requires a dedicated HA3 link. The firewalls use this link for forwarding
packets to the peer during session setup and asymmetric traffic flow.
High Availability
HA Links and Backup Descripon

Links
The HA3 link is a Layer 2 link that uses MAC-in-MAC encapsulaon.
It does not support Layer 3 addressing or encrypon. PA-7000 Series
firewalls synchronize sessions across the NPCs one-for-one. On
PA-800 Series, PA-3200 Series, and PA-5200 Series firewalls, you can
configure aggregate interfaces as an HA3 link. The aggregate interfaces
can also provide redundancy for the HA3 link; you cannot configure
backup links for the HA3 link. On PA-3200 Series, PA-5200 Series,
and PA-7000 Series firewalls, the dedicated HSCI ports support the
HA3 link. The firewall adds a proprietary packet header to packets
traversing the HA3 link, so the MTU over this link must be greater than
the maximum packet length forwarded.
HA4 Link and HA4 The HA4 link and HA4 backup link perform session cache
Backup Link synchronizaon among all HA cluster members having the same
cluster ID. The HA4 link between cluster members detects
connecvity failures between cluster members by sending and
receiving Layer 2 keepalive messages. View the status of the HA4 and
HA4 backup links on the firewall dashboard.
HA Ports on Palo Alto Networks Firewalls

When connecng two Palo Alto Networks® firewalls in a high availability (HA) configuraon,
we recommend that you use the dedicated HA ports for HA Links and Backup Links. These
dedicated ports include: the HA1 ports labeled HA1, HA1-A, and HA1-B used for HA control and
synchronizaon traffic; and HA2 and the High Speed Chassis Interconnect (HSCI) ports used for
HA session setup traffic. The PA-5200 Series firewalls have mulpurpose auxiliary ports labeled
AUX-1 and AUX-2 that you can configure for HA1 traffic.
You can also configure the HSCI port for HA3, which is used for packet forwarding to the peer
firewall during session setup and asymmetric traffic flow (acve/acve HA only). The HSCI port
can be used for HA2 traffic, HA3 traffic, or both.
The HA1 and AUX links provide synchronizaon for funcons that reside on the
management plane. Using the dedicated HA interfaces on the management plane is
more efficient than using the in-band ports as this eliminates the need to pass the
synchronizaon packets over the dataplane.
If your firewall does not have dedicated HA ports, you can configure data ports as HA interfaces.
If your firewall does have dedicated HA ports but does not have a dedicated HA backup port, you
can also configure data ports as backups to dedicated HA ports.
Whenever possible, connect HA ports directly between the two firewalls in an HA pair
(not through a switch or router) to avoid HA link and communicaons problems that could
occur if there is a network issue.
Use the following table to learn about dedicated HA ports and how to connect the HA Links and
Backup Links:
High Availability
Model Front-Panel Dedicated Port(s)
PA-800 Series Firewalls • HA1 and HA2—Ethernet 10Mbps/100Mbps/1000Mbps ports

used for HA1 and HA2 in both HA Modes.
• For HA1 traffic—Connect the HA1 port on the first firewall
directly to the HA1 port on the second firewall in the pair or
connect these ports together through a switch or router.
• For HA2 traffic—Connect the HA2 port on the first firewall
directly to the HA2 port on the second firewall in the pair or
connect these ports together through a switch or router.
PA-3200 Series • HA1-A and HA1-B—Ethernet 10Mbps/100Mbps/1000Mbps

Firewalls ports used for HA1 traffic in both HA Modes.
• For HA1 traffic—Connect the HA1-A port on the first firewall
directly to the HA1-A port on the second firewall in the pair or
connect them together through a switch or router.
• For a backup to the HA1-A connecon—Connect the HA1-
B port on the first firewall directly to the HA1-B port on the
second firewall in the pair or connect them together through a
switch or router.
If the firewall dataplane restarts due to a failure or

manual restart, the HA1-B link will also restart. If
this occurs and the HA1-A link is not connected
and configured, then a split brain condion occurs.
Therefore, we recommend that you connect and
configure the HA1-A ports and the HA1-B ports to
provide redundancy and to avoid split brain issues.
You can remap the firewall’s SFP ports as HA1-A

and HA1-B ports via PAN-OS or Panorama.
• HSCI—The HSCI port is a Layer 1 SFP+ interface that connects
two PA-3200 Series firewalls in an HA configuraon. Use this port
for an HA2 connecon, HA3 connecon, or both.
The traffic carried on the HSCI ports is raw Layer 1 traffic, which
is not routable or switchable. Therefore, you must connect the
HSCI ports directly to each other (from the HSCI port on the first
firewall to the HSCI port on the second firewall).

High Availability

switch or router.
• HSCI—The HSCI port is a Layer 1 interface that connects two
PA-5200 Series firewalls in an HA configuraon. Use this port for
an HA2 connecon, HA3 connecon, or both.
The HSCI port on the PA-5220 firewall is a QSFP+

port and the HSCI port on the PA-5250, PA-5260, and
PA-5280 firewalls is a QSFP28 port.
The traffic carried on the HSCI port is raw Layer 1 traffic, which
is not routable or switchable. Therefore, you must connect the
HSCI ports directly to each other (from the HSCI port on the first
firewall to the HSCI port on the second firewall).
PA-5200 Series • AUX-1 and AUX-2—The auxiliary SFP+ ports are mulpurpose
Firewalls (connued) ports that you can configure for HA1, management funcons, or
log forwarding to Panorama. Use these ports when you need a
fiber connecon for one of these funcons.
• For HA1 traffic—Connect the AUX-1 port on the first firewall
directly to the AUX-1 port on the second firewall in the pair or
• For a backup to the AUX-1 connecon—Connect the AUX-2
port on the first firewall directly to the AUX-2 port on the
switch or router.

switch or router.
You cannot configure an HA1 connecon on the

NPC data ports or the management (MGT) port.
• HSCI-A and HSCI-B—The HSCI ports are Layer 1 QSFP+
interfaces that connect two PA-7000 Series firewalls in an HA
High Availability

configuraon. Use these ports for an HA2 connecon, HA3
connecon, or both.
The traffic carried on the HSCI ports is raw Layer 1 traffic, which
is not routable or switchable. Therefore, you must connect these
ports as follows:
• For HA2 and HA3 traffic—Connect the HSCI-A port on the
first firewall directly to the HSCI-A port on the second firewall.
For HA2 or HA2/HA3 traffic, the PA-7000 Series

firewalls synchronize sessions across the NPCs one-
for-one.
• For a backup to the HSCI-A connecon—Connect the HSCI-
B port on the first firewall directly to the HSCI-B port on the
second firewall.
HA2 and HA2-Backup links can be configured to use a

dataplane interface instead of the HSCI ports. However, if
configured this way, both the HA2 and HA2-Backup links
need to use dataplane interfaces. A mix of a dataplane
port and an HSCI port for either HA2 or HA2-Backup will
result in a commit failure. This applies to the PA-7050-
SMC, PA-7080-SMC, PA-7050-SMC-B, and PA-7080-
SMC-B.
Device Priority and Preempon

The firewalls in an Acve-Passive HA pair can be assigned a device priority value to indicate a
preference for which firewall should assume the acve role. If you need to use a specific firewall
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 firewall. The firewall with the lower numerical
value, and therefore higher priority, is designated as acve. The other firewall is the passive
firewall.
The same is true for an Acve-Acve HA pair; however, the device ID is used to assign a device
priority value. Similarly, the lower numerical value in device ID corresponds to a higher priority.
The firewall with the higher priority becomes acve-primary and the paired firewall becomes
acve-secondary.
By default, preempon is disabled on the firewalls and must be enabled on both firewalls. When
enabled, the preempve behavior allows the firewall with the higher priority (lower numerical
value) to resume as acve or acve-primary aer it recovers from a failure. When preempon
occurs, the event is logged in the system logs.
High Availability
Failover
When a failure occurs on one firewall and the peer in the HA pair (or a peer in the HA cluster)
takes over the task of securing traffic, the event is called a failover. A failover is triggered, for
example, when a monitored metric on a firewall in the HA pair fails. The metrics that the firewall
monitors for detecng a firewall failure are:
• Heartbeat Polling and Hello messages
The firewalls use hello message and heartbeats to verify that the peer firewall is responsive
and operaonal. Hello messages are sent from one peer to the other at the configured Hello
Interval to verify the state of the firewall. The heartbeat is an ICMP ping to the HA peer over
the control link, and the peer responds to the ping to establish that the firewalls are connected
and responsive. By default, the interval for the heartbeat is 1000 milliseconds. A ping is sent
every 1000 milliseconds and if there are three consecuve heartbeat losses, a failovers occurs.
For details on the HA mers that trigger a failover, see HA Timers.
• Link Monitoring
You can specify a group of physical interfaces that the firewall will monitor (a link group) and
the firewall monitors the state of each link in the group (link up or link down). You determine
the failure condion for the link group: Any link down or All links down in the group constutes
a link group failure (but not necessarily a failover).
You can create mulple link groups. Therefore, you also determine the failure condion of the
set of link groups: Any link group fails or All link groups fail, which determines when a failover
is triggered. The default behavior is that failure of Any one link in Any link group causes the
firewall to change the HA state to non-funconal (or to tentave state in acve/acve mode)
to indicate a failure of a monitored object.
• Path Monitoring
You can specify a desnaon IP group of IP address that the firewall will monitor. The firewall
monitors the full path through the network to mission-crical IP addresses using ICMP pings
to verify reachability of the IP address. The default interval for pings is 200ms. An IP address
is considered unreachable when 10 consecuve pings (the default value) fail. You specify the
failure condion for the IP addresses in a desnaon IP group: Any IP address unreachable
or All IP addresses unreachable in the group. You can specify mulple desnaon IP groups
for a path group for a virtual wire, VLAN, or virtual router; you specify the failure condion
of desnaon IP groups in a path group: Any or All, which constutes a path group failure.
You can configure mulple virtual wire path groups, VLAN path groups, and virtual router path
groups.
You also determine the global failure condion: Any path group fails or All path groups fail,
which determines when a failover is triggered. The default behavior is that Any one of the IP
addresses becoming unreachable in Any desnaon IP group in Any virtual wire, VLAN, or
virtual router path group causes the firewall to change the HA state to non-funconal (or to
tentave state in acve/acve mode) to indicate a failure of a monitored object.
In addion to the failover triggers listed above, a failover also occurs when the administrator
suspends the firewall or when preempon occurs.
On PA-3200 Series, PA-5200 Series, and PA-7000 Series firewalls, a failover can occur when an
internal health check fails. This health check is not configurable and is enabled to monitor the
High Availability
crical components, such as the FPGA and CPUs. Addionally, general health checks occur on any
plaorm, causing failover.
The following describes what occurs in the event of a failure of a Network Processing Card (NPC)
on a PA-7000 Series firewall that is a member of an HA cluster:
• If the NPC that is being used to hold the HA clustering session cache (a copy of the other
members’ sessions) goes down, the firewall goes non-funconal. When this occurs, the session
distribuon device (such as a load balancer) must detect that the firewall is down and distribute
session load to the other members of the cluster.
• If the NPC of a cluster member goes down and no link monitoring or path monitoring was
enabled on that NPC, the PA-7000 Series firewall member will stay up, but with a lower
capacity because one NPC is down.
• If the NPC of a cluster member goes down and link monitoring or path monitoring was enabled
on that NPC, the PA-7000 Series firewall will go non-funconal and the session distribuon
device (such as a load balancer) must detect that the firewall is down and distribute session
load to the other members of the cluster.
LACP and LLDP Pre-Negoaon for Acve/Passive HA

If a firewall uses LACP or LLDP, negoaon of those protocols upon failover prevents sub-second
failover. However, you can enable an interface on a passive firewall to negoate LACP and LLDP
prior to failover. Thus, a firewall in Passive or Non-funconal HA state can communicate with
neighboring devices using LACP or LLDP. Such pre-negoaon speeds up failover.
All firewall models except VM-Series firewalls support a pre-negoaon configuraon, which
depends on whether the Ethernet or AE interface is in a Layer 2, Layer 3, or virtual wire
deployment. An HA passive firewall handles LACP and LLDP packets in one of two ways:
• Acve—The firewall has LACP or LLDP configured on the interface and acvely parcipates in
LACP or LLDP pre-negoaon, respecvely.
• Passive—LACP or LLDP is not configured on the interface and the firewall does not parcipate
in the protocol, but allows the peers on either side of the firewall to pre-negoate LACP or
LLDP, respecvely.
The following table displays which deployments are supported on Aggregate Ethernet (AE) and
Ethernet interfaces.
Interface Deployment AE Interface Ethernet Interface
LACP in Layer 2 Acve Not supported
LACP in Layer 3 Acve Not supported
LACP in Virtual Wire Not supported Passive
LLDP in Layer 2 Acve Acve
LLDP in Layer 3 Acve Acve
High Availability
Interface Deployment AE Interface Ethernet Interface
LLDP in Virtual Wire Acve • Acve if LLDP itself is

configured.
• Passive if LLDP itself is not
configured.
Pre-negoaon is not supported on subinterfaces or tunnel interfaces.

To configure LACP or LLDP pre-negoaon, see the step (Oponal) Enable LACP and LLDP Pre-
Negoaon for Acve/Passive HA for faster failover if your network uses LACP or LLDP.
Floang IP Address and Virtual MAC Address

In a Layer 3 deployment of HA acve/acve mode, you can assign floang IP addresses, which
move from one HA firewall to the other if a link or firewall fails. The interface on the firewall that
owns the floang IP address responds to ARP requests with a virtual MAC address.
Floang IP addresses are recommended when you need funconality such as Virtual Router
Redundancy Protocol (VRRP). Floang IP addresses can also be used to implement VPNs and
source NAT, allowing for persistent connecons when a firewall offering those services fails.
As shown in the figure below, each HA firewall interface has its own IP address and floang IP
address. The interface IP address remains local to the firewall, but the floang IP address moves
between the firewalls upon firewall failure. You configure the end hosts to use a floang IP
address as its default gateway, allowing you to load balance traffic to the two HA peers. You can
also use external load balancers to load balance traffic.
If a link or firewall fails or a path monitoring event causes a failover, the floang IP address and
virtual MAC address move over to the funconal firewall. (In the figure below, each firewall has
two floang IP addresses and virtual MAC addresses; they all move over if the firewall fails.) The
funconing firewall sends a gratuitous ARP to update the MAC tables of the connected switches
to inform them of the change in floang IP address and MAC address ownership to redirect traffic
to itself.
Aer the failed firewall recovers, by default the floang IP address and virtual MAC address
move back to firewall with the Device ID [0 or 1] to which the floang IP address is bound.
More specifically, aer the failed firewall recovers, it comes on line. The currently acve firewall
determines that the firewall is back online and checks whether the floang IP address it is
handling belongs navely to itself or the other firewall. If the floang IP address was originally
bound to the other Device ID, the firewall automacally gives it back. (For an alternave to this
default behavior, see Use Case: Configure Acve/Acve HA with Floang IP Address Bound to
Acve-Primary Firewall.)
High Availability
Each firewall in the HA pair creates a virtual MAC address for each of its interfaces that has a
floang IP address or ARP Load-Sharing IP address.
The format of the virtual MAC address (on firewalls other than PA-7000, PA-5200, and PA-3200
Series firewalls) is 00-1B-17-00-xx-yy, where 00-1B-17 is the vendor ID (of Palo Alto Networks
in this case), 00 is fixed, xx indicates the Device ID and Group ID as shown in the following figure,
and yy is the Interface ID:
7 6 543210 76543210
Device-ID 0 Group-ID Interface-ID
The format of the virtual MAC address on PA-7000, PA-5200, and PA-3200 Series firewalls is
B4-0C-25-xx-xx-xx, where B4-0C-25 is the vendor ID (of Palo Alto Networks in this case), and the
next 24 bits indicate the Device ID, Group ID and Interface ID as follows:
765 4 321076 5432 1076543210
111 Device-ID Group-ID 0000 Interface-ID
When a new acve firewall takes over, it sends gratuitous ARPs from each of its connected
interfaces to inform the connected Layer 2 switches of the new locaon of the virtual MAC
address. To configure floang IP addresses, see Use Case: Configure Acve/Acve HA with
Floang IP Addresses.
ARP Load-Sharing
In a Layer 3 interface deployment and acve/acve HA configuraon, ARP load-sharing allows the
firewalls to share an IP address and provide gateway services. Use ARP load-sharing only when no
Layer 3 device exists between the firewall and end hosts, that is, when end hosts use the firewall
as their default gateway.
High Availability
In such a scenario, all hosts are configured with a single gateway IP address. One of the firewalls
responds to ARP requests for the gateway IP address with its virtual MAC address. Each firewall
has a unique virtual MAC address generated for the shared IP address. The load-sharing algorithm
that controls which firewall will respond to the ARP request is configurable; it is determined by
compung the hash or modulo of the source IP address of the ARP request.
Aer the end host receives the ARP response from the gateway, it caches the MAC address and
all traffic from the host is routed via the firewall that responded with the virtual MAC address for
the lifeme of the ARP cache. The lifeme of the ARP cache depends on the end host operang
system.
If a link or firewall fails, the floang IP address and virtual MAC address move over to the
funconal firewall. The funconal firewall sends gratuitous ARPs to update the MAC table of the
connected switches to redirect traffic from the failed firewall to itself. See Use Case: Configure
Acve/Acve HA with ARP Load-Sharing.
You can configure interfaces on the WAN side of the HA firewalls with floang IP addresses, and
configure interfaces on the LAN side of the HA firewalls with a shared IP address for ARP load-
sharing. For example, the figure below illustrates floang IP addresses for the upstream WAN
edge routers and an ARP load-sharing address for the hosts on the LAN segment.
High Availability
Route-Based Redundancy
In a Layer 3 interface deployment and acve/acve HA configuraon, the firewalls are connected
to routers, not switches. The firewalls use dynamic roung protocols to determine the best path
(asymmetric route) and to load share between the HA pair. In such a scenario, no floang IP
addresses are necessary. If a link, monitored path, or firewall fails, or if Bidireconal Forwarding
Detecon (BFD) detects a link failure, the roung protocol (RIP, OSPF, or BGP) handles the
reroung of traffic to the funconing firewall. You configure each firewall interface with a unique
IP address. The IP addresses remain local to the firewall where they are configured; they do not
move between devices when a firewall fails. See Use Case: Configure Acve/Acve HA with
Route-Based Redundancy.
High Availability
HA Timers
High availability (HA) mers facilitate a firewall to detect a firewall failure and trigger a failover.
To reduce the complexity in configuring mers for an HA pair, you can select from three profiles:
Recommended, Aggressive and Advanced. These profiles auto-populate the opmum HA mer
values for the specific firewall plaorm to enable a speedier HA deployment.
Use the Recommended profile for typical failover mer sengs and the Aggressive profile for
faster failover mer sengs. The Advanced profile allows you to customize the mer values to
suit your network requirements.
The following table describes each mer included in the profiles and the current preset values
(Recommended/Aggressive) across the different hardware models; these values are for current
reference only and can change in a subsequent release.
Timers that affect members of an HA cluster are described in Configure HA Clustering.
Timers Descripon PA-7000 Series PA-800 Series Panorama

Virtual
PA-5200 Series PA-220
Appliance
PA-3200 Series VM-Series
Panorama M-
Series
Monitor Fail Interval during which 0/0 0/0 0/0

Hold Up Time the firewall will remain
(ms) acve following a path
monitor or link monitor
failure. This seng is
recommended to avoid
an HA failover due to
the occasional flapping
of neighboring devices.
High Availability

Virtual
Appliance
Panorama M-
Series
Preempon Time that a passive 1/1 1/1 1/1

Hold Time (min) or acve-secondary
firewall will wait before
taking over as the
acve or acve-primary
firewall.
Heartbeat Frequency at which 1000/1000 2000/1000 2000/1000

Interval (ms) the HA peers exchange
heartbeat messages in
the form of an ICMP
(ping).
Promoon Hold Time that the passive 2000/500 2000/500 2000/500

Time (ms) firewall (in acve/
passive mode) or the
acve-secondary
firewall (in acve/
acve mode) will wait
before taking over as
the acve or acve-
primary firewall aer
communicaons with
the HA peer have been
lost. This hold me will
begin only aer the
peer failure declaraon
has been made.
Addional Time interval in 500/500 500/500 7000/5000

Master Hold Up milliseconds that is
Time (ms) applied to the same
event as Monitor Fail
Hold Up Time (range
is 0 to 60,000; default
is 500). The addional
me interval is applied
only to the acve
firewall in acve/
passive mode and to
the acve-primary
firewall in acve/acve
mode. This mer is
High Availability

Virtual
Appliance
Panorama M-
Series
recommended to avoid
a failover when both
firewalls experience the
same link/path monitor
failure simultaneously.
Hello Interval Interval in milliseconds 8000/8000 8000/8000 8000/8000

(ms) between hello packets
that are sent to
verify that the HA
funconality on
the other firewall is
operaonal (range
is 8,000 to 60,000;
default is 8,000).
Flap Max A flap is counted when 3/3 3/3 Not Applicable

one of the following
occurs:
• A preempon-
enabled firewall
leaves the acve
state within 20
minutes aer
becoming acve.
• A link or path
fails to stay up for
10 minutes aer
becoming funconal.
In the case of a failed
preempon or non-
funconal loop, this
value indicates the
maximum number of
flaps that are permied
before the firewall is
suspended (range 0 to
16; default is 3).
High Availability
Session Owner
In an HA acve/acve configuraon, both firewalls are acve simultaneously, which means
packets can be distributed between them. Such distribuon requires the firewalls to fulfill two
funcons: session ownership and session setup. Typically, each firewall of the pair performs one
of these funcons, thereby avoiding race condions that can occur in asymmetrically routed
environments.
You configure the session owner of sessions to be either the firewall that receives the First Packet
of a new session from the end host or the firewall that is in acve-primary state (the Primary
device). If Primary device is configured, but the firewall that receives the first packet is not in
acve-primary state, the firewall forwards the packet to the peer firewall (the session owner) over
the HA3 link.
The session owner performs all Layer 7 processing, such as App-ID, Content-ID, and threat
scanning for the session. The session owner also generates all traffic logs for the session.
If the session owner fails, the peer firewall becomes the session owner. The exisng sessions fail
over to the funconing firewall and no Layer 7 processing is available for those sessions. When a
firewall recovers from a failure, by default, all sessions it owned before the failure revert back to
that original firewall; Layer 7 processing does not resume.
If you configure session ownership to be Primary device, the session setup defaults to Primary
device also.
Palo Alto Networks recommends seng the Session Owner to First Packet and the
Session Setup to IP Modulo unless otherwise indicated in a specific use case. Seng the
Session Owner to First Packet reduces traffic across the HA3 link and helps distribute the
dataplane load across peers.
Seng Session Owner and Session Setup to Primary Device causes the acve-primary
firewall to perform all traffic processing. You might want to configure this for one of these
reasons:
• You are troubleshoong and capturing logs and pcaps, so that packet processing is not
split between the firewalls.
• You want to force the acve/acve HA pair to funcon like an acve/passive HA pair.
See Use Case: Configure Acve/Acve HA with Floang IP Address Bound to
Acve-Primary Firewall.
Session Setup
The session setup firewall performs the Layer 2 through Layer 4 processing necessary to set up
a new session. The session setup firewall also performs NAT using the NAT pool of the session
owner. You determine the session setup firewall in an acve/acve configuraon by selecng one
of the following session setup load sharing opons.
High Availability
Session Setup Opon Descripon
IP Modulo The firewall distributes the session setup load based on parity of the
source IP address. This is a determinisc method of sharing the session
setup.
IP Hash The firewall uses a hash of the source and desnaon IP addresses to
distribute session setup responsibilies.
Primary Device The acve-primary firewall always sets up the session; only one
firewall performs all session setup responsibilies.
First Packet The firewall that receives the first packet of a session performs session
setup.
• If you want to load-share the session owner and session setup responsibilies,
set session owner to First Packet and session setup to IP modulo. These are the
recommended sengs.
• If you want to do troubleshoong or capture logs or pcaps, or if you want an acve/
acve HA pair to funcon like an acve/passive HA pair, set both the session owner
and session setup to Primary device so that the acve-primary device performs all
traffic processing. See Use Case: Configure Acve/Acve HA with Floang IP
Address Bound to Acve-Primary Firewall.
The firewall uses the HA3 link to send packets to its peer for session setup if necessary. The
following figure and text describe the path of a packet that firewall FW1 receives for a new
session. The red doed lines indicate FW1 forwarding the packet to FW2 and FW2 forwarding
the packet back to FW1 over the HA3 link.
The end host sends a packet to FW1.
High Availability
FW1 examines the contents of the packet to match it to an exisng session. If there is no
session match, FW1 determines that it has received the first packet for a new session and
therefore becomes the session owner (assuming Session Owner Selecon is set to First
Packet).
FW1 uses the configured session setup load-sharing opon to idenfy the session setup
firewall. In this example, FW2 is configured to perform session setup.
FW1 uses the HA3 link to send the first packet to FW2.
FW2 sets up the session and returns the packet to FW1 for Layer 7 processing, if any.
FW1 then forwards the packet out the egress interface to the desnaon.
The following figure and text describe the path of a packet that matches an exisng session:
The end host sends a packet to FW1.

FW1 examines the contents of the packet to match it to an exisng session. If the session
matches an exisng session, FW1 processes the packet and sends the packet out the egress
interface to the desnaon.
NAT in Acve/Acve HA Mode

In an acve/acve HA configuraon:
• You must bind each Dynamic IP (DIP) NAT rule and Dynamic IP and Port (DIPP) NAT rule to
either Device ID 0 or Device ID 1.
• You must bind each stac NAT rule to either Device ID 0, Device ID 1, both Device IDs, or the
firewall in acve-primary state.
Thus, when one of the firewalls creates a new session, the Device ID 0 or Device ID 1 binding
determines which NAT rules match the firewall. The device binding must include the session
owner firewall to produce a match.
The session setup firewall performs the NAT policy match, but the NAT rules are evaluated based
on the session owner. That is, the session is translated according to NAT rules that are bound to
the session owner firewall. While performing NAT policy matching, a firewall skips all NAT rules
that are not bound to the session owner firewall.
High Availability
For example, suppose the firewall with Device ID 1 is the session owner and session setup
firewall. When the firewall with Device ID 1 tries to match a session to a NAT rule, it skips all rules
bound to Device ID 0. The firewall performs the NAT translaon only if the session owner and the
Device ID in the NAT rule match.
You will typically create device-specific NAT rules when the peer firewalls use different IP
addresses for translaon.
If one of the peer firewalls fails, the acve firewall connues to process traffic for synchronized
sessions from the failed firewall, including NAT traffic. In a source NAT configuraon, when one
firewall fails:
• The floang IP address that is used as the Translated IP address of the NAT rule transfers to
the surviving firewall. Hence, the exisng sessions that fail over will sll use this IP address.
• All new sessions will use the device-specific NAT rules that the surviving firewall naturally
owns. That is, the surviving firewall translates new sessions using only the NAT rules that
match its Device ID; it ignores any NAT rules bound to the failed Device ID.
For examples of acve/acve HA with NAT, see:
• Use Case: Configure Acve/Acve HA with Source DIPP NAT Using Floang IP Addresses
• Use Case: Configure Separate Source NAT IP Address Pools for Acve/Acve HA Firewalls
• Use Case: Configure Acve/Acve HA for ARP Load-Sharing with Desnaon NAT
• Use Case: Configure Acve/Acve HA for ARP Load-Sharing with Desnaon NAT in Layer 3
ECMP in Acve/Acve HA Mode

When an acve/acve HA peer fails, its sessions transfer to the new acve-primary firewall,
which tries to use the same egress interface that the failed firewall was using. If the firewall finds
that interface among the ECMP paths, the transferred sessions will take the same egress interface
and path. This behavior occurs regardless of the ECMP algorithm in use; using the same interface
is desirable.
Only if no ECMP path matches the original egress interface will the acve-primary firewall select a
new ECMP path.
If you did not configure the same interfaces on the acve/acve peers, upon failover the acve-
primary firewall selects the next best path from the FIB table. Consequently, the exisng sessions
might not be distributed according to the ECMP algorithm.
High Availability
Set Up Acve/Passive HA
• Prerequisites for Acve/Passive HA
• Configuraon Guidelines for Acve/Passive HA
• Configure Acve/Passive HA
• Define HA Failover Condions
• Verify Failover
Prerequisites for Acve/Passive HA

To set up high availability on your Palo Alto Networks firewalls, you need a pair of firewalls that
meet the following requirements:
The same model—Both the firewalls in the pair must be of the same hardware model or virtual
machine model.
The same PAN-OS version—Both the firewalls should be running the same PAN-OS version
and must each be up-to-date on the applicaon, URL, and threat databases.
The same mul virtual system capability—Both firewalls must have Mul Virtual System
Capability either enabled or not enabled. When enabled, each firewall requires its own mulple
virtual systems licenses.
The same type of interfaces—Dedicated HA links, or a combinaon of the management port
and in-band ports that are set to interface type HA.
• Determine the IP address for the HA1 (control) connecon between the HA peers. The HA1
IP address for both peers must be on the same subnet if they are directly connected or are
connected to the same switch.
For firewalls without dedicated HA ports, you can use the management port for the control
connecon. Using the management port provides a direct communicaon link between the
management planes on both firewalls. However, because the management ports will not be
directly cabled between the peers, make sure that you have a route that connects these two
interfaces across your network.
• If you use Layer 3 as the transport method for the HA2 (data) connecon, determine the IP
address for the HA2 link. Use Layer 3 only if the HA2 connecon must communicate over a
routed network. The IP subnet for the HA2 links must not overlap with that of the HA1 links
or with any other subnet assigned to the data ports on the firewall.
The same set of licenses—Licenses are unique to each firewall and cannot be shared between
the firewalls. Therefore, you must license both firewalls idencally. If both firewalls do not have
an idencal set of licenses, they cannot synchronize configuraon informaon and maintain
parity for a seamless failover.
As a best pracce, if you have an exisng firewall and you want to add a new firewall
for HA purposes and the new firewall has an exisng configuraon Reset the Firewall
to Factory Default Sengs on the new firewall. This ensures that the new firewall has
a clean configuraon. Aer HA is configured, you will then sync the configuraon on
the primary firewall to the newly introduced firewall with the clean configuraon.
High Availability
Configuraon Guidelines for Acve/Passive HA

To set up an acve (PeerA) passive (PeerB) pair in HA, you must configure some opons idencally
on both firewalls and some independently (non-matching) on each firewall. These HA sengs are
not synchronized between the firewalls. For details on what is/is not synchronized, see Reference:
HA Synchronizaon.
The following checklist details the sengs that you must configure idencally on both firewalls:
You must enable HA on both firewalls.
You must configure the same Group ID value on both firewalls. The firewall uses the Group ID
value to create a virtual MAC address for all the configured interfaces. See Floang IP Address
and Virtual MAC Address for informaon about virtual MAC addresses. When a new acve
firewall takes over, it sends Gratuitous ARP messages from each of its connected interfaces to
inform the connected Layer 2 switches of the virtual MAC address’ new locaon.
If you are using in-band ports as HA links, you must set the interfaces for the HA1 and HA2
links to type HA.
Set the HA Mode to Acve Passive on both firewalls.
If required, enable preempon on both firewalls. The device priority value, however, must not
be idencal.
If required, configure encrypon on the HA1 link (for communicaon between the HA peers)
on both firewalls.
High Availability
Based on the combinaon of HA1 and HA1 Backup ports you are using, use the following
recommendaons to decide whether you should enable heartbeat backup:
HA funconality (HA1 and HA1 backup) is not supported on the management interface
if it's configured for DHCP addressing (IP Type set to DHCP Client). The excepons are
AWS and Azure, where the management interface is configured as DHCP Client and it
supports HA1 and HA1 Backup links.
• HA1: Dedicated HA1 port

HA1 Backup: Dedicated HA1 port
Recommendaon: Enable Heartbeat Backup
HA1 Backup: In-band port
HA1 Backup: Management port
Recommendaon: Do not enable Heartbeat Backup
• HA1: In-band port
• HA1: Management port
Recommendaon: Do not enable Heartbeat Backup
The following table lists the HA sengs that you must configure independently on each firewall.
See Reference: HA Synchronizaon for more informaon about other configuraon sengs are
not automacally synchronized between peers.
Independent PeerA PeerB

Configuraon
Sengs
Control Link IP address of the HA1 link configured IP address of the HA1 link
on this firewall (PeerA). configured on this firewall
(PeerB).
For firewalls without dedicated HA ports, use the management port IP

address for the control link.
Data Link By default, the HA2 link uses By default, the HA2 link uses
Ethernet/Layer 2. Ethernet/Layer 2.
The data link
informaon is
synchronized
High Availability
Independent PeerA PeerB

Configuraon
Sengs
between the If using a Layer 3 connecon, If using a Layer 3 connecon,
firewalls aer configure the IP address for the data configure the IP address for the
HA is enabled link on this firewall (PeerA). data link on this firewall (PeerB).
and the control
link is established
between the
firewalls.
Device Priority The firewall you plan to make acve If PeerB is passive, set the device
(required, if must have a lower numerical value priority value to a number larger
preempon is than its peer. So, if Peer A is to than the seng on PeerA. For
enabled) funcon as the acve firewall, keep example, set the value to 110.
the default value of 100 and increment
the value on PeerB.
If the firewalls have the same device
priority value, they use the MAC
address of their HA1 as the e-
breaker.
Link Monitoring Select the physical interfaces on the Pick a similar set of physical
—Monitor one firewall that you would like to monitor interfaces that you would like
or more physical and define the failure condion (all or to monitor on this firewall and
interfaces that any) to trigger a failover. define the failure condion (all or
handle vital traffic any) to trigger a failover.
on this firewall
and define the
failure condion.
Path Monitoring Define the failure condion (all or any), Pick a similar set of devices or
—Monitor one or ping interval and the ping count. This desnaon IP addresses that can
more desnaon is parcularly useful for monitoring be monitored for determining
IP addresses the availability of other interconnected the failover trigger for PeerB.
that the firewall networking devices. For example, Define the failure condion (all
can use ICMP monitor the availability of a router that or any), ping interval and the
pings to ascertain connects to a server, connecvity to ping count.
responsiveness. the server itself, or some other vital
device that is in the flow of traffic.
Make sure that the node/device that
you are monitoring is not likely to
be unresponsive, especially when it
comes under load, as this could cause
a a path monitoring failure and trigger
a failover.
High Availability
Configure Acve/Passive HA
The following procedure shows how to configure a pair of firewalls in an acve/passive
deployment as depicted in the following example topology.
To configure an acve/passive HA pair, first complete the following workflow on the first firewall
and then repeat the steps on the second firewall.
STEP 1 | Connect the HA ports to set up a physical connecon between the firewalls.
• For firewalls with dedicated HA ports, use an Ethernet cable to connect the dedicated HA1
ports and the HA2 ports on peers. Use a crossover cable if the peers are directly connected
to each other.
• For firewalls without dedicated HA ports, select two data interfaces for the HA2 link and
the backup HA1 link. Then, use an Ethernet cable to connect these in-band HA interfaces
across both firewalls.
Use the management port for the HA1 link and ensure that the management ports can connect
to each other across your network.
STEP 2 | Enable ping on the management port.

Enabling ping allows the management port to exchange heartbeat backup informaon.
1. Select Device > Setup > Management and edit the Management Interface Sengs.
2. Select Ping as a service that is permied on the interface.
STEP 3 | If the firewall does not have dedicated HA ports, set up the data ports to funcon as HA
ports.
For firewalls with dedicated HA ports connue to the next step.
1. Select Network > Interfaces.
2. Confirm that the link is up on the ports that you want to use.
3. Select the interface and set Interface Type to HA.
4. Set the Link Speed and Link Duplex sengs, as appropriate.
High Availability
STEP 4 | Set the HA mode and group ID.

1. Select Device > High Availability > General and edit the Setup secon.
2. Set a Group ID and oponally a Descripon for the pair. The Group ID uniquely
idenfies each HA pair on your network. If you have mulple HA pairs that share the
same broadcast domain you must set a unique Group ID for each pair.
3. Set the mode to Acve Passive.
STEP 5 | Set up the control link connecon.

This example shows an in-band port that is set to interface type HA.
For firewalls that use the management port as the control link, the IP address informaon is
automacally pre-populated.
1. In Device > High Availability > General, edit the Control Link (HA1) secon.
2. Select the Port that you have cabled for use as the HA1 link.
3. Set the IPv4/IPv6 Address and Netmask.
If the HA1 interfaces are on separate subnets, enter the IP address of the Gateway. Do
not add a gateway address if the firewalls are directly connected or are on the same
VLAN.
STEP 6 | (Oponal) Enable encrypon for the control link connecon.

This is typically used to secure the link if the two firewalls are not directly connected, that is if
the ports are connected to a switch or a router.
1. Export the HA key from one firewall and import it into the peer firewall.
1. Select Device > Cerficate Management > Cerficates.
2. Select Export HA key. Save the HA key to a network locaon that the peer can
access.
3. On the peer firewall, select Device > Cerficate Management > Cerficates, and
select Import HA key to browse to the locaon that you saved the key and import it
in to the peer.
4. Repeat this process on the second firewall to exchange HA keys on both devices.
2. Select Device > High Availability > General, edit the Control Link (HA1) secon.
3. Select Encrypon Enabled.
If you enable encrypon, aer you finish configuring the HA firewalls, you can
Refresh HA1 SSH Keys and Configure Key Opons.
STEP 7 | Set up the backup control link connecon.

1. In Device > High Availability > General, edit the Control Link (HA1 Backup) secon.
2. Select the HA1 backup interface and set the IPv4/IPv6 Address and Netmask.
PA-3200 Series firewalls don’t support an IPv6 address for the HA1 backup
control link; use an IPv4 address.
High Availability
STEP 8 | Set up the data link connecon (HA2) and the backup HA2 connecon between the firewalls.
1. In Device > High Availability > General, edit the Data Link (HA2) secon.
2. Select the Port to use for the data link connecon.
3. Select the Transport method. The default is ethernet, and will work when the HA pair is
connected directly or through a switch. If you need to route the data link traffic through
the network, select IP or UDP as the transport mode.
4. If you use IP or UDP as the transport method, enter the IPv4/IPv6 Address and
Netmask.
5. Verify that Enable Session Synchronizaon is selected.
6. Select HA2 Keep-alive to enable monitoring on the HA2 data link between the HA
peers. If a failure occurs based on the threshold that is set (default is 10000 ms), the
defined acon will occur. For acve/passive configuraon, a crical system log message
is generated when an HA2 keep-alive failure occurs.
You can configure the HA2 keep-alive opon on both firewalls, or just one
firewall in the HA pair. If the opon is only enabled on one firewall, only that
firewall will send the keep-alive messages. The other firewall will be nofied if a
failure occurs.
7. Edit the Data Link (HA2 Backup) secon, select the interface, and add the IPv4/IPv6
Address and Netmask.
STEP 9 | Enable heartbeat backup if your control link uses a dedicated HA port or an in-band port.
You do not need to enable heartbeat backup if you are using the management port for the
control link.
1. In Device > High Availability > General, edit the Elecon Sengs.
2. Select Heartbeat Backup.
To allow the heartbeats to be transmied between the firewalls, you must verify that the
management port across both peers can route to each other.
Enabling heartbeat backup also allows you to prevent a split-brain situaon.

Split brain occurs when the HA1 link goes down causing the firewall to miss
heartbeats, although the firewall is sll funconing. In such a situaon, each
peer believes that the other is down and aempts to start services that are
running, thereby causing a split brain. When the heartbeat backup link is
enabled, split brain is prevented because redundant heartbeats and hello
messages are transmied over the management port.
High Availability
STEP 10 | Set the device priority and enable preempon.

This seng is only required if you wish to make sure that a specific firewall is the preferred
acve firewall. For informaon, see Device Priority and Preempon.
2. Set the numerical value in Device Priority. Make sure to set a lower numerical value on
the firewall that you want to assign a higher priority to.
If both firewalls have the same device priority value, the firewall with the lowest
MAC address on the HA1 control link will become the acve firewall.
3. Select Preempve.
You must enable preempve on both the acve firewall and the passive firewall.
STEP 11 | (Oponal) Modify the HA Timers.

By default, the HA mer profile is set to the Recommended profile and is suited for most HA
deployments.
2. Select the Aggressive profile for triggering failover faster; select Advanced to define
custom values for triggering failover in your set up.
To view the preset value for an individual mer included in a profile, select
Advanced and click Load Recommended or Load Aggressive. The preset values
for your hardware model will be displayed on screen.
STEP 12 | (Oponal) Modify the link status of the HA ports on the passive firewall.
The passive link state is shutdown, by default. Aer you enable HA, the link state for
the HA ports on the acve firewall will be green and those on the passive firewall will
be down and display as red.
Seng the link state to Auto allows for reducing the amount of me it takes for the passive
firewall to take over when a failover occurs and it allows you to monitor the link state.
To enable the link status on the passive firewall to stay up and reflect the cabling status on the
physical interface:
1. In Device > High Availability > General, edit the Acve Passive Sengs.
2. Set the Passive Link State to Auto.
The auto opon decreases the amount of me it takes for the passive firewall to take
over when a failover occurs.
Although the interface displays green (as cabled and up) it connues to discard
all traffic unl a failover is triggered.
When you modify the passive link state, make sure that the adjacent devices do not
forward traffic to the passive firewall based only on the link status of the firewall.
High Availability
STEP 13 | Enable HA.

2. Select Enable HA.
3. Select Enable Config Sync. This seng enables the synchronizaon of the configuraon
sengs between the acve and the passive firewall.
4. Enter the IP address assigned to the control link of the peer in Peer HA1 IP Address.
For firewalls without dedicated HA ports, if the peer uses the management port for the
HA1 link, enter the management port IP address of the peer.
5. Enter the Backup HA1 IP Address.
STEP 14 | (Oponal) Enable LACP and LLDP Pre-Negoaon for Acve/Passive HA for faster failover if
your network uses LACP or LLDP.
Enable LACP and LLDP before configuring HA pre-negoaon for the protocol if you
want pre-negoaon to funcon in acve mode.
1. Ensure that in Step 12 you set the link state to Auto.

2. Select Network > Interfaces > Ethernet.
3. To enable LACP acve pre-negoaon:
1. Select an AE interface in a Layer 2 or Layer 3 deployment.
2. Select the LACP tab.
3. Select Enable in HA Passive State.
4. Click OK.
You cannot also select Same System MAC Address for Acve-Passive HA
because pre-negoaon requires unique interface MAC addresses on the
acve and passive firewalls.
4. To enable LACP passive pre-negoaon:
1. Select an Ethernet interface in a virtual wire deployment.
2. Select the Advanced tab.
3. Select the LACP tab.
5. Click OK.
5. To enable LLDP acve pre-negoaon:
1. Select an Ethernet interface in a Layer 2, Layer 3, or virtual wire deployment.
2. Select the Advanced tab.
3. Select the LLDP tab.
5. Click OK.
If you want to allow LLDP passive pre-negoaon for a virtual wire

deployment, perform Step 14.e but do not enable LLDP itself.
High Availability
STEP 15 | Save your configuraon changes.

Click Commit.
STEP 16 | Aer you finish configuring both firewalls, verify that the firewalls are paired in acve/
passive HA.
1. Access the Dashboard on both firewalls, and view the High Availability widget.
2. On the acve firewall, click the Sync to peer link.
3. Confirm that the firewalls are paired and synced, as shown as follows:
• On the passive firewall: the state of the local firewall should display passive and the
Running Config should show as synchronized.
• On the acve firewall: The state of the local firewall should display acve and the
Running Config should show as synchronized.
Define HA Failover Condions

Perform the following task to use link monitoring or path monitoring to define Failover condions
and thus establish what will cause a firewall in an HA pair to fail over, an event where the task
of securing traffic passes from the previously acve firewall to its HA peer. The HA Overview
describes condions that cause a failover.
You can monitor mulple IP path groups per virtual router, VLAN, or virtual wire. You can enable
each path group with one or more IP addresses and give each its own peer failure condions.
Addionally, you can set these failure condions at both the path-group level and the broader
virtual router or VLAN or virtual wire group level using “any” or “all” fail checks to determine the
status of the acve firewall.
When you upgrade to PAN-OS 10.0, the firewall automacally transfers your currently monitored
desnaon IP addresses to a newly created desnaon group and gives that group a default path-
monitoring name. The new desnaon group retains your previous failover condion at the path-
group level.
Ensure that you delete all VLAN path monitoring configuraons in acve/acve HA
before you upgrade to PAN-OS 10.1 because VLAN path monitoring is not compable
with acve/acve HA pairing in PAN-OS 10.0; retaining an earlier acve/acve HA
configuraon results in an autocommit failure.
Before you enable path monitoring, you must set up your virtual routers, VLAN, or virtual wires
or a combinaon of these logical networking components. Path monitoring in virtual routers and
virtual wires is compable with both acve/acve and acve/passive HA deployments; however,
path monitoring in VLANs is supported only on acve/passive pairs.
Before you enable path monitoring, you must also:
• Check reachability for desnaon IP groups in your virtual routers.
• Ensure that the VLANs (for which you intend to enable path monitoring) include configured
interfaces.
• Obtain the source IP address that you will use to receive pings from the appropriate desnaon
IP address.
High Availability
If you are using SNMPv3 to monitor the firewalls, note that the SNMPv3 Engine ID
is unique to each firewall; the EngineID is not synchronized between the HA pair
and, therefore, allows you to independently monitor each firewall in the HA pair. For
informaon on seng up SNMP, see Forward Traps to an SNMP Manager. Because the
EngineID is generated using the firewall serial number, on the VM-Series firewall you must
apply a valid license in order to obtain a unique EngineID for each firewall.
STEP 1 | To configure HA link monitoring, specify a group of physical interfaces for the firewall to
monitor (link up or link down).
1. Select Device > High Availability > Link and Path Monitoring.
2. In the Link Monitoring secon, Add a link group by Name.
3. Select Enabled to enable the link group.
4. Select the Failure Condion for the interfaces in the link group: Any (default) or All.
5. Add the Interface(s) to monitor.
6. Click OK.
STEP 2 | (Oponal) Modify the failure condion for the set of Link Groups configured on the firewall.
By default, the firewall triggers a failover when any monitored Link Group fails.
1. Edit the Link Monitoring secon.
2. Set the Failure Condion to Any (default) or All.
3. Click OK.
High Availability
STEP 3 | To configure HA path monitoring for a virtual wire, VLAN, or virtual router, specify the
desnaon IP addresses that the firewall will ping to verify network connecvity.
1. In the Path Monitoring secon, select Add Virtual Wire Path, Add VLAN Path, or Add
Virtual Router Path.
2. Enter a Name for the virtual wire, VLAN, or virtual router path group.
3. (Virtual Wire Path or VLAN Path only) Enter the Source IP address to use to ping the
desnaon IP address through the virtual wire or VLAN.
4. Select Enabled to enable the path group.
5. Select the Failure Condion that results in a failure for this path group: Any (default) to
issue a failure when one or more Desnaon IP groups in this path group fail or All to
issue a failure when all Desnaon IP groups in this path group fail.
6. Enter the Ping Interval in milliseconds; the interval between ICMP messages sent to the
Desnaon IP address (range is 200 to 60,000; default is 200).
7. Enter the Ping Count of pings that must fail before declaring a failure (range is 3 to 10;
default is 10).
8. Add and enter a Desnaon IP Group name.
9. Add one or more Desnaon IP addresses to ping.
10. Select Enabled to enable path monitoring for the Desnaon IP group.
11. Select the Failure Condion that results in a failure for this Desnaon IP group: Any
(default) to issue a failure when one or more listed IP addresses is unreachable or All to
issue a failure when all listed IP addresses are unreachable.
12. Click OK twice.
13. (Panorama only) Select the appropriate Panorama template to push the path monitoring
configuraon to your appliance.
You can push HA path monitoring for a virtual wire, VLAN, or virtual router
only to firewalls running PAN-OS 10.1 or a later release. If you try to push the
configuraon to firewalls running a release earlier than PAN-OS 10.1 (such as
9.1.x or 9.0.x), the commit may fail or the commit may remove desnaon IP
addresses from the path group.
STEP 4 | (Oponal) Modify the failure condion for the set of Path Groups configured on the firewall.
By default, the firewall triggers a failover when any monitored Path Group fails.
1. Edit the Path Monitoring secon.
2. Select Enabled to enable path monitoring on the appliance.
3. Set the Failure Condion to Any (default) to issue a failure for this firewall when one
or more monitored virtual routers, VLANs, or virtual wires is down. Select All to issue
a failure for this firewall when all monitored virtual routers, VLANs, or virtual wires are
down.
4. Click OK.
STEP 5 | Commit.
High Availability
Verify Failover
To test that your HA configuraon works properly, trigger a manual failover and verify that the
firewalls transion states successfully.
STEP 1 | Suspend the acve firewall.
Select Device > High Availability > Operaonal Commands and click the Suspend local device
link.
STEP 2 | Verify that the passive firewall has taken over as acve.
On the Dashboard, verify that the state of the passive firewall changes to acve in the High
Availability widget.
STEP 3 | Restore the suspended firewall to a funconal state. Wait for a couple of minutes, and then
verify that preempon has occurred, if Preempve is enabled.
1. On the firewall you previously suspended, select Device > High Availability >
Operaonal Commands and click the Make local device funconal link.
2. In the High Availability widget on the Dashboard, confirm that the firewall has taken over
as the acve firewall and that the peer is now in a passive state.
High Availability
Set Up Acve/Acve HA
• Prerequisites for Acve/Acve HA
• Configure Acve/Acve HA
• Determine Your Acve/Acve Use Case
Prerequisites for Acve/Acve HA

To set up acve/acve HA on your firewalls, you need a pair of firewalls that meet the following
requirements:
The same model—The firewalls in the pair must be of the same hardware model.
The same PAN-OS version—The firewalls must be running the same PAN-OS version and must
each be up-to-date on the applicaon, URL, and threat databases.
The same mul virtual system capability—Both firewalls must have Mul Virtual System
Capability either enabled or not enabled. When enabled, each firewall requires its own mulple
virtual systems licenses.
The same type of interfaces—Dedicated HA links, or a combinaon of the management port
and in-band ports that are set to interface type HA.
• The HA interfaces must be configured with stac IP addresses only, not IP addresses
obtained from DHCP (except AWS can use DHCP addresses). Determine the IP address for
the HA1 (control) connecon between the HA peers. The HA1 IP address for the peers must
be on the same subnet if they are directly connected or are connected to the same switch.
For firewalls without dedicated HA ports, you can use the management port for the control
connecon. Using the management port provides a direct communicaon link between the
management planes on both firewalls. However, because the management ports will not be
directly cabled between the peers, make sure that you have a route that connects these two
interfaces across your network.
• If you use Layer 3 as the transport method for the HA2 (data) connecon, determine the IP
address for the HA2 link. Use Layer 3 only if the HA2 connecon must communicate over a
routed network. The IP subnet for the HA2 links must not overlap with that of the HA1 links
or with any other subnet assigned to the data ports on the firewall.
• Each firewall needs a dedicated interface for the HA3 link. The PA-7000 Series firewalls use
the HSCI port for HA3. The PA-5200 Series firewalls can use the HSCI port for HA3 or you
can configure aggregate interfaces on the dataplane ports for HA3 for redundancy. On the
remaining plaorms, you can configure aggregate interfaces on dataplane ports as the HA3
link for redundancy.
The same set of licenses—Licenses are unique to each firewall and cannot be shared between
the firewalls. Therefore, you must license both firewalls idencally. If both firewalls do not have
High Availability
an idencal set of licenses, they cannot synchronize configuraon informaon and maintain
parity for a seamless failover.
If you have an exisng firewall and you want to add a new firewall for HA purposes
and the new firewall has an exisng configuraon, it is recommended that you Reset
the Firewall to Factory Default Sengs on the new firewall. This will ensure that the
new firewall has a clean configuraon. Aer HA is configured, you will then sync the
configuraon on the primary firewall to the newly introduced firewall with the clean
config. You will also have to configure local IP addresses.
Configure Acve/Acve HA
The following procedure describes the basic workflow for configuring your firewalls in an acve/
acve configuraon. However, before you begin, Determine Your Acve/Acve Use Case for
configuraon examples more tailored to your specific network environment.
If you have a switch located between your HA firewalls, the switch ports that connect the
HA3 link must support jumbo frames to handle the overhead associated with the MAC-in-
MAC encapsulaon on the HA3 link.
To configure acve/acve, first complete the following steps on one peer and then complete them
on the second peer, ensuring that you set the Device ID to different values (0 or 1) on each peer.
STEP 1 | Connect the HA ports to set up a physical connecon between the firewalls.
For each use case, the firewalls could be any hardware model; choose the HA3 step
that corresponds with your model.
• For firewalls with dedicated HA ports, use an Ethernet cable to connect the dedicated HA1
ports and the HA2 ports on peers. Use a crossover cable if the peers are directly connected
to each other.
• For firewalls without dedicated HA ports, select two data interfaces for the HA2 link and
the backup HA1 link. Then, use an Ethernet cable to connect these in-band HA interfaces
across both firewalls. Use the management port for the HA1 link and ensure that the
management ports can connect to each other across your network.
• For HA3:
• On PA-7000 Series firewalls, connect the High Speed Chassis Interconnect (HSCI-A) on
the first chassis to the HSCI-A on the second chassis, and the HSCI-B on the first chassis
to the HSCI-B on the second chassis.
• On PA-5200 Series firewalls (which have one HSCI port), connect the HSCI port on the
first chassis to the HSCI port on the second chassis. You can also use data ports for HA3
on PA-5200 Series firewalls.
• On PA-3200 Series firewalls (which have one HSCI port), connect the HSCI port on the
first chassis to the HSCI port on the second chassis.
• On any other hardware model, use dataplane interfaces for HA3.
High Availability
STEP 2 | Enable ping on the management port.

Enabling ping allows the management port to exchange heartbeat backup informaon.
1. In Device > Setup > Management, edit Management Interface Sengs.
2. Select Ping as a service that is permied on the interface.
STEP 3 | If the firewall does not have dedicated HA ports, set up the data ports to funcon as HA
ports.
For firewalls with dedicated HA ports connue to the next step.
1. Select Network > Interfaces.
2. Confirm that the link is up on the ports that you want to use.
3. Select the interface and set Interface Type to HA.
4. Set the Link Speed and Link Duplex sengs, as appropriate.
STEP 4 | Enable acve/acve HA and set the group ID.

1. In Device > High Availability > General, edit Setup.
3. Enter a Group ID, which must be the same for both firewalls. The firewall uses the Group
ID to calculate the virtual MAC address (range is 1-63).
4. (Oponal) Enter a Descripon.
5. For Mode, select Acve Acve.
STEP 5 | Set the Device ID, enable synchronizaon, and idenfy the control link on the peer firewall
2. Select Device ID as follows:
• When configuring the first peer, set the Device ID to 0.
• When configuring the second peer, set the Device ID to 1.
3. Select Enable Config Sync. This seng is required to synchronize the two firewall
configuraons (enabled by default).
4. Enter the Peer HA1 IP Address, which is the IP address of the HA1 control link on the
peer firewall.
5. (Oponal) Enter a Backup Peer HA1 IP Address, which is the IP address of the backup
control link on the peer firewall.
6. Click OK.
High Availability
STEP 6 | Determine whether or not the firewall with the lower Device ID preempts the acve-primary
firewall upon recovery from a failure.
1. In Device > High Availability > General, edit Elecon Sengs.
2. Select Preempve to cause the firewall with the lower Device ID to automacally
resume acve-primary operaon aer either firewall recovers from a failure. Both
firewalls must have Preempve selected for preempon to occur.
Leave Preempve unselected if you want the acve-primary role to remain with the
current firewall unl you manually make the recovered firewall the acve-primary
firewall.
STEP 7 | Enable heartbeat backup if your control link uses a dedicated HA port or an in-band port.
You need not enable heartbeat backup if you are using the management port for the control
link.
2. Select Heartbeat Backup.
To allow the heartbeats to be transmied between the firewalls, you must verify that the
management port across both peers can route to each other.
Enabling heartbeat backup allows you to prevent a split-brain situaon.

Split brain occurs when the HA1 link goes down, causing the firewall to miss
heartbeats, although the firewall is sll funconing. In such a situaon, each
peer believes the other is down and aempts to start services that are running,
thereby causing a split brain. Enabling heartbeat backup prevents split brain
because redundant heartbeats and hello messages are transmied over the
management port.
STEP 8 | (Oponal) Modify the HA Timers.

By default, the HA mer profile is set to the Recommended profile and is suited for most HA
deployments.
2. Select Aggressive to trigger faster failover. Select Advanced to define custom values for
triggering failover in your setup.
To view the preset value for an individual mer included in a profile, select
Advanced and click Load Recommended or Load Aggressive. The preset values
for your hardware model will be displayed on screen.
High Availability
STEP 9 | Set up the control link connecon.

This example uses an in-band port that is set to interface type HA.
For firewalls that use the management port as the control link, the IP address informaon is
automacally pre-populated.
1. In Device > High Availability > General, edit Control Link (HA1).
2. Select the Port that you have cabled for use as the HA1 link.
3. Set the IPv4/IPv6 Address and Netmask.
If the HA1 interfaces are on separate subnets, enter the IP address of the Gateway. Do
not add a gateway address if the firewalls are directly connected.
STEP 10 | (Oponal) Enable encrypon for the control link connecon.

This is typically used to secure the link if the two firewalls are not directly connected, that is if
the ports are connected to a switch or a router.
1. Export the HA key from one firewall and import it into the peer firewall.
2. Select Export HA key. Save the HA key to a network locaon that the peer can
access.
3. On the peer firewall, select Device > Cerficate Management > Cerficates, and
select Import HA key to browse to the locaon that you saved the key and import it
in to the peer.
2. In Device > High Availability > General, edit the Control Link (HA1).
3. Select Encrypon Enabled.
If you enable encrypon, aer you finish configuring the HA firewalls, you can
Refresh HA1 SSH Keys and Configure Key Opons.
STEP 11 | Set up the backup control link connecon.

1. In Device > High Availability > General, edit Control Link (HA1 Backup).
2. Select the HA1 backup interface and set the IPv4/IPv6 Address and Netmask.
PA-3200 Series firewalls don’t support an IPv6 address for the HA1 backup
control link; use an IPv4 address.
High Availability
STEP 12 | Set up the data link connecon (HA2) and the backup HA2 connecon between the firewalls.
1. In Device > High Availability > General, edit Data Link (HA2).
2. Select the Port to use for the data link connecon.
3. Select the Transport method. The default is ethernet, and will work when the HA pair is
connected directly or through a switch. If you need to route the data link traffic through
the network, select IP or UDP as the transport mode.
4. If you use IP or UDP as the transport method, enter the IPv4/IPv6 Address and
Netmask.
5. Verify that Enable Session Synchronizaon is selected.
6. Select HA2 Keep-alive to enable monitoring on the HA2 data link between the HA
peers. If a failure occurs based on the threshold that is set (default is 10000 ms), the
defined acon will occur. When an HA2 Keep-alive failure occurs, the system either
generates a crical system log message or causes a split dataplane depending on your
configuraon.
You can configure the HA2 Keep-alive opon on both firewalls, or just one
firewall in the HA pair. If the opon is only enabled on one firewall, only that
firewall sends the Keep-alive messages. The other firewall is nofied if a failure
occurs.
A split dataplane causes the dataplanes of both peers to operate independently

while leaving the high-available state as Acve-Primary and Acve-Secondary. If
only one firewall is configured to split dataplane, then split dataplane applies to
the other device as well.
7. Edit the Data Link (HA2 Backup) secon, select the interface, and add the IPv4/IPv6
Address and Netmask.
8. Click OK.
STEP 13 | Configure the HA3 link for packet forwarding.

1. In Device > High Availability > Acve/Acve Config, edit Packet Forwarding.
2. For HA3 Interface, select the interface you want to use to forward packets between
acve/acve HA peers. It must be a dedicated interface capable of Layer 2 transport and
set to Interface Type HA.
3. Select VR Sync to force synchronizaon of all virtual routers configured on the HA peers.
Select when the virtual router is not configured for dynamic roung protocols. Both
peers must be connected to the same next-hop router through a switched network and
must use stac roung only.
4. Select QoS Sync to synchronize the QoS profile selecon on all physical interfaces.
Select when both peers have similar link speeds and require the same QoS profiles on
all physical interfaces. This seng affects the synchronizaon of QoS sengs on the
Network tab. QoS policy is synchronized regardless of this seng.
STEP 14 | (Oponal) Modify the Tentave Hold me.

2. For Tentave Hold Time (sec), enter the number of seconds that a firewall stays in
Tentave state aer it recovers post-failure (range is 10-600, default is 60).
High Availability
STEP 15 | Configure Session Owner and Session Setup.

2. For Session Owner Selecon, select one of the following:
• First Packet—The firewall that receives the first packet of a new session is the session
owner (recommended seng). This seng minimizes traffic across HA3 and load
shares traffic across peers.
• Primary Device—The firewall that is in acve-primary state is the session owner.
3. For Session Setup, select one of the following:
• IP Modulo—The firewall performs an XOR operaon on the source and desnaon
IP addresses from the packet and based on the result, the firewall chooses which HA
peer will set up the session.
• Primary Device—The acve-primary firewall sets up all sessions.
• First Packet—The firewall that receives the first packet of a new session performs
session setup (recommended seng).
Start with First Packet for Session Owner and Session Setup, and then based
on load distribuon, you can change to one of the other opons.
• IP Hash—The firewall uses a hash of either the source IP address or a combinaon of
the source and desnaon IP addresses to distribute session setup responsibilies.
4. Click OK.
STEP 16 | Configure an HA virtual address.

You need a virtual address to use a Floang IP Address and Virtual MAC Address or ARP Load-
Sharing.
1. In Device > High Availability > Acve/Acve Config, Add a Virtual Address.
2. Enter or select an Interface.
3. Select the IPv4 or IPv6 tab and click Add.
4. Enter an IPv4 Address or IPv6 Address.
5. For Type:
• Select Floang to configure the virtual IP address to be a floang IP address.
• Select ARP Load Sharing to configure the virtual IP address to be a shared IP address
and skip to Configure ARP Load-Sharing.
STEP 17 | Configure the floang IP address.

1. Do not select Floang IP bound to the Acve-Primary device unless you want the
acve/acve HA pair to behave like an acve/passive HA pair.
2. For Device 0 Priority and Device 1 Priority, enter a priority for the firewall configured
with Device ID 0 and Device ID 1, respecvely. The relave priories determine which
High Availability
peer owns the floang IP address you just configured (range is 0-255). The firewall with
the lowest priority value (highest priority) owns the floang IP address.
3. Select Failover address if link state is down to cause the firewall to use the failover
address when the link state on the interface is down.
4. Click OK.
STEP 18 | Configure ARP Load-Sharing.

The device selecon algorithm determines which HA firewall responds to the ARP requests to
provide load sharing.
1. For Device Selecon Algorithm, select one of the following:
• IP Modulo—The firewall that will respond to ARP requests is based on the parity of
the ARP requester's IP address.
• IP Hash—The firewall that will respond to ARP requests is based on a hash of the ARP
requester's IP address.
2. Click OK.
STEP 19 | Define HA Failover Condions.
STEP 20 | Commit the configuraon.
Determine Your Acve/Acve Use Case

Determine which type of use case you have and then select the corresponding procedure to
configure acve/acve HA.
If you are using Route-Based Redundancy, Floang IP Address and Virtual MAC Address, or ARP
Load-Sharing, select the corresponding procedure:
• Use Case: Configure Acve/Acve HA with Route-Based Redundancy
• Use Case: Configure Acve/Acve HA with Floang IP Addresses
• Use Case: Configure Acve/Acve HA with ARP Load-Sharing
If you want a Layer 3 acve/acve HA deployment that behaves like an acve/passive
deployment, select the following procedure:
• Use Case: Configure Acve/Acve HA with Floang IP Address Bound to Acve-Primary
Firewall
If you are configuring NAT in Acve/Acve HA Mode, see the following procedures:
• Use Case: Configure Acve/Acve HA with Source DIPP NAT Using Floang IP Addresses
• Use Case: Configure Separate Source NAT IP Address Pools for Acve/Acve HA Firewalls
• Use Case: Configure Acve/Acve HA for ARP Load-Sharing with Desnaon NAT
• Use Case: Configure Acve/Acve HA for ARP Load-Sharing with Desnaon NAT in Layer 3
High Availability
Use Case: Configure Acve/Acve HA with Route-Based Redundancy

The following Layer 3 topology illustrates two PA-7050 firewalls in an acve/acve HA
environment that use Route-Based Redundancy. The firewalls belong to an OSPF area. When a
link or firewall fails, OSPF handles the redundancy by redirecng traffic to the funconing firewall.
STEP 1 | Configure Acve/Acve HA.

Perform Step 1 through Step 15.
STEP 2 | Configure OSPF.

See OSPF.
STEP 3 | Define HA failover condions.

Define HA Failover Condions.
STEP 5 | Configure the peer firewall in the same way, except in Step 5, if you selected Device ID 0 for
the first firewall, select Device ID 1 for the peer firewall.
Use Case: Configure Acve/Acve HA with Floang IP Addresses

In this Layer 3 interface example, the HA firewalls connect to switches and use floang IP
addresses to handle link or firewall failures. The end hosts are each configured with a gateway,
which is the floang IP address of one of the HA firewalls. See Floang IP Address and Virtual
MAC Address.
High Availability


You need a virtual address to use a Floang IP Address and Virtual MAC Address.
1. In Device > High Availability > Acve/Acve Config, Add a Virtual Address.
5. For Type, select Floang to configure the virtual IP address to be a floang IP address.

1. Do not select Floang IP bound to the Acve-Primary device.
2. For Device 0 Priority and Device 1 Priority, enter a priority for the firewall configured
with Device ID 0 and Device ID 1, respecvely. The relave priories determine which
peer owns the floang IP address you just configured (range is 0 to 255). The firewall
with the lowest priority value (highest priority) owns the floang IP address.
4. Click OK.
STEP 4 | Enable jumbo frames on firewalls other than PA-7000 Series firewalls.
Perform Step 19 of Configure Acve/Acve HA.
STEP 5 | Define HA Failover Condions
High Availability
STEP 7 | Configure the peer firewall in the same way, except selecng a different Device ID.
For example, if you selected Device ID 0 for the first firewall, select Device ID 1 for the peer
firewall.
Use Case: Configure Acve/Acve HA with ARP Load-Sharing

In this example, hosts in a Layer 3 deployment need gateway services from the HA firewalls. The
firewalls are configured with a single shared IP address, which allows ARP Load-Sharing. The end
hosts are configured with the same gateway, which is the shared IP address of the HA firewalls.
STEP 1 | Perform Step 1 through Step 15 of Configure Acve/Acve HA.

The virtual address is the shared IP address that allows ARP Load-Sharing.
1. Select Device > High Availability > Acve/Acve Config > Virtual Address and click
Add.
5. For Type, select ARP Load Sharing, which allows both peers to use the virtual IP address
for ARP Load-Sharing.
High Availability

1. For Device Selecon Algorithm, select one of the following:
requester's IP address.
2. Click OK.
STEP 5 | Define HA Failover Condions
firewall.
Use Case: Configure Acve/Acve HA with Floang IP Address Bound to Acve-

Primary Firewall
In mission-crical data centers, you may want both Layer 3 HA firewalls to parcipate in path
monitoring so that they can detect path failures upstream from both firewalls. Addionally, you
prefer to control if and when the floang IP address returns to the recovered firewall aer it
comes back up, rather than the floang IP address returning to the device ID to which it is bound.
(That default behavior is described in Floang IP Address and Virtual MAC Address.)
In this use case, you control when the floang IP address and therefore the acve-primary role
move back to a recovered HA peer. The acve/acve HA firewalls share a single floang IP
address that you bind to whichever firewall is in the acve-primary state. With only one floang IP
address, network traffic flows predominantly to a single firewall, so this acve/acve deployment
funcons like an acve/passive deployment.
In this use case, Cisco Nexus 7010 switches with virtual PortChannels (vPCs) operang in Layer 3
connect to the firewalls. You must configure the Layer 3 switches (router peers) north and south
of the firewalls with a route preference to the floang IP address. That is, you must design your
network so the route tables of the router peers have the best path to the floang IP address. This
example uses stac routes with the proper metrics so that the route to the floang IP address
uses a lower metric (the route to the floang IP address is preferred) and receives the traffic. An
alternave to using stac routes would be to design the network to redistribute the floang IP
address into the OSPF roung protocol (if you are using OSPF).
The following topology illustrates the floang IP address bound to the acve-primary firewall,
which is inially Peer A, the firewall on the le.
High Availability
Upon a failover, when the acve-primary firewall (Peer A) goes down and the acve-secondary
firewall (Peer B) takes over as the acve-primary peer, the floang IP address moves to Peer B
(shown in the following figure). Peer B remains the acve-primary firewall and traffic connues to
go to Peer B, even when Peer A recovers and becomes the acve-secondary firewall. You decide if
and when to make Peer A the acve-primary firewall again.
Binding the floang IP address to the acve-primary firewall provides you with more control over
how the firewalls determine floang IP address ownership as they move between various HA
Firewall States. The following advantages result:
• You can have an acve/acve HA configuraon for path monitoring out of both firewalls, but
have the firewalls funcon like an acve/passive HA configuraon because traffic directed to
the floang IP address always goes to the acve-primary firewall.
When you disable preempon on both firewalls, you have the following addional benefits:
• The floang IP address does not move back and forth between HA firewalls if the acve-
secondary firewall flaps up and down.
• You can review the funconality of the recovered firewall and the adjacent components before
manually direcng traffic to it again, which you can do at a convenient down me.
High Availability
• You have control over which firewall owns the floang IP address so that you keep all flows of
new and exisng sessions on the acve-primary firewall, thereby minimizing traffic on the HA3
link.
• We strongly recommended you configure HA link monitoring on the interface(s) that

support the floang IP address(es) to allow each HA peer to quickly detect a link failure
and fail over to its peer. Both HA peers must have link monitoring for it to funcon.
• We strongly recommend you configure HA path monitoring to nofy each HA
peer when a path has failed so a firewall can fail over to its peer. Because the
floang IP address is always bound to the acve-primary firewall, the firewall cannot
automacally fail over to the peer when a path goes down and path monitoring is not
enabled.
You cannot configure NAT for a floang IP address that is bound to an acve-primary
firewall.
STEP 2 | (Oponal) Disable preempon.
Disabling preempon allows you full control over when the recovered firewall becomes
the acve-primary firewall.
2. Clear Preempve if it is enabled.
3. Click OK.

2. For Session Owner Selecon, we recommend you select Primary Device. The firewall
that is in acve-primary state is the session owner.
Alternavely, for Session Owner Selecon you can select First Packet and then for
Session Setup, select Primary Device or First Packet.
3. For Session Setup, select Primary Device—The acve-primary firewall sets up all
sessions. This is the recommended seng if you want your acve/acve configuraon
to behave like an acve/passive configuraon because it keeps all acvity on the acve-
primary firewall.
You must also engineer your network to eliminate the possibility of asymmetric
traffic going to the HA pair. If you don’t do so and traffic goes to the acve-
secondary firewall, seng Session Owner Selecon and Session Setup to
Primary Device causes the traffic to traverse HA3 to get to the acve-primary
firewall for session ownership and session setup.
4. Click OK.
High Availability

Add.
3. Select the IPv4 or IPv6 tab and Add an IPv4 Address or IPv6 Address.
4. For Type, select Floang, which configures the virtual IP address to be a floang IP
address.
5. Click OK.
STEP 6 | Bind the floang IP address to the acve-primary firewall.

1. Select Floang IP bound to the Acve-Primary device.
3. Click OK.
firewall.
Use Case: Configure Acve/Acve HA with Source DIPP NAT Using Floang IP
Addresses
This Layer 3 interface example uses source NAT in Acve/Acve HA Mode. The Layer 2 switches
create broadcast domains to ensure users can reach everything north and south of the firewalls.
PA-3050-1 has Device ID 0 and its HA peer, PA-3050-2, has Device ID 1. In this use case, NAT
translates the source IP address and port number to the floang IP address configured on the
egress interface. Each host is configured with a default gateway address, which is the floang IP
address on Ethernet1/1 of each firewall. The configuraon requires two source NAT rules, one
bound to each Device ID, although you configure both NAT rules on a single firewall and they are
synchronized to the peer firewall.
High Availability
STEP 1 | On PA-3050-2 (Device ID 1), perform Step 1 through Step 3 of Configure Acve/Acve HA.
STEP 2 | Enable acve/acve HA.

5. Set the Device ID to 1.
peer firewall.
9. Click OK.

Complete Step 6 through Step 14.

2. For Session Owner Selecon, select First Packet—The firewall that receives the first
packet of a new session is the session owner.
3. For Session Setup, select IP Modulo—Distributes session setup load based on parity of
the source IP address.
4. Click OK.
High Availability

Add.
2. Select Interface eth1/1.
3. Select IPv4 and Add an IPv4 Address of 10.1.1.101.
4. For Type, select Floang, which configures the virtual IP address to be a floang IP
address.

1. Do not select Floang IP bound to the Acve-Primary device.
3. Click OK.
STEP 7 | Enable jumbo frames on firewalls other than the PA-7000 Series.
STEP 10 | Configure the peer firewall, PA-3050-1 with the same sengs, except for the following
changes:
• Select Device ID 0.
• Configure an HA virtual address of 10.1.1.100.
• For Device 1 Priority, enter 255. For Device 0 Priority, enter 0.
In this example, Device ID 0 has a lower priority value so a higher priority; therefore, the
firewall with Device ID 0 (PA-3050-1) owns the floang IP address 10.1.1.100.
STEP 11 | Sll on PA-3050-1, create the source NAT rule for Device ID 0.
1. Select Policies > NAT and click Add.
2. Enter a Name for the rule that in this example idenfies it as a source NAT rule for
Device ID 0.
3. For NAT Type, select ipv4 (default).
4. On the Original Packet, for Source Zone, select Any.
5. For Desnaon Zone, select the zone you created for the external network.
6. Allow Desnaon Interface, Service, Source Address, and Desnaon Address to
remain set to Any.
7. For the Translated Packet, select Dynamic IP And Port for Translaon Type.
8. For Address Type, select Interface Address, in which case the translated address will
be the IP address of the interface. Select an Interface (eth1/1 in this example) and an IP
Address of the floang IP address 10.1.1.100.
9. On the Acve/Acve HA Binding tab, for Acve/Acve HA Binding, select 0 to bind the
NAT rule to Device ID 0.
10. Click OK.
High Availability
STEP 12 | Create the source NAT rule for Device ID 1.

2. Enter a Name for the policy rule that in this example helps idenfy it as a source NAT
rule for Device ID 1.
4. On the Original Packet, for Source Zone, select Any. For Desnaon Zone, select the
zone you created for the external network.
5. Allow Desnaon Interface, Service, Source Address, and Desnaon Address to
remain set to Any.
6. For the Translated Packet, select Dynamic IP And Port for Translaon Type.
7. For Address Type, select Interface Address, in which case the translated address will
be the IP address of the interface. Select an Interface (eth1/1 in this example) and an IP
Address of the floang IP address 10.1.1.101.
8. On the Acve/Acve HA Binding tab, for the Acve/Acve HA Binding, select 1 to bind
the NAT rule to Device ID 1.
9. Click OK.
Use Case: Configure Separate Source NAT IP Address Pools for Acve/Acve HA
Firewalls
If you want to use IP address pools for source NAT in Acve/Acve HA Mode, each firewall must
have its own pool, which you then bind to a Device ID in a NAT rule.
Address objects and NAT rules are synchronized (in both acve/passive and acve/acve mode),
so they need to be configured on only one of the firewalls in the HA pair.
This example configures an address object named Dyn-IP-Pool-dev0 containing the IP address
pool 10.1.1.140-10.1.1.150. It also configures an address object named Dyn-IP-Pool-dev1
containing the IP address pool 10.1.1.160-10.1.1.170. The first address object is bound to Device
ID 0; the second address object is bound to Device ID 1.
STEP 1 | On one HA firewall, create address objects.
1. Select Objects > Addresses and Add an address object Name, in this example, Dyn-IP-
Pool-dev0.
2. For Type, select IP Range and enter the range 10.1.1.140-10.1.1.150.
3. Click OK.
4. Repeat this step to configure another address object named Dyn-IP-Pool-dev1 with the
IP Range of 10.1.1.160-10.1.1.170.
High Availability

1. Select Policies > NAT and Add a NAT policy rule with a Name, for example, Src-NAT-
dev0.
2. For Original Packet, for Source Zone, select Any.
3. For Desnaon Zone, select the desnaon zone for which you want to translate the
source address, such as Untrust.
4. For Translated Packet, for Translaon Type, select Dynamic IP and Port.
5. For Translated Address, Add the address object you created for the pool of addresses
belonging to Device ID 0: Dyn-IP-Pool-dev0.
6. For Acve/Acve HA Binding, select 0 to bind the NAT rule to Device ID 0.
7. Click OK.

1. Select Policies > NAT and Add a NAT policy rule with a Name, for example, Src-NAT-
dev1.
2. For Original Packet, for Source Zone, select Any.
3. For Desnaon Zone, select the desnaon zone for which you want to translate the
source address, such as Untrust.
4. For Translated Packet, for Translaon Type, select Dynamic IP and Port.
5. For Translated Address, Add the address object you created for the pool of addresses
belonging to Device ID 1: Dyn-IP-Pool-dev1.
6. For Acve/Acve HA Binding, select 1 to bind the NAT rule to Device ID 1.
7. Click OK.
Use Case: Configure Acve/Acve HA for ARP Load-Sharing with Desnaon NAT
This Layer 3 interface example uses NAT in Acve/Acve HA Mode and ARP Load-Sharing
with desnaon NAT. Both HA firewalls respond to an ARP request for the desnaon NAT
address with the ingress interface MAC address. Desnaon NAT translates the public, shared
IP address (in this example, 10.1.1.200) to the private IP address of the server (in this example,
192.168.2.200).
When the HA firewalls receive traffic for the desnaon 10.1.1.200, both firewalls could possibly
respond to the ARP request, which could cause network instability. To avoid the potenal issue,
configure the firewall that is in acve-primary state to respond to the ARP request by binding the
desnaon NAT rule to the acve-primary firewall.
High Availability

ID to calculate the virtual MAC address (range is 1 to 63).
6. Select Device ID to be 1.
peer firewall.
10. Click OK.
STEP 3 | Perform Step 6 through Step 15 in Configure Acve/Acve HA.

Add.
4. For Type, select ARP Load Sharing, which configures the virtual IP address to be for both
peers to use for ARP Load-Sharing.
High Availability

1. For Device Selecon Algorithm, select IP Modulo. The firewall that will respond to ARP
requests is based on the parity of the ARP requester's IP address.
2. Click OK.
STEP 6 | Enable jumbo frames on firewalls other than the PA-7000 Series.
STEP 9 | Configure the peer firewall, PA-3050-1 (Device ID 0), with the same sengs, except in Step 2
select Device ID 0.
STEP 10 | Sll on PA-3050-1 (Device ID 0), create the desnaon NAT rule so that the acve-primary
firewall responds to ARP requests.
2. Enter a Name for the rule that, in this example, idenfies it as a desnaon NAT rule for
Layer 2 ARP.
5. For Desnaon Zone, select the Untrust zone you created for the external network.
6. Allow Desnaon Interface, Service, and Source Address to remain set to Any.
7. For Desnaon Address, specify 10.1.1.200.
8. For the Translated Packet, Source Address Translaon remains None.
9. For Desnaon Address Translaon, enter the private IP address of the desnaon
server, in this example, 192.168.1.200.
10. On the Acve/Acve HA Binding tab, for Acve/Acve HA Binding, select primary to
bind the NAT rule to the firewall in acve-primary state.
11. Click OK.
Use Case: Configure Acve/Acve HA for ARP Load-Sharing with Desnaon NAT in
Layer 3
This Layer 3 interface example uses NAT in Acve/Acve HA Mode and ARP Load-Sharing.
PA-3050-1 has Device ID 0 and its HA peer, PA-3050-2, has Device ID 1.
In this use case, both of the HA firewalls must respond to an ARP request for the desnaon
NAT address. Traffic can arrive at either firewall from either WAN router in the untrust zone.
Desnaon NAT translates the public-facing, shared IP address to the private IP address of the
server. The configuraon requires one desnaon NAT rule bound to both Device IDs so that
both firewalls can respond to ARP requests.
High Availability

1. Select Device > High Availability > General > Setup and edit.
4. ( Oponal) Enter a Descripon.
6. Select Device ID to be 1.
peer firewall.
9. ( Oponal) Enter a Backup Peer HA1 IP Address, which is the IP address of the backup
10. Click OK.


Add.
4. For Type, select ARP Load Sharing, which configures the virtual IP address to be for both
peers to use for ARP Load-Sharing.
High Availability

1. For Device Selecon Algorithm, select one of the following
requester's source IP address and desnaon IP address.
2. Click OK.
STEP 9 | Configure the peer firewall, PA-3050-1 (Device ID 0), with the same sengs, except set the
Device ID to 0 instead of 1.
STEP 10 | Sll on PA-3050-1 (Device ID 0), create the desnaon NAT rule for both Device ID 0 and
Device ID 1.
2. Enter a Name for the rule that in this example idenfies it as a desnaon NAT rule for
Layer 3 ARP.
5. For Desnaon Zone, select the Untrust zone you created for the external network.
6. Allow Desnaon Interface, Service, and Source Address to remain set to Any.
7. For Desnaon Address, specify 10.1.1.200.
8. For the Translated Packet, Source Address Translaon remains None.
9. For Desnaon Address Translaon, enter the private IP address of the desnaon
server, in this example 192.168.1.200.
10. On the Acve/Acve HA Binding tab, for Acve/Acve HA Binding, select both to bind
the NAT rule to both Device ID 0 and Device ID 1.
11. Click OK.
High Availability
HA Clustering Overview
®
A number of Palo Alto Networks firewall models now support session state synchronizaon
among firewalls in a high availability (HA) cluster of up to 16 firewalls. The HA cluster peers
synchronize sessions to protect against failure of the data center or a large security inspecon
point with horizontally scaled firewalls. In the case of a network outage or a firewall going down,
the sessions fail over to a different firewall in the cluster. Such synchronizaon is especially helpful
in the following use cases.
One use case is when HA peers are spread across mulple data centers so that there is no single
point of failure within or between data centers. A second mul-data center use case is when one
data center is acve and the other is standby.
A third HA clustering use case is horizontal scaling, in which you add HA cluster members to a
single data center to scale security and ensure session survivability.
High Availability
HA clusters support a Layer 3 or virtual wire deployment. HA peers in the cluster can be a
combinaon of HA pairs and standalone cluster members. In an HA cluster, all members are
considered acve; there is no concept of passive firewalls except for HA pairs, which can keep
their acve/passive relaonship aer you add them to an HA cluster.
All cluster members share session state. When a new firewall joins an HA cluster, that triggers all
firewalls in the cluster to synchronize all exisng sessions. HA4 and HA4 backup connecons are
the dedicated cluster links that synchronize session state among all cluster members having the
same cluster ID. The HA4 link between cluster members detects connecvity failures between
cluster members. HA1 (control link), HA2 (data link), and HA3 (packet-forwarding link) are not
supported between cluster members that aren’t HA pairs.
For a normal session that has not failed over, only the firewall that is the session owner creates
a traffic log. For a session that failed over, the new session owner (the firewall that receives the
failed over traffic) creates the traffic log.
The firewall models that support HA clustering and the maximum number of members supported
per cluster are as follows:
Firewall Model Number of Members Supported Per

Cluster
PA-3200 Series 6
PA-5200 Series 16
PA-5450 8
PA-7000 Series firewalls that have at least one PA-7080: 4

of the following cards: PA-7000-100G-NPC,
PA-7050: 6
PA-7000-20GQXM-NPC, PA-7000-20GXM-NPC
High Availability
Firewall Model Number of Members Supported Per

Cluster
VM-300 6
VM-500 6
VM-700 16
HA clustering is not supported in public cloud deployments. Consider the HA Clustering Best
Pracces and Provisioning before you start to Configure HA Clustering.
High Availability
HA Clustering Best Pracces and Provisioning

These are the provisioning requirements and best pracces for HA clustering.
• Provisioning Requirements and Best Pracces
®
• HA cluster members must be the same firewall model and run the same PAN-OS version.
When upgrading, firewall members will connue to synchronize sessions with one
member at a different version.
• It is highly recommended and a best pracce to use Panorama to provision HA cluster
members to keep all configuraon and policies synchronized among all cluster members.
• HA cluster members must be licensed for the same components to ensure consistent policy
enforcement and content inspecon capabilies.
• The licenses must expire at the same me to prevent mismatched licenses and loss of
funconality.
• All cluster members should be running with the same version of dynamic Content Updates
for consistent security enforcement.
• HA cluster members must share the same zone names in order for sessions to successfully
fail over to another cluster member. For example, suppose sessions going to an ingress zone
named internal are dropped because the link is down. For those sessions to fail over to
an HA firewall peer in the cluster, that peer must also have a zone named internal.
• Client-to-server and server-to-client flows must go back to the same firewall under normal
(non-failure) condions in order for security content scanning to occur. Asymmetric traffic
won’t be dropped, but it cannot be scanned for security purposes.
• Session Synchronizaon Best Pracces
• Dedicated HA communicaon interfaces should be used over dataplane interfaces. HSCI
interfaces aren’t used for HA4. This allows separaon of HA pair and cluster session
synchronizaon to ensure maximum bandwidth and reliability for session syncing.
• HA4 should be adequately sized if you use dataplane interfaces. This ensures best effort
session state synchronizing between cluster members.
• Best pracce is to have a dedicated cluster network for the HA4 communicaons link to
ensure adequate bandwidth and non-congested, low-latency connecons between cluster
members.
• Architect your networks and perform traffic engineering to avoid possible race condions,
in which a network steers traffic from the session owner to a cluster member before the
session is successfully synced between the firewalls. Layer2 HA4 connecons must have
sufficient bandwidth and low latency to allow mely synchronizaon between HA members.
The HA4 latency must be lower than the latency incurred when the peering devices switch
traffic between cluster members.
• Architect your networks to minimize asymmetric flows. Session setup requires one cluster
member to see the complete TCP three-way handshake.
High Availability
• Health Check Best Pracces

• On HA pairs in a cluster, configure an Acve/Passive pair with HA backup communicaon
links for HA1, HA2, and HA4. Configure an Acve/Acve pair with HA backup
communicaons links for HA1, HA2, HA3, and HA4.
• Configure HA4 backup links on all cluster members.
High Availability
Configure HA Clustering
Learn about HA clustering and follow the HA Clustering Best Pracces and Provisioning before
you configure HA firewalls as members of a cluster.
STEP 1 | Establish an interface as an HA interface (to later assign as the HA4 link).
1. Select Network > Interfaces > Ethernet and select an interface; for example,
ethernet1/1.
2. Select the Interface Type to be HA.
3. Click OK.
4. Repeat this step to configure another interface to use as the HA4 backup link.
STEP 2 | Enable HA clustering.

1. Select Device > High Availability > General and edit the Clustering Sengs.
2. Enable Cluster Parcipaon.
3. Enter the Cluster ID, a unique numeric ID for an HA cluster in which all members can
share session state; range is 1 to 99.
4. Enter a short, helpful Cluster Descripon.
5. (Oponal) Change Cluster Synchronizaon Timeout (min), which is the maximum
number of minutes that the local firewall waits before going to Acve state when
another cluster member (for example, in unknown state) is prevenng the cluster from
fully synchronizing; range is 0 to 30; default is 0.
6. (Oponal) Change Monitor Fail Hold Down Time (min), which is the number of minutes
aer which a down link is retested to see if it is back up; range is 1 to 60; default is 1.
7. Click OK.
STEP 3 | Configure the HA4 link.

1. Select HA Communicaons and in the Clustering Links secon, edit the HA4 secon.
2. Select the interface you configured in the first step as an HA interface to be the Port for
the HA4 link; for example, ethernet1/1.
3. Enter the IPv4/IPv6 Address of the local HA4 interface.
4. Enter the Netmask.
5. (Oponal) Change the HA4 Keep-alive Threshold (ms) to specify the meframe within
which the firewall must receive keepalives from a cluster member to know that the
cluster member is funconal; range is 5,000 to 60,000; default is 10,000.
6. Click OK.
High Availability
STEP 4 | Configure the HA4 Backup link.

1. Edit the HA4 Backup secon.
2. Select the other interface you configured in the first step as an HA interface to be the
Port for the HA4 backup link.
3. Enter the IPv4/IPv6 Address of the local HA4 backup interface.
4. Enter the Netmask.
5. Click OK.
STEP 5 | Specify all members of the HA cluster, including the local member and both HA peers in any
HA pair.
1. Select Cluster Config.
2. (On a supported firewall) Add a peer member’s Device Serial Number.
3. (On Panorama) Add and select a Device from the dropdown and enter a Device Name.
4. Enter the HA4 IP Address of the HA peer in the cluster.
5. Enter the HA4 Backup IP Address of the HA peer in the cluster.
6. Enable Session Synchronizaon with the peer you idenfied.
7. (Oponal) Enter a helpful Descripon.
8. Click OK.
9. Select the device and Enable it.
STEP 6 | Define HA failover condions with link and path monitoring.
STEP 7 | Commit.
STEP 8 | (Panorama only) Refresh the list of HA firewalls in the HA cluster.

1. Under Templates, select Device > High Availability > Cluster Config.
2. Click Refresh at the boom of the screen.
STEP 9 | View HA cluster informaon in the UI.

1. Select Dashboard.
2. View the HA cluster fields. The top secon displays cluster state and HA4 connecons
to provide cluster health at a glance. The HA4 and HA4 Backup indicators will be one of
the following: Green indicates the link status of the cluster members is Up. Red indicates
the link status of all the cluster members is Down. Yellow indicates the link status of
some cluster members is Up while the status of other cluster members is Down. Grey
indicates not configured. The center secon displays the capacity of the local session
table and session cache table so you can monitor how full the tables are and plan for
firewall upgrades. The lower secon displays communicaon errors on the HA4 and
High Availability
HA4 backup links, signifying possible problems with synchronizing informaon between
members.
STEP 10 | Access the CLI to view HA cluster and HA4 link informaon and perform other HA clustering
tasks.
You can view HA cluster flap stascs. The cluster flap count is reset when the HA
device moves from suspended to funconal and vice versa. The cluster flap count also
resets when the non-funconal hold me expires.
High Availability
Refresh HA1 SSH Keys and Configure Key Opons

All Palo Alto Networks firewalls come with Secure Shell (SSH) pre-configured, and the high
availability (HA) firewalls can act as SSH server and SSH client simultaneously. When you
configure acve/passive or acve/acve HA, you can enable encrypon for the HA1 (control link)
connecon between the HA firewalls. We recommend you secure the HA1 traffic between the
HA peers with encrypon, parcularly if the firewalls aren’t located in the same site. Aer you
enable encrypon on the HA1 control link, you can use the CLI to create an SSH service profile
and secure the connecon between the HA firewalls.
SSH service profiles enable you to change the default host key type, generate a new pair of public
and private SSH host keys for the HA1 control link, and configure other SSH HA1 sengs. You
can apply the new host keys and configured sengs to the firewalls without restarng the HA
peers. The firewall will reestablish HA1 sessions with its peer to synchronize the configuraon
changes. It also generates system logs (subtype is ha) for reestablishing HA1 and HA1-backup
sessions.
The following examples show how to configure various SSH sengs for your HA1 aer you
enable encrypon and access the CLI. (See Refresh SSH Keys and Configure Key Opons for
Management Interface Connecon for SSH management server profile examples.)
You must enable encrypon and it must be funconing properly on an HA pair before you
can perform the following tasks.
If you are configuring the HA1 control link in FIPS-CC mode, you must set automac
rekeying parameters for session keys.
To use the same SSH connecon sengs for each Dedicated Log Collector (M-series or
Panorama virtual appliance in Log Collector mode) in a Collector Group, configure an SSH
service profile from the Panorama management server, Commit the changes to Panorama,
and then Push the configuraon to the Log Collectors. You can use the set log-
collector-group <name> general-setting management ssh commands.
Create an SSH service profile to exercise greater control over SSH connecons between your
HA firewalls.
This example creates an HA profile without configuring any sengs.
1. admin@PA-3250> configure
2. admin@PA-3250# set deviceconfig system ssh profiles ha-profiles
<name>
3. admin@PA-3250# commit
4. admin@PA-3250# exit
5. To verify that the new profile has been created and view the sengs for any exisng
profiles:
admin@PA-3250> configure
admin@PA-3250# show deviceconfig system ssh profiles
High Availability
(Oponal) Set the SSH server to use only the specified encrypon ciphers for the HA1 sessions.
By default, HA1 SSH allows all supported ciphers for encrypon of CLI HA sessions. When you
set one or more ciphers, the SSH server adverses only those ciphers while connecng, and
if the SSH client (HA peer) tries to connect using a different cipher, the server terminates the
connecon.
2. admin@PA-3250# set deviceconfig system ssh profiles ciphers ha-
profiles <name> ciphers <cipher>
aes128-cbc—AES 128-bit cipher with Cipher Block Chaining
aes128-ctr—AES 128-bit cipher with Counter Mode
aes128-gcm—AES 128-bit cipher with GCM (Galois/Counter Mode)
aes256-gcm—AES 256-bit cipher with GCM
5. (HA1 Backup is configured) admin@PA-3250> request high-availability
session-reestablish
6. (No HA1 Backup is configured or HA1 Backup link is down) admin@PA-3250> request
high-availability session-reestablish force
You can force the firewall to reestablish HA1 sessions if there is no HA1 backup,
which causes a brief split-brain condion between the HA peers. (Using the force
opon when an HA1 backup is configured has no effect.)
7. To verify the ciphers have been updated:
admin@PA-3250# show deviceconfig system ssh profiles ha-profiles
ciphers
(Oponal) Set the default host key type.

If you enable encrypon on the HA1 control link, the firewall uses a default host key type of
RSA 2048 unless you change it. The HA1 SSH connecon uses only the default host key
type to authencate the HA peers (before an encrypted session is established between them).
You can change the default host key type; the choices are ECDSA 256, 384, or 521, or RSA
2048, 3072, or 4096. Change the default host key type if you prefer a longer RSA key length or
if you prefer ECDSA rather than RSA. This example sets the default host key type to an ECDSA
High Availability
key of 256 bits. It also re-establishes the HA1 connecon using the new host key without
restarng the HA peers.
<name> default-hostkey key-type ECDSA key-length 256
5. admin@PA-3250> request high-availability sync-to-remote ssh-key
An HA connecon must already be established between the HA firewalls. If the

firewalls have not yet established an HA connecon, you must enable encrypon
on the control link connecon, export the HA key to a network locaon and
import the HA key on the peer. See Configure Acve/Passive HA or Configure
Acve/Acve HA.
session-reestablish
which causes a brief split-brain condion between the two HA peers. (Using the
force opon when an HA1 backup is configured has no effect.)
8. To verify the host key has been updated:
<name> default-hostkey
High Availability
(Oponal) Delete a cipher from the set of ciphers you selected for SSH over the HA1 control
link.
This example deletes the AES CBC cipher with 128-bit key.
2. admin@PA-3250# delete deviceconfig system ssh profiles ha-profiles
<name> ciphers aes128-cbc
session-reestablish
force opon when an HA1 backup is configured has no effect.
7. To verify the cipher has been deleted:
<name> ciphers
High Availability
(Oponal) Set the session key exchange algorithms the HA1 SSH server will support.
By default, the SSH server (HA firewall) adverses all the key exchange algorithms to the SSH
client (HA peer firewall).
If you are using an ECDSA default key type, the best pracce is to use an ECDH key
algorithm.
<name> kex <value>
diffie-hellman-group14-sha1—Diffie-Hellman group 14 with SHA1 hash
ecdh-sha2-nistp256—Ellipc-Curve Diffie-Hellman over Naonal Instute of
Standards and Technology (NIST) P-256 with SHA2-256 hash
ecdh-sha2-nistp384—Ellipc-Curve Diffie-Hellman over NIST P-384 with SHA2-384
hash
ecdh-sha2-nistp521—Ellipc-Curve Diffie-Hellman over NIST P-521 with SHA2-521
hash
session-reestablish
force opon when an HA1 backup is configured has no effect.
7. To verify the key exchange algorithms have been updated:
High Availability
(Oponal) Set the message authencaon codes (MAC) the HA1 SSH server will support.
By default, the server adverses all of the MAC algorithms to the client.
<name> mac <value>
hmac-sha1—MAC with SHA1 cryptographic hash
hmac-sha2-256—MAC with SHA2-256 cryptographic hash
hmac-sha2-512—MAC with SHA2-512 cryptographic hash
session-reestablish
force opon has no effect when an HA1 backup is configured.
7. To verify the MAC algorithms have been updated:
High Availability
(Oponal) Regenerate ECDSA or RSA host keys for HA1 SSH to replace the exisng keys, and
re-establish HA1 sessions between HA peers using the new keys without restarng the HA
peers.
The HA peers use the host keys to authencate each other. This example regenerates the
ECDSA 256 default host key.
Regenerang a host key does not change your default host key type. To regenerate the
default host key you are using, you must specify your default host key type and length
when you regenerate. Regenerang a host key that isn’t your default host key type
simply regenerates a key that you aren’t using and therefore has no effect.
2. admin@PA-3250# set deviceconfig system ssh regenerate-hostkeys ha
key-type ECDSA key-length 256
5. admin@PA-3250> request high-availability sync-to-remote ssh-key
An HA connecon must already be established between the HA firewalls. If the

firewalls have not yet established an HA connecon, you must enable encrypon
on the control link connecon, export the HA key to a network locaon, and
import the HA key on the peer. See Configure Acve/Passive HA or Configure
Acve/Acve HA.
session-reestablish
(Oponal) Set rekey parameters to establish when automac rekeying of the session keys
occurs for SSH over the HA1 control link.
The session keys are used to encrypt the traffic between the HA peers. The parameters you
can set are data volume (in megabytes), me interval (seconds), and packet count. Aer any
one rekey parameter reaches its configured value, SSH iniates a key exchange.
You can set a second or third parameter if you aren’t sure the parameter you configured
will reach its value as soon as you want rekeying to occur. The first parameter to reach its
configured value will prompt a rekey, then the firewall will reset all rekey parameters.
<name> session-rekey data 32
Rekeying occurs aer the volume of data (in megabytes) is transmied following the
previous rekey. The default is based on the cipher you use and ranges from 1GB to 4GB;
High Availability
the range is 10MB to 4,000MB. Alternavely, you can enter set deviceconfig
system ssh profiles ha-profiles <name> session-rekey data
default command, which sets the data parameter to the default value of the individual
cipher you are using.
<name> session-rekey interval 3600
Rekeying occurs aer the specified me interval (in seconds) passes following the
previous rekeying. By default, me-based rekeying is disabled (set to none). The range is
10 to 3,600.
<name> session-rekey packets 27
n
Rekeying occurs aer the defined number of packets (2 ) are transmied following
14
the previous rekey. For example, 14 configures that a maximum of 2 packets are
28 12 27
transmied before a rekey occurs. The default is 2 . The range is 12 to 27 (2 to 2 ).
Alternavely, you can enter set deviceconfig system ssh profiles ha-
profiles <name> session-rekey packets default, which sets the packets
28
parameter to 2 .
Choose rekeying parameters based on your type of traffic and network speeds (in
addion to FIPS-CC requirements if they apply to you). Don’t set the parameters
so low that they affect SSH performance.
session-reestablish
9. To verify the changes:
<name> session-rekey
High Availability
Acvate the profile by selecng the profile and restarng HA1 SSH service.
2. admin@PA-3250# set deviceconfig system ssh ha ha-profile <name>
5. admin@PA-3250> set ssh service-restart ha
6. To verify the correct profile is in use:
admin@PA-3250# show deviceconfig system ssh ha
High Availability
HA Firewall States
An HA firewall can be in one of the following states:
HA Firewall Occurs In Descripon

State
Inial A/P or A/ Transient state of a firewall when it joins the HA pair. The firewall
A remains in this state aer boot-up unl it discovers a peer and
negoaons begins. Aer a meout, the firewall becomes acve
if HA negoaon has not started.
Acve A/P State of the acve firewall in an acve/passive configuraon.
Passive A/P State of the passive firewall in an acve/passive configuraon.

The passive firewall is ready to become the acve firewall with
no disrupon to the network. Although the passive firewall is not
processing other traffic:
• If passive link state auto is configured, the passive firewall is
running roung protocols, monitoring link and path state, and
the passive firewall will pre-negoate LACP and LLDP if LACP
and LLDP pre-negoaon are configured, respecvely.
• The passive firewall is synchronizing flow state, runme
objects, and configuraon.
• The passive firewall is monitoring the status of the acve
firewall using the hello protocol.
Acve-Primary A/A In an acve/acve configuraon, state of the firewall that

connects to User-ID agents, runs DHCP server and DHCP relay,
and matches NAT and PBF rules with the Device ID of the
acve-primary firewall. A firewall in this state can own sessions
and set up sessions.
Acve- A/A In an acve/acve configuraon, state of the firewall that

Secondary connects to User-ID agents, runs DHCP server, and matches
NAT and PBF rules with the Device ID of the acve-secondary
firewall. A firewall in acve-secondary state does not support
DHCP relay. A firewall in this state can own sessions and set up
sessions.
Tentave A/A State of a firewall (in an acve/acve configuraon) caused by

one of the following:
• Failure of a firewall.
• Failure of a monitored object (a link or path).
• The firewall leaves suspended or non-funconal state.
High Availability
HA Firewall Occurs In Descripon

State
A firewall in tentave state synchronizes sessions and
configuraons from the peer.
• In a virtual wire deployment, when a firewall enters tentave
state due to a path failure and receives a packet to forward,
it sends the packet to the peer firewall over the HA3 link for
processing. The peer firewall processes the packet and sends
it back over the HA3 link to the firewall to be sent out the
egress interface. This behavior preserves the forwarding path
in a virtual wire deployment.
• In a Layer 3 deployment, when a firewall in tentave state
receives a packet, it sends that packet over the HA3 link for
the peer firewall to own or set up the session. Depending on
the network topology, this firewall either sends the packet
out to the desnaon or sends it back to the peer in tentave
state for forwarding.
Aer the failed path or link clears or as a failed firewall
transions from tentave state to acve-secondary state, the
Tentave Hold Time is triggered and roung convergence
occurs. The firewall aempts to build roung adjacencies and
populate its route table before processing any packets. Without
this mer, the recovering firewall would enter acve-secondary
state immediately and would silently discard packets because it
would not have the necessary routes.
When a firewall leaves suspended state, it goes into tentave
state for the Tentave Hold Time aer links are up and able to
process incoming packets.
Tentave Hold Time range (sec) can be disabled (which is 0
seconds) or in the range 10-600; default is 60.
Non- A/P or A/ Error state due to a dataplane failure or a configuraon

funconal A mismatch, such as only one firewall configured for packet
forwarding, VR sync or QoS sync.
In acve/passive mode, all of the causes listed for Tentave state
cause non-funconal state.
Suspended A/P or A/ The device is disabled so won’t pass data traffic and although
A HA communicaons sll occur, the device doesn’t parcipate in
the HA elecon process. It can’t move to an HA funconal state
without user intervenon.
High Availability
Reference: HA Synchronizaon
If you have enabled configuraon synchronizaon on both peers in an HA pair, most of the
configuraon sengs you configure on one peer will automacally sync to the other peer upon
commit. To avoid configuraon conflicts, always make configuraon changes on the acve (acve/
passive) or acve-primary (acve/acve) peer and wait for the changes to sync to the peer before
making any addional configuraon changes.
Only commied configuraons synchronize between HA peers. Any configuraon in the

commit queue at the me of an HA sync will not be synchronized.
The following topics idenfy which configuraon sengs you must configure on each firewall
independently (these sengs are not synchronized from the HA peer).
• What Sengs Don’t Sync in Acve/Passive HA?
• What Sengs Don’t Sync in Acve/Acve HA?
• Synchronizaon of System Runme Informaon
What Sengs Don’t Sync in Acve/Passive HA?

You must configure the following sengs on each firewall in an HA pair in an acve/passive
deployment. These sengs do not sync from one peer to another.
Configuraon Item What Doesn’t Sync in Acve/Passive?
Management All management configuraon sengs must be configured individually

Interface Sengs on each firewall, including:
• Device > Setup > Management > General Sengs—Hostname,
Domain, Login Banner, SSL/TLS Service Profile (and associated
cerficates), Time Zone, Locale, Date, Time, Latude, Longitude.
• Device > Setup > Management > Management Interface Sengs—
IP Type, IP Address, Netmask, Default Gateway, IPv6 Address/
Prefix Length, Default IPv6 Gateway, Speed, MTU, and Services
(HTTP, HTTP OCSP, HTTPS, Telnet, SSH, Ping, SNMP, User-ID,
User-ID Syslog Listener-SSL, User-ID Syslog Listener-UDP)
Mul-vsys Capability You must acvate the Virtual Systems license on each firewall in the
pair to increase the number of virtual systems beyond the base number
provided by default on PA-3200 Series, PA-5200 Series, and PA-7000
Series firewalls.
You must also enable Mul Virtual System Capability on each firewall
(Device > Setup > Management > General Sengs).
Panorama Sengs Set the following Panorama sengs on each firewall (Device > Setup >
Management > Panorama Sengs).
• Panorama Servers
High Availability

• Disable Panorama Policy and Objects and Disable Device and
Network Template
SNMP Device > Setup > Operaons > SNMP Setup
Services Device > Setup > Services
Global Service Routes Device > Setup > Services > Service Route Configuraon
Telemetry and Threat Device > Setup > Telemetry and Threat Intelligence
Intelligence Sengs
Data Protecon Device > Setup > Content-ID > Manage Data Protecon
Jumbo Frames Device > Setup > Session > Session Sengs > Enable Jumbo Frame
Packet Buffer Device > Setup > Session > Session Sengs > Packet Buffer
Protecon Protecon
Network > Zones > Enable Packet Buffer Protecon
Forward Proxy Server Device > Setup > Session > Decrypon Sengs > SSL Forward Proxy
Cerficate Sengs Sengs
Master Key Secured Device > Setup > HSM > Hardware Security Module Provider >
by HSM Master Key Secured by HSM
Log Export Sengs Device > Scheduled Log Export
Soware Updates With soware updates, you can either download and install them
separately on each firewall, or download them on one peer and sync
the update to the other peer. You must install the update on each peer
(Device > Soware).
GlobalProtect Agent With GlobalProtect app updates, you can either download and install
Package them separately on each firewall, or download them to one peer and
sync the update to the other peer. You must acvate separately on
each peer (Device > GlobalProtect Client).
Content Updates With content updates, you can either download and install them
(Device > Dynamic Updates).
Licenses/ Device > Licenses

Subscripons
High Availability
Support Subscripon Device > Support
Master Key The master key must be idencal on each firewall in the HA pair, but
you must manually enter it on each firewall (Device > Master Key and
Diagnoscs).
Before changing the master key, you must disable config sync on both
peers (Device > High Availability > General > Setup and clear the
Enable Config Sync check box) and then re-enable it aer you change
the keys.
Reports, logs, and Log data, reports, and Dashboard data and sengs (column display,
Dashboard Sengs widgets) are not synced between peers. Report configuraon sengs,
however, are synced.
HA sengs Device > High Availability
Rule Usage Data Rule usage data, such as hit count, Created, and Modified Dates, are
not synced between peers. You need to log in to the each firewall to
view the policy rule hit count data for each firewall or use Panorama to
view informaon on the HA firewall peers.
Cerficates for Device > Cerficate Management > Cerficates

Device Management
Cerficates used for device management or for syslog communicaon
and Syslog
over SSL don’t synchronize with an HA peer.
Communicaon over
SSL only
Cerficates in a Device > Cerficate Management > Cerficate Profile

Cerficate Profile
SSL/TLS Service Device > Cerficate Management > SSL/TLS Service Profile
Profile for Device
SSL/TLS Service Profile for Device Management doesn’t synchronize
Management only
with an HA peer.
Device-ID and IoT IP address-to-device mappings and policy rule recommendaons don’t
Security synchronize with an HA peer.
What Sengs Don’t Sync in Acve/Acve HA?

You must configure the following sengs on each firewall in an HA pair in an acve/acve
deployment. These sengs do not sync from one peer to another.
High Availability
Configuraon Item What Doesn’t Sync in Acve/Acve?
Management You must configure all management sengs individually on each

Interface Sengs firewall, including:
• Device > Setup > Management > General Sengs—Hostname,
Domain, Login Banner, SSL/TLS Service Profile (and associated
cerficates), Time Zone, Locale, Date, Time, Latude, Longitude.
• Device > Setup > Management > Management Interface Sengs—
IP Address, Netmask, Default Gateway, IPv6 Address/Prefix Length,
Default IPv6 Gateway, Speed, MTU, and Services (HTTP, HTTP
OCSP, HTTPS, Telnet, SSH, Ping, SNMP, User-ID, User-ID Syslog
Listener-SSL, User-ID Syslog Listener-UDP)
Mul-vsys Capability You must acvate the Virtual Systems license on each firewall in the
pair to increase the number of virtual systems beyond the base number
provided by default on PA-3200 Series, PA-5200 Series, and PA-7000
Series firewalls.
You must also enable Mul Virtual System Capability on each firewall
(Device > Setup > Management > General Sengs).
Panorama Sengs Set the following Panorama sengs on each firewall (Device > Setup >
Management > Panorama Sengs).
• Panorama Servers
• Disable Panorama Policy and Objects and Disable Device and
Network Template
SNMP Device > Setup > Operaons > SNMP Setup
Services Device > Setup > Services
Global Service Routes Device > Setup > Services > Service Route Configuraon
Telemetry and Threat Device > Setup > Telemetry and Threat Intelligence
Intelligence Sengs
Data Protecon Device > Setup > Content-ID > Manage Data Protecon
Jumbo Frames Device > Setup > Session > Session Sengs > Enable Jumbo Frame
Packet Buffer Device > Setup > Session > Session Sengs > Packet Buffer
Protecon Protecon
Network > Zones > Enable Packet Buffer Protecon
Forward Proxy Server Device > Setup > Session > Decrypon Sengs > SSL Forward Proxy
Cerficate Sengs Sengs
High Availability
HSM Configuraon Device > Setup > HSM
Log Export Sengs Device > Scheduled Log Export
Soware Updates With soware updates, you can either download and install them
(Device > Soware).
GlobalProtect Agent With GlobalProtect app updates, you can either download and install
Package them separately on each firewall, or download them to one peer and
sync the update to the other peer. You must acvate separately on
each peer (Device > GlobalProtect Client).
Content Updates With content updates, you can either download and install them
(Device > Dynamic Updates).
Licenses/ Device > Licenses

Subscripons
Support Subscripon Device > Support
Ethernet Interface IP All Ethernet interface configuraon sengs sync except for the IP
Addresses address (Network > Interface > Ethernet).
Loopback Interface IP All Loopback interface configuraon sengs sync except for the IP
Addresses address (Network > Interface > Loopback).
Tunnel Interface IP All Tunnel interface configuraon sengs sync except for the IP
Addresses address (Network > Interface > Tunnel).
LACP System Priority Each peer must have a unique LACP System ID in an acve/acve
deployment (Network > Interface > Ethernet > Add Aggregate Group
> System Priority).
VLAN Interface IP All VLAN interface configuraon sengs sync except for the IP
Address address (Network > Interface > VLAN).
Virtual Routers Virtual router configuraon synchronizes only if you have enabled
VR Sync (Device > High Availability > Acve/Acve Config > Packet
Forwarding). Whether or not to do this depends on your network
design, including whether you have asymmetric roung.
IPSec Tunnels IPSec tunnel configuraon synchronizaon is dependent on whether

you have configured the Virtual Addresses to use Floang IP
High Availability

addresses (Device > High Availability > Acve/Acve Config > Virtual
Address). If you have configured a floang IP address, these sengs
sync automacally. Otherwise, you must configure these sengs
independently on each peer.
GlobalProtect Portal GlobalProtect portal configuraon synchronizaon is dependent on

Configuraon whether you have configured the Virtual Addresses to use Floang IP
addresses (Network > GlobalProtect > Portals). If you have configured
a floang IP address, the GlobalProtect portal configuraon sengs
sync automacally. Otherwise, you must configure the portal sengs
independently on each peer.
GlobalProtect GlobalProtect gateway configuraon synchronizaon is dependent

Gateway on whether you have configured the Virtual Addresses to use
Configuraon Floang IP addresses (Network > GlobalProtect > Gateways). If you
have configured a floang IP address, the GlobalProtect gateway
configuraon sengs sync automacally. Otherwise, you must
configure the gateway sengs independently on each peer.
QoS QoS configuraon synchronizes only if you have enabled QoS

Sync (Device > High Availability > Acve/Acve Config > Packet
Forwarding). You might choose not to sync QoS seng if, for example,
you have different bandwidth on each link or different latency through
your service providers.
LLDP No LLDP state or individual firewall data is synchronized in an acve/

acve configuraon (Network > Network Profiles > LLDP).
BFD No BFD configuraon or BFD session data is synchronized in an

acve/acve configuraon (Network > Network Profiles > BFD
Profile).
IKE Gateways IKE gateway configuraon synchronizaon is dependent on whether

you have configured the Virtual Addresses to use floang IP addresses
(Network > IKE Gateways). If you have configured a floang IP
address, the IKE gateway configuraon sengs sync automacally.
Otherwise, you must configure the IKE gateway sengs independently
on each peer.
Master Key The master key must be idencal on each firewall in the HA pair, but
you must manually enter it on each firewall (Device > Master Key and
Diagnoscs).
Before changing the master key, you must disable config sync on both
peers (Device > High Availability > General > Setup and clear the
Enable Config Sync check box) and then re-enable it aer you change
the keys.
High Availability
Reports, logs, and Log data, reports, and dashboard data and sengs (column display,
Dashboard Sengs widgets) are not synced between peers. Report configuraon sengs,
however, are synced.
HA sengs • Device > High Availability

• (The excepon is Device > High Availability > Acve/Acve
Configuraon > Virtual Addresses, which do sync.)
Rule Usage Data Rule usage data, such as hit count, Created, and Modified Dates, are
not synced between peers. You need to log in to the each firewall to
view the policy rule hit count data for each firewall or use Panorama to
view informaon on the HA firewall peers.
Cerficates for Device > Cerficate Management > Cerficates

Device Management
Cerficates used for device management or for syslog communicaon
and Syslog
over SSL don’t synchronize with an HA peer.
Communicaon over
SSL only
Cerficates in a Device > Cerficate Management > Cerficate Profile

Cerficate Profile
SSL/TLS Service Device > Cerficate Management > SSL/TLS Service Profile
Profile for Device
SSL/TLS Service Profile for Device Management doesn’t synchronize
Management only
with an HA peer.
Device-ID and IoT IP address-to-device mappings and policy rule recommendaons don’t
Security synchronize with an HA peer.
Synchronizaon of System Runme Informaon

The following table summarizes what system runme informaon is synchronized between HA
peers.
Runme Informaon Config Synced? HA Link Details
A/P A/A
Management Plane
User to Group Mappings Yes Yes HA1
User Mappings across Yes Yes HA1

Virtual Systems
High Availability
A/P A/A
User to IP Address Yes Yes HA1

Mappings
DHCP Lease (as server) Yes Yes HA1 If the PAN-OS versions
on the HA peers don’t
match, the DHCP
Lease (as server) config
informaon won’t sync.
DNS Cache No No N/A
FQDN Refresh No No N/A
IKE Keys (phase 2) Yes Yes HA1
Forward Informaon Base Yes Yes HA1

(FIB)
PAN-DB URL Cache Yes No HA1 This is synchronized upon

database backup to disk
(every eight hours, when
URL database version
updates), or when the
firewall reboots.
Content (manual sync) Yes Yes HA1
PPPoE, PPPoE Lease Yes Yes HA1
DHCP Client Sengs and Yes Yes HA1 If the PAN-OS versions
Lease on the HA peers don’t
match, the DHCP Client
Sengs and Lease config
informaon won’t sync.
SSL VPN Logged in User Yes Yes HA1

List
Dataplane
Session Table Yes Yes HA2 • Acve/passive peers

do not sync ICMP
or host session
informaon.
High Availability
A/P A/A
• Acve/acve peers
do not sync host
session, mulcast
session, or BFD
session informaon.
A host
session is
a session
terminated
on one
of the
firewall
interfaces,
such as
an ICMP
session
pinging
one
of the
firewall
interfaces
or a GP
tunnel.
ARP Table Yes No HA2
Neighbor Discovery (ND) Yes No HA2

Table
MAC Table Yes No HA2
IPSec Sequence Number Yes Yes HA2

(an-replay)
DoS Block List Entries No No N/A
Virtual MAC Yes Yes HA2
SCTP Associaons Yes No HA2
Monitoring
To forestall potenal issues and to accelerate incidence response when needed, the
firewall provides intelligence about traffic and user paerns using customizable and
informave reports. The dashboard, Applicaon Command Center (ACC), reports, and
logs on the firewall allow you to monitor acvity on your network. You can monitor
the logs and filter the informaon to generate reports with predefined or customized
views. For example, you can use the predefined templates to generate reports on
user acvies or analyze the reports and logs to interpret unusual behavior on your
network and generate a custom report on the traffic paern. For a visually engaging
presentaon of network acvity, the dashboard and the ACC include widgets, charts,
and tables with which you can interact to find the informaon you care about. In
addion, you can configure the firewall to forward monitored informaon as email
noficaons, syslog messages, SNMP traps, and NetFlow records to external services.
> Use the Dashboard > View Policy Rule Usage
> Use the Applicaon Command > Use External Services for Monitoring
Center > Configure Log Forwarding
> Use the App Scope Reports > Configure Email Alerts
> Use the Automated Correlaon > Use Syslog for Monitoring
Engine
> SNMP Monitoring and Traps
> Take Packet Captures
> Forward Logs to an HTTP(S)
> Monitor Applicaons and Threats Desnaon
> View and Manage Logs > NetFlow Monitoring
> Monitor Block List
> View and Manage Reports
445
Monitoring
Use the Dashboard

The Dashboard tab widgets show general firewall informaon, such as the soware version, the
operaonal status of each interface, resource ulizaon, and up to 10 of the most recent entries in
the threat, configuraon, and system logs. All of the available widgets are displayed by default, but
each administrator can remove and add individual widgets, as needed. Click the refresh icon to
update the dashboard or an individual widget. To change the automac refresh interval, select an
interval from the drop-down (1 min, 2 mins, 5 mins, or Manual). To add a widget to the dashboard,
click the widget drop-down, select a category and then the widget name. To delete a widget, click
in the tle bar. The following table describes the dashboard widgets.
Dashboard Charts Descripons
Top Applicaons Displays the applicaons with the most sessions. The block size
indicates the relave number of sessions (mouse-over the block to
view the number), and the color indicates the security risk—from green
(lowest) to red (highest). Click an applicaon to view its applicaon
profile.
Top High Risk Similar to Top Applicaons, except that it displays the highest-risk
Applicaons applicaons with the most sessions.
General Informaon Displays the firewall name, model, PAN-OS soware version, the
applicaon, threat, and URL filtering definion versions, the current
date and me, and the length of me since the last restart.
Interface Status Indicates whether each interface is up (green), down (red), or in an

unknown state (gray).
Threat Logs Displays the threat ID, applicaon, and date and me for the last 10
entries in the Threat log. The threat ID is a malware descripon or URL
that violates the URL filtering profile.
Config Logs Displays the administrator username, client (Web or CLI), and date and
me for the last 10 entries in the Configuraon log.
Data Filtering Logs Displays the descripon and date and me for the last 60 minutes in
the Data Filtering log.
URL Filtering Logs Displays the descripon and date and me for the last 60 minutes in
the URL Filtering log.
System Logs Displays the descripon and date and me for the last 10 entries in the
System log.
A Config installed entry indicates configuraon

changes were commied successfully.
Monitoring
Dashboard Charts Descripons
System Resources Displays the Management CPU usage, Data Plane usage, and the
Session Count, which displays the number of sessions established
through the firewall.
Logged In Admins Displays the source IP address, session type (Web or CLI), and session
start me for each administrator who is currently logged in.
ACC Risk Factor Displays the average risk factor (1 to 5) for the network traffic
processed over the past week. Higher values indicate higher risk.
High Availability If high availability (HA) is enabled, indicates the HA status of the local
and peer firewall—green (acve), yellow (passive), or black (other). For
more informaon about HA, see High Availability.
Locks Shows configuraon locks taken by administrators.
Monitoring
Use the Applicaon Command Center

The Applicaon Command Center (ACC) is an interacve, graphical summary of the applicaons,
users, URLs, threats, and content traversing your network.The ACC uses the firewall logs to
provide visibility into traffic paerns and aconable informaon on threats. The ACC layout
includes a tabbed view of network acvity, threat acvity, and blocked acvity and each tab
includes pernent widgets for beer visualizaon of network traffic. The graphical representaon
allows you to interact with the data and visualize the relaonships between events on the
network, so that you can uncover anomalies or find ways to enhance your network security rules.
For a personalized view of your network, you can also add a custom tab and include widgets that
allow you to drill down into the informaon that is most important to you.
ACC data, including ACC widgets and exported ACC reports, use Security policy rule data
that you enabled to Log at Session End. If some data you expect to view in the ACC is
not displayed, view your Traffic and Threat logs to determine the correct Security policy
rule to modify as needed so all new logs generated that match the Security policy rule are
viewable in the ACC.
• ACC—First Look
• ACC Tabs
• ACC Widgets (Widget Descripons)
• ACC Filters
• Interact with the ACC
• Use Case: ACC—Path of Informaon Discovery
ACC—First Look
Take a quick tour of the ACC.
Monitoring
ACC—First Look
Tabs The ACC includes three predefined tabs that

provide visibility into network traffic, threat
acvity, and blocked acvity. For informaon on
each tab, see ACC Tabs.
Widgets Each tab includes a default set of widgets that best

represent the events/trends associated with the
tab. The widgets allow you to survey the data using
the following filters:
• bytes (in and out)
• sessions
• content (files and data)
• URL categories
• threats (and count)
For informaon on each widget, see ACC Widgets.
Time The charts or graphs in each widget provide a

summary and historic view. You can choose a
custom range or use the predefined me periods
that range from the last 15 minutes up to the last
90 days or last 30 calendar days. The selected me
period applies across all tabs in the ACC.
The me period used to render data, by default,
is the Last Hour updated in 15 minute intervals.
The date and me interval are displayed onscreen,
for example at 11:40, the me range is 01/12
10:30:00-01/12 11:29:59.
Global Filters The Global Filters allow you to set the filter across
all widgets and all tabs. The charts/graphs apply
the selected filters before rendering the data. For
informaon on using the filters, see ACC Filters.
Applicaon The applicaon view allows you filter the ACC

View view by either the sanconed and unsanconed
applicaons in use on your network, or by the risk
level of the applicaons in use on your network.
Green indicates sanconed applicaons, blue
unsanconed applicaons, and yellow indicates
applicaons that are parally sanconed. Parally
sanconed applicaons are those that have a
mixed sanconed state; it indicates that the
applicaon is inconsistently tagged as sanconed,
for example it might be sanconed on one or more
Monitoring
ACC—First Look
virtual systems on a firewall enabled for mulple
virtual systems or across one or more firewalls
within a device group on Panorama.
Risk Factor The risk factor (1=lowest to 5=highest) indicates

the relave risk based on the applicaons used
on your network. The risk factor uses a variety of
factors to assess the associated risk levels, such
as whether the applicaon can share files, is it
prone to misuse or does it try to evade firewalls,
it also factors in the threat acvity and malware
as seen through the number of blocked threats,
compromised hosts or traffic to malware hosts/
domains.
Source The data used for the ACC display. The opons
vary on the firewall and on Panorama.
On the firewall, if enabled for mulple virtual
systems, you can use the Virtual System drop-
down to change the ACC display to include data
from all virtual systems or just a selected virtual
system.
On Panorama, you can select the Device Group
drop-down to change the ACC display to include
data from all device groups or just a selected
device group.
Addionally, on Panorama, you can change the
Data Source as Panorama data or Remote Device
Data. Remote Device Data is only available when
all the managed firewalls are on PAN-OS 7.0.0
or later. When you filter the display for a specific
device group, Panorama data is used as the data
source.
Export You can export the widgets displayed in the

currently selected tab as a PDF. The PDF is
downloaded and saved to the downloads folder
associated with your web browser, on your
computer.
ACC Tabs
The ACC includes the following predefined tabs for viewing network acvity, threat acvity, and
blocked acvity.
Monitoring
Tab Descripon
Network Acvity Displays an overview of traffic and user acvity on your network
including:
• Top applicaons in use
• Top users who generate traffic (with a drill down into the bytes,
content, threats or URLs accessed by the user)
• Most used security rules against which traffic matches occur
In addion, you can also view network acvity by source or
desnaon zone, region, or IP address, ingress or egress interfaces,
and GlobalProtect host informaon such as the operang systems
of the devices most commonly used on the network.
Threat Acvity Displays an overview of the threats on the network, focusing on

the top threats: vulnerabilies, spyware, viruses, hosts vising
malicious domains or URLs, top WildFire submissions by file type
and applicaon, and applicaons that use non-standard ports. The
Compromised Hosts widget in this tab (the widget is supported
on some plaorms only), supplements detecon with beer
visualizaon techniques; it uses the informaon from the correlated
events tab (Automated Correlaon Engine > Correlated Events) to
present an aggregated view of compromised hosts on your network
by source users/IP addresses and sorted by severity.
Blocked Acvity Focuses on traffic that was prevented from coming into the
network. The widgets in this tab allow you to view acvity denied
by applicaon name, username, threat name, blocked content—files
and data that were blocked by a file blocking profile. It also lists the
top security rules that were matched on to block threats, content,
and URLs.
Tunnel Acvity Displays the acvity of tunnel traffic that the firewall inspected
based on your tunnel inspecon policies. Informaon includes
tunnel usage based on tunnel ID, monitor tag, user, and tunnel
protocols such as Generic Roung Encapsulaon (GRE), General
Packet Radio Service (GPRS) Tunneling Protocol for User Data (GTP-
U), and non-encrypted IPSec.
GlobalProtect Acvity Displays an overview of user acvity in your GlobalProtect

deployment. Informaon includes the number of users and number
of mes users connected, the gateways to which users connected,
the number of connecon failures and the failure reason, a
summary of authencaon methods and GlobalProtect app versions
used, and the number of endpoints that are quaranned.
In addion, this tab displays a chart view summary of devices
that have been quaranned. Use the toggle at the top of the
chart to view the quaranned devices by the acons that caused
Monitoring
Tab Descripon
GlobalProtect to quaranne the device, the reason GlobalProtect
quaranned the device, and the locaon of the quaranned devices.
SSL Acvity Displays an overview of TLS/SSL decrypon acvity on the firewall.

Informaon includes successful and unsuccessful decrypon
acvity in your network, decrypon failure reasons such as
protocol, cerficate, and version issues, TLS versions, key exchange
algorithms, and the amount and type of decrypted and undecrypted
traffic.
Use the ACC informaon to evaluate how decrypon is working on
your network and then use the Decrypon Log to drill down into
details.
You can also Interact with the ACC to create customized tabs with custom layout and widgets that
meet your network monitoring needs, export the tab and share with another administrator.
ACC Widgets
The widgets on each tab are interacve; you can set the ACC Filters and drill down into the details
for each table or graph, or customize the widgets included in the tab to focus on the informaon
you need. For details on what each widget displays, see Widget Descripons.
Widgets
View You can sort the data by bytes, sessions, threats,

count, content, URLs, malicious, benign, files,
Monitoring
Widgets
applicaons, data, profiles, objects, users. The
available opons vary by widget.
Graph The graphical display opons are treemap, line

graph, horizontal bar graph, stacked area graph,
stacked bar graph, and map. The available opons
vary by widget; the interacon experience also
varies with each graph type. For example, the
widget for Applicaons using Non-Standard Ports
allows you to choose between a treemap and a line
graph.
To drill down into the display, click into the graph.
The area you click into becomes a filter and allows
you to zoom into the selecon and view more
granular informaon on the selecon.
Table The detailed view of the data used to render the

graph is provided in a table below the graph. You
can interact with the table in several ways:
• Click and set a local filter for an aribute in
the table. The graph is updated and the table
is sorted using the local filter. The informaon
displayed in the graph and the table are always
synchronized.
• Hover over the aribute in the table and use the
opons available in the drop-down.
Acons
Maximize view— Allows you enlarge the widget
and view the table in a larger screen space and with
more viewable informaon.
Set up local filters—Allows you to add ACC

Filters to refine the display within the widget.
Use these filters to customize the widgets; these
customizaons are retained between logins.
Jump to logs—Allows you to directly navigate to the

logs (Monitor > Logs > <log-type> tab). The logs are
Monitoring
Widgets
filtered using the me period for which the graph is
rendered.
If you have set local and global filters, the log query
concatenates the me period and the filters and
only displays logs that match the combined filter
set.
Export—Allows you to export the graph as a

PDF. The PDF is downloaded and saved on your
computer. It is saved in the Downloads folder
associated with your web browser.
Widget Descripons
Each tab on the ACC includes a different set of widgets.
Widget Descripon
Network Acvity—Displays an overview of traffic and user acvity on your network.
Applicaon Usage The table displays the top ten applicaons used on your network, all
the remaining applicaons used on the network are aggregated and
displayed as other. The graph displays all applicaons by applicaon
category, sub category, and applicaon. Use this widget to scan
for applicaons being used on the network, it informs you about
the predominant applicaons using bandwidth, session count, file
transfers, triggering the most threats, and accessing URLs.
Sort aributes: bytes, sessions, threats, content, URLs
Charts available: treemap, area, column, line (the charts vary by the
sort by aribute selected)
User Acvity Displays the top ten most acve users on the network who have
generated the largest volume of traffic and consumed network
resources to obtain content. Use this widget to monitor top users on
usage sorted on bytes, sessions, threats, content (files and paerns),
and URLs visited.
Charts available: area, column, line (the charts vary by the sort by
aribute selected)
Source IP Acvity Displays the top ten IP addresses or hostnames of the devices that
have iniated acvity on the network. All other devices are aggregated
and displayed as other.
Monitoring
Widget Descripon
Desnaon IP Displays the IP addresses or hostnames of the top ten desnaons

Acvity that were accessed by users on the network.
Source Regions Displays the top ten regions (built-in or custom defined regions) around
the world from where users iniated acvity on your network.
Charts available: map, bar
Desnaon Regions Displays the top ten desnaon regions (built-in or custom defined
regions) on the world map from where content is being accessed by
users on the network.
Charts available: map, bar
HIP Informaon Displays informaon on the state of the hosts on which the
GlobalProtect agent is running; the host system is a GlobalProtect
endpoint. This informaon is sourced from entries in the HIP match log
that are generated when the data submied by the GlobalProtect app
matches a HIP object or a HIP profile you have defined on the firewall.
If you do not have HIP Match logs, this widget is blank. To learn how
to create HIP objects and HIP profiles and use them as policy match
criteria, see Configure HIP-Based Policy Enforcement.
Sort aributes: profiles, objects, operang systems
Charts available: bar
Rule Usage Displays the top ten rules that have allowed the most traffic on the
network. Use this widget to view the most commonly used rules,
monitor the usage paerns, and to assess whether the rules are
effecve in securing your network.
Charts available: line
Ingress Interfaces Displays the firewall interfaces that are most used for allowing traffic
into the network.
Sort aributes: bytes, bytes sent, bytes received
Monitoring
Widget Descripon
Egress Interfaces Displays the firewall interfaces that are most used by traffic exing the
network.
Sort aributes: bytes, bytes sent, bytes received
Source Zones Displays the zones that are most used for allowing traffic into the
network.
Desnaon Zones Displays the zones that are most used by traffic going outside the
network.
Threat Acvity—Displays an overview of the threats on the network
Compromised Hosts Displays the hosts that are likely compromised on your network. This
widget summarizes the events from the correlaon logs. For each
source user/IP address, it includes the correlaon object that triggered
the match and the match count, which is aggregated from the match
evidence collated in the correlated events logs. For details see Use the
Automated Correlaon Engine.
Available on the PA-5200 Series, PA-7000 Series, and Panorama.
Sort aributes: severity (by default)
Hosts Vising Displays the frequency with which hosts (IP address/hostnames) on
Malicious URLs your network have accessed malicious URLs. These URLs are known to
be malware based on categorizaon in PAN-DB.
Sort aributes: count
Hosts Resolving Displays the top hosts matching DNS signatures; hosts on the network
Malicious Domains that are aempng to resolve the hostname or domain of a malicious
URL. This informaon is gathered from an analysis of the DNS acvity
on your network. It ulizes passive DNS monitoring, DNS traffic
generated on the network, acvity seen in the sandbox if you have
configured DNS sinkhole on the firewall, and DNS reports on malicious
DNS sources that are available to Palo Alto Networks customers.
Sort aributes: count
Monitoring
Widget Descripon
Threat Acvity Displays the threats seen on your network. This informaon is based
on signature matches in Anvirus, An-Spyware, and Vulnerability
Protecon profiles and viruses reported by WildFire.
Sort aributes: threats
Charts available: bar, area, column
WildFire Acvity by Displays the applicaons that generated the most WildFire
Applicaon submissions. This widget uses the malicious and benign verdict from
the WildFire Submissions log.
Sort aributes: malicious, benign
Charts available: bar, line
WildFire Acvity by Displays the threat vector by file type. This widget displays the file
File Type types that generated the most WildFire submissions and uses the
malicious and benign verdict from the WildFire Submissions log. If this
data is unavailable, the widget is empty.
Sort aributes: malicious, benign
Applicaons using Displays the applicaons that are entering your network on non-
Non Standard Ports standard ports. If you have migrated your firewall rules from a port-
based firewall, use this informaon to cra policy rules that allow
traffic only on the default port for the applicaon. Where needed,
make an excepon to allow traffic on a non-standard port or create a
custom applicaon.
Charts available: treemap, line
Rules Allowing Displays the security policy rules that allow applicaons on non-
Applicaons On Non default ports. The graph displays all the rules, while the table displays
Standard Ports the top ten rules and aggregates the data from the remaining rules as
other.
This informaon helps you idenfy gaps in network security by
allowing you to assess whether an applicaon is hopping ports or
sneaking into your network. For example, you can validate whether
you have a rule that allows traffic on any port except the default port
for the applicaon. Say for example, you have a rule that allow DNS
traffic on its applicaon-default port (port 53 is the standard port for
DNS). This widget will display any rule that allows DNS traffic into your
network on any port except port 53.
Monitoring
Widget Descripon
Charts available: treemap, line
Blocked Acvity—Focuses on traffic that was prevented from coming into the network
Blocked Applicaon Displays the applicaons that were denied on your network, and
Acvity allows you to view the threats, content, and URLs that you kept out of
your network.
Sort aributes: threats, content, URLs
Charts available: treemap, area, column
Blocked User Displays user requests that were blocked by a match on an Anvirus,
Acvity An-spyware, File Blocking or URL Filtering profile aached to
Security policy rule.
Blocked Threats Displays the threats that were successfully denied on your network.
These threats were matched on anvirus signatures, vulnerability
signatures, and DNS signatures available through the dynamic content
updates on the firewall.
Sort aributes: threats
Blocked Content Displays the files and data that was blocked from entering the
network. The content was blocked because security policy denied
access based on criteria defined in a File Blocking security profile or a
Data Filtering security profile.
Sort aributes: files, data
Security Policies Displays the security policy rules that blocked or restricted traffic
Blocking Acvity into your network. Because this widget displays the threats, content,
and URLs that were denied access into your network, you can use
it to assess the effecveness of your policy rules. This widget does
not display traffic that blocked because of deny rules that you have
defined in policy.
GlobalProtect Acvity—Displays informaon of user acvity in your GlobalProtect deployment.
Monitoring
Widget Descripon
Successful Displays a chart view of GlobalProtect connecon acvity over the

GlobalProtect selected me period. Use the toggle at the top of the chart to switch
Connecon Acvity between connecon stascs by users, portals and gateways, and
locaon.
Sort aributes: users, portals/gateways, locaon
Unsuccessful Displays a chart view of unsuccessful GlobalProtect connecon

GlobalProtect acvity over the selected me period. Use the toggle at the top of
Connecon Acvity the chart to switch between connecon stascs by users, portals
and gateways, and locaon. To help you idenfy and troubleshoot
connecon issues, you can also view the reasons chart or graph. For
this chart, the ACC indicates the error, source user, public IP address
and other informaon to help you idenfy and resolve the issue
quickly.
Sort aributes: users, portals/gateways, reasons, locaon
GlobalProtect Displays a chart view summary of your deployment. Use the toggle at
Deployment Acvity the top of the chart to view the distribuon of users by authencaon
method, GlobalProtect app version, and operang system version.
Sort aributes: auth method, globalprotect app version, os
GlobalProtect Displays a chart view summary of devices that have been quaranned.
Quaranne Acvity Use the toggle at the top of the chart to view the quaranned devices
by the acons that caused GlobalProtect to quaranne the device, the
reason GlobalProtect quaranned the device, and the locaon of the
quaranned devices.
Sort aributes: acons, reason, locaon
SSL Acvity—Displays informaon about SSL/TLS acvity in your network.
Traffic Acvity Shows SSL/TLS acvity compared to non-SSL/TLS acvity by total

number of sessions or bytes.
SSL/TLS Acvity Shows successful TLS connecons by TLS version and applicaon or
SNI. This widget helps you understand how much risk you are taking
on by allowing weaker TLS protocol versions. Idenfying applicaons
and SNIs that use weak protocols enables you to evaluate each
one and decide whether you need to allow access to it for business
reasons. If you don’t need the applicaon for business purposes, you
Monitoring
Widget Descripon
may want to block the traffic instead of allowing it. Click an applicaon
or an SNI to drill down and see detailed informaon.
Decrypon Failure Shows the reasons for decrypon failures, such as cerficate or
Reasons protocol issues, by SNI. Use this informaon to detect problems
caused by Decrypon policy or profile misconfiguraon or by traffic
that uses weak protocols or algorithms. Click a failure reason to drill
down and isolate the number of sessions per SNI or click an SNI to see
the failures for that SNI.
Successful TLS Shows the amount of decrypted and non-decrypted traffic by sessions
Version Acvity or bytes. Traffic that was not decrypted may be excepted from
decrypon by policy, policy misconfiguraon, or by being on the
Decrypon Exclusion List (Device > Cerficate Management > SSL
Decrypon Exclusion).
Successful Key Shows successful key exchange acvity per algorithm, by applicaon
Exchange Acvity or by SNI. Click a key exchange algorithm to see the acvity for just
that algorithm or click an applicaon or SNI to view the key exchange
acvity for that applicaon or SNI.
ACC Filters
The graphs and tables on the ACC widgets allow you to use filters to narrow the scope of data
that is displayed, so that you can isolate specific aributes and analyze informaon you want to
view in greater detail. The ACC supports the simultaneous use of widget and global filters.
• Widget Filters—Apply a widget filter, which is a filter that is local to a specific widget. A widget
filter allows you to interact with the graph and customize the display so that you can drill down
in to the details and access the informaon you want to monitor on a specific widget. To create
a widget filter that is persistent across reboots, you must use the Set Local Filter opon.
Monitoring
• Global filters—Apply global filters across all the tabs in the ACC. A global filter allows you
to pivot the display around the details you care about right now and exclude the unrelated
informaon from the current display. For example, to view all events relang to a specific user
and applicaon, you can apply the username and the applicaon as a global filter and view only
informaon pertaining to the user and the applicaon through all the tabs and widgets on the
ACC. Global filters are not persistent.
You can apply global filters in three ways:

• Set a global filter from a table—Select an aribute from a table in any widget and apply the
aribute as a global filter.
• Add a widget filter to a global filter—Hover over the aribute and click the arrow icon to
the right of the aribute. This opon allows you to elevate a local filter used in a widget, and
apply the aribute globally to update the display across all the tabs on the ACC.
• Define a global filter—Define a filter using the Global Filters pane on the ACC.
See Interact with the ACC for details on using these filters.
Interact with the ACC

To customize and refine the ACC display, you can add, delete, export and import tabs, add and
delete widgets, set local and global filters, and interact with the widgets.
Add a tab.
1. Select the icon along the list of tabs.
2. Add a View Name. This name will be used as the name for the tab. You can add up to five
tabs.
Monitoring
Edit a tab.
Select the tab, and click the pencil icon next to the tab name, to edit the tab. For example
.
Eding a tab allows you to add or delete or reset the widgets that are displayed in the tab. You
can also change the widget layout in the tab.
To save the tab as the default tab, select .
Export and Import tabs.

1. Select the tab, and click the pencil icon next to the tab name, to edit the tab.
2. Select the icon to export the current tab as a .txt file. You can share this .txt file with
another administrator.
3. To import the tab as a new tab on another firewall, select the icon along the list of
tabs, and add a name and click the import icon, browse to select the .txt file.
See what widgets are included in a tab.

1. Select the tab, and click on the pencil icon to edit it.
2. Select the Add Widget drop-down and verify the widgets that have the check boxes
selected.
Add a widget or a widget group.

1. Add a new tab or edit a predefined tab.
2. Select Add Widget, and then select the check box that corresponds to the widget you
want to add. You can select up to a maximum of 12 widgets.
3. (Oponal) To create a 2-column layout, select Add Widget Group. You can drag and drop
widgets into the 2-column display. As you drag the widget into the layout, a placeholder
will display for you to drop the widget.
You cannot name a widget group.
Delete a tab or a widget group/ widget.

1. To delete a custom tab, select the tab and click the X icon.
You cannot delete a predefined tab.
2. To delete a widget group/widget, edit the tab and in the workspace secon, click the [X]
icon on the right. You cannot undo a deleon.
Monitoring
Reset the default widgets in a tab.

On a predefined tab, such as the Blocked Acvity tab, you can delete one or more widgets. If
you want to reset the layout to include the default set of widgets for the tab, edit the tab and
click Reset View.
Zoom in on the details in an area, column, or line graph.

Watch how the zoom-in capability works.
Click and drag an area in the graph to zoom in. For example, when you zoom into a line graph,
it triggers a re-query and the firewall fetches the data for the selected me period. It is not a
mere magnificaon.
Use the table drop-down to find more informaon on an aribute.

1. Hover over an aribute in a table to see the drop-down.
2. Click into the drop-down to view the available opons.
• Global Find—Use Global Find to Search the Firewall or Panorama Management Server
for references to the aribute (username/IP address, object name, policy rule name,
threat ID, or applicaon name) anywhere in the candidate configuraon.
• Value—Displays the details of the threat ID, or applicaon name, or address object.
• Who Is—Performs a domain name (WHOIS) lookup for the IP address. The lookup
queries databases that store the registered users or assignees of an Internet resource.
• Search HIP Report—Uses the username or IP address to find matches in a HIP Match
report.
Set a widget filter.
You can also click an aribute in the table (below the graph) to apply it as a widget
filter.
1. Select a widget and click the icon.

2. Click the icon to add the filters you want to apply.
3. Click Apply. These filters are persistent across reboots.
The acve widget filters are indicated next to the widget name.
Negate a widget filter

1. Click the icon to display the Setup Local Filters dialog.
2. Add a filter, and then click the negate icon.
Monitoring
Set a global filter from a table.

Hover over an aribute in the table below the chart and click the arrow icon to the right of the
aribute.
Set a global filter using the Global Filters pane.

Watch global filters in acon.
1. Locate the Global Filters pane on the le side of the ACC.
2. Click the icon to view the list of filters you can apply.
Promote a widget filter to a global filter.

1. On any table in a widget, click the link for an aribute. This sets the aribute as a widget
filter.
2. To promote the filter to be a global filter, select the arrow to the right of the filter.
Remove a filter.
Click the icon to remove a filter.
• For global filters: It is located in the Global Filters pane.
• For widget filters: Click the icon to display the Setup Local Filters dialog, then select the
filter, and click the icon.
Monitoring
Clear all filters.

• For global filters: Click the Clear All buon under Global Filters.
• For widget filters: Select a widget and click the icon. Then click the Clear All buon in the
Setup Local Filters dialog.
See what filters are in use.

• For global filters: The number of global filters applied are displayed on the le pane under
Global Filters.
• For widget filters: The number of widget filters applied on a widget are displayed next to the
widget name. To view the filters, click the icon.
Reset the display on a widget.

• If you set a widget filter or drill into a graph, click the Home link to reset the display in the
widget.
Use Case: ACC—Path of Informaon Discovery

The ACC has a wealth of informaon that you can use as a starng point for analyzing network
traffic. Let’s look at an example on using the ACC to uncover events of interest. This example
illustrates how you can use the ACC to ensure that legimate users can be held accountable for
their acons, detect and track unauthorized acvity, and detect and diagnose compromised hosts
and vulnerable systems on your network.
The widgets and filters in the ACC give you the capability to analyze the data and filter the views
based on events of interest or concern. You can trace events that pique your interest, directly
export a PDF of a tab, access the raw logs, and save a personalized view of the acvity that you
want to track. These capabilies make it possible for you to monitor acvity and develop policies
and countermeasures for forfying your network against malicious acvity. In this secon, you will
Interact with the ACC widgets across different tabs, drill down using widget filters, and pivot the
ACC views using global filters, and export a PDF for sharing with incidence response or IT teams.
At first glance, you see the Applicaon Usage and User Acvity widgets in the ACC > Network
Acvity tab. The User Acvity widget shows that user Marsha Wirth has transferred 154
Megabytes of data during the last hour. This volume is nearly six mes more than any other user
on the network. To see the trend over the past few hours, expand the Time period to the Last 6
Hrs, and now Marsha’s acvity has been 1.7 Gigabytes over 1,500 sessions and has triggered 455
threats signatures.
Monitoring
Because Marsha has transferred a large volume of data, apply her username as a global filter (ACC
Filters) and pivot all the views in the ACC to Marsha’s traffic acvity.
The Applicaon Usage tab now shows that the top applicaon that Martha used was rapidshare,
a Swiss-owned file-hosng site that belongs to the file-sharing URL category. For further
invesgaon, add rapidshare as a global filter, and view Marsha’s acvity in the context of
rapidshare.
Consider whether you want to sancon rapidshare for company use. Should you allow
uploads to this site and do you need a QoS policy to limit bandwidth?
Monitoring
To view which IP addresses Marsha has communicated with, check the Desnaon IP Acvity
widget, and view the data by bytes and by URLs.
To find out which countries Marsha communicated with, sort on sessions in the Desnaon
Regions widget.
From this data, you can confirm that Marsha, a user on your network, has established sessions in
Canada, Germany, Sweden, United Kingdom, and the United States. She logged 2 threats in her
sessions with each desnaon country.
To look at Marsha’s acvity from a threat perspecve, remove the global filter for rapidshare.
In the Threat Acvity widget on the Threat Acvity tab, view the threats. The widget displays
that her acvity had triggered a match for 452 vulnerabilies in the brute force, informaon
Monitoring
leak, portable executable (PE) and spyware threat category. Several of these vulnerabilies are of
crical severity.
To further drill-down into each vulnerability, click into the graph and narrow the scope of your
invesgaon. Each click automacally applies a local filter on the widget.
To invesgate each threat by name, you can create a global filter for say, WordPress Login
Brute Force Aack. Then, view the User Acvity widget in the Network Acvity tab. The tab
is automacally filtered to display threat acvity for Marsha (noce the global filters in the
screenshot).
Monitoring
Noce that this Microso code-execuon vulnerability was triggered over email, by the imap
applicaon. You can now establish that Martha has IE vulnerabilies and email aachment
vulnerabilies, and perhaps her computer needs to be patched. You can now either navigate to
the Blocked Threats widget in the Blocked Acvity tab to check how many of these vulnerabilies
were blocked.
Or, you can check the Rule Usage widget on the Network Acvity tab to discover how many
vulnerabilies made it into your network and which security rule allowed this traffic, and navigate
directly to the security rule using the Global Find capability.
Then, drill into the aackers using web-browsing to aack target desnaon. Consider modifying
the security policy rule to restrict these malicious IP addresses or more narrowly defining which IP
addresses can access your network resources.
To review if any threats were logged over web-browsing, check Marsha’s acvity in the WildFire
Acvity by Applicaon widget in the Threat Acvity tab. You can confirm that Marsha had no
malicious acvity, but to verify that other no other user was compromised by the web-browsing
Monitoring
applicaon, negate Marsha as a global filter and look for other users who triggered threats over
web-browsing.
Click into the bar for imap in the graph and drill into the inbound threats associated with the
applicaon. To find out who an IP address is registered to, hover over the aacker IP address and
select the Who Is link in the drop-down.
Because the session count from this IP address is high, check the Blocked Content and Blocked
Threats widgets in the Blocked Acvity tab for events related to this IP address. The Blocked
Acvity tab allows you to validate whether or not your policy rules are effecve in blocking
content or threats when a host on your network is compromised.
Use the Export PDF capability on the ACC to export the current view (create a snapshot of the
data) and send it to an incidence response team. To view the threat logs directly from the widget,
you can also click the icon to jump to the logs; the query is generated automacally and only
the relevant logs are displayed onscreen (for example in Monitor > Logs > Threat Logs).
Monitoring
You have now used the ACC to review network data/trends to find which applicaons or users are
generang the most traffic, and how many applicaon are responsible for the threats seen on the
network. You were able to idenfy which applicaon(s), user(s) generated the traffic, determine
whether the applicaon was on the default port, and which policy rule(s) allowed the traffic
into the network, and determine whether the threat is spreading laterally on the network. You
also idenfied the desnaon IP addresses, geo-locaons with which hosts on the network are
communicang with. Use the conclusions from your invesgaon to cra goal-oriented policies
that can secure users and your network.
Monitoring
Use the App Scope Reports

The App Scope reports provide visibility and analysis tools to help pinpoint problemac behavior,
helping you understand changes in applicaon usage and user acvity, users and applicaons that
take up most of the network bandwidth, and idenfy network threats.
With the App Scope reports, you can quickly see if any behavior is unusual or unexpected. Each
report provides a dynamic, user-customizable window into the network; hovering the mouse over
and clicking either the lines or bars on the charts opens detailed informaon about the specific
applicaon, applicaon category, user, or source on the ACC. The App Scope charts on Monitor >
App Scope give you the ability to:
• Toggle the aributes in the legend to only view chart details that you want to review. The
ability to include or exclude data from the chart allows you to change the scale and review
details more closely.
• Click into an aribute in a bar chart and drill down to the related sessions in the ACC. Click
into an Applicaon name, Applicaon Category, Threat Name, Threat Category, Source IP
address or Desnaon IP address on any bar chart to filter on the aribute and view the
related sessions in the ACC.
• Export a chart or map to PDF or as an image. For portability and offline viewing, you can Export
charts and maps as PDFs or PNG images.
The following App Scope reports are available:
• Summary Report
• Change Monitor Report
• Threat Monitor Report
• Threat Map Report
• Network Monitor Report
• Traffic Map Report
Summary Report
The App Scope Summary report (Monitor > App Scope > Summary) displays charts for the top five
gainers, losers, and bandwidth consuming applicaons, applicaon categories, users, and sources.
Monitoring
Change Monitor Report

The App Scope Change Monitor report (Monitor > App Scope > Change Monitor) displays
changes over a specified me period. For example, the following chart displays the top
applicaons that gained in use over the last hour as compared with the last 24-hour period. The
top applicaons are determined by session count and sorted by percent.
The Change Monitor Report contains the following buons and opons.
Buon Descripon
Top 10 Determines the number of records with the highest

measurement included in the chart.
Monitoring
Applicaon Determines the type of item reported: Applicaon,

Applicaon Category, Source, or Desnaon.
Gainers Displays measurements of items that have increased

over the measured period.
Losers Displays measurements of items that have decreased

New Displays measurements of items that were added over

the measured period.
Dropped Displays measurements of items that were disconnued

Filter Applies a filter to display only the selected item. None

displays all entries.
Determines whether to display session or byte

informaon.
Sort Determines whether to sort entries by percentage or

raw growth.
Export Exports the graph as a .png image or as a PDF.
Compare Specifies the period over which the change

measurements are taken.
Threat Monitor Report

The App Scope Threat Monitor report (Monitor > App Scope > Threat Monitor) displays a count
of the top threats over the selected me period. For example, the following figure shows the top
10 threat types over the last 6 hours.
Monitoring
Each threat type is color-coded as indicated in the legend below the chart. The Threat Monitor
report contains the following buons and opons.

Threats Determines the type of item measured: Threat, Threat

Category, Source, or Desnaon.
Filter Applies a filter to display only the selected type of

items.
Determines whether the informaon is presented in a

stacked column chart or a stacked area chart.
Specifies the period over which the measurements are

taken.
Threat Map Report

The App Scope Threat Map report (Monitor > App Scope > Threat Map) shows a geographical
view of threats, including severity. Each threat type is color-coded as indicated in the legend
below the chart.
The firewall uses geolocaon for creang threat maps. The firewall is placed at the boom of
the threat map screen, if you have not specified the geolocaon coordinates (Device > Setup >
Management, General Sengs secon) on the firewall.
Monitoring
The Threat Map report contains the following buons and opons.

Incoming threats Displays incoming threats.
Outdoing threats Displays outgoing threats.
Filer Applies a filter to display only the selected type of

items.
Zoom In and Zoom Out Zoom in and zoom out of the map.
Indicates the period over which the measurements are

taken.
Network Monitor Report

The App Scope Network Monitor report (Monitor > App Scope > Network Monitor) displays
the bandwidth dedicated to different network funcons over the specified period of me. Each
network funcon is color-coded as indicated in the legend below the chart. For example, the
image below shows applicaon bandwidth for the past 7 days based on session informaon.
Monitoring
The Network Monitor report contains the following buons and opons.

Applicaon Determines the type of item reported: Applicaon,

Applicaon Category, Source, or Desnaon.
Filter Applies a filter to display only the selected item. None

displays all entries.

informaon.
Determines whether the informaon is presented in a

stacked column chart or a stacked area chart.
Indicates the period over which the change

Traffic Map Report

The App Scope Traffic Map (Monitor > App Scope > Traffic Map) report shows a geographical
view of traffic flows according to sessions or flows.
Monitoring
The firewall uses geolocaon for creang traffic maps. The firewall is placed at the boom of
the traffic map screen, if you have not specified the geolocaon coordinates (Device > Setup >
Management, General Sengs secon) on the firewall.
Each traffic type is color-coded as indicated in the legend below the chart. The Traffic Map report
contains the following buons and opons.
Buons Descripon

Incoming threats Displays incoming threats.
Outgoing threats Displays outgoing threats.

informaon.
Zoom In and Zoom Out Zoom in and zoom out of the map.
Indicates the period over which the change

Monitoring
Use the Automated Correlaon Engine

The automated correlaon engine is an analycs tool that uses the logs on the firewall to detect
aconable events on your network. The engine correlates a series of related threat events that,
when combined, indicate a likely compromised host on your network or some other higher level
conclusion. It pinpoints areas of risk, such as compromised hosts on the network, allows you
to assess the risk and take acon to prevent exploitaon of network resources. The automated
correlaon engine uses correlaon objects to analyze the logs for paerns and when a match
occurs, it generates a correlated event.
The following models support the automated correlaon engine:

• Panorama—M-Series appliances and virtual appliances
• Automated Correlaon Engine Concepts

• View the Correlated Objects
• Interpret Correlated Events
• Use the Compromised Hosts Widget in the ACC
Automated Correlaon Engine Concepts

The automated correlaon engine uses correlaon objects to analyze the logs for paerns and
when a match occurs, it generates a correlated event.
• Correlaon Object
• Correlated Events
Correlaon Object
A correlaon object is a definion file that specifies paerns to match against, the data sources
to use for the lookups, and me period within which to look for these paerns. A paern is a
boolean structure of condions that queries the following data sources (or logs) on the firewall:
applicaon stascs, traffic, traffic summary, threat summary, threat, data filtering, and URL
filtering. Each paern has a severity rang, and a threshold for the number of mes the paern
match must occur within a defined me limit to indicate malicious acvity. When the match
condions are met, a correlated event is logged.
A correlaon object can connect isolated network events and look for paerns that indicate a
more significant event. These objects idenfy suspicious traffic paerns and network anomalies,
including suspicious IP acvity, known command-and-control acvity, known vulnerability
exploits, or botnet acvity that, when correlated, indicate with a high probability that a host on
the network has been compromised. Correlaon objects are defined and developed by the Palo
Alto Networks Threat Research team, and are delivered with the weekly dynamic updates to
the firewall and Panorama. To obtain new correlaon objects, the firewall must have a Threat
Prevenon license. Panorama requires a support license to get the updates.
Monitoring
The paerns defined in a correlaon object can be stac or dynamic. Correlated objects that
include paerns observed in WildFire are dynamic, and can correlate malware paerns detected
by WildFire with command-and-control acvity iniated by a host that was targeted with the
malware on your network or acvity seen by a Traps protected endpoint on Panorama. For
example, when a host submits a file to the WildFire cloud and the verdict is malicious, the
correlaon object looks for other hosts or clients on the network that exhibit the same behavior
seen in the cloud. If the malware sample had performed a DNS query and browsed to a malware
domain, the correlaon object will parse the logs for a similar event. When the acvity on a host
matches the analysis in the cloud, a high severity correlated event is logged.
Correlated Events
A correlated event is logged when the paerns and thresholds defined in a correlaon object
match the traffic paerns on your network. To Interpret Correlated Events and to view a graphical
display of the events, see Use the Compromised Hosts Widget in the ACC.
View the Correlated Objects

You can view the correlaon objects that are currently available on the firewall.
STEP 1 | Select Monitor > Automated Correlaon Engine > Correlaon Objects. All the objects in the
list are enabled by default.
STEP 2 | View the details on each correlaon object. Each object provides the following informaon:
• Name and Title—The name and tle indicate the type of acvity that the correlaon object
detects. The name column is hidden from view, by default. To view the definion of the
object, unhide the column and click the name link.
• ID— A unique number that idenfies the correlaon object; this column is also hidden by
default. The IDs are in the 6000 series.
• Category—A classificaon of the kind of threat or harm posed to the network, user, or host.
For now, all the objects idenfy compromised hosts on the network.
• State—Indicates whether the correlaon object is enabled (acve) or disabled (inacve). All
the objects in the list are enabled by default, and are hence acve. Because these objects
are based on threat intelligence data and are defined by the Palo Alto Networks Threat
Monitoring
Research team, keep the objects acve in order to track and detect malicious acvity on
your network.
• Descripon—Specifies the match condions for which the firewall or Panorama will analyze
logs. It describes the sequence of condions that are matched on to idenfy acceleraon or
escalaon of malicious acvity or suspicious host behavior. For example, the Compromise
Lifecycle object detects a host involved in a complete aack lifecycle in a three-step
escalaon that starts with scanning or probing acvity, progressing to exploitaon, and
concluding with network contact to a known malicious domain.
For more informaon, see Automated Correlaon Engine Concepts and Use the Automated
Correlaon Engine.
Interpret Correlated Events

You can view and analyze the logs generated for each correlated event in the Monitor >
Automated Correlaon Engine > Correlated Events tab.
Correlated Events includes the following details:
Field Descripon
Match Time The me the correlaon object triggered a match.
Update Time The me when the event was last updated with evidence on the
match. As the firewall collects evidence on paern or sequence
of events defined in a correlaon object, the me stamp on the
correlated event log is updated.
Object Name The name of the correlaon object that triggered the match.
Source Address The IP address of the user/device on your network from which the
traffic originated.
Source User The user and user group informaon from the directory server, if
User-ID is enabled.
Severity A rang that indicates the urgency and impact of the match. The
severity level indicates the extent of damage or escalaon paern,
and the frequency of occurrence. Because correlaon objects are
Monitoring
Field Descripon
To primarily for detecng threats, the correlated events typically relate
configure to idenfying compromised hosts on the network and the severity
the implies the following:
firewall
• Crical—Confirms that a host has been compromised based on
or
correlated events that indicate an escalaon paern. For example,
Panorama
a crical event is logged when a host that received a file with a
to send
malicious verdict by WildFire exhibits the same command-and-
alerts
control acvity that was observed in the WildFire sandbox for that
using
malicious file.
email,
SNMP • High—Indicates that a host is very likely compromised based on
or syslog a correlaon between mulple threat events, such as malware
messages detected anywhere on the network that matches the command-
for a and-control acvity generated by a parcular host.
desired • Medium—Indicates that a host is likely compromised based
severity on the detecon of one or mulple suspicious events, such as
level, repeated visits to known malicious URLs, which suggests a scripted
see Use command-and-control acvity.
External
Services • Low—Indicates that a host is possibly compromised based on the
for detecon of one or mulple suspicious events, such as a visit to a
Monitoring. malicious URL or a dynamic DNS domain.
• Informaonal—Detects an event that may be useful in aggregate
for idenfying suspicious acvity, but the event is not necessarily
significant on its own.
Summary A descripon that summarizes the evidence gathered on the

correlated event.
Click the icon to see the detailed log view, which includes all the evidence on a match:
Monitoring
Tab Descripon
Match Object Details: Presents informaon on the Correlaon Object that triggered the
Informaon match.
Match Details: A summary of the match details that includes the match me, last
update me on the match evidence, severity of the event, and an event summary.
Match Presents all the evidence that corroborates the correlated event. It lists detailed
Evidence informaon on the evidence collected for each session.
Use the Compromised Hosts Widget in the ACC

The compromised hosts widget on ACC > Threat Acvity, aggregates the Correlated Events
and sorts them by severity. It displays the source IP address/user who triggered the event, the
correlaon object that was matched and the number of mes the object was matched. Use the
match count link to jump to the match evidence details.
For more details, see Use the Automated Correlaon Engine and Use the Applicaon Command
Center.
Monitoring
Take Packet Captures

All Palo Alto Networks firewalls allow you to take packet captures (pcaps) of traffic that traverses
the management interface and network interfaces on the firewall. When taking packet captures on
the dataplane, you may need to Disable Hardware Offload to ensure that the firewall captures all
traffic.
Packet capture can be very CPU intensive and can degrade firewall performance. Only
use this feature when necessary and make sure you turn it off aer you have collected the
required packets.
• Types of Packet Captures

• Disable Hardware Offload
• Take a Custom Packet Capture
• Take a Threat Packet Capture
• Take an Applicaon Packet Capture
• Take a Packet Capture on the Management Interface
Types of Packet Captures

There are different types of packet captures you can enable, depending on what you need to do:
• Custom Packet Capture—The firewall captures packets for all traffic or for specific traffic based
on filters that you define. For example, you can configure the firewall to only capture packets to
and from a specific source and desnaon IP address or port. You then use the packet captures
for troubleshoong network#related issues or for gathering applicaon aributes to enable
you to write custom applicaon signatures or to request an applicaon signature from Palo Alto
Networks. See Take a Custom Packet Capture.
• Threat Packet Capture—The firewall captures packets when it detects a virus, spyware, or
vulnerability. You enable this feature in Anvirus, An-Spyware, and Vulnerability Protecon
security profiles. A link to view or export the packet captures will appear in the second column
of the Threat log. These packet captures provide context around a threat to help you determine
if an aack is successful or to learn more about the methods used by an aacker. You can also
submit this type of pcap to Palo Alto Networks to have a threat re-analyzed if you feel it’s a
false-posive or false-negave. See Take a Threat Packet Capture.
• Applicaon Packet Capture—The firewall captures packets based on a specific applicaon
and filters that you define. A link to view or export the packet captures will appear in the
second column of the Traffic logs for traffic that matches the packet capture rule. See Take an
Applicaon Packet Capture.
• Management Interface Packet Capture—The firewall captures packets on the management
interface (MGT). The packet captures are useful when troubleshoong services that traverse
the interface, such as firewall management authencaon to External Authencaon Services,
soware and content updates, log forwarding, communicaon with SNMP servers, and
authencaon requests for GlobalProtect and Authencaon Portal. See Take a Packet Capture
on the Management Interface.
Monitoring
• GTP Event Packet Capture—The firewall captures a single GTP event, such as GTP-in-GTP, end
user IP spoofing, and abnormal GTP messages, to make GTP troubleshoong easier for mobile
network operators. Enable packet capture in a Mobile Network Protecon profile.
Disable Hardware Offload

Packet captures for traffic passing through the network data ports on a Palo Alto Networks
firewall are performed by the dataplane CPU. To capture traffic that passes through the
management interface, you must Take a Packet Capture on the Management Interface, in which
case the packet capture is performed on the management plane.
When a packet capture is performed on the dataplane, the packet capture filter is used differently
by the ingress stage, compared to the firewall, drop, and egress capture stages. The ingress stage
uses the packet capture filter to copy individual packets that match the filter to the capture file.
Packets that fail packet-parsing checks are dropped before being captured. The firewall, drop, and
egress capture stages use the same packet capture filter to mark all new sessions that match the
filter. Because each session, as recorded in the session tables, idenfies both client-to-server and
server-to-client connecons, any traffic, in either direcon, that matches to the flagged session
will be copied to the firewall-stage and transmit-stage capture files. Likewise, any dropped traffic
(post receive stage) in either direcon that matches to a flagged session will be copied to the drop-
stage capture file.
On firewall models that include a network processor, traffic that meets certain pre-determined
criteria by Palo Alto Networks may be offloaded for handling by the network processor. Such
offloaded traffic will not reach the dataplane CPU and will, therefore, not be captured. To capture
offloaded traffic, you must use the CLI to turn off the hardware offload feature.
Common types of traffic that may be offloaded include non-decrypted SSL and SSH traffic (which
being encrypted cannot be usefully inspected beyond the inial SSL/SSH session setup), network
protocols (such as OSPF, BGP, RIP), and traffic that matches an applicaon-override policy. Some
types of traffic will never be offloaded, such as ARP, all non-IP traffic, IPSec, and VPN sessions.
Individual SYN, FIN, and RST packets, even for session traffic that has been offloaded, will never
be offloaded, and will always be passed through to the dataplane CPU, once recognized as such by
the network processor.
Hardware offload is supported on the following firewalls: PA-3200 Series, PA-5200 Series,
and PA-7000 Series firewall.
Disabling hardware offload may increase the dataplane CPU usage. If dataplane CPU
usage is already high, you may want to schedule a maintenance window before disabling
hardware offload.
STEP 1 | Disable hardware offload by running the following CLI command:
admin@PA-7050>set session offload no
STEP 2 | Aer the firewall captures the required traffic, enable hardware offload by running the
following CLI command:
admin@PA-7050>set session offload yes
Monitoring
Take a Custom Packet Capture

Custom packet captures allow you to define the traffic that the firewall will capture. To ensure that
you capture all traffic, you may need to Disable Hardware Offload.
STEP 1 | Before you start a packet capture, idenfy the aributes of the traffic that you want to
capture.
For example, to determine the source IP address, source NAT IP address, and the desnaon
IP address for traffic between two systems, perform a ping from the source system to the to
the desnaon system. Aer the ping is complete, go to Monitor > Traffic and locate the traffic
log for the two systems. Click the Detailed Log View icon located in the first column of the log
and note the source address, source NAT IP, and the desnaon address.
The following example shows how to use a packet capture to troubleshoot a Telnet
connecvity issue from a user in the Trust zone to a server in the DMZ zone.
Monitoring
STEP 2 | Set packet capture filters, so the firewall only captures traffic you are interested in.
Using filters makes it easier for you to locate the informaon you need in the packet capture
and will reduce the processing power required by the firewall to take the packet capture. To
capture all traffic, do not define filters and leave the filter opon off.
For example, if you configured NAT on the firewall, you will need to apply two filters. The first
one filters on the pre-NAT source IP address to the desnaon IP address and the second one
filters traffic from the desnaon server to the source NAT IP address.
1. Select Monitor > Packet Capture.
2. Click Clear All Sengs at the boom of the window to clear any exisng capture
sengs.
3. Click Manage Filters and click Add.
4. Select Id 1 and in the Source field enter the source IP address you are interested in and
in the Desnaon field enter a desnaon IP address.
For example, enter the source IP address 192.168.2.10 and the desnaon IP address
10.43.14.55. To further filter the capture, set Non-IP to exclude non-IP traffic, such as
broadcast traffic.
5. Add the second filter and select Id 2.
For example, in the Source field enter 10.43.14.55 and in the Desnaon field enter
10.43.14.25. In the Non-IP drop-down menu select exclude.
6. Click OK.
STEP 3 | Set Filtering to On.
Monitoring
STEP 4 | Specify the traffic stage(s) that trigger the packet capture and the filename(s) to use to store
the captured content. For a definion of each stage, click the Help icon on the packet capture
page.
For example, to configure all packet capture stages and define a filename for each stage,
perform the following procedure:
1. Add a Stage to the packet capture configuraon and define a File name for the resulng
packet capture.
For example, select receive as the Stage and set the File name to telnet-test-received.
2. Connue to Add each Stage you want to capture (receive, firewall, transmit, and drop)
and set a unique File name for each stage.
STEP 5 | Set Packet Capture to ON.

The firewall or appliance warns you that system performance can be degraded; acknowledge
the warning by clicking OK. If you define filters, the packet capture should have lile impact
on performance, but you should always turn Off packet capture aer the firewall captures the
data that you want to analyze.
STEP 6 | Generate traffic that matches the filters that you defined.
For this example, generate traffic from the source system to the Telnet-enabled server by
running the following command from the source system (192.168.2.10):
telnet 10.43.14.55
Monitoring
STEP 7 | Turn packet capture OFF and then click the refresh icon to see the packet capture files.
Noce that in this case, there were no dropped packets, so the firewall did not create a file for
the drop stage.
STEP 8 | Download the packet captures by clicking the filename in the File Name column.
STEP 9 | View the packet capture files using a network packet analyzer.
In this example, the received.pcap packet capture shows a failed Telnet session from the source
system at 192.168.2.10 to the Telnet-enabled server at 10.43.14.55. The source system sent
the Telnet request to the server, but the server did not respond. In this example, the server may
not have Telnet enabled, so check the server.
STEP 10 | Enable the Telnet service on the desnaon server (10.43.14.55) and turn on packet capture
to take a new packet capture.
STEP 11 | Generate traffic that will trigger the packet capture.

Run the Telnet session again from the source system to the Telnet-enabled server
telnet 10.43.14.55
Monitoring
STEP 12 | Download and open the received.pcap file and view it using a network packet analyzer.
The following packet capture now shows a successful Telnet session from the host user at
192.168.2.10 to the Telnet-enabled server at 10.43.14.55.
You also see the NAT address 10.43.14.25. When the server responds, it does so to
the NAT address. You can see the session is successful as indicated by the three-way
handshake between the host and the server and then you see Telnet data.
Take a Threat Packet Capture

To configure the firewall to take a packet capture (pcap) when it detects a threat, enable packet
capture on Anvirus, An-Spyware, and Vulnerability Protecon security profiles.
Monitoring
STEP 1 | Enable the packet capture opon in the security profile.

Some security profiles allow you to define a single-packet capture or an extended-capture. If
you choose extended-capture, define the capture length. This will allow the firewall to capture
more packets to provide addional context related to the threat.
If the acon for a given threat is allow, the firewall does not trigger a Threat log and
does not capture packets. If the acon is alert, you can set the packet capture to
single-packet or extended-capture. All blocking acons (drop, block, and reset acons)
capture a single packet. The content package on the device determines the default
acon.
1. Select Objects > Security Profiles and enable the packet capture opon for the
supported profiles as follows:
• Anvirus—Select a custom anvirus profile and in the Anvirus tab select the Packet
Capture check box.
• An-Spyware—Select a custom An-Spyware profile, click the DNS Signatures tab
and in the Packet Capture drop-down, select single-packet or extended-capture.
• Vulnerability Protecon—Select a custom Vulnerability Protecon profile and in the
Rules tab, click Add to add a new rule, or select an exisng rule. Set Packet Capture
to single-packet or extended-capture.
If the profile has signature excepons defined, click the Excepons tab and in the
Packet Capture column for a signature, set single-packet or extended-capture.
2. (Oponal) If you selected extended-capture for any of the profiles, define the extended
packet capture length.
1. Select Device > Setup > Content-ID and edit the Content-ID Sengs.
2. In the Extended Packet Capture Length (packets) secon, specify the number of
packets that the firewall will capture (range is 1-50; default is 5).
3. Click OK.
STEP 2 | Add the security profile (with packet capture enabled) to a Security Policy rule.
1. Select Policies > Security and select a rule.
2. Select the Acons tab.
3. In the Profile Sengs secon, select a profile that has packet capture enabled.
For example, click the Anvirus drop-down and select a profile that has packet capture
enabled.
Monitoring
STEP 3 | View/export the packet capture from the Threat logs.

1. Select Monitor > Logs > Threat.
2. In the log entry that you are interested in, click the green packet capture icon in the
second column. View the packet capture directly or Export it to your system.
Take an Applicaon Packet Capture

The following topics describe two ways that you can configure the firewall to take applicaon
packet captures:
• Take a Packet Capture for Unknown Applicaons
• Take a Custom Applicaon Packet Capture
Take a Packet Capture for Unknown Applicaons

Palo Alto Networks firewalls automacally generate a packet capture for sessions that contain an
applicaon that the firewall cannot idenfy. Typically, the only applicaons that are classified as
unknown traffic—tcp, udp, or non-syn-tcp—are commercially available applicaons that do not yet
have App-ID signatures, are internal or custom applicaons on your network, or potenal threats.
You can use these packet captures to gather more context related to the unknown applicaon
or use the informaon to analyze the traffic for potenal threats. You can also Manage Custom
or Unknown Applicaons by controlling them through security policy or by wring a custom
applicaon signature and then creang a security rule based on the custom signature. If the
applicaon is a commercial applicaon, you can submit the packet capture to Palo Alto Networks
to have an App-ID signature created.
STEP 1 | Verify that unknown applicaon packet capture is enabled (this opon is enabled by default).
1. To view the unknown applicaon capture seng, run the following CLI command:
admin@PA-220>show running application setting | match “Unknown

capture”
2. If the unknown capture seng opon is off, enable it:
admin@PA-220>set application dump-unknown yes
Monitoring
STEP 2 | Locate unknown TCP and UDP applicaons by filtering the traffic logs.
1. Select Monitor > Logs > Traffic.
2. Click Add Filter, create the unknown TCP poron of the filter (Connector = “and”,
Aribute = “Applicaon”, Operator = “equal”, and enter “unknown-tcp” as the Value), and
then click Add to add the query to the filter.
3. Create the unknown UDP poron of the filter (Connector = “or”, Aribute =
“Applicaon”, Operator = “equal”, and enter “unknown-udp” as the Value), and then click
Add to add the query to the filter.
4. Click Apply to place the filter in the log screen query field.
STEP 3 | Click the Apply Filter arrow next to the query field to run the filter and then click the packet
capture icon to view the packet capture or Export it to your local system.
Monitoring
Take a Custom Applicaon Packet Capture

You can configure a Palo Alto Networks firewall to take a packet capture based on an applicaon
name and filters that you define. You can then use the packet capture to troubleshoot issues with
controlling an applicaon. When configuring an applicaon packet capture, you must use the
applicaon name defined in the App-ID database. You can view a list of all App-ID applicaons
using Applipedia or from the web interface on the firewall in Objects > Applicaons.
STEP 1 | Using a terminal emulaon applicaon, such as PuTTY, launch an SSH session to the firewall.
STEP 2 | Turn on the applicaon packet capture and define filters.
admin@PA-220>set application dump on application <application-name>

rule <rule-name>
For example, to capture packets for the linkedin-base applicaon that matches the security rule
named Social Networking Apps, run the following CLI command:
admin@PA-220>set application dump on application linkedin-base rule

"Social Networking Apps"
You can also apply other filters, such as source IP address and desnaon IP address.
STEP 3 | View the packet capture output to ensure that the correct filters are applied. The output
displays aer you enable the packet capture.
The following output confirms that applicaon capture filtering is now based on the linkedin-
base applicaon for traffic that matches the Social Networking Apps rule.
STEP 4 | Access linkedin.com from a web browser and perform some LinkedIn tasks to generate
LinkedIn traffic, and then run the following CLI command to turn off applicaon packet
capture:
admin@PA-220>set application dump off
Monitoring
STEP 5 | View/export the packet capture.

1. Log in to the web interface on the firewall and select Monitor > Logs > Traffic.
2. In the log entry that you are interested in, click the green packet capture icon .
3. View the packet capture directly or Export it to your computer. The following screen
capture shows the linkedin-base packet capture.
Take a Packet Capture on the Management Interface

The tcpdump CLI command enables you to capture packets that traverse the management
interface (MGT) on a Palo Alto Networks firewall.
Each plaorm has a default number of bytes that tcpdump captures. The PA-220
firewalls capture 68 bytes of data from each packet and anything over that is truncated.
The PA-7000 Series firewalls and VM-Series firewalls capture 96 bytes of data from each
packet. To define the number of packets that tcpdump will capture, use the snaplen
(snap length) opon (range 0-65535). Seng the snaplen to 0 will cause the firewall to
use the maximum length required to capture whole packets.
STEP 1 | Using a terminal emulaon applicaon, such as PuTTY, launch an SSH session to the firewall.
Monitoring
STEP 2 | To start a packet capture on the MGT interface, run the following command:
admin@PA-220>tcpdump filter “<filter-option> <IP-address>” snaplen

length
For example, to capture the traffic that is generated when and administrator authencates
to the firewall using RADIUS, filter on the desnaon IP address of the RADIUS server
(10.5.104.99 in this example):
admin@PA-220>tcpdump filter “dst 10.5.104.99” snaplen 0
You can also filter on src (source IP address), host, net, and you can exclude content. For
example, to filter on a subnet and exclude all SCP, SFTP, and SSH traffic (which uses port 22),
run the following command:
admin@PA-220>tcpdump filter “net 10.5.104.0/24 and not port 22”

snaplen 0
Each me tcpdump takes a packet capture, it stores the content in a file named
mgmt.pcap. This file is overwrien each me you run tcpdump.
STEP 3 | Aer the traffic you are interested in has traversed the MGT interface, press Ctrl + C to stop
the capture.
STEP 4 | View the packet capture by running the following command:
admin@PA-220> view-pcap mgmt-pcap mgmt.pcap
The following output shows the packet capture from the MGT port (10.5.104.98) to the
RADIUS server (10.5.104.99):
09:55:29.139394 IP 10.5.104.98.43063 > 10.5.104.99.radius: RADIUS,

Access Request (1), id: 0x00 length: 89
09:55:29.144354 arp reply 10.5.104.98 is-at 00:25:90:23:94:98 (oui
Unknown)
09:55:29.379290 IP 10.5.104.98.43063 > 10.5.104.99.radius: RADIUS,
Access Request (1), id: 0x00 length: 70
09:55:34.379262 arp who-has 10.5.104.99 tell 10.5.104.98
Monitoring
STEP 5 | (Oponal) Export the packet capture from the firewall using SCP (or TFTP). For example, to
export the packet capture using SCP, run the following command:
admin@PA-220>scp export mgmt-pcap from mgmt.pcap

to <username@host:path>
For example, to export the pcap to an SCP enabled server at 10.5.5.20 to a temp folder named
temp-SCP, run the following CLI command:
admin@PA-220>scp export mgmt-pcap from mgmt.pcap to

[email protected]:c:/temp-SCP
Enter the login name and password for the account on the SCP server to enable the firewall to
copy the packet capture to the c:\temp-SCP folder on the SCP-enabled.
STEP 6 | You can now view the packet capture files using a network packet analyzer, such as
Wireshark.
Monitoring
Monitor Applicaons and Threats

All Palo Alto Networks next-generaon firewalls come equipped with the App-ID technology,
which idenfies the applicaons traversing your network, irrespecve of protocol, encrypon, or
evasive tacc. You can then Use the Applicaon Command Center to monitor the applicaons.
The ACC graphically summarizes the data from a variety of log databases to highlight the
applicaons traversing your network, who is using them, and their potenal security impact. ACC
is dynamically updated, using the connuous traffic classificaon that App-ID performs; if an
applicaon changes ports or behavior, App-ID connues to see the traffic, displaying the results
in ACC. Addional visibility into URL categories, threats, and data provides a complete and well-
rounded picture of network acvity. With ACC, you can very quickly learn more about the traffic
traversing the network and then translate that informaon into a more informed security policy
You can also Use the Dashboard to monitor the network.
Review the Content Delivery Network Infrastructure to check whether logged events on the
firewall pose a security risk. The AutoFocus intelligence summary shows the prevalence of
properes, acvies, or behaviors associated with logs in your network and on a global scale,
as well as the WildFire verdict and AutoFocus tags linked to them. With an acve AutoFocus
subscripon, you can use this informaon to create customized AutoFocus Alerts that track
specific threats on your network.
Monitoring
View and Manage Logs

A log is an automacally generated, me-stamped file that provides an audit trail for system
events on the firewall or network traffic events that the firewall monitors. Log entries contain
arfacts, which are properes, acvies, or behaviors associated with the logged event, such
as the applicaon type or the IP address of an aacker. Each log type records informaon for a
separate event type. For example, the firewall generates a Threat log to record traffic that matches
a spyware, vulnerability, or virus signature or a DoS aack that matches the thresholds configured
for a port scan or host sweep acvity on the firewall.
• Log Types and Severity Levels
• View Logs
• Filter Logs
• Export Logs
• Configure Log Storage Quotas and Expiraon Periods
• Schedule Log Exports to an SCP or FTP Server
Log Types and Severity Levels

You can see the following log types in the Monitor > Logs pages.
• Traffic Logs
• Threat Logs
• URL Filtering Logs
• WildFire Submissions Logs
• Data Filtering Logs
• Correlaon Logs
• Tunnel Inspecon Logs
• Config Logs
• System Logs
• HIP Match Logs
• GlobalProtect Logs
• IP-Tag Logs
• User-ID Logs
• Decrypon Logs
• Alarms Logs
• Authencaon Logs
• Unified Logs
Monitoring
Traffic Logs
Traffic logs display an entry for the start and end of each session. Each entry includes the
following informaon: date and me; source and desnaon zones, source and desnaon
dynamic address groups, addresses and ports; applicaon name; security rule applied to the traffic
flow; rule acon (allow, deny, or drop); ingress and egress interface; number of bytes; and session
end reason.
A dynamic address group only appears in a log if the rule the traffic matches includes a
dynamic address group. If an IP address appears in more than one dynamic address group,
the firewall displays up to five dynamic address groups in logs along with the source IP
address
The Type column indicates whether the entry is for the start or end of the session. The Acon
column indicates whether the firewall allowed, denied, or dropped the session. A drop indicates
the security rule that blocked the traffic specified any applicaon, while a deny indicates the rule
idenfied a specific applicaon. If the firewall drops traffic before idenfying the applicaon,
such as when a rule drops all traffic for a specific service, the Applicaon column displays not-
applicable.
Click beside an entry to view addional details about the session, such as whether an ICMP
entry aggregates mulple sessions between the same source and desnaon (in which case the
Count column value is greater than one).
When the Decrypon log introduced in PAN-OS 10.1 is disabled, the firewall sends
HTTP/2 logs as Traffic logs. However, when the Decrypon logs are enabled, the firewall
sends HTTP/2 logs as Tunnel Inspecon logs (when Decrypon logs are disabled, HTTP/2
logs are sent as Traffic logs), so you need to check the Tunnel Inspecon logs instead of the
Traffic logs for HTTP/2 events.
Threat Logs
Threat logs display entries when traffic matches one of the Security Profiles aached to a security
rule on the firewall. Each entry includes the following informaon: date and me; type of threat
(such as virus or spyware); threat descripon or URL (Name column); source and desnaon
zones, addresses, source and desnaon dynamic address groups, and ports; applicaon name;
alarm acon (such as allow or block); and severity level.
A dynamic address group only appears in a log if the rule the traffic matches includes a
dynamic address group. If an IP address appears in more than one dynamic address group,
the firewall displays up to five dynamic address groups in logs along with the source IP
address
To see more details on individual Threat log entries:

• Click beside a threat entry to view details such as whether the entry aggregates mulple
threats of the same type between the same source and desnaon (in which case the Count
column value is greater than one).
• If you configured the firewall to Take Packet Captures, click beside an entry to access the
captured packets.
The following table summarizes the Threat severity levels:
Monitoring
Severity Descripon
Crical Serious threats, such as those that affect default installaons of widely
deployed soware, result in root compromise of servers, and the exploit code
is widely available to aackers. The aacker usually does not need any special
authencaon credenals or knowledge about the individual vicms and the
target does not need to be manipulated into performing any special funcons.
High Threats that have the ability to become crical but have migang factors; for
example, they may be difficult to exploit, do not result in elevated privileges, or do
not have a large vicm pool.
WildFire Submissions log entries with a malicious verdict and an acon set to allow
are logged as High.
Medium Minor threats in which impact is minimized, such as DoS aacks that do not
compromise the target or exploits that require an aacker to reside on the same
LAN as the vicm, affect only non-standard configuraons or obscure applicaons,
or provide very limited access.
• Threat log entries with a malicious verdict and an acon of block or alert, based
on the exisng WildFire signature severity, are logged as Medium.
Low Warning-level threats that have very lile impact on an organizaon's

infrastructure. They usually require local or physical system access and may oen
result in vicm privacy or DoS issues and informaon leakage.
• Data Filtering profile matches are logged as Low.
• WildFire Submissions log entries with a grayware verdict and any acon are
logged as Low.
InformaonalSuspicious events that do not pose an immediate threat, but that are reported to
call aenon to deeper problems that could possibly exist.
• URL Filtering log entries are logged as Informaonal.
• WildFire Submissions log entries with a benign verdict and any acon are
logged as Informaonal.
• WildFire Submissions log entries with any verdict and an acon set to block and
forward are logged as Informaonal.
• Log entries with any verdict and an acon set to block are logged as
Informaonal.
URL Filtering Logs

URL Filtering logs display entries for traffic that matches either URL Filtering profiles aached to
Security policy rules or URL categories used as match criteria in Security policy rules. For example,
the firewall generates a log if a rule blocks access to specific websites and URL categories or if you
configured a rule to generate an alert when a user accesses a website.
Monitoring
WildFire Submissions Logs

The firewall forwards samples (files and emails links) to the WildFire cloud for analysis based on
WildFire Analysis profiles sengs (Objects > Security Profiles > WildFire Analysis). The firewall
generates WildFire Submissions log entries for each sample it forwards aer WildFire completes
stac and dynamic analysis of the sample. WildFire Submissions log entries include the firewall
Acon for the sample (allow or block), the WildFire verdict for the submied sample, and the
severity level of the sample.
The following table summarizes the WildFire verdicts:
Verdict Descripon
Benign Indicates that the entry received a WildFire analysis verdict of benign. Files
categorized as benign are safe and do not exhibit malicious behavior.
Grayware Indicates that the entry received a WildFire analysis verdict of grayware. Files
categorized as grayware do not pose a direct security threat, but might display
otherwise obtrusive behavior. Grayware can include, adware, spyware, and
Browser Helper Objects (BHOs).
Phishing Indicates that WildFire assigned a link an analysis verdict of phishing. A phishing
verdict indicates that the site to which the link directs users displayed credenal
phishing acvity.
Malicious Indicates that the entry received a WildFire analysis verdict of malicious. Samples
categorized as malicious are can pose a security threat. Malware can include
viruses, C2 (command-and-control), worms, Trojans, Remote Access Tools (RATs),
rootkits, and botnets. For samples that are idenfied as malware, the WildFire
cloud generates and distributes a signature to prevent against future exposure.
C2 samples are classified as C2 in the WildFire analysis report and

other Palo Alto Networks products that rely on WildFire analysis data;
however, that verdict is translated and categorized as malicious by the
firewall.
Data Filtering Logs

Data Filtering logs display entries for the security rules that help prevent sensive informaon
such as credit card numbers from leaving the area that the firewall protects. See Data Filtering for
informaon on defining Data Filtering profiles.
This log type also shows informaon for File Blocking Profiles. For example, if a rule blocks .exe
files, the log shows the blocked files.
Correlaon Logs
The firewall logs a correlated event when the paerns and thresholds defined in a Correlaon
Object match the traffic paerns on your network. To Interpret Correlated Events and view a
graphical display of the events, see Use the Compromised Hosts Widget in the ACC.
Monitoring
The following table summarizes the Correlaon log severity levels:
Crical Confirms that a host has been compromised based on correlated events that
indicate an escalaon paern. For example, a crical event is logged when a
host that received a file with a malicious verdict by WildFire, exhibits the same
command-and control acvity that was observed in the WildFire sandbox for that
malicious file.
High Indicates that a host is very likely compromised based on a correlaon between
mulple threat events, such as malware detected anywhere on the network that
matches the command and control acvity being generated from a parcular
host.
Medium Indicates that a host is likely compromised based on the detecon of one or
mulple suspicious events, such as repeated visits to known malicious URLs that
suggests a scripted command-and-control acvity.
Low Indicates that a host is possibly compromised based on the detecon of one or
mulple suspicious events, such as a visit to a malicious URL or a dynamic DNS
domain.
InformaonalDetects an event that may be useful in aggregate for idenfying suspicious

acvity; each event is not necessarily significant on its own.
Tunnel Inspecon Logs

Tunnel inspecon logs are like traffic logs for tunnel sessions; they display entries of non-
encrypted tunnel sessions. To prevent double counng, the firewall saves only the inner flows
in traffic logs, and sends tunnel sessions to the tunnel inspecon logs. The tunnel inspecon
log entries include Receive Time (date and me the log was received), the tunnel ID, monitor
tag, session ID, the Security rule applied to the tunnel session, number of bytes in the session,
parent session ID (session ID for the tunnel session), source address, source user and source zone,
desnaon address, desnaon user, and desnaon zone.
When the Decrypon logs introduced in PAN-OS 10.1 are enabled, the firewall sends
HTTP/2 logs as Tunnel Inspecon logs (when Decrypon logs are disabled, HTTP/2
logs are sent as Traffic logs), so you need to check the Tunnel Inspecon logs instead of
the Traffic logs for HTTP/2 events. In this case, you must also enable Tunnel Content
Inspecon to obtain the App-ID for HTTP/2 traffic.
Click the Detailed Log view to see details for an entry, such as the tunnel protocol used, and the
flag indicang whether the tunnel content was inspected or not. Only a session that has a parent
session will have the Tunnel Inspected flag set, which means the session is in a tunnel-in-tunnel
(two levels of encapsulaon). The first outer header of a tunnel will not have the Tunnel Inspected
flag set.
Monitoring
Config Logs
Config logs display entries for changes to the firewall configuraon. Each entry includes the date
and me, the administrator username, the IP address from where the administrator made the
change, the type of client (Web, CLI, or Panorama), the type of command executed, the command
status (succeeded or failed), the configuraon path, and the values before and aer the change.
System Logs
System logs display entries for each system event on the firewall. Each entry includes the date
and me, event severity, and event descripon. The following table summarizes the System log
severity levels. For a paral list of System log messages and their corresponding severity levels,
refer to System Log Events.
Crical Hardware failures, including high availability (HA) failover and link failures.
High Serious issues, including dropped connecons with external devices, such as LDAP
and RADIUS servers.
Medium Mid-level noficaons, such as anvirus package upgrades.
Low Minor severity noficaons, such as user password changes.
InformaonalLog in/log off, administrator name or password change, any configuraon change,
and all other events not covered by the other severity levels.
HIP Match Logs

The GlobalProtect Host Informaon Profile (HIP) matching enables you to collect informaon
about the security status of the end devices accessing your network (such as whether they
have disk encrypon enabled). The firewall can allow or deny access to a specific host based on
adherence to the HIP-based security rules you define. HIP Match logs display traffic flows that
match a HIP Object or HIP Profile that you configured for the rules.
GlobalProtect Logs
GlobalProtect logs display the following logs related to GlobalProtect:
• GlobalProtect system logs.
GlobalProtect authencaon event logs remain in Monitor > Logs > System; however, the
Auth Method column of the GlobalProtect logs display the authencaon method used for
logins.
• LSVPN/satellite events.
• GlobalProtect portal and gateway logs.
• Clientless VPN logs.
Monitoring
IP-Tag Logs
IP-tag logs display how and when a source IP address is registered or unregistered on the
firewall and what tag the firewall applied to the address. Addionally, each log entry displays
the configured meout (when configured) and the source of the IP address-to-tag mapping
informaon, such as User-ID agent VM informaon sources and auto-tagging. See how to Register
IP Address and Tags Dynamically for more informaon.
User-ID Logs
User-ID logs display informaon about IP address-to-username mappings and Authencaon
Timestamps, such as the sources of the mapping informaon and the mes when users
authencated. You can use this informaon to help troubleshoot User-ID and authencaon
issues. For example, if the firewall is applying the wrong policy rule for a user, you can view the
logs to verify whether that user is mapped to the correct IP address and whether the group
associaons are correct.
Decrypon Logs
Decrypon Logs display entries for unsuccessful TLS handshakes by default and can display
entries for successful TLS handshakes if you enable them in Decrypon policy. If you enable
entries for successful handshakes, ensure that you have the system resources (log space) for the
logs.
Decrypon logs include a vast amount of informaon to help you Troubleshoot and Monitor
Decrypon and then resolve issues. There are 62 columns of different types of informaon you
can enable in the logs, and you can select any individual log ( , the magnifying glass) and see
the details in a single Detail view. You can view cerficate, cipher suite, and error informaon
such as: subject common name, issuer common name, root common name, root status, cerficate
key type and size, cerficate start and end date, cerficate serial number, cerficate fingerprint,
TLS version, key exchange algorithm, encrypon algorithm, negoated EC curve, authencaon
algorithm, SNI, proxy type, errors informaon (cipher, HSM, resource, resume, protocol, feature,
cerficate, version), and error indexes (codes that you can look up to get more error informaon).
Alarms Logs
An alarm is a firewall-generated message indicang that the number of events of a parcular type
(for example, encrypon and decrypon failures) has exceeded the threshold configured for that
event type. To enable alarms and configure alarm thresholds, select Device > Log Sengs and edit
the Alarm Sengs.
When generang an alarm, the firewall creates an Alarm log and opens the System Alarms dialog
to display the alarm. Aer you Close the dialog, you can reopen it anyme by clicking Alarms ( )
at the boom of the web interface. To prevent the firewall from automacally opening the dialog
for a parcular alarm, select the alarm in the Unacknowledged Alarms list and Acknowledge the
alarm.
Authencaon Logs
Authencaon logs display informaon about authencaon events that occur when end users
try to access network resources for which access is controlled by Authencaon Policy rules. You
can use this informaon to help troubleshoot access issues and to adjust your Authencaon
Monitoring
policy as needed. In conjuncon with correlaon objects, you can also use Authencaon logs to
idenfy suspicious acvity on your network, such as brute force aacks.
Oponally, you can configure Authencaon rules to log meout events. These meouts relate to
the period when a user need authencate for a resource only once but can access it repeatedly.
Seeing informaon about the meouts helps you decide if and how to adjust them (for details, see
Authencaon Timestamps).
System logs record authencaon events relang to GlobalProtect and to administrator

access to the web interface.
Unified Logs
Unified logs are entries from the Traffic, Threat, URL Filtering, WildFire Submissions, and Data
Filtering logs displayed in a single view. Unified log view enables you to invesgate and filter the
latest entries from different log types in one place, instead of searching through each log type
separately. Click Effecve Queries ( ) in the filter area to select which log types will display
entries in Unified log view.
The Unified log view displays only entries from logs that you have permission to see. For example,
an administrator who does not have permission to view WildFire Submissions logs will not see
WildFire Submissions log entries when viewing Unified logs. Administrave Role Types define
these permissions.
When you Set Up Remote Search in AutoFocus to perform a targeted search on the
firewall, the search results are displayed in Unified log view.
View Logs
You can view the different log types on the firewall in a tabular format. The firewall locally stores
all log files and automacally generates Configuraon and System logs by default. To learn more
about the security rules that trigger the creaon of entries for the other types of logs, see Log
Types and Severity Levels.
To configure the firewall to forward logs as syslog messages, email noficaons, or Simple
Network Management Protocol (SNMP) traps, Use External Services for Monitoring.
STEP 1 | Select a log type to view.
1. Select Monitor > Logs.
2. Select a log type from the list.
The firewall displays only the logs you have permission to see. For example,
if your administrave account does not have permission to view WildFire
Submissions logs, the firewall does not display that log type when you access the
logs pages. Administrave Role Types define the permissions.
STEP 2 | (Oponal) Customize the log column display.

1. Click the arrow to the right of any column header, and select Columns.
2. Select columns to display from the list. The log updates automacally to match your
selecons.
Monitoring
STEP 3 | View addional details about log entries.

• Click the spyglass ( ) for a specific log entry. The Detailed Log View has more informaon
about the source and desnaon of the session, as well as a list of sessions related to the
log entry.
• (Threat log only) Click next to an entry to access local packet captures of the threat. To
enable local packet captures, see Take Packet Captures.
• (Traffic, Threat, URL Filtering, WildFire Submissions, Data Filtering, and Unified logs only)
View AutoFocus threat data for a log entry.
1. Enable AutoFocus Threat Intelligence.
Enable AutoFocus in Panorama to view AutoFocus threat data for all Panorama
log entries, including those from firewalls that are not connected to AutoFocus
and/or are running PAN-OS 7.0 and earlier release versions (Panorama > Setup
> Management > AutoFocus).
2. Hover over an IP address, URL, user agent, threat name (subtype: virus and wildfire-virus
only), filename, or SHA-256 hash.
3. Click the drop-down ( ) and select AutoFocus.
4. Content Delivery Network Infrastructure.
Next Steps...
• Filter Logs.
• Export Logs.
• Configure Log Storage Quotas and Expiraon Periods.
Filter Logs
Each log has a filter area that allows you to set a criteria for which log entries to display. The
ability to filter logs is useful for focusing on events on your firewall that possess parcular
properes or aributes. Filter logs by arfacts that are associated with individual log entries.
For example, filtering by the rule UUID makes it easier to pinpoint the specific rule you want to
locate, even among many similarly-named rules. If your ruleset is very large and contains many
rules, using the rule’s UUID as a filter spotlights the parcular rule you need to find without having
to navigate through pages of results.
STEP 1 | (Unified logs only) Select the log types to include in the Unified log display.
1. Click Effecve Queries ( ).
2. Select one or more log types from the list (traffic, threat, url, data, and wildfire).
3. Click OK. The Unified log updates to show only entries from the log types you have
selected.
Monitoring
STEP 2 | Add a filter to the filter field.
If the value of the arfact matches the operator (such as has or in), enclose the value
in quotaon marks to avoid a syntax error. For example, if you filter by desnaon
country and use IN as a value to specify INDIA, enter the filter as ( dstloc eq
“IN” ).
• Click one or more arfacts (such as the applicaon type associated with traffic and the
IP address of an aacker) in a log entry. For example, click the Source 10.0.0.25 and
Applicaon web-browsing of a log entry to display only entries that contain both arfacts in
the log (AND search).
• To specify arfacts to add to the filter field, click Add Filter ( ).
• To add a previously saved filter, click Load Filter ( ).
STEP 3 | Apply the filter to the log.

Click Apply Filter ( ). The log will refresh to display only log entries that match the current
filter.
STEP 4 | (Oponal) Save frequently used filters.

1. Click Save Filter ( ).
2. Enter a Name for the filter.
3. Click OK. You can view your saved filters by clicking Load Filter ( ).
Next Steps...
• View Logs.
• Export Logs.
Export Logs
You can export the contents of a log type to a comma-separated value (CSV) formaed report. By
default, the report contains up to 2,000 rows of log entries.
STEP 1 | Set the number of rows to display in the report.
1. Select Device > Setup > Management, then edit the Logging and Reporng Sengs.
2. Click the Log Export and Reporng tab.
3. Edit the number of Max Rows in CSV Export (up to 1048576 rows).
4. Click OK.
STEP 2 | Download the log.

1. Click Export to CSV ( ). A progress bar showing the status of the download appears.
2. When the download is complete, click Download file to save a copy of the log to your
local folder. For descripons of the column headers in a downloaded log, refer to Syslog
Field Descripons.
Next Step...
Schedule Log Exports to an SCP or FTP Server.
Monitoring
Configure Log Storage Quotas and Expiraon Periods

The firewall automacally deletes logs that exceed the expiraon period. When the firewall
reaches the storage quota for a log type, it automacally deletes older logs of that type to create
space even if you don’t set an expiraon period.
If you want to manually delete logs, select Device > Log Sengs and, in the Manage Logs
secon, click the links to clear logs by type.
STEP 1 | Select Device > Setup > Management and edit the Logging and Reporng Sengs.
STEP 2 | Select Log Storage and enter a Quota (%) for each log type. When you change a percentage
value, the dialog refreshes to display the corresponding absolute value (Quota GB/MB
column).
STEP 3 | Enter the Max Days (expiraon period) for each log type (range is 1-2,000). The fields are
blank by default, which means the logs never expire.
The firewall synchronizes expiraon periods across high availability (HA) pairs. Because
only the acve HA peer generates logs, the passive peer has no logs to delete unless
failover occurs and it starts generang logs.
Schedule Log Exports to an SCP or FTP Server

You can schedule exports of Traffic, Threat, URL Filtering, Data Filtering, HIP Match, and WildFire
Submission logs to a Secure Copy (SCP) server or File Transfer Protocol (FTP) server. Perform this
task for each log type you want to export.
You can use Secure Copy (SCP) commands from the CLI to export the enre log
database to an SCP server and import it to another firewall. Because the log database is
too large for an export or import to be praccal on the following plaorms, they do not
support these opons: PA-7000 Series firewalls (all PAN-OS releases), Panorama virtual
appliance running Panorama 6.0 or later releases, and Panorama M-Series appliances (all
Panorama releases).
STEP 1 | Select Device > Scheduled Log Export and click Add.
STEP 2 | Enter a Name for the scheduled log export and Enable it.
STEP 3 | Select the Log Type to export.
STEP 4 | Select the daily Scheduled Export Start Time. The opons are in 15-minute increments for a
24-hour clock (00:00 - 23:59).
STEP 5 | Select the Protocol to export the logs: SCP (secure) or FTP.
STEP 6 | Enter the Hostname or IP address of the server.
STEP 7 | Enter the Port number. By default, FTP uses port 21 and SCP uses port 22.
Monitoring
STEP 8 | Enter the Path or directory in which to save the exported logs.
STEP 9 | Enter the Username and, if necessary, the Password (and Confirm Password) to access the
server.
STEP 10 | (FTP only) Select Enable FTP Passive Mode if you want to use FTP passive mode, in which
the firewall iniates a data connecon with the FTP server. By default, the firewall uses FTP
acve mode, in which the FTP server iniates a data connecon with the firewall. Choose
the mode based on what your FTP server supports and on your network requirements.
STEP 11 | (SCP only) Click Test SCP server connecon. Before establishing a connecon, the firewall
must accept the host key for the SCP server.
If you use a Panorama template to configure the log export schedule, you must
perform this step aer comming the template configuraon to the firewalls. Aer the
template commit, log in to each firewall, open the log export schedule, and click Test
SCP server connecon.
Monitoring
Monitor Block List

There are two ways you can cause the firewall to place an IP address on the block list:
• Configure a Vulnerability Protecon profile with a rule to Block IP connecons and apply the
profile to a Security policy, which you apply to a zone.
• Configure a DoS Protecon policy rule with the Protect acon and a Classified DoS Protecon
profile, which specifies a maximum rate of connecons per second allowed. When incoming
packets match the DoS Protecon policy and exceed the Max Rate, and if you specified a
Block Duraon and a Classified policy rule to include source IP address, the firewall puts the
offending source IP address on the block list.
In the cases described above, the firewall automacally blocks that traffic in hardware before
those packets use CPU or packet buffer resources. If aack traffic exceeds the blocking capacity
of the hardware, the firewall uses IP blocking mechanisms in soware to block the traffic.
The firewall automacally creates a hardware block list entry based on your Vulnerability
Protecon profile or DoS Protecon policy rule; the source address from the rule is the source IP
address in the hardware block list.
Entries on the block list indicate in the Type column whether they were blocked by hardware (hw)
or soware (sw). The boom of the screen displays:
• Count of Total Blocked IPs out of the number of blocked IP addresses the firewall supports.
• Percentage of the block list that the firewall has used.
To view details about an address on the block list, hover over a Source IP address and click the
down arrow link. Click the Who Is link, which displays the Network Soluons Who Is feature,
providing informaon about the address.
For informaon on configuring a Vulnerability Protecon profile, see Customize the Acon
and Trigger Condions for a Brute Force Signature. For more informaon on block list and DoS
Protecon profiles, see DoS Protecon Against Flooding of New Sessions.
Monitoring
View and Manage Reports

The reporng capabilies on the firewall allow you to keep a pulse on your network, validate your
policies, and focus your efforts on maintaining network security for keeping your users safe and
producve.
• Report Types
• View Reports
• Configure the Expiraon Period and Run Time for Reports
• Disable Predefined Reports
• Custom Reports
• Generate Custom Reports
• Generate Botnet Reports
• Generate the SaaS Applicaon Usage Report
• Manage PDF Summary Reports
• Generate User/Group Acvity Reports
• Manage Report Groups
• Schedule Reports for Email Delivery
• Manage Report Storage Capacity
Report Types
The firewall includes predefined reports that you can use as-is, or you can build custom reports
that meet your needs for specific data and aconable tasks, or you can combine predefined and
custom reports to compile informaon you need. The firewall provides the following types of
reports:
• Predefined Reports—Allow you to view a quick summary of the traffic on your network. A suite
of predefined reports are available in four categories—Applicaons, Traffic, Threat, and URL
Filtering. See View Reports.
• User or Group Acvity Reports—Allow you to schedule or create an on-demand report on the
applicaon use and URL acvity for a specific user or for a user group. The report includes the
URL categories and an esmated browse me calculaon for individual users. See Generate
User/Group Acvity Reports.
• Custom Reports—Create and schedule custom reports that show exactly the informaon
you want to see by filtering on condions and columns to include. You can also include query
builders for more specific drill down on report data. See Generate Custom Reports.
• PDF Summary Reports—Aggregate up to 18 predefined or custom reports/graphs from Threat,
Applicaon, Trend, Traffic, and URL Filtering categories into one PDF document. See Manage
PDF Summary Reports.
• Botnet Reports—Allow you to use behavior-based mechanisms to idenfy potenal botnet-
infected hosts in the network. See Generate Botnet Reports.
Monitoring
• Report Groups—Combine custom and predefined reports into report groups and compile a
single PDF that is emailed to one or more recipients. See Manage Report Groups.
Reports can be generated on demand, on a recurring schedule, and can be scheduled for email
delivery.
View Reports
The firewall provides an assortment of over 40 predefined reports that it generates every day. You
can view these reports directly on the firewall. You can also view custom reports and summary
reports.
About 200 MB of storage is allocated for saving reports on the firewall. This limit can be
reconfigured for PA-7000 series and PA-5200 series firewalls only. For all other firewall models,
you can Configure the Expiraon Period and Run Time for Reports to allow the firewall to delete
reports that exceed the period. Keep in mind that when the firewall reaches its storage limit, it
automacally deletes older reports to create space even if you don’t set an expiraon period.
Another way to conserve system resources on the firewall is to Disable Predefined Reports. For
long-term retenon of reports, you can export the reports (as described below) or Schedule
Reports for Email Delivery.
Unlike other reports, you can’t save User/Group Acvity reports on the firewall. You must
Generate User/Group Acvity Reports on demand or schedule them for email delivery.
STEP 1 | (VM-50, VM-50 Lite, and PA-200 firewalls only) Enable generaon of predefined reports.
By default, predefined reports are disabled on VM-50, VM-50 Lite, and PA-200
firewalls to save resources.
1. Select Device > Setup > Management and edit Logging and Reporng.
2. Select Pre-Defined Reports and enable (check) Pre-Defined Reports.
3. Check (enable) the predefined reports you want to generate and click OK
5. Access the firewall CLI to enable predefined reports.
This step is required for local predefined reports and predefined reports pushed from a
Panorama™ management server.
admin> debug predefined-default enable
STEP 2 | Select Monitor > Reports.

The reports are grouped into secons (types) on the right-hand side of the page: Custom
Reports, Applicaon Reports, Traffic Reports, Threat Reports, URL Filtering Reports, and PDF
Summary Reports.
STEP 3 | Select a report to view. The reports page then displays the report for the previous day.
To view reports for other days, select a date in the calendar at the boom right of the page and
select a report. If you select a report in another secon, the date selecon resets to the current
date.
Monitoring
STEP 4 | To view a report offline, you can export the report to PDF, CSV or to XML formats. Click
Export to PDF, Export to CSV, or Export to XML at the boom of the page, then print or
save the file.
Configure the Expiraon Period and Run Time for Reports

The expiraon period and run me are global sengs that apply to all Report Types. Aer running
new reports, the firewall automacally deletes reports that exceed the expiraon period.
STEP 1 | Select Device > Setup > Management, edit the Logging and Reporng Sengs, and select
the Log Export and Reporng tab.
STEP 2 | Set the Report Runme to an hour in the 24-hour clock schedule (default is 02:00; range is
00:00 [midnight] to 23:00).
STEP 3 | Enter the Report Expiraon Period in days (default is no expiraon; range is 1 is 2,000).
You can’t change the storage that the firewall allocates for saving reports: it is
predefined at about 200 MB. When the firewall reaches the storage maximum, it
automacally deletes older reports to create space even if you don’t set a Report
Expiraon Period.
Disable Predefined Reports

The firewall includes about 40 predefined reports that it automacally generates daily. If you do
not use some or all of these, you can disable selected reports to conserve system resources on the
firewall.
Make sure that no report group or PDF summary report includes the predefined reports you will
disable. Otherwise, the firewall will render the PDF summary report or report group without any
data.
STEP 1 | Select Device > Setup > Management and edit the Logging and Reporng Sengs.
STEP 2 | Select the Pre-Defined Reports tab and clear the check box for each report you want to
disable. To disable all predefined reports, click Deselect All.
Custom Reports
In order to create purposeful custom reports, you must consider the aributes or key pieces of
informaon that you want to retrieve and analyze, such as threats, as well as the best way to
categorize the informaon, such as grouping by rule UUID, which will allow you to see the rule
that applies to each threat type. This consideraon guides you in making the following selecons
in a custom report:
Monitoring
Selecon Descripon
Database You can base the report on one of the following database types:
• Summary databases—These databases are available for Applicaon
Stascs, Traffic, Threat, URL Filtering, and Tunnel Inspecon logs.
The firewall aggregates the detailed logs at 15-minute intervals. To
enable faster response me when generang reports, the firewall
condenses the data: duplicate sessions are grouped and incremented
with a repeat counter, and some aributes (columns) are excluded
from the summary.
• Detailed logs—These databases itemize the logs and list all the
aributes (columns) for each log entry.
Reports based on detailed logs take much longer to run and

are not recommended unless absolutely necessary.
Aributes The columns that you want to use as the match criteria. The aributes
are the columns that are available for selecon in a report. From the list
of Available Columns, you can add the selecon criteria for matching
data and for aggregang the details (the Selected Columns).
Sort By/ Group By The Sort By and the Group By criteria allow you to organize/segment
the data in the report; the sorng and grouping aributes available vary
based on the selected data source.
The Sort By opon specifies the aribute that is used for aggregaon. If
you do not select an aribute to sort by, the report will return the first
N number of results without any aggregaon.
The Group By opon allows you to select an aribute and use it as an
anchor for grouping data; all the data in the report is then presented in
a set of top 5, 10, 25 or 50 groups. For example, when you select Hour
as the Group By selecon and want the top 25 groups for a 24-hr me
period, the results of the report will be generated on an hourly basis
over a 24-hr period. The first column in the report will be the hour and
the next set of columns will be the rest of your selected report columns.
The following example illustrates how the Selected Columns and Sort
By/Group By criteria work together when generang reports:
Monitoring
The columns circled in red (above) depict the columns selected, which
are the aributes that you match against for generang the report.
Each log entry from the data source is parsed and these columns are
matched on. If mulple sessions have the same values for the selected
columns, the sessions are aggregated and the repeat count (or sessions)
is incremented.
The column circled in blue indicates the chosen sort order. When the
sort order (Sort By) is specified, the data is sorted (and aggregated) by
the selected aribute.
The column circled in green indicates the Group By selecon, which
serves as an anchor for the report. The Group By column is used as a
match criteria to filter for the top N groups. Then, for each of the top
N groups, the report enumerates the values for all the other selected
columns.
For example, if a report has the following selecons:
The output will display as follows:
The report is anchored by Day and sorted by Sessions. It lists the 5 days
(5 Groups) with maximum traffic in the Last 7 Days me frame. The
Monitoring
data is enumerated by the Top 5 sessions for each day for the selected
columns—App Category, App Subcategory and Risk.
Time Frame The date range for which you want to analyze data. You can define a
custom range or select a me period ranging from the last 15 minutes
to the last 30 days. The reports can be run on demand or scheduled to
run at a daily or weekly cadence.
Query Builder The query builder allows you to define specific queries to further
refine the selected aributes. It allows you see just what you want in
your report using and and or operators and a match criteria, and then
include or exclude data that matches or negates the query in the report.
Queries enable you to generate a more focused collaon of informaon
in a report.
Generate Custom Reports

You can configure custom reports that the firewall generates immediately (on demand) or on
schedule (each night). To understand the selecons available to create a purposeful custom report,
see Custom Reports.
Aer the firewall has generated a scheduled custom report, you risk invalidang the past
results of that report if you modify its configuraon to change its future output. If you
need to modify a scheduled report configuraon, the best pracce is to create a new
report.
STEP 1 | Select Monitor > Manage Custom Reports.
STEP 2 | Click Add and then enter a Name for the report.
To base a report on an predefined template, click Load Template and choose the
template. You can then edit the template and save it as a custom report.
STEP 3 | Select the Database to use for the report.
Each me you create a custom report, a log view report is automacally created. This
report show the logs that were used to build the custom report. The log view report
uses the same name as the custom report, but appends the phrase (Log View) to the
report name.
When creang a report group, you can include the log view report with the custom report. For
more informaon, see Manage Report Groups.
Monitoring
STEP 4 | Select the Scheduled check box to run the report each night. The report is then available for
viewing in the Reports column on the side.
To generate a scheduled custom report using logs stored in Cortex Data Lake on the
Panorama™ management server, Cloud Service plugin 1.8 or later release must be
installed on Panorama.
STEP 5 | Define the filtering criteria. Select the Time Frame, the Sort By order, Group By preference,
and select the columns that must display in the report.
STEP 6 | (Oponal) Select the Query Builder aributes if you want to further refine the selecon
criteria. To build a report query, specify the following and click Add. Repeat as needed to
construct the full query.
• Connector—Choose the connector (and/or) to precede the expression you are adding.
• Negate—Select the check box to interpret the query as a negaon. If, for example, you
choose to match entries in the last 24 hours and/or are originang from the untrust zone,
the negate opon causes a match on entries that are not in the past 24 hours and/or are not
from the untrust zone.
• Aribute—Choose a data element. The available opons depend on the choice of database.
• Operator—Choose the criterion to determine whether the aribute applies (such as =). The
available opons depend on the choice of database.
• Value—Specify the aribute value to match.
For example, the following figure (based on the Traffic Log database) shows a query that
matches if the Traffic log entry was received in the past 24 hours and is from the untrust zone.
STEP 7 | To test the report sengs, select Run Now. Modify the sengs as required to change the
informaon that is displayed in the report.
Monitoring
STEP 8 | Click OK to save the custom report.

Examples of Custom Reports
If you want to set up a simple report in which you use the traffic summary database from the
last 30 days, and sort the data by the top 10 sessions and these sessions are grouped into 5
groups by day of the week. You would set up the custom report to look like this:
And the PDF output for the report would look as follows:
Now, if you want to use the query builder to generate a custom report that represents the top
consumers of network resources within a user group, you would set up the report to look like
this:
Monitoring
The report would display the top users in the product management user group sorted by bytes.
Generate Botnet Reports

The botnet report enables you to use heurisc and behavior-based mechanisms to idenfy
potenal malware- or botnet-infected hosts in your network. To evaluate botnet acvity and
infected hosts, the firewall correlates user and network acvity data in Threat, URL, and Data
Filtering logs with the list of malware URLs in PAN-DB, known dynamic DNS domain providers,
and domains registered within the last 30 days. You can configure the report to idenfy hosts that
visited those sites, as well as hosts that communicated with Internet Relay Chat (IRC) servers or
that used unknown applicaons. Malware oen use dynamic DNS to avoid IP blocking, while IRC
servers oen use bots for automated funcons.
The firewall requires Threat Prevenon and URL Filtering licenses to use the botnet report.
You can Use the Automated Correlaon Engine to monitor suspicious acvies based on
addional indicators besides those that the botnet report uses. However, the botnet report
is the only tool that uses newly registered domains as an indicator.
• Configure a Botnet Report

• Interpret Botnet Report Output
Configure a Botnet Report

You can schedule a botnet report or run it on demand. The firewall generates scheduled botnet
reports every 24 hours because behavior-based detecon requires correlang traffic across
mulple logs over that meframe.
Monitoring
STEP 1 | Define the types of traffic that indicate possible botnet acvity.
1. Select Monitor > Botnet and click Configuraon on the right side of the page.
2. Enable and define the Count for each type of HTTP Traffic that the report will include.
The Count values represent the minimum number of events of each traffic type that
must occur for the report to list the associated host with a higher confidence score
(higher likelihood of botnet infecon). If the number of events is less than the Count, the
report will display a lower confidence score or (for certain traffic types) won’t display an
entry for the host. For example, if you set the Count to three for Malware URL visit, then
hosts that visit three or more known malware URLs will have higher scores than hosts
that visit less than three. For details, see Interpret Botnet Report Output.
3. Define the thresholds that determine whether the report will include hosts associated
with traffic involving Unknown TCP or Unknown UDP applicaons.
4. Select the IRC check box to include traffic involving IRC servers.
5. Click OK to save the report configuraon.
STEP 2 | Schedule the report or run it on demand.

1. Click Report Seng on the right side of the page.
2. Select a me interval for the report in the Test Run Time Frame drop-down.
3. Select the No. of Rows to include in the report.
4. (Oponal) Add queries to the Query Builder to filter the report output by aributes such
as source/desnaon IP addresses, users, or zones.
For example, if you know in advance that traffic iniated from the IP address 10.3.3.15
contains no potenal botnet acvity, add not (addr.src in 10.0.1.35) as a
query to exclude that host from the report output. For details, see Interpret Botnet
Report Output.
5. Select Scheduled to run the report daily or click Run Now to run the report immediately.
Interpret Botnet Report Output

The botnet report displays a line for each host that is associated with traffic you defined as
suspicious when configuring the report. For each host, the report displays a confidence score of
1 to 5 to indicate the likelihood of botnet infecon, where 5 indicates the highest likelihood. The
scores correspond to threat severity levels: 1 is informaonal, 2 is low, 3 is medium, 4 is high, and
5 is crical. The firewall bases the scores on:
• Traffic type—Certain HTTP traffic types are more likely to involve botnet acvity. For example,
the report assigns a higher confidence to hosts that visit known malware URLs than to hosts
that browse to IP domains instead of URLs, assuming you defined both those acvies as
suspicious.
• Number of events—Hosts that are associated with a higher number of suspicious events will
have higher confidence scores based on the thresholds (Count values) you define when you
Configure a Botnet Report.
• Executable downloads—The report assigns a higher confidence to hosts that download
executable files. Executable files are a part of many infecons and, when combined with the
Monitoring
other types of suspicious traffic, can help you priorize your invesgaons of compromised
hosts.
When reviewing the report output, you might find that the sources the firewall uses to evaluate
botnet acvity (for example, the list of malware URLs in PAN-DB) have gaps. You might also find
that these sources idenfy traffic that you consider safe. To compensate in both cases, you can
add query filters when you Configure a Botnet Report.
Generate the SaaS Applicaon Usage Report

The SaaS Applicaon Usage PDF report is a two-part report that allows you to easily explore
SaaS applicaon acvity by risk and sancon state. A sanconed applicaon is an applicaon
that you formally approve for use on your network. A SaaS applicaon is an applicaon that has
the characterisc SaaS=yes in the applicaons details page in Objects > Applicaons, all other
applicaons are considered as non-SaaS. To indicate that you have sanconed a SaaS or non-SaaS
applicaon, you must tag it with the predefined tag named Sanconed. The firewall and Panorama
consider any applicaon without this predefined tag as unsanconed for use on the network.
• The first part of the report presents the key findings for the SaaS applicaons on your
network during the reporng period with a comparison of the sanconed versus unsanconed
applicaons and lists the top applicaons based on sancon state by usage, compliance, and
data transfers. To help you idenfy and explore the extent of high risk applicaon usage,
the applicaons with risky characteriscs secon of the report lists the SaaS applicaons
with the following unfavorable hosng characteriscs: cerficaons achieved, past data
breaches, support for IP-based restricons, financial viability, and terms of service. You
can also view a comparison of sanconed versus unsanconed SaaS applicaons by total
number of applicaons used on your network, bandwidth consumed by these applicaons,
the number of users using these applicaons, top user groups that use the largest number of
SaaS applicaons, and the top user groups that transfer the largest volume of data through
sanconed and unsanconed SaaS applicaons. This first part of the report also highlights
the top SaaS applicaon subcategories listed in order by maximum number of applicaons
used, the number of users, and the amount of data (bytes) transferred in each applicaon
subcategory.
• The second part of the report focuses on the detailed browsing informaon for SaaS and non-
SaaS applicaons for each applicaon subcategory listed in the first-part of the report. For each
applicaon in a subcategory, it also includes informaon about the top users who transferred
data, the top blocked or alerted file types, and the top threats for each applicaon. In addion,
this secon of the report tallies samples for each applicaon that the firewall submied for
WildFire analysis, and the number of samples determined to be benign and malicious.
Use the insights from this report to consolidate the list of business-crical and approved SaaS
applicaons and to enforce policies for controlling unsanconed and risky applicaons that pose
unnecessary risks for malware propagaon and data leaks.
The predefined SaaS applicaon usage report is sll available as a daily View Reports that
lists the top 100 SaaS applicaons (which means applicaons with the SaaS applicaon
characterisc, SaaS=yes) running on your network on a given day. This report does
not give visibility into applicaons you have designated as sanconed, but rather gives
visibility into all of the SaaS applicaons in use on your network.
Monitoring
STEP 1 | Tag applicaons that you approve for use on your network as Sanconed.
For generang an accurate and informave report, you need to tag the sanconed
applicaons consistently across firewalls with mulple virtual systems, and across
firewalls that belong to a device group on Panorama. If the same applicaon is tagged
as sanconed in one virtual system and is not sanconed in another or, on Panorama,
if an applicaon is unsanconed in a parent device group but is tagged as sanconed
in a child device group (or vice versa), the SaaS Applicaon Usage report will report the
applicaon as parally sanconed and will have overlapping results.
Example: If Box is sanconed on vsys1 and Google Drive is sanconed on vsys2, Google Drive
users in vsys1 will be counted as users of an unsanconed SaaS applicaon and Box users
in vsys2 will be counted as users of an unsanconed SaaS applicaon. The key finding in the
report will highlight that a total of two unique SaaS applicaons are discovered on the network
with two sanconed applicaons and two unsanconed applicaons.
1. Select Objects > Applicaons.
2. Click the applicaon Name to edit an applicaon and select Edit in the Tag secon.
3. Select Sanconed from the Tags drop-down.
You must use the predefined Sanconed tag ( ). If you use any other tag to
indicate that you sanconed an applicaon, the firewall will fail to recognize the tag and
the report will be inaccurate.
4. Click OK and Close to exit all open dialogs.
Monitoring
STEP 2 | Configure the SaaS Applicaon Usage report.

1. Select Monitor > PDF Reports > SaaS Applicaon Usage.
2. Click Add, enter a Name, and select a Time Period for the report (default is Last 7 Days).
By default, the report includes detailed informaon on the top SaaS and non-
SaaS applicaon subcategories, which can make the report large by page count
and file size. Clear the Include detailed applicaon category informaon in
report check box if you want to reduce the file size and restrict the page count to
10 pages.
3. Select whether you want the report to Include logs from:
In PAN-OS 10.0.2 and later releases, reports generated from logs in the Cortex
Data Lake only support including logs from the Selected Zone.
• All User Groups and Zones—The report includes data on all security zones and user
groups available in the logs.
If you want to include specific user groups in the report, select Include user group
informaon in the report and click the manage groups link to select the groups you
want to include. You must add between one and up to a maximum of 25 user groups,
so that the firewall or Panorama can filter the logs for the selected user groups. If you
do select the groups to include, the report will aggregate all user groups in to one
group called Others.
• Selected Zone—The report filters data for the specified security zone, and includes
data on that zone only.
If you want to include specific user groups in the report, select Include user group
informaon in the report and click the manage groups for selected zone link to select
the user groups within this zone that you want to include in the report. You must
add between one and up to a maximum of 25 user groups, so that the firewall or
Panorama can filter the logs for the selected user groups within the security zone. If
Monitoring
you do select the groups to include, the report will aggregate all user groups in to one
group called Others.
• Selected User Group—The report filters data for the specified user group only, and
includes SaaS applicaon usage informaon for the selected user group only.
4. Select whether you want to include all the applicaon subcategories in the report
(the default) or Limit the max subcategories in the report to the top 10, 15, 20 or 25
categories (default is all subcategories).
5. Click Run Now to generate the report on-demand for the last 7-day and the last 30-day
me period. Make sure that the pop-up blocker is disabled on your browser because the
report opens in a new tab.
STEP 3 | Schedule Reports for Email Delivery.

The last 90-days report must be scheduled for email delivery.
On the PA-220R and the PA-800 Series firewalls, the SaaS Applicaon Usage report is not sent
as a PDF aachment in the email. Instead, the email includes a link that you must click to open
the report in a web browser.
Manage PDF Summary Reports

PDF summary reports contain informaon compiled from exisng reports, based on data for the
top 5 in each category (instead of top 50). They also contain trend charts that are not available in
other reports.
Monitoring
STEP 1 | Set up a PDF Summary Report.

1. Select Monitor > PDF Reports > Manage PDF Summary.
2. Click Add and then enter a Name for the report.
3. Use the drop-down for each report group and select one or more of the elements to
design the PDF Summary Report. You can include a maximum of 18 report elements.
Selecng Top Threats is displayed as top-attacks in the Predefined Widgets

column for the PDF Summary Report.
• To remove an element from the report, click the x icon or clear the selecon from the
drop-down for the appropriate report group.
• To rearrange the reports, drag and drop the element icons to another area of the
report.
4. Click OK to save the report.
Monitoring
STEP 2 | View the report.

To download and view the PDF Summary Report, see View Reports.
The following summary secons refer to the following PDF Summary Report elements:
• Top 5 Aacks—Refers to the Top threats element.
• Top 5 Threats—Refers to the High risk user - Top threats element.
• Top Threats report—Refers to the full list of threats from the Top threats element.
Generate User/Group Acvity Reports

User/Group Acvity reports summarize the web acvity of individual users or user groups. Both
reports include the same informaon except for the Browsing Summary by URL Category and
Browse me calculaons, which only the User Acvity report includes.
You must configure User-ID on the firewall to access the list of users and user groups.
Monitoring
STEP 1 | Configure the browse mes and number of logs for User/Group Acvity reports.
Required only if you want to change the default values.
1. Select Device > Setup > Management, edit the Logging and Reporng Sengs, and
select the Log Export and Reporng tab.
2. For the Max Rows in User Acvity Report, enter the maximum number of rows that
the detailed user acvity report supports (range is 1-1048576, default is 5000). This
determines the number of logs that the report analyzes.
3. Enter the Average Browse Time in seconds that you esmate users should take to
browse a web page (range is 0-300, default is 60). Any request made aer the average
browse me elapses is considered a new browsing acvity. The calculaon uses Log
Only the Page a User Visits (logged in the URL Filtering logs) as the basis and ignores any
new web pages that are loaded between the me of the first request (start me) and the
average browse me. For example, if you set the Average Browse Time to two minutes
and a user opens a web page and views that page for five minutes, the browse me for
that page will sll be two minutes. This is done because the firewall can’t determine
how long a user views a given page. The average browse me calculaon ignores sites
categorized as web adversements and content delivery networks.
4. For the Page Load Threshold, enter the esmated me in seconds for page elements to
load on the page (default is 20). Any requests that occur between the first page load and
the page load threshold are assumed to be elements of the page. Any requests that occur
outside of the page load threshold are assumed to be the user clicking a link within the
page.
STEP 2 | Generate the User/Group Acvity report.

1. Select Monitor > PDF Reports > User Acvity Report.
2. Click Add and then enter a Name for the report.
3. Create the report:
• User Acvity Report—Select User and enter the Username or IP address (IPv4 or
IPv6) of the user.
• Group Acvity Report—Select Group and select the Group Name of the user group.
4. Select the Time Period for the report.
5. (Oponal) Select the Include Detailed Browsing check box (default is cleared) to include
detailed URL logs in the report.
The detailed browsing informaon can include a large volume of logs (thousands of logs)
for the selected user or user group and can make the report very large.
6. To run the report on demand, click Run Now.
7. To save the report configuraon, click OK. You can’t save the output of User/Group
Acvity reports on the firewall. To schedule the report for email delivery, see Schedule
Reports for Email Delivery.
Monitoring
Manage Report Groups

Report groups allow you to create sets of reports that the system can compile and send as a single
aggregate PDF report with an oponal tle page and all the constuent reports included.
Set up report groups.
You must set up a Report Group to email report(s).
1. Create an Email server profile.
2. Define the Report Group. A report group can compile predefined reports, PDF Summary
reports, custom reports, and Log View report into a single PDF.
1. Select Monitor > Report Group.
2. Click Add and then enter a Name for the report group.
3. (Oponal) Select Title Page and add a Title for the PDF output.
4. Select reports from the le column and click Add to move each report to the report
group on the right.
The Log View report is a report type that is automacally created each me you
create a custom report and uses the same name as the custom report. This report will
show the logs that were used to build the contents of the custom report.
To include the log view data, when creang a report group, add your custom report
under the Custom Reports list and then add the log view report by selecng the
matching report name from the Log View list. The report will include the custom
report data and the log data that was used to create the custom report.
6. To use the report group, see Schedule Reports for Email Delivery.
Schedule Reports for Email Delivery

Reports can be scheduled for daily delivery or delivered weekly on a specified day. Scheduled
reports are executed starng at 2:00 AM, and email delivery starts aer all scheduled reports have
been generated.
Monitoring
STEP 1 | Select Monitor > PDF Reports > Email Scheduler and click Add.
STEP 2 | Enter a Name to idenfy the schedule.
STEP 3 | Select the Report Group for email delivery. To set up a report group; see Manage Report
Groups.
STEP 4 | For the Email Profile, select an Email server profile to use for delivering the reports, or click
the Email Profile link to Create an Email server profile.
STEP 5 | Select the frequency at which to generate and send the report in Recurrence.
STEP 6 | The Override Email Addresses field allows you to send this report exclusively to the specified
recipients. When you add recipients to the field, the firewall does not send the report to the
recipients configured in the Email server profile. Use this opon for those occasions when the
report is for the aenon of someone other than the administrators or recipients defined in
the Email server profile.
Manage Report Storage Capacity

By default, firewalls contain 200MB of dedicated storage for reports generated by the firewall.
In some instances, especially for PA-7000 series and PA-5200 series firewalls, you may need
to increase the capacity of available report storage space in order to successfully generate new
reports.
STEP 2 | Confirm the current report storage capacity of the firewall:

The command output displays the report storage size in bytes. For this procedure, the firewall
has the default 200MB report storage capacity.
STEP 3 | Verify you have sufficient storage across the firewall to allocate toward expanding the report
storage capacity:
admin> show system disk-space
Monitoring
STEP 4 | Increase the report storage capacity as needed:

For example, we are increasing the report storage size to 1GB.
admin> request report-storage-size set size <0-4>
STEP 5 | Verify that the report storage capacity is increased to the amount set in the previous step:
admin> request report-storage-size show
Monitoring
View Policy Rule Usage

View the number of mes a Security, NAT, QoS, policy-based forwarding (PBF), Decrypon,
Tunnel Inspecon, Applicaon Override, Authencaon, or DoS protecon rule matches
traffic to help keep your firewall policies up to date as your environment and security needs
change. To prevent aackers from exploing over-provisioned access, such as when a server is
decommissioned or when you no longer need temporary access to a service, use the policy rule hit
count data to idenfy and remove unused rules.
Policy rule usage data enables you to validate rule addions and rule changes and to monitor
the me frame when a rule was used. For example, when you migrate port-based rules to app-
based rules, you create an app-based rule above the port-based rule and check for any traffic that
matches the port-based rule. Aer migraon, the hit count data helps you determine whether
it is safe to remove the port-based rule by confirming whether traffic is matching the app-based
rule instead of the port-based rule. The policy rule hit count helps you determine whether a rule is
effecve for access enforcement.
You can reset the rule hit count data to validate an exisng rule or to gauge rule usage within a
specified period of me. Policy rule hit count data is not stored on the firewall or Panorama so
that data is no longer available aer you reset (clear) the hit count.
Aer filtering your policy rulebase, administrators can take acon to delete, disable, enable, and
tag policy rules directly from the policy opmizer. For example, you can filter for unused rules
and then tag them for review to determine whether they can be safely deleted or kept in the
rulebase. By enabling administrators to take acon directly from the policy opmizer, you reduce
the management overhead required to further assist in simplifying your rule lifecycle management
and ensure that your firewalls are not over-provisioned.
The rule hit count data is not synchronized across firewalls in a high availability (HA)
deployment so you need to log in to each firewall to view the policy rule hit count data for
each firewall or use Panorama to view informaon on the HA firewall peers.
Policy rule usage data is also useful when using Security Policy Rule Opmizaon to
determine which rules to migrate or clean up first.
STEP 1 | Launch the Web Interface.
STEP 2 | Verify that Policy Rule Hit Count is enabled.

1. Navigate to Policy Rulebase Sengs (Device > Setup > Management).
2. Verify that Policy Rule Hit Count is enabled.
STEP 3 | Select Policies.
Monitoring
STEP 4 | View the policy rule usage for each policy rule:
• Hit Count—The number of mes traffic matched the criteria you defined in the policy rule.
Persists through reboot, dataplane restarts, and upgrades unless you manually reset or
rename the rule.
• Last Hit—The most recent mestamp for when traffic matched the rule.
• First Hit—The first instance when traffic was matched to this rule.
• Modified—The date and me the policy rule was last modified.
• Created—The date and me the policy rule was created.
If the rule was created when Panorama was running PAN-OS 8.1 and the Policy
Rule Hit Count seng is enabled, the First Hit date and me is used as the Created
date and me on upgrade to PAN-OS 9.0. If the rule was created in PAN-OS 8.1
when the Policy Rule Hit Count seng was disabled or if the rule was created when
Panorama was running PAN-OS 8.0 or an earlier release, the Created date for the
rule will be the date and me you successfully upgraded Panorama to PAN-OS 9.0
STEP 5 | In the Policy Opmizer dialog, view the Rule Usage filter.
STEP 6 | Filter rules in the selected rulebase.
Use the rule usage filter to evaluate the rule usage within a specified period of me. For
example, filter the selected rulebase for Unused rules within the last 30 days. You can
also evaluate rule usage with other rule aributes, such as the Created and Modified
dates, which enables you to filter for the correct set of rules to review. You can use this
data to help manage your rule lifecycle and to determine if a rule needs to be removed
to reduce your network aack surface.
1. Select the Timeframe you want to filter on or specify a Custom me frame.
2. Select the rule Usage on which to filter.
3. (Oponal) If you have reset the rule usage data for any rules, check for Exclude rules
reset during the last <number of days> days and decide when to exclude a rule based
Monitoring
on the number of days you specify since the rule was reset. Only rules that were reset
before your specified number of days are included in the filtered results.
4. (Oponal) Specify search filters based on rule data

1. Hover your cursor over the column header and Columns.
2. Add any addional columns you want to display or use for filter.
3. Hover your cursor over the column data that you would like to filter on Filter. For data
that contain dates, select whether to filter using This date, This date or earlier, or This
date or later.
4. Apply Filter ( ).
Monitoring
STEP 7 | Take acon on one or more unused policy rules.

1. Select one or more unused policy rules.
2. Perform one of the following acons:
• Delete—Delete one or more selected policy rules.
• Enable—Enable one or more selected policy rules when disabled.
• Disable—Disable one or more selected policy rules.
• Tag—Apply one or more group tags to one or more selected policy rules. The group
tag must already exist in order to tag policy rule.
• Untag—Remove one or more group tags from one or more selected policy rules.
Monitoring
Use External Services for Monitoring

Using an external service to monitor the firewall enables you to receive alerts for important
events, archive monitored informaon on systems with dedicated long-term storage, and integrate
with third-party security monitoring tools. The following are some common scenarios for using
external services:
For immediate noficaon about important system events or threats, you can Monitor
Stascs Using SNMP, Forward Traps to an SNMP Manager, or Configure Email Alerts.
To send an HTTP-based API request directly to any third-party service that exposes an API to
automate a workflow or an acon. You can, for example, forward logs that match a defined
criteria to create an incidence cket on ServiceNow instead of relying on an external system to
convert syslog messages or SNMP traps to an HTTP request. You can modify the URL, HTTP
header, parameters, and the payload in the HTTP request to trigger an acon based on the
aributes in a firewall log. See Forward Logs to an HTTP(S) Desnaon.
For long-term log storage and centralized firewall monitoring, you can Configure Syslog
Monitoring to send log data to a syslog server. This enables integraon with third-party
security monitoring tools such as Splunk or ArcSight.
For monitoring stascs on the IP traffic that traverses firewall interfaces, you can Configure
NetFlow Exports to view the stascs in a NetFlow collector.
You can Configure Log Forwarding from the firewalls directly to external services or from the
firewalls to Panorama and then configure Panorama to forwardlogs to the servers. Refer to Log
Forwarding Opons for the factors to consider when deciding where to forward logs.
You can’t aggregate NetFlow records on Panorama; you must send them directly from the
firewalls to a NetFlow collector.
Monitoring
Configure Log Forwarding

In an environment where you use mulple firewalls to control and analyze network traffic, any
single firewall can display logs and reports only for the traffic it monitors. Because logging in to
mulple firewalls can make monitoring a cumbersome task, you can more efficiently achieve global
visibility into network acvity by forwarding the logs from all firewalls to Panorama or external
services. If you Use External Services for Monitoring, the firewall automacally converts the logs
to the necessary format: syslog messages, SNMP traps, email noficaons, or as an HTTP payload
to send the log details to an HTTP(S) server. In cases where some teams in your organizaon can
achieve greater efficiency by monitoring only the logs that are relevant to their operaons, you
can create forwarding filters based on any log aributes (such as threat type or source user). For
example, a security operaons analyst who invesgates malware aacks might be interested only
in Threat logs with the type aribute set to wildfire-virus.
You can forward logs from the firewalls directly to external services or from the firewalls
to Panorama and then configure Panorama to forward logs to the servers. Refer to Log
Forwarding Opons for the factors to consider when deciding where to forward logs.
You can use Secure Copy (SCP) commands from the CLI to export the enre log
database to an SCP server and import it to another firewall. Because the log database is
too large for an export or import to be praccal on the PA-7000 Series firewall, it does not
support these opons. You can also use the web interface on all plaorms to View and
Manage Reports, but only on a per log type basis, not for the enre log database.
STEP 1 | Configure a server profile for each external service that will receive log informaon.
You can use separate profiles to send different sets of logs, filtered by log aributes, to
a different server. To increase availability, define mulple servers in a single profile.
Configure one or more of the following server profiles:

• (Required for SMTP over TLS) If you have not already done so, create a cerficate profile for
the email server.
• 2 To enable the SNMP manager (trap server) to interpret firewall traps, you must load the
Palo Alto Networks Supported MIBs into the SNMP manager and, if necessary, compile
them. For details, refer to your SNMP management soware documentaon.
• If the syslog server requires client authencaon, you must also 5
• Configure an HTTP server profile (see Forward Logs to an HTTP/S Desnaon).
STEP 2 | Create a Log Forwarding profile.

The profile defines the desnaons for Traffic, Threat, WildFire Submission, URL Filtering, Data
Filtering, Tunnel and Authencaon logs.
1. Select Objects > Log Forwarding and Add a profile.
If you want the firewall to automacally assign the profile to new security rules and
zones, enter default. If you don’t want a default profile, or you want to override
Monitoring
an exisng default profile, enter a Name that will help you idenfy the profile when
assigning it to security rules and zones.
If no log forwarding profile named default exists, the profile selecon is set
to None by default in new security rules (Log Forwarding field) and new security
zones (Log Seng field), although you can change the selecon.
3. Add one or more match list profiles.
The profiles specify log query filters, forwarding desnaons, and automac acons such
as tagging. For each match list profile:
2. Select the Log Type.
3. In the Filter drop-down, select Filter Builder. Specify the following and then Add each
query:
• Connector logic (and/or)
• Log Aribute
• Operator to define inclusion or exclusion logic
• Aribute Value for the query to match
4. Select Panorama if you want to forward logs to Log Collectors or the Panorama
management server.
5. For each type of external service that you use for monitoring (SNMP, Email, Syslog,
and HTTP), Add one or more server profiles.
4. (Oponal, GlobalProtect Only) If you are using a log forwarding profile with a security
policy to automacally quaranne a device using GlobalProtect, select Quaranne in the
Built-in Acons area.
5. Click OK to save the Log Forwarding profile.
STEP 3 | Assign the Log Forwarding profile to policy rules and network zones.
Security, Authencaon, and DoS Protecon rules support log forwarding. In this example, you
assign the profile to a Security rule.
Perform the following steps for each rule that you want to trigger log forwarding:
1. Select Policies > Security and edit the rule.
2. Select Acons and select the Log Forwarding profile you created.
3. Set the Profile Type to Profiles or Group, and then select the security profiles or Group
Profile required to trigger log generaon and forwarding for:
• Threat logs—Traffic must match any security profile assigned to the rule.
• WildFire Submission logs—Traffic must match a WildFire Analysis profile assigned to
the rule.
4. For Traffic logs, select Log At Session Start and/or Log At Session End.
Monitoring
STEP 4 | Configure the desnaons for System, Configuraon, Correlaon, GlobalProtect, HIP Match,
and User-ID logs.
Panorama generates Correlaon logs based on the firewall logs it receives, rather than
aggregang Correlaon logs from firewalls.
1. Select Device > Log Sengs.

2. For each log type that the firewall will forward, see Step Add one or more match list
profiles.
STEP 5 | (PA-7000 Series firewalls only) Configure a log card interface to perform log forwarding.
1. Select Network > Interfaces > Ethernet and click Add Interface.
2. Select the Slot and Interface Name.
3. Set the Interface Type to Log Card.
4. Enter the IP Address, Default Gateway, and (for IPv4 only) Netmask.
5. Select Advanced and specify the Link Speed, Link Duplex, and Link State.
These fields default to auto, which specifies that the firewall automacally
determines the values based on the connecon. However, the minimum
recommended Link Speed for any connecon is 1000 (Mbps).
STEP 6 | Commit and verify your changes.

2. Verify the log desnaons you configured are receiving firewall logs:
• Panorama—If the firewall forwards logs to a Panorama virtual appliance in Panorama
mode or to an M-Series appliance, you must configure a Collector Group before
Panorama will receive the logs. You can then verify log forwarding.
• Email server—Verify that the specified recipients are receiving logs as email
noficaons.
• Syslog server—Refer to your syslog server documentaon to verify it’s receiving logs
as syslog messages.
• SNMP manager—Use an SNMP Manager to Explore MIBs and Objects to verify it’s
receiving logs as SNMP traps.
• HTTP server—Forward Logs to an HTTP/S Desnaon.
Monitoring
Configure Email Alerts

You can configure email alerts for System, Config, HIP Match, Correlaon, Threat, WildFire
Submission, and Traffic logs. You can use separate profiles to send email noficaons for each log
type to a different server. To increase availability, define mulple servers (up to four) in a single
profile.
As a best pracce, configure transport layer security (TLS) to require the firewall to
authencate with the email server before the firewall relays email to the server. This helps
prevent malicious acvity, such as Simple Mail Transfer Protocol (SMTP) relay, which can
be used to send spam or malware, and email spoofing, which can be used for phishing
aacks.
STEP 1 | (Required for SMTP over TLS) If you have not already done so, create a cerficate profile for
the email server.
STEP 2 | Select Device > Server Profiles > Email.
STEP 3 | Add an email server profile and enter a Name.
STEP 4 | From the read-only window that appears, Add the email server and enter a Name.
STEP 5 | If the firewall has more than one virtual system (vsys), select the Locaon (vsys or Shared)
where this profile is available.
STEP 6 | (Oponal) Enter an Email Display Name to specify the name to display in the From field of
the email.
STEP 7 | Enter the email address From which the firewall sends emails.
STEP 8 | Enter the email address To which the firewall sends emails.
STEP 9 | (Oponal) If you want to send emails to a second account, enter the address of the
Addional Recipient. You can add only one addional recipient. For mulple recipients, add
the email address of a distribuon list.
STEP 10 | Enter the IP address or hostname of the Email Gateway to use for sending emails.
STEP 11 | Select the Type of protocol to use to connect to the email server:
• Unauthencated SMTP—Use SMTP to connect to the email server without authencaon.
The default Port is 25, but you can oponally specify a different port. This protocol does not
provide the same security as SMTP over TLS, but if you select this protocol, skip the next
step.
• SMTP over TLS—(Recommended) Use TLS to require authencaon to connect to the email
server. Connue to the next step to configure the TLS authencaon.
Monitoring
STEP 12 | (SMTP over TLS only) Configure the firewall to use TLS authencaon to connect to the
email server.
1. (Oponal) Specify the Port to use to connect to the email server (default is 587).
2. TLS Version—Specify the TLS version (1.1 or 1.2).
Palo Alto Networks strongly recommends using the latest TLS version.
3. Select the Authencaon Method for the firewall and the email server:
• Auto—Allow the firewall and the email server to determine the authencaon
method.
• Login—Use Base64 encoding for the username and password and transmit them
separately.
• Plain—Use Base64 encoding for the username and password and transmit them
together.
4. Select a Cerficate Profile to authencate with the email server.
5. Enter the Username and Password of the account that sends the emails, then Confirm
Password.
6. (Oponal) To confirm that the firewall can successfully authencate with the email
server, you can Test Connecon.
STEP 13 | Click OK to save the Email server profile.
STEP 14 | (Oponal) Select the Custom Log Format tab and customize the format of the email
messages. For details on how to create custom formats for the various log types, refer to the
Common Event Format Configuraon Guide.
STEP 15 | Configure email alerts for Traffic, Threat, and WildFire Submission logs.
1. See Create a Log Forwarding profile.
1. Select Objects > Log Forwarding, click Add, and enter a Name to idenfy the profile.
2. For each log type and each severity level or WildFire verdict, select the Email server
profile and click OK.
2. See Assign the Log Forwarding profile to policy rules and network zones.
STEP 16 | Configure email alerts for System, Config, HIP Match, and Correlaon logs.
2. For System and Correlaon logs, click each Severity level, select the Email server profile,
and click OK.
3. For Config and HIP Match logs, edit the secon, select the Email server profile, and click
OK.
4. Click Commit.
Monitoring
Use Syslog for Monitoring

Syslog is a standard log transport mechanism that enables the aggregaon of log data from
different network devices—such as routers, firewalls, printers—from different vendors into a
central repository for archiving, analysis, and reporng. Palo Alto Networks firewalls can forward
every type of log they generate to an external syslog server. You can use TCP or TLS (TLSv1.2
only) for reliable and secure log forwarding, or UDP for non-secure forwarding.
• Configure Syslog Monitoring
• Syslog Field Descripons
Configure Syslog Monitoring

To Use Syslog for Monitoring a Palo Alto Networks firewall, create a Syslog server profile and
assign it to the log sengs for each log type. Oponally, you can configure the header format
used in syslog messages and enable client authencaon for syslog over TLSv1.2.
For CEF-formated syslog events collecon, you must edit the default syslog
configuraon. The default syslog monitoring configuraon is not supported for CEF syslog
events collecon.
Monitoring
STEP 1 | Configure a Syslog server profile.
You can use separate profiles to send syslogs for each log type to a different server. To
increase availability, define mulple servers (up to four) in a single profile.
1. Select Device > Server Profiles > Syslog.

2. Click Add and enter a Name for the profile.
3. If the firewall has more than one virtual system (vsys), select the Locaon (vsys or
Shared) where this profile is available.
4. For each syslog server, click Add and enter the informaon that the firewall requires to
connect to it:
• Name—Unique name for the server profile.
• Syslog Server—IP address or fully qualified domain name (FQDN) of the syslog server.
If you configure an FQDN and use UDP transport, if the firewall cannot
resolve the FQDN, the firewall uses the exisng IP address resoluon for the
FQDN as the Syslog Server address.
• Transport—Select TCP, UDP, or SSL (TLS) as the protocol for communicang with the
syslog server. For SSL, the firewall supports only TLSv1.2.
• Port—The port number on which to send syslog messages (default is UDP on port
514); you must use the same port number on the firewall and the syslog server.
• Format—Select the syslog message format to use: BSD (the default) or IETF.
Tradionally, BSD format is over UDP and IETF format is over TCP or SSL/TLS.
• Facility—Select a syslog standard value (default is LOG_USER) to calculate the priority
(PRI) field in your syslog server implementaon. Select the value that maps to how
you use the PRI field to manage your syslog messages.
5. (Oponal) To customize the format of the syslog messages that the firewall sends, select
the Custom Log Format tab. For details on how to create custom formats for the various
log types, refer to the Common Event Format Configuraon Guide.
Monitoring
STEP 2 | Configure syslog forwarding for Traffic, Threat, and WildFire Submission logs.
1. Configure the firewall to forward logs. For more informaon, see Step Create a Log
Forwarding profile.
1. Select Objects > Log Forwarding, click Add, and enter a Name to idenfy the profile.
2. For each log type and each severity level or WildFire verdict, select the Syslog server
profile and click OK.
2. Assign the log forwarding profile to a security policy to trigger log generaon and
forwarding. For more informaon, See Step Assign the Log Forwarding profile to policy
rules and network zones.
1. Select Policies > Security and select a policy rule.
2. Select the Acons tab and select the Log Forwarding profile you created.
3. In the Profile Type drop-down, select Profiles or Groups, and then select the security
profiles or Group Profiles required to trigger log generaon and forwarding.
4. For Traffic logs, select one or both of the Log at Session Start and Log At Session End
check boxes, and click OK.
For detailed informaon about configuring a log forwarding profile and assigning the
profile to a policy rule, see Configure Log Forwarding.
STEP 3 | Configure syslog forwarding for System, Config, HIP Match, and Correlaon logs.
2. For System and Correlaon logs, click each Severity level, select the Syslog server profile,
and click OK.
3. For Config, HIP Match, and Correlaon logs, edit the secon, select the Syslog server
profile, and click OK.
STEP 4 | (Oponal) Configure the header format of syslog messages.

The log data includes the unique idenfier of the firewall that generated the log. Choosing
the header format provides more flexibility in filtering and reporng on the log data for some
Security Informaon and Event Management (SIEM) servers.
This is a global seng and applies to all Syslog server profiles configured on the firewall.
1. Select Device > Setup > Management and edit the Logging and Reporng Sengs.
2. Select the Log Export and Reporng tab and select the Syslog HOSTNAME Format:
• FQDN (default)—Concatenates the hostname and domain name defined on the
sending firewall.
• hostname—Uses the hostname defined on the sending firewall.
• ipv4-address—Uses the IPv4 address of the firewall interface used to send logs. By
default, this is the MGT interface.
• ipv6-address—Uses the IPv6 address of the firewall interface used to send logs. By
default, this is the MGT interface.
• none—Leaves the hostname field unconfigured on the firewall. There is no idenfier
for the firewall that sent the logs.
Monitoring
STEP 5 | Create a cerficate to secure syslog communicaon over TLSv1.2.

Required only if the syslog server uses client authencaon. The syslog server uses the
cerficate to verify that the firewall is authorized to communicate with the syslog server.
Ensure the following condions are met:
• The private key must be available on the sending firewall; the keys can’t reside on a
Hardware Security Module (HSM).
• The subject and the issuer for the cerficate must not be idencal.
• The syslog server and the sending firewall must have cerficates that the same trusted
cerficate authority (CA) signed. Alternavely, you can generate a self-signed cerficate on
the firewall, export the cerficate from the firewall, and import it in to the syslog server.
• The connecon to a Syslog server over TLS is validated using the Online Cerficate Status
Protocol (OCSP) or using Cerficate Revocaon Lists (CRL) so long as each cerficate in the
trust chain specifies one or both of these extensions. However, you cannot bypass OCSP
or CRL failures so you must ensure that the cerficate chain is valid and that you can verify
each cerficate using OCSP or CRL.
Generate.
2. Enter a Name for the cerficate.
3. In the Common Name field, enter the IP address of the firewall sending logs to the syslog
server.
4. In Signed by, select the trusted CA or the self-signed CA that the syslog server and the
sending firewall both trust.
The cerficate can’t be a Cerficate Authority nor an External Authority (cerficate
signing request [CSR]).
5. Click Generate. The firewall generates the cerficate and key pair.
6. Click the cerficate Name to edit it, select the Cerficate for Secure Syslog check box,
and click OK.
STEP 6 | Commit your changes and review the logs on the syslog server.
1. Click Commit.
2. To review the logs, refer to the documentaon of your syslog management soware. You
can also review the Syslog Field Descripons.
STEP 7 | (Oponal) Configure the firewall to terminate the connecon to the syslog server upon
FQDN refresh.
When you configure a syslog server profile using a FQDN, the firewall maintains its connecon
to the syslog server by default in the event of an FQDN name change.
For example, you have replaced an exisng syslog server with a new syslog server that uses
a different FQDN name. If you want the firewall to connect to the new syslog server using a
new FQDN name, you can configure the firewall to automacally terminate its connecon to
Monitoring
the old syslog server and establish a connecon to the new syslog server using the new FQDN
name.
1. Log in to the firewall CLI.
2. Configure the firewall to terminate the connecon to the syslog server upon FQDN
refresh.
admin> set syslogng fqdn-refresh yes
Syslog Field Descripons

The following topics list the standard fields of each log type that Palo Alto Networks firewalls
can forward to an external server, as well as the severity levels, custom formats, and escape
sequences. To facilitate parsing, the delimiter is a comma: each field is a comma-separated value
(CSV) string. The FUTURE_USE tag applies to fields that the firewalls do not currently implement.
WildFire Submissions logs are a subtype of Threat log and use the same syslog format.
• Traffic Log Fields

• Threat Log Fields
• HIP Match Log Fields
• GlobalProtect Log Fields
• IP-Tag Log Fields
• User-ID Log Fields
• Decrypon Log Fields
• Tunnel Inspecon Log Fields
• SCTP Log Fields
• Config Log Fields
• Authencaon Log Fields
• System Log Fields
• Correlated Events Log Fields
• GTP Log Fields
• Custom Log/Event Format
• Escape Sequences
Traffic Log Fields

Format: FUTURE_USE, Receive Time, Serial Number, Type, Threat/Content Type, FUTURE_USE,
Generated Time, Source Address, Desnaon Address, NAT Source IP, NAT Desnaon IP, Rule
Name, Source User, Desnaon User, Applicaon, Virtual System, Source Zone, Desnaon Zone,
Inbound Interface, Outbound Interface, Log Acon, FUTURE_USE, Session ID, Repeat Count,
Source Port, Desnaon Port, NAT Source Port, NAT Desnaon Port, Flags, Protocol, Acon,
Bytes, Bytes Sent, Bytes Received, Packets, Start Time, Elapsed Time, Category, FUTURE_USE,
Sequence Number, Acon Flags, Source Country, Desnaon Country, FUTURE_USE, Packets
Monitoring
Sent, Packets Received, Session End Reason, Device Group Hierarchy Level 1, Device Group
Hierarchy Level 2, Device Group Hierarchy Level 3, Device Group Hierarchy Level 4, Virtual
System Name, Device Name, Acon Source, Source VM UUID, Desnaon VM UUID, Tunnel
ID/IMSI, Monitor Tag/IMEI, Parent Session ID, Parent Start Time, Tunnel Type, SCTP Associaon
ID, SCTP Chunks, SCTP Chunks Sent, SCTP Chunks Received, Rule UUID, HTTP/2 Connecon,
App Flap Count, Policy ID, Link Switches, SD-WAN Cluster, SD-WAN Device Type, SD-WAN
Cluster Type, SD-WAN Site, Dynamic User Group Name, XFF Address, Source Device Category,
Source Device Profile, Source Device Model, Source Device Vendor, Source Device OS Family,
Source Device OS Version, Source Hostname, Source Mac Address, Desnaon Device Category,
Desnaon Device Profile, Desnaon Device Model, Desnaon Device Vendor, Desnaon
Device OS Family, Desnaon Device OS Version, Desnaon Hostname, Desnaon Mac
Address, Container ID, POD Namespace, POD Name, Source External Dynamic List, Desnaon
External Dynamic List, Host ID, Serial Number, Source Dynamic Address Group, Desnaon
Dynamic Address Group, Session Owner, High Resoluon Timestamp, A Slice Service Type, A Slice
Differenator, Applicaon Subcategory, Applicaon Category, Applicaon Technology, Applicaon
Risk, Applicaon Characterisc, Applicaon Container, Applicaon SaaS, Applicaon Sanconed
State
Field Name Descripon
Receive Time (receive_me Time the log was received at the management plane.
or cef-formaed-
receive_me)
Serial Number (serial) Serial number of the firewall that generated the log.
Type (type) Specifies the type of log; value is TRAFFIC.
Threat/Content Type Subtype of traffic log; values are start, end, drop, and deny
(subtype)
• Start—session started
• End—session ended
• Drop—session dropped before the applicaon is idenfied
and there is no rule that allows the session.
• Deny—session dropped aer the applicaon is idenfied
and there is a rule to block or no rule that allows the
session.
Generated Time Time the log was generated on the dataplane.

(me_generated or cef-
formaed-me_generated)
Source Address (src) Original session source IP address.
Desnaon Address (dst) Original session desnaon IP address.
NAT Source IP (natsrc) If Source NAT performed, the post-NAT Source IP address.
Monitoring
NAT Desnaon IP (natdst) If Desnaon NAT performed, the post-NAT Desnaon IP

address.
Rule Name (rule) Name of the rule that the session matched.
Source User (srcuser) Username of the user who iniated the session.
Desnaon User (dstuser) Username of the user to which the session was desned.
Applicaon (app) Applicaon associated with the session.
Virtual System (vsys) Virtual System associated with the session.
Source Zone (from) Zone the session was sourced from.
Desnaon Zone (to) Zone the session was desned to.
Inbound Interface Interface that the session was sourced from.

(inbound_if)
Outbound Interface Interface that the session was desned to.

(outbound_if)
Log Acon (logset) Log Forwarding Profile that was applied to the session.
Session ID (sessionid) An internal numerical idenfier applied to each session.
Repeat Count (repeatcnt) Number of sessions with same Source IP, Desnaon IP,
Applicaon, and Subtype seen within 5 seconds.
Source Port (sport) Source port ulized by the session.
Desnaon Port (dport) Desnaon port ulized by the session.
NAT Source Port (natsport) Post-NAT source port.
NAT Desnaon Port Post-NAT desnaon port.

(natdport)
Flags (flags) 32-bit field that provides details on session; this field can be
decoded by AND-ing the values with the logged value:
• 0x80000000—session has a packet capture (PCAP)
• 0x40000000—opon is enabled to allow a client to use
mulple paths to connect to a desnaon host
• 0x20000000—file is submied to WildFire for a verdict
Monitoring

• 0x10000000—enterprise credenal submission by end user
detected
• 0x08000000— source for the flow is on the allow list and
not subject to recon protecon
• 0x02000000—IPv6 session
• 0x01000000—SSL session is decrypted (SSL Proxy)
• 0x00800000—session is denied via URL filtering
• 0x00400000—session has a NAT translaon performed
• 0x00200000—user informaon for the session was
captured through Authencaon Portal
• 0x00100000—applicaon traffic is on a non-standard
desnaon port
• 0x00080000 —X-Forwarded-For value from a proxy is in the
source user field
• 0x00040000—log corresponds to a transacon within a hp
proxy session (Proxy Transacon)
• 0x00020000—Client to Server flow is subject to policy
based forwarding
• 0x00010000—Server to Client flow is subject to policy
based forwarding
• 0x00008000—session is a container page access (Container
Page)
• 0x00002000—session has a temporary match on a rule for
implicit applicaon dependency handling. Available in PAN-
OS 5.0.0 and above.
• 0x00000800—symmetric return is used to forward traffic
for this session
• 0x00000400—decrypted traffic is being sent out clear text
through a mirror port
• 0x00000100—payload of the outer tunnel is being
inspected
IP Protocol (proto) IP protocol associated with the session.
Acon (acon) Acon taken for the session; possible values are:
• allow—session was allowed by policy
• deny—session was denied by policy
• drop—session was dropped silently
• drop ICMP—session was silently dropped with an ICMP
unreachable message to the host or applicaon
Monitoring

• reset both—session was terminated and a TCP reset is sent
to both the sides of the connecon
• reset client—session was terminated and a TCP reset is sent
to the client
• reset server—session was terminated and a TCP reset is sent
to the server
Bytes (bytes) Number of total bytes (transmit and receive) for the session.
Bytes Sent (bytes_sent) Number of bytes in the client-to-server direcon of the

session.
Bytes Received Number of bytes in the server-to-client direcon of the

(bytes_received) session.
Packets (packets) Number of total packets (transmit and receive) for the session.
Start Time (start) Time of session start.
Elapsed Time (elapsed) Elapsed me of the session.
Category (category) URL category associated with the session (if applicable).
Sequence Number (seqno) A 64-bit log entry idenfier incremented sequenally; each log
type has a unique number space.
Acon Flags (aconflags) A bit field indicang if the log was forwarded to Panorama.
Source Country (srcloc) Source country or Internal region for private addresses;
maximum length is 32 bytes.
Desnaon Country (dstloc) Desnaon country or Internal region for private addresses.
Maximum length is 32 bytes.
Packets Sent (pkts_sent) Number of client-to-server packets for the session.
Packets Received Number of server-to-client packets for the session.

(pkts_received)
Session End Reason The reason a session terminated. If the terminaon had
(session_end_reason) mulple causes, this field displays only the highest priority
reason. The possible session end reason values are as follows,
in order of priority (where the first is highest):
• threat—The firewall detected a threat associated with a
reset, drop, or block (IP address) acon.
Monitoring

• policy-deny—The session matched a security rule with a
deny or drop acon.
• decrypt-cert-validaon—The session terminated
because you configured the firewall to block SSL
forward proxy decrypon or SSL inbound inspecon
when the session uses client authencaon or when
the session uses a server cerficate with any of the
following condions: expired, untrusted issuer, unknown
status, or status verificaon me-out. This session
end reason also displays when the server cerficate
produces a fatal error alert of type bad_cerficate,
unsupported_cerficate, cerficate_revoked, access_denied,
or no_cerficate_RESERVED (SSLv3 only).
• decrypt-unsupport-param—The session terminated
because you configured the firewall to block SSL forward
proxy decrypon or SSL inbound inspecon when the
session uses an unsupported protocol version, cipher,
or SSH algorithm. This session end reason is displays
when the session produces a fatal error alert of type
unsupported_extension, unexpected_message, or
handshake_failure.
• decrypt-error—The session terminated because you
configured the firewall to block SSL forward proxy
decrypon or SSL inbound inspecon when firewall
resources or the hardware security module (HSM) were
unavailable. This session end reason is also displayed when
you configured the firewall to block SSL traffic that has
SSL errors or that produced any fatal error alert other than
those listed for the decrypt-cert-validaon and decrypt-
unsupport-param end reasons.
• tcp-rst-from-client—The client sent a TCP reset to the
server.
• tcp-rst-from-server—The server sent a TCP reset to the
client.
• resources-unavailable—The session dropped because of a
system resource limitaon. For example, the session could
have exceeded the number of out-of-order packets allowed
per flow or the global out-of-order packet queue.
• tcp-fin—Both hosts in the connecon sent a TCP FIN
message to close the session.
• tcp-reuse—A session is reused and the firewall closes the

previous session.
Monitoring

• decoder—The decoder detects a new connecon within
the protocol (such as HTTP-Proxy) and ends the previous
connecon.
• aged-out—The session aged out.
• unknown—This value applies in the following situaons:
• Session terminaons that the preceding reasons do not
cover (for example, a clear session all command).
• For logs generated in a PAN-OS release that does not
support the session end reason field (releases older
than PAN-OS 6.1), the value will be unknown aer an
upgrade to the current PAN-OS release or aer the logs
are loaded onto the firewall.
• In Panorama, logs received from firewalls for which the
PAN-OS version does not support session end reasons
will have a value of unknown.
• n/a—This value applies when the traffic log type is not end.
Device Group Hierarchy A sequence of idenficaon numbers that indicate the device
(dg_hier_level_1 to group’s locaon within a device group hierarchy. The firewall
dg_hier_level_4) (or virtual system) generang the log includes the idenficaon
number of each ancestor in its device group hierarchy. The
shared device group (level 0) is not included in this structure.
If the log values are 12, 34, 45, 0, it means that the log was
generated by a firewall (or virtual system) that belongs to
device group 45, and its ancestors are 34, and 12. To view the
device group names that correspond to the value 12, 34 or 45,
use one of the following methods:
API query:
/api/?type=op&cmd=<show><dg-hierarchy></dg-
hierarchy></show>
Virtual System Name The name of the virtual system associated with the session;
(vsys_name) only valid on firewalls enabled for mulple virtual systems.
Device Name (device_name) The hostname of the firewall on which the session was logged.
Acon Source (acon_source) Specifies whether the acon taken to allow or block an
applicaon was defined in the applicaon or in policy. The
acons can be allow, deny, drop, reset- server, reset-client or
reset-both for the session.
Monitoring
Source VM UUID (src_uuid) Idenfies the source universal unique idenfier for a guest
virtual machine in the VMware NSX environment.
Desnaon VM UUID Idenfies the desnaon universal unique idenfier for a guest
(dst_uuid) virtual machine in the VMware NSX environment.
Tunnel ID/IMSI (tunnelid/ Internaonal Mobile Subscriber Identy (IMSI) is a unique

imsi) number allocated to each mobile subscriber in the GSM/
UMTS/EPS system. IMSI shall consist of decimal digits (0
through 9) only and maximum number of digits allowed are 15.
Monitor Tag/IMEI Internaonal Mobile Equipment Identy (IMEI) is a unique 15

(monitortag/imei) or 16 digit number allocated to each mobile staon equipment.
Parent Session ID ID of the session in which this session is tunneled. Applies to

(parent_session_id) inner tunnel (if two levels of tunneling) or inside content (if one
level of tunneling) only.
Parent Start Time Year/month/day hours:minutes:seconds that the parent tunnel

(parent_start_me) session began.
Tunnel Type (tunnel) Type of tunnel, such as GRE or IPSec.
SCTP Associaon ID Number that idenfies all connecons for an associaon

(assoc_id) between two SCTP endpoints.
SCTP Chunks (chunks) Sum of SCTP chunks sent and received for an associaon.
SCTP Chunks Sent Number of SCTP chunks sent for an associaon.

(chunks_sent)
SCTP Chunks Received Number of SCTP chunks received for an associaon.

(chunks_received)
Rule UUID (rule_uuid) The UUID that permanently idenfies the rule.
HTTP/2 Connecon Idenfies if traffic used an HTTP/2 Connecon by displaying

(hp2_connecon) one of the following values:
• Parent session ID—HTTP/2 connecon
• 0—SSL session
App Flap Count Number of link flaps that occurred during the session.
(link_change_count)
Policy ID (policy_id) Name of the SD-WAN policy.
Monitoring
Link Switches (link_switches) Contains up to four link flap entries, with each entry containing
the link name, link tag, link type, physical interface, mestamp,
bytes read, bytes wrien, link health, and link flap cause.
SD-WAN Cluster Name of the SD-WAN cluster.

(sdwan_cluster)
SD-WAN Device Type Type of device (hub or branch).

(sdwan_device_type)
SD-WAN Cluster Type Type of cluster (mesh or hub-spoke).

(sdwan_cluster_type)
SD-WAN Site (sdwan_site) Name of the SD-WAN site.
Dynamic User Group Name Name of the dynamic user group that contains the user who
(dynusergroup_name) iniated the session.
XFF Address (xff_ip) The IP address of the user who requested the web page or
the IP address of the next to last device that the request
traversed. If the request goes through one or more proxies,
load balancers, or other upstream devices, the firewall displays
the IP address of the most recent device.
Source Device Category The category for the device that Device-ID idenfies as the
(src_category) source of the traffic.
Source Device Profile The device profile for the device that Device-ID idenfies as
(src_profile) the source of the traffic.
Source Device Model The model of the device that Device-ID idenfies as the source
(src_model) of the traffic.
Source Device Vendor The vendor of the device that Device-ID idenfies as the
(src_vendor) source of the traffic.
Source Device OS Family The operang system type for the device that Device-ID
(src_osfamily) idenfies as the source of the traffic.
Source Device OS Version The version of the operang system for the device that
(src_osversion) Device-ID idenfies as the source of the traffic.
Source Hostname (src_host) The hostname of the device that Device-ID idenfies as the
source of the traffic.
Monitoring
Source MAC Address The MAC address for the device that Device-ID idenfies as
(src_mac) the source of the traffic.
Desnaon Device Category The category for the device that Device-ID idenfies as the
(dst_category) desnaon for the traffic.
Desnaon Device Profile The device profile for the device that Device-ID idenfies as
(dst_profile) the desnaon for the traffic.
Desnaon Device Model The model of the device that Device-ID idenfies as the
(dst_model) desnaon for the traffic.
Desnaon Device Vendor The vendor of the device that Device-ID idenfies as the
(dst_vendor) desnaon for the traffic.
Desnaon Device OS The operang system type for the device that Device-ID
Family (dst_osfamily) idenfies as the desnaon for the traffic.
Desnaon Device OS The version of the operang system for the device that
Version (dst_osversion) Device-ID idenfies as the desnaon for the traffic.
Desnaon Hostname The hostname of the device that Device-ID idenfies as the
(dst_host) desnaon for the traffic.
Desnaon MAC Address The MAC address for the device that Device-ID idenfies as
(dst_mac) the desnaon for the traffic.
Container ID (container_id) The container ID of the PAN-NGFW pod on the Kubernetes

node where the applicaon POD is deployed.
POD Namespace The namespace of the applicaon POD being secured.

(pod_namespace)
POD Name (pod_name) The applicaon POD being secured.
Source External Dynamic List The name of the external dynamic list that contains the source
(src_edl) IP address of the traffic.
Desnaon External The name of the external dynamic list that contains the
Dynamic List (dst_edl) desnaon IP address of the traffic.
Host ID (hosd) Unique ID GlobalProtect assigns to idenfy the host.
User Device Serial Number Serial number of the user’s machine or device.
(serialnumber)
Monitoring
Source Dynamic Address Original session source dynamic address group.

Group (src_dag)
Desnaon Dynamic Address Original desnaon source dynamic address group.

Group (dst_dag)
Session Owner The original high availability (HA) peer session owner in an HA
(session_owner) cluster from which the session table data was synchronized
upon HA failover.
High Resoluon Timestamp Time in milliseconds the log was received at the management
(high_res_mestamp) plane.
The format for this new field is YYYY-MM-DDThh:ss:sssTZD:
• YYYY—Four digit year
• MM—Two-digit month
• DD—Two-digit day of the month (01 through 31)
• T—Indicator for the beginning of the mestamp
• hh—Two-digit hour using 24-hour me (00 through 23)
• mm—Two-digit minute (00 through 59)
• ss—Two-digit second (00 through 60)
• sss—One or more digits for millisecond
• TZD—Time zone designator (+hh:mm or -hh:mm)
The High Resoluon Timestamp is supported

for logs received from managed firewalls
running PAN-OS 10.1 and later releases.
Logs received from managed firewalls running
PAN-OS 9.1 and earlier releases display a
1969-12-31T16:00:00:000-8:00
mestamp regardless of when the log was received.
A Slice Service Type The A Slice Service Type of the Network Slice ID.
(nsdsai_sst)
A Slice Differenator The A Slice Differenator of the Network Slice ID.

(nsdsai_sd)
Applicaon Subcategory The applicaon subcategory specified in the applicaon

(subcategory_of_app) configuraon properes.
Applicaon Category The applicaon category specified in the applicaon

(category_of_app) configuraon properes. Values are:
Monitoring

• business-systems
• collaboraon
• general-internet
• media
• networking
• saas
Applicaon Technology The applicaon technology specified in the applicaon

(technology_of_app) configuraon properes. Values are:
• browser-based
• client-server
• network-protocol
• peer-to-peer
Applicaon Risk (risk_of_app) Risk level associated with the applicaon (1=lowest to
5=highest).
Applicaon Characterisc Comma-separated list of applicable characterisc of the

(characterisc_of_app) applicaon
Applicaon Container The parent applicaon for an applicaon.

(container_of_app)
Applicaon SaaS Displays 1 if a SaaS applicaon or 0 if not a SaaS applicaon.

(is_saas_of_app)
Applicaon Sanconed State Displays 1 if applicaon is sanconed or 0 if applicaon is not

(sanconed_state_of_app) sanconed.

Threat Log Fields

Generated Time, Source Address, Desnaon Address, NAT Source IP, NAT Desnaon IP, Rule
Name, Source User, Desnaon User, Applicaon, Virtual System, Source Zone, Desnaon Zone,
Source Port, Desnaon Port, NAT Source Port, NAT Desnaon Port, Flags, IP Protocol, Acon,
URL/Filename, Threat ID, Category, Severity, Direcon, Sequence Number, Acon Flags, Source
Locaon, Desnaon Locaon, FUTURE_USE, Content Type, PCAP_ID, File Digest, Cloud, URL
Index, User Agent, File Type, X-Forwarded-For, Referer, Sender, Subject, Recipient, Report ID,
Device Group Hierarchy Level 1, Device Group Hierarchy Level 2, Device Group Hierarchy Level
3, Device Group Hierarchy Level 4, Virtual System Name, Device Name, FUTURE_USE, Source
Monitoring
VM UUID, Desnaon VM UUID, HTTP Method, Tunnel ID/IMSI, Monitor Tag/IMEI, Parent
Session ID, Parent Start Time, Tunnel Type, Threat Category, Content Version, FUTURE_USE,
SCTP Associaon ID, Payload Protocol ID, HTTP Headers, URL Category List, Rule UUID, HTTP/2
Connecon, Dynamic User Group Name, XFF Address, Source Device Category, Source Device
Profile, Source Device Model, Source Device Vendor, Source Device OS Family, Source Device
OS Version, Source Hostname, Source MAC Address, Desnaon Device Category, Desnaon
Device Profile, Desnaon Device Model, Desnaon Device Vendor, Desnaon Device OS
Family, Desnaon Device OS Version, Desnaon Hostname, Desnaon MAC Address,
Container ID, POD Namespace, POD Name, Source External Dynamic List, Desnaon External
Dynamic List, Host ID, Serial Number, Domain EDL, Source Dynamic Address Group, Desnaon
Dynamic Address Group, Paral Hash, High Resoluon Timestamp, Reason, Jusficaon, A Slice
Service Type, Applicaon Subcategory, Applicaon Category, Applicaon Technology, Applicaon
Risk, Applicaon Characterisc, Applicaon Container, Applicaon SaaS, Applicaon Sanconed
State
Receive Time Time the log was received at the management plane.
(receive_me or cef-
formaed-receive_me)
Serial Number (serial #) Serial number of the firewall that generated the log.
Type (type) Specifies the type of log; value is THREAT.
Threat/Content Type Subtype of threat log. Values include the following:

(subtype)
• data—Data paern matching a Data Filtering profile.
• file—File type matching a File Blocking profile.
• flood—Flood detected via a Zone Protecon profile.
• packet—Packet-based aack protecon triggered by a Zone
Protecon profile.
• scan—Scan detected via a Zone Protecon profile.
• spyware —Spyware detected via an An-Spyware profile.
• url—URL filtering log.
• ml-virus—Virus detected by WildFire Inline ML via an Anvirus
profile.
• virus—Virus detected via an Anvirus profile.
• vulnerability —Vulnerability exploit detected via a Vulnerability
• wildfire —A WildFire verdict generated when the firewall submits
a file to WildFire per a WildFire Analysis profile and a verdict
(malware, phishing, grayware, or benign, depending on what you
are logging) is logged in the WildFire Submissions log.
• wildfire-virus—Virus detected via an Anvirus profile.
Monitoring
Generate Time Time the log was generated on the dataplane.

(me_generated
or cef-formaed-
me_generated)
Source address (src) Original session source IP address.
Desnaon address (dst) Original session desnaon IP address.
NAT Source IP (natsrc) If source NAT performed, the post-NAT source IP address.
NAT Desnaon IP If desnaon NAT performed, the post-NAT desnaon IP address.

(natdst)
Rule Name (rule) Name of the rule that the session matched.
Desnaon User Username of the user to which the session was desned.
(dstuser)

(inbound_if)

(outbound_if)
Repeat Count Number of sessions with same Source IP, Desnaon IP,
(repeatcnt) Applicaon, and Content/Threat Type seen within 5 seconds.
Monitoring
NAT Source Port Post-NAT source port.

(natsport)

(natdport)
Flags (flags) 32-bit field that provides details on session; this field can be
decoded by AND-ing the values with the logged value:
• 0x40000000—opon is enabled to allow a client to use mulple
paths to connect to a desnaon host
detected
• 0x08000000— source for the flow is on an allow list and not
subject to recon protecon
• 0x00200000—user informaon for the session was captured
through Authencaon Portal
• 0x00100000—applicaon traffic is on a non-standard desnaon
port
• 0x00080000 —X-Forwarded-For value from a proxy is in the
source user field
• 0x00040000 —log corresponds to a transacon within a hp
proxy session (Proxy Transacon)
• 0x00020000—Client to Server flow is subject to policy based
forwarding
• 0x00010000—Server to Client flow is subject to policy based
forwarding
• 0x00008000 —session is a container page access (Container
Page)
• 0x00002000 —session has a temporary match on a rule for
implicit applicaon dependency handling. Available in PAN-OS
5.0.0 and above.
• 0x00000800 —symmetric return is used to forward traffic for
this session
Monitoring

• 0x00000400—decrypted traffic is being sent out clear text
through a mirror port
• 0x00000010—payload of the outer tunnel is being inspected
Acon (acon) Acon taken for the session; values are alert, allow, deny, drop,
drop-all-packets, reset-client, reset-server, reset-both, block-url.
• alert—threat or URL detected but not blocked
• allow— flood detecon alert
• deny—flood detecon mechanism acvated and deny traffic
based on configuraon
• drop— threat detected and associated session was dropped
• reset-client —threat detected and a TCP RST is sent to the client
• reset-server —threat detected and a TCP RST is sent to the
server
• reset-both —threat detected and a TCP RST is sent to both the
client and the server
• block-url —URL request was blocked because it matched a URL
category that was set to be blocked
• block-ip—threat detected and client IP is blocked
• random-drop—flood detected and packet was randomly dropped
• sinkhole—DNS sinkhole acvated
• syncookie-sent—syncookie alert
• block-connue (URL subtype only)—a HTTP request is blocked
and redirected to a Connue page with a buon for confirmaon
to proceed
• connue (URL subtype only)—response to a block-connue URL
connue page indicang a block-connue request was allowed
to proceed
• block-override (URL subtype only)—a HTTP request is blocked
and redirected to an Admin override page that requires a pass
code from the firewall administrator to connue
• override-lockout (URL subtype only)—too many failed admin
override pass code aempts from the source IP. IP is now
blocked from the block-override redirect page
• override (URL subtype only)—response to a block-override page
where a correct pass code is provided and the request is allowed
• block (Wildfire only)—file was blocked by the firewall and
uploaded to Wildfire
Monitoring
URL/Filename (misc) Field with variable length. A Filename has a maximum of 63

characters. A URL has a maximum of 1023 characters
The actual URI when the subtype is url
File name or file type when the subtype is file
File name when the subtype is virus
File name when the subtype is wildfire-virus
File name when the subtype is wildfire
URL or File name when the subtype is vulnerability if applicable
URL when Threat Category is domain-edl
Threat/Content Name Palo Alto Networks idenfier for known and custom threats. It
(thread) is a descripon string followed by a 64-bit numerical idenfier in
parentheses for some Subtypes:
• 8000 – 8099— scan detecon
• 8500 – 8599— flood detecon
• 9999— URL filtering log
• 10000 – 19999 —spyware phone home detecon
• 20000 – 29999 —spyware download detecon
• 30000 – 44999 —vulnerability exploit detecon
• 52000 – 52999— filetype detecon
• 60000 – 69999 —data filtering detecon
If the Domain EDL field is populated, then this field is populated
with the same value.
Threat ID ranges for virus detecon, WildFire signature

feed, and DNS C2 signatures used in previous releases
have been replaced with permanent, globally unique
IDs. Refer to the Threat/Content Type (subtype) and
Threat Category (thr_category) field names to create
updated reports, filter threat logs, and ACC acvity.
Category (category) For URL Subtype, it is the URL Category; For WildFire subtype, it is
the verdict on the file and is either ‘malware’, ‘phishing’, ‘grayware’,
or ‘benign’; For other subtypes, the value is ‘any’.
Severity (severity) Severity associated with the threat; values are informaonal, low,
medium, high, crical.
Monitoring
Direcon (direcon) Indicates the direcon of the aack, client-to-server or server-to-

client:
• 0—direcon of the threat is client to server
• 1—direcon of the threat is server to client
Sequence Number A 64-bit log entry idenfier incremented sequenally. Each log type
(seqno) has a unique number space.
Source Country (srcloc) Source country or Internal region for private addresses. Maximum
length is 32 bytes.
Desnaon Country Desnaon country or Internal region for private addresses.

(dstloc) Maximum length is 32 bytes.
Content Type Applicable only when Subtype is URL.

(contenype)
Content type of the HTTP response data. Maximum length 32
bytes.
PCAP ID (pcap_id) The packet capture (pcap) ID is a 64 bit unsigned integral denong
an ID to correlate threat pcap files with extended pcaps taken as a
part of that flow. All threat logs will contain either a pcap_id of 0 (no
associated pcap), or an ID referencing the extended pcap file.
File Digest (filedigest) Only for WildFire subtype; all other types do not use this field
The filedigest string shows the binary hash of the file sent to be
analyzed by the WildFire service.
Cloud (cloud) Only for WildFire subtype; all other types do not use this field.
The cloud string displays the FQDN of either the WildFire appliance
(private) or the WildFire cloud (public) from where the file was
uploaded for analysis.
URL Index (url_idx) Used in URL Filtering and WildFire subtypes.

When an applicaon uses TCP keepalives to keep a connecon
open for a length of me, all the log entries for that session have a
single session ID. In such cases, when you have a single threat log
(and session ID) that includes mulple URL entries, the url_idx is
a counter that allows you to correlate the order of each log entry
within the single session.
For example, to learn the URL of a file that the firewall forwarded
to WildFire for analysis, locate the session ID and the url_idx from
the WildFire Submissions log and search for the same session ID
Monitoring

and url_idx in your URL filtering logs. The log entry that matches
the session ID and url_idx will contain the URL of the file that was
forwarded to WildFire.
User Agent (user_agent) Only for the URL Filtering subtype; all other types do not use this
field.
The User Agent field specifies the web browser that the user used
to access the URL, for example Internet Explorer. This informaon is
sent in the HTTP request to the server.
File Type (filetype) Only for WildFire subtype; all other types do not use this field.
Specifies the type of file that the firewall forwarded for WildFire
analysis.
X-Forwarded-For (xff) Only for the URL Filtering subtype; all other types do not use this
field.
The X-Forwarded-For field in the HTTP header contains the IP
address of the user who requested the web page. It allows you to
idenfy the IP address of the user, which is useful parcularly if
you have a proxy server on your network that replaces the user IP
address with its own address in the source IP address field of the
packet header.
Referer (referer) Only for the URL Filtering subtype; all other types do not use this
field.
The Referer field in the HTTP header contains the URL of the web
page that linked the user to another web page; it is the source
that redirected (referred) the user to the web page that is being
requested.
Sender (sender) Specifies the name of the sender of an email.
Subject (subject) Specifies the subject of an email.
Recipient (recipient) Specifies the name of the receiver of an email.
Report ID (repord) Only for WildFire subtype; all other types do not use this field.
Idenfies the analysis request on the WildFire cloud or the WildFire
appliance.
(dg_hier_level_1 to group’s locaon within a device group hierarchy. The firewall (or
dg_hier_level_4) virtual system) generang the log includes the idenficaon number
of each ancestor in its device group hierarchy. The shared device
group (level 0) is not included in this structure.
Monitoring

generated by a firewall (or virtual system) that belongs to device
group 45, and its ancestors are 34, and 12. To view the device group
names that correspond to the value 12, 34 or 45, use one of the
following methods:
API query:
hierarchy></show>
Virtual System Name The name of the virtual system associated with the session; only
(vsys_name) valid on firewalls enabled for mulple virtual systems.
Device Name The hostname of the firewall on which the session was logged.
(device_name)
Source VM UUID Idenfies the source universal unique idenfier for a guest virtual
(src_uuid) machine in the VMware NSX environment.
Desnaon VM UUID Idenfies the desnaon universal unique idenfier for a guest
(dst_uuid) virtual machine in the VMware NSX environment.
HTTP Method Only in URL filtering logs. Describes the HTTP Method used in
(hp_method) the web request. Only the following methods are logged: Connect,
Delete, Get, Head, Opons, Post, Put.
Tunnel ID/IMSI Internaonal Mobile Subscriber Identy (IMSI) is a unique number

(tunnel_id/imsi) allocated to each mobile subscriber in the GSM/UMTS/EPS system.
IMSI shall consist of decimal digits (0 through 9) only and maximum
number of digits allowed are 15.
Monitor Tag/IMEI Internaonal Mobile Equipment Identy (IMEI) is a unique 15 or 16

(monitortag/imei) digit number allocated to each mobile staon equipment.
Parent Session ID ID of the session in which this session is tunneled. Applies to inner
(parent_session_id) tunnel (if two levels of tunneling) or inside content (if one level of
tunneling) only.
Parent Session Start Year/month/day hours:minutes:seconds that the parent tunnel

Time (parent_start_me) session began.
Threat Category Describes threat categories used to classify different types of threat
(thr_category) signatures.
Monitoring

If a domain external dynamic list generated the log, domain-edl
populates this field.
Content Version Applicaons and Threats version on your firewall when the log was
(contentver) generated.
SCTP Associaon ID Number that idenfies all connecons for an associaon between
(assoc_id) two SCTP endpoints.
Payload Protocol ID ID of the protocol for the payload in the data poron of the
(ppid)
data chunk.
HTTP Headers Indicates the inserted HTTP header in the URL log entries on the
(hp_headers) firewall.
URL Category List Lists the URL Filtering categories that the firewall used to enforce
(url_category_list) policy.
Rule UUID (rule_uuid) The UUID that permanently idenfies the rule.
HTTP/2 Connecon Idenfies if traffic used an HTTP/2 connecon by displaying one of

(hp2_connecon) the following values:
• TCP connecon session ID—session is HTTP/2
• 0—session is not HTTP/2
Dynamic User The name of the dynamic user group that contains the user who
Group Name iniated the session.
(dynusergroup_name)
XFF Address (xff_ip) The IP address of the user who requested the web page or the IP
address of the next to last device that the request traversed. If the
request goes through one or more proxies, load balancers, or other
upstream devices, the firewall displays the IP address of the most
recent device.
Source Device Category The category for the device that Device-ID idenfies as the source
(src_category) of the traffic.
Source Device Profile The device profile for the device that Device-ID idenfies as the
(src_profile) source of the traffic.
Source Device Model The model of the device that Device-ID idenfies as the source of
(src_model) the traffic.
Monitoring
Source Device Vendor The vendor of the device that Device-ID idenfies as the source of
(src_vendor) the traffic.
Source Device OS The operang system type for the device that Device-ID idenfies
Family (src_osfamily) as the source of the traffic.
Source Device OS The version of the operang system for the device that Device-ID
Version (src_osversion) idenfies as the source of the traffic.
Source Hostname The hostname of the device that Device-ID idenfies as the source
(src_host) of the traffic.
Source MAC Address The MAC address for the device that Device-ID idenfies as the
(src_mac) source of the traffic.
Desnaon Device The category for the device that Device-ID idenfies as the
Category (dst_category) desnaon for the traffic.
Desnaon Device The device profile for the device that Device-ID idenfies as the
Profile (dst_profile) desnaon for the traffic.
Desnaon Device The model of the device that Device-ID idenfies as the desnaon
Model (dst_model) for the traffic.
Desnaon Device The vendor of the device that Device-ID idenfies as the
Vendor (dst_vendor) desnaon for the traffic.
Desnaon Device OS The operang system type for the device that Device-ID idenfies
Family (dst_osfamily) as the desnaon for the traffic.
Desnaon Device OS The version of the operang system for the device that Device-ID
Version (dst_osversion) idenfies as the desnaon for the traffic.
Desnaon Hostname The hostname of the device that Device-ID idenfies as the
(dst_host) desnaon for the traffic.
Desnaon MAC The MAC address for the device that Device-ID idenfies as the
Address (dst_mac) desnaon for the traffic.
Container ID The container ID of the PAN-NGFW pod on the Kubernetes node

(container_id) where the applicaon POD is deployed.
POD Namespace The namespace of the applicaon POD being secured.

(pod_namespace)
POD Name (pod_name) The applicaon POD being secured.
Monitoring
Source External The name of the external dynamic list that contains the source IP
Dynamic List (src_edl) address of the traffic.
Desnaon External The name of the external dynamic list that contains the desnaon
Dynamic List (dst_edl) IP address of the traffic.
User Device Serial Serial number of the user’s machine or device.

Number (serialnumber)
Domain EDL The name of the external dynamic list that contains the domain
(domain_edl) name of the traffic.
Source Dynamic Original session source dynamic address group.

Address Group (src_dag)
Desnaon Dynamic Original desnaon source dynamic address group.

Address Group (dst_dag)
Paral Hash Machine Learning paral hash.

(paral_hash)
High Resoluon Time in milliseconds the log was received at the management plane.
Timestamp (high_res
mestamp)
The High Resoluon Timestamp is supported for logs

received from managed firewalls running PAN-OS 10.1
and later releases. Logs received from managed firewalls
running PAN-OS 9.1 and earlier releases display a
1969-12-31T16:00:00:000-8:00 mestamp
regardless of when the log was received.
Monitoring
Reason (reason) Reason for Data Filtering acon.
Jusficaon Jusficaon for Data Filtering acon.

(jusficaon)
(nssai_sst)

Applicaon Category The applicaon category specified in the applicaon configuraon

(category_of_app) properes. Values are:
• collaboraon
• media
• networking
• saas

• browser-based
• client-server
• peer-to-peer
Applicaon Risk Risk level associated with the applicaon (1=lowest to 5=highest).
(risk_of_app)
Applicaon Comma-separated list of applicable characterisc of the applicaon

Characterisc
(characterisc_of_app)

(container_of_app)

(is_saas_of_app)
Monitoring
Applicaon Displays 1 if applicaon is sanconed or 0 if applicaon is not

Sanconed State sanconed.
(sanconed_state_of_app)

HIP Match Log Fields

Generated Time, Source User, Virtual System, Machine Name, Operang System, Source Address,
HIP, Repeat Count, HIP Type, FUTURE_USE, FUTURE_USE, Sequence Number, Acon Flags,
3, Device Group Hierarchy Level 4, Virtual System Name, Device Name, Virtual System ID, IPv6
Source Address, Host ID, User Device Serial Number, Device MAC Address, High Resoluon
Timestamp
(receive_me or
cef-formaed-
receive_me)
Serial Number Serial number of the firewall that generated the log.
(serial)
Type (type) Specifies the type of log; value is HIP-MATCH.
Threat/Content Subtype of HIP match log; unused.

Type (subtype)

(me_generated
or cef-formaed-
me_generated)
Source User Username of the user who iniated the session.

(srcuser)
Virtual System (vsys) Virtual System associated with the HIP match log.
Machine Name Name of the user’s machine.

(machinename)
Monitoring
Operang System The operang system installed on the user’s machine or device (or on
(os) the client system).
Source Address (src) IP address of the source user.
HIP (matchname) Name of the HIP object or profile.
Repeat Count Number of mes the HIP profile matched.

(repeatcnt)
HIP Type Whether the hip field represents a HIP object or a HIP profile.
(matchtype)
Sequence Number A 64-bit log entry idenfier incremented sequenally; each log type has
(seqno) a unique number space.
Acon Flags A bit field indicang if the log was forwarded to Panorama.
(aconflags)
Device Group A sequence of idenficaon numbers that indicate the device group’s
Hierarchy locaon within a device group hierarchy. The firewall (or virtual system)
(dg_hier_level_1 to generang the log includes the idenficaon number of each ancestor
dg_hier_level_4) in its device group hierarchy. The shared device group (level 0) is not
included in this structure.
If the log values are 12, 34, 45, 0, it means that the log was generated
by a firewall (or virtual system) that belongs to device group 45, and
its ancestors are 34, and 12. To view the device group names that
correspond to the value 12, 34 or 45, use one of the following methods:
API query:
hierarchy></show>
Virtual System The name of the virtual system associated with the session; only valid
Name (vsys_name) on firewalls enabled for mulple virtual systems.
(device_name)
Virtual System ID A unique idenfier for a virtual system on a Palo Alto Networks firewall.
(vsys_id)
IPv6 System IPv6 address of the user’s machine or device.

Address (srcipv6)
Monitoring
User Device Serial number of the user’s machine or device.

Serial Number
(serialnumber)
Device MAC The MAC address of the user’s machine or device.

Address (mac)
Timestamp
(high_res_mestamp)

1969-12-31T16:00:00:000-8:00 mestamp
GlobalProtect Log Fields

Generated Time, Virtual System, Event ID, Stage, Authencaon Method, Tunnel Type, Source
User, Source Region, Machine Name, Public IP, Public IPv6, Private IP, Private IPv6, Host ID, Serial
Number, Client Version, Client OS, Client OS Version, Repeat Count, Reason, Error, Descripon,
Status, Locaon, Login Duraon, Connect Method, Error Code, Portal, Sequence Number, Acon
Flags, High Res Timestamp, Selecon Type, Response Time, Priority, Aempted Gateways,
Gateway, Device Group Hierarchy Level 1, Device Group Hierarchy Level 2, Device Group
Hierarchy Level 3, Device Group Hierarchy Level 4, Virtual System Name, Device Name, Virtual
System ID
Monitoring
Receive Time The me that the log was received at the management plane.
(receive_me)
Serial # (serial) The serial number of the firewall that generated the log.
Type (type) Specifies the type of log; value is GLOBALPROTECT.
Threat/Content Type Subtype of threat log. Values include the following:

(subtype)
• data—Data paern matching a Data Filtering profile.
• file—File type matching a File Blocking profile.
• flood—Flood detected via a Zone Protecon profile.
• packet—Packet-based aack protecon triggered by a Zone
• scan—Scan detected via a Zone Protecon profile.
• spyware —Spyware detected via an An-Spyware profile.
• url—URL filtering log.
• virus—Virus detected via an Anvirus profile.
• vulnerability —Vulnerability exploit detected via a Vulnerability
• wildfire —A WildFire verdict generated when the firewall submits
a file to WildFire per a WildFire Analysis profile and a verdict
(malicious, phishing, grayware, or benign, depending on what you
are logging) is logged in the WildFire Submissions log.
• wildfire-virus—Virus detected via an Anvirus profile.
Generate Time The me that the log was generated on the dataplane.
(me_generated)
Virtual System (vsys) The Virtual System associated with the session.
Event ID (evend) A string showing the name of the event.
Stage (stage) A string showing the stage of the connecon (for example, before-
login, login, or tunnel).
Authencaon A string showing the authencaon type, such as LDAP, RADIUS, or

Method SAML.
(auth_method)
Tunnel Type The type of tunnel (either SSLVPN or IPSec).

(tunnel_type)
Monitoring
Source User (srcuser) The username of the user who iniated the session.
Source Region The region for the user who iniated the session.
(srcregion)
Machine Name The name of the user’s machine.

(machinename)
Public IP (public_ip) The public IP address for the user who iniated the session.
Public IPv6 The public IPv6 address for the user who iniated the session.
(public_ipv6)
Private IP (private_ip) The private IP address for the user who iniated the session.
Private IPv6 The private IPv6 address for the user who iniated the session.
(private_ipv6)
Host ID (hosd) The unique ID that GlobalProtect assigns to idenfy the host.
Serial Number The serial number of the user’s machine or device.

(serialnumber)
Client Version The client’s GlobalProtect app version.

(client_ver)
Client OS (client_os) The client device’s OS type (for example, Windows or Linux).
Client OS Version The client device’s OS version.

(client_os_ver)
Repeat Count The number of sessions with the same source IP address, desnaon
(repeatcnt) IP address, applicaon, and subtype that GlobalProtect has detected
within the last five seconds.
Reason (reason) A string that shows the reason for the quaranne.
Error (error) A string showing that error that has occurred in any event.
Descripon (opaque) Addional informaon for any event that has occurred.
Status (status) The status (success or failure) of the event.
Locaon (locaon) A string showing the administrator-defined locaon of the

GlobalProtect portal or gateway.
Monitoring
Login Duraon The length of me, in seconds, the user is connected to the
(login_duraon) GlobalProtect gateway from logging in to logging out.
Connect Method A string showing the how the GlobalProtect app connects to Gateway,
(connect_method) (for example, on-demand or user-logon.
Error Code An integer associated with any errors that occurred.

(error_code)
Portal (portal) The name of the GlobalProtect portal or gateway.
Sequence Number A 64-bit log entry idenfier incremented sequenally; each log type
(aconflags)
Gateway The connecon method that is selected to connect to the gateway.

Selecon Method
• manual—The gateway to which you want the GlobalProtect app to
(selecon_type)
manually connect.
• preferred—The preferred gateway to which you want the
GlobalProtect app to connect.
• auto—Automacally connect to the Best Available gateway based
on the priority assigned to the gateway and the response me.
SSL Response Time The SSL response me of the selected gateway that is measured in
(response_me) milliseconds on the endpoint during tunnel setup.
Gateway Priority The priority order of the gateway that is based on highest (1), high (2),
(priority) medium (3), low (4), or lowest (5) to which the GlobalProtect app can
connect.
Aempted Gateways The fields that are collected for each gateway connecon aempt
(aempted_gateways) with the gateway name, SSL response me, and priority (see Gateway
Priority in a Mulple Gateway Configuraon. Each field entry is
separated by commas such as g82-gateway,12,3. Each gateway
entry is separated by semicolons such as g83-gateway,10,2;g84-
gateway,-1,1.
Gateway Name The name of the gateway that is specified on the portal configuraon.
(gateway)
generang the log includes the idenficaon number of each ancestor
Monitoring

(dg_hier_level_1 to in its device group hierarchy. The shared device group (level 0) is not
dg_hier_level_4) included in this structure.
by a firewall (or virtual system) that belongs to device group 45,
and its ancestors are 34, and 12. To view the device group names
that correspond to the value 12, 34 or 45, use one of the following
methods:
API query:
hierarchy></show>
Virtual System Name The name of the virtual system associated with the session; only valid
(vsys_name) on firewalls enabled for mulple virtual systems.
(device_name)
Virtual System ID A unique idenfier for a virtual system on a Palo Alto Networks
(vsys_id) firewall.
IP-Tag Log Fields

Format: FUTURE_USE , Receive Time, Serial, Type, Threat/Content Type, FUTURE_USE, Generate
Time, Virtual System, Source IP, Tag Name , Event ID, Repeat Count , Timeout, Data Source Name,
Data Source Type, Data Source Subtype, Sequence Number, Acon Flags, DG Hierarchy Level 1 ,
DG Hierarchy Level 2, DG Hierarchy Level 3, DG Hierarchy Level 4, Virtual System Name, Device
Name, Virtual System ID, High Resoluon Timestamp
Receive Time The me the log was received at the management plane.
(receive_me or
cef-formaed-
receive_me)
Serial Number (serial) The serial number of the firewall that generated the log.
Type (type) Specifies the type of log; value is IPTAG.
Threat/Content Type The subtype of the HIP match log; unused.

(subtype)
Generated Time The me the log was generated on the dataplane.
(me_generated
Monitoring

or cef-formaed-
me_generated)
Virtual System (vsys) The virtual system associated with the HIP match log.
Source IP (src) The IP address of the source user.
Tag Name (tag_name) The tag mapped to the source IP address.
Event ID (event_id) A string showing the name of the event.
Repeat Count The number of sessions with the same Source IP, Desnaon IP,
(repeatcnt) Applicaon, and Subtype seen within 5 seconds.
Timeout (meout) The amount of me before the IP address-to-tag mapping expires for
the source IP address.
Data Source Name The name of the source from which mapping informaon is collected.
(datasourcename)
Data Source Type The source from which mapping informaon is collected.
(datasource_type)
Data Source Subtype The mechanism used to idenfy the IP address-to-username mappings
(datasource_subtype) within a data source.
Acon Flags A bit field indicang whether the log was forwarded to Panorama.
(aconflags)
Device Group A sequence of idenficaon numbers that indicates the locaon of the
Hierarchy device group within a device group hierarchy. The firewall (or virtual
(dg_hier_level_1 to system) generang the log includes the idenficaon number of each
dg_hier_level_4) ancestor in its device group hierarchy except the shared device group
(level 0), which is not included in this structure.
If the log values are 12, 34, 45, and 0, it means that the log was
generated by a firewall (or virtual system) that belongs to device group
45 and its ancestors are 34 and 12. To view the device group names
that correspond to the value 12, 34, or 45, use one of the following
methods:
API query:
hierarchy></show>
Monitoring
(device_name)
Timestamp (high_res
mestamp)

1969-12-31T16:00:00:000-8:00 mestamp
User-ID Log Fields

Format: FUTURE_USER, Receive Time, Serial Number, Type, Threat/Content Type, FUTURE_USE,
Generated Time, Virtual System, Source IP, User, Data Source Name, Event ID, Repeat Count, Time
Out Threshold, Source Port, Desnaon Port, Data Source, Data Source Type, Sequence Number,
Acon Flags, Device Group Hierarchy Level 1, Device Group Hierarchy Level 2, Device Group
Hierarchy Level 3, Device Group Hierarchy Level 4, Virtual System Name, Device Name, Virtual
System ID, Factor Type, Factor Compleon Time, Factor Number, FUTURE_USE, FUTURE_USE,
User Group Flags, User by Source, High Resoluon Timestamp
Monitoring
(receive_me or cef-
formaed-receive_me)
Type (type) Specifies the type of log; value is USERID.
Threat/Content Type Subtype of User-ID log; values are login, logout, register-tag, and
(subtype) unregister-tag.
• login—User logged in.
• logout—User logged out.
• register-tag—Indicates a tag or tags were registered for the user.
• unregister-tag—Indicates a tag or tags were unregistered for the
user.
Generated Time The me the log was generated on the dataplane.
(me_generated
or cef-formaed-
me_generated)
Virtual System (vsys) Virtual System associated with the configuraon log.
Source IP (ip) Original session source IP address.
User (user) Idenfies the end user.
Data Source Name User-ID source that sends the IP (Port)-User Mapping.
(datasourcename)
Event ID (evend) String showing the name of the event.
Repeat Count Number of sessions with same Source IP, Desnaon IP,
(repeatcnt) Applicaon, and Subtype seen within 5 seconds.
Time Out Threshold Timeout aer which the IP/User Mappings are cleared.
(meout)
Source Port (beginport) Source port ulized by the session.
Desnaon Port Desnaon port ulized by the session.

(endport)
Data Source Source from which mapping informaon is collected.

(datasource)
Monitoring
Data Source Type Mechanism used to idenfy the IP/User mappings within a data
(datasourcetype) source.
Sequence Number Serial number of the firewall that generated the log.
(seqno)
(dg_hier_level_1 to group’s locaon within a device group hierarchy. The firewall (or
dg_hier_level_4) virtual system) generang the log includes the idenficaon number
of each ancestor in its device group hierarchy. The shared device
group (level 0) is not included in this structure.
generated by a firewall (or virtual system) that belongs to device
group 45, and its ancestors are 34, and 12. To view the device group
names that correspond to the value 12, 34 or 45, use one of the
following methods:
API query: /api/?type=op&cmd=<show><dg-hierarchy></
dg-hierarchy></show>
Virtual System Name The name of the virtual system associated with the session; only
(vsys_name) valid on firewalls enabled for mulple virtual systems.
(device_name)
Factor Type (factortype) Vendor used to authencate a user when Mul Factor
authencaon is present.
Factor Compleon Time Time the authencaon was completed.

(factorcompleonme)
Factor Number Indicates the use of primary authencaon (1) or addional factors
(factorno) (2, 3).
User Group Flags Displays whether the user group that was found during user group
(ugflags) mapping. Supported values are:
• User Group Found—Indicates whether the user could be mapped
to a group.
Monitoring

• Duplicate User—Indicates whether duplicate users were found in
a user group. Displays N/A if no user group is found.
User by Source Indicates the username received from the source through IP
(userbysource) address-to-username mapping.
Timestamp (high_res
mestamp)

1969-12-31T16:00:00:000-8:00 mestamp
Decrypon Log Fields

Format: FUTURE_USE, Receive Time, Serial Number, Type, Threat/Content Type, Config Version,
Generate Time, Source Address, Desnaon Address, NAT Source IP, NAT Desnaon IP, Rule,
Source User, Desnaon User, Applicaon, Virtual System, Source Zone, Desnaon Zone,
Inbound Interface, Outbound Interface, Log Acon, Time Logged, Session ID, Repeat Count,
Source Port, Desnaon Port, NAT Source Port, NAT Desnaon Port, Flags, IP Protocol, Acon,
Tunnel, FUTURE_USE, FUTURE_USE, Source VM UUID, Desnaon VM UUID, UUID for rule,
Stage for Client to Firewall, Stage for Firewall to Server, TLS Version, Key Exchange Algorithm,
Encrypon Algorithm, Hash Algorithm, Policy Name, Ellipc Curve, Error Index, Root Status, Chain
Status, Proxy Type, Cerficate Serial Number, Fingerprint, Cerficate Start Date, Cerficate End
Date, Cerficate Version, Cerficate Size, Common Name Length, Issuer Common Name Length,
Root Common Name Length, SNI Length, Cerficate Flags, Subject Common Name, Issuer Subject
Common Name, Root Subject Common Name, Server Name Indicaon, Error, Container ID, POD
Namespace, POD Name, Source External Dynamic List, Desnaon External Dynamic List, Source
Dynamic Address Group, Desnaon Dynamic Address Group, High Res Timestamp, Source
Device Category, Source Device Profile, Source Device Model, Source Device Vendor, Source
Device OS Family, Source Device OS Version, Source Hostname, Source Mac Address, Desnaon
Monitoring
Device Category, Desnaon Device Profile, Desnaon Device Model, Desnaon Device
Vendor, Desnaon Device OS Family, Desnaon Device OS Version, Desnaon Hostname,
Desnaon Mac Address, Sequence Number, Acon Flags, Device Group Hierarchy Level 1,
4, Virtual System Name, Device Name, Virtual System ID, Applicaon Subcategory, Applicaon
Category, Applicaon Technology, Applicaon Risk, Applicaon Characterisc, Applicaon
Container, Applicaon SaaS, Applicaon Sanconed State
(receive_me or
cef-formaed-
receive_me)
Type (type) Specifies the type of log; value is DECRYPTION.
Threat/ContentType Not used in the Decrypon log.

(subtype)
Config Version The soware version.

(config_ver)
Generate Time Time the log was generated on the dataplane.

(me_generated)
Desnaon Address Original session desnaon IP address.

(dst)
NAT Source IP If Source NAT performed, the post-NAT Source IP address.

(natsrc)
NAT Desnaon IP If Desnaon NAT performed, the post-NAT Desnaon IP address.

(natdst)
Rule (rule) Security policy rule that controls the session traffic.
Desnaon User Username of the user to which the session was desned.
(dstuser)
Monitoring

(inbound_if)

(outbound_if)
Log Acon (logset) Log Forwarding profile applied to the session.
Time Logged The me the log was received.

(me_received)
Repeat Count Number of sessions with the same Source IP, Desnaon IP,
(repeatcnt) Applicaon, and Content/Threat Type seen within 5 seconds.

(dport)

(natsport)

(natdport)
Flags (flags) 32-bit field that provides details on session; this field can be decoded
by AND-ing the values with the logged value:
• 0x40000000—opon is enabled to allow a client to use mulple
paths to connect to a desnaon host
detected
• 0x08000000— source for the flow is on the allow list and not
subject to recon protecon
Monitoring

• 0x00200000—user informaon for the session was captured
• 0x00100000—applicaon traffic is on a non-standard desnaon
port
• 0x00080000 —X-Forwarded-For value from a proxy is in the source
user field
• 0x00040000—log corresponds to a transacon within a hp proxy
session (Proxy Transacon)
• 0x00020000—Client to Server flow is subject to policy based
forwarding
• 0x00010000—Server to Client flow is subject to policy based
forwarding
• 0x00008000—session is a container page access (Container Page)
• 0x00002000—session has a temporary match on a rule for implicit
applicaon dependency handling. Available in PAN-OS 5.0.0 and
above.
• 0x00000800—symmetric return is used to forward traffic for this
session
• 0x00000400—decrypted traffic is being sent out clear text through
a mirror port
• 0x00000100—payload of the outer tunnel is being inspected
• drop—session was dropped silently
• drop ICMP—session was silently dropped with an ICMP unreachable
message to the host or applicaon
• reset both—session was terminated and a TCP reset is sent to both
the sides of the connecon
• reset client—session was terminated and a TCP reset is sent to the
client
• reset server—session was terminated and a TCP reset is sent to the
server
Monitoring
Tunnel (tunnel) Type of tunnel.
Source VM UUID The source universal unique idenfier for a guest virtual machine in the
(src_uuid) VMware NSX environment.
Desnaon VM The desnaon universal unique idenfier for a guest virtual machine
UUID (dst_uuid) in the VMware NSX environment.
UUID for rule The UUID that permanently idenfies the rule.
(rule_uuid)
Stage for Client The stage of the TLS handshake from the client to the firewall, for
to Firewall example, Client Hello, Server Hello, Cerficate, Client/Server key
(hs_stage_c2f) exchange, etc.
Stage for Firewall to The stage of the TLS handshake from the firewall to the server.
Server (hs_stage_f2s)
TLS Version The version of TLS protocol used for the session.
(tls_version)
Key Exchange The key exchange algorithm used for the session.
Algorithm
(tls_keyxchg)
Encrypon Algorithm The algorithm used to encrypt the session data, such as AES-128-CBC,
(tls_enc) AES-256-GCM, etc.
Hash Algorithm The authencaon algorithm used for the session, for example, SHA,
(tls_auth) SHA256, SHA384, etc.
Policy Name The name of the Decrypon policy associated with the session.
(policy_name)
Ellipc Curve The ellipc cryptography curve that the client and server negoate and
(ec_curve) use for connecons that use ECDHE cipher suites.
Error Index The type of error that occurred: Cipher, Resource, Resume, Version,
(err_index) Protocol, Cerficate, Feature, or HSM.
Root Status The status of the root cerficate, for example, trusted, untrusted, or
(root_status) uninspected.
Chain Status Whether the chain is trusted. Values are:

(chain_status)
• Uninspected
• Untrusted
Monitoring

• Trusted
• Incomplete
Proxy Type The Decrypon proxy type, such as Forward for Forward Proxy,
(proxy_type) Inbound for Inbound Inspecon, No Decrypt for undecrypted traffic,
GlobalProtect, etc.
Cerficate Serial The unique idenfier of the cerficate (generated by the cerficate
Number (cert_serial) issuer).
Cerficate A hash of the cerficate in x509 binary format.

Fingerprint
(fingerprint)
Cerficate Start Date The me the cerficate became valid (cerficate in invalid before this
(notbefore) me).
Cerficate End Date The me the cerficate expires (cerficate becomes invalid aer this
(notaer) me).
Cerficate Version The cerficate version (V1, V2, or V3).

(cert_ver)
Cerficate Size The cerficate key size.

(cert_size)
Common Name The length of the subject common name.

Length (cn_len)
Issuer Common The length of the issuer common name.

Name Length
(issuer_len)
Root Common Name The length of the root common name.

Length (rootcn_len)
SNI Length (sni_len) The length of the Server Name Indicaon (hostname).
Cerficate Flags The cerficate flags can return seven values:

(cert_flags)
• Session is resumed (b_resume_session)
• Cerficate (subject) common name is truncated
(b_cert_cn_truncated)
• Issuer common name is truncated (b_issuer_cn_truncated)
• Root common name is truncated (b_root_cn_truncated)
• Server Name Indicaon (SNI) is truncated (b_sni_truncated)
Monitoring

• Cerficate type, RSA or ECDSA (b_cert_type)
• Unused (padding3)
Subject Common The domain name (the name of the server that the cerficate protects).
Name (cn)
Issuer Common The name of the organizaon that verified the cerficate’s contents.
Name (issuer_cn)
Root Common Name The name of the root cerficate authority.

(root_cn)
Server Name The hostname of the server that the client is trying to contact. Using
Indicaon SNIs enables a server to host mulple websites and present mulple
cerficates on the same IP address and TCP port because each website
(sni)
has a unique SNI.
Error (error) A string showing the error that has occurred in the event.
Container ID A unique alphanumeric string that idenfies the container if the

(container_id) firewall runs in a cloud container.
POD Namespace The name of the Kubernetes pod namespace.

(pod_namespace)
POD Name The name of the kubernetes pod.

(pod_name)
Desnaon External The name of the external dynamic list that contains the desnaon IP
Dynamic List (dst_edl) address of the traffic.
Source Dynamic The dynamic address group that Device-ID idenfies as the source of
Address Group the traffic.
(src_dag)
Desnaon Dynamic The dynamic address group that Device-ID idenfies as the desnaon
Address Group for the traffic.
(dst_dag)
Timestamp
The format for this field is YYYY-MM-DDThh:ss:sssTZD:
Monitoring


1969-12-31T16:00:00:000-8:00 mestamp
Source Device The category for the device that Device-ID idenfies as the source of
Category the traffic.
(src_category)
Source Device Model The model of the device that Device-ID idenfies as the source of the
(src_model) traffic.
Source Device The vendor of the device that Device-ID idenfies as the source of the
Vendor (src_vendor) traffic.
Source Device OS The operang system type for the device that Device-ID idenfies as
Family (src_osfamily) the source of the traffic.
Source Device The version of the operang system for the device that Device-ID
OS Version idenfies as the source of the traffic.
(src_osversion)
Source Hostname The hostname of the device that Device-ID idenfies as the source of
(src_host) the traffic.
Desnaon The category for the device that Device-ID idenfies as the desnaon
Device Category for the traffic.
(dst_category)
Monitoring
Desnaon Device The device profile for the device that Device-ID idenfies as the
Profile (dst_profile) desnaon for the traffic.
Desnaon Device The model of the device that Device-ID idenfies as the desnaon
Model (dst_model) for the traffic.
Desnaon Device The vendor of the device that Device-ID idenfies as the desnaon
Vendor (dst_vendor) for the traffic.
Desnaon The operang system type for the device that Device-ID idenfies as
Device OS Family the desnaon for the traffic.
(dst_osfamily)
Desnaon The version of the operang system for the device that Device-ID
Device OS Version idenfies as the desnaon for the traffic.
(dst_osversion)
Desnaon The hostname of the device that Device-ID idenfies as the

Hostname (dst_host) desnaon for the traffic.
Desnaon MAC The MAC address for the device that Device-ID idenfies as the
Address (dst_mac) desnaon for the traffic.
(seqno) has unique number space.
(aconflags)
methods:
API query:
hierarchy></show>
Monitoring
(device_name)
Applicaon The applicaon subcategory specified in the applicaon configuraon

Subcategory properes.
(subcategory_of_app)

• collaboraon
• media
• networking
• saas
Applicaon The applicaon technology specified in the applicaon configuraon

Technology properes. Values are:
(technology_of_app)
• browser-based
• client-server
• peer-to-peer
(risk_of_app)

Characterisc

(container_of_app)

(is_saas_of_app)
Monitoring

Tunnel Inspecon Log Fields

Format: FUTURE_USE, Receive Time, Serial Number, Type, Subtype, FUTURE_USE, Generated
Time, Source Address, Desnaon Address, NAT Source IP, NAT Desnaon IP, Rule Name,
Source User, Desnaon User, Applicaon, Virtual System, Source Zone, Desnaon Zone,
Source Port, Desnaon Port, NAT Source Port, NAT Desnaon Port, Flags, Protocol, Acon,
Severity, Sequence Number, Acon Flags, Source Locaon, Desnaon Locaon, Device Group
Hierarchy Level 1, Device Group Hierarchy Level 2, Device Group Hierarchy Level 3, Device Group
Hierarchy Level 4, Virtual System Name, Device Name, Tunnel ID/IMSI, Monitor Tag/IMEI, Parent
Session ID, Parent Start Time, Tunnel, Bytes, Bytes Sent, Bytes Received, Packets, Packets Sent,
Packets Received, Maximum Encapsulaon, Unknown Protocol, Strict Check, Tunnel Fragment,
Sessions Created, Sessions Closed, Session End Reason, Acon Source, Start Time, Elapsed
Time, Tunnel Inspecon Rule, Remote User IP, Remote User ID, Rule UUID, PCAP ID, Dynamic
User Group, Source External Dynamic List, Desnaon External Dynamic List, High Resoluon
Timestamp, A Slice Differenator, A Slice Service Type, PDU Session ID, Applicaon Subcategory,
Applicaon Category, Applicaon Technology, Applicaon Risk, Applicaon Characterisc,
Applicaon Container, Applicaon SaaS, Applicaon Sanconed State
Receive Time Month, day, and me the log was received at the management plane.
(receive_me or
cef-formaed-
receive_me)
Type (type) Type of log as it pertains to the session: START or END.
(subtype)
• Drop—session dropped before the applicaon is idenfied and there
is no rule that allows the session.
• Deny—session dropped aer the applicaon is idenfied and there
is a rule to block or no rule that allows the session.

(me_generated
Monitoring

or cef-formaed-
me_generated)
Source Address (src) Source IP address of packets in the session.
Desnaon Address Desnaon IP address of packets in the session.

(dst)
NAT Source IP If Source NAT performed, the post-NAT Source IP address.

(natsrc)
NAT Desnaon IP If Desnaon NAT performed, the post-NAT Desnaon IP address.

(natdst)
Rule Name (rule) Name of the Security policy rule in effect on the session.
Source User (srcuser) Source User ID of packets in the session.
Desnaon User Desnaon User ID of packets in the session.

(dstuser)
Applicaon (app) Tunneling protocol used in the session.
Source Zone (from) Source zone of packets in the session.
Desnaon Zone (to) Desnaon zone of packets in the session.

(inbound_if)

(outbound_if)
Session ID (sessionid) Session ID of the session being logged.
Repeat Count Number of sessions with same Source IP, Desnaon IP, Applicaon,
(repeatcnt) and Subtype seen within 5 seconds.

(dport)
Monitoring

(natsport)

(natdport)
Flags (flags) 32-bit field that provides details on session; this field can be decoded
by AND-ing the values with the logged value:
• 0x80000000 —session has a packet capture (PCAP)
• 0x02000000 —IPv6 session
• 0x01000000 —SSL session was decrypted (SSL Proxy)
• 0x00800000 —session was denied via URL filtering
• 0x00400000 —session has a NAT translaon performed (NAT)
• 0x00200000 —user informaon for the session was captured
• 0x00080000 —X-Forwarded-For value from a proxy is in the source
user field
• 0x00040000 —log corresponds to a transacon within a hp proxy
session (Proxy Transacon)
• 0x00008000 —session is a container page access (Container Page)
• 0x00002000 —session has a temporary match on a rule for implicit
applicaon dependency handling. Available in PAN-OS 5.0.0 and
above.
• 0x00000800 —symmetric return was used to forward traffic for this
session
• Allow—session was allowed by policy
• Deny—session was denied by policy
• Drop—session was dropped silently
• Drop ICMP—session was silently dropped with an ICMP
unreachable message to the host or applicaon
• Reset both—session was terminated and a TCP reset is sent to both
the sides of the connecon
• Reset client—session was terminated and a TCP reset is sent to the
client
• Reset server—session was terminated and a TCP reset is sent to the
server
Monitoring
Severity (severity) Severity associated with the event; values are informaonal, low,
(seqno) has a unique number space. This field is not supported on PA-7000
Series firewalls.
(aconflags)
Source Locaon Source country or Internal region for private addresses; maximum
(srcloc) length is 32 bytes.
Desnaon Locaon Desnaon country or Internal region for private addresses. Maximum
(dstloc) length is 32 bytes.
methods:
API query:
hierarchy></show>
(device_name)
Tunnel ID (tunnelid) ID of the tunnel being inspected or the Internaonal Mobile Subscriber
Identy (IMSI) ID of the mobile user.
Monitor Tag Monitor name you configured for the Tunnel Inspecon policy rule or
(monitortag) the Internaonal Mobile Equipment Identy (IMEI) ID of the mobile
device.
Monitoring
Parent Session ID ID of the session in which this session is tunneled. Applies to inner
(parent_session_id) tunnel (if two levels of tunneling) or inside content (if one level of
tunneling) only.
Parent Start Time Year/month/day hours:minutes:seconds that the parent tunnel session
(parent_start_me) began.
Bytes (bytes) Number of bytes in the session.
Bytes Sent Number of bytes in the client-to-server direcon of the session.

(bytes_sent)
Bytes Received Number of bytes in the server-to-client direcon of the session.

(bytes_received)
Packets Sent Number of client-to-server packets for the session.

(pkts_sent)

(pkts_received)
Maximum Number of packets the firewall dropped because the packet exceeded
Encapsulaon the maximum number of encapsulaon levels configured in the Tunnel
(max_encap) Inspecon policy rule (Drop packet if over maximum tunnel inspecon
level).
Unknown Protocol Number of packets the firewall dropped because the packet contains
(unknown_proto) an unknown protocol, as enabled in the Tunnel Inspecon policy rule
(Drop packet if unknown protocol inside tunnel).
Strict Checking Number of packets the firewall dropped because the tunnel protocol
(strict_check) header in the packet failed to comply with the RFC for the tunnel
protocol, as enabled in the Tunnel Inspecon policy rule (Drop packet
if tunnel protocol fails strict header check).
Tunnel Fragment Number of packets the firewall dropped because of fragmentaon

(tunnel_fragment) errors.
Sessions Created Number of inner sessions created.

(sessions_created)
Monitoring
Sessions Closed Number of completed/closed sessions created.

(sessions_closed)
Session End Reason The reason a session terminated. If the terminaon had mulple
(session_end_reason) causes, this field displays only the highest priority reason. The possible
session end reason values are as follows, in order of priority (where the
first is highest):
• threat—The firewall detected a threat associated with a reset, drop,
or block (IP address) acon.
• policy-deny—The session matched a security rule with a deny or
drop acon.
• decrypt-cert-validaon—The session terminated because you
configured the firewall to block SSL forward proxy decrypon or
SSL inbound inspecon when the session uses client authencaon
or when the session uses a server cerficate with any of the
following condions: expired, untrusted issuer, unknown status, or
status verificaon me-out. This session end reason also displays
when the server cerficate produces a fatal error alert of type
bad_cerficate, unsupported_cerficate, cerficate_revoked,
access_denied, or no_cerficate_RESERVED (SSLv3 only).
• decrypt-unsupport-param—The session terminated because you
configured the firewall to block SSL forward proxy decrypon or
SSL inbound inspecon when the session uses an unsupported
protocol version, cipher, or SSH algorithm. This session end
reason is displays when the session produces a fatal error
alert of type unsupported_extension, unexpected_message, or
handshake_failure.
• decrypt-error—The session terminated because you configured
the firewall to block SSL forward proxy decrypon or SSL inbound
inspecon when firewall resources or the hardware security module
(HSM) were unavailable. This session end reason is also displayed
when you configured the firewall to block SSL traffic that has SSH
errors or that produced any fatal error alert other than those listed
for the decrypt-cert-validaon and decrypt-unsupport-param end
reasons.
• tcp-rst-from-client—The client sent a TCP reset to the server.
• tcp-rst-from-server—The server sent a TCP reset to the client.
• resources-unavailable—The session dropped because of a system
resource limitaon. For example, the session could have exceeded
the number of out-of-order packets allowed per flow or the global
out-of-order packet queue.
• tcp-fin—One host or both hosts in the connecon sent a TCP FIN
message to close the session.
Monitoring

• tcp-reuse—A session is reused and the firewall closes the previous
session.
• decoder—The decoder detects a new connecon within the
protocol (such as HTTP-Proxy) and ends the previous connecon.
• aged-out—The session aged out.
• unknown—This value applies in the following situaons:
• Session terminaons that the preceding reasons do not cover (for
example, a clear session all command).
• For logs generated in a PAN-OS release that does not support
the session end reason field (releases older than PAN-OS 6.1),
the value will be unknown aer an upgrade to the current PAN-
OS release or aer the logs are loaded onto the firewall.
• In Panorama, logs received from firewalls for which the PAN-OS
version does not support session end reasons will have a value of
unknown.
• n/a—This value applies when the traffic log type is not end.
Acon Source Specifies whether the acon taken to allow or block an applicaon was
(acon_source) defined in the applicaon or in policy. The acons can be allow, deny,
drop, reset- server, reset-client or reset-both for the session.
Start Time (start) Year/month/day hours:minutes:seconds that the session began.
Elapsed Time Elapsed me of the session.

(elapsed)
Tunnel Name of the tunnel inspecon rule matching the cleartext tunnel
Inspecon Rule traffic.
(tunnel_insp_rule)
Remote User IP IPv4 or IPv6 address of a remote user.

(remote_user_ip)
Remote User ID IMSI identy of a remote user, and if available, one IMEI identy or
(remote_user_id) one MSISDN identy.
Security Rule UUID The UUID that permanently idenfies the rule.
(rule_uuid)
PCAP ID (pcap_id) Unique packet capture ID that defines the locaon of the pcap file on
the firewall.
Monitoring
Dynamic User The name of the dynamic user group that contains the user who
Group Name iniated the session.
(dynusergroup_name)
Desnaon External The name of the external dynamic list that contains the desnaon IP
Dynamic List (dst_edl) address of the traffic.
Timestamp (high_res
mestamp)

1969-12-31T16:00:00:000-8:00 mestamp

(nssai_sd)
(nssai_sd)
PDU Session ID Session ID for the collecon of L4 segments inside a tunnel.

(pdu_session_id)

Monitoring

• collaboraon
• media
• networking
• saas
Applicaon The applicaon technology specified in the applicaon configuraon

Technology properes. Values are:
(technology_of_app)
• browser-based
• client-server
• peer-to-peer
(risk_of_app)

Characterisc

(container_of_app)

(is_saas_of_app)


SCTP Log Fields

Format: FUTURE_USE, Receive Time, Serial Number, Type, FUTURE_USE, FUTURE_USE,
Generated Time, Source Address, Desnaon Address, FUTURE_USE, FUTURE_USE, Rule Name,
FUTURE_USE, FUTURE_USE, FUTURE_USE, Virtual System, Source Zone, Desnaon Zone,
Monitoring
Source Port, Desnaon Port, FUTURE_USE, FUTURE_USE, FUTURE_USE, FUTURE_USE, IP

Protocol, Acon, Device Group Hierarchy Level 1, Device Group Hierarchy Level 2, Device Group
Hierarchy Level 3, Device Group Hierarchy Level 4, Virtual System Name, Device Name, Sequence
Number, FUTURE_USE, SCTP Associaon ID, Payload Protocol ID, Severity, SCTP Chunk Type,
FUTURE_USE, SCTP Verificaon Tag 1, SCTP Verificaon Tag 2, SCTP Cause Code, Diameter
App ID, Diameter Command Code, Diameter AVP Code, SCTP Stream ID, SCTP Associaon End
Reason, Op Code, SCCP Calling Party SSN, SCCP Calling Party Global Title, SCTP Filter, SCTP
Chunks, SCTP Chunks Sent, SCTP Chunks Received, Packets, Packets Sent, Packets Received,
UUID for rule, High Resoluon Timestamp
Receive Time (receive_me Time the log was received at the management plane.
or cef-formaed-
receive_me)
Type (type) Specifies the type of log; value is SCTP.

Desnaon Address (dst) Original session desnaon IP address.

(inbound_if)

(outbound_if)
Repeat Count (repeatcnt) Number of sessions with same Source IP, Desnaon IP,
Applicaon, and Subtype seen within 5 seconds.
Monitoring
• allow—session was allowed by the policy
• deny—session was denied by the policy
(dg_hier_level_1 to group’s locaon within a device group hierarchy. The firewall
dg_hier_level_4) (or virtual system) generang the log includes the idenficaon
number of each ancestor in its device group hierarchy. The
shared device group (level 0) is not included in this structure.
generated by a firewall (or virtual system) that belongs to
device group 45, and its ancestors are 34, and 12. To view the
device group names that correspond to the value 12, 34 or 45,
use one of the following methods:
API query:
hierarchy></show>
Virtual System Name The name of the virtual system associated with the session;
(vsys_name) only valid on firewalls enabled for mulple virtual systems.
Device Name (device_name) The hostname of the firewall on which the session was logged.
Sequence Number (seqno) A 64-bit log entry idenfier incremented sequenally; each log
type has a unique number space.
SCTP Associaon ID An internal 56-bit numerical logical idenfier applied to each

(assoc_id) SCTP associaon.
Payload Protocol ID (ppid) Idenfies the Payload Protocol ID (PPID) in the data chunk
which triggered this event. PPID is assigned by Internet
Assigned Numbers Authority (IANA).
Severity (severity) Severity associated with the event; values are informaonal,
low, medium, high, crical.
Monitoring
SCTP Chunk Type Describes the type of informaon contained in a chunk, such
(sctp_chunk_type) as control or data.
SCTP Event Type Defines the event triggered per SCTP chunk or packet when
(sctp_event_type) SCTP protecon profile is applied to the SCTP traffic. It is also
triggered by start or end of a SCTP associaon.
SCTP Verificaon Tag 1 Used by endpoint1 which iniates the associaon to verify if
(verif_tag_1) the SCTP packet received belongs to current SCTP associaon
and validate the endpoint2.
SCTP Verificaon Tag 2 Used by endpoint2 to verify if the SCTP packet received
(verif_tag_2) belongs to current SCTP associaon and validate the
endpoint1.
SCTP Cause Code Sent by an endpoint to specify reason for an error condion to
(sctp_cause_code) other endpoint of same SCTP associaon.
Diameter App ID The diameter applicaon in the data chunk which triggered
(diam_app_id) the event. Diameter Applicaon ID is assigned by Internet
Assigned Numbers Authority (IANA).
Diameter Command Code The diameter command code in the data chunk which triggered
(diam_cmd_code) the event. Diameter Command Code is assigned by Internet
Assigned Numbers Authority (IANA)
Diameter AVP Code The diameter AVP code in the data chunk which triggered the
(diam_avp_code) event.
SCTP Stream ID (stream_id) ID of the stream which carries the data chunk which triggered
the event.
SCTP Associaon End Reason an associaon was terminated. If the terminaon had
Reason (assoc_end_reason) mulple causes, the highest priority reason is displayed. The
possible session end reasons in descending priority are:
• shutdown-from-endpoint (highest)—endpoint sends out
SHUTDOWN
• abort-from-endpoint—endpoint sends out ABORT
• unknown (lowest)—the associaon aged out, or associaon
terminaon reason is not covered by one of the previous
reasons (for example, a clear session all command).
Op Code (op_code) Idenfies the operaon code of applicaon layer SS7

protocols, like MAP or CAP, in the data chunk which triggered
the event.
Monitoring
SCCP Calling Party SSN The Signaling Connecon Control Part (SCCP) calling party
(sccp_calling_ssn) subsystem number (SSN) in the data chunk which triggered the
event.
SCCP Calling Party Global The Signaling Connecon Control Part (SCCP) calling party
Title (sccp_calling_gt) global tle (GT) in the data chunk which triggered the event.
SCTP Filter (sctp_filter) Name of the filter that the SCTP chunk matched.
SCTP Chunks (chunks) Number of total chunks (transmit and receive) for the
associaon.
SCTP Chunks Sent Number of endpoint1(which iniates associaon)-to-endpoint2

(chunks_sent) chunks for the associaon.
SCTP Chunks Received Number of endpoint2-to-endpoint1(which iniates associaon)

(chunks_received) chunks for the associaon.
Packets Sent (pkts_sent) Number of client-to-server packets for the session.

(pkts_received)
UUID for rule (rule_uuid) The UUID that permanently idenfies the rule.
Monitoring

1969-12-31T16:00:00:000-8:00
Authencaon Log Fields

Generated Time, Virtual System, Source IP, User, Normalize User, Object, Authencaon Policy,
Repeat Count, Authencaon ID, Vendor, Log Acon, Server Profile, Descripon, Client Type,
Event Type, Factor Number, Sequence Number, Acon Flags, Device Group Hierarchy 1, Device
Group Hierarchy 2, Device Group Hierarchy 3, Device Group Hierarchy 4, Virtual System Name,
Device Name, Virtual System ID, Authencaon Protocol, UUID for rule, High Resoluon
Timestamp, Source Device Category, Source Device Profile, Source Device Model, Source Device
Vendor, Source Device OS Family, Source Device OS Version, Source Hostname, Source Mac
Address, Region, FUTURE_USE, User Agent, Session ID
(receive_me or
cef-formaed-
receive_me)
Serial Number (serial) Serial number of the device that generated the log.
Type (type) Specifies the type of log; value is AUTHENTICATION.
Threat/Content Type Subtype of the system log; refers to the system daemon generang the
(subtype) log; values are crypto, dhcp, dnsproxy, dos, general, global-protect, ha,
hw, nat, ntpd, pbf, port, pppoe, ras, roung, satd, sslmgr, sslvpn, userid,
url-filtering, vpn.

(me_generated
or cef-formaed-
me_generated)
Source IP (ip) Original session source IP address.
Monitoring
User (user) End user being authencated.
Normalize User Normalized version of username being authencated (such as

(normalize_user) appending a domain name to the username).
Object (object) Name of the object associated with the system event.
Authencaon Policy Policy invoked for authencaon before allowing access to a protected
(authpolicy) resource.
Repeat Count Number of sessions with same Source IP, Desnaon IP, Applicaon,
(repeatcnt) and Subtype seen within 5 seconds.
Authencaon ID Unique ID given across primary authencaon and addional (mul

(authid) factor) authencaon.
Vendor (vendor) Vendor providing addional factor authencaon.
Server Profile Authencaon server used for authencaon.

(serverprofile)
Descripon (desc) Addional authencaon informaon.
Client Type Type of client used to complete authencaon (such as authencaon

(clienype) portal).
Event Type (event) Result of the authencaon aempt.
Factor Number Indicates the use of primary authencaon (1) or addional factors (2,
(factorno) 3).
(aconflags)
Monitoring

methods:
API query:
hierarchy></show>
(device_name)
Authencaon Indicates the authencaon protocol used by the server. For example,
Protocol (authproto) PEAP with GTC.
UUID for rule The UUID that permanently idenfies the rule.
(rule_uuid)
Timestamp (high_res
_mestamp)

1969-12-31T16:00:00:000-8:00 mestamp
Monitoring
Source Device The category for the device that Device-ID idenfies as the source of
Category the traffic.
(src_category)
Source Device Model The model of the device that Device-ID idenfies as the source of the
(src_model) traffic.
Source Device The vendor of the device that Device-ID idenfies as the source of the
Vendor (src_vendor) traffic.
Source Device OS The operang system type for the device that Device-ID idenfies as
Family (src_osfamily) the source of the traffic.
Source Device The version of the operang system for the device that Device-ID
OS Version idenfies as the source of the traffic.
(src_osversion)
Source Hostname The hostname of the device that Device-ID idenfies as the source of
(src_host) the traffic.
Region (region) The geographical region where the traffic originates.
User Agent The string from the HTTP request header User-Agent.
(user_agent)
Session ID A string that uniquely idenfies the traffic session.
Config Log Fields

Format: FUTURE_USE, Receive Time, Serial Number, Type, Subtype, FUTURE_USE, Generated
Time, Host, Virtual System, Command, Admin, Client, Result, Configuraon Path, Before Change
Detail, Aer Change Detail, Sequence Number, Acon Flags, Device Group Hierarchy Level 1,
Device Group Hierarchy Level 2, Device Group Hierarchy Level 3, Device Group Hierarchy Level 4,
Virtual System Name, Device Name, Device Group, Audit Comment
(receive_me or
Monitoring

cef-formaed-
receive_me)
Serial Number Serial number of the device that generated the log.
(serial)
Type (type) Specifies the type of log; value is CONFIG.
Threat/Content Subtype of the configuraon log; unused.

Type (subtype)

(me_generated
or cef-formaed-
me_generated)
Host (host) Hostname or IP address of the client machine
Virtual System (vsys) Virtual System associated with the configuraon log
Command (cmd) Command performed by the Admin; values are add, clone, commit,
delete, edit, move, rename, set.
Admin (admin) Username of the Administrator performing the configuraon
Client (client) Client used by the Administrator; values are Web and CLI
Result (result) Result of the configuraon acon; values are Submied, Succeeded,
Failed, and Unauthorized
Configuraon Path The path of the configuraon command issued; up to 512 bytes in
(path) length
Before This field is in custom logs only; it is not in the default format.
Change Detail
It contains the full xpath before the configuraon change.
(before_change_detail)
Aer Change Detail This field is in custom logs only; it is not in the default format.
(aer_change_detail)
It contains the full xpath aer the configuraon change.
Sequence Number A 64bit log entry idenfier incremented sequenally; each log type has
(seqno) a unique number space.
(aconflags)
Monitoring
by a firewall (or virtual system) that belongs to device group 45, and
its ancestors are 34, and 12. To view the device group names that
correspond to the value 12, 34 or 45, use one of the following methods:
API query:
hierarchy></show>
Virtual System The name of the virtual system associated with the session; only valid
Name (vsys_name) on firewalls enabled for mulple virtual systems.
(device_name)
Device Group (dg_id) The device group the firewall belongs to if managed by a Panorama™
management server.
Audit Comment The audit comment entered in a policy rule configuraon change.
(comment)
System Log Fields

Format: FUTURE_USE, Receive Time, Serial Number, Type, Content/Threat Type, FUTURE_USE,
Generated Time, Virtual System, Event ID, Object, FUTURE_USE, FUTURE_USE, Module, Severity,
Descripon, Sequence Number, Acon Flags, Device Group Hierarchy Level 1, Device Group
Hierarchy Level 2, Device Group Hierarchy Level 3, Device Group Hierarchy Level 4, Virtual
System Name, Device Name, FUTURE_USE, FUTURE_USE, High Resoluon Timestamp
(receive_me or
cef-formaed-
receive_me)
Type (type) Specifies the type of log; value is SYSTEM.
Monitoring
Content/Threat Type Subtype of the system log; refers to the system daemon generang the

(me_generated
or cef-formaed-
me_generated)
Event ID (evend) String showing the name of the event.
Object (object) Name of the object associated with the system event.
Module (module) This field is valid only when the value of the Subtype field is general. It
provides addional informaon about the sub-system generang the
log; values are general, management, auth, ha, upgrade, chassis.
Descripon (opaque) Detailed descripon of the event, up to a maximum of 512 bytes.
(aconflags)
methods:
API query:
hierarchy></show>
Monitoring
(device_name)
Timestamp

1969-12-31T16:00:00:000-8:00 mestamp
Correlated Events Log Fields

Format: FUTURE_USE, Receive Time, Serial Number, Type, Content/Threat Type, FUTURE_USE,
Generated Time, Source Address. Source User, Virtual System, Category, Severity, Device Group
Hierarchy Level 1, Device Group Hierarchy Level 2, Device Group Hierarchy Level 3, Device Group
Hierarchy Level 4, Virtual System Name, Device Name, Virtual System ID, Object Name, Object ID,
Evidence
(receive_me or
cef-formaed-
receive_me)
Serial Number (serial) Serial number of the device that generated the log.
Monitoring
Type (type) Specifies the type of log; value is CORRELATION.
Content/Threat Type Subtype of the system log; refers to the system daemon generang the

(me_generated
or cef-formaed-
me_generated)
Source Address (src) IP address of the user who iniated the event.
Source User (srcuser) Username of the user who iniated the event.
Category (category) A summary of the kind of threat or harm posed to the network, user, or
host.
methods:
API query:
hierarchy></show>
(device_name)
Monitoring
Object Name Name of the correlaon object that was matched on.
(objectname)
Object ID (object_id) Name of the object associated with the system event.
Evidence (evidence) A summary statement that indicates how many mes the host has
matched against the condions defined in the correlaon object. For
example, Host visited known malware URl (19 mes).
GTP Log Fields

Generated Time, Source Address, Desnaon Address, FUTURE_USE, FUTURE_USE, Rule
Name, FUTURE_USE, FUTURE_USE, Applicaon, Virtual System, Source Zone, Desnaon Zone,
Inbound Interface, Outbound Interface, Log Acon, FUTURE_USE, Session ID, FUTURE_USE,
Source Port, Desnaon Port, FUTURE_USE, FUTURE_USE, FUTURE_USE, Protocol, Acon,
GTP Event Type, MSISDN, Access Point Name, Radio Access Technology, GTP Message Type,
End User IP Address, Tunnel Endpoint Idenfier1, Tunnel Endpoint Idenfier2, GTP Interface,
GTP Cause, Severity, Serving Country MCC, Serving Network MNC, Area Code, Cell ID, GTP
Event Code, FUTURE_USE, FUTURE_USE, Source Locaon, Desnaon Locaon, FUTURE_USE,
FUTURE_USE, FUTURE_USE, FUTURE_USE, FUTURE_USE, FUTURE_USE, FUTURE_USE,
Tunnel ID/IMSI, Monitor Tag/IMEI, FUTURE_USE, FUTURE_USE, FUTURE_USE, FUTURE_USE,
FUTURE_USE, FUTURE_USE, FUTURE_USE, FUTURE_USE, FUTURE_USE, FUTURE_USE,
FUTURE_USE, FUTURE_USE, FUTURE_USE, FUTURE_USE, FUTURE_USE, FUTURE_USE, Start
Time, Elapsed Time, Tunnel Inspecon Rule, Remote User IP, Remote User ID, UUID for rule,
PCAP ID, High Resoluon Timestamp, A Slice Service Type, A Slice Differenator, Applicaon
Subcategory, Applicaon Category, Applicaon Technology, Applicaon Risk, Applicaon
Characterisc, Applicaon Container, Applicaon SaaS, Applicaon Sanconed State
Receive Time (receive_me Month, Day and me the log was received at the management
or cef-formaed- plane.
receive_me)
Type (type) Specifies the type of log; value is GTP.
(subtype)
Monitoring

• Drop—session dropped before the applicaon is idenfied
and there is no rule that allows the session.
• Deny—session dropped aer the applicaon is idenfied
and there is a rule to block or no rule that allows the
session.

Source Address (src) Source IP address of packets in the session.
Desnaon Address (dst) Desnaon IP address of packets in the session.
Applicaon (app) Tunneling protocol used in the session.
Source Zone (from) Source zone of packets in the session.
Desnaon Zone (to) Desnaon zone of packets in the session.

(inbound_if)

(outbound_if)
Session ID (sessionid) Session ID of the session being logged.
Monitoring
GTP Event Type (event_type) Defines event triggered by a GTP message when checks in
GTP protecon profile are applied to the GTP traffic. Also
triggered by the start or end of a GTP session.
MSISDN (msisdn) Service identy associated with the mobile subscriber

composed of a Country Code, Naonal Desnaon Code
and a Subscriber. Consists of decimal digits (0-9) only with a
maximum of 15 digits.
Access Point Name (apn) Reference to a Packet Data Network Data Gateway (PGW)/
Gateway GPRS Support Node in a mobile network. Composed
of a mandatory APN Network Idenfier and an oponal APN
Operator Idenfier.
Radio Access Technology (rat) Type of technology used for radio access. For example,
EUTRAN, WLAN, Virtual, HSPA Evoluon, GAN and GERAN.
GTP Message Type Indicates the GTP message type.

(msg_type)
End IP Address (end_ip_adr) IP address of a mobile subscriber allocated by a PGW/GGSN.
Tunnel Endpoint Idenfier1 Idenfies the GTP tunnel in the network node. TEID1 is the
(teid1) first TEID in the GTP message.
Tunnel Endpoint Idenfier2 Idenfies the GTP tunnel in the network node. TEID2 is the
(teid2) second TEID in the GTP message.
GTP Interface (gtp_interface) 3GPP interface from which a GTP message is received.
GTP Cause (cause_code) GTP cause value in logs responses which contain an
Informaon Element that provides informaon about
acceptance or rejecon of GTP requests by a network node.
Severity (severity) Severity associated with the event; values are informaonal,
low, medium, high, crical.
Serving Network MCC (mcc) Mobile country code of serving core network operator.
Serving Network MNC (mnc) Mobile network code of serving core network operator.
Area Code (area_code) Area within a Public Land Mobile Network (PLMN).
Cell ID (cell_id) Base staon within an area code.
GTP Event Code (event_code) Event code describing the GTP event.
Monitoring
Source Locaon (srcloc) Source country or Internal region for private addresses;
Desnaon Locaon (dstloc) Desnaon country or Internal region for private addresses;
Tunnel ID/IMSI (imsi) Internaonal Mobile Subscriber Identy (IMSI) is a unique

number allocated to each mobile subscriber in the GSM/
UMTS/EPS system. IMSI shall consist of decimal digits (0
through 9) only and maximum number of digits allowed are 15.
Monitor Tag/IMEI (imei) Internaonal Mobile Equipment Identy (IMEI) is a unique 15

or 16 digit number allocated to each mobile staon equipment.
Start Time (start) Time of session start.
Elapsed Time (elapsed) Elapsed me of the session.
Tunnel Inspecon Rule Name of the tunnel inspecon rule matching the cleartext
tunnel traffic
(tunnel_insp_rule)
Remote User IP IPv4 or IPv6 address used by a remote user.

(remote_user_ip)
Remote User ID IMSI identy of a remote user, and if available, one IMEI
(remote_user_id) identy and/or one MSISDN identy.
UUID for rule (rule_uuid) Universally Unique ID for rule.
PCAP ID (pcap_id) Unique packet capture ID that is used to locate the pcap file
saved on the firewall.
Monitoring


1969-12-31T16:00:00:000-8:00
(nsdsai_sst)

(nsdsai_sd)

Applicaon Category The applicaon category specified in the applicaon

(category_of_app) configuraon properes. Values are:
• collaboraon
• media
• networking
• saas

• browser-based
• client-server
• peer-to-peer
Applicaon Risk (risk_of_app) Risk level associated with the applicaon (1=lowest to
5=highest).
Applicaon Characterisc Comma-separated list of applicable characterisc of the

(characterisc_of_app) applicaon
Monitoring

(container_of_app)

(is_saas_of_app)
Applicaon Sanconed State Displays 1 if applicaon is sanconed or 0 if applicaon is not

(sanconed_state_of_app) sanconed.

Syslog Severity
The syslog severity is set based on the log type and contents.
Log Type/Severity Syslog Severity
Traffic Info
Config Info
Threat/System— Info
Informaonal
Threat/System—Low Noce
Threat/System—Medium Warning
Threat/System—High Warning
Threat/System—Crical Crical
Custom Log/Event Format

To facilitate the integraon with external log parsing systems, the firewall allows you to customize
the log format; it also allows you to add custom Key: Value aribute pairs. Custom message
formats can be configured under Device > Server Profiles > Syslog > Syslog Server Profile >
Custom Log Format.
To achieve ArcSight Common Event Format (CEF) compliant log formang, refer to the CEF
Configuraon Guide.
Monitoring
Escape Sequences
Any field that contains a comma or a double-quote is enclosed in double quotes. Furthermore, if
a double-quote appears inside a field it is escaped by preceding it with another double-quote. To
maintain backward compability, the Misc field in threat log is always enclosed in double-quotes.
Monitoring
SNMP Monitoring and Traps

The following topics describe how Palo Alto Networks firewalls, Panorama, and WF-500
appliances implement SNMP, and the procedures to configure SNMP monitoring and trap delivery.
• SNMP Support
• Use an SNMP Manager to Explore MIBs and Objects
• Enable SNMP Services for Firewall-Secured Network Elements
• Monitor Stascs Using SNMP
• Forward Traps to an SNMP Manager
• Supported MIBs
SNMP Support
You can use an SNMP manager to monitor event-driven alerts and operaonal stascs for the
firewall, Panorama, or WF-500 appliance and for the traffic they process. The stascs and traps
can help you idenfy resource limitaons, system changes or failures, and malware aacks. You
configure alerts by forwarding log data as traps, and enable the delivery of stascs in response to
GET messages (requests) from your SNMP manager. Each trap and stasc has an object idenfier
(OID). Related OIDs are organized hierarchically within the Management Informaon Bases (MIBs)
that you load into the SNMP manager to enable monitoring.
When an event triggers SNMP trap generaon (for example, an interface goes down), the
firewall, Panorama virtual appliance, M-Series appliance, and WF-500 appliance respond
by updang the corresponding SNMP object (for example, the interfaces MIB) instead of
waing for the periodic update of all objects that occurs every ten seconds. This ensures
that your SNMP manager displays the latest informaon when polling an object to confirm
an event.
The firewall, Panorama, and WF-500 appliance support SNMP Version 2c and Version 3. Decide
which to use based on the version that other devices in your network support and on your
network security requirements. SNMPv3 is more secure and enables more granular access control
for system stascs than SNMPv2c. The following table summarizes the security features of each
version. You select the version and configure the security features when you Monitor Stascs
Using SNMP and Forward Traps to an SNMP Manager.
SNMPVersion
Authencaon Message Privacy MessageIntegrity
MIB Access Granularity
SNMPv2cCommunity string No (cleartext) No SNMP community access for all

MIBs on a device
SNMPv3 EngineID, username, Privacy Yes User access based on views that
and authencaon password for include or exclude specific OIDs
password (SHA AES (128,
hashing for the 192, or 256)
password) encrypon
Monitoring
SNMPVersion
Authencaon Message Privacy MessageIntegrity
MIB Access Granularity
of SNMP
messages
SNMP Implementaon illustrates a deployment in which firewalls forward traps to an SNMP

manager while also forwarding logs to Log Collectors. Alternavely, you could configure the Log
Collectors to forward the firewall traps to the SNMP manager. For details on these deployments,
refer to Log Forwarding Opons in Centralized Logging and Reporng. In all deployments, the
SNMP manager gets stascs directly from the firewall, Panorama, or WF-500 appliance. In this
example, a single SNMP manager collects both traps and stascs, though you can use separate
managers for these funcons if that beer suits your network.
Figure 2: SNMP Implementation
Use an SNMP Manager to Explore MIBs and Objects

To use SNMP for monitoring Palo Alto Networks firewalls, Panorama, or WF-500 appliances,
you must first load the Supported MIBs into your SNMP manager and determine which object
idenfiers (OIDs) correspond to the system stascs and traps you want to monitor. The following
topics provide an overview of how to find OIDs and MIBs in an SNMP manager. For the specific
steps to perform these tasks, refer to your SNMP management soware.
• Idenfy a MIB Containing a Known OID
Monitoring
• Walk a MIB
• Idenfy the OID for a System Stasc or Trap
Idenfy a MIB Containing a Known OID

If you already know the OID for a parcular SNMP object (stasc or trap) and want to know
the OIDs of similar objects so you can monitor them, you can explore the MIB that contains the
known OID.
STEP 1 | Load all the Supported MIBs into your SNMP manager.
STEP 2 | Search the enre MIB tree for the known OID. The search result displays the MIB path for
the OID, as well as informaon about the OID (for example, name, status, and descripon).
You can then select other OIDs in the same MIB to see informaon about them.
STEP 3 | (Oponal) Walk a MIB to display all its objects.
Walk a MIB
If you want to see which SNMP objects (system stascs and traps) are available for monitoring,
displaying all the objects of a parcular MIB can be useful. To do this, load the Supported
MIBs into your SNMP manager and perform a walk on the desired MIB. To list the traps
that Palo Alto Networks firewalls, Panorama, and WF-500 appliance support, walk the
panCommonEventEventsV2 MIB. In the following example, walking the PAN-COMMON-MIB.my
displays the following list of OIDs and their values for certain stascs:
Monitoring
Idenfy the OID for a System Stasc or Trap

To use an SNMP manager for monitoring Palo Alto Networks firewalls, Panorama, or WF-500
appliances, you must know the OIDs of the system stascs and traps you want to monitor.
STEP 1 | Review the Supported MIBs to determine which one contains the type of stasc you want.
For example, the PAN-COMMON-MIB.my contains hardware version informaon. The
panCommonEventEventsV2 MIB contains all the traps that Palo Alto Networks firewalls,
Panorama, and WF-500 appliances support.
STEP 2 | Open the MIB in a text editor and perform a keyword search. For example, using Hardware
version as a search string in PAN-COMMON-MIB idenfies the panSysHwVersion object:
panSysHwVersion OBJECT-TYPE
SYNTAX DisplayString (SIZE(0..128))
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Hardware version of the unit."
::= {panSys 2}
Monitoring
STEP 3 | In a MIB browser, search the MIB tree for the idenfied object name to display its OID. For
example, the panSysHwVersion object has an OID of 1.3.6.1.4.1.25461.2.1.2.1.2.
Enable SNMP Services for Firewall-Secured Network Elements

If you will use Simple Network Management Protocol (SNMP) to monitor or manage network
elements (for example, switches and routers) that are within the security zones of Palo Alto
Networks firewalls, you must create a security rule that allows SNMP services for those elements.
You don’t need a security rule to enable SNMP monitoring of Palo Alto Networks firewalls,
Panorama, or WF-500 appliances. For details, see Monitor Stascs Using SNMP.
STEP 1 | Create an applicaon group.

1. Select Objects > Applicaon Group and click Add.
2. Enter a Name to idenfy the applicaon group.
3. Click Add, type snmp, and select snmp and snmp-trap from the drop-down.
4. Click OK to save the applicaon group.
STEP 2 | Create a security rule to allow SNMP services.

2. In the General tab, enter a Name for the rule.
3. In the Source and Desnaon tabs, click Add and enter a Source Zone and a Desnaon
Zone for the traffic.
4. In the Applicaons tab, click Add, type the name of the applicaons group you just
created, and select it from the drop-down.
5. In the Acons tab, verify that the Acon is set to Allow, and then click OK and Commit.
Monitor Stascs Using SNMP

The stascs that a Simple Network Management Protocol (SNMP) manager collects from Palo
Alto Networks firewalls can help you gauge the health of your network (systems and connecons),
Monitoring
idenfy resource limitaons, and monitor traffic or processing loads. The stascs include
informaon such as interface states (up or down), acve user sessions, concurrent sessions,
session ulizaon, temperature, and system upme.
You can’t configure an SNMP manager to control Palo Alto Networks firewalls (using SET
messages), only to collect stascs from them (using GET messages). For details on how
SNMP is implemented for Palo Alto Networks firewalls, see SNMP Support.
STEP 1 | Configure the SNMP Manager to get stascs from firewalls.

The following steps provide an overview of the tasks you perform on the SNMP manager. For
the specific steps, refer to the documentaon of your SNMP manager.
1. To enable the SNMP manager to interpret firewall stascs, load the Supported MIBs for
Palo Alto Networks firewalls and, if necessary, compile them.
2. For each firewall that the SNMP manager will monitor, define the connecon sengs (IP
address and port) and authencaon sengs (SNMPv2c community string or SNMPv3
EngineID/username/password) for the firewall.
All Palo Alto Networks firewalls use port 161.
The SNMP manager can use the same or different connecon and authencaon
sengs for mulple firewalls. The sengs must match those you define when you
configure SNMP on the firewall (see Step 3). For example, if you use SNMPv2c, the
community string you define when configuring the firewall must match the community
string you define in the SNMP manager for that firewall.
3. Determine the object idenfiers (OIDs) of the stascs you want to monitor. For
example, to monitor the session ulizaon percentage of a firewall, a MIB browser shows
that this stasc corresponds to OID 1.3.6.1.4.1.25461.2.1.2.3.1.0 in PAN-COMMON-
MIB.my. For details, see Use an SNMP Manager to Explore MIBs and Objects.
4. Configure the SNMP manager to monitor the desired OIDs.
STEP 2 | Enable SNMP traffic on a firewall interface.

This is the interface that will receive stascs requests from the SNMP manager.
PAN-OS doesn’t synchronize management (MGT) interface sengs for firewalls in a

high availability (HA) configuraon. You must configure the interface for each HA peer.
Perform this step in the firewall web interface.

• To enable SNMP traffic on the MGT interface, select Device > Setup > Interfaces, edit the
Management interface, select SNMP, and then click OK and Commit.
• To enable SNMP traffic on any other interface, create an interface management profile for
SNMP services and assign the profile to the interface that will receive the SNMP requests.
The interface type must be Layer 3 Ethernet.
Monitoring
STEP 3 | Configure the firewall to respond to stascs requests from an SNMP manager.
PAN-OS doesn’t synchronize SNMP response sengs for firewalls in a high availability
(HA) configuraon. You must configure these sengs for each HA peer.
1. Select Device > Setup > Operaons and, in the Miscellaneous secon, click SNMP
Setup.
2. Select the SNMP Version and configure the authencaon values as follows. For version
details, see SNMP Support.
• V2c—Enter the SNMP Community String, which idenfies a community of SNMP
managers and monitored devices, and serves as a password to authencate the
community members to each other.
As a best pracce, don’t use the default community string public; it’s well
known and therefore not secure.
• V3—Create at least one SNMP view group and one user. User accounts and views
provide authencaon, privacy, and access control when firewalls forward traps and
SNMP managers get firewall stascs.
• Views—Each view is a paired OID and bitwise mask: the OID specifies a MIB and
the mask (in hexadecimal format) specifies which objects are accessible within
(include matching) or outside (exclude matching) that MIB. Click Add in the first list
and enter a Name for the group of views. For each view in the group, click Add and
configure the view Name, OID, matching Opon (include or exclude), and Mask.
• Users—Click Add in the second list, enter a username under Users, select the View
group from the drop-down, enter the authencaon password (Auth Password)
used to authencate to the SNMP manager, and enter the privacy password (Priv
Password) used to encrypt SNMP messages to the SNMP manager.
STEP 4 | Monitor the firewall stascs in an SNMP manager.

Refer to the documentaon of your SNMP manager for details.
When monitoring stascs related to firewall interfaces, you must match the interface
indexes in the SNMP manager with interface names in the firewall web interface.
For details, see Firewall Interface Idenfiers in SNMP Managers and NetFlow
Collectors.
Forward Traps to an SNMP Manager

Simple Network Management Protocol (SNMP) traps can alert you to system events (failures or
changes in hardware or soware of Palo Alto Networks firewalls) or to threats (traffic that matches
a firewall security rule) that require immediate aenon.
To see the list of traps that Palo Alto Networks firewalls support, use your SNMP Manager
to access the panCommonEventEventsV2 MIB. For details, see Use an SNMP Manager to
Explore MIBs and Objects.
For details on how for Palo Alto Networks firewalls implement SNMP, see SNMP Support.
Monitoring
STEP 1 | Enable the SNMP manager to interpret the traps it receives.

Load the Supported MIBs for Palo Alto Networks firewalls and, if necessary, compile them. For
the specific steps, refer to the documentaon of your SNMP manager.
STEP 2 | Configure an SNMP Trap server profile.

The profile defines how the firewall accesses the SNMP managers (trap servers). You can define
up to four SNMP managers for each profile.
Oponally, configure separate SNMP Trap server profiles for different log types,
severity levels, and WildFire verdicts.

2. Select Device > Server Profiles > SNMP Trap.
3. Click Add and enter a Name for the profile.
4. If the firewall has more than one virtual system (vsys), select the Locaon (vsys or
Shared) where this profile is available.
5. Select the SNMP Version and configure the authencaon values as follows. For version
details, see SNMP Support.
• V2c—For each server, click Add and enter the server Name, IP address (SNMP
Manager), and Community String. The community string idenfies a community of
SNMP managers and monitored devices, and serves as a password to authencate the
community members to each other.
As a best pracce, don’t use the default community string public; it’s well
known and therefore not secure.
• V3—For each server, click Add and enter the server Name, IP address (SNMP
Manager), SNMP User account (this must match a username defined in the SNMP
manager), EngineID used to uniquely idenfy the firewall (you can leave the field
blank to use the firewall serial number), authencaon password (Auth Password)
used to authencate to the server, and privacy password (Priv Password) used to
encrypt SNMP messages to the server.
STEP 3 | Configure log forwarding.

1. Configure the desnaons of Traffic, Threat, and WildFire traps:
1. Create a Log Forwarding profile. For each log type and each severity level or WildFire
verdict, select the SNMP Trap server profile.
2. Assign the Log Forwarding profile to policy rules and network zones. The rules and
zones will trigger trap generaon and forwarding.
2. Configure the desnaons for System, Configuraon, User-ID, HIP Match, and
Correlaon logs. For each log (trap) type and severity level, select the SNMP Trap server
profile.
3. Click Commit.
Monitoring
STEP 4 | Monitor the traps in an SNMP manager.

Refer to the documentaon of your SNMP manager.
When monitoring traps related to firewall interfaces, you must match the interface
indexes in the SNMP manager with interface names in the firewall web interface.
For details, see Firewall Interface Idenfiers in SNMP Managers and NetFlow
Collectors.
Supported MIBs
The following table lists the Simple Network Management Protocol (SNMP) management
informaon bases (MIBs) that Palo Alto Networks firewalls, Panorama, and WF-500 appliances
support. You must load these MIBs into your SNMP manager to monitor the objects (system
stascs and traps) that are defined in the MIBs. For details, see Use an SNMP Manager to
Explore MIBs and Objects.
MIB Type Supported MIBs
Standard—The Internet MIB-II

Engineering Task Force
IF-MIB
(IETF) maintains most
standard MIBs. You can HOST-RESOURCES-MIB
download the MIBs from the
ENTITY-MIB
IETF website.
ENTITY-SENSOR-MIB
Palo Alto
ENTITY-STATE-MIB
Networks
firewalls, IEEE 802.3 LAG MIB
Panorama,
LLDP-V2-MIB.my
and WF-500
appliances BFD-STD-MIB
don’t support
every object
(OID) in every
one of these
MIBs. See the
Supported
MIBs links for
an overview of
the supported
OIDs.
Enterprise—You can PAN-COMMON-MIB.my

download the enterprise
PAN-GLOBAL-REG-MIB.my
MIBs from the Palo Alto
Networks Technical PAN-GLOBAL-TC-MIB.my
Documentaon portal.
PAN-LC-MIB.my
Monitoring
MIB Type Supported MIBs

PAN-PRODUCT-MIB.my
PAN-ENTITY-EXT-MIB.my
PAN-TRAPS.my
MIB-II
MIB-II provides object idenfiers (OIDs) for network management protocols in TCP/IP-based
networks. Use this MIB to monitor general informaon about systems and interfaces. For example,
you can analyze trends in bandwidth usage by interface type (ifType object) to determine if the
firewall needs more interfaces of that type to accommodate spikes in traffic volume.
Palo Alto Networks firewalls, Panorama, and WF-500 appliances support only the following object
groups:
Object Group Descripon
system Provides system informaon such as the hardware model, system

upme, FQDN, and physical locaon.
interfaces Provides stascs for physical and logical interfaces such as type,
current bandwidth (speed), operaonal status (for example, up or
down), and discarded packets. Logical interface support includes VPN
tunnels, aggregate groups, Layer 2 subinterfaces, Layer 3 subinterfaces,
loopback interfaces, and VLAN interfaces.
RFC 1213 defines this MIB.
IF-MIB
IF-MIB supports interface types (physical and logical) and larger counters (64K) beyond those
defined in MIB-II. Use this MIB to monitor interface stascs in addion to those that MIB-
II provides. For example, to monitor the current bandwidth of high-speed interfaces (greater
than 2.2Gps) such as the 10G interfaces of the PA-5200 Series firewalls, you must check the
ifHighSpeed object in IF-MIB instead of the ifSpeed object in MIB-II. IF-MIB stascs can be
useful when evaluang the capacity of your network.
Palo Alto Networks firewalls, Panorama, and WF-500 appliances support only the ifXTable in IF-
MIB, which provides interface informaon such as the number of mulcast and broadcast packets
transmied and received, whether an interface is in promiscuous mode, and whether an interface
has a physical connector.
HOST-RESOURCES-MIB
HOST-RESOURCES-MIB provides informaon for host computer resources. Use this MIB
to monitor CPU and memory usage stascs. For example, checking the current CPU load
(hrProcessorLoad object) can help you troubleshoot performance issues on the firewall.
Monitoring
Palo Alto Networks firewalls, Panorama, and WF-500 appliances support porons of the following
object groups:
hrDevice Provides informaon such as CPU load, storage capacity, and paron
size. The hrProcessorLoad OIDs provide an average of the cores that
process packets.
For the PA-7000 and PA-5200 Series firewalls, which have mulple
dataplanes (DPs), you can monitor individual dataplane processor
ulizaon. Set alerts when ulizaon reaches a specific threshold for
each DP processor to avoid service availability issues.
hrSystem Provides informaon such as system upme, number of current user

sessions, and number of current processes.
hrStorage Provides informaon such as the amount of used storage.
ENTITY-MIB
ENTITY-MIB provides OIDs for mulple logical and physical components. Use this MIB to
determine what physical components are loaded on a system (for example, fans and temperature
sensors) and see related informaon such as models and serial numbers. You can also use the
index numbers for these components to determine their operaonal status in the ENTITY-
SENSOR-MIB and ENTITY-STATE-MIB.
Palo Alto Networks firewalls, Panorama, and WF-500 appliances support only porons of the
entPhysicalTable group:
Object Descripon
entPhysicalIndex A single namespace that includes disk slots and disk drives.
entPhysicalDescr The component descripon.
entPhysicalVendorTypeThe sysObjectID (see PAN-PRODUCT-MIB.my) when it is available

(chassis and module objects).
entPhysicalContainedInThe value of entPhysicalIndex for the component that contains this

component.
entPhysicalClass Chassis (3), container (5) for a slot, power supply (6), fan (7), sensor (8)
for each temperature or other environmental, and module (9) for each
line card.
Monitoring
Object Descripon
entPhysicalParentRelPos
The relave posion of this child component among its sibling
components. Sibling components are defined as entPhysicalEntry
components that share the same instance values of each of the
entPhysicalContainedIn and entPhysicalClass objects.
entPhysicalName Supported only if the management (MGT) interface allows for naming
the line card.
entPhysicalHardwareRev
The vendor-specific hardware revision of the component.
entPhysicalFirwareRev The vendor-specific firmware revision of the component.
entPhysicalSowareRevThe vendor-specific soware revision of the component.
entPhysicalSerialNum The vendor-specific serial number of the component.
entPhysicalMfgName The name of the manufacturer of the component.
entPhysicalMfgDate The date when the component was manufactured.
entPhysicalModelNameThe disk model number.
entPhysicalAlias An alias that the network manager specified for the component.
entPhysicalAssetID A user-assigned asset tracking idenfier that the network manager

specified for the component.
entPhysicalIsFRU Indicates whether the component is a field replaceable unit (FRU).
entPhysicalUris The Common Language Equipment Idenfier (CLEI) number of the

component (for example, URN:CLEI:CNME120ARA).
ENTITY-SENSOR-MIB
ENTITY-SENSOR-MIB adds support for physical sensors of networking equipment beyond what
ENTITY-MIB defines. Use this MIB in tandem with the ENTITY-MIB to monitor the operaonal
status of the physical components of a system (for example, fans and temperature sensors). For
example, to troubleshoot issues that might result from environmental condions, you can map
the enty indexes from the ENTITY-MIB (entPhysicalDescr object) to operaonal status values
(entPhysSensorOperStatus object) in the ENTITY-SENSOR-MIB. In the following example, all the
fans and temperature sensors for a PA-3020 firewall are working:
Monitoring
The same OID might refer to different sensors on different plaorms. Use the ENTITY-MIB
for the targeted plaorm to match the value to the descripon.
Palo Alto Networks firewalls, Panorama, and WF-500 appliances support only porons of the
entPhySensorTable group. The supported porons vary by plaorm and include only thermal
(temperature in Celsius) and fan (in RPM) sensors.
RFC 3433 defines the ENTITY-SENSOR-MIB.
ENTITY-STATE-MIB
ENTITY-STATE-MIB provides informaon about the state of physical components beyond what
ENTITY-MIB defines, including the administrave and operaonal state of components in chassis-
based plaorms. Use this MIB in tandem with the ENTITY-MIB to monitor the operaonal state
of the components of a PA-7000 Series firewall (for example, line cards, fan trays, and power
supplies). For example, to troubleshoot log forwarding issues for Threat logs, you can map the log
processing card (LPC) indexes from the ENTITY-MIB (entPhysicalDescr object) to operaonal state
values (entStateOper object) in the ENTITY-STATE-MIB. The operaonal state values use numbers
to indicate state: 1 for unknown, 2 for disabled, 3 for enabled, and 4 for tesng. The PA-7000
Series firewall is the only Palo Alto Networks firewall that supports this MIB.
RFC 4268 defines the ENTITY-STATE-MIB.
IEEE 802.3 LAG MIB

Use the IEEE 802.3 LAG MIB to monitor the status of aggregate groups that have Link
Aggregaon Control Protocol (LACP in an Aggregate Interface Group) enabled. When the firewall
logs LACP events, it also generates traps that are useful for troubleshoong. For example, the
traps can tell you whether traffic interrupons between the firewall and an LACP peer resulted
from lost connecvity or from mismatched interface speed and duplex values.
PAN-OS implements the following SNMP tables for LACP.
The dot3adTablesLastChanged object indicates the me of the most recent change to
dot3adAggTable, dot3adAggPortListTable, and dot3adAggPortTable.
Table Descripon
Aggregator This table contains informaon about every aggregate group that is
Configuraon Table associated with a firewall. Each aggregate group has one entry.
(dot3adAggTable)
Some table objects have restricons, which the dot3adAggIndex
object describes. This index is the unique idenfier that the local
Monitoring
Table Descripon
system assigns to the aggregate group. It idenfies an aggregate
group instance among the subordinate managed objects of the
containing object. The idenfier is read-only.
The ifTable MIB (a list of interface entries) does not support

logical interfaces and therefore does not have an entry for
the aggregate group.
Aggregaon This table lists the ports associated with each aggregate group in a
Port List Table firewall. Each aggregate group has one entry.
(dot3adAggPortListTable)
The dot3adAggPortListPorts aribute lists the complete set of ports
associated with an aggregate group. Each bit set in the list represents
a port member. For non-chassis plaorms, this is a 64-bit value. For
chassis plaorms, the value is an array of eight 64-bit entries.
Aggregaon Port Table This table contains LACP configuraon informaon about every port
(dot3adAggPortTable) associated with an aggregate group in a firewall. Each port has one
entry. The table has no entries for ports that are not associated with
an aggregate group.
LACP Stascs Table This table contains link aggregaon informaon about every port
(dot3adAggPortStatsTable)associated with an aggregate group in a firewall. Each port has one
row. The table has no entries for ports that are not associated with an
aggregate group.
The IEEE 802.3 LAG MIB includes the following LACP-related traps:
Trap Name Descripon
panLACPLostConnecvityTrap
The peer lost connecvity to the firewall.
panLACPUnresponsiveTrap The peer does not respond to the firewall.
panLACPNegoFailTrap LACP negoaon with the peer failed.
panLACPSpeedDuplexTrap The link speed and duplex sengs on the firewall and peer do not
match.
panLACPLinkDownTrap An interface in the aggregate group is down.
panLACPLacpDownTrap An interface was removed from the aggregate group.
panLACPLacpUpTrap An interface was added to the aggregate group.
Monitoring
For the MIB definions, refer to IEEE 802.3 LAG MIB.
LLDP-V2-MIB.my
Use the LLDP-V2-MIB to monitor Link Layer Discovery Protocol (LLDP) events. For example,
you can check the lldpV2StatsRxPortFramesDiscardedTotal object to see the number of LLDP
frames that were discarded for any reason. The Palo Alto Networks firewall uses LLDP to discover
neighboring devices and their capabilies. LLDP makes troubleshoong easier, especially for
virtual wire deployments where the ping or traceroute ulies won’t detect the firewall.
Palo Alto Networks firewalls support all the LLDP-V2-MIB objects except:
• The following lldpV2Stascs objects:
• lldpV2StatsRemTablesLastChangeTime
• lldpV2StatsRemTablesInserts
• lldpV2StatsRemTablesDeletes
• lldpV2StatsRemTablesDrops
• lldpV2StatsRemTablesAgeouts
• The following lldpV2RemoteSystemsData objects:
• The lldpV2RemOrgDefInfoTable table
• In the lldpV2RemTable table: lldpV2RemTimeMark
BFD-STD-MIB
Use the Bidireconal Forwarding Detecon (BFD) MIB to monitor and receive failure alerts for the
bidireconal path between two forwarding engines, such as interfaces, data links, or the actual
engines. For example, you can check the bfdSessState object to see the state of a BFD session
between forwarding engines. In the Palo Alto Networks implementaon, one of the forwarding
engines is a firewall interface and the other is an adjacent configured BFD peer.
PAN-COMMON-MIB.my
Use the PAN-COMMON-MIB to monitor the following informaon for Palo Alto Networks
firewalls, Panorama, and WF-500 appliances:
panSys Contains such objects as system soware/hardware versions, dynamic

content versions, serial number, HA mode/state, and global counters.
The global counters include those related to Denial of Service (DoS),
IP fragmentaon, TCP state, and dropped packets. Tracking these
counters enables you to monitor traffic irregularies that result from
DoS aacks, system or connecon faults, or resource limitaons. PAN-
COMMON-MIB supports global counters for firewalls but not for
Panorama.
Monitoring
panChassis Chassis type and M-Series appliance mode (Panorama or Log

Collector).
panSession Session ulizaon informaon. For example, the total number of acve
sessions on the firewall or a specific virtual system.
panMgmt Status of the connecon from the firewall to the Panorama

management server.
panGlobalProtect GlobalProtect gateway ulizaon as a percentage, maximum tunnels

allowed, and number of acve tunnels.
panLogCollector Logging stascs for each Log Collector, including logging rate, log
quotas, disk usage, retenon periods, log redundancy (enabled or
disabled), the forwarding status from firewalls to Log Collectors, the
forwarding status from Log Collectors to external services, and the
status of firewall-to-Log Collector connecons.
panDeviceLogging Logging stascs for each firewall, including logging rate, disk usage,
retenon periods, the forwarding status from individual firewalls
to Panorama and external servers, and the status of firewall-to-Log
Collector connecons.
PAN-GLOBAL-REG-MIB.my
PAN-GLOBAL-REG-MIB.my contains global, top-level OID definions for various sub-trees of Palo
Alto Networks enterprise MIB modules. This MIB doesn’t contain objects for you to monitor; it is
required only for referencing by other MIBs.
PAN-GLOBAL-TC-MIB.my
PAN-GLOBAL-TC-MIB.my defines convenons (for example, character length and allowed
characters) for the text values of objects in Palo Alto Networks enterprise MIB modules. All Palo
Alto Networks products use these convenons. This MIB doesn’t contain objects for you to
monitor; it is required only for referencing by other MIBs.
PAN-LC-MIB.my
PAN-LC-MIB.my contains definions of managed objects that Log Collectors (M-Series appliances
in Log Collector mode) implement. Use this MIB to monitor the logging rate, log database storage
duraon (in days), and disk usage (in MB) of each logical disk (up to four) on a Log Collector. For
example, you can use this informaon to determine whether you should add more Log Collectors
or forward logs to an external server (for example, a syslog server) for archiving.
PAN-PRODUCT-MIB.my
PAN-PRODUCT-MIB.my defines sysObjectID OIDs for all Palo Alto Networks products. This MIB
doesn’t contain objects for you to monitor; it is required only for referencing by other MIBs.
Monitoring
PAN-ENTITY-EXT-MIB.my
Use PAN-ENTITY-EXT-MIB.my in tandem with the ENTITY-MIB to monitor power usage
for the physical components of a PA-7000 Series firewall (for example, fan trays, and power
supplies), which is the only Palo Alto Networks firewall that supports this MIB. For example,
when troubleshoong log forwarding issues, you might want to check the power usage of the log
processing cards (LPCs): you can map the LPC indexes from the ENTITY-MIB (entPhysicalDescr
object) to values in the PAN-ENTITY-EXT-MIB (panEntryFRUModelPowerUsed object).
PAN-TRAPS.my
Use PAN-TRAPS.my to see a complete lisng of all the generated traps and informaon about
them (for example, a descripon). For a list of traps that Palo Alto Networks firewalls, Panorama,
and WF-500 appliances support, refer to the PAN-COMMON-MIB.my panCommonEvents >
panCommonEventsEvents > panCommonEventEventsV2 object.
Monitoring
Forward Logs to an HTTP/S Desnaon

The firewall and Panorama™ can forward logs to an HTTP/S server. You can choose to forward
all logs or specific logs to trigger an acon on an external HTTP-based service when an event
occurs. When forwarding logs to an HTTP server, configure the firewall to send an HTTP-based
API request directly to a third-party service to trigger an acon that is based on the aributes in a
firewall log. You can configure the firewall to work with any HTTP-based service that exposes an
API and you can modify the URL, HTTP header, parameters, and the payload in the HTTP request
to meet your integraon needs.
STEP 1 | Create an HTTP server profile to forward logs to an HTTP/S desnaon.
The HTTP server profile allows you to specify how to access the server and define the
format in which to forward logs to the HTTP/S desnaon. By default, the firewall uses the
management port to forward these logs. However, you can assign a different source interface
and IP address in Device > Setup > Services > Service Route Configuraon.
1. Select Device > Server Profiles > HTTP and Add a new profile.
2. Specify a Name for the server profile, and select the Locaon. The profile can be Shared
across all virtual systems or can belong to a specific virtual system.
3. Add the details for each server. Each profile can have a maximum of four servers.
4. Enter a Name and IP Address.
5. Select the Protocol (HTTP or HTTPS). The default Port is 80 or 443 respecvely but you
can modify the port number to match the port on which your HTTP server listens.
6. Select the TLS Version supported on the server—1.0, 1.1, or 1.2 (default).
7. Select the Cerficate Profile to use for the TLS connecon with the server.
8. Select the HTTP Method that the third-party service supports—DELETE,GET, POST
(default), or PUT.
9. (Oponal) Enter the Username and Password for authencang to the server, if needed.
10. (Oponal) Select Test Server Connecon to verify network connecvity between the
firewall and the HTTP/S server.
Monitoring
STEP 2 | Select the Payload Format for the HTTP request.

1. Select the Log Type link for each log type for which you want to define the HTTP request
format.
2. Select the Pre-defined Formats (available through content updates) or create a custom
format.
If you create a custom format, the URI is the resource endpoint on the HTTP service. The
firewall appends the URI to the IP address you defined earlier to construct the URL for
the HTTP request. Ensure that the URI and payload format matches the syntax that your
third-party vendor requires. You can use any aribute supported on the selected log type
within the HTTP Header, the Parameter and Value pairs, and in the request payload.
3. Send Test Log to verify that the HTTP server receives the request. When you
interacvely send a test log, the firewall uses the format as is and does not replace the
variable with a value from a firewall log. If your HTTP server sends a 404 response,
provide values for the parameters so that the server can process the request successfully.
Monitoring
STEP 3 | Define the match criteria for when the firewall will forward logs to the HTTP server and
aach the HTTP server profile you will use.
1. Select the log types for which you want to trigger a workflow:
• Add a Log Forwarding Profile (Objects > Log Forwarding) for logs that pertain to user
acvity (for example, Traffic, Threat, or Authencaon logs).
• Select Device > Log Sengs for logs that pertain to system events, such as
Configuraon or System logs.
2. Select the Log Type and use the new Filter Builder to define the match criteria.
3. Add the HTTP server profile for forwarding logs to the HTTP desnaon.
Monitoring
NetFlow Monitoring
NetFlow is an industry-standard protocol that the firewall can use to export stascs about the IP
traffic ingressing its interfaces. The firewall exports the stascs as NetFlow fields to a NetFlow
collector. The NetFlow collector is a server you use to analyze network traffic for security,
administraon, accounng and troubleshoong. All Palo Alto Networks firewalls support NetFlow
Version 9. The firewalls support only unidireconal NetFlow, not bidireconal. The firewalls
perform NetFlow processing on all IP packets on the interfaces and do not support sampled
NetFlow. You can export NetFlow records for Layer 3, Layer 2, virtual wire, tap, VLAN, loopback,
and tunnel interfaces. For aggregate Ethernet sub-interfaces, you can export records for the
individual sub-interfaces that data flows through within the group. To idenfy firewall interfaces in
a NetFlow collector, see Firewall Interface Idenfiers in SNMP Managers and NetFlow Collectors.
The firewalls support standard and enterprise (PAN-OS specific) NetFlow Templates, which
NetFlow collectors use to decipher the NetFlow fields.
• Configure NetFlow Exports
• NetFlow Templates
Configure NetFlow Exports

To use a NetFlow collector for analyzing the network traffic ingressing firewall interfaces, perform
the following steps to configure NetFlow record exports.
STEP 1 | Create a NetFlow server profile.
The profile defines which NetFlow collectors will receive the exported records and specifies
export parameters.
1. Select Device > Server Profiles > NetFlow and Add a profile.
3. Specify the rate at which the firewall refreshes NetFlow Templates in Minutes (default is
30) and Packets (exported records—default is 20), according to the requirements of your
NetFlow collector. The firewall refreshes the templates aer either threshold is passed.
4. Specify the Acve Timeout, which is the frequency in minutes at which the firewall
exports records (default is 5).
5. Select PAN-OS Field Types if you want the firewall to export App-ID and User-ID fields.
6. Add each NetFlow collector (up to two per profile) that will receive records. For each
collector, specify the following:
• Name to idenfy the collector.
• NetFlow Server hostname or IP address.
• Access Port (default 2055).
Monitoring
STEP 2 | Assign the NetFlow server profile to the firewall interfaces where traffic you want to analyze
is ingressing.
In this example, you assign the profile to an exisng Ethernet interface.
1. Select Network > Interfaces > Ethernet and click an interface name to edit it.
You can export NetFlow records for Layer 3, Layer 2, virtual wire, tap, VLAN,
loopback, and tunnel interfaces. For aggregate Ethernet interfaces, you can
export records for the individual sub-interfaces that data flows through within
the group.
2. Select the NetFlow server profile (NetFlow Profile) you configured and click OK.
STEP 3 | (Required for PA-7000 Series, PA-5400 Series, and PA-5200 Series firewalls) Configure a
service route for the interface that the firewall will use to send NetFlow records.
You cannot use the management (MGT) interface to send NetFlow records from the PA-7000
Series, PA-5400 Series, and PA-5200 Series firewalls. For other firewall models, a service route
is oponal. For all firewalls, the interface that sends NetFlow records does not have to be the
same as the interface for which the firewall collects the records.
2. (Firewall with mulple virtual systems) Select one of the following:
• Global—Select this opon if the service route applies to all virtual systems on the
firewall.
• Virtual Systems—Select this opon if the service route applies to a specific virtual
system. Set the Locaon to the virtual system.
3. Select Service Route Configuraon and Customize.
4. Select the protocol (IPv4 or IPv6) that the interface uses. You can configure the service
route for both protocols if necessary.
5. Click Nelow in the Service column.
6. Select the Source Interface.
Any, Use default, and MGT are not valid interface opons for sending NetFlow records
from PA-7000 Series, PA-5400 Series, or PA-5200 Series firewalls.
7. Select a Source Address (IP address).
8. Click OK twice to save your changes.
STEP 5 | Monitor the firewall traffic in a NetFlow collector.

Refer to your NetFlow collector documentaon.
When monitoring stascs, you must match the interface indexes in the NetFlow
collector with interface names in the firewall web interface. For details, see Firewall
Interface Idenfiers in SNMP Managers and NetFlow Collectors.
To troubleshoot NetFlow delivery issues, use the operaonal CLI command debug log-
receiver netflow statistics.
Monitoring
NetFlow Templates
NetFlow collectors use templates to decipher the fields that the firewall exports. The firewall
selects a template based on the type of exported data: IPv4 or IPv6 traffic, with or without
NAT, and with standard or enterprise-specific (PAN-OS specific) fields. The firewall periodically
refreshes templates to re-evaluate which one to use (in case the type of exported data changes)
and to apply any changes to the fields in the selected template. When you Configure NetFlow
Exports, set the refresh rate based on a me interval and a number of exported records according
to the requirements of your NetFlow collector. The firewall refreshes the templates aer either
threshold is passed.
The Palo Alto Networks firewall supports the following NetFlow templates:
Template ID
IPv4 Standard 256
IPv4 Enterprise 257
IPv6 Standard 258
IPv6 Enterprise 259
IPv4 with NAT Standard 260
IPv4 with NAT Enterprise 261
IPv6 with NAT Standard 262
IPv6 with NAT Enterprise 263
The following table lists the NetFlow fields that the firewall can send, along with the templates
that define them:
Value Field Descripon Templates
1 IN_BYTES Incoming counter with length N All templates

* 8 bits for the number of bytes
associated with an IP flow. By
default, N is 4.
2 IN_PKTS Incoming counter with length N * All templates

8 bits for the number of packets
associated with an IP glow. By
default, N is 4.
4 PROTOCOL IP protocol byte. All templates
Monitoring
5 TOS Type of Service byte seng when All templates

entering the ingress interface.
6 TCP_FLAGS Total of all the TCP flags in this All templates

flow.
7 L4_SRC_PORT TCP/UDP source port number All templates

(for example, FTP, Telnet, or
equivalent).
8 IPV4_SRC_ADDR IPv4 source address. IPv4 standard

IPv4 enterprise
IPv4 with NAT
standard
IPv4 with NAT
enterprise
10 INPUT_SNMP Input interface index. The value All templates

length is 2 bytes by default, but
higher values are possible. For
details on how Palo Alto Networks
firewalls generate interface
indexes, see Firewall Interface
Idenfiers in SNMP Managers and
NetFlow Collectors.
11 L4_DST_PORT TCP/UDP desnaon port number All templates

(for example, FTP, Telnet, or
equivalent).
12 IPV4_DST_ADDR IPv4 desnaon address. IPv4 standard

IPv4 enterprise
IPv4 with NAT
standard
IPv4 with NAT
enterprise
14 OUTPUT_SNMP Output interface index. The value All templates

length is 2 bytes by default, but
higher values are possible. For
details on how Palo Alto Networks
firewalls generate interface
indexes, see Firewall Interface
Monitoring

Idenfiers in SNMP Managers and
NetFlow Collectors.
21 LAST_SWITCHED System upme in milliseconds All templates

when the last packet of this flow
was switched.
22 FIRST_SWITCHED System upme in milliseconds All templates

when the first packet of this flow
was switched.
27 IPV6_SRC_ADDR IPv6 source address. IPv6 standard

IPv6 enterprise
IPv6 with NAT
standard
IPv6 with NAT
enterprise
28 IPV6_DST_ADDR IPv6 desnaon address. IPv6 standard

IPv6 enterprise
IPv6 with NAT
standard
IPv6 with NAT
enterprise
32 ICMP_TYPE Internet Control Message Protocol All templates

(ICMP) packet type. This is
reported as:
ICMP Type * 256 + ICMP code
61 DIRECTION Flow direcon: All templates

• 0 = ingress
• 1 = egress
148 flowId An idenfier of a flow that is All templates

unique within an observaon
domain. You can use this
informaon element to disnguish
between different flows if flow
keys such as IP addresses and port
numbers are not reported or are
reported in separate records. The
Monitoring

flowID corresponds to the session
ID field in Traffic and Threat logs.
233 firewallEvent Indicates a firewall event: All templates

• 0 = Ignore (invalid)—Not used.
• 1 = Flow created—The NetFlow
data record is for a new flow.
• 2 = Flow deleted—The NetFlow
data record is for the end of a
flow.
• 3 = Flow denied—The NetFlow
data record indicates a flow that
firewall policy denied.
• 4 = Flow alert—Not used.
• 5 = Flow update—The NetFlow
data record is sent for a long-
lasng flow, which is a flow that
lasts longer than the Acve
Timeout period configured in
the NetFlow server profile.
225 postNATSourceIPv4Address The definion of this informaon IPv4 with NAT

element is idencal to that of standard
sourceIPv4Address, except that it
IPv4 with NAT
reports a modified value that the
enterprise
firewall produced during network
address translaon aer the
packet traversed the interface.
226 postNATDesnaonIPv4Address
The definion of this informaon IPv4 with NAT
desnaonIPv4Address, except
IPv4 with NAT
that it reports a modified value
enterprise
that the firewall produced during
network address translaon aer
the packet traversed the interface.
227 postNAPTSourceTransportPort The definion of this informaon IPv4 with NAT

sourceTransportPort, except that it
IPv4 with NAT
enterprise
firewall produced during network
address port translaon aer the
packet traversed the interface.
Monitoring
228 postNAPTDesnaonTransportPort
desnaonTransportPort, except
IPv4 with NAT
enterprise
that the firewall produced during
network address port translaon
aer the packet traversed the
interface.
281 postNATSourceIPv6Address The definion of this informaon IPv6 with NAT

element is idencal to the standard
definion of informaon element
IPv6 with NAT
sourceIPv6Address, except that it
enterprise
firewall produced during NAT64
network address translaon aer
the packet traversed the interface.
See RFC 2460 for the definion of
the source address field in the IPv6
header. See RFC 6146 for NAT64
specificaon.
282 postNATDesnaonIPv6Address
element is idencal to the standard
definion of informaon element
IPv6 with NAT
desnaonIPv6Address, except
enterprise
that the firewall produced
during NAT64 network address
translaon aer the packet
traversed the interface. See RFC
2460 for the definion of the
desnaon address field in the
IPv6 header. See RFC 6146 for
NAT64 specificaon.
346 privateEnterpriseNumber This is a unique private enterprise IPv4 enterprise

number that idenfies Palo Alto
IPv4 with NAT
Networks: 25461.
enterprise
IPv6 enterprise
IPv6 with NAT
enterprise
Monitoring
56701App-ID The name of an applicaon that IPv4 enterprise

App-ID idenfied. The name can
IPv4 with NAT
be up to 32 bytes.
enterprise
IPv6 enterprise
IPv6 with NAT
enterprise
56702User-ID A username that User-ID IPv4 enterprise

idenfied. The name can be up to
IPv4 with NAT
64 bytes.
enterprise
IPv6 enterprise
IPv6 with NAT
enterprise
Monitoring
Firewall Interface Idenfiers in SNMP Managers and

NetFlow Collectors
When you use a NetFlow collector (see NetFlow Monitoring) or SNMP manager (see SNMP
Monitoring and Traps) to monitor the Palo Alto Networks firewall, an interface index (SNMP
ifindex object) idenfies the interface that carried a parcular flow (see Interface Indexes in an
SNMP Manager). In contrast, the firewall web interface uses interface names as idenfiers (for
example, ethernet1/1), not indexes. To understand which stascs that you see in a NetFlow
collector or SNMP manager apply to which firewall interface, you must be able to match the
interface indexes with interface names.
Figure 3: Interface Indexes in an SNMP Manager
You can match the indexes with names by understanding the formulas that the firewall uses to
calculate indexes. The formulas vary by plaorm and interface type: physical or logical.
Physical interface indexes have a range of 1-9999, which the firewall calculates as follows:
Firewall Plaorm Calculaon Example Interface Index
VM-Series Number of management ports + VM-100 firewall, Eth1/4 =

physical port offset
1 (number of management
• Number of management ports) + 4 (physical port) = 5
ports—This is a constant of 1.
• Physical port offset—This is
the physical port number.
PA-220, PA-220R, Number of management ports + PA-5200 Series firewall,

PA-800 Series physical port offset Eth1/4 =
• Number of management 5 (number of management
ports—This is a constant of 5. ports) + 4 (physical port) = 9
PA-3200 Series, Number of management ports + PA-5200 Series firewall,

PA-5200 Series physical port offset Eth1/4 =
• Number of management 4 (number of management
ports—This is a constant of 4. ports) + 4 (physical port) = 8
Monitoring
Firewall Plaorm Calculaon Example Interface Index

PA-7000 Series (Max. ports * slot) + physical port PA-7000 Series firewall,
offset + number of management Eth3/9 =
ports
[64 (max. ports) * 3 (slot)] + 9
• Maximum ports—This is a (physical port) + 5 (number of
constant of 64. management ports) = 206
• Slot—This is the chassis
slot number of the network
interface card.
• Number of management
ports—This is a constant of 5.
Logical interface indexes for all plaorms are nine-digit numbers that the firewall calculates as
follows:
Interface Range Digit Digits Digits Digits 1-4 Example Interface Index
Type 9 7-8 5-6
Layer 101010001-199999999
Type: Interface Interface Subinterface: Eth1/5.22 =
3 1 slot: port: suffix 100000000 (type) +
subinterface 1-9 1-9 1-9999 100000 (slot) + 50000
(01-09) (01-09) (0001-9999) (port) + 22 (suffix) =
101050022
Layer 101010001-199999999
Type: Interface Interface Subinterface: Eth2/3.6 = 100000000
2 1 slot: port: suffix (type) + 200000 (slot) +
subinterface 1-9 1-9 1-9999 30000 (port) + 6 (suffix)
(01-09) (01-09) (0001-9999) = 102030006
Vwire 101010001-199999999
Type: Interface Interface Subinterface: Eth4/2.312 =
subinterface 1 slot: port: suffix 100000000 (type) +
1-9 1-9 1-9999 400000 (slot) + 20000
(01-09) (01-09) (0001-9999) (port) + 312 (suffix) =
104020312
VLAN 200000001-200009999
Type: 00 00 VLAN VLAN.55 = 200000000
2 suffix: (type) + 55 (suffix) =
1-9999 200000055
(0001-9999)
Monitoring
Interface Range Digit Digits Digits Digits 1-4 Example Interface Index
Type 9 7-8 5-6
Loopback300000001-300009999
Type: 00 00 Loopback Loopback.55 =
3 suffix: 300000000 (type) + 55
1-9999 (suffix) = 300000055
(0001-9999)
Tunnel 400000001-400009999
Type: 00 00 Tunnel Tunnel.55 =
4 suffix: 400000000 (type) + 55
1-9999 (suffix) = 400000055
(0001-9999)
Aggregate500010001-500089999
Type: 00 AE Subinterface: AE5.99 = 500000000
group 5 suffix: suffix (type) + 50000 (AE
1-8 1-9999 Suffix) + 99 (suffix) =
(01-08) (0001-9999) 500050099
Monitoring
Monitor Transceivers
You can monitor the status of transceivers in your physical appliance or device to enable easier
installaon and troubleshoong. Diagnoscs that can be viewed are transmied bias current,
transmied power, received power, transceiver temperature, and power supply voltage. See below
for a list of devices that support transceiver monitoring.
• PA-800 Series
• PA-3200 Series
• PA-5200 Series
• PA-7000 Series
Use the Command Line Interface to run transceiver monitoring. See the following table for all
available CLI commands.
If you run commands on an incompable transceiver, the CLI will return 'n/a' for any
diagnosc informaon it cannot read.
CLI Definion
View a summary of the specified transceiver

show transceiver <interface nam with values for each diagnosc.
e>
Example:
admin@PA-7080> show transceiver

ethernet11/25
The CLI will return values for Temperature,

Voltage, Current, Tx Power, and Rx Power.
Receive more detailed transceiver

show transceiver-detail <interfa specificaons, including vendor informaon
ce name> and link lengths. The CLI will also provide
more detailed diagnosc informaon.
View a list of all acve transceivers as well as

show transceiver all a summary of each of their diagnoscs.
Get comprehensive details on each

show transceiver-detail all transceiver in the device.
Monitoring
User-ID
The user identy, as opposed to an IP address, is an integral component of an effecve
security infrastructure. Knowing who is using each of the applicaons on your
network, and who may have transmied a threat or is transferring files, can strengthen
security policies and reduce incident response mes. User-ID™, a standard feature on
the Palo Alto Networks firewall, enables you to leverage user informaon stored in a
wide range of repositories. The following topics provide more details about User-ID
and how to configure it:
> User-ID Overview

> User-ID Concepts
> Enable User-ID
> Map Users to Groups
> Map IP Addresses to Users
> Enable User- and Group-Based Policy
> Enable Policy for Users with Mulple Accounts
> Verify the User-ID Configuraon
> Deploy User-ID in a Large-Scale Network
653
User-ID
User-ID Overview
User-ID™ enables you to idenfy all users on your network using a variety of techniques to
ensure that you can idenfy users in all locaons using a variety of access methods and operang
systems, including Microso Windows, Apple iOS, Mac OS, Android, and Linux®/UNIX. Knowing
who your users are instead of just their IP addresses enables:
• Visibility—Improved visibility into applicaon usage based on users gives you a more relevant
picture of network acvity. The power of User-ID becomes evident when you noce a
strange or unfamiliar applicaon on your network. Using either ACC or the log viewer, your
security team can discern what the applicaon is, who the user is, the bandwidth and session
consumpon, along with the source and desnaon of the applicaon traffic, as well as any
associated threats.
• Policy control—Tying user informaon to Security policy rules improves safe enablement of
applicaons traversing the network and ensures that only those users who have a business
need for an applicaon have access. For example, some applicaons, such as SaaS applicaons
that enable access to Human Resources services (such as Workday or Service Now) must be
available to any known user on your network. However, for more sensive applicaons you can
reduce your aack surface by ensuring that only users who need these applicaons can access
them. For example, while IT support personnel may legimately need access to remote desktop
applicaons, the majority of your users do not.
• Logging, reporng, forensics—If a security incident occurs, forensics analysis and reporng
based on user informaon rather than just IP addresses provides a more complete picture of
the incident. For example, you can use the pre-defined User/Group Acvity to see a summary
of the web acvity of individual users or user groups, or the SaaS Applicaon Usage report to
see which users are transferring the most data over unsanconed SaaS applicaons.
To enforce user- and group-based policies, the firewall must be able to map the IP addresses in the
packets it receives to usernames. User-ID provides many mechanisms to collect this User Mapping
informaon. For example, the User-ID agent monitors server logs for login events and listens
for syslog messages from authencang services. To idenfy mappings for IP addresses that
the agent didn’t map, you can configure Authencaon Policy to redirect HTTP requests to an
Authencaon Portal login. You can tailor the user mapping mechanisms to suit your environment,
and even use different mechanisms at different sites to ensure that you are safely enabling access
to applicaons for all users, in all locaons, all the me.
User-ID
Figure 4: User-ID
To enable user- and group-based policy enforcement, the firewall requires a list of all available
users and their corresponding group memberships so that you can select groups when defining
your policy rules. The firewall collects Group Mapping informaon by connecng directly to your
LDAP directory server, or using XML API integraon with your directory server.
See User-ID Concepts for informaon on how User-ID works and Enable User-ID for instrucons
on seng up User-ID.
User-ID does not work in environments where the source IP addresses of users are subject
to NAT translaon before the firewall maps the IP addresses to usernames.
User-ID
User-ID Concepts
• Group Mapping
• User Mapping
Group Mapping
To define policy rules based on user or group, first you create an LDAP server profile that defines
how the firewall connects and authencates to your directory server. The firewall supports a
variety of directory servers, including Microso Acve Directory (AD), Novell eDirectory, and
Sun ONE Directory Server. The server profile also defines how the firewall searches the directory
to retrieve the list of groups and the corresponding list of members. If you are using a directory
server that is not navely supported by the firewall, you can integrate the group mapping funcon
using the XML API. You can then create a group mapping configuraon to Map Users to Groups
and Enable User- and Group-Based Policy.
Defining policy rules based on group membership rather than on individual users simplifies
administraon because you don’t have to update the rules whenever new users are added
to a group. When configuring group mapping, you can limit which groups will be available
in policy rules. You can specify groups that already exist in your directory service or define
custom groups based on LDAP filters. Defining custom groups can be quicker than creang new
groups or changing exisng ones on an LDAP server, and doesn’t require an LDAP administrator
to intervene. User-ID maps all the LDAP directory users who match the filter to the custom
group. For example, you might want a security policy that allows contractors in the Markeng
Department to access social networking sites. If no Acve Directory group exists for that
department, you can configure an LDAP filter that matches users for whom the LDAP aribute
Department is set to Markeng. Log queries and reports that are based on user groups will include
custom groups.
User Mapping
Knowing user and groups names is only one piece of the puzzle. The firewall also needs to know
which IP addresses map to which users so that security rules can be enforced appropriately.
User-ID Overview illustrates the different methods that are used to idenfy users and groups on
your network and shows how user mapping and group mapping work together to enable user-
and group-based security enforcement and visibility. The following topics describe the different
methods of user mapping:
• Server Monitoring
• Port Mapping
• Syslog
• XFF Headers
• Username Header Inseron
• Authencaon Policy and Authencaon Portal
• GlobalProtect
• XML API
User-ID
• Client Probing
Server Monitoring
With server monitoring a User-ID agent—either a Windows-based agent running on a domain
server in your network, or the PAN-OS integrated User-ID agent running on the firewall—monitors
the security event logs for specified Microso Exchange Servers, Domain Controllers, or Novell
eDirectory servers for login events. For example, in an AD environment, you can configure the
User-ID agent to monitor the security logs for Kerberos cket grants or renewals, Exchange server
access (if configured), and file and print service connecons. For these events to be recorded in
the security log, the AD domain must be configured to log successful account login events. In
addion, because users can log in to any of the servers in the domain, you must set up server
monitoring for all servers to capture all user login events. See Configure User Mapping Using the
Windows User-ID Agent or Configure User Mapping Using the PAN-OS Integrated User-ID Agent
for details.
Port Mapping
In environments with mul-user systems—such as Microso Terminal Server or Citrix
environments—many users share the same IP address. In this case, the user-to-IP address mapping
process requires knowledge of the source port of each client. To perform this type of mapping,
you must install the Palo Alto Networks Terminal Server Agent on the Windows/Citrix terminal
server itself to intermediate the assignment of source ports to the various user processes. For
terminal servers that do not support the Terminal Server agent, such as Linux terminal servers, you
can use the XML API to send user mapping informaon from login and logout events to User-ID.
See Configure User Mapping for Terminal Server Users for configuraon details.
XFF Headers
If you have a proxy server deployed between the users on your network and the firewall, the
firewall might see the proxy server IP address as the source IP address in HTTP/HTTPS traffic that
the proxy forwards rather than the IP address of the client that requested the content. In many
cases, the proxy server adds an X-Forwarded-For (XFF) header to traffic packets that includes the
actual IPv4 or IPv6 address of the client that requested the content or from whom the request
originated. In such cases, you can configure the firewall to extract the end user IP address from
the XFF so that User-ID can map the IP address to a username. This enables you to Use XFF
Values for Policies and Logging Source Users so that you can enforce user-based policy to safely
enable access to web-based for your users behind a proxy server.
Username Header Inseron

When you configure a secondary enforcement device with your Palo Alto Networks firewall
to enforce user-based policy, the secondary device may not have the IP address-to-username
mapping from the firewall. Transming the user’s identy to downstream devices may require
deployment of addional devices such as proxies or negavely impact the user’s experience (for
example, users having to log in mulple mes). You can dynamically add the domain and username
to the HTTP header of the user’s outgoing traffic, allowing any secondary devices that you use
with your Palo Alto Networks firewall to receive the user’s informaon and enforce user-based
policy. Including the user's identy by inserng the username and domain in the traffic headers
enables enforcement of user-based policy without negavely impacng the user's experience or
deployment of addional infrastructure.
User-ID
Authencaon Policy and Authencaon Portal

In some cases, the User-ID agent can’t map an IP address to a username using server monitoring
or other methods—for example, if the user isn’t logged in or uses an operang system such
as Linux that your domain servers don’t support. In other cases, you might want users to
authencate when accessing sensive applicaons regardless of which methods the User-
ID agent uses to perform user mapping. For all these cases, you can configure Configure
Authencaon Policy and Map IP Addresses to Usernames Using Authencaon Portal. Any
web traffic (HTTP or HTTPS) that matches an Authencaon policy rule prompts the user to
authencate through Authencaon Portal. You can use the following Authencaon Portal
Authencaon Methods:
• Browser challenge—Use Kerberos single sign-on if you want to reduce the number of login
prompts that users must respond to.
• Web form—Use Mul-Factor Authencaon, SAML single sign-on, Kerberos, TACACS+,
RADIUS, LDAP, or Local Authencaon.
• Client Cerficate Authencaon.
Syslog
Your environment might have exisng network services that authencate users. These services
include wireless controllers, 802.1x devices, Apple Open Directory servers, proxy servers, and
other Network Access Control (NAC) mechanisms. You can configure these services to send
syslog messages that contain informaon about login and logout events and configure the User-
ID agent to parse those messages. The User-ID agent parses for login events to map IP addresses
to usernames and parses for logout events to delete outdated mappings. Deleng outdated
mappings is parcularly useful in environments where IP address assignments change oen.
Both the PAN-OS integrated User-ID agent and Windows-based User-ID agent use Syslog Parse
profiles to parse syslog messages. In environments where services send the messages in different
formats, you can create a custom profile for each format and associate mulple profiles with
each syslog sender. If you use the PAN-OS integrated User-ID agent, you can also use predefined
Syslog Parse profiles that Palo Alto Networks provides through Applicaons content updates.
Syslog messages must meet the following criteria for a User-ID agent to parse them:
• Each message must be a single-line text string. The allowed delimiters for line breaks are a new
line (\n) or a carriage return plus a new line (\r\n).
• The maximum size for individual messages is 8,000 bytes.
• Messages sent over UDP must be contained in a single packet; messages sent over SSL can
span mulple packets. A single packet might contain mulple messages.
See Configure User-ID to Monitor Syslog Senders for User Mapping for configuraon details.
User-ID
Figure 5: User-ID Integration with Syslog
GlobalProtect
For mobile or roaming users, the GlobalProtect endpoint provides the user mapping informaon to
the firewall directly. In this case, every GlobalProtect user has an app running on the endpoint that
requires the user to enter login credenals for VPN access to the firewall. This login informaon
is then added to the User-ID user mapping table on the firewall for visibility and user-based
security policy enforcement. Because GlobalProtect users must authencate to gain access to
the network, the IP address-to-username mapping is explicitly known. This is the best soluon
in sensive environments where you must be certain of who a user is in order to allow access
to an applicaon or service. For more informaon on seng up GlobalProtect, refer to the
GlobalProtect Administrator’s Guide.
XML API
Authencaon Portal and the other standard user mapping methods might not work for
certain types of user access. For example, the standard methods cannot add mappings of users
connecng from a third-party VPN soluon or users connecng to a 802.1x-enabled wireless
network. For such cases, you can use the PAN-OS XML API to capture login events and send them
to the PAN-OS integrated User-ID agent. See Send User Mappings to User-ID Using the XML API
for details.
Client Probing
Palo Alto Networks strongly recommends disabling client probing because it is not a
recommended method of obtaining User-ID informaon in a high-security network.
Palo Alto Networks does not recommend using client probing due to the following potenal risks:
• Because client probing trusts data reported back from the endpoint, it can expose you to
security risks when misconfigured. If you enable it on external, untrusted interfaces, this
would cause the agent to send client probes containing sensive informaon such as the
username, domain name, and password hash of the User-ID agent service account outside
User-ID
of your network. If you do not configure the service account correctly, the credenals could
potenally be exploited by an aacker to penetrate the network to gain further access.
• Client probing was designed for legacy networks where most users were on Windows
workstaons on the internal network, but is not ideal for today’s more modern networks that
support a roaming and mobile user base on a variety of devices and operang systems.
• Client probing can generate a large amount of network traffic (based on the total number of
mapped IP addresses).
Instead, Palo Alto Networks strongly recommends using the following alternate methods for user
mapping:
• Using more isolated and trusted sources, such as domain controllers and integraons with
Syslog or the XML API, to safely capture user mapping informaon from any device type or
operang system.
• Configuring Authencaon Policy and Authencaon Portal to ensure that you only allow
access to authorized users.
The User-ID agent supports two types of client probing:
• NetBIOS probing, which uses the Windows User-ID agent.
• WMI probing, which uses either the PAN-OS integrated User-ID agent or the Windows User-
ID agent.
Client probing is not recommended as a user mapping method, but if you plan to enable
it, Palo Alto Networks strongly recommends using WMI probing over NetBIOS probing.
In a Microso Windows environment, you can configure the User-ID agent to probe client systems
using Windows Management Instrumentaon (WMI) or NetBIOS probing at regular intervals to
verify that an exisng user mapping is sll valid or to obtain the username for an IP address that is
not yet mapped.
If you do choose to enable probing in your trusted zones, the agent will probe each learned IP
address periodically (every 20 minutes by default, but this is configurable) to verify that the same
user is sll logged in. In addion, when the firewall encounters an IP address for which it has no
user mapping, it will send the address to the agent for an immediate probe.
See Configure User Mapping Using the Windows User-ID Agent or Configure User Mapping Using
the PAN-OS Integrated User-ID Agent for details.
User-ID
Enable User-ID
The user identy, as opposed to an IP address, is an integral component of an effecve security
infrastructure. Knowing who is using each of the applicaons on your network, and who may
have transmied a threat or is transferring files, can strengthen your security policy and reduce
incident response mes. User-ID enables you to leverage user informaon stored in a wide range
of repositories for visibility, user- and group-based policy control, and improved logging, reporng,
and forensics:
STEP 1 | Enable User-ID on the source zones that contain the users who will send requests that
require user-based access controls.
Enable User-ID on trusted zones only. If you enable User-ID and client probing on
an external untrusted zone (such as the internet), probes could be sent outside your
protected network, resulng in an informaon disclosure of the User-ID agent service
account name, domain name, and encrypted password hash, which could allow an
aacker to gain unauthorized access to protected services and applicaons.
1. Select Network > Zones and click the Name of the zone.
2. Enable User Idenficaon and click OK.
STEP 2 | Create a Dedicated Service Account for the User-ID Agent.
As a best pracce, create a service account with the minimum set of permissions
required to support the User-ID opons you enable to reduce your aack surface in the
event that the service account is compromised.
This is required if you plan to use the Windows-based User-ID agent or the PAN-OS integrated
User-ID agent to monitor domain controllers, Microso Exchange servers, or Windows clients
for user login and logout events.
STEP 3 | Map Users to Groups.

This enables the firewall to connect to your LDAP directory and retrieve Group Mapping
informaon so that you will be able to select usernames and group names when creang
policy.
User-ID
STEP 4 | Map IP Addresses to Users.
As a best pracce, do not enable client probing as a user mapping method on high-
security networks. Client probing can generate a large amount of network traffic and
can pose a security threat when misconfigured.
The way you do this depends on where your users are located and what types of systems they
are using, and what systems on your network are collecng login and logout events for your
users. You must configure one or more User-ID agents to enable User Mapping:
• Configure User Mapping Using the Windows User-ID Agent.
• Configure User Mapping Using the PAN-OS Integrated User-ID Agent.
• Configure User-ID to Monitor Syslog Senders for User Mapping.
• Configure User Mapping for Terminal Server Users.
• Send User Mappings to User-ID Using the XML API.
• Insert Username in HTTP Headers.
STEP 5 | Specify the networks to include and exclude from user mapping.
As a best pracce, always specify which networks to include and exclude from User-ID.
This allows you to ensure that only your trusted assets are probed and that unwanted
user mappings are not created unexpectedly.
The way you specify which networks to include and exclude depends on whether you are using
the Windows-based User-ID agent or the PAN-OSintegrated User-ID agent.
STEP 6 | Configure Authencaon Policy and Authencaon Portal.

The firewall uses Authencaon Portal to authencate end users when they request services,
applicaons, or URL categories that match Authencaon Policy rules. Based on user
informaon collected during authencaon, the firewall creates new user mappings or
updates exisng mappings. The mapping informaon collected during authencaon overrides
informaon collected through other User-ID methods.
1. Configure Authencaon Portal.
2. Configure Authencaon Policy.
User-ID
STEP 7 | Enable user- and group-based policy enforcement.
Create rules based on group rather than user whenever possible. This prevents you
from having to connually update your rules (which requires a commit) whenever your
user base changes.
Aer configuring User-ID, you will be able to choose a username or group name when defining
the source or desnaon of a security rule:
1. Select Policies > Security and Add a new rule or click an exisng rule name to edit.
2. Select User and specify which users and groups to match in the rule in one of the
following ways:
• If you want to select specific users or groups as matching criteria, click Add in the
Source User secon to display a list of users and groups discovered by the firewall
group mapping funcon. Select the users or groups to add to the rule.
• If you want to match any user who has or has not authencated and you don’t need
to know the specific user or group name, select known-user or unknown from the
drop-down above the Source User list.
3. Configure the rest of the rule as appropriate and then click OK to save it. For details on
other fields in the security rule, see Set Up a Basic Security Policy.
STEP 8 | Create the Security policy rules to safely enable User-ID within your trusted zones and
prevent User-ID traffic from egressing your network.
Follow the Best Pracce Internet Gateway Security Policy to ensure that the User-ID
applicaon (paloalto-userid-agent) is only allowed in the zones where your agents
(both your Windows agents and your PAN-OS integrated agents) are monitoring services and
distribung mappings to firewalls. Specifically:
• Allow the paloalto-userid-agent applicaon between the zones where your agents
reside and the zones where the monitored servers reside (or even beer, between the
specific systems that host the agent and the monitored servers).
• Allow the paloalto-userid-agent applicaon between the agents and the firewalls
that need the user mappings and between firewalls that are redistribung user mappings
and the firewalls they are redistribung the informaon to.
• Deny the paloalto-userid-agent applicaon to any external zone, such as your
internet zone.
STEP 9 | Configure the firewall to obtain user IP addresses from X-Forwarded-For (XFF) headers.
When the firewall is between the Internet and a proxy server, the IP addresses in the packets
that the firewall sees are for the proxy server rather than users. To enable visibility of user IP
addresses instead, configure the firewall to use the XFF headers for user mapping. With this
opon enabled, the firewall matches the IP addresses with usernames referenced in policy to
User-ID
enable control and visibility for the associated users and groups. For details, see Idenfy Users
Connected through a Proxy Server.
1. Select Device > Setup > Content-ID and edit the X-Forwarded-For Headers sengs.
2. Select X-Forwarded-For Header in User-ID.
Selecng Strip-X-Forwarded-For Header doesn’t disable the use of XFF headers

for user aribuon in policy rules; the firewall zeroes out the XFF value only
aer using it for user aribuon.
STEP 10 | If you use a high availability (HA) configuraon, enable synchronizaon.
As a best pracce, always enable the Enable Config Sync opon for an HA
configuraon to ensure that the group mappings and user mappings are synchronized
between the acve and passive firewall.
3. Select Enable Config Sync.
peer firewall.
6. Click OK.

Commit your changes to acvate them.
STEP 12 | Verify the User-ID Configuraon.

Aer you configure user mapping and group mapping, verify that the configuraon works
properly and that you can safely enable and monitor user and group access to your applicaons
and services.
User-ID
Map Users to Groups

Defining policy rules based on user group membership rather than individual users simplifies
administraon because you don’t have to update the rules whenever group membership changes.
The number of disnct user groups that each firewall or Panorama can reference across all policies
varies by model. For more informaon, refer to the Compability Matrix.
Use the following procedure to enable the firewall to connect to your LDAP directory and retrieve
Group Mapping informaon. You can then Enable User- and Group-Based Policy.
The following are best pracces for group mapping in an Acve Directory (AD)
environment:
• If you have a single domain, you need only one group mapping configuraon with an
LDAP server profile that connects the firewall to the domain controller with the best
connecvity. You can add up to four domain controllers to the LDAP server profile for
redundancy. Note that you cannot increase redundancy beyond four domain controllers
for a single domain by adding mulple group mapping configuraons for that domain.
• If you have mulple domains and/or mulple forests, you must create a group mapping
configuraon with an LDAP server profile that connects the firewall to a domain server
in each domain/forest. Take steps to ensure unique usernames in separate forests.
• If you have Universal Groups, create an LDAP server profile to connect to the root
domain of the Global Catalog server on port 3268 or 3269 for SSL, then create another
LDAP server profile to connect to the root domain controllers on port 389. This helps
ensure that users and group informaon is available for all domains and subdomains.
• Before using group mapping, configure a Primary Username for user-based security
policies, since this aribute will idenfy users in the policy configuraon, logs, and
reports.
User-ID
STEP 1 | Add an LDAP server profile.

The profile defines how the firewall connects to the directory servers from which it collects
group mapping informaon.
If you create mulple group mapping configuraons that use the same base
disnguished name (DN) or LDAP server, the group mapping configuraons cannot
contain overlapping groups (for example, the Include list for one group mapping
configuraon cannot contain a group that is also in a different group mapping
configuraon).
1. Select Device > Server Profiles > LDAP and Add a server profile.
3. Add the LDAP servers. You can add up to four servers to the profile but they must be
the same Type. For each server, enter a Name (to idenfy the server), LDAP Server IP
address or FQDN, and server Port (default 389).
4. Select the server Type.
Based on your selecon (such as acve-directory), the firewall automacally populates
the correct LDAP aributes in the group mapping sengs. However, if you customized
your LDAP schema, you might need to modify the default sengs.
5. For the Base DN, enter the Disnguished Name (DN) of the LDAP tree locaon where
you want the firewall to start searching for user and group informaon.
6. For the Bind DN, Password and Confirm Password, enter the authencaon credenals
for binding to the LDAP tree.
The Bind DN can be a fully qualified LDAP name (such as
cn=administrator,cn=users,dc=acme,dc=local) or a user principal name (such
as [email protected]).
7. Enter the Bind Timeout and Search Timeout in seconds (default is 30 for both).
STEP 2 | Configure the server sengs in a group mapping configuraon.

1. Select Device > User Idenficaon > Group Mapping Sengs.
2. Add the group mapping configuraon.
3. Enter a unique Name to idenfy the group mapping configuraon.
4. Select the LDAP Server Profile you just created.
5. (Oponal) Specify the Update Interval (in seconds). Enter a value (range is 60—86400,
default is 3600) based on how oen the firewall should be check the LDAP source for
updates to the group mapping configuraon. If the LDAP source contains many groups, a
value that is too low may not allow enough me to map all the groups.
6. (Oponal) By default, the User Domain field is blank: the firewall automacally detects
the domain names for Acve Directory (AD) servers. If you enter a value, it overrides any
domain names that the firewall retrieves from the LDAP source. For most configuraons,
User-ID
if you need to enter a value, enter the NetBIOS domain name (for example, example not
example.com).
If you use Global Catalog, entering a value replaces the domain name for all users and
groups from this server, including those from other domains.
7. (Oponal) To filter the groups that the firewall tracks for group mapping, in the Group
Objects secon, enter a Search Filter (LDAP query) and Object Class (group definion).
8. (Oponal) To filter the users that the firewall tracks for group mapping, in the User
Objects secon, enter a Search Filter (LDAP query), and Object Class (user definion).
9. Make sure the group mapping configuraon is Enabled (default is enabled).
STEP 3 | (Oponal) Define User and Group Aributes to collect for user and group mapping. This step
is required if you want to map users based on directory aributes other than the domain.
1. If your User-ID sources only send the username and the username is unique across the
organizaon, select Device > User Idenficaon > User Mapping > Setup and Edit the
Setup secon to Allow matching usernames without domains to allow the firewall to
check if unique usernames collected from the LDAP server during group mapping match
the users associated with a policy and avoid overwring the domain in your source
profile.
Before enabling this opon, configure group mapping for the LDAP group
containing the User-ID source (such as GlobalProtect or Authencaon Portal)
that collects the mappings. Aer you commit the changes, the User-ID source
populates the usernames without domains. Only usernames collected during
group mapping can be matched without a domain. If your User-ID sources send
user informaon in mulple formats and you enable this opon, verify that the
aributes collected by the firewall have a unique prefix. To ensure users are
idenfied correctly if you enable this opon, all aributes for group mapping
should be unique. If the username is not unique, the firewall logs an error in the
Debug logs.
2. Select Device > User Idenficaon > Group Mapping Sengs > Add > User and Group
Aributes > User Aributes and enter the Directory Aribute you want to collect for
user idenficaon. Specify a Primary Username to idenfy the user on the firewall and
User-ID
to represent the user in reports and logs that will override any other format the firewall
receives from the User-ID source.
When you select the Server Profile Type, the firewall auto-populates the values for the
user and group aributes. Based on the user informaon that your User-ID sources send,
you may need to configure the correct aributes:
• User Principal Name (UPN): userPrincipalName
• NetBios Name: sAMAccountName
• Email ID: Directory aribute for that email
• Mulple formats: Retrieve the user mapping aributes from the user directory before
enabling your User-ID sources.
If you do not specify a primary username, the firewall uses the following default values
for each server profile type:
Aribute Acve Directory Novell eDirectory or Sun ONE

Directory Server
Primary Username sAMAccountName uid
E-Mail mail mail
Alternate Username 1 userPrincipalName None.
Group Name name cn
Group Member member member
3. (Oponal) Specify an E-Mail address format and up to three Alternate Username

formats.
4. Select Device > User Idenficaon > Group Mapping Sengs > Add > User and Group
Aributes > Group Aributes and specify the Group Name, Group Member, and E-Mail
address formats.
You must commit before the firewall collects the directory aributes from the LDAP
server.
STEP 4 | Limit which groups will be available in policy rules.

Required only if you want to limit policy rules to specific groups. The combined maximum for
the Group Include List and Custom Group list is 640 entries per group mapping configuraon.
User-ID
Each entry can be a single group or a list of groups. By default, if you don’t specify groups, all
groups are available in policy rules.
Any custom groups you create will also be available in the Allow List of authencaon
profiles (Configure an Authencaon Profile and Sequence).
1. Add exisng groups from the directory service:

1. Select Group Include List.
2. Select the Available Groups you want to appear in policy rules and add ( ) them to
the Included Groups.
2. If you want to base policy rules on user aributes that don’t match exisng user groups,
create custom groups based on LDAP filters:
1. Select Custom Group and Add the group.
2. Enter a group Name that is unique in the group mapping configuraon for the current
firewall or virtual system.
If the Name has the same value as the Disnguished Name (DN) of an exisng AD
group domain, the firewall uses the custom group in all references to that name (such
as in policies and logs).
3. Specify an LDAP Filter of up to 2,048 UTF-8 characters and click OK.
The firewall doesn’t validate LDAP filters, so it’s up to you to ensure they are accurate.
To minimize the performance impact on the LDAP directory server, use only
indexed aributes in the filter.
You must commit before custom groups will be available in policies and objects.

You must commit before you can use custom groups in policies and objects and before the
firewall can collect the aributes from the LDAP server.
Aer configuring the firewall to retrieve group mapping informaon from an LDAP
server, but before configuring policies based on the groups it retrieves, the best pracce
is to either wait for the firewall to refresh its group mappings cache or refresh the cache
manually. To verify which groups you can currently use in policies, access the firewall
CLI and run the show user group command. To determine when the firewall will
next refresh the group mappings cache, run the show user group-mapping
statistics command and check the Next Action. To manually refresh the
cache, run the debug user-id refresh group-mapping all command.
User-ID
STEP 6 | Verify that the user and group mapping has correctly idenfied users.
1. Select Device > User Idenficaon > Group Mapping > Group Include List to confirm
the firewall has fetched all of the groups.
2. To verify that all of the user aributes have been correctly captured, use the following
CLI command:
show user user-attributes user all
The normalized format for the User Principal Name (UPN), primary username, email
aributes, and any configured alternate usernames display for all users:
[email protected]> show user user-attributes user all
Primary: nam\sam-user Email: [email protected]
Alt User Names:1) nam.com\sam-user
2) nam\sam-user-upn
3) [email protected]
4) [email protected]
3. Verify that the usernames are correctly displayed in the Source User column under
Monitor > Logs > Traffic.
User-ID
4. Verify that the users are mapped to the correct usernames in the User Provided by
Source column under Monitor > Logs > User-ID.
User-ID
Map IP Addresses to Users

User-ID provides many different methods for mapping IP addresses to usernames. Before you
begin configuring user mapping, consider where your users are logging in from, what services they
are accessing, and what applicaons and data you need to control access to. This will inform which
types of agents or integraons would best allow you to idenfy your users.
Once you have your plan, you can begin configuring user mapping using one or more of the
following methods as needed to enable user-based access and visibility to applicaons and
resources:
If you have users with client systems that aren’t logged in to your domain servers—for example,
users running Linux clients that don’t log in to the domain—you can Map IP Addresses to
Usernames Using Authencaon Portal. Using Authencaon Portal in conjuncon with
Authencaon Policy also ensures that all users authencate to access your most sensive
applicaons and data.
To map users as they log in to your Exchange servers, domain controllers, eDirectory servers, or
Windows clients you must configure a User-ID agent:
• Configure User Mapping Using the PAN-OS Integrated User-ID Agent
• Configure User Mapping Using the Windows User-ID Agent
If you have clients running mul-user systems in a Windows environment, such as Microso
Terminal Server or Citrix Metaframe Presentaon Server or XenApp, Configure the Palo Alto
Networks Terminal Server (TS) Agent for User Mapping. For a mul-user system that doesn’t
run on Windows, you can Retrieve User Mappings from a Terminal Server Using the PAN-OS
XML API.
To obtain user mappings from exisng network services that authencate users—such as
wireless controllers, 802.1x devices, Apple Open Directory servers, proxy servers, or other
Network Access Control (NAC) mechanisms—Configure User-ID to Monitor Syslog Senders for
User Mapping.
While you can configure either the Windows agent or the PAN-OS integrated User-
ID agent on the firewall to listen for authencaon syslog messages from the network
services, because only the PAN-OS integrated agent supports syslog listening over TLS,
it is the preferred configuraon.
To include the username and domain in the headers for outgoing traffic so other devices in your
network can idenfy the user and enforce user-based policy, you can Insert Username in HTTP
Headers.
To Share User-ID Mappings Across Virtual Systems, you can configure a virtual system as a
User-ID hub.
For other clients that you can’t map using the other methods, you can Send User Mappings to
User-ID Using the XML API.
A large-scale network can have hundreds of informaon sources that firewalls query for
user and group mapping and can have numerous firewalls that enforce policies based on
the mapping informaon. You can simplify User-ID administraon for such a network by
aggregang the mapping informaon before the User-ID agents collect it. You can also reduce
the resources that the firewalls and informaon sources use in the querying process by
User-ID
configuring some firewalls to redistribute the mapping informaon. For details, see Deploy
User-ID in a Large-Scale Network.
Create a Dedicated Service Account for the User-ID Agent

To use the Windows-based User-ID agent or the PAN-OS integrated User-ID agent to map users
as they log in to your Exchange servers, domain controllers, eDirectory servers, or Windows
clients, create a dedicated service account for the User-ID agent on a domain controller in each
domain that the agent will monitor.
The User-ID agent maps users based on logs for security events. To ensure that the User-ID agent
can successfully map users, verify that the source for your mappings generates logs for Audit
Logon, Audit Kerberos Authencaon Service, and Audit Kerberos Service Ticket Operaons
events. At a minimum, the source must generate logs for the following events:
• Logon Success (4624)
• Authencaon Ticket Granted (4768)
• Service Ticket Granted (4769)
• Ticket Granted Renewed (4770)
The required permissions for the service account depend on the user mapping methods and
sengs you plan to use. For example, if you are using the PAN-OS integrated User-ID agent, the
service account requires Server Operator privileges to monitor user sessions. If you are using the
Windows-based User-ID agent, the service account does not require Server Operator privileges
to monitor user sessions. To reduce the risk of compromising the User-ID service account, always
configure the account with the minimum set of permissions necessary for the agent.
• If you are installing the Windows-based User-ID agent on a supported Windows server,
Configure a Service Account for the Windows User-ID Agent.
• If you are using the PAN-OS integrated User-ID agent on the firewall, Configure a Service
Account for the PAN-OS Integrated User-ID Agent.
User-ID provides many methods for safely collecng user mapping informaon. Some
legacy features designed for environments that only required user mapping on Windows
desktops aached to the local network require privileged service accounts. If the privileged
service account is compromised, this would open your network to aack. As a best
pracce, avoid using legacy features that require privileges that would pose a threat if
compromised, such as client probing and session monitoring.
Configure a Service Account for the Windows User-ID Agent

Create a dedicated Acve Directory (AD) service account for the Windows User-ID agent to
access the services and hosts it will monitor to collect user mappings. You must create a service
account in each domain the agent will monitor. Aer you enable the required permissions for the
service account, Configure User Mapping Using the Windows User-ID Agent.
The following workflow details all required privileges and provides guidance for the User-
ID features which require privileges that could pose a threat so that you can decide how to
best idenfy users without compromising your overall security posture.
User-ID
STEP 1 | Create an AD service account for the User-ID agent.

You must create a service account in each domain the agent will monitor.
1. Log in to the domain controller.
2. Right-click the Windows icon ( ), Search for Active Directory Users and
Computers, and launch the applicaon.
3. In the navigaon pane, open the domain tree, right-click Managed Service Accounts and
select New > User.
4. Enter the First Name, Last Name, and User logon name of the user and click Next.
5. Enter the Password and Confirm Password, then click Next and Finish.
User-ID
STEP 2 | Configure either local or group policy to allow the service account to log on as a service.
The permission to log on as a service is only needed locally on the Windows server that is the
agent host.
• To assign permissions locally:
1. select Control Panel > Administrave Tools > Local Security Policy.
2.
3. Select Local Policies > User Rights Assignment > Log on as a service.
4. Add User or Group to add the service account.
User-ID
5. Enter the object names to select (the service account name) in domain\username
format and click OK.
• To configure group policy if you are installing Windows User-ID agents on mulple servers,
use the Group Policy Management Editor.
1. Select Start > Group Policy Management > <your domain> > Default Domain Policy >
Acon > Edit for the Windows server that is the agent host.
2. Select Computer Configuraon > Policies > Windows Sengs > Security Sengs >
Local Policies > User Rights Assignment.
User-ID
3. Right-click Log on as a service, then select Properes.

4. Add User or Group to add the service account username or builn group, then click OK
twice.
Administrators have this privilege by default.
STEP 3 | If you want to use WMI to collect user data, assign DCOM privileges to the service account
so that it can use WMI queries on monitored servers.
1. Select Acve Directory Users and Computers > <your domain> > Builn > Distributed
COM Users.
2. Right-click Properes > Members > Add and enter the service account name.
User-ID
STEP 4 | If you plan to use WMI probing, enable the account to read the CIMV2 namespace and
assign the required permissions on the client systems to be probed.
Do not enable client probing on high-security networks. Client probing can generate
a large amount of network traffic and can pose a security threat when misconfigured.
Instead collect user mapping informaon from more isolated and trusted sources, such
as domain controllers and through integraons with Syslog or the XML API, which have
the added benefit of allowing you to safely capture user mapping informaon from any
device type or operang system, instead of just Windows clients.
Perform this task on each client system that the User-ID agent will probe for user mapping
informaon:
1. Right-click the Windows icon ( ), Search for wmimgmt.msc, and launch the WMI
Management Console.
2. In the console tree, right-click WMI Control and select Properes.
3. Select the Security tab, then select Root > CIMV2, and click the Security buon.
4. Add the name of the service account you created, Check Names to verify your entry, and
click OK.
You might have to change the Locaons or click Advanced to query for account
names. See the dialog help for details.
User-ID
5. In the Permissions for <Username> secon, Allow the Enable Account and Remote
Enable permissions.
6. Click OK twice.
7. Use the Local Users and Groups MMC snap-in (lusrmgr.msc) to add the service account
to the local Distributed Component Object Model (DCOM) Users and Remote Desktop
Users groups on the system that will be probed.
User-ID
STEP 5 | If you want to use Server Monitoring to idenfy users, add the service account to the Event
Log Reader builn group to allow the service account to read the security log events.
1. On the domain controller or Exchange server that contains the logs you want the User-
ID agent to read, or on the member server that receives events from Windows log
forwarding, select Start > Run, enter MMC.
2. Select File > Add/Remove Snap-in > Acve Directory Users and Computers > Add, then
click OK to run the MMC and launch the Acve Directory Users and Computers snap-in.
3. Navigate to the Builn folder for the domain, right-click the Event Log Readers group,
and select Properes > Members.
4. Add the service account then click Check Names to validate that you have the proper
object name.
User-ID
5. Click OK twice to save the sengs.

6. Confirm that the builn Event Log Reader group lists the service account as a member
(Event Log Readers > Properes > Members).
User-ID
STEP 6 | Assign account permissions to the installaon folder to allow the service account to access
the agent’s installaon folder to read the configuraon and write logs.
You only need to perform this step if the service account you configured for the User-ID agent
is not either a domain administrator or a local administrator on the User-ID agent server host.
1. From the Windows Explorer, navigate to C:\Program Files(x86)\Palo Alto
Networks, right-click the folder, and select Properes.
2. On the Security tab, click Edit.
3. Add the User-ID agent service account and Allow permissions to Modify, Read &
execute, List folder contents, Read, and Write, and then click OK to save the account
sengs.
If you do not want to configure individual permissions, you can Allow the Full
Control permission instead.
User-ID
STEP 7 | To allow the agent to make configuraon changes (for example, if you select a different
logging level), give the service account permissions to the User-ID agent registry sub-tree.
1. Select Start > Run and enter regedt32 and navigate to the Palo Alto Networks sub-tree
in one of the following locaons:
• 32-bit systems—HKEY_LOCAL_MACHINE\Software\Palo Alto Networks
• 64-bit systems—HKEY_LOCAL_MACHINE\Software\WOW6432Node\PaloAlto
Networks
2. Right-click the Palo Alto Networks node and select Permissions.
3. Assign the User-ID service account Full Control and then click OK to save the seng.
User-ID
STEP 8 | Disable service account privileges that are not required.

By ensuring that the User-ID service account has the minimum set of account privileges, you
can reduce the aack surface should the account be compromised.
To ensure that the User-ID account has the minimum privileges necessary, deny the following
privileges on the account.
• Deny interacve logon for the User-ID service account—While the User-ID service account
does need permission to read and parse Acve Directory security event logs, it does not
require the ability to logon to servers or domain systems interacvely. You can restrict this
User-ID
privilege using Group Policies or by using a Managed Service account (refer to Microso
TechNet for more informaon).
1. Select Group Policy Management Editor > Default Domain Policy > Computer
Configuraon > Policies > Windows Sengs > Security Sengs > User Rights
Assignment.
2. For Deny log on as a batch job, Deny log on locally, and Deny log on through Remote
Desktop Services, right-click Properes.
3. Select Define these policy sengs > Add User or Group and add the service account
name, then click OK.
• Deny remote access for the User-ID service account—This prevents an aacker from using
the account to access your network from the outside the network.
1. Select Start > Run, enter MMC, and select File > Add/Remove Snap-in > Acve Directory
Users and Computers > Users.
2. Right-click the service account name, then select Properes.
3. Select Dial-in, then Deny the Network Access Permission.
User-ID
STEP 9 | As a next step, Configure User Mapping Using the Windows User-ID Agent.
Configure a Service Account for the PAN-OS Integrated User-ID Agent

Create a dedicated Acve Directory (AD) service account for the PAN-OS Integrated User-ID
agent to access the services and hosts it will monitor to collect user mappings.You must create a
service account in each domain the agent will monitor. Aer you enable the required permissions
for the service account, Configure User Mapping Using the PAN-OS Integrated User-ID Agent.
The following workflow details all required privileges and provides guidance for the User-
ID features which require privileges that could pose a threat so that you can decide how to
best idenfy users without compromising your overall security posture.
STEP 1 | Create an AD service account for the User-ID agent.

You must create a service account in each domain the agent will monitor.
1. Log in to the domain controller.
2. Right-click the Windows icon ( ), Search for Active Directory Users and
Computers, and launch the applicaon.
3. In the navigaon pane, open the domain tree, right-click Managed Service Accounts and
select New > User.
4. Enter the First Name, Last Name, and User logon name of the user and click Next.
5. Enter the Password and Confirm Password, then click Next and Finish.
User-ID
STEP 2 | If you want to use Server Monitoring to idenfy users, add the service account to the Event
Log Reader builn group to allow the service account to read the security log events.
1. On the domain controller or Exchange server that contains the logs you want the User-
ID agent to read, or on the member server that receives events from Windows log
forwarding, select Start > Run, enter MMC.
2. Select File > Add/Remove Snap-in > Acve Directory Users and Computers > Add, then
click OK to run the MMC and launch the Acve Directory Users and Computers snap-in.
3. Navigate to the Builn folder for the domain, right-click the Event Log Readers group,
and select Properes > Members.
4. Add the service account then click Check Names to validate that you have the proper
object name.
User-ID

6. Confirm that the builn Event Log Reader group lists the service account as a member
(Event Log Readers > Properes > Members).
STEP 3 | If you want to use WMI to collect user data, assign DCOM privileges to the service account
so that it can use WMI queries on monitored servers.
1. Select Acve Directory Users and Computers > <your domain> > Builn > Distributed
COM Users.
2. Right-click Properes > Members > Add and enter the service account name.
User-ID
STEP 4 | If you plan to use WMI probing, enable the service account to read the CIMV2 namespace on
the domain controllers you want to monitor and assign the required permissions on the client
systems to be probed.
Do not enable client probing on high-security networks. Client probing can generate
a large amount of network traffic and can pose a security threat when misconfigured.
Instead collect user mapping informaon from more isolated and trusted sources, such
as domain controllers and through integraons with Syslog or the XML API, which have
the added benefit of allowing you to safely capture user mapping informaon from any
device type or operang system, instead of just Windows clients.
Perform this task on each client system that the User-ID agent will probe for user mapping
informaon:
1. Right-click the Windows icon ( ), Search for wmimgmt.msc, and launch the WMI
Management Console.
2. In the console tree, right-click WMI Control and select Properes.
3. Select the Security tab, then select Root > CIMV2, and click the Security buon.
4. Add the name of the service account you created, Check Names to verify your entry, and
click OK.
You might have to change the Locaons or click Advanced to query for account
names. See the dialog help for details.
User-ID
5. In the Permissions for <Username> secon, Allow the Enable Account and Remote
Enable permissions.
6. Click OK twice.
7. Use the Local Users and Groups MMC snap-in (lusrmgr.msc) to add the service account
to the local Distributed Component Object Model (DCOM) Users and Remote Desktop
Users groups on the system that will be probed.
STEP 5 | (Not Recommended) To allow the agent to monitor user sessions to poll Windows servers for
user mapping informaon, assign Server Operator privileges to the service account.
Because this group also has privileges for shung down and restarng servers, only
assign the account to this group if monitoring user sessions is very important.
1. Select Acve Directory Users and Computers > <your domain> > Builn > Server
Operators Group.
2. Right-click Properes > Members > Add add service account name
STEP 6 | Disable service account privileges that are not required.

By ensuring that the User-ID service account has the minimum set of account privileges, you
can reduce the aack surface should the account be compromised.
To ensure that the User-ID account has the minimum privileges necessary, deny the following
privileges on the account:
• Deny interacve logon for the User-ID service account—While the User-ID service account
does need permission to read and parse Acve Directory security event logs, it does not
require the ability to logon to servers or domain systems interacvely. You can restrict this
User-ID
privilege using Group Policies or by using a Managed Service account (refer to Microso
TechNet for more informaon).
1. Select Group Policy Management Editor > Default Domain Policy > Computer
Configuraon > Policies > Windows Sengs > Security Sengs > User Rights
Assignment.
2. For Deny log on as a batch job, Deny log on locally, and Deny log on through Remote
Desktop Services, right-click Properes, then select Define these policy sengs > Add
User or Group and add the service account name, then click OK.
• Deny remote access for the User-ID service account—This prevents an aacker from using
the account to access your network from the outside the network.
1. Start > Run, enter MMC, and select File > Add/Remove Snap-in > Acve Directory Users
and Computers > Users.
2. Right-click the service account name, then select Properes.
3. Select Dial-in, then Deny the Network Access Permission.
User-ID
STEP 7 | As a next step, Configure User Mapping Using the PAN-OS Integrated User-ID Agent.
Configure User Mapping Using the Windows User-ID Agent

In most cases, the majority of your network users will have logins to your monitored domain
services. For these users, the Palo Alto Networks User-ID agent monitors the servers for login
events and performs the IP address to username mapping. The way you configure the User-ID
agent depends on the size of your environment and the locaon of your domain servers. As a
best pracce, locate your User-ID agents near the servers it will monitor (that is, the monitored
servers and the Windows User-ID agent should not be across a WAN link from each other). This is
because most of the traffic for user mapping occurs between the agent and the monitored server,
with only a small amount of traffic—the delta of user mappings since the last update—from the
agent to the firewall.
The following topics describe how to install and configure the User-ID Agent and how to configure
the firewall to retrieve user mapping informaon from the agent:
• Install the Windows-Based User-ID Agent
• Configure the Windows User-ID Agent for User Mapping
Install the Windows-Based User-ID Agent

The following procedure shows how to install the User-ID agent on a member server in the
domain and set up the service account with the required permissions. If you are upgrading, the
installer will automacally remove the older version; however, it is a good idea to back up the
config.xml file before running the installer.
For informaon about the system requirements for installing the Windows-based User-
ID agent and for informaon on supported server OS versions, refer to the User-ID agent
release notes and the Palo Alto Networks Compability Matrix.
User-ID
STEP 1 | Create a dedicated Acve Directory service account for the User-ID agent to access the
services and hosts it will monitor to collect user mappings.
Create a Dedicated Service Account for the User-ID Agent and grant the necessary
permissions for the Windows User-ID agent.
1. Enable the service account to log on as a service by configuring either local or group
policy.
1. To configure the group policy if you are installing Windows-based User-ID agents
on mulple servers, select Group Policy Management > Default Domain Policy >
User-ID
Computer Configuraon > Policies > Windows Sengs > Security Sengs > Local
Policies > User Rights Assignment for the Windows server that is the agent host.
2. Right-click Log on as a service, then select Properes.
3. Add the service account username or builn group (Administrators have this privilege
by default).
The permission to log on as a service is only needed locally on the Windows

server that is the agent host. If you are using only one User-ID agent, you can
grant the permissions locally on the agent host using the following instrucons.
1. To assign permissions locally, select Control Panel > Administrave Tools > Local
Security Policy.
2. Select Local Policies > User Rights Assignment > Log on as a service.
User-ID
3. Add User or Group to add the service account.
4. Enter the service account name in domain\username format in the Enter the object
names to select entry field and click OK.
User-ID
To confirm the service account name is valid, Check Names.

2. If you want to use server monitoring to idenfy users, add the service account to the
Event Log Reader builn group to enable privileges for reading the security log events.
1. On the domain controller or Exchange server that contains the logs you want the
User-ID agent to read, or on the member server that receives events from Windows
User-ID
log forwarding, run the MMC and launch the Acve Directory Users and Computers
snap-in.
2. Navigate to the Builn folder for the domain, right-click the Event Log Reader group
and select Add to Group to open the properes dialog.
3. Click Add and enter the name of the service account that you configured the User-ID
service to use and then click Check Names to validate that you have the proper object
name.
5. Confirm that the builn Event Log Reader group lists the service account as a member.
3. Assign account permissions to the installaon folder to allow the service account to
access the agent’s installaon folder to read the configuraon and write logs.
You only need to perform this step if the service account you configured for the User-ID
agent is not either a domain administrator or a local administrator on the User-ID agent
server host.
1. From the Windows Explorer, navigate to C:\Program Files(x86)\Palo Alto
Networks for 32-bit systems, right-click the folder, and select Properes.
2. On the Security tab, click Edit.
User-ID
3. Add the User-ID agent service account and assign it permissions to Modify, Read &
execute, List folder contents, Read, and Write, and then click OK to save the account
sengs.
If you want to allow the service account to access the User-ID agent’s registry
keys, Allow the Full Control permission.
4. Give the service account permissions to the User-ID Agent registry sub-tree:
1. Run regedt32 and navigate to the Palo Alto Networks sub-tree in the following
locaon: HKEY_LOCAL_MACHINE\Software\Palo Alto Networks.
2. Right-click the Palo Alto Networks node and select Permissions.
3. Assign the User-ID service account Full Control and then click OK to save the seng.
STEP 2 | Decide where to install the User-ID agent.

The User-ID agent queries the Domain Controller and Exchange server logs using Microso
Remote Procedure Calls (MSRPCs). During the inial connecon, the agent transfers the
most recent 50,000 events from the log to map users. On each subsequent connecon, the
agent transfers events with a mestamp later than the last communicaon with the domain
controller. Therefore, always install one or more User-ID agents at each site that has servers to
be monitored.
• You must install the User-ID agent on a system running one of the supported OS versions:
see “Operang System (OS) Compability User-ID Agent” in the Compability Matrix. The
system must also meet the minimum requirements (see the User-ID agent release notes).
• Make sure the system that will host the User-ID agent is a member of the same domain as
the servers it will monitor.
• As a best pracce, install the User-ID agent close to the servers it will be monitoring: there
is more traffic between the User-ID agent and the monitored servers than there is between
the User-ID agent and the firewall, so locang the agent close to the monitored servers
opmizes bandwidth usage.
• To ensure the most comprehensive mapping of users, you must monitor all domain
controllers that process authencaon for users you want to map. You might need to install
mulple User-ID agents to efficiently monitor all of your resources.
• If you are using the User-ID agent for credenal detecon, you must install it on the read-
only domain controller (RODC). As a best pracce deploy a separate agent for this purpose.
User-ID
Do not use the User-ID agent installed on the RODC to map IP addresses to users. The
User-ID agent installer for credenal detecon is named UaCredInstall64-x.x.x.msi.
STEP 3 | Download the User-ID agent installer.
Install the User-ID agent version that is the same as the PAN-OS version running on
the firewalls. If there is not a User-ID agent version that matches the PAN-OS version,
install the latest version that is closest to the PAN-OS version.
1. Log in to the Palo Alto Networks Customer Support Portal.

2. Select Updates > Soware Updates.
3. Set Filter By to User Idenficaon Agent and select the version of the User-ID agent
you want to install from the corresponding Download column. The file name uses
the following format: UaInstall-x.x.x.msi (where x represents the version
number). For example, to download the 10.0 version of the User-ID agent, select
UaInstall-10.0.0-0.msi.
If you are using the User-ID agent for credenal detecon, download the
UaCredInstall64-x.x.x.msi file instead. Only download and install the
UaCredInstall64-x.x.x.msi if you are using the User-ID for credenal detecon.
4. Save the file on the systems where you plan to install the agent.
STEP 4 | Run the installer as an administrator.

1. Open the Windows Start menu, right-click the Command Prompt program, and select
Run as administrator.
2. From the command line, run the .msi file you downloaded. For example, if you saved
the .msi file to the Desktop, enter the following:
C:\Users\administrator.acme>cd Desktop
User-ID
C:\Users\administrator.acme\Desktop>UaInstall-6.0.0-1.msi
3. Follow the setup prompts to install the agent using the default sengs. By default, the
agent gets installed to C:\Program Files(x86)\Palo Alto Networks, but you
can Browse to a different locaon.
4. When the installaon completes, Close the setup window.
STEP 5 | Launch the User-ID Agent applicaon as an administrator.

Open the Windows Start menu, right-click the User-ID Agent program, and select Run as
administrator.
You must run the User-ID Agent applicaon as an administrator to install the
applicaon, commit configuraon changes, or uninstall the applicaon.
STEP 6 | (Oponal) Change the service account that the User-ID agent uses to log in.
By default, the agent uses the administrator account used to install the .msi file. To change the
account to a restricted account:
1. Select User Idenficaon > Setup and click Edit.
2. Select the Authencaon tab and enter the service account name that you want the
User-ID agent to use in the User name for Acve Directory field.
3. Enter the Password for the specified account.
4. Commit the changes to the User-ID agent configuraon to restart the service using the
service account credenals.
User-ID
STEP 7 | (Oponal) Assign your own cerficates for mutual authencaon between the Windows
User-ID agent and the firewall.
1. Obtain your cerficate for the Windows User-ID agent using one of the following
methods. Upload the server cerficate in Privacy Enhanced Mail (PEM) format and the
server cerficate’s encrypted key.
• Generate a Cerficate and export it for upload to the Windows User-ID agent.
• Export a cerficate from your enterprise cerficate authority (CA) and the upload it to
the Windows User-ID agent.
2. Add a server cerficate to Windows User-ID agent.
1. On the Windows User-ID agent, select Server Cerficate and click Add.
2. Enter the path and name of the cerficate file received from the CA or browse to the
cerficate file.
3. Enter the private key passphrase.
4. Click OK and then Commit.
3. Upload a cerficate to the firewall to validate the Windows User-ID agent’s identy.
4. Configure the cerficate profile for the client device (firewall or Panorama).
1. Select Device > Cerficate Management > Cerficate Profile.
2. Configure a Cerficate Profile.
You can only assign one cerficate profile for Windows User-ID agents and
Terminal Server (TS) agents. Therefore, your cerficate profile must include all
cerficate authories that issued cerficates uploaded to connected User-ID
and TS agents.
5. Assign the cerficate profile on the firewall.
1. Select Device > User Idenficaon > Connecon Security and click the edit buon.
2. Select the User-ID Cerficate Profile you configured in the previous step.
3. Click OK.
STEP 8 | Configure Credenal Detecon with the Windows-based User-ID Agent.

To use the Windows-based User-ID agent to detect credenal submissions and Prevent
Credenal Phishing, you must install the User-ID credenal service on the Windows-based
User-ID agent. You can only install this add-on on a read-only domain controller (RODC).
Configure the Windows User-ID Agent for User Mapping

The Palo Alto Networks Windows User-ID agent is a Windows service that connects to servers
on your network—for example, Acve Directory servers, Microso Exchange servers, and Novell
eDirectory servers—and monitors the logs for login events. The agent uses this informaon to map
IP addresses to usernames. Palo Alto Networks firewalls connect to the User-ID agent to retrieve
this user mapping informaon, enabling visibility into user acvity by username rather than IP
address and enables user- and group-based security enforcement.
User-ID
For informaon about the server OS versions supported by the User-ID agent, refer to
“Operang System (OS) Compability User-ID Agent” in the User-ID Agent Release
Notes.
STEP 1 | Define the servers the User-ID agent will monitor to collect IP address to user mapping
informaon.
The User-ID agent can monitor up to 100 servers, of which up to 50 can be syslog senders.
To collect all of the required mappings, the User-ID agent must connect to all servers
that your users log in to in order to monitor the security log files on all servers that
contain login events.
1. Open the Windows Start menu and select User-ID Agent.

2. Select User Idenficaon > Discovery.
3. In the Servers secon of the screen, click Add.
4. Enter a Name and Server Address for the server to be monitored. The network address
can be a FQDN or an IP address.
5. Select the Server Type (Microso Acve Directory, Microso Exchange, Novell
eDirectory, or Syslog Sender) and then click OK to save the server entry. Repeat this
step for each server to be monitored.
6. (Oponal) To enable the Windows User-ID agent to automacally discover domain
controllers on your network using DNS lookups, click Auto Discover. If you have new
domain controllers that you want the Windows User-ID agent to discover, click Auto
Discover each me you want to discover the new domain controllers.
Auto-discovery locates domain controllers in the local domain only; you must
manually add Exchange servers, eDirectory servers, and syslog senders.
7. (Oponal) To tune the frequency at which the firewall polls configured servers for
mapping informaon, select User Idenficaon > Setup and Edit the Setup secon. On
the Server Monitor tab, modify the value in the Server Log Monitor Frequency (seconds)
field. Increase the value in this field to 5 seconds in environments with older Domain
Controllers or high-latency links.
Ensure that the Enable Server Session Read seng is not selected. This seng
requires that the User-ID agent have an Acve Directory account with Server
Operator privileges so that it can read all user sessions. Instead, use a syslog or
XML API integraon to monitor sources that capture login and logout events
for all device types and operang systems (instead of just Windows), such as
wireless controllers and Network Access Controllers (NACs).
User-ID
STEP 2 | Specify the subnetworks the Windows User-ID agent should include in or exclude from User-
ID.
By default, the User-ID maps all users accessing the servers you are monitoring.
As a best pracce, always specify which networks to include and exclude from User-
ID to ensure that the agent is only communicang with internal resources and to
prevent unauthorized users from being mapped. You should only enable User-ID on the
subnetworks where users internal to your organizaon are logging in.
1. Select User Idenficaon > Discovery.

2. Add an entry to the Include/Exclude list of configured networks and enter a Name for
the entry and enter the IP address range of the subnetwork in as the Network Address.
3. Select whether to include or exclude the network:
• Include specified network—Select this opon if you want to limit user mapping
to users logged in to the specified subnetwork only. For example, if you include
10.0.0.0/8, the agent maps the users on that subnetwork and excludes all others. If
you want the agent to map users in other subnetworks, you must repeat these steps
to add addional networks to the list.
• Exclude specified network—Select this opon only if you want the agent to exclude
a subset of the subnetworks you added for inclusion. For example, if you include
10.0.0.0/8 and exclude 10.2.50.0/22, the agent will map users on all the subnetworks
of 10.0.0.0/8 except 10.2.50.0/22, and will exclude all subnetworks outside of
10.0.0.0/8.
If you add Exclude profiles without adding any Include profiles, the User-ID
agent excludes all subnetworks, not just the ones you added.
4. Click OK.
User-ID
STEP 3 | (Oponal) If you configured the agent to connect to a Novell eDirectory server, you must
specify how the agent should search the directory.
1. Select User Idenficaon > Setup and click Edit in the Setup secon of the window.
2. Select the eDirectory tab and then complete the following fields:
• Search Base—The starng point or root context for agent queries, for example:
dc=domain1,dc=example, dc=com.
• Bind Disnguished Name—The account to use to bind to the directory, for example:
cn=admin,ou=IT, dc=domain1, dc=example, dc=com.
• Bind Password—The bind account password. The agent saves the encrypted password
in the configuraon file.
• Search Filter—The search query for user entries (default is objectClass=Person).
• Server Domain Prefix—A prefix to uniquely idenfy the user. This is only required if
there are overlapping name spaces, such as different users with the same name from
two different directories.
• Use SSL—Select the check box to use SSL for eDirectory binding.
• Verify Server Cerficate—Select the check box to verify the eDirectory server
cerficate when using SSL.
STEP 4 | (Strongly recommended) Disable client probing.
Palo Alto Networks strongly recommends disabling client probing on high-security

networks. Client probing can pose a security threat if not correctly configured. For
more informaon, see client probing.
1. On the Client Probing tab, deselect the Enable WMI Probing check box if it is enabled.
2. Deselect the Enable NetBIOS Probing check box if it is enabled.
Palo Alto Network strongly recommends that you collect user mapping
informaon from isolated and trusted sources, such as domain controllers
or integraons with Syslog or the XML API, to safely capture user mapping
informaon from any device type or operang system.
If you must enable client probing, select the Enable WMI Probing check box and
on the Client Probing tab. Due to the potenal security risks of this method, only
select the Enable NetBIOS Probing check box if the firewall cannot obtain user
mappings using any other method. Then add a remote administraon excepon
to the Windows firewall for each probed client to ensure the Windows firewall
will allow client probing. Each probed client PC must allow port 139 in the
Windows firewall and must also have file and printer sharing services enabled.
STEP 5 | Save the configuraon.

Click OK to save the User-ID agent setup sengs and then click Commit to restart the User-ID
agent and load the new sengs.
User-ID
STEP 6 | (Oponal) Define the set of users for which you do not need to provide IP address-to-
username mappings, such as kiosk accounts.
Save the ignore-user list as a text document on the agent host using the tle
ignore_user_list and use the .txt file extension to save it to the User-ID Agent folder on
the domain server where the agent is installed.
List the user accounts to ignore; there is no limit to the number of accounts you can add to the
list. Each user account name must be on a separate line. For example:
SPAdmin
SPInstall
TFSReport
You can use an asterisk as a wildcard character to match mulple usernames, but only as
the last character in the entry. For example, corpdomain\it-admin* would match all
administrators in the corpdomain domain whose usernames start with the string it‑admin.
You can also use the ignore-user list to idenfy users whom you want to force to
authencate using Authencaon Portal.
Aer adding entries to the Ignore User list, you must stop and restart the connecon to
the service.
STEP 7 | Configure the firewall to connect to the User-ID agent.
The firewall can connect to only one Windows-based User-ID agent that is using the
User-ID credenal service add-on to detect corporate credenal submissions. See
Configure Credenal Detecon with the Windows-based User-ID Agent for more
details on how to use this service for credenal phishing prevenon.
Complete the following steps on each firewall you want to connect to the User-ID agent to
receive user mappings:
1. Select Device > Data Redistribuon > Agents and click Add.
2. Enter a Name for the agent.
3. Add an Agent Using the Host and Port.
4. Enter the IP address of the Windows Host on which the User-ID Agent is installed.
5. Enter the Port number (1-65535) on which the agent will listen for user mapping
requests. This value must match the value configured on the User-ID agent. By default,
the port is set to 5007 on the firewall and on newer versions of the User-ID agent.
However, some older User-ID agent versions use port 2010 as the default.
6. Select IP User Mappings as the Data type.
7. Make sure that the configuraon is Enabled, then click OK.
9. Verify that the Connected status displays as connected (a green light).
User-ID
STEP 8 | Verify that the User-ID agent is successfully mapping IP addresses to usernames and that the
firewalls can connect to the agent.
1. Launch the User-ID agent and select User Idenficaon.
2. Verify that the agent status shows Agent is running. If the Agent is not running, click
Start.
3. To verify that the User-ID agent can connect to monitored servers, make sure the Status
for each Server is Connected.
4. To verify that the firewalls can connect to the User-ID agent, make sure the Status for
each of the Connected Devices is Connected.
5. To verify that the User-ID agent is mapping IP addresses to usernames, select Monitoring
and make sure that the mapping table is populated. You can also Search for specific
users, or Delete user mappings from the list.
Configure User Mapping Using the PAN-OS Integrated User-ID

Agent
The following procedure describes how to configure the PAN-OS® integrated User-ID™ agent on
the firewall for IP address-to-username mapping. The integrated User-ID agent performs the same
tasks as the Windows-based agent with the excepon of NetBIOS client probing (WMI probing is
supported).
STEP 1 | Create an Acve Directory service account for the User-ID agent to access the services and
hosts that the firewall will monitor for collecng user mapping informaon.
Create a Dedicated Service Account for the User-ID Agent.
User-ID
STEP 2 | Define the servers that the firewall will monitor to collect user mapping informaon.
Within the total maximum of 100 monitored servers per firewall, you can define no more than
50 syslog senders for any single virtual system.
To collect all the required mappings, the firewall must connect to all servers that your
users log in to so that the firewall can monitor the Security log files on all servers that
contain login events.
1. Select Device > User Idenficaon > User Mapping.

2. Add a server (Server Monitoring secon).
3. Enter a Name to idenfy the server.
4. Select the Type of server.
• Microso Acve Directory
• Microso Exchange
• Novell eDirectory
• Syslog Sender
5. (Microso Acve Directory and Microso Exchange only) Select the Transport Protocol
you want to use to monitor security logs and session informaon on the server.
• WMI—The firewall and the monitored servers use Windows Management
Instrumentaon (WMI) to communicate.
• WinRM-HTTP—The firewall and the monitored servers use Kerberos for mutual
authencaon and the monitored server encrypts the communicaon with the
firewall using a negoated Kerberos session key.
• WinRM-HTTPS—The firewall and the monitored servers use HTTPS to communicate
and use basic authencaon or Kerberos for mutual authencaon.
If you select a Windows Remote Management (WinRM) opon, you must Configure
Server Monitoring Using WinRM.
6. (Microso Acve Directory, Microso Exchange, and Novell eDirectory only) Enter the
Network Address of the server.
If you are using WinRM with Kerberos, you must enter a fully qualified domain
name (FDQN). If you want to use WinRM with basic authencaon or use
WMI to monitor the server, you can enter an IP address or FQDN.
To monitor servers using WMI, specify an IP address, the service account name
(if all server monitoring is in the same domain), or a fully qualified domain
name (FQDN). If you specify an FQDN, use the down-level logon name in the
(DLN)\sAMAccountName format instead of the FQDN\sAMAccountName
format. For example, use example\user.services not example.com
\user.services. If you specify an FQDN, the firewall will aempt to
authencate using Kerberos, which does not support WMI.
7. (Syslog Sender only) If you select Syslog Sender as the server Type, Configure the PAN-
OS Integrated User-ID Agent as a Syslog Listener.
8. (Novell eDirectory only) Make sure the Server Profile you select is Enabled and click OK.
User-ID
9. (Oponal) Configure the firewall to automacally Discover domain controllers on your

network using DNS lookups.
The auto-discovery feature is for domain controllers only; you must manually
add any Exchange servers or eDirectory servers you want to monitor.
STEP 3 | (Oponal) Specify the frequency at which the firewall polls Windows servers for mapping
informaon. This is the interval between the end of the last query and the start of the next
query.
If the domain controller is processing many requests, delays between queries may
exceed the specified value.
1. Edit the Palo Alto Networks User ID Agent Setup.

2. Select the Server Monitor tab and specify the Server Log Monitor Frequency in seconds
(range is 1 to 3,600; default is 2). In environments with older domain controllers or high-
latency links, set this frequency to a minimum of five seconds.
Ensure that the Enable Session opon is not enabled. This opon requires that
the User-ID agent have an Acve Directory account with Server Operator
privileges so that it can read all user sessions. Instead, use a Syslog or XML
API integraon to monitor sources that capture login and logout events for all
device types and operang systems (instead of just Windows), such as wireless
controllers and network access control (NAC) devices.
STEP 4 | Specify the subnetworks that the PAN-OS integrated User-ID agent should include in or
exclude from user mapping.
By default, the User-ID maps all users accessing the servers you are monitoring.
As a best pracce, always specify which networks to include and, oponally, which
networks to exclude from User-ID to ensure that the agent is communicang only
with internal resources and to prevent unauthorized users from being mapped. You
should enable user mapping only on the subnetworks where users internal to your
organizaon are logging in.
1. Select Device > User Idenficaon > User Mapping.

2. Add an entry to the Include/Exclude Networks and enter a Name for the entry. Ensure
that the entry is Enabled.
3. Enter the Network Address and then select whether to include or exclude it:
• Include—Select this opon to limit user mapping to only users logged in to the
specified subnetwork. For example, if you include 10.0.0.0/8, the agent maps the
users on that subnetwork and excludes all others. If you want the agent to map users
in other subnetworks, you must repeat these steps to add addional networks to the
list.
• Exclude—Select this opon to configure the agent to exclude a subset of the
subnetworks you added for inclusion. For example, if you include 10.0.0.0/8 and
User-ID
exclude 10.2.50.0/22, the agent will map users on all the subnetworks of 10.0.0.0/8
except 10.2.50.0/22 and will exclude all subnetworks outside of 10.0.0.0/8.
If you add Exclude profiles without adding any Include profiles, the User-ID
agent excludes all subnetworks, not just the ones you added.
4. Click OK.
STEP 5 | Set the domain credenals for the account that the firewall will use to access Windows
resources. This is required for monitoring Exchange servers and domain controllers as well as
for WMI probing.
1. Edit the Palo Alto Networks User-ID Agent Setup.
2. Select the Server Monitor Account tab and enter the User Name and Password for the
service account that the User-ID agent will use to probe the clients and monitor servers.
Enter the username using the domain\username syntax.
3. If you are using WinRM to monitor servers, configure the firewall to authencate with
the server you are monitoring.
• If you want to use WinRM with basic authencaon, enable WinRM on the server,
configure basic authencaon, and specify the service account Domain’s DNS Name.
• If you want to use WinRM with Kerberos, Configure a Kerberos server profile if you
have not already done so and then select the Kerberos Server Profile.
STEP 6 | (Oponal, not recommended) Configure WMI probing (the PAN-OS integrated User-ID agent
does not support NetBIOS probing).
Do not enable WMI probing on high-security networks. Client probing can generate a
large amount of network traffic and can pose a security threat when misconfigured.
1. On the Client Probing tab, Enable Probing.

2. (Oponal) Specify the Probe Interval to define the interval (in minutes) between the end
of the last probe request and the start of the next request.
If necessary, increase the value to ensure the User-ID agent has sufficient me to probe
all the learned IP addresses (range is 1 to 1440; default is 20).
If the request load is high, the observed delay between requests might
significantly exceed the specified interval.
3. Click OK.
4. Make sure the Windows firewall will allow client probing by adding a remote
administraon excepon to the Windows firewall for each probed client.
User-ID
STEP 7 | (Oponal) Define the set of user accounts that don’t require IP address-to-username
mappings, such as kiosk accounts.
Define the ignore user list on the firewall that is the User-ID agent, not the client. If
you define the ignore user list on the client firewall, the users in the list are sll mapped
during redistribuon.
On the Ignore User List tab, Add each username you want to exclude from user mapping. You
can also use the ignore user list to idenfy the users you want to force to use Authencaon
Portal to authencate. You can use an asterisk as a wildcard character to match mulple
usernames but only as the last character in the entry. For example, corpdomain\it-admin*
would match all administrators in the corpdomain domain whose usernames start with the
string it‑admin. You can add up to 5,000 entries to exclude from user mapping.
STEP 8 | Acvate your configuraon changes.

Click OK and Commit.
STEP 9 | Verify the configuraon.

1. Access the firewall CLI.
2. Enter the following operaonal command:
> show user server-monitor state all
3. On the Device > User Idenficaon > User Mapping tab in the web interface, verify that
the Status of each server you configured for server monitoring is Connected.
Configure Server Monitoring Using WinRM

You can configure the PAN-OS integrated User-ID agent to monitor servers using Windows
Remote Management (WinRM). Using the WinRM protocol improves speed, efficiency, and
security when monitoring server events to map user events to IP addresses. The PAN-OS
integrated User-ID agent supports the WinRM protocol on Windows Server 2012 Acve
Directory and Microso Exchange Server 2012 or later versions of both.
There are three ways to configure server monitoring using WinRM:
• Configure WinRM over HTTPS with Basic Authencaon—The firewall authencates to the
monitored server using the username and password of the service account for the User-ID
agent and the firewall authencates the monitored server using the User-ID cerficate profile.
• Configure WinRM over HTTP with Kerberos—The firewall and the monitored servers use
Kerberos for mutual authencaon and the monitored server encrypts the communicaon with
the firewall using a negoated Kerberos session key.
• Configure WinRM over HTTPS with Kerberos—The firewall and the monitored server use
HTTPS to communicate and use Kerberos for mutual authencaon.
Configure WinRM over HTTPS with Basic Authencaon

When you configure WinRM to use HTTPS with basic authencaon, the firewall transfers the
credenals for the service account in a secure tunnel using SSL.
User-ID
STEP 1 | Configure the service account with Remote Management User and CIMV2 privileges for the
server you want to monitor.
STEP 2 | On the Windows server you are monitoring, obtain the thumbprint from the cerficate for
the Windows server to use with WinRM and enable WinRM.
Ensure that you use an account with administrator privileges to configure WinRM on
the server you want to monitor. As a best pracce for security, this account should not
be the same account as the service account in Step 1.
1. Verify the cerficate is installed in the Local Computer cerficate store (Cerficates
(Local Computer) > Personal > Cerficates).
If you do not see the Local Computer cerficate store, launch the Microso Management
Console (Start > Run > MMC) and add the Cerficates snap-in (File > Add/Remove
Snap-in > Cerficates > Add > Computer account > Next > Finish).
2. Open the cerficate and select General > Details > Show: <All>.
3. Select the Thumbprint and copy it.
4. To enable the firewall to connect to the Windows server using WinRM, enter the
following command: winrm quickconfig.
5. Enter y to confirm the changes and then confirm the output displays WinRM service
started.
If WinRM is enabled, the output displays WinRM service is already running
on this machine. You will be prompted to confirm any addional required
configuraon changes.
6. To verify that WinRM is communicang using HTTPS, enter the following command:
winrm enumerate winrm/config/listener and confirm that the output displays
Transport = HTTPS.
By default, WinRM/HTTPS uses port 5986.
7. From the Windows server command prompt, enter the following command:
winrm create winrm/config/Listener?Address=*+Transport=HTTPS
@{Hostname=”<hostname>";CertificateThumbprint=”Certificate
Thumbprint"}, where hostname is the hostname of the Windows server and Cerficate
Thumbprint is the value you copied from the cerficate.
Use the command prompt (not Powershell) and remove any spaces in the
Cerficate Thumbprint to ensure that WinRM can validate the cerficate.
c:\> winrm set winrm/config/client/auth @{Basic="true"}
9. Enter the following command: winrm get winrm/config/service/Auth and

confirm that Basic = true.
User-ID
STEP 3 | Enable Basic Authencaon between the PAN-OS integrated User-ID agent and the
monitored servers.
1. Select Device > User Idenficaon > User Mapping > Palo Alto Networks User-ID
Agent Setup > Server Monitor Account.
2. In domain\username format, enter the User Name for the service account that the
User-ID agent will use to monitor servers.
3. Enter the Domain’s DNS Name of the server monitor account.
4. Enter the Password and Confirm Password for the service account.
5. Click OK
STEP 4 | Configure server monitoring for the PAN-OS integrated User-ID agent.
1. Select the Microso server Type (Microso Acve Directory or Microso Exchange).
2. Select Win-RM-HTTPS as the Transport Protocol to use Windows Remote Management
(WinRM) over HTTPS to monitor the server security logs and session informaon.
3. Enter the IP address or FQDN Network Address of the server.
STEP 5 | To enable the PAN-OS integrated User-ID agent to communicate with the monitored servers
using WinRM-HTTPS, verify that you successfully imported the root cerficate for the
User-ID
service cerficates that the Windows server uses for WinRM on to the firewall and associate
the cerficate with the User-ID Cerficate Profile.
1. Select Device > User Idenficaon > Connecon Security.
2. Click Edit.
3. Select the Windows server cerficate to use for the User-ID Cerficate Profile.
4. Click OK.
STEP 7 | Verify that the status of each monitored server is Connected (Device > User Idenficaon >
User Mapping).
Configure WinRM over HTTP with Kerberos

When you configure WinRM over HTTP with Kerberos, the firewall and the monitored servers use
Kerberos for mutual authencaon and the monitored server encrypts the communicaon with
the firewall using a negoated Kerberos session key.
WinRM with Kerberos supports the aes128-cts-hmac-sha1-96 and aes256-cts-hmac-

sha1-96 ciphers. If the server you want to monitor uses RC4, you must download the
Windows update and disable RC4 for Kerberos in the registry sengs of the server you
want to monitor.
User-ID
STEP 2 | Confirm that WinRM is enabled on the Windows server you are monitoring.
started.
3. To verify that WinRM is communicang using HTTP, enter the following command:
winrm enumerate winrm/config/listener and confirm that the output displays
Transport = HTTP.
By default, WinRM/HTTP uses port 5985.
confirm that Kerberos = true.
STEP 3 | Enable the PAN-OS integrated User-ID agent and the monitored servers to authencate
using Kerberos.
1. If you did not do so during the inial configuraon, configure date and me (NTP)
sengs to ensure successful Kerberos negoaon.
2. Configure a Kerberos server profile on the firewall to authencate with the server to
monitor the security logs and session informaon.
Kerberos uses the domain name to locate the service account.
7. Select the Kerberos Server Profile you configured in Step 3.2.
8. Click OK.
User-ID
1. Configure the Microso server type (Microso Acve Directory or Microso Exchange).
2. Select WinRM-HTTP as the Transport Protocol to use Windows Remote Management
(WinRM) over HTTP to monitor the server security logs and session informaon.
3. Enter the FQDN Network Address of the server.

If you are using Kerberos, the network address must be a fully qualified domain name
(FDQN).
User Mapping).
Configure WinRM over HTTPS with Kerberos

When you configure WinRM over HTTPS with Kerberos, the firewall and the monitored server use
HTTPS to communicate and use Kerberos for mutual authencaon.
WinRM with Kerberos supports the aes128-cts-hmac-sha1-96 and aes256-cts-hmac-

sha1-96 ciphers. If the server you want to monitor uses RC4, you must download the
Windows update and disable RC4 for Kerberos in the registry sengs of the server you
want to monitor.
User-ID
STEP 2 | On the Windows server you are monitoring, obtain the thumbprint from the cerficate for
the Windows server to use with WinRM and enable WinRM.
1. Verify the cerficate is installed in the Local Computer cerficate store (Cerficates
(Local Computer) > Personal > Cerficates).
If you do not see the Local Computer cerficate store, launch the Microso Management
Console (Start > Run > MMC) and add the Cerficates snap-in (File > Add/Remove
Snap-in > Cerficates > Add > Computer account > Next > Finish).
2. Open the cerficate and select General > Details > Show: <All>.
3. Select the Thumbprint and copy it.
started.
6. To verify that WinRM is communicang using HTTPS, enter the following command:
winrm enumerate winrm/config/listener. Then confirm that the output
displays Transport = HTTPS.
By default, WinRM/HTTPS uses 5986.
winrm create winrm/config/Listener?Address=*+Transport=HTTPS
@{Hostname=”<hostname>";CertificateThumbprint=”Certificate
Thumbprint"}, where hostname is the hostname of the Windows server and Cerficate
Thumbprint is the value you copied from the cerficate.
Use the command prompt (not Powershell) and remove any spaces in the
Cerficate Thumbprint to ensure that WinRM can validate the cerficate.
confirm that Basic = false and Kerberos= true.
User-ID
STEP 3 | Enable the PAN-OS integrated User-ID agent and the monitored servers to authencate
using Kerberos.
1. If you did not do so during the inial configuraon, configure date and me (NTP)
sengs to ensure successful Kerberos negoaon.
2. Configure a Kerberos server profile on the firewall to authencate with the server to
monitor the security logs and session informaon.
Kerberos uses the domain name to locate the service account.
7. Select the Kerberos Server Profile you created in Step 3.2.
8. Click OK.
1. Configure the Microso server type (Microso Acve Directory or Microso Exchange).
2. Select Win-RM-HTTPS as the Transport Protocol to use Windows Remote Management
(WinRM) over HTTPS to monitor the server security logs and session informaon.
3. Enter the FQDN Network Address of the server.

If you are using Kerberos, the network address must be a fully qualified domain name
(FDQN).
User-ID
STEP 5 | To enable the PAN-OS integrated User-ID agent to communicate with the monitored servers
using WinRM-HTTPS, verify that you successfully imported the root cerficate for the
service cerficates that the Windows server uses for WinRM on to the firewall and associate
the cerficate with the User-ID Cerficate Profile.
The firewall uses the same cerficate to authencate with all monitored servers.
2. Click Edit.
3. Select the Windows server cerficate to use for the User-ID Cerficate Profile.
4. Click OK.
User Mapping).
Configure User-ID to Monitor Syslog Senders for User Mapping

To obtain IP address-to-username mappings from exisng network services that authencate
users, you can configure the PAN-OS integrated User-ID agent or Windows-based User-ID
agent to parse Syslog messages from those services. To keep user mappings up to date, you can
also configure the User-ID agent to parse syslog messages for logout events so that the firewall
automacally deletes outdated mappings.
• Configure the PAN-OS Integrated User-ID Agent as a Syslog Listener
• Configure the Windows User-ID Agent as a Syslog Listener
Configure the PAN-OS Integrated User-ID Agent as a Syslog Listener

To configure the PAN-OS Integrated User-ID agent to create new user mappings and remove
outdated mappings through syslog monitoring, start by defining Syslog Parse profiles. The User-ID
agent uses the profiles to find login and logout events in syslog messages. In environments where
syslog senders (the network services that authencate users) deliver syslog messages in different
formats, configure a profile for each syslog format. Syslog messages must meet certain criteria
for a User-ID agent to parse them (see Syslog). This procedure uses examples with the following
formats:
• Login events—[Tue Jul 5 13:15:04 2016 CDT] Administratorauthentication
success User:johndoe1 Source:192.168.3.212
• Logout events—[Tue Jul 5 13:18:05 2016CDT] User logout successful
User:johndoe1 Source:192.168.3.212
Aer configuring the Syslog Parse profiles, you specify syslog senders for the User-ID agent to
monitor.
User-ID
STEP 1 | Determine whether there is a predefined Syslog Parse profile for your parcular syslog
senders.
Palo Alto Networks provides several predefined profiles through Applicaon content updates.
The predefined profiles are global to the firewall, whereas custom profiles apply to a single
virtual system only.
Any new Syslog Parse profiles in a given content release is documented in the
corresponding release note along with the specific regex used to define the filter.
1. Install the latest Applicaons or Applicaons and Threats update:

1. Select Device > Dynamic Updates and Check Now.
2. Download and Install any new update.
2. Determine which predefined Syslog Parse profiles are available:
1. Select Device > User Idenficaon > User Mapping and click Add in the Server
Monitoring secon.
2. Set the Type to Syslog Sender and click Add in the Filter secon. If the Syslog Parse
profile you need is available, skip the steps for defining custom profiles.
STEP 2 | Define custom Syslog Parse profiles to create and delete user mappings.
Each profile filters syslog messages to idenfy either login events (to create user mappings) or
logout events (to delete mappings), but no single profile can do both.
1. Review the syslog messages that the syslog sender generates to idenfy the syntax for
login and logout events. This enables you to define the matching paerns when creang
Syslog Parse profiles.
While reviewing syslog messages, also determine whether they include the
domain name. If they don’t, and your user mappings require domain names,
enter the Default Domain Name when defining the syslog senders that the User-
ID agent monitors (later in this procedure).
2. Select Device > User Idenficaon > User Mapping and edit the Palo Alto Networks
User-ID Agent Setup.
3. Select Syslog Filters and Add a Syslog Parse profile.
4. Enter a name to idenfy the Syslog Parse Profile.
5. Select the Type of parsing to find login or logout events in syslog messages:
• Regex Idenfier—Regular expressions.
• Field Idenfier—Text strings.
The following steps describe how to configure these parsing types.
User-ID
STEP 3 | (Regex Idenfier parsing only) Define the regex matching paerns.
If the syslog message contains a standalone space or tab as a delimiter, use \s for a
space and \t for a tab.
1. Enter the Event Regex for the type of events you want to find:
• Login events—For the example message, the regex (authentication\ success)
{1} extracts the first {1} instance of the string authenticationsuccess.
• Logout events—For the example message, the regex (logout\ successful){1}
extracts the first {1} instance of the string logoutsuccessful.
The backslash (\) before the space is a standard regex escape character that instructs the
regex engine not to treat the space as a special character.
2. Enter the Username Regex to idenfy the start of the username.
In the example message, the regex User:([a-zA-Z0-9\\\._]+) matches the string
User:johndoe1 and idenfies johndoe1 as the username.
3. Enter the Address Regex to idenfy the IP address poron of syslog messages.
In the example message, the regular expression Source:([0-9]{1,3}\.
[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}) matches the IPv4 address
Source:192.168.3.212.
The following is an example of a completed Syslog Parse profile that uses regex to
idenfy login events:
4. Click OK twice to save the profile.
User-ID
STEP 4 | (Field Idenfier parsing only) Define string matching paerns.

1. Enter an Event String to idenfy the type of events you want to find.
• Login events—For the example message, the string authentication success
idenfies login events.
• Logout events—For the example message, the string logoutsuccessful idenfies
logout events.
2. Enter a Username Prefix to idenfy the start of the username field in syslog messages.
The field does not support regex expressions such as \s (for a space) or \t (for a tab).
In the example messages, User: idenfies the start of the username field.
3. Enter the Username Delimiter that indicates the end of the username field in syslog
messages. Use \s to indicate a standalone space (as in the sample message) and \t to
indicate a tab.
4. Enter an Address Prefix to idenfy the start of the IP address field in syslog messages.
In the example messages, Source: idenfies the start of the address field.
5. Enter the Address Delimiter that indicates the end of the IP address field in syslog
messages.
For example, enter \n to indicate the delimiter is a line break.
The following is an example of a completed Syslog Parse profile that uses string matching
to idenfy login events:
User-ID
STEP 5 | Specify the syslog senders that the firewall monitors.

Within the total maximum of 100 monitored servers per firewall, you can define no more than
50 syslog senders for any single virtual system.
The firewall discards any syslog messages received from senders that are not on this list.
1. Select Device > User Idenficaon > User Mapping and Add an entry to the Server
Monitoring list.
2. Enter a Name to idenfy the sender.
3. Make sure the sender profile is Enabled (default is enabled).
4. Set the Type to Syslog Sender.
5. Enter the Network Address (IP address) of the syslog sender.
6. Select SSL (default) or UDP as the Connecon Type.
To select the TLS cerficate that the firewall uses to receive syslog messages,
select Device > User Idenficaon > User Mapping > Palo Alto Networks User-
ID Agent Setup. Edit the sengs and select Server Monitor, then select the
Syslog Service Profile that contains the TLS cerficate you want to the firewall
to use to receive syslog messages.
The PAN-OS integrated User-ID agent accepts syslogs over SSL and UDP only.
However, you must use cauon when using UDP to receive syslog messages
because it is an unreliable protocol and as such there is no way to verify that
a message was sent from a trusted syslog sender. Although you can restrict
syslog messages to specific source IP addresses, an aacker can sll spoof the IP
address, potenally allowing the injecon of unauthorized syslog messages into
the firewall.
Always use SSL to listen for syslog messages because the traffic is encrypted
(UDP sends the traffic in cleartext). If you must use UDP, make sure that the
syslog sender and client are both on a dedicated, secure network to prevent
untrusted hosts from sending UDP traffic to the firewall.
A syslog sender using SSL to connect will show a Status of Connected only when there is
an acve SSL connecon. Syslog senders using UDP will not show a Status value.
7. For each syslog format that the sender supports, Add a Syslog Parse profile to the Filter
list. Select the Event Type that each profile is configured to idenfy: login (default) or
logout.
8. (Oponal) If the syslog messages don’t contain domain informaon and your user
mappings require domain names, enter a Default Domain Name to append to the
mappings.
User-ID
STEP 6 | Enable syslog listener services on the interface that the firewall uses to collect user
mappings.
1. Select Network > Network Profiles > Interface Mgmt and edit an exisng Interface
Management profile or Add a new profile.
2. Select User-ID Syslog Listener-SSL or User-ID Syslog Listener-UDP or both, based on
the protocols you defined for the syslog senders in the Server Monitoring list.
The listening ports (514 for UDP and 6514 for SSL) are not configurable; they
are enabled through the management service only.
3. Click OK to save the interface management profile.
Even aer enabling the User-ID Syslog Listener service on the interface,
the interface only accepts syslog connecons from senders that have a
corresponding entry in the User-ID monitored servers configuraon. The firewall
discards connecons or messages from senders that are not on the list.
4. Assign the Interface Management profile to the interface that the firewall uses to collect
user mappings:
1. Select Network > Interfaces and edit the interface.
2. Select Advanced > Other info, select the Interface Management Profile you just
added, and click OK.
STEP 7 | Verify that the firewall adds and deletes user mappings when users log in and out.
You can use CLI commands to see addional informaon about syslog senders, syslog
messages, and user mappings.
1. Log in to a client system for which a monitored syslog sender generates login and logout
event messages.
3. Verify that the firewall mapped the login username to the client IP address:
> show user ip-user-mapping ip <ip-address>

IP address: 192.0.2.1 (vsys1)
User: localdomain\username
From: SYSLOG
4. Log out of the client system.

5. Verify that the firewall deleted the user mapping:

No matched record
Configure the Windows User-ID Agent as a Syslog Listener

To configure the Windows-based User-ID agent to create new user mappings and remove
outdated mappings through syslog monitoring, start by defining Syslog Parse profiles. The User-ID
User-ID
agent uses the profiles to find login and logout events in syslog messages. In environments where
syslog senders (the network services that authencate users) deliver syslog messages in different
formats, configure a profile for each syslog format. Syslog messages must meet certain criteria
for a User-ID agent to parse them (see Syslog). This procedure uses examples with the following
formats:
• Login events—[Tue Jul 5 13:15:04 2016 CDT] Administrator authentication
success User:johndoe1 Source:192.168.3.212
• Logout events—[Tue Jul 5 13:18:05 2016 CDT] User logout successful
User:johndoe1 Source:192.168.3.212
Aer configuring the Syslog Parse profiles, you specify the syslog senders that the User-ID agent
monitors.
The Windows User-ID agent accepts syslogs over TCP and UDP only. However, you
must use cauon when using UDP to receive syslog messages because it is an unreliable
protocol and as such there is no way to verify that a message was sent from a trusted
syslog sender. Although you can restrict syslog messages to specific source IP addresses,
an aacker can sll spoof the IP address, potenally allowing the injecon of unauthorized
syslog messages into the firewall. As a best pracce, use TCP instead of UDP. In either
case, make sure that the syslog sender and client are both on a dedicated, secure VLAN to
prevent untrusted hosts from sending syslogs to the User-ID agent.
STEP 1 | Deploy the Windows-based User-ID agents if you haven’t already.

1. Install the Windows-Based User-ID Agent.
2. Configure the firewall to connect to the User-ID agent.
STEP 2 | Define custom Syslog Parse profiles to create and delete user mappings.
Each profile filters syslog messages to idenfy either login events (to create user mappings) or
logout events (to delete mappings), but no single profile can do both.
1. Review the syslog messages that the syslog sender generates to idenfy the syntax for
login and logout events. This enables you to define the matching paerns when creang
Syslog Parse profiles.
While reviewing syslog messages, also determine whether they include the
domain name. If they don’t, and your user mappings require domain names,
enter the Default Domain Name when defining the syslog senders that the User-
ID agent monitors (later in this procedure).
2. Open the Windows Start menu and select User-ID Agent.
3. Select User Idenficaon > Setup and Edit the Setup.
4. Select Syslog, Enable Syslog Service, and Add a Syslog Parse profile.
5. Enter a Profile Name and Descripon.
6. Select the Type of parsing to find login and logout events in syslog messages:
• Regex—Regular expressions.
• Field—Text strings.
The following steps describe how to configure these parsing types.
User-ID
STEP 3 | (Regex parsing only) Define the regex matching paerns.

If the syslog message contains a standalone space or tab as a delimiter, use \s for a space and
\t for a tab.
1. Enter the Event Regex for the type of events you want to find:
• Login events—For the example message, the regex (authentication\ success)
{1} extracts the first {1} instance of the string authentication success.
• Logout events—For the example message, the regex (logout\ successful){1}
extracts the first {1} instance of the string logout successful.
The backslash before the space is a standard regex escape character that instructs the
regex engine not to treat the space as a special character.
2. Enter the Username Regex to idenfy the start of the username.
In the example message, the regex User:([a-zA-Z0-9\\\._]+) matches the string
User:johndoe1 and idenfies johndoe1 as the username.
3. Enter the Address Regex to idenfy the IP address poron of syslog messages.
In the example message, the regular expression Source:([0-9]{1,3}\.
[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}) matches the IPv4 address
Source:192.168.3.212.
The following is an example of a completed Syslog Parse profile that uses regex to
idenfy login events:
User-ID
STEP 4 | (Field Idenfier parsing only) Define string matching paerns.

1. Enter an Event String to idenfy the type of events you want to find.
• Login events—For the example message, the string authentication success
idenfies login events.
• Logout events—For the example message, the string logout successful idenfies
logout events.
2. Enter a Username Prefix to idenfy the start of the username field in syslog messages.
In the example messages, User: idenfies the start of the username field.
3. Enter the Username Delimiter that indicates the end of the username field in syslog
messages. Use \s to indicate a standalone space (as in the sample message) and \t to
indicate a tab.
4. Enter an Address Prefix to idenfy the start of the IP address field in syslog messages.
In the example messages, Source: idenfies the start of the address field.
5. Enter the Address Delimiter that indicates the end of the IP address field in syslog
messages.
For example, enter \n to indicate the delimiter is a line break.
The following is an example of a completed Syslog Parse profile that uses string matching
to idenfy login events:
User-ID
STEP 5 | Specify the syslog senders that the User-ID agent monitors.
Within the total maximum of 100 servers of all types that the User-ID agent can monitor, up to
50 can be syslog senders.
The User-ID agent discards any syslog messages received from senders that are not on this list.
1. Select User Idenficaon > Discovery and Add an entry to the Servers list.
2. Enter a Name to idenfy the sender.
3. Enter the Server Address of the syslog sender (IP address or FQDN).
4. Set the Server Type to Syslog Sender.
5. (Oponal) If you want to override the current domain in the username of your syslog
message or prepend the domain to the username if your syslog message doesn’t contain
a domain, enter a Default Domain Name.
6. For each syslog format that the sender supports, Add a Syslog Parse profile to the Filter
list. Select the Event Type that you configured each profile to idenfy—login (default) or
logout—and then click OK.
8. Commit your changes to the User-ID agent configuraon.
STEP 6 | Verify that the User-ID agent adds and deletes user mappings when users log in and out.
You can use CLI commands to see addional informaon about syslog senders, syslog
messages, and user mappings.
1. Log in to a client system for which a monitored syslog sender generates login and logout
event messages.
2. Verify that the User-ID agent mapped the login username to the client IP address:
1. In the User-ID agent, select Monitoring.
2. Enter the username or IP address in the filter field, Search, and verify that the list
displays the mapping.
3. Verify that the firewall received the user mapping from the User-ID agent:
2. Run the following command:
If the firewall received the user mapping, the output resembles the following:
User: localdomain\username
User-ID
From: SYSLOG
4. Log out of the client system.

5. Verify that the User-ID agent removed the user mapping:
1. In the User-ID agent, select Monitoring.
2. Enter the username or IP address in the filter field, Search, and verify that the list does
not display the mapping.
6. Verify that the firewall deleted the user mapping:
2. Run the following command:
If the firewall deleted the user mapping, the output displays:
No matched record
Map IP Addresses to Usernames Using Authencaon Portal

When a user iniates web traffic (HTTP or HTTPS) that matches an Authencaon Policy rule,
the firewall prompts the user to authencate through Authencaon Portal. This ensures that
you know exactly who is accessing your most sensive applicaons and data. Based on user
informaon collected during authencaon, the firewall creates a new IP address-to-username
mapping or updates the exisng mapping for that user. This method of user mapping is useful
in environments where the firewall cannot learn mappings through other methods such as
monitoring servers. For example, you might have users who are not logged in to your monitored
domain servers, such as users on Linux clients.
• Authencaon Portal Authencaon Methods
• Authencaon Portal Modes
• Configure Authencaon Portal
Authencaon Portal Authencaon Methods

Authencaon Portal uses the following methods to authencate users whose web requests
match Authencaon Policy rules:
Authencaon Method Descripon
Kerberos SSO The firewall uses Kerberos single sign-on (SSO) to transparently
obtain user credenals from the browser. To use this method,
your network requires a Kerberos infrastructure, including a
key distribuon center (KDC) with an authencaon server
and cket granng service. The firewall must have a Kerberos
account.
User-ID
Authencaon Method Descripon

If Kerberos SSO authencaon fails, the firewall falls back to
web form or client cerficate authencaon, depending on your
Authencaon policy and Authencaon Portal configuraon.
Web Form The firewall redirects web requests to a web form for
authencaon. For this method, you can configure
Authencaon policy to use Mul-Factor Authencaon (MFA),
SAML, Kerberos, TACACS+, RADIUS, or LDAP authencaon.
Although users have to manually enter their login credenals,
this method works with all browsers and operang systems.
Client Cerficate The firewall prompts the browser to present a valid client
Authencaon cerficate to authencate the user. To use this method, you must
provision client cerficates on each user system and install the
trusted cerficate authority (CA) cerficate used to issue those
cerficates on the firewall.
Authencaon Portal Modes

The Authencaon Portal mode defines how the firewall captures web requests for
authencaon:
Mode Descripon
Transparent The firewall intercepts the browser traffic per the

Authencaon policy rule and impersonates the original
desnaon URL, issuing an HTTP 401 to invoke authencaon.
However, because the firewall does not have the real cerficate
for the desnaon URL, the browser displays a cerficate error
to users aempng to access a secure site. Therefore, use this
mode only when absolutely necessary, such as in Layer 2 or
virtual wire deployments.
Redirect The firewall intercepts unknown HTTP or HTTPS sessions

and redirects them to a Layer 3 interface on the firewall
using an HTTP 302 redirect to perform authencaon. This
is the preferred mode because it provides a beer end-user
experience (no cerficate errors). However, it does require
addional Layer 3 configuraon. Another benefit of the Redirect
mode is that it provides for the use of session cookies, which
enable the user to connue browsing to authencated sites
without requiring re-mapping each me the meouts expire.
This is especially useful for users who roam from one IP address
to another (for example, from the corporate LAN to the wireless
network) because they won’t need to re-authencate when the
IP address changes as long as the session stays open.
User-ID
Mode Descripon
If you use Kerberos SSO, you must use Redirect mode
because the browser will provide credenals only to trusted
sites. Redirect mode is also required if you use Mul-Factor
Authencaon to authencate Authencaon Portal users.
Configure Authencaon Portal

The following procedure shows how to set up Authencaon Portal authencaon by configuring
the PAN-OS integrated User-ID agent to redirect web requests that match an Authencaon
Policy rule to a firewall interface (redirect host).
SSL Inbound Inspecon does not support Authencaon Portal redirect. To use
Authencaon Portal redirect and decrypon, you must use SSL Forward Proxy.
Based on their sensivity, the applicaons that users access through Authencaon Portal require
different authencaon methods and sengs. To accommodate all authencaon requirements,
you can use default and custom authencaon enforcement objects. Each object associates an
Authencaon rule with an authencaon profile and an Authencaon Portal authencaon
method.
• Default authencaon enforcement objects—Use the default objects if you want to associate
mulple Authencaon rules with the same global authencaon profile. You must configure
this authencaon profile before configuring Authencaon Portal, and then assign it
in the Authencaon Portal Sengs. For Authencaon rules that require Mul-Factor
Authencaon (MFA), you cannot use default authencaon enforcement objects.
• Custom authencaon enforcement objects—Use a custom object for each Authencaon
rule that requires an authencaon profile that differs from the global profile. Custom objects
are mandatory for Authencaon rules that require MFA. To use custom objects, create
authencaon profiles and assign them to the objects aer configuring Authencaon Portal—
when you Configure Authencaon Policy.
Keep in mind that authencaon profiles are necessary only if users authencate through a
Authencaon Portal Web Form or Kerberos SSO. Alternavely, or in addion to these methods,
the following procedure also describes how to implement Client Cerficate Authencaon.
If you use Authencaon Portal without the other User-ID funcons (user mapping and
group mapping), you don’t need to configure a User-ID agent.
STEP 1 | Configure the interfaces that the firewall will use for incoming web requests, authencang
users, and communicang with directory servers to map usernames to IP addresses.
When the firewall connects to authencaon servers or User-ID agents, it uses the
management interface by default. As a best pracce, isolate your management network by
configuring service routes to connect to the authencaon servers or User-ID agents.
1. (MGT interface only) Select Device > Setup > Interfaces, edit the Management interface,
select User-ID, and click OK.
2. (Non-MGT interface only) Assign an Interface Management Profile to the Layer 3
interface that the firewall will use for incoming web requests and communicaon
User-ID
with directory servers. You must enable Response Pages and User-ID in the Interface
Management profile.
3. (Non-MGT interface only) Configure a service route for the interface that the firewall
will use to authencate users. If the firewall has more than one virtual system (vsys),
the service route can be global or vsys-specific. The services must include LDAP and
potenally the following:
• Kerberos, RADIUS, TACACS+, or Mul-Factor Authencaon—Configure a service
route for any authencaon services that you use.
• UID Agent—Configure this service only if you Enable User- and Group-Based Policy.
4. (Redirect mode only) Create a DNS address (A) record that maps the IP address on the
Layer 3 interface to the redirect host. If you will use Kerberos SSO, you must also add a
DNS pointer (PTR) record that performs the same mapping.
If your network doesn’t support access to the directory servers from any firewall interface, you
must Configure User Mapping Using the Windows User-ID Agent.
STEP 2 | Make sure Domain Name System (DNS) is configured to resolve your domain controller
addresses.
To verify proper resoluon, ping the server FQDN. For example:
admin@PA-220> ping host dc1.acme.com
User-ID
STEP 3 | Configure clients to trust Authencaon Portal cerficates.

Required for redirect mode—to transparently redirect users without displaying cerficate
errors. You can generate a self-signed cerficate or import a cerficate that an external
cerficate authority (CA) signed.
To use a self-signed cerficate, create a root CA cerficate and use it to sign the cerficate you
will use for Authencaon Portal:
2. Create a Self-Signed Root CA Cerficate or import a CA cerficate (see Import a
Cerficate and Private Key).
3. Generate a Cerficate to use for Authencaon Portal. Be sure to configure the
following fields:
• Common Name—Enter the DNS name of the intranet host for the Layer 3 interface.
• Signed By—Select the CA cerficate you just created or imported.
• Cerficate Aributes—Click Add, for the Type select IP and, for the Value, enter the
IP address of the Layer 3 interface to which the firewall will redirect requests.
4. Configure an SSL/TLS Service Profile. Assign the Authencaon Portal cerficate you
just created to the profile.
If you don’t assign an SSL/TLS Service Profile, the firewall uses TLS 1.2 by
default. To use a different TLS version, configure an SSL/TLS Service Profile for
the TLS version you want to use.
5. Configure clients to trust the cerficate:
1. Export the CA cerficate you created or imported.
2. Import the cerficate as a trusted root CA into all client browsers, either by manually
configuring the browser or by adding the cerficate to the trusted roots in an Acve
Directory (AD) Group Policy Object (GPO).
STEP 4 | (Oponal) Configure Client Cerficate Authencaon.
You don’t need an authencaon profile or sequence for client cerficate

authencaon. If you configure both an authencaon profile/sequence and cerficate
authencaon, users must authencate using both.
1. Use a root CA cerficate to generate a client cerficate for each user who will
authencate through Authencaon Portal. The CA in this case is usually your enterprise
CA, not the firewall.
2. Export the CA cerficate in PEM format to a system that the firewall can access.
3. Import the CA cerficate onto the firewall: see Import a Cerficate and Private Key. Aer
the import, click the imported cerficate, select Trusted Root CA, and click OK.
• In the Username Field drop-down, select the cerficate field that contains the user
identy informaon.
• In the CA Cerficates list, click Add and select the CA cerficate you just imported.
User-ID
STEP 5 | (Oponal) Configure Authencaon Portal for the Apple Capve Network Assistant.
This step is only required if you are using Authencaon Portal with the Apple Capve
Network Assistant (CNA). To use Authencaon Portal with CNA, perform the following steps.
1. Verify you have specified an FQDN for the redirect host (not just an IP address).
2. Select an SSL/TLS service profile that uses a publicly-signed cerficate for the specified
FQDN.
3. Enter the following command to adjust the number of requests supported for
Authencaon Portal: set deviceconfig setting ctd cap-portal-ask-
requests <threshold-value>
By default, the firewall has a rate limit threshold for Authencaon Portal that limits the
number of requests to one request every two seconds. The CNA sends mulple requests
that can exceed this limit, which can result in a TCP reset and an error from the CNA. The
recommended threshold value is 5 (default is one). This value will allow up to 5 requests
every two seconds. Based on your environment, you may need to configure a different
value. If the current value is not sufficient to handle the number of requests, increase the
value.
STEP 6 | Configure the Authencaon Portal sengs.

1. Select Device > User Idenficaon > Authencaon Portal Sengs and edit the
sengs.
2. Enable Authencaon Portal (default is enabled).
3. Specify the Timer, which is the maximum me in minutes that the firewall retains
an IP address-to-username mapping for a user aer that user authencates through
Authencaon Portal (default is 60; range is 1 to 1,440). Aer the Timer expires, the
User-ID
firewall removes the mapping and any associated Authencaon Timestamps used to
evaluate the Timeout in Authencaon policy rules.
When evaluang the Authencaon Portal Timer and the Timeout value in each
Authencaon policy rule, the firewall prompts the user to re-authencate for
whichever seng expires first. Upon re-authencang, the firewall resets the
me count for the Authencaon Portal Timer and records new authencaon
mestamps for the user. Therefore, to enable different Timeout periods for
different Authencaon rules, set the Authencaon Portal Timer to a value the
same as or higher than any rule Timeout.
4. Select the SSL/TLS Service Profile you created for redirect requests over TLS. See
Configure an SSL/TLS Service Profile.
5. Select the Mode (in this example, Redirect).
6. (Redirect mode only) Specify the Redirect Host, which is the intranet hostname (a
hostname with no period in its name) that resolves to the IP address of the Layer 3
interface on the firewall to which web requests are redirected.
If users authencate through Kerberos single sign-on (SSO), the Redirect Host must be
the same as the hostname specified in the Kerberos keytab.
7. Select the fall back authencaon method to use:
• To use client cerficate authencaon, select the Cerficate Profile you created.
• To use global sengs for interacve or SSO authencaon, select the Authencaon
Profile you configured.
• To use Authencaon policy rule-specific sengs for interacve or SSO
authencaon, assign authencaon profiles to authencaon enforcement objects
when you Configure Authencaon Policy.
8. Click OK and Commit the Authencaon Portal configuraon.
STEP 7 | Next steps...

The firewall does not display the Authencaon Portal web form to users unl you Configure
Authencaon Policy rules that trigger authencaon when users request services or
applicaons.
Configure User Mapping for Terminal Server Users

Individual terminal server users appear to have the same IP address and therefore an IP address-
to-username mapping is not sufficient to idenfy a specific user. To idenfy specific users on
Windows-based terminal servers, the Palo Alto Networks Terminal Server agent (TS agent)
allocates a port range to each user. The TS agent then nofies every connected firewall about the
allocated port range, which allows the firewall to create an IP address-port-user mapping table and
enable user- and group-based security policy enforcement. For non-Windows terminal servers,
configure the PAN-OS XML API to extract user mapping informaon. The following values apply
for both methods:
• Default port range: 1025 to 65534
• Per user block size: 200
• Maximum number of mul-user systems: 2,500
User-ID
For informaon about the terminal servers supported by the TS agent and the number of TS
agents supported on each firewall model, refer to the Palo Alto Networks Compability Matrix
and the Product Comparison Tool.
The following secons describe how to configure user mapping for terminal server users:
• Configure the Palo Alto Networks Terminal Server (TS) Agent for User Mapping
• Retrieve User Mappings from a Terminal Server Using the PAN-OS XML API
Configure the Palo Alto Networks Terminal Server (TS) Agent for User Mapping
Use the following procedure to install and configure the TS agent on the terminal server. To map
all your users, you must install the TS agent on all terminal servers to which your users log in.
If you are using TS agent 7.0 or a later version, disable any Sophos anvirus soware on
the TS agent host. Otherwise, the anvirus soware overwrites the source ports that the
TS agent allocates.
For informaon about default values, ranges, and other specificaons, refer to Configure
User Mapping for Terminal Server Users. For informaon about the terminal servers
supported by the TS agent and the number of TS agents supported on each firewall model,
refer to the Palo Alto Networks Compability Matrix.
STEP 1 | Download the TS agent installer.

1. Log in to the Palo Alto Networks Customer Support Portal.
2. Select Updates > Soware Updates.
3. Set Filter By to Terminal Services Agent and select the version of the agent you want to
install from the corresponding Download column. For example, to download TS agent
9.0, select TaInstall-9.0.msi.
4. Save the TaInstall.x64-x.x.x-xx.msi or TaInstall-x.x.x-xx.msi file on
the systems where you plan to install the agent; be sure to select the appropriate version
based on whether the Windows system is running a 32-bit or a 64-bit OS.
User-ID
STEP 2 | Run the installer as an administrator.

1. Open the Windows Start menu, right-click the Command Prompt program, and Run as
administrator.
2. From the command line, run the .msi file you downloaded. For example, if you saved the
TaInstall-9.0.msi file to the Desktop, then enter the following:
C:\Users\administrator.acme>cd Desktop
C:\Users\administrator.acme\Desktop>TaInstall-9.0.0-1.msi
3. Follow the setup prompts to install the agent using the default sengs. The setup
installs the agent in C:\ProgramFiles\Palo Alto Networks\Terminal Server
Agent.
To ensure correct port allocaon, you must use the default Terminal Server agent
installaon folder locaon.
4. When the installaon completes, Close the setup dialog.
If you are upgrading to a TS agent version that has a newer driver than the
exisng installaon, the installaon wizard prompts you to reboot the system
aer you upgrade.
STEP 3 | Define the range of ports for the TS agent to allocate to end users.
The System Source Port Allocaon Range and System Reserved Source Ports specify
the range of ports that are allocated to non-user sessions. Make sure the values in
these fields do not overlap with the ports you designate for user traffic. These values
can be changed only by eding the corresponding Windows registry sengs. The TS
agent does not allocate ports for network traffic emied by session 0.
1. Open the Windows Start menu and select Terminal Server Agent to launch the Terminal
Server agent applicaon.
2. Configure (side menu) the agent.
3. Enter the Source Port Allocaon Range (default is 20,000-39,999). This is the full range
of port numbers that the TS agent will allocate for user mapping. The port range you
specify cannot overlap the System Source Port Allocaon Range.
4. (Oponal) If there are ports or port ranges within the source port allocaon that
you do not want the TS agent to allocate to user sessions, specify them as Reserved
Source Ports. To include mulple ranges, use commas with no spaces (for example:
2000-3000,3500,4000-5000).
5. Specify the number of ports to allocate to each individual user upon login to the terminal
server (Port Allocaon Start Size Per User); default is 200.
6. Specify the Port Allocaon Maximum Size Per User, which is the maximum number of
ports the Terminal Server agent can allocate to an individual user.
7. Specify whether to connue processing traffic from the user if the user runs out of
allocated ports. The Fail port binding when available ports are used up opon is enabled
by default, which indicates that the applicaon will fail to send traffic when all ports are
User-ID
used. To enable users to connue using applicaons when they run out of ports, disable
(clear) this opon, but if you do, this traffic may not be idenfied with User-ID.
8. If the terminal server stops responding when you aempt to shut it down, enable the
Detach agent driver at shutdown opon.
STEP 4 | (Oponal) Assign your own cerficates for mutual authencaon between the TS agent and
the firewall.
1. Obtain your cerficate for the TS agent from your enterprise PKI or generate one
on your firewall. The private key of the server cerficate must be encrypted and the
cerficate must be uploaded in PEM file format. Perform one of the following tasks to
upload a cerficate:
• Generate a Cerficate and export it.
• Export a cerficate from your enterprise cerficate authority (CA).
2. Add a server cerficate to the TS agent.
1. On the TS agent, select Server Cerficate and Add a new cerficate.
2. Enter the path and name of the cerficate file received from the CA or browse to the
cerficate file.
3. Enter the private key password.
4. Click OK.
The TS agent uses a self-signed cerficate on port 5009 with following

informaon:Issuer: CN=Terminal Server Agent, OU=Engineering, O=Palo Alto
Networks, L=Santa Clara, S=California, C=USSubject: CN=Terminal Server
Agent, OU=Engineering, O=Palo Alto Networks, L=Santa Clara, S=California,
C=US
3. Configure and assign the cerficate profile for the firewall.
1. Select Device > Cerficate Management > Cerficate Profile to Configure a
Cerficate Profile.
You can assign only one cerficate profile for Windows User-ID agents and
TS agents. Therefore, your cerficate profile must include all cerficate
authories that issued cerficates uploaded to connected Windows User-ID
and TS agents.
3. Edit ( ) and select the cerficate profile you configured in the previous step as the
User-ID Cerficate Profile.
4. Click OK.
User-ID
STEP 5 | Configure the firewall to connect to the Terminal Server agent.

Complete the following steps on each firewall you want to connect to the Terminal Server
agent to receive user mappings:
1. Select Device > User Idenficaon > Terminal Server Agents and Add a new TS agent.
2. Enter a Name for the Terminal Server agent.
3. Enter the hostname or IP address of the Windows Host on which the Terminal Server
agent is installed.
The hostname or IP address must resolve to a stac IP address. If you change the
exisng hostname, the TS agent resets when you commit the changes to resolve the new
hostname. If the hostname resolves to mulple IP addresses, the TS agent uses the first
address in the list.
4. (Oponal) Enter the hostname or IP address for any Alternave IP Addresses that can
appear as the source IP address for the outgoing traffic.
The hostname or IP address must resolve to a stac IP address. You can enter up to 8 IP
addresses or hostnames.
5. Enter the Port number on which the agent will listen for user mapping requests. This
value must match the value configured on the Terminal Server agent. By default, the port
is set to 5009 on the firewall and on the agent. If you change it on the firewall, you must
also change the Listening Port on the Terminal Server agent Configure dialog to the same
port.
6. Make sure that the configuraon is Enabled and then click OK.
8. Verify that the Connected status displays as connected (a green light).
STEP 6 | Verify that the Terminal Server agent is successfully mapping IP addresses to usernames and
that the firewalls can connect to the agent.
1. Open the Windows Start menu and select Terminal Server Agent.
2. Verify that the firewalls can connect by making sure the Connecon Status of each
firewall in the Connecon List is Connected.
3. Verify that the Terminal Server agent is successfully mapping port ranges to usernames
(Monitor in the side menu) and confirm that the mapping table is populated.
User-ID
STEP 7 | (Windows 2012 R2 servers only) Disable Enhanced Protected Mode in Microso Internet
Explorer for each user who uses that browser.
This task is not necessary for other browsers, such as Google Chrome or Mozilla Firefox.
To disable Enhanced Protected Mode for all users, use Local Security Policy.
Perform these steps on the Windows Server:

1. Start Internet Explorer.
2. Select Sengs > Internet opons > Advanced and scroll to the Security secon.
3. Disable (clear) the Enable Enhanced Protected Mode opon.
4. Click OK.
In Internet Explorer, Palo Alto Networks recommends that you do not disable
Protected Mode, which differs from Enhanced Protected Mode.
Retrieve User Mappings from a Terminal Server Using the PAN-OS XML API
The PAN-OS XML API uses standard HTTP requests to send and receive data. API calls can be
made directly from command line ulies such as cURL or using any scripng or applicaon
framework that supports RESTful services.
To enable a non-Windows terminal server to send user mapping informaon directly to the
firewall, create scripts that extract the user login and logout events and use them for input to
the PAN-OS XML API request format. Then define the mechanisms for subming the XML
API request(s) to the firewall using cURL or wget and providing the firewall’s API key for secure
communicaon. Creang user mappings from mul-user systems such as terminal servers requires
use of the following API messages:
• <multiusersystem>—Sets up the configuraon for an XML API Mul-user System on the
firewall. This message allows for definion of the terminal server IP address (this will be the
source address for all users on that terminal server). In addion, the <multiusersystem>
setup message specifies the range of source port numbers to allocate for user mapping and
the number of ports to allocate to each individual user upon login (called the block size). If you
want to use the default source port allocaon range (1025-65534) and block size (200), you do
not need to send a <multiusersystem> setup event to the firewall. Instead, the firewall will
automacally generate the XML API Mul-user System configuraon with the default sengs
upon receipt of the first user login event message.
• <blockstart>—Used with the <login> and <logout> messages to indicate the starng
source port number allocated to the user. The firewall then uses the block size to determine the
actual range of port numbers to map to the IP address and username in the login message. For
example, if the <blockstart> value is 13200 and the block size configured for the mul-user
system is 300, the actual source port range allocated to the user is 13200 through 13499. Each
connecon iniated by the user should use a unique source port number within the allocated
range, enabling the firewall to idenfy the user based on its IP address-port-user mappings
for enforcement of user- and group-based security rules. When a user exhausts all the ports
allocated, the terminal server must send a new <login> message allocang a new port range
for the user so that the firewall can update the IP address-port-user mapping. In addion, a
single username can have mulple blocks of ports mapped simultaneously. When the firewall
User-ID
receives a <logout> message that includes a <blockstart> parameter, it removes the

corresponding IP address-port-user mapping from its mapping table. When the firewall receives
a <logout> message with a username and IP address, but no <blockstart>, it removes the
user from its table. And, if the firewall receives a <logout> message with an IP address only, it
removes the mul-user system and all mappings associated with it.
The XML files that the terminal server sends to the firewall can contain mulple message
types and the messages do not need to be in any parcular order within the file. However,
upon receiving an XML file that contains mulple message types, the firewall will process
them in the following order: mulusersystem requests first, followed by logins, then
logouts.
The following workflow provides an example of how to use the PAN-OS XML API to send user
mappings from a non-Windows terminal server to the firewall.
STEP 1 | Generate the API key that will be used to authencate the API communicaon between
the firewall and the terminal server. To generate the key you must provide login credenals
for an administrave account; the API is available to all administrators (including role-based
administrators with XML API privileges enabled).
Any special characters in the password must be URL/ percent-encoded.
From a browser, log in to the firewall. Then, to generate the API key for the firewall, open a
new browser window and enter the following URL:
https://<Firewall-IPaddress>/api/?
type=keygen&user=<username>&password=<password>
Where <Firewall-IPaddress> is the IP address or FQDN of the firewall and <username>

and <password> are the credenals for the administrave user account on the firewall. For
example:
https://10.1.2.5/api/?type=keygen&user=admin&password=admin
The firewall responds with a message containing the key, for example:
<response status="success">
<result>
<key>k7J335J6hI7nBxIqyfa62sZugWx7ot%2BgzEA9UOnlZRg=</key>
</result>
</response>
User-ID
STEP 2 | (Oponal) Generate a setup message that the terminal server will send to specify the port
range and block size of ports per user that your Terminal Server agent uses.
If the Terminal Server agent does not send a setup message, the firewall will automacally
create a Terminal Server agent configuraon using the following default sengs upon receipt
of the first login message:
• Default port range: 1025 to 65534
• Per user block size: 200
• Maximum number of mul-user systems: 1,000
The following shows a sample setup message:
<uid-message>
<payload>
<multiusersystem>
<entry ip="10.1.1.23" startport="20000" endport="39999"
blocksize="100/">
</multiusersystem>
</payload>
<type>update</type>
<version>1.0</version>
</uid-message>
where entry ip specifies the IP address assigned to terminal server users, startport
and endport specify the port range to use when assigning ports to individual users, and
blocksize specifies the number of ports to assign to each user. The maximum blocksize is
4000 and each mul-user system can allocate a maximum of 1000 blocks.
If you define a custom blocksize and or port range, keep in mind that you must configure the
values such that every port in the range gets allocated and that there are no gaps or unused
ports. For example, if you set the port range to 1000–1499, you could set the block size to
100, but not to 200. This is because if you set it to 200, there would be unused ports at the
end of the range.
STEP 3 | Create a script that will extract the login events and create the XML input file to send to the
firewall.
Make sure the script enforces assignment of port number ranges at fixed boundaries with
no port overlaps. For example, if the port range is 1000–1999 and the block size is 200,
acceptable blockstart values would be 1000, 1200, 1400, 1600, or 1800. Blockstart values of
1001, 1300, or 1850 would be unacceptable because some of the port numbers in the range
would be le unused.
The login event payload that the terminal server sends to the firewall can contain
mulple login events.
The following shows the input file format for a PAN-OS XML login event:
<uid-message>
<payload>
<login>
User-ID
<entry name="acme\jjaso" ip="10.1.1.23" blockstart="20000">

<entry name="acme\jparker" ip="10.1.1.23" blockstart="20100">
<entry name="acme\ccrisp" ip="10.1.1.23" blockstart="21000">
</login>
</payload>
<type>update</type>
</uid-message>
The firewall uses this informaon to populate its user mapping table. Based on the mappings
extracted from the example above, if the firewall received a packet with a source address and
port of 10.1.1.23:20101, it would map the request to user jparker for policy enforcement.
Each mul-user system can allocate a maximum of 1,000 port blocks.
STEP 4 | Create a script that will extract the logout events and create the XML input file to send to the
firewall.
Upon receipt of a logout event message with a blockstart parameter, the firewall removes
the corresponding IP address-port-user mapping. If the logout message contains a username
and IP address, but no blockstart parameter, the firewall removes all mappings for the user.
If the logout message contains an IP address only, the firewall removes the mul-user system
and all associated mappings.
The following shows the input file format for a PAN-OS XML logout event:
<uid-message>
<payload>
<logout>
<entry name="acme\jjaso" ip="10.1.1.23" blockstart="20000">
<entry name="acme\ccrisp" ip="10.1.1.23">
<entry ip="10.2.5.4">
</logout>
</payload>
<type>update</type>
</uid-message>
You can also clear the muluser system entry from the firewall using the following CLI
command: clear xml-api multiusersystem
STEP 5 | Make sure that the scripts you create include a way to dynamically enforce that the port
block range allocated using the XML API matches the actual source port assigned to the user
on the terminal server and that the mapping is removed when the user logs out or the port
allocaon changes.
One way to do this would be to use netfilter NAT rules to hide user sessions behind the
specific port ranges allocated via the XML API based on the uid. For example, to ensure that a
User-ID
user with the user ID jjaso is mapped to a source network address translaon (SNAT) value of
10.1.1.23:20000-20099, the script you create should include the following:
[root@ts1 ~]# iptables -t nat -A POSTROUTING -m owner --uid-owner

jjaso -p tcp -j SNAT --to-source 10.1.1.23:20000-20099
Similarly, the scripts you create should also ensure that the IP table roung configuraon
dynamically removes the SNAT mapping when the user logs out or the port allocaon changes:
[root@ts1 ~]# iptables -t nat -D POSTROUTING 1
STEP 6 | Define how to package the XML input files containing the setup, login, and logout events into
wget or cURL messages for transmission to the firewall.
To apply the files to the firewall using wget:
> wget --post file <filename> “https://<Firewall-

IPaddress>/api/?type=user-id&key=<key>&file-
name=<input_filename.xml>&client=wget&vsys=<VSYS_name>”
For example, the syntax for sending an input file named login.xml to the firewall at 10.2.5.11
using key k7J335J6hI7nBxIqyfa62sZugWx7ot%2BgzEA9UOnlZRg using wget would look
as follows:
> wget --post file login.xml “https://10.2.5.11/api/?type=user-

id&key=k7J335J6hI7nBxIqyfa62sZugWx7ot%2BgzEA9UOnlZRg&file-
name=login.xml&client=wget&vsys=vsys1”
To apply the file to the firewall using cURL:
> curl --form file=@<filename> https://<Firewall-IPaddress>/api/?

type=user-id&key=<key>&vsys=<VSYS_name>
For example, the syntax for sending an input file named login.xml to the firewall at 10.2.5.11
using key k7J335J6hI7nBxIqyfa62sZugWx7ot%2BgzEA9UOnlZRg using cURL would
look as follows:
> curl --form [email protected] “https://10.2.5.11/api/?type=user-

id&key=k7J335J6hI7nBxIqyfa62sZugWx7ot%2BgzEA9UOnlZRg&vsys=vsys1”
STEP 7 | Verify that the firewall is successfully receiving login events from the terminal servers.
Verify the configuraon by opening an SSH connecon to the firewall and then running the
following CLI commands:
To verify if the terminal server is connecng to the firewall over XML:
admin@PA-5250> show user xml-api multiusersystem

Host Vsys Users Blocks
----------------------------------------
User-ID
10.5.204.43 vsys1 5 2
To verify that the firewall is receiving mappings from a terminal server over XML:
admin@PA-5250> show user ip-port-user-mapping all
Global max host index 1, host hash count 1
XML API Multi-user System 10.5.204.43

Vsys 1, Flag 3
Port range: 20000 - 39999
Port size: start 200; max 2000
Block count 100, port count 20000
20000-20199: acme\administrator
Total host: 1
Send User Mappings to User-ID Using the XML API

User-ID provides many out-of-the box methods for obtaining user mapping informaon. However,
you might have applicaons or devices that capture user informaon but cannot navely integrate
with User-ID. For example, you might have a custom, internally developed applicaon or a device
that no standard user mapping method supports. In such cases, you can use the PAN-OS XML
API to create custom scripts that send the informaon to the PAN-OS integrated User-ID agent
or directly to the firewall. The PAN-OS XML API uses standard HTTP requests to send and
receive data. API calls can be made directly from command line ulies such as cURL or using any
scripng or applicaon framework that supports POST and GET requests.
To enable an external system to send user mapping informaon to the PAN-OS integrated User-
ID agent, create scripts that extract user login and logout events and use the events as input
to the PAN-OS XML API request. Then define the mechanisms for subming the XML API
requests to the firewall (using cURL, for example) and use the API key of the firewall for secure
communicaon. For more details, refer to the PAN-OS XML API Usage Guide.
User-ID
Enable User- and Group-Based Policy

Aer you Enable User-ID, you will be able to configure Security Policy that applies to specific
users and groups. User-based policy controls can also include applicaon informaon (including
which category and subcategory it belongs in, its underlying technology, or what the applicaon
characteriscs are). You can define policy rules to safely enable applicaons based on users or
groups of users, in either outbound or inbound direcons.
Examples of user-based policies include:
• Enable only the IT department to use tools such as SSH, telnet, and FTP on standard ports.
• Allow the Help Desk Services group to use Slack.
• Allow all users to read Facebook, but block the use of Facebook apps, and restrict posng to
employees in markeng.
User-ID
Enable Policy for Users with Mulple Accounts

If a user in your organizaon has mulple responsibilies, that user might have mulple
usernames (accounts), each with disnct privileges for accessing a parcular set of services, but
with all the usernames sharing the same IP address (the client system of the user). However, the
User-ID agent can map any one IP address (or IP address and port range for terminal server users)
to only one username for enforcing policy, and you can’t predict which username the agent will
map. To control access for all the usernames of a user, you must make adjustments to the rules,
user groups, and User-ID agent.
For example, say the firewall has a rule that allows username corp_user to access email and a rule
that allows username admin_user to access a MySQL server. The user logs in with either username
from the same client IP address. If the User-ID agent maps the IP address to corp_user, then
whether the user logs in as corp_user or admin_user, the firewall idenfies that user as corp_user
and allows access to email but not the MySQL server. On the other hand, if the User-ID agent
maps the IP address to admin_user, the firewall always idenfies the user as admin_user regardless
of login and allows access to the MySQL server but not email. The following steps describe how to
enforce both rules in this example.
STEP 1 | Configure a user group for each service that requires disnct access privileges.
In this example, each group is for a single service (email or MySQL server). However, it is
common to configure each group for a set of services that require the same privileges (for
example, one group for all basic user services and one group for all administrave services).
If your organizaon already has user groups that can access the services that the user requires,
simply add the username that is used for less restricted services to those groups. In this
example, the email server requires less restricted access than the MySQL server, and corp_user
is the username for accessing email. Therefore, you add corp_user to a group that can access
email (corp_employees) and to a group that can access the MySQL server (network_services).
If adding a username to a parcular exisng group would violate your organizaonal pracces,
you can create a custom group based on an LDAP filter. For this example, say network_services
is a custom group, which you configure as follows:
1. Select Device > User Idenficaon > Group Mapping Sengs and Add a group mapping
configuraon with a unique Name.
2. Select an LDAP Server Profile and ensure the Enabled check box is enabled.
3. Select the Custom Group tab and Add a custom group with network_services as a Name.
4. Specify an LDAP Filter that matches an LDAP aribute of corp_user and click OK.
Later, if other users that are in the group for less restricted services are given
addional usernames that access more restricted services, you can add those
usernames to the group for more restricted services. This scenario is more
common than the inverse; a user with access to more restricted services usually
already has access to less restricted services.
User-ID
STEP 2 | Configure the rules that control user access based on the groups you just configured.
For more informaon, refer to Enable user- and group-based policy enforcement.
1. Configure a security rule that allows the corp_employees group to access email.
2. Configure a security rule that allows the network_services group to access the MySQL
server.
STEP 3 | Configure the ignore list of the User-ID agent.

This ensures that the User-ID agent maps the client IP address only to the username that is a
member of the groups assigned to the rules you just configured. The ignore list must contain all
the usernames of the user that are not members of those groups.
In this example, you add admin_user to the ignore list of the Windows-based User-ID agent
to ensure that it maps the client IP address to corp_user. This guarantees that, whether the
user logs in as corp_user or admin_user, the firewall idenfies the user as corp_user and applies
both rules that you configured because corp_user is a member of the groups that the rules
reference.
1. Create an ignore_user_list.txt file.
2. Open the file and add admin_user.
If you later add more usernames, each must be on a separate line.
3. Save the file to the User-ID agent folder on the domain server where the agent is
installed.
If you use the PAN-OS integrated User-ID agent, see Configure User Mapping
Using the PAN-OS Integrated User-ID Agent for instrucons on how to
configure the ignore list.
STEP 4 | Configure endpoint authencaon for the restricted services.

This enables the endpoint to verify the credenals of the user and preserves the ability to
enable access for users with mulple usernames.
In this example, you have configured a firewall rule that allows corp_user, as a member of
the network_services group, to send a service request to the MySQL server. You must now
configure the MySQL server to respond to any unauthorized username (such as corp_user) by
prompng the user to enter the login credenals of an authorized username (admin_user).
If the user logs in to the network as admin_user, the user can then access the MySQL
server without it prompng for the admin_user credenals again.
In this example, both corp_user and admin_user have email accounts, so the email server won’t
prompt for addional credenals regardless of which username the user entered when logging
in to the network.
The firewall is now ready to enforce rules for a user with mulple usernames.
User-ID
Verify the User-ID Configuraon

Aer you configure user and group mapping, enable User-ID in your Security policy, and configure
Authencaon policy, you should verify that User-ID works properly.
STEP 2 | Verify that group mapping is working.

From the CLI, enter the following operaonal command:
> show user group-mapping statistics
STEP 3 | Verify that user mapping is working.

If you are using the PAN-OS integrated User-ID agent, you can verify this from the CLI using
the following command:
> show user ip-user-mapping-mp all

IP Vsys From User Timeout (sec)
------------------------------------------------------
192.168.201.1 vsys1 UIA acme\george 210
192.168.201.11 vsys1 UIA acme\duane 210
192.168.201.50 vsys1 UIA acme\betsy 210
192.168.201.10 vsys1 UIA acme\administrator 210
192.168.201.100 vsys1 AD acme\administrator 748
Total: 5 users
*: WMI probe succeeded
User-ID
STEP 4 | Test your Security policy rule.

• From a machine in the zone where User-ID is enabled, aempt to access sites and
applicaons to test the rules you defined in your policy and ensure that traffic is allowed
and denied as expected.
• You can also troubleshoot the running configuraon to determine whether the policy is
configured correctly. For example, suppose you have a rule that blocks users from playing
World of Warcra; you could test the policy as follows:
1. Select Device > Troubleshoong, and select Security Policy Match from the Select Test
drop-down.
2. Enter 0.0.0.0 as the Source and Desnaon IP addresses. This executes the policy
match test against any source and desnaon IP addresses.
3. Enter the Desnaon Port.
5. Execute the security policy match test.
User-ID
STEP 5 | Test your Authencaon policy and Authencaon Portal configuraon.

1. From the same zone, go to a machine that is not a member of your directory, such as a
Mac OS system, and try to ping to a system external to the zone. The ping should work
without requiring authencaon.
2. From the same machine, open a browser and navigate to a web site in a desnaon zone
that matches an Authencaon rule you defined. The Authencaon Portal web form
should display and prompt you for login credenals.
3. Log in using the correct credenals and confirm that you are redirected to the requested
page.
4. You can also test your Authencaon policy using the test authentication-
policy-match operaonal command as follows:
> test authentication-policy-match from corporate to internet

source 192.168.201.10 destination 8.8.8.8
Matched rule: 'authentication portal' action: web-form
STEP 6 | Verify that the log files display usernames.

Select a logs page (such as Monitor > Logs > Traffic) and verify that the Source User column
displays usernames.
STEP 7 | Verify that reports display usernames.

1. Select Monitor > Reports.
2. Select a report type that includes usernames. For example, the Denied Applicaons
report, Source User column, should display a list of the users who aempted to access
the applicaons.
User-ID
Deploy User-ID in a Large-Scale Network

A large-scale network can have hundreds of informaon sources that firewalls query to map
IP addresses to usernames and to map usernames to user groups. You can simplify User-
ID administraon for such a network by aggregang the user mapping and group mapping
informaon before the User-ID agents collect it, thereby reducing the number of required agents.
A large-scale network can also have numerous firewalls that use the mapping informaon to
enforce policies. You can reduce the resources that the firewalls and informaon sources use
in the querying process by configuring some firewalls to acquire mapping informaon through
redistribuon instead of direct querying. Redistribuon also enables the firewalls to enforce user-
based policies when users rely on local sources for authencaon (such as regional directory
services) but need access to remote services and applicaons (such as global data center
applicaons).
If you Configure Authencaon Policy, your firewalls must also redistribute the Authencaon
Timestamps associated with user responses to authencaon challenges. Firewalls use the
mestamps to evaluate the meouts for Authencaon policy rules. The meouts allow a user
who successfully authencates to later request services and applicaons without authencang
again within the meout periods. Redistribung mestamps enables you to enforce consistent
meouts for each user even if the firewall that inially grants a user access is not the same firewall
that later controls access for that user.
If you have configured mulple virtual systems, you can share IP address-to-username mapping
informaon across virtual systems by selecng a virtual system as a User-ID hub.
• Deploy User-ID for Numerous Mapping Informaon Sources
• Redistribute Data and Authencaon Timestamps
• Share User-ID Mappings Across Virtual Systems
Deploy User-ID for Numerous Mapping Informaon Sources

You can use Windows Log Forwarding and Global Catalog servers to simplify user mapping and
group mapping in a large-scale network of Microso Acve Directory (AD) domain controllers or
Exchange servers. These methods simplify User-ID administraon by aggregang the mapping
informaon before the User-ID agents collect it, thereby reducing the number of required agents.
• Windows Log Forwarding and Global Catalog Servers
• Plan a Large-Scale User-ID Deployment
• Configure Windows Log Forwarding
• Configure User-ID for Numerous Mapping Informaon Sources
Windows Log Forwarding and Global Catalog Servers

Because each User-ID agent can monitor up to 100 servers, the firewall needs mulple User-
ID agents to monitor a network with hundreds of AD domain controllers or Exchange servers.
Creang and managing numerous User-ID agents involves considerable administrave overhead,
especially in expanding networks where tracking new domain controllers is difficult. Windows
Log Forwarding enables you to minimize the administrave overhead by reducing the number of
servers to monitor and thereby reducing the number of User-ID agents to manage. When you
User-ID
configure Windows Log Forwarding, mulple domain controllers export their login events to a
single domain member from which a User-ID agent collects the user mapping informaon.
You can configure Windows Log Forwarding for Windows Server versions 2012 and 2012
R2. Windows Log Forwarding is not available for non-Microso servers.
To collect group mapping informaon in a large-scale network, you can configure the firewall to
query a Global Catalog server that receives account informaon from the domain controllers.
The following figure illustrates user mapping and group mapping for a large-scale network
in which the firewall uses a Windows-based User-ID agent. See Plan a Large-Scale User-ID
Deployment to determine if this deployment suits your network.
Plan a Large-Scale User-ID Deployment

When deciding whether to use Windows Log Forwarding and Global Catalog servers for your
User-ID implementaon, consult your system administrator to determine:
User-ID
Bandwidth required for domain controllers to forward login events to member servers.
The bandwidth is a mulple of the login rate (number of logins per minute) of the domain
controllers and the byte size of each login event.
Domain controllers won’t forward their enre security logs, they forward only the events that
the user mapping process requires per login: four events for Windows Server 2012 and MS
Exchange.
Whether the following network elements support the required bandwidth:
• Domain controllers—Must support the processing load associated with forwarding the
events.
• Member Servers—Must support the processing load associated with receiving the events.
• Connecons—The geographic distribuon (local or remote) of the domain controllers,
member servers, and Global Catalog servers is a factor. Generally, a remote distribuon
supports less bandwidth.
Configure Windows Log Forwarding

To configure Windows Log Forwarding, you need administrave privileges for configuring group
policies on Windows servers. Configure Windows Log Forwarding on all the Windows Event
Collectors—the member servers that collect login events from domain controllers. The following is
an overview of the tasks; consult your Windows Server documentaon for the specific steps.
STEP 1 | On each Windows Event Collector, enable event collecon, add the domain controllers
as event sources, and configure the event collecon query (subscripon). The events you
specify in the subscripon vary by domain controller plaorm:
• Windows Server 2012 (including R2) and 2016, or MS Exchange—The event IDs for the
required events are 4768 (Authencaon Ticket Granted), 4769 (Service Ticket Granted),
4770 (Ticket Granted Renewed), and 4624 (Logon Success).
To forward events as quickly as possible, Minimize Latency when configuring the

subscripon.
User-ID agents monitor the Security log on Windows Event Collectors, not the default
forwarded events locaon. To change the event logging path to the Security log, perform the
following steps on each Windows Event Collector.
1. Open the Event Viewer.
2. Right-click the Security log and select Properes.
3. Copy the Log path (default %SystemRoot%\System32\Winevt\Logs
\security.evtx) and click OK.
4. Right-click the Forwarded Events folder and select Properes.
5. Replace the default Log path (%SystemRoot%\System32\Winevt\Logs
\ForwardedEvents.evtx) by pasng the value from the Security log, and then click OK.
STEP 2 | Configure a group policy to enable Windows Remote Management (WinRM) on the domain
controllers.
STEP 3 | Configure a group policy to enable Windows Event Forwarding on the domain controllers.
User-ID
Configure User-ID for Numerous Mapping Informaon Sources
STEP 1 | Configure Windows Log Forwarding on the member servers that will collect login events.
Configure Windows Log Forwarding. This step requires administrave privileges for configuring
group policies on Windows servers.
STEP 2 | Install the Windows-based User-ID agent.

Install the Windows-Based User-ID Agent on a Windows server that can access the member
servers. Make sure the system that will host the User-ID agent is a member of the same
domain as the servers it will monitor.
STEP 3 | Configure the User-ID agent to collect user mapping informaon from the member servers.
1. Start the Windows-based User-ID agent.
2. Select User Idenficaon > Discovery and perform the following steps for each member
server that will receive events from domain controllers:
1. In the Servers secon, click Add and enter a Name to idenfy the member server.
2. In the Server Address field, enter the FQDN or IP address of the member server.
3. For the Server Type, select Microso Acve Directory.
4. Click OK to save the server entry.
3. Configure the remaining User-ID agent sengs (refer to Configure the Windows-Based
User-ID Agent for User Mapping).
4. If the User-ID sources provide usernames in mulple formats, specify the format for the
Primary Username when you Map Users to Groups.
The primary username is the username that idenfies the user on the firewall and
represents the user in reports and logs, regardless of the format that the User-ID source
provides.
STEP 4 | Configure an LDAP server profile to specify how the firewall connects to the Global Catalog
servers (up to four) for group mapping informaon.
To improve availability, use at least two Global Catalog servers for redundancy.
You can collect group mapping informaon only for universal groups, not local domain groups
(subdomains).
1. Select Device > Server Profiles > LDAP, click Add, and enter a Name for the profile.
2. In the Servers secon, for each Global Catalog, click Add and enter the server Name, IP
address (LDAP Server), and Port. For a plaintext or Start Transport Layer Security (Start
TLS) connecon, use Port 3268. For an LDAP over SSL connecon, use Port 3269. If
the connecon will use Start TLS or LDAP over SSL, select the Require SSL/TLS secured
connecon check box.
3. In the Base DN field, enter the Disnguished Name (DN) of the point in the Global
Catalog server where the firewall will start searching for group mapping informaon (for
example, DC=acbdomain,DC=com).
4. For the Type, select acve-directory.
User-ID
STEP 5 | Configure an LDAP server profile to specify how the firewall connects to the servers (up to
four) that contain domain mapping informaon.
User-ID uses this informaon to map DNS domain names to NetBIOS domain names. This
mapping ensures consistent domain/username references in policy rules.
To improve availability, use at least two servers for redundancy.
The steps are the same as for the LDAP server profile you created for Global Catalogs in the
previous step, except for the following fields:
• LDAP Server—Enter the IP address of the domain controller that contains the domain
mapping informaon.
• Port—For a plaintext or Start TLS connecon, use Port 389. For an LDAP over SSL
connecon, use Port 636. If the connecon will use Start TLS or LDAP over SSL, select the
Require SSL/TLS secured connecon check box.
• Base DN—Select the DN of the point in the domain controller where the
firewall will start searching for domain mapping informaon. The value must
start with the string: cn=partitions,cn=configuration (for example,
cn=partitions,cn=configuration,DC=acbdomain,DC=com).
STEP 6 | Create a group mapping configuraon for each LDAP server profile you created.
1. Select Device > User Idenficaon > Group Mapping Sengs.
2. Click Add and enter a Name to idenfy the group mapping configuraon.
3. Select the LDAP Server Profile and ensure the Enabled check box is selected.
If the Global Catalog and domain mapping servers reference more groups than
your security rules require, configure the Group Include List and/or Custom
Group list to limit the groups for which User-ID performs mapping.
Insert Username in HTTP Headers

When you configure a secondary enforcement appliance with your Palo Alto Networks firewall
to enforce user-based policy, the secondary appliance may not have the IP address-to-username
mapping from the firewall. Transming user informaon to downstream appliances may require
deployment of addional appliances such as proxies or negavely impact the user’s experience
(for example, users having to log in mulple mes). By sharing the user's identy in the HTTP
headers, you can enforce user-based policy without negavely impacng the user's experience or
deploying addional infrastructure.
When you configure this feature, apply the URL profile to your Security policy, and commit your
changes, the firewall:
1. Populates the user and domain values with the format of the primary username in the group
mapping for the source user.
2. Encodes this informaon using Base64.
3. Adds the Base64-encoded header to the payload.
User-ID
4. Routes the traffic to the downstream appliance.

If you want to include the username and domain only when the user accesses specific domains,
configure a domain list and the firewall inserts the header only when a domain in the list matches
the Host header of the HTTP request.
To share user informaon with downstream appliances, you must first enable User-ID and
configure group mapping.
To include the username and domain in the header, the firewall requires the IP address-to-
username mapping for the user. If the user is not mapped, the firewall inserts unknown in
Base64 encoding for both the domain and username in the header.
To include the username and domain in headers for HTTPS traffic, you must first create a
decrypon profile to decrypt HTTPS traffic.
This feature supports forward-proxy decrypon traffic.
STEP 1 | Create or edit a URL Filtering Profile.
The firewall does not insert headers if the acon for the URL filtering profile is block
for the domain.
STEP 2 | Create or edit an HTTP header inseron entry using predefined types.
You can define up to five headers for each profile.
STEP 3 | Select Dynamic Fields as the header Type.
STEP 4 | Add the Domains where you want insert headers. When the user accesses a domain in the
list, the firewall inserts the specified header.
STEP 5 | Add a new Header or select X-Authencated-User to edit it.
STEP 6 | Select a header Value format (either ($domain)\($user) or WinNT://($domain)/

($user)) or enter your own format using the ($domain) and ($user) dynamic tokens
(for example, ($user)@($domain) for UserPrincipalName).
Do not use the same dynamic token (either ($user) or ($domain)) more than once
per value.
Each value can be up to 512 characters. The firewall populates the ($user) and ($domain)
dynamic tokens using the primary username in the group mapping profile. For example:
• If the primary username is the sAMAccountName, the value for ($user) is the
sAMAccountName and the value for ($domain) is the NetBios domain name.
• If the primary username is the UserPrincipalName, the ($user) the user account name
(prefix) and the ($domain) is the Domain Name System (DNS) name.
STEP 7 | (Oponal) Select Log to enable logging for the header inseron.
User-ID
STEP 8 | Apply the URL filtering profile to the security policy rule for HTTP or HTTPS traffic.
STEP 9 | Select OK twice to confirm the HTTP header configuraon.
STEP 11 | Verify the firewall includes the username and domain in the HTTP headers.
• Use the show user user-ids all command to verify the group mapping is correct.
• Use the show counter global name ctd_header_insert command to view the
number of HTTP headers inserted by the firewall.
• If you configured logging in Step 7, check the logs for the inserted Base64 encoded
payload (for example, corpexample\testuser would appear in the logs as
Y29ycGV4YW1wbGVcdGVzdHVzZXI=).
Redistribute Data and Authencaon Timestamps

In a large-scale network, instead of configuring all your firewalls to directly query the mapping
informaon sources, you can streamline resource usage by configuring some firewalls to collect
mapping informaon through redistribuon.
You can redistribute user mapping informaon collected through any method except
Terminal Server (TS) agents. You cannot redistribute Group Mapping or HIP match
informaon.
If you use Panorama to manage firewalls and aggregate firewall logs, you can use
Panorama to manage User-ID redistribuon. Leveraging Panorama is a simpler soluon
than creang extra connecons between firewalls to redistribute User-ID informaon.
If you Configure Authencaon Policy, your firewalls must also redistribute the Authencaon
Timestamps that are generated when users authencate to access applicaons and services.
Firewalls use the mestamps to evaluate the meouts for Authencaon policy rules. The
meouts allow a user who successfully authencates to later request services and applicaons
without authencang again within the meout periods. Redistribung mestamps enables you
to enforce consistent meouts across all the firewalls in your network.
Firewalls share data and authencaon mestamps as part of the same redistribuon flow; you
don’t have to configure redistribuon for each informaon type separately.
• Firewall Deployment for Data Redistribuon
• Configure Data Redistribuon
Firewall Deployment for Data Redistribuon

In a large-scale network, instead of configuring all your firewalls to directly query the data
sources, you can streamline resource usage by configuring some firewalls to collect data through
redistribuon. Data redistribuon also provides granularity, allowing you to redistribute only the
types of informaon you specify to only the devices you select. You can also filter the IP user
mappings or IP tag mappings using subnets and ranges to ensure the firewalls collect only the
mappings they need to enforce policy.
User-ID
Data redistribuon can be unidireconal (the agent provides data to the client) or bidireconal,
where both the agent and the client can simultaneously send and receive data.
To redistribute the data, you can use the following architecture types:
• Hub and spoke architecture for a single region:
To redistribute data between firewalls, use a hub and spoke architecture as a best pracce.
In this configuraon, a hub firewall collects the data from sources such as Windows User-ID
agents, Syslog Servers, Domain Controllers, or other firewalls. Configure the redistribuon
client firewalls to collect the data from the hub firewall.
For example, a hub (consisng of a pair of VM-50s for resiliency) could connect to the User-ID
sources for the user mappings. The hub would then be able to redistribute the user mappings
when the client firewalls that use the user mappings to enforce policy connect to the hub to
receive data.
• Mul-Hub and spoke architecture for mulple regions:
If you have firewalls deployed in mulple regions and want to distribute the data to the
firewalls in all of these regions so that you can enforce policy consistently regardless of where
the user logs in, you can use a mul-hub and spoke architecture for mulple regions.
Start by configuring a firewall in each region to collect data from the sources. This firewall acts
as a local hub for redistribuon. This firewall collects the data from all sources in that region so
that it can redistribute it to the client firewalls. Next, configure the client firewalls to connect to
the redistribuon hubs for their region and all other regions so that the client firewalls have all
data from all hubs.
As a best pracce, enable bidireconal redistribuon within a region if the firewalls need to
both send and receive data. For example, if a firewall is acng as a GlobalProtect gateway for
remote users and as a branch firewall for local users, the firewall must send the user mappings
it collects for remote users to the hub firewall as well as receive the user mappings of the local
users from the hub firewall.
• Hierarchical architecture:
To redistribute data, you can also use a hierarchical architecture. For example, to redistribute
data such as User-ID informaon, organize the redistribuon sequence in layers, where
each layer has one or more firewalls. In the boom layer, PAN-OS integrated User-ID agents
running on firewalls and Windows-based User-ID agents running on Windows servers map IP
addresses to usernames. Each higher layer has firewalls that receive the mapping informaon
and authencaon mestamps from up to 100 redistribuon points in the layer beneath it. The
top-layer firewalls aggregate the mappings and mestamps from all layers. This deployment
provides the opon to configure policies for all users in top-layer firewalls and region- or
funcon-specific policies for a subset of users in the corresponding domains served by lower-
layer firewalls.
In this scenario, three layers of firewalls redistribute mappings and mestamps from local
offices to regional offices and then to a global data center. The data center firewall that
aggregates all the informaon shares it with other data center firewalls so that they can all
enforce policy and generate reports for users across your enre network. Only the boom layer
firewalls use User-ID agents to query the directory servers.
The informaon sources that the User-ID agents query do not count towards the maximum
of ten hops in the sequence. However, Windows-based User-ID agents that forward mapping
User-ID
informaon to firewalls do count. Also in this example, the top layer has two hops: the first to
aggregate informaon in one data center firewall and the second to share the informaon with
other data center firewalls.
Configure Data Redistribuon

Before you configure data redistribuon:
Plan the redistribuon architecture. Some factors to consider are:
• Which firewalls will enforce policies for all data types and which firewalls will enforce
region- or funcon-specific policies for a subset of data?
• How many hops does the redistribuon sequence require to aggregate all data? The
maximum allowed number of hops for user mappings is ten and the maximum allowed
number of hops for IP address-to-username mappings and IP address-to-tag mappings is
one.
• How can you minimize the number of firewalls that query the user mapping informaon
sources? The fewer the number of querying firewalls, the lower the processing load is on
both the firewalls and sources.
Configure the data sources from which your redistribuon agents obtain the data to
redistribute to their clients:
• user mappings from PAN-OS Integrated User-ID agents or Windows-based User-ID agents
• IP address-to-tag mappings for dynamic address groups
• username-to-tag mappings for dynamic user groups
• GlobalProtect for HIP-based Policy Enforcement
• data for device quaranne (Panorama only)
Configure Authencaon Policy.
Data redistribuon consists of:
• The redistribuon agent that provides informaon
• The redistribuon client that receives informaon
Perform the following steps on the firewalls in the data redistribuon sequence.
STEP 1 | On a redistribuon client firewall, configure a firewall, Panorama, or Windows User-ID agent
as a data redistribuon agent.
1. Select Device > Data Redistribuon > Agents.
2. Add a redistribuon agent and enter a Name.
3. Confirm that the agent is Enabled.
User-ID
STEP 2 | Add the agent using its Serial Number or its Host and Port.
• To add an agent using a serial number, select the Serial Number of the firewall you want to
use as a redistribuon agent.
• To add an agent using its host and port informaon:
1. Enter the informaon for the Host.
2. Select whether the host is an LDAP Proxy.
3. Enter the Port (default is 5007, range is 1—65535).
4. (Mulple virtual systems only) Enter the Collector Name to idenfy which virtual system
you want to use as a redistribuon agent.
5. (Mulple virtual systems only) Enter and confirm the Collector Pre-Shared Key for the
virtual system you want to use as a redistribuon agent.
STEP 3 | Select one or more Data Type for the agent to redistribute.
• IP User Mappings—IP address-to-username mappings for User-ID.
• IP Tags—IP address-to-tag mappings for dynamic address groups.
• User Tags—Username-to-tag mappings for dynamic user groups.
• HIP—Host informaon profile (HIP) data from GlobalProtect, which includes HIP objects
and profiles.
• Quaranne List—Devices that GlobalProtect idenfies as quaranned.
STEP 4 | (Mulple virtual systems only) Configure a virtual system as a collector that can redistribute
data.
Skip this step if the firewall receives but does not redistribute data.
You can redistribute informaon among virtual systems on different firewalls or on the
same firewall. In both cases, each virtual system counts as one hop in the redistribuon
sequence.
1. Select Device > Data Redistribuon > Collector Sengs.

2. Edit the Data Redistribuon Agent Setup.
3. Enter a Collector Name and Pre-Shared Key to idenfy this firewall or virtual system as a
User-ID agent.
User-ID
STEP 5 | (Oponal but recommended) Configure which networks you want to include in data
redistribuon and which networks you want to exclude from data redistribuon.
You can include or exclude networks and subnetworks when redistribung either IP address-
to-tag mappings or IP address-to-username mappings.
As a best pracce, always specify which networks to include and exclude to ensure that
the agent is only communicang with internal resources.
1. Select Device > Data Redistribuon > Include/Exclude Networks.

2. Add an entry and enter a Name.
3. Confirm that the entry is Enabled.
4. Select whether you want to Include or Exclude the entry.
5. Enter the Network Address for the entry.
6. Click OK.
STEP 6 | Configure the service route that the firewall uses to query other firewalls for User-ID
informaon.
Skip this step if the firewall only receives user mapping informaon from Windows-based User-
ID agents or directly from the informaon sources (such as directory servers) instead of from
other firewalls.
2. (Firewalls with mulple virtual systems only) Select Global (for a firewall-wide service
route) or Virtual Systems (for a virtual system-specific service route), and then configure
the service route.
3. Click Service Route Configuraon, select Customize, and select IPv4 or IPv6 based on
your network protocols. Configure the service route for both protocols if your network
uses both.
4. Select UID Agent and then select the Source Interface and Source Address.
5. Click OK twice to save the service route.
STEP 7 | Enable the firewall to respond when other firewalls query it for data to redistribute.
Skip this step if the firewall receives but does not redistribute data.
Configure an Interface Management Profile with the User-ID service enabled and assign the
profile to a firewall interface.
User-ID
STEP 8 | (Oponal but recommended) Use a custom cerficate from your enterprise PKI to establish a
unique chain of trust from the redistribuon client to the redistribuon agent.
1. On the redistribuon client firewall, create a custom SSL cerficate profile to use for
outgoing connecons.
2. Select Device > Setup > Management > Secure Communicaon Sengs.
3. Edit the sengs.
4. Select the Customize Secure Server Communicaon opon.
5. Select the Cerficate Profile you created in Substep 1.
6. Click OK.
7. Customize Communicaon for Data Redistribuon.
9. Enter the following CLI command to confirm the cerficate profile (SSL config) uses
Custom certificates: show redistribution agent state <agent-name>
(where <agent-name> is the name of the redistribuon agent or User-ID agent.
STEP 9 | (Oponal but recommended) Use a custom cerficate from your enterprise PKI to establish a
unique chain of trust from the redistribuon agent to the redistribuon client.
1. On the redistribuon agent firewall, create a custom SSL/TLS service profile for the
firewall to use for incoming connecons.
2. Select Device > Setup > Management > Secure Communicaon Sengs.
3. Edit the sengs.
4. Select the Customize Secure Server Communicaon opon.
5. Select the SSL/TLS Service Profile you created in Step 1.
6. Click OK.
8. Enter the following CLI command to confirm the cerficate profile (SSL config) uses
Custom certificates: show redistribution service status.
User-ID
STEP 10 | Verify the agents correctly redistribute data to the clients.

1. View the agent stascs (Device > Data Redistribuon > Agents) and select Status
to view a summary of the acvity for the redistribuon agent, such as the number of
mappings that the client firewall has received.
2. Confirm that the Connected status is yes.
3. On the agent, access the CLI and enter the following CLI command to check the status of
the redistribuon: show redistribution service status.
4. On the agent, enter the following CLI command to view the redistribuon clients: show
redistribution service client all.
5. On the client, enter the following CLI command to check the status of the redistribuon:
show redistribution service client all.
6. Confirm the Source Name in the User-ID logs (Monitor > Logs > User-ID) to verify that
the firewall receives the mappings from the redistribuon agents.
7. On the client, view the IP-Tag log (Monitor > Logs > IP-Tag) to confirm that the client
firewall receives data.
8. On the client, enter the following CLI command and verify that the source the firewall
receives the mappings From is REDIST: show user ip-user-mapping all.
STEP 11 | (Oponal) To troubleshoot data redistribuon, enable the traceroute opon.

When you enable the traceroute opon, the firewall that receives the data appends its IP
address to the <route> field, which is a list of all firewall IP addresses that the data has
traversed. This opon requires that all PAN-OS devices in the redistribuon route use PAN-
OS version 10.0. If a PAN-OS device in the redistribuon route uses PAN-OS 9.1.x or earlier
versions, the traceroute informaon terminates at that device.
1. On the redistribuon agent where the source originates, enter the following CLI
command: debug user-id test cp-login traceroute yes ip-address
<ip-address> user <username> (where <ip-address> is the IP address of the IP
address-to-username mapping you want to verify and <username> is the username of
the IP address-to-username mapping you want to verify.
2. On a client of the firewall where you configured the traceroute, verify the firewall
redistributes the data by entering the following CLI command: show user ip-user-
mapping all.
The firewall displays the mestamp for the creaon of the mapping (SeqNumber) and
whether the user has GlobalProtect (GP User).
admin > show user ip-user-mapping-mp ip 192.0.2.0

User: jimdoe
From: REDIST
Timeout: 889s
Created: 11s ago
Origin: 198.51.100.0
SeqNumber: 15895329682-67831262
GP User: No
Local HIP: No
Route Node 0: 198.51.100.0 (vsys1)
User-ID
Route Node 1: 198.51.100.1 (vsys1)
Share User-ID Mappings Across Virtual Systems

To simplify User-ID™ source configuraon when you have mulple virtual systems, configure
the User-ID sources on a single virtual system to share IP address-to-username mappings and
username-to-group mappings with all other virtual systems on the firewall.
Configuring a single virtual system as a User-ID hub simplifies user mapping by eliminang the
need to configure the sources on mulple virtual systems, especially if traffic will pass through
mulple virtual systems based on the resources the user is trying to access (for example, in an
academic networking environment where a student will be accessing different departments whose
traffic is managed by different virtual systems).
To map the user or group, the firewall uses the mapping table on the local virtual system and
applies the policy for that user or group. If the firewall does not find the mapping for a user or
group on the virtual system where that user’s traffic originated, the firewall queries the hub to
fetch the IP address-to-username informaon for that user or group mapping informaon for that
group. If the firewall locates the mapping on both the User-ID hub and the local virtual system,
the firewall uses the mapping it learns locally. If the mapping on the local firewall differs from the
mapping on the virtual system hub, the firewall uses the local mapping.
Aer you configure the User-ID hub, the virtual system can use the mapping table on the User-ID
hub when it needs to idenfy a user for user-based policy enforcement or to display the username
in a log or report but the source is not available locally. When you select a hub, the firewall retains
the mappings on other virtual systems so we recommend consolidang the User-ID sources on
the hub. However, if you don’t want to share mappings from a specific source, you can configure
an individual virtual system to perform user or group mapping.
STEP 1 | Assign the virtual system as a User-ID hub.
1. Select Device > Virtual Systems and then select the virtual system where you
consolidated your User-ID sources.
2. On the Resource tab, Make this vsys a User-ID data hub and click Yes to confirm. Then
click OK.
User-ID
STEP 2 | Click Yes to confirm.
STEP 3 | Select the Mapping Type that you want to share then click OK.
• IP User Mapping—Share IP address-to-username mapping informaon with other virtual

systems.
• User Group Mapping—Share group mapping informaon with other virtual systems.
You must select at least one mapping type.
STEP 4 | Consolidate your User-ID sources and migrate them to the virtual system that you want to
use as a User-ID hub.
This consolidates the User-ID configuraon for operaonal simplicity. By configuring the hub
to monitor servers and connect to agents that were previously monitored by other virtual
systems, the hub collects the user mapping informaon instead of having each virtual system
User-ID
collect it independently. If you don’t want to share mappings from specific virtual systems,
configure those mappings on a virtual system that will not be used as the hub.
Use the same format for the Primary Username across virtual systems and firewalls.
1. Remove any sources that are unnecessary or outdated.

2. Idenfy all configuraons for your Windows-based or integrated agents and any sources
that send user mappings using the XML API and copy them to the virtual system you
want to use as a User-ID hub.
On the hub, you can configure any User-ID source that is currently configured
on a virtual system. However, IP address-and-port-to-username mapping
informaon from Terminal Server agents are not shared between the User-ID
hub and the connected virtual systems.
3. Specify the subnetworks that User-ID should include in or exclude from mapping.
4. Define the Ignore User List.
5. On all other virtual systems, remove any sources that are on the User-ID hub.
STEP 5 | Commit the changes to enable the User-ID hub and begin collecng mappings for the
consolidated sources.
STEP 6 | Confirm the User-ID hub is mapping the users and groups.
1. Use the show user ip-user-mapping all command to show the IP address-to-
username mappings and which virtual system provides the mappings.
2. Use the show user user-id-agent statistics command to show which virtual
system is serving as the User-ID hub.
3. Confirm the hub is sharing the group mappings by using the following CLI commands:
• show user group-mapping statistics
• show user group-mapping state all
• show user group list
• show user group name <group-name>
App-ID
To safely enable applicaons on your network, the Palo Alto Networks next-
generaon firewalls provide both an applicaon and web perspecve—App-ID and
URL Filtering—to protect against a full spectrum of legal, regulatory, producvity, and
resource ulizaon risks.
App-ID enables visibility into the applicaons on the network, so you can learn how
they work and understand their behavioral characteriscs and their relave risk. This
applicaon knowledge allows you to create and enforce security policy rules to enable,
inspect, and shape desired applicaons and block unwanted applicaons. When
you define policy rules to allow traffic, App-ID begins to classify traffic without any
addional configuraon.
New and modified App-IDs are released as part of Applicaons and Threat Content
Updates—follow the Best Pracces for Applicaons and Threats Content Updates to
seamlessly keep your applicaon and threat signatures up-to-date.
> App-ID Overview > Security Policy Rule Opmizaon
> Streamlined App-ID Policy Rules > App-ID Cloud Engine
> App-ID and HTTP/2 Inspecon > SaaS App-ID Policy Recommendaon
> Manage Custom or Unknown > Applicaon Level Gateways
Applicaons > Disable the SIP Applicaon-level
> Manage New and Modified App-IDs Gateway (ALG)
> Use Applicaon Objects in Policy > Use HTTP Headers to Manage SaaS
> Safely Enable Applicaons on Applicaon Access
Default Ports > Maintain Custom Timeouts for
> Applicaons with Implicit Support Legacy Applicaons
767
App-ID
App-ID Overview
App-ID, a patented traffic classificaon system only available in Palo Alto Networks firewalls,
determines what an applicaon is irrespecve of port, protocol, encrypon (SSH or SSL) or
any other evasive tacc used by the applicaon. It applies mulple classificaon mechanisms
—applicaon signatures, applicaon protocol decoding, and heuriscs—to your network traffic
stream to accurately idenfy applicaons.
Here's how App-ID idenfies applicaons traversing your network:
• Traffic is matched against policy to check whether it is allowed on the network.
• Signatures are then applied to allowed traffic to idenfy the applicaon based on unique
applicaon properes and related transacon characteriscs. The signature also determines if
the applicaon is being used on its default port or it is using a non-standard port. If the traffic is
allowed by policy, the traffic is then scanned for threats and further analyzed for idenfying the
applicaon more granularly.
• If App-ID determines that encrypon (SSL or SSH) is in use, and a Decrypon policy rule is in
place, the session is decrypted and applicaon signatures are applied again on the decrypted
flow.
• Decoders for known protocols are then used to apply addional context-based signatures to
detect other applicaons that may be tunneling inside of the protocol (for example, Yahoo!
Instant Messenger used across HTTP). Decoders validate that the traffic conforms to the
protocol specificaon and provide support for NAT traversal and opening dynamic pinholes for
applicaons such as SIP and FTP.
• For applicaons that are parcularly evasive and cannot be idenfied through advanced
signature and protocol analysis, heuriscs or behavioral analysis may be used to determine the
identy of the applicaon.
When the applicaon is idenfied, the policy check determines how to treat the applicaon, for
example—block, or allow and scan for threats, inspect for unauthorized file transfer and data
paerns, or shape using QoS.
App-ID
Streamlined App-ID Policy Rules

Safely enable a broad set of applicaons with common aributes using a single policy rule (for
example, give your users broad access to web-based applicaons or safely enable all enterprise
VoIP applicaons). Palo Alto Networks takes on the task of researching applicaons with common
aributes and delivers this through tags in dynamic content updates. This:
• Minimizes errors and saves me.
• Helps you to create policies that automacally update to handle newly released applicaons.
• Simplifies the transion toward an App-ID based rule set using Policy Opmizer.
Your firewall can then use your tag-based applicaon filter to dynamically enforce new and
updated App-IDs without requiring you to review or update policy rules whenever new
applicaons are added. If you choose to exclude applicaons from a specific tag, new content
updates honor those exclusions. You can also use your own tags to define applicaons types
based on your policy requirements.
• Create an Applicaon Filter Using Tags
• Create an Applicaon Filter Based on Custom Tags
Create an Applicaon Filter Using Tags

STEP 1 | Create an applicaon filter using one or more tags.
If you select more than one tag, applicaons must match both tags to be included in the filter.
STEP 2 | (Oponal) Exclude tags from your filter by selecng the check box in the Exclude column.
STEP 3 | Create a security policy rule and Add your new applicaon filter on the Applicaon tab.
App-ID
Create an Applicaon Filter Based on Custom Tags

STEP 1 | Create a custom tag and apply to App-IDs.
1. (Oponal) Remove tags from an applicaon.
2. Filter or search for applicaons, then select the specific applicaons to remove tags.
3. Edit Tags and select the tags to remove.
4. Click OK.
App-ID
STEP 2 | Create an applicaon filter using one or more tags.

If you select more than one tag, applicaons must match both tags to be included in the filter.
STEP 3 | Create a security policy rule and Add your new applicaon filter on the Applicaon tab.
App-ID
App-ID and HTTP/2 Inspecon

You can now safely enable applicaons running over HTTP/2, without any addional configuraon
on the firewall. As more websites connue to adopt HTTP/2, the firewall can enforce security
policy and all threat detecon and prevenon capabilies on a stream-by-stream basis. This
visibility into HTTP/2 traffic enables you to secure web servers that provide services over HTTP/2,
and allow your users to benefit from the speed and resource efficiency gains that HTTP/2
provides.
The firewall processes and inspects HTTP/2 traffic by default when SSL decrypon is enabled. For
HTTP/2 inspecon to work correctly, the firewall must be enabled to use ECDHE (ellipc curve
Diffie-Hellman) as a key exchange algorithm for SSL sessions. ECDHE is enabled by default, but
you can check to confirm that it’s enabled by selecng Objects > Decrypon > Decrypon Profile
> SSL Decrypon > SSL Protocol Sengs.
When the Decrypon logs introduced in PAN-OS 10.1 are enabled, you must enable
Tunnel Content Inspecon to obtain the App-ID for HTTP/2 traffic.
You can disable HTTP/2 inspecon for targeted traffic, or globally:
Disable HTTP/2 inspecon for targeted traffic.

You’ll need to specify for the firewall to remove any value contained in the Applicaon-Layer
Protocol Negoaon (ALPN) TLS extension. ALPN is used to secure HTTP/2 connecons—
App-ID
when there is no value specified for this TLS extension, the firewall either downgrades HTTP/2
traffic to HTTP/1.1 or classifies it as unknown TCP traffic.
1. Select Objects > Decrypon > Decrypon Profile > SSL Decrypon > SSL Forward
Proxy and then select Strip ALPN.
2. Aach the decrypon profile to a decrypon policy (Policies > Decrypon) to turn off
HTTP/2 inspecon for traffic that matches the policy.
Disable HTTP/2 inspecon globally.

Use the CLI command: set deviceconfig setting http2 enable no and Commit
your changes. The firewall will classify HTTP/2 traffic as unknown TCP traffic.
App-ID
Manage Custom or Unknown Applicaons

Palo Alto Networks provides weekly applicaon updates to idenfy new App-ID signatures.
By default, App-ID is always enabled on the firewall, and you don't need to enable a series of
signatures to idenfy well-known applicaons. Typically, the only applicaons that are classified
as unknown traffic—tcp, udp or non-syn-tcp—in the ACC and the traffic logs are commercially
available applicaons that have not yet been added to App-ID, internal or custom applicaons on
your network, or potenal threats.
On occasion, the firewall may report an applicaon as unknown for the following reasons:
• Incomplete data—A handshake took place, but no data packets were sent prior to the meout.
• Insufficient data—A handshake took place followed by one or more data packets; however, not
enough data packets were exchanged to idenfy the applicaon.
The following choices are available to handle unknown applicaons:
• Create security policies to control unknown applicaons by unknown TCP, unknown UDP or by
a combinaon of source zone, desnaon zone, and IP addresses.
• Request an App-ID from Palo Alto Networks—If you would like to inspect and control the
applicaons that traverse your network, for any unknown traffic, you can record a packet
capture. If the packet capture reveals that the applicaon is a commercial applicaon, you can
submit this packet capture to Palo Alto Networks for App-ID development. If it is an internal
applicaon, you can create a custom App-ID and/or define an applicaon override policy.
• Create a Custom Applicaon with a signature and aach it to a security policy, or create a
custom applicaon and define an applicaon override policy—A custom applicaon allows
you to customize the definion of the internal applicaon—its characteriscs, category and
sub-category, risk, port, meout—and exercise granular policy control in order to minimize the
range of unidenfied traffic on your network. Creang a custom applicaon also allows you to
correctly idenfy the applicaon in the ACC and traffic logs and is useful in auding/reporng
on the applicaons on your network. For a custom applicaon you can specify a signature and
a paern that uniquely idenfies the applicaon and aach it to a security policy that allows or
denies the applicaon.
Alternavely, if you would like the firewall to process the custom applicaon using fast path
(Layer-4 inspecon instead of using App-ID for Layer-7 inspecon), you can reference the
custom applicaon in an applicaon override policy rule. An applicaon override with a custom
applicaon will prevent the session from being processed by the App-ID engine, which is a
Layer-7 inspecon. Instead it forces the firewall to handle the session as a regular stateful
inspecon firewall at Layer-4, and thereby saves applicaon processing me.
For example, if you build a custom applicaon that triggers on a host header
www.mywebsite.com, the packets are first idenfied as web-browsing and then are matched
as your custom applicaon (whose parent applicaon is web-browsing). Because the parent
applicaon is web-browsing, the custom applicaon is inspected at Layer-7 and scanned for
content and vulnerabilies.
If you define an applicaon override, the firewall stops processing at Layer-4. The custom
applicaon name is assigned to the session to help idenfy it in the logs, and the traffic is not
scanned for threats.
App-ID
Manage New and Modified App-IDs

New and modified App-IDs are delivered to the firewall as part of Applicaons and Threats
Content Updates. While new and modified App-IDs enable the firewall to enforce your security
policy with ever-increasing precision, changes in security policy enforcement that can occur
when a content update release is installed can impact applicaon availability. For this reason,
you will need to think about how to best deploy content updates so that you can get the latest
threat prevenon as it’s made available, and adjust your security policy to best leverage new and
modified App-IDs.
The following opons enable you to assess the impact of new App-IDs on exisng policy
enforcement, disable (and enable) App-IDs, and seamlessly update policy rules to secure and
enforce newly-idenfied applicaons:
• Workflow to Best Incorporate New and Modified App-IDs
• See the New and Modified App-IDs in a Content Release
• See How New and Modified App-IDs Impact Your Security Policy
• Ensure Crical New App-IDs are Allowed
• Monitor New App-IDs
• Disable and Enable App-IDs
You can also take advantage of the Streamlined App-ID Policy Rules that use applicaon tags
provided in the content updates.
Workflow to Best Incorporate New and Modified App-IDs

Refer to this master workflow to first set up Applicaon and Threat content updates, and then
to best incorporate new and modified App-IDs into your security policy. Everything you need to
deploy content updates is referenced here.
STEP 1 | Align your business needs with an approach to deploying Applicaon and Threat content
updates.
Learn how Applicaons and Threat Content Updates work, and idenfy your organizaon as
either mission-crical or security-first. Understanding which of these is most important to your
business will help you to decide how to best deploy content updates and apply best pracces
to meet your business needs. You might find that you want to apply a mix of both approaches,
perhaps depending on firewall deployment (data center or perimeter) or office locaon (remote
or headquarters).
STEP 2 | Review and apply the Best Pracces for Applicaons and Threats Content Updates based on
your organizaon’s network security and applicaon availability requirements.
STEP 3 | Configure a security policy rule to always allow new App-IDs that might have network-wide
impact, like authencaon or soware development applicaons.
The New App-ID characterisc matches to only the App-IDs introduced in the latest content
release. When used in a security policy, this gives you a month’s me to fine tune your security
policy based on new App-IDs while ensuring constant availability for App-IDs that fall into
crical categories (Ensure Crical New App-IDs are Allowed).
App-ID
STEP 4 | Set the schedule to Deploy Applicaon and Threat Content Updates; this includes the opon
to delay new App-ID installaon unl you’ve had me to make necessary security policy
updates (using the New App-ID Threshold).
STEP 5 | Aer you’ve setup a content updates installaon schedule, you’ll want to regularly check in
and See the New and Modified App-IDs in a Content Release.
STEP 6 | You can then See How New and Modified App-IDs Impact Your Security Policy, and make
adjustments to your security policy as needed.
STEP 7 | Monitor New App-IDs to get a view into new App-ID acvity on your network, so that you’re
best equipped to make the most effecve security policy updates.
See the New and Modified App-IDs in a Content Release

For both downloaded and installed content updates, you can see a list of the new and modified
App-IDs the update includes. Full applicaon details are provided, and importantly, updates to
applicaons with network-wide impact (for example, LDAP or IKE) are prominently flagged as
a recommended for policy review. For modified App-IDs, applicaon details also describe how
coverage is either now expanded or more precise.
STEP 1 | Select Device > Dynamic Updates and select Check Now to refresh the list of available
content updates.
STEP 2 | For either a downloaded or currently installed content release, click Review Apps link in the
Acons column to view details on newly-idenfied and modified applicaons in that release:
App-ID
STEP 3 | Review the App-IDs this content release introduces or modifies since the last content
version.
New and modified App-IDs are listed separately. Full applicaon details are provided for each,
and App-IDs that Palo Alto Networks foresees as having network-wide impact are flagged as
recommended for policy review.
New App-ID details that you can use to assess possible impact to policy enforcement include:
• Depends on—Lists the applicaon signatures that this App-ID relies on to uniquely idenfy
the applicaon. If one of the applicaon signatures listed in the Depends On field is
disabled, the dependent App-ID is also disabled.
• Previously Idenfied As—Lists the App-IDs that matched to the applicaon before the new
App-ID was installed to uniquely idenfy the applicaon.
• App-ID Enabled—All App-IDs display as enabled when a content release is downloaded,
unless you choose to manually disable the App-ID signature before installing the content
update.
For modified App-IDs, details include informaon on: Expanded Coverage, Remove False
Posive, and applicaon metadata changes. The Expanded Coverage and Remove False
Posive fields both indicate how the applicaon’s coverage has changed (it’s either more
comprehensive or has been narrowed) and a clock icon indicates a metadata change, where
certain applicaon details are updated.
STEP 4 | Based on your findings, click Review Policies to see how the new and modified App-IDs
impact security policy enforcement: See How New and Modified App-IDs Impact Your
Security Policy.
App-ID
See How New and Modified App-IDs Impact Your Security Policy
Newly-categorized and modified App-IDs can change the way the firewall enforces traffic.
Perform a content update policy review to see how new and modified App-IDs impact your
security policy, and to easily make any necessary adjustments. You can perform a content update
policy review for both downloaded and installed content.
STEP 1 | Select Device > Dynamic Updates.
STEP 2 | See the New and Modified App-IDs in a Content Release to learn more about each App-ID
that a content release introduces or modifies.
STEP 3 | For a downloaded or currently installed content release, click Review Policies in the Acon
column. The Policy review based on candidate configuraon dialog allows you to filter by
Content Version and view either new or modified App-IDs introduced in a specific release
(you can also filter the policy impact of new App-IDs according to Rulebase, Virtual System,
and Applicaon).
STEP 4 | Select an App-ID from the Applicaon drop-down to view policy rules that currently enforce
the applicaon. The rules displayed are based on the App-IDs that match to the applicaon
before the new App-ID is installed (view applicaon details to see the list of applicaon
signatures that an applicaon was Previously Idenfied As before the new App-ID).
STEP 5 | Use the detail provided in the policy review to plan policy rule updates to take effect when
the App-ID is installed, or if the content release version that included the App-ID is currently
installed, the changes you make take effect immediately.
You can Add app to selected policies or Remove app from selected policies.
Ensure Crical New App-IDs are Allowed

New App-IDs can cause a change in policy enforcement for traffic that is newly-idenfied as
belonging to a certain applicaon. To migate any impact to security policy enforcement, you can
use the New App-ID characterisc in a security policy rule so that the rule always enforces the
most recently introduced App-IDs without requiring you to make configuraon changes when
new App-IDs are installed. The New App-ID characterisc always matches to only the new App-
IDs in the most recently installed content releases. When a new content release is installed, the
new App-ID characterisc automacally begins to match only to the new App-IDs in that content
release version.
You can choose to enforce all new App-IDs, or target the security policy rule to enforce certain
types of new App-IDs that might have network-wide or crical impact (for example, enforce only
authencaon or soware development applicaons). Set the security policy rule to Allow to
ensure that even if an App-ID release introduces expanded or more precise coverage for crical
applicaons, the firewall connues to allow them.
New App-IDs are released monthly, so a policy rule that allows the latest App-IDs gives you a
month’s me (or, if the firewall is not installing content updates on a schedule, unl the next me
App-ID
you manually install content) to assess how newly-categorized applicaons might impact security
policy enforcement and make any necessary adjustments.
STEP 1 | Select Objects > Applicaon Filters and Add a new applicaon filter.
STEP 2 | Define the types of new applicaons for which you want to ensure constant availability
based on subcategory or characterisc. For example, select the category “auth-service”
to ensure that any newly-installed applicaons that are known to perform or support
authencaon are allowed.
STEP 3 | Only aer narrowing the types of new applicaons that you want to allow immediately upon
installaon, select Apply to New App-IDs only.
STEP 4 | Select Policies > Security and add or edit a security policy rule that is configured to allow
matching traffic.
STEP 5 | Select Applicaon and add the new Applicaon Filter to the policy rule as match criteria.
STEP 6 | Click OK and Commit to save your changes.
STEP 7 | To connue to adjust your security policy to account for any changes to enforcement that
new App-IDs introduce:
• Monitor New App-IDs—Monitor and get reports on new App-ID acvity.
• See the New and Modified App-IDs in a Content Release—See how the newly-installed App-
IDs impact your exisng security policy rules.
Monitor New App-IDs

The New App-ID characterisc enables you to monitor new applicaons on your network, so
that you can beer assess the security policy updates you might want to make. Use the New
App-ID
App-ID characterisc on the ACC to get visibility into the new applicaons on your network, and
to generate reports that detail newly-categorized applicaon acvity. What you learn can help
you make the right decisions about how you to update your security policy to enforce the most
recently-categorized App-IDs. Whether you’re using it on the ACC or to generate reports (or to
Ensure Crical New App-IDs are Allowed), the New App-ID characterisc always matches to only
the new App-IDs in the most recently installed content releases. When a new content release is
installed, the new App-ID characterisc automacally begins to match only to the new App-IDs in
that content release version.
Generate a report with details specifically regarding new applicaons (applicaons introduced
only in the latest content release).
Use the ACC to monitor new applicaon acvity: select ACC and under Global Filters, select
Applicaon > Applicaon Characteriscs > New App-ID.
App-ID
Disable and Enable App-IDs

You can disable all App-IDs introduced in a content release if you want to immediately benefit
from the latest threat prevenon, and plan to enable the App-IDs later, and you can disable App-
IDs for specific applicaons.
Policy rules referencing App-IDs only match to and enforce traffic based on enabled App-IDs.
Certain App-IDs cannot be disabled and only allow a status of enabled. App-IDs that cannot
be disabled include applicaon signatures that are implicitly used by other App-IDs (such as
unknown-tcp). Disabling a base App-ID could cause App-IDs which depend on the base App-ID to
also be disabled. For example, disabling facebook-base will disable all other Facebook App-IDs.
Disable all App-IDs in a content release or for scheduled content updates.

While this opon allows you to be protected against threats, by giving you the opon to enable
the App-ID at a later me, Palo Alto Networks recommends that instead of disabling App-IDs
on a regular basis, you should instead configure a security policy rule to Temporarily Allow New
App-IDs. This rule will always allow the new App-IDs introduced in only the latest content
release. Because content updates that include new App-IDs are released only once a month,
this gives you me to assess the new App-IDs and adjust your security policy to cover the new
App-IDs if needed, all the while ensuring that availability for crical applicaons is not affected.
• To disable all new App-IDs introduced in a content release, select Device > Dynamic
Updates and Install an Applicaon and Threats content release. When prompted, select
Disable new apps in content update. Select the check box to disable apps and connue
installing the content update.
• On the Device > Dynamic Updates page, select Schedule. Choose to Disable new apps in
content update for downloads and installaons of content releases.
Disable App-IDs for one applicaon or mulple applicaons at a single me.

• To quickly disable a single applicaon or mulple applicaons at the same me, click
Objects > Applicaons. Select one or more applicaon check box and click Disable.
• To review details for a single applicaon, and then disable the App-ID for that applicaon,
select Objects > Applicaons and Disable App-ID. You can use this step to disable both
pending App-IDs (where the content release including the App-ID is downloaded to the
firewall but not installed) or installed App-IDs.
Enable App-IDs.
Enable App-IDs that you previously disabled by selecng Objects > Applicaons. Select one or
more applicaon check box and click Enable or open the details for a specific applicaon and
click Enable App-ID.
App-ID
Use Applicaon Objects in Policy

Use applicaon objects to define how your security policy handles applicaons.
• Create an Applicaon Group
• Create an Applicaon Filter
• Create a Custom Applicaon
• Resolve Applicaon Dependencies
Create an Applicaon Group

An applicaon group is an object that contains applicaons that you want to treat similarly in
policy. Applicaon groups are useful for enabling access to applicaons that you explicitly sancon
for use within your organizaon. Grouping sanconed applicaons simplifies administraon of
your rulebases. Instead of having to update individual policy rules when there is a change in the
applicaons you support, you can update only the affected applicaon groups.
When deciding how to group applicaons, consider how you plan to enforce access to your
sanconed applicaons and create an applicaon group that aligns with each of your policy goals.
For example, you might have some applicaons that you will only allow your IT administrators
to access, and other applicaons that you want to make available for any known user in your
organizaon. In this case, you would create separate applicaon groups for each of these policy
goals. Although you generally want to enable access to applicaons on the default port only,
you may want to group applicaons that are an excepon to this and enforce access to those
applicaons in a separate rule.
STEP 1 | Select Objects > Applicaon Groups.
STEP 2 | Add a group and give it a descripve Name.
STEP 3 | (Oponal) Select Shared to create the object in a shared locaon for access as a shared
object in Panorama or for use across all virtual systems in a mulple virtual system firewall.
STEP 4 | Add the applicaons you want in the group and then click OK.
App-ID
Create an Applicaon Filter

An applicaon filter is an object that dynamically groups applicaons based on applicaon
aributes that you define, including category, subcategory, technology, risk factor, and
characterisc. This is useful when you want to safely enable access to applicaons that you do
not explicitly sancon, but that you want users to be able to access. For example, you may want
to enable employees to choose their own office programs (such as Evernote, Google Docs, or
Microso Office 365) for business use. To safely enable these types of applicaons, you could
create an applicaon filter that matches on the Category business-systems and the Subcategory
office-programs. As new applicaons office programs emerge and new App-IDs get created,
these new applicaons will automacally match the filter you defined; you will not have to make
any addional changes to your policy rulebase to safely enable any applicaon that matches the
aributes you defined for the filter.
STEP 1 | Select Objects > Applicaon Filters.
STEP 2 | Add a filter and give it a descripve Name.
STEP 3 | (Oponal) Select Shared to create the object in a shared locaon for access as a shared
object in Panorama or for use across all virtual systems in a mulple virtual system firewall.
STEP 4 | Define the filter by selecng aribute values from the Category, Subcategory, Technology,
Risk, and Characterisc secons. As you select values, noce that the list of matching
applicaons at the boom of the dialog narrows. When you have adjusted the filter
aributes to match the types of applicaons you want to safely enable, click OK.
App-ID
Create a Custom Applicaon

To safely enable applicaons you must classify all traffic, across all ports, all the me. With App-ID,
the only applicaons that are typically classified as unknown traffic—tcp, udp or non-syn-tcp—in
the ACC and the Traffic logs are commercially available applicaons that have not yet been added
to App-ID, internal or custom applicaons on your network, or potenal threats.
If you are seeing unknown traffic for a commercial applicaon that does not
yet have an App-ID, you can submit a request for a new App-ID here: hp://
researchcenter.paloaltonetworks.com/submit-an-applicaon/.
To ensure that your internal custom applicaons do not show up as unknown traffic, create a
custom applicaon. You can then exercise granular policy control over these applicaons in order
to minimize the range of unidenfied traffic on your network, thereby reducing the aack surface.
Creang a custom applicaon also allows you to correctly idenfy the applicaon in the ACC and
Traffic logs, which enables you to audit/report on the applicaons on your network.
To create a custom applicaon, you must define the applicaon aributes: its characteriscs,
category and sub-category, risk, port, meout. In addion, you must define paerns or values that
the firewall can use to match to the traffic flows themselves (the signature). Finally, you can aach
the custom applicaon to a security policy that allows or denies the applicaon (or add it to an
applicaon group or match it to an applicaon filter). You can also create custom applicaons to
idenfy ephemeral applicaons with topical interest, such as ESPN3-Video for world cup soccer
or March Madness.
In order to collect the right data to create a custom applicaon signature, you'll need a
good understanding of packet captures and how datagrams are formed. If the signature is
created too broadly, you might inadvertently include other similar traffic; if it is defined too
narrowly, the traffic will evade detecon if it does not strictly match the paern.
Custom applicaons are stored in a separate database on the firewall and this database is
not impacted by the weekly App-ID updates.
The supported applicaon protocol decoders that enable the firewall to detect applicaons
that may be tunneling inside of the protocol include the following as of content release
version 609: FTP, HTTP, IMAP, POP3, SMB, and SMTP.
The following is a basic example of how to create a custom applicaon.

STEP 1 | Gather informaon about the applicaon that you will be able to use to write custom
signatures.
To do this, you must have an understanding of the applicaon and how you want to control
access to it. For example, you may want to limit what operaons users can perform within the
applicaon (such as uploading, downloading, or live streaming). Or you may want to allow the
applicaon, but enforce QoS policing.
• Capture applicaon packets so that you can find unique characteriscs about the
applicaon on which to base your custom applicaon signature. One way to do this is to run
a protocol analyzer, such as Wireshark, on the client system to capture the packets between
the client and the server. Perform different acons in the applicaon, such as uploading and
App-ID
downloading, so that you will be able to locate each type of session in the resulng packet
captures (PCAPs).
• Because the firewall by default takes packet captures for all unknown traffic, if the firewall is
between the client and the server you can view the packet capture for the unknown traffic
directly from the Traffic log.
• Use the packet captures to find paerns or values in the packet contexts that you can use to
create signatures that will uniquely match the applicaon traffic. For example, look for string
paerns in HTTP response or request headers, URI paths, or hostnames. For informaon on
the different string contexts you can use to create applicaon signatures and where you can
find the corresponding values in the packet, refer to Creang Custom Threat Signatures.
STEP 2 | Add the custom applicaon.

1. Select Objects > Applicaons and click Add.
2. On the Configuraon tab, enter a Name and a Descripon for the custom applicaon
that will help other administrators understand why you created the applicaon.
3. (Oponal) Select Shared to create the object in a shared locaon for access as a shared
object in Panorama or for use across all virtual systems in a mulple virtual system
firewall.
4. Define the applicaon Properes and Characteriscs.
App-ID
STEP 3 | Define details about the applicaon, such as the underlying protocol, the port number the
applicaon runs on, the meout values, and any types of scanning you want to be able to
perform on the traffic.
On the Advanced tab, define sengs that will allow the firewall to idenfy the applicaon
protocol:
• Specify the default ports or protocol that the applicaon uses.
• Specify the session meout values. If you don’t specify meout values, the default meout
values will be used.
• Indicate any type of addional scanning you plan to perform on the applicaon traffic.
For example, to create a custom TCP-based applicaon that runs over SSL, but uses port 4443
(instead of the default port for SSL, 443), you would specify the port number. By adding the
port number for a custom applicaon, you can create policy rules that use the default port
for the applicaon rather than opening up addional ports on the firewall. This improves your
security posture.
App-ID
STEP 4 | Define the criteria that the firewall will use to match the traffic to the new applicaon.
You will use the informaon you gathered from the packet captures to specify unique string
context values that the firewall can use to match paerns in the applicaon traffic.
1. On the Signatures tab, click Add and define a Signature Name and oponally a Comment
to provide informaon about how you intend to use this signature.
2. Specify the Scope of the signature: whether it matches to a full Session or a single
Transacon.
3. Specify condions to define signatures by clicking Add And Condion or Add Or
Condion.
4. Select an Operator to define the type of match condions you will use: Paern Match or
Equal To.
• If you selected Paern Match, select the Context and then use a regular expression
to define the Paern to match the selected context. Oponally, click Add to define a
qualifier/value pair. The Qualifier list is specific to the Context you chose.
• If you selected Equal To, select the Context and then use a regular expression to
define the Posion of the bytes in the packet header to use match the selected
context. Choose from first-4bytes or second-4bytes. Define the 4-byte hex value for
the Mask (for example, 0xffffff00) and Value (for example, 0xaabbccdd).
For example, if you are creang a custom applicaon for one of your internal
applicaons, you could use the ssl-rsp-cerficate Context to define a paern match
for the cerficate response message of a SSL negoaon from the server and create a
Paern to match the commonName of the server in the message as shown here:
5. Repeat steps 4.c and 4.d for each matching condion.

6. If the order in which the firewall aempts to match the signature definions is important,
make sure the Ordered Condion Match check box is selected and then order the
condions so that they are evaluated in the appropriate order. Select a condion or a
App-ID
group and click Move Up or Move Down. You cannot move condions from one group to
another.
7. Click OK to save the signature definion.
STEP 5 | Save the applicaon.

1. Click OK to save the custom applicaon definion.
2. Click Commit.
STEP 6 | Validate that traffic matches the custom applicaon as expected.

1. Select Policies > Security and Add a security policy rule to allow the new applicaon.
2. Run the applicaon from a client system that is between the firewall and the applicaon
and then check the Traffic logs (Monitor > Traffic) to make sure that you see traffic
matching the new applicaon (and that it is being handled per your policy rule).
Resolve Applicaon Dependencies

You can see applicaon dependencies when you create a new Security policy rule and when
performing Commits. When a policy does not include all applicaon dependencies, you can
directly access the associated Security policy rule to add the required applicaons.
STEP 1 | Create a security policy rule.
STEP 2 | Specify the applicaon that the rule will allow or block.
1. In the Applicaons tab, Add the Applicaon you want to safely enable. You can select
mulple applicaons or you can use applicaon groups or applicaon filters.
2. View dependencies for selected applicaons and Add To Current Rule or Add To Exisng
Rule.
3. If adding to an exisng rule, Select Rule and click OK.
App-ID
STEP 3 | Click OK and Commit your changes.

1. Review any Commit warnings in the App Dependency tab.
2. Select the Count to view the applicaon dependencies not included.

3. Select the Rule name to open the policy and add the dependencies.
Resolve any dependent applicaons or they’ll connue to generate warnings on

Commits.
App-ID
Safely Enable Applicaons on Default Ports

Applicaons running on unusual ports can indicate an aacker that is aempng to circumvent
tradional port-based protecons. Applicaon-default is a feature of Palo Alto Networks firewalls
that gives you an easy way to prevent this type of evasion and safely enable applicaons on their
most commonly-used ports. Applicaon-default is a best pracce for applicaon-based security
policies—it reduces administrave overhead, and closes security gaps that port-based policy
introduces:
Less overhead—Write simple applicaon-based security policy rules based on your business
needs, instead of researching and maintaining applicaon-to-port mappings. We’ve defined the
default ports for all applicaons with an App-ID.
Stronger security—Enabling applicaons to run only on their default ports is a security best
pracce. Applicaon-default helps you to make sure that crical applicaons are available
without compromising security if an applicaon is behaving in an unexpected way.
Addionally, the default ports an applicaon uses can somemes depend on whether the
applicaon is encrypted or cleartext. Port-based policy requires you to open all the default
ports an applicaon might use to account for encrypon. Open ports introduce security gaps
that an aacker can leverage to bypass your security policy. However, applicaon-default
differenates between encrypted and clear-text applicaon traffic. This means that it can
enforce the default port for an applicaon, regardless of whether it is encrypted or not.
For example, without applicaon-default, you would need to open ports 80 and 443 to enable
web-browsing traffic—you’d be allowing both cleartext and encrypted web-browsing traffic
on both ports. With applicaon-default turned on, the firewall strictly enforces cleartext web-
browsing traffic only on port 80 and SSL-tunneled traffic only on port 443.
To see the ports that an applicaon uses by default, you can visit Applipedia or select Objects
> Applicaons. Applicaon details include the applicaon’s standard port—the port it most
commonly uses when in cleartext. For web-browsing, SMTP, FTP, LDAP, POP3, and IMAP details
also include the applicaon’s secure port—the port the applicaon uses when encrypted.
Select Policy > Security and add or a modify a rule to enforce applicaons only on their default
port(s):
App-ID
Using applicaon-default as part of an applicaon-based security policy and with SSL

decrypon is a best pracce. Addionally, if you have exisng security policy rules that
control web-browsing traffic with the Service set to service-hp and service-hps, you
should update those rules to use applicaon-default instead.
App-ID
Applicaons with Implicit Support

When creang a policy to allow specific applicaons, you must also be sure that you are allowing
any other applicaons on which the applicaon depends. In many cases, you do not have to
explicitly allow access to the dependent applicaons for the traffic to flow because the firewall is
able to determine the dependencies and allow them implicitly. This implicit support also applies
to custom applicaons that are based on HTTP, SSL, MS-RPC, or RTSP. Applicaons for which the
firewall cannot determine dependent applicaons on me will require that you explicitly allow the
dependent applicaons when defining your policies. You can determine applicaon dependencies
from within your applicaon-based security policy workflow using one of the following:
• Policy Opmizer
• Create an Applicaon Filter Using Tags
• Create an Applicaon Filter Based on Custom Tags
• Resolve Applicaon Dependencies
Applipedia is also available if needed.
The following table lists the applicaons for which the firewall has implicit support (as of Content
Update 595).
Applicaon Implicitly Supports
360-safeguard-update hp
apple-update hp
apt-get hp
as2 hp
avg-update hp
avira-anvir-update hp, ssl
blokus rtmp
bugzilla hp
clubcooee hp
corba hp
cubby hp, ssl
dropbox ssl
App-ID
esignal hp
evernote hp, ssl
ezhelp hp
facebook hp, ssl
facebook-chat jabber
facebook-social-plugin hp
fastviewer hp, ssl
forclient-update hp
good-for-enterprise hp, ssl
google-cloud-print hp, ssl, jabber
google-desktop hp
google-talk jabber
google-update hp
gotomypc-desktop-sharing citrix-jedi
gotomypc-file-transfer citrix-jedi
gotomypc-prinng citrix-jedi
hipchat hp
iheartradio ssl, hp, rtmp
infront hp
instagram hp, ssl
issuu hp, ssl
java-update hp
jepptech-updates hp
App-ID
kerberos rpc
kik hp, ssl
lastpass hp, ssl
logmein hp, ssl
mcafee-update hp
megaupload hp
metatrader hp
mocha-rdp t_120
mount rpc
ms-frs msrpc
ms-rdp t_120
ms-scheduler msrpc
ms-service-controller msrpc
nfs rpc
oovoo hp, ssl
paloalto-updates ssl
panos-global-protect hp
panos-web-interface hp
pastebin hp
pastebin-posng hp
pinterest hp, ssl
portmapper rpc
prezi hp, ssl
App-ID
rdp2tcp t_120
renren-im jabber
roboform hp, ssl
salesforce hp
stumbleupon hp
supremo hp
symantec-av-update hp
trendmicro hp
trillian hp, ssl
twier hp
whatsapp hp, ssl
xm-radio rtsp
App-ID
Security Policy Rule Opmizaon

Policy Opmizer provides a simple workflow to migrate your legacy Security policy rulebase
to an App-ID based rulebase, which improves your security by reducing the aack surface and
gaining visibility into applicaons so you can safely enable them. Policy Opmizer idenfies
port-based rules so you can convert them to applicaon-based allow rules or add applicaons
from a port-based rule to an exisng applicaon-based rule without compromising applicaon
availability. It also idenfies over-provisioned App-ID based rules (App-ID rules configured with
unused applicaons). Policy Opmizer helps you priorize which port-based rules to migrate first,
idenfy applicaon-based rules that allow applicaons you don’t use, and analyze rule usage
characteriscs such as hit count.
Converng port-based rules to applicaon-based rules improves your security posture because
you select the applicaons you want to allow and deny all other applicaons, so you eliminate
unwanted and potenally malicious traffic from your network. Combined with restricng
applicaon traffic to its default ports (set the Service to applicaon-default), converng to
applicaon-based rules also prevents evasive applicaons from running on non-standard ports.
You can use this feature on:
• Firewalls that run PAN-OS version 9.0 and have App-ID enabled.
• Panorama running PAN-OS version 9.0. You don’t have to upgrade firewalls that Panorama
manages to use the Policy Opmizer capabilies. However, to use the Rule Usage capabilies
(Monitor Policy Rule Usage), managed firewalls must run PAN-OS 8.1 or later. If managed
firewalls connect to Log Collectors, those Log Collectors must also run PAN-OS version 9.0.
Managed PA-7000 Series firewalls that have a Log Processing Card (LPC) can also run PAN-OS
8.1 (or later).
• For Cortex Data Lake compability, Panorama running PAN-OS 10.0.3 or later with the Cloud
Services plugin 2.0 Innovaon or later installed.
PA-7000 Series Firewalls support two logging cards, the PA-7000 Series Firewall Log
Processing Card (LPC) and the high-performance PA-7000 Series Firewall Log Forwarding
Card (LFC). Unlike the LPC, the LFC does not have disks to store logs locally. Instead, the
LFC forwards all logs to one or more external logging systems, such as Panorama or a
syslog server. If you use the LFC, the applicaon usage informaon for Policy Opmizer
does not display on the firewall because traffic logs aren’t stored locally. If you use the LPC,
the traffic logs are stored locally on the firewall, so the applicaon usage informaon for
Policy Opmizer displays on the firewall.
Use this feature to:

• Migrate port-based rules to applicaon-based rules—Instead of combing through traffic
logs and manually mapping applicaons to port-based rules, use Policy Opmizer to idenfy
port-based rules and list the applicaons that matched each rule, so you can select the
applicaons you want to allow and safely enable them. Converng your legacy port-based rules
to applicaon-based allow rules supports your business applicaons and enables you to block
any applicaons associated with malicious acvity.
App-ID
• Idenfy over-provisioned applicaon-based rules—Rules that are too broad allow applicaons
you don’t use on your network, which increases the aack surface and the risk of inadvertently
allowing malicious traffic.
Remove unused applicaons from Security policy rules to reduce the aack surface and
keep the rulebase clean. Don’t allow applicaons that nobody uses on your network.
• Add App-ID Cloud Engine (ACE) applicaons to Security policy rules—If you have a SaaS
Security Inline subscripon, you can use Policy Opmizer’s New App Viewer to manage cloud-
delivered App-IDs in Security policy. The ACE documentaon describes how to use Policy
Opmizer to gain visibility into and control cloud-delivered App-IDs.
The Policy Opmizer examples in this secon do not show the New App Viewer
because they depict firewalls that do not have a SaaS Security Inline subscripon.
To migrate a configuraon from a legacy firewall to a Palo Alto Networks device, see Best
Pracces for Migrang to Applicaon-Based Policy.
You can’t sort Security policy rules in Security > Policies because sorng would change the rule
order in the rulebase. However, under Polices > Security > Policy Opmizer, Policy Opmizer
provides sorng opons that don’t affect the rule order, so you can sort rules to priorize which
rules to convert or clean up first. You can sort rules by the amount of traffic during the past 30
days, the number of applicaons seen on the rule, the number of days with no new applicaons,
and the number of applicaons allowed (for over-provisioned rules).
You can use Policy Opmizer in other ways as well, including validang pre-producon rules and
troubleshoong exisng rules. Note that Policy Opmizer honors only Log at Session End and
ignores Log at Session Start to avoid counng transient applicaons on rules.
Due to resource constraints, VM-50 Lite virtual firewalls don’t support Policy Opmizer.
• Policy Opmizer Concepts

• Migrate Port-Based to App-ID Based Security Policy Rules
• Rule Cloning Migraon Use Case: Web Browsing and SSL Traffic
• Add Applicaons to an Exisng Rule
• Idenfy Security Policy Rules with Unused Applicaons
• High Availability for Applicaon Usage Stascs
• How to Disable Policy Opmizer
Policy Opmizer Concepts

Review the following topics to learn more about this feature’s support:
• Sorng and Filtering Security Policy Rules
• Clear Applicaon Usage Data
App-ID
Sorng and Filtering Security Policy Rules

You can filter Security policy rules to see the port-based rules, which are rules with no applicaons
configured on them (Policies > Security > Policy Opmizer > No App Specified). You can also filter
to see the rules that have applicaons configured on them, but traffic only matches some of the
configured applicaons—the rule is over-provisioned and includes applicaons that aren’t seen on
the rule (Policies > Security > Policy Opmizer > Unused Apps). In addion, if you have a SaaS
Security Inline license, you can use the New App Viewer to filter rules that have seen new App-ID
Cloud Engine (ACE) applicaons (see the ACE documentaon for how to do this). You can sort the
filtered policy rules based on different types of stascs to help priorize which rules to convert
from port-based to applicaon-based rules or to clean up first.
You can’t filter or sort rules in Policies > Security because that would change the order of
the policy rules in the rulebase. Filtering and sorng Policies > Security > Policy Opmizer
> No App Specified, Policies > Security > Policy Opmizer > Unused Apps, and Policies
> Security > Policy Opmizer > New App Viewer (if you have a SaaS Inline Security
subscripon) does not change the order of the rules in the rulebase.
You can click several column headers to sort rules based on applicaon usage stascs. In
addion, you can View Policy Rule Usage to help idenfy and remove unused rules to reduce
security risks and keep your policy rule base organized. Rule usage tracking allows you to quickly
validate new rule addions and rule changes and to monitor rule usage for operaons and
troubleshoong tasks.
App-ID
• Traffic (Bytes, 30 days)—The amount of traffic seen on the rule over the last 30 days. The 30-
day window places rules that currently match the most traffic at the top of the list by default (a
longer me frame places more emphasis on older rules that would remain at the top of the list
because they have large cumulave totals even though they may no longer see much traffic).
Click to reverse the order.
• Apps Seen—Place the rules with the most or least applicaons seen at the top. The firewall
never automacally purges the applicaon data.
The firewall updates Apps Seen approximately every hour. However, if there is a large
volume of applicaon traffic or a large number of rules, it may take longer than an hour
to update. Aer you add an applicaon to a rule, wait at least an hour before running
Traffic logs to see the applicaon’s log informaon.
• Days with No New Apps—Place the rules with the most or least days since the last new
applicaon matched the rule at the top.
• (Unused Apps only) Apps Allowed—Place the rules with the most or least applicaons
configured on the rule at the top.
Applicaon usage stascs only count applicaons for rules that meet the following criteria:
App-ID
• The rule’s Acon must be Allow.

• The rule’s Log Seng must be Log at Session End (this is the default Log Seng). Rules that
Log at Session Start are ignored to prevent counng transient applicaons.
• Valid traffic must match the rule. For example, if the session ends before enough traffic passes
through the firewall to idenfy the applicaon, it is not counted. The following traffic types are
not valid and therefore don’t count for Policy Opmizer stascs:
• Insufficient-data
• Not-applicable
• Non-syn-tcp
• Incomplete
You can filter the Traffic logs (Monitor > Logs > Traffic) to see traffic idenfied as one of
these types. For example, to see all traffic idenfied as incomplete, use the filter (app eq
incomplete).
If these criteria aren’t met, the applicaon isn’t counted for stascs such as Apps Seen, doesn’t
affect stascs such as Days with No New Apps, and doesn’t appear in lists of applicaons.
The firewall doesn’t track applicaon usage stascs for the interzone-default and
intrazone-default Security policy rules.
If the UUID of a rule changes, the applicaon usage stascs for that rule reset because
the UUID change makes the firewall see the rule as a different (new) rule.
To see and sort the applicaons seen on a rule, in the rule’s row, click Compare or click the
number in Apps Seen.
App-ID
For the rules you see in Policies > Security > Policy Opmizer > No App Specified and Policies >
Security > Policy Opmizer > Unused Apps, clicking Compare or the Apps Seen number brings
up Applicaons & Usage, which gives you a view of the applicaons seen on the rule and the
ability to sort them. Applicaons & Usage is also where you Migrate Port-Based to App-ID Based
Security Policy Rules and remove unused applicaons from rules.
App-ID
You can sort the applicaons seen on the rule by all six of the Apps Seen stascs (Apps Seen is
not updated in real me and takes an hour or longer to update, depending on the volume of traffic
and number of rules).
• Applicaons—Alphabecal by applicaon name. If you configure specific ports or port ranges
for a rule’s Service (the Service cannot be any), and there are standard (applicaon default)
ports for the applicaon, and the configured ports don’t match the applicaon-default ports,
then a yellow, triangular warning icon appears next to the applicaon.
• Subcategory—Alphabecal by applicaon subcategory, derived from the applicaon content
metadata.
• Risk—According to the risk rang of the applicaon.
• First Seen—The first day the applicaon was seen on the rule. The me stamp resoluon is by
the day only (not hourly).
• Last Seen—The last day the applicaon was seen on the rule. The me stamp resoluon is by
the day only (not hourly).
• Traffic (30 days)—Traffic in bytes that matched the rule over the last 30 days is the default
sorng method.
App-ID
Set the Timeframe to display stascs for a parcular me period—Anyme, the Past 7 days, the
Past 15 days, or the Past 30 days.
Traffic (30 days) always displays only the last 30 days of traffic in bytes. Changing the
Timeframe does not change the duraon of the Traffic (30 days) bytes measurement.
Clicking the column header orders the display and clicking the same column again reverses the
order. For example, click Risk to sort applicaons from low risk to high risk. Click Risk again to sort
applicaons from high risk to low risk.
The firewall doesn’t report applicaon usage stascs in real me for Policy Opmizer, so it isn’t a
replacement for running reports.
• The firewall updates Apps Allowed, Apps Seen, and the applicaons listed in Applicaons &
Usage approximately every hour, not in real me. If there is a large amount of traffic or a large
number of rules, updates may take longer. Aer you add an applicaon to a rule, wait at least
an hour before running Traffic logs to see the applicaon’s log informaon.
The firewall updates Apps Seen approximately every hour. However, if there is a large volume
of applicaon traffic or a large number of rules, it may take longer than an hour to update. Aer
you add an applicaon to a rule, wait at least an hour before running Traffic logs to see the
applicaon’s log informaon.
• The firewall updates Days with No New Apps and also First Seen and Last Seen on
Applicaons & Usage once per day, at midnight device me.
• For rules with large numbers of applicaons seen, it may take longer to process applicaon
usage stascs.
• For Security policy rulebases with large numbers of rules that have many applicaons, it may
take longer to process applicaon usage stascs.
• For firewalls managed by Panorama, applicaon usage data is visible only for rules Panorama
pushes to the firewalls, not for rules configured locally on individual firewalls.
Clear Applicaon Usage Data

You can use a CLI command to clear applicaon usage data for an individual Security policy rule
and reset Apps Seen and other applicaon usage data.
App-ID
STEP 1 | Find the UUID of the Security policy rule whose applicaon usage data you want to clear.
There are two ways to find the UUID in the UI:
• In Policies > Security, copy the UUID from the Rule UUID column.
• In Policies > Security, select Copy UUID in the rule Name drop-down menu.
STEP 2 | Switch from the UI to the CLI.

Use the UUID you captured in the UI to clear the rule’s applicaon usage data:
admin@PA-VM>clear policy-app-usage-data ruleuuid <uuid-value>
Paste or type the rule’s UUID as the value and execute the command to clear the rule’s
applicaon usage data.
Migrate Port-Based to App-ID Based Security Policy Rules

When you transion from a legacy firewall to a Palo Alto Networks next-generaon firewall, you
inherit a large number of port-based rules that allow any applicaon on the ports, which increases
the aack surface because any applicaon can use an open port. Policy Opmizer idenfies all
applicaons seen on any legacy port-based Security policy rule and provides an easy workflow for
selecng the applicaons you want to allow on that rule. Migrate port-based rules to applicaon-
based rules to reduce the aack surface and safely enable applicaons on your network. Use
Policy Opmizer to maintain the rulebase as you add new applicaons.
Migrate a few port-based rules at a me to applicaon-based rules, in a priorized

manner. A gradual conversion is safer than migrang a large rulebase at one me and
makes it easier to ensure that the new applicaon-based rules control the necessary
applicaons. Use Policy Opmizer to priorize which rules to convert first.
To migrate a configuraon from a legacy firewall to a Palo Alto Networks device, see Best
Pracces for Migrang to Applicaon-Based Policy.
App-ID
STEP 1 | Idenfy port-based rules.

Port-based rules have no configured (allowed) applicaons. Policies > Security > Policy
Opmizer > No App Specified displays all port-based rules (Apps Allowed is any).
STEP 2 | Priorize which port-based rules to convert first.

Policies > Security > Policy Opmizer > No App Specified enables you to sort rules without
affecng their order in the rulebase and provides other informaon that helps you priorize
rules for conversion based on your business goals and risk tolerance.
• Traffic (Bytes, 30 days)—(Click to sort.) Rules that currently match the most traffic are at the
top of the list. This is the default sorng order.
• Apps Seen—(Click to sort.) A large number of legimate applicaons matching a port-based
rule may indicate you should replace it with mulple applicaon-based rules that ghtly
define the applicaons, users, and sources and desnaons. For example, if a port-based
rule controls traffic for mulple applicaons for different user groups on different sets of
devices, create separate rules that pair applicaons with their legimate users and devices
to reduce the aack surface and increase visibility. (Clicking the Apps Seen number or
Compare shows you the applicaons that have matched the rule.)
The firewall updates Apps Seen approximately every hour. However, if there is a
large volume of applicaon traffic or a large number of rules, it may take longer
than an hour to update. Aer you add an applicaon to a rule, wait at least an hour
before running Traffic logs to see the applicaon’s log informaon.
• Days with No New Apps—(Click to sort.) When the applicaons seen on a port-based
rule stabilize, you can be more confident the rule is mature, conversion won’t accidentally
exclude legimate applicaons, and no more new applicaons will match the rule. The
Created and Modified dates help you evaluate a rule’s stability because older rules that
have not been modified recently may also be more stable.
• Hit Count—Displays rules with the most matches over a selected me frame. You can
exclude rules for which you reset the hit counter and specify the exclusion me period in
days. Excluding rules with recently reset hit counters prevents misconcepons about rules
that show fewer hits than you expect because you didn’t know the counter was reset.
You can also use Hit Count to View Policy Rule Usage and help idenfy and
remove unused rules to reduce security risks and keep your rulebase organized.
STEP 3 | Review the Apps Seen on port-based rules, starng with the highest priority rules.
On No Apps Specified, click Compare or the number in Apps Seen to open Applicaons &
Usage, which lists applicaons that matched a port-based rule over a specified Timeframe,
App-ID
with each applicaon’s Risk, the date it was First Seen, the date it was Last Seen, and the
amount of traffic over the last 30 days.
You can check Applicaons seen on port-based rules over the past 7, 15, or 30 days, or
over the rule’s lifeme (Anyme). For migrang rules, Anyme provides the most complete
assessment of applicaons that matched the rule.
You can search and filter the Apps Seen, but keep in mind that it takes an hour or more to
update Apps Seen. You can also order the Apps Seen by clicking the column headers. For
example, you can click Traffic (30 days) to bring the applicaons with the most recent traffic to
the top of the list, or click Subcategory to organize the applicaons by subcategory.
The granularity of measurement for First Seen and Last Seen data is one day, so on the
day you define a rule, the dates in these two columns are the same. On the second day
the firewall sees traffic on an applicaon, you’ll see a difference in the dates.
App-ID
STEP 4 | Clone or add applicaons to the rule to specify the applicaons you want to allow on the
rule.
On Applicaons & Usage, convert a port-based rule to an applicaon-based rule in either of
two ways:
• Clone the rule—Preserves the original port-based rule and places the cloned applicaon-
based rule directly above it in the rulebase.
• Add Applicaons to the Rule—Replaces the original port-based rule with the new
applicaon-based rule and deletes the original rule.
If you have exisng applicaon-based rules and you want to migrate applicaons to
them from port-based rules, you can Add Applicaons to an Exisng Rule instead
of cloning a new rule or converng the port-based rule by adding applicaons to it.
Some applicaons appear on the network at intervals, for example, for quarterly or
yearly events. These applicaons may not display on the Applicaons & Usage screen
if the history isn’t long enough to capture their latest acvity.
When you clone a rule or add applicaons to a rule, nothing else about the original rule
changes. The original rule’s configuraon remains the same except for the applicaons
you added to the rule. For example, if the original rule’s Service allowed Any applicaon
or specified a parcular service, you need to change the Service to Applicaon-Default
to restrict the allowed applicaons to their default ports on the new rule.
Cloning is the safest way to migrate rules, especially when Applicaons & Usage shows more
than a few well-known applicaons matching the rule (Rule Cloning Migraon Use Case: Web
Browsing and SSL Traffic provides an example of this). Cloning preserves the original port-
based rule and places it below the cloned applicaon-based rule, which eliminates the risk of
losing applicaon availability because traffic that doesn’t match the cloned rule flows through
to the port-based rule. When traffic from legimate applicaons hasn’t hit the port-based rule
for a reasonable period of me, you can remove it to complete that rule’s migraon.
To clone a port-based rule:
1. In Apps Seen, click the check box next to each applicaon you want in the cloned rule. Keep
in mind that it takes an hour or more to update Apps Seen.
2. Click Create Cloned Rule. In the Create Cloned Rule dialog, Name the cloned rule
(“slack” in this example) and add other applicaons in the same container and applicaon
App-ID
dependencies, if required. For example, to clone a rule by selecng the slack-base

applicaon:
The green text is the selected applicaon to clone. The container applicaon (slack) is in
the gray row. The applicaons listed in italics are applicaons that have not been seen on
the rule but are in the same container as the selected applicaon. Individual applicaons
that have been seen on the rule are in normal font. All the applicaons are included in the
cloned rule by default (Add Container App, which adds all the applicaons in the container,
is selected by default) to help prevent the rule from breaking in the future.
3. If you want to allow all of the applicaons in the container, leave Add container app
selected. This also “future proofs” the rule because when an applicaon is added to the
container app, it’s automacally added to the rule.
If you want to constrain access to some of the individual applicaons in the container,
uncheck the box next to each individual applicaon you don’t want users to access. This
also unchecks the container app, so if you want to allow new applicaons in the container
later, you have to add those applicaons individually.
If you uncheck the container app, all the apps are unchecked and you manually select the
apps you want to include in the cloned rule.
4. If applicaon dependencies are listed in a box below the Applicaons (there are none in
this example), leave them checked. The applicaons you selected need those applicaon
dependencies to run. Common dependencies include ssl and web-browsing.
5. Click OK to add the new applicaon-based rule directly above the port-based rule in the
rulebase.
When you clone a rule and Commit the configuraon, the applicaons you select for the
cloned rule are removed from the original port-based rule’s Apps Seen list. For example,
if a port-based rule has 16 Apps Seen and you select two individual applicaons and one
dependent applicaon for the cloned rule, aer cloning, the port-based rule shows 13 Apps
Seen because the three selected applicaons have been removed from the port-based rule
(16-3 = 13). The cloned rule shows the three added applicaons in Apps on Rule.
Creang a cloned rule with a container app works a bit differently. For example, a port-
based rule has 16 Apps Seen and you select one individual applicaon and a container
app for the cloned rule. The container app has five individual applicaons and has one
dependent applicaon. Aer cloning, the cloned rule shows seven Apps on Rule—the
App-ID
individual applicaon, the five individual applicaons in the container app, and the dependent
applicaon for the container app. However, in the original port-based rule, Apps Seen shows
13 applicaons because only the individual applicaon, the container app, and the container
app’s dependent applicaon are removed from the port-based rule.
In contrast to cloning, adding applicaons to a port-based rule replaces the rule with the
resulng applicaon-based rule. Adding applicaons to a rule is simpler than cloning, but riskier
because you may inadvertently miss applicaons that should be on the rule, and the original
port-based rule is no longer in the rulebase to catch accidental omissions. However, adding
applicaons to port-based rules that apply to only a few well-known applicaons migrates the
rule quickly to an applicaon-based rule. For example, for a port-based rule that only controls
traffic to TCP port 22, the only legimate applicaon is SSH, so it’s safe to add applicaons to
the rule.
Adding applicaons using the tradional Security policy rule’s Applicaon tab does
not change Apps Seen or Apps on Rule. To preserve accurate applicaon usage
informaon, when replacing port-based rules with applicaon-based rules, add
applicaons using Add to This Rule or Match Usage (or create a cloned rule or add
applicaons to an exisng applicaon-based rule instead) in Apps Seen.
There are three ways to replace a port-based rule with an applicaon-based rule by adding
applicaons (Add to This Rule and Match Usage in Apps Seen and Add in Apps on Rule):
• Add to This Rule applicaons from Apps Seen (applicaons that matched the rule). Keep in
mind that it takes an hour or more to update Apps Seen.
1. Select applicaons from Apps Seen on the rule.
2. Click Add to This Rule. In the Add to This Rule dialog, add other applicaons in the same
container app and applicaon dependencies, if required. For example, to add slack-base
to a rule:
Similar to the Create Cloned Rule dialog, the green text in Add to This Rule is the
selected applicaon to add to the rule. The container app (slack) is in the gray row. The
applicaons listed in italics are applicaons that have not been seen on the rule but are
in the same container as the selected applicaon. Individual applicaons that have been
seen on the rule are in normal font. All the applicaons are included in the cloned rule by
App-ID
default (Add Container App, which adds all the applicaons in the container, is selected
by default) to help prevent the rule from breaking in the future.
3. If you want to allow all of the applicaons in the container, leave Add container app
selected. This also “future proofs” the rule because when an applicaon is added to the
container app, it’s automacally added to the rule.
If you want to constrain access to some of the individual applicaons in the container,
uncheck the box next to each individual applicaon you don’t want users to access.
This also unchecks the container app, so if you want to allow new applicaons in the
container later, you have to add those applicaons individually.
If you uncheck the container app, all the apps are unchecked and you manually select the
apps you want to include in the cloned rule.
4. If applicaon dependencies are listed in a box below the Applicaons (there are none in
this example), leave them checked. The applicaons you selected need those applicaon
dependencies to run.
5. Click OK to replace the port-based rule with the new applicaon-based rule.
When you Add to This Rule and Commit the configuraon, the applicaons you didn’t add
are removed from Apps Seen because the new applicaon-based rule no longer allows
them. For example, if a rule has 16 Apps Seen and you Add to This Rule three applicaons,
the resulng new rule shows only those three added applicaons in Apps Seen.
Add to This Rule with a container app works a bit differently. For example, a port-based
rule has 16 Apps Seen and you select one individual applicaon and a container app to add
to the new rule. The container app has five individual applicaons and has one dependent
applicaon. Aer adding the applicaons to the rule, the new rule shows seven Apps on
Rule—the individual applicaon, the five individual applicaons in the container app, and the
dependent applicaon for the container app. However, Apps Seen shows 13 applicaons
because the individual applicaon, the container app, and the container app’s dependent
applicaon are removed from that list.
• Add all of the Apps Seen on the rule to the rule at one me with one click (Match Usage).
Port-based rules allow any applicaon, so Apps Seen may include unneeded or
unsafe applicaons. Use Match Usage to convert a rule only when the rule has seen
a small number of well-known applicaons with legimate business purposes. A
good example is TCP port 22, which should only allow SSH traffic, so if SSH is the
only applicaon seen on a port-based rule that opens port 22, you can safely Match
Usage.
1. In Apps Seen, click Match Usage. Keep in mind that it takes an hour or more to update
Apps Seen. All the applicaons in Apps Seen are copied to Apps on Rule.
2. Click OK to create the applicaon-based rule and replace the port-based rule.
• If you know the applicaons you want on the rule, you can Add applicaons manually in
Apps on Rule. However, this method is equivalent to using the tradional Security policy
rule Applicaon tab and does not change Apps Seen or Apps on Rule. To preserve accurate
App-ID
applicaon usage informaon, convert rules using Add to This Rule, Create Cloned Rule, or
Match Usage in Apps Seen.
1. In Apps on Rule, Add (or Browse) and select applicaons to add to the rule. This is
equivalent to adding applicaons on the Applicaon tab.
2. Click OK to add the applicaons to the rule and replace the port-based rule with the new
applicaon-based rule.
Because this method is equivalent to adding applicaons using the Applicaon

tab, the dialog to add applicaon dependencies doesn’t pop up.
STEP 5 | For each applicaon-based rule, set the Service to applicaon-default.
If business needs require you to allow applicaons (for example, internal custom
applicaons) on non-standard ports between parcular clients and servers, restrict
the excepon to only the required applicaon, sources, and desnaons. Consider
rewring custom applicaons so they use the applicaon default port.
STEP 7 | Monitor the rules.

• Cloned rules—Monitor the original port-based rule to ensure the applicaon-based rule
matches the desired traffic. If applicaons you want to allow match the port-based rule,
add them to the applicaon-based rule or clone another applicaon-based rule for them.
When only applicaons that you don’t want on your network match the port-based rule for
a reasonable period of me, the cloned rule is robust (it catches all the applicaon traffic
you want to control) and you can safely remove it.
• Rules with Added Applicaons—Because you convert only port-based rules that have a few
well-known applicaons directly to applicaon-based rules, in most cases the rule is solid
from the start. Monitor the converted rule to see if the expected traffic matches the rule—
if there’s less traffic than expected, the rule may not allow all of the necessary applicaons.
If there’s more traffic than expected, the rule may allow unwanted traffic. Listen to user
feedback—if users can’t access applicaons they need for business purposes, the rule (or
another rule) may be too ght.
Rule Cloning Migraon Use Case: Web Browsing and SSL Traffic
A port-based rule that allows web access on TCP ports 80 (HTTP web-browsing) and 443 (HTTPS
SSL) provides no control over which applicaons use those open ports. There are many web
applicaons, so a general rule that allows web traffic allows thousands of applicaons, many of
which you don’t want on your network.
This use case shows how to migrate a port-based policy that allows all web applicaons to an
applicaon-based policy that allows only the applicaons you want, so you can safely enable the
applicaons you choose to allow. For rules that see a lot of applicaons, cloning the original port-
based rule is safer than adding applicaons to the rule because adding replaces the port-based
rule, so if you inadvertently forget to add a crical applicaon, you affect applicaon availability.
And if you Match Usage, which also replaces the port-based rule, you allow all of the applicaons
the rule has seen, which could be dangerous, especially with web browsing traffic.
App-ID
Cloning the rule retains the original port-based rule and places the cloned rule directly above
the port-based rule in the rulebase, so you can monitor the rules. Cloning also allows you to split
rules that see a lot of different applicaons—such as a port-based web traffic rule—into mulple
applicaon-based rules so you can treat different groups of applicaons differently. When you’re
sure you’re allowing all the applicaons you need to allow in the cloned rule (or rules), you can
remove the port-based rule.
This example clones a port-based web traffic rule to create an applicaon-based rule for web-
based file sharing traffic (a subset of the applicaon traffic seen on the port-based rule).
This example does not apply to using the New App Viewer to clone App-ID Cloud Engine
(ACE) applicaons (see the ACE documentaon for examples of how to do this); ACE
requires a SaaS Security Inline license.
STEP 1 | Navigate to Policies > Security > Policy Opmizer > No App Specified to view the port-
based rules.
STEP 2 | Click Compare for the rule you want to migrate.

In this example, the port-based rule that allows web access is named Traffic to internet.
App-ID
STEP 3 | Use the sorng opons to review and select the applicaons you want to allow from Apps
Seen.
The number of Apps Seen is updated approximately every hour, so if you don’t see as
many applicaons as you expect, check again aer about an hour. Depending on the
firewall’s load, it may take longer than one hour for these fields to update.
For example, click Subcategory to sort the applicaons, scroll to the file-sharing subcategory,
and then select the applicaons you want to allow. Alternavely, you can filter (search) for file-
sharing applicaons.
STEP 4 | Click Create Cloned Rule and Name the cloned rule (file-sharing-apps in this example).
Create Cloned Rule shows the selected applicaons shaded green, the container apps shaded
gray, individual applicaons in the container that haven’t been seen on the rule in italics, and
individual applicaons that have been seen on the rule in normal text font. Scrolling through
Applicaons shows all the container apps and their individual applicaons.
Create Cloned Rule also shows the dependent applicaons for the selected applicaons. In this
example, some of the selected applicaons require (Required By) the google-base and google-
docs-base applicaons to run.
App-ID
STEP 5 | Select the applicaons you want in the cloned rule.

For applicaons you don’t want to include, uncheck the corresponding box, which also
unchecks the container app. If you don’t include the container app, then when new apps are
added to the container, they won’t automacally be added to the rule.
If you uncheck the container app, all the individual applicaons in the container are unchecked
and you must select the apps you want to add manually.
STEP 6 | Click OK to create the cloned rule.
STEP 7 | In Policies > Security, the cloned rule (file-sharing-apps) is inserted in the rulebase above the
original port-based rule (Traffic to internet).
STEP 8 | Click the rule name to edit the cloned rule, which inherits the properes of the original port-
based rule.
STEP 9 | On the Service/URL Category tab, delete service-hp and service-hps from Service.
This changes the Service to applicaon-default, which prevents applicaons from using non-
standard ports and further reduces the aack surface.
If business needs require you to allow applicaons (for example, internal custom
applicaons) on non-standard ports between parcular clients and servers, restrict
the excepon to only the required applicaon, sources, and desnaons. Consider
rewring custom applicaons so they use the applicaon default port.
STEP 10 | On the Source, User, and Desnaon tabs, ghten the rule to apply to only the right users in
only the right locaons (zones, subnets).
For example, you may decide to limit web file sharing acvity to only the user groups that have
business reasons to share files across the web.
STEP 11 | Click OK.
STEP 13 | Repeat the process for other applicaon categories in the port-based web access rule unl
your applicaon-based rules allow only the applicaons you want to allow on your network.
When traffic you want to allow stops hing the original port-based rule for a sufficient amount
of me to be confident that the port-based rule is no longer needed, you can remove the port-
based rule from the rulebase.
App-ID
Add Applicaons to an Exisng Rule

In some cases, you may want to add applicaons learned (seen) on a port-based rule to a rule
that already exists. For example, an administrator may create a cloned applicaon-based rule
for general business web applicaons from a port-based rule that allows internet access (a
port 80/443 rule). Later, the administrator noces that the port-based internet access rule has
seen more general business applicaons and wants to add some or all of them to the cloned
applicaon-based rule (cloning another applicaon-based rule for the same type of applicaon
would create an unnecessary rule and complicate the rulebase).
This example assumes that an applicaon-based Security policy rule to control general business
traffic already exists or was cloned from a port-based internet access rule, similarly to the Rule
Cloning Migraon Use Case: Web Browsing and SSL Traffic. In that example, we cloned an
applicaon-based rule from the port-based internet access rule and changed the new rule’s
Service to applicaon-default to prevent web-based applicaons from using non-standard ports.
In addion to adding applicaons to an exisng applicaon-based rule, you can add

applicaons to an exisng port-based rule. This converts the port-based rule to an
applicaon-based rule for the applicaons you add to the rule. If you do this, go to the rule
and change the Service to applicaon-default to prevent the applicaons from using non-
standard ports (also, the Service configured on the rule may not match the applicaon).
This example does not apply to using the New App Viewer to add App-ID Cloud Engine
(ACE) applicaons to an exisng rule (see the ACE documentaon for examples of how to
do this); ACE requires a SaaS Security Inline license.
STEP 1 | You check the port-based internet access rule and discover that the rule has seen general
business applicaons and that you need to allow some of them for business purposes.
App-ID
STEP 2 | Select the general business apps you want to add to the exisng rule.
STEP 3 | Click Add to Exisng Rule and select the Name of the rule to which you want to add the
applicaons, in this example, general-business-applicaons.
STEP 4 | Click OK in Add Apps to Exisng Ruleto add the selected applicaons to the general-
business-applicaons rule.
STEP 5 | Click OK in Applicaons & Usage.
STEP 6 | The updated rule now controls the original applicaons on the rule and the applicaons you
just added.
App-ID
Idenfy Security Policy Rules with Unused Applicaons

If you have applicaon-based Security policy rules that allow a large number of applicaons, you
can remove unused applicaons (applicaons never seen on the rules) to ghten those rules so
that they only allow applicaons actually seen in traffic that matches the rule. Idenfying and
removing unused applicaons from Security policy rules is a best pracce that strengthens your
security posture by reducing the aack surface.
STEP 1 | Idenfy Security policy rules that have unused applicaons.
Policies > Security > Policy Opmizer > Unused Apps displays all applicaon-based rules that
are configured with applicaons that have not matched (been seen on) the rule. This means
that these rules allow applicaons that you may not use in your network (or that another rule
shadows the rule, so traffic that you expect to match the rule matches an earlier rule in the
rulebase).
The number of Apps Allowed and Apps Seen are updated approximately every hour,
so if you configure applicaons on a rule and don’t see as many Apps Allowed as you
expect, check again aer about an hour. Depending on the firewall’s load, it may take
longer than one hour for these fields to update.
STEP 2 | Priorize which rules with unused applicaons to modify first.

Policies > Security > Policy Opmizer > Unused Apps enables you to sort rules without
affecng their order in the rulebase and provides other informaon that helps you priorize
rules to clean up based on your business goals and risk tolerance.
• The difference between Apps Allowed (the number of applicaons on the allow list) and
Apps Seen (the number of allowed applicaons actually seen on the rule) shows how many
applicaons are configured on each rule but not actually seen on the rule, which indicates
to what extent the rule is over-provisioned. Click Apps Allowed to sort by the number of
applicaons allowed in a rule and click Apps Seen to sort by the number of applicaons
actually seen on a rule.
• Days with No New Apps (click to sort) shows you the number of days since the last me a
new applicaon hit the rule. This indicates how likely it is that the rule is mature and won’t
see any applicaons that haven’t already been seen. The longer the Days with No New
Apps, the less likely that new applicaons will hit the rule and the more likely that you know
all the applicaons the rule allows.
• Created and Modified dates also help determine whether a rule has matured enough to
understand whether applicaons not seen on the rule may be seen at a later date or if the
rule has seen all the applicaons expected to hit the rule. The longer the me since a rule
was Modified, the more likely the rule is mature. (If Created and Modified are the same, the
rule hasn’t been modified.)
• Hit Count—Displays rules with the most matches over a selected me frame. You can
exclude rules for which you reset the hit counter and specify the exclusion me period in
App-ID
days. Excluding rules with recently reset hit counters prevents misconcepons about rules
that show fewer hits than you expect because you didn’t know the counter was reset.
You can also use Hit Count to View Policy Rule Usage.
You can also click Traffic (Bytes, 30 days) to sort by the amount of traffic a rule has seen over
the last 30 days. Use this informaon to priorize which rules to modify first. For example, you
can priorize rules with the largest difference between Apps Allowed and Apps Seen and that
also have the most Days with No New Apps, because those rules have the greatest number of
unused applicaons and are the most mature.
STEP 3 | Review the Apps Seen on the rule.

On Unused Apps, click Compare or the number in the Apps Seen column to open Applicaons
& Usage, which shows the applicaons configured on the rule (Apps on Rule) and the Apps
Seen on the rule.
• The number next to Apps Seen (10 in this example) is the number of applicaons that
matched the rule. Keep in mind that it takes at least one hour for the firewall to update
Apps Seen.
• The number next to Apps on Rule (35 in this example) is how many applicaons are
configured on the rule, which is calculated by counng each applicaon in a container
app (but not the container app itself—if you configure a container app on the rule, the rule
allows the container app’s individual applicaons). Because the Applicaons list shows only
the applicaons you configure manually on the rule, when you configure a container app on
a rule, Applicaons only shows the container app, not all of the individual applicaons in the
container (unless you also manually configure the individual applicaons on the rule). For
this reason, the number of Apps on Rule may not be the same as the number of applicaons
you see in the Applicaons list.
• Click the number next to Apps on Rule to see all of the individual applicaons on the rule.
This example rule has 10 Apps Seen (applicaons that matched the rule) but allows 35 Apps
on Rule. The facebook container app is configured on the rule and the rule sees traffic from
the individual applicaons facebook-base, facebook-chat, and facebook-video (Apps Seen).
App-ID
When you click the Apps on Rule number, the Apps on Rule dialog displays the individual
applicaons allowed, but not the container app itself.
You cannot add or delete applicaons from the pop-up dialog.

Compare the Apps Seen on the rule to the Apps on Rule. If an applicaon on the rule isn’t used
(you don’t see the applicaon or you don’t see applicaons in an allowed container in Apps
Seen), consider removing the applicaon from the rule to reduce the aack surface. Take into
account periodically used applicaons, such as for quarterly or annual events, which may look
unused if you don’t examine a long enough me frame. Timeframe enables you to select the
me frame for the Apps Seen on the rule. Select Anyme to see every applicaon seen over
the life of the rule. Depending on the Created or Modified date in the No App Specified dialog
and the me between periodic events, the rule may not have been on the firewall long enough
to see all periodically used applicaons.
STEP 4 | Remove unused applicaons from the rule.

Delete (or Add) applicaons in Apps on Rule to remove (or add) applicaons manually, or
Match Usage to add the Apps Seen on the rule and delete applicaons for which no matching
traffic has been seen on the rule with one click.
To remove applicaons from the rule manually, select applicaons from Apps on Rule and
Delete them. Ensure that none of the applicaons are required for periodic events before you
remove them from the rule. (You can also add or delete applicaons on the Security policy
rule’s Applicaon tab.)
Match Usage moves the Apps Seen on the rule to Apps on Rule and removes all unused
applicaons from the rule.
You can clone rules from Policies > Security and from No App Specified to Migrate
Port-Based to App-ID Based Security Policy Rules. You can’t clone a rule starng
from Unused Apps.
App-ID
STEP 6 | Monitor updated rules and listen to user feedback to ensure that updated rules allow the
applicaons you want to allow and don’t inadvertently block periodically used applicaons.
The number of Apps Allowed and Apps Seen are updated approximately every hour.
Aer you remove all of the unused applicaons from a rule, the rule remains listed in
Policies > Security > Policy Opmzer > Unused Apps unl the firewall updates the
display. When the firewall updates the display and the number of Apps Allowed is
the same as the number of Apps Seen, the rule no longer displays in the Unused Apps
screen. However, depending on the firewall’s load, it may take longer than one hour for
these fields to update.
High Availability for Applicaon Usage Stascs

When you configure two firewalls as a High Availability (HA) pair, the applicaon usage stascs
are local to the firewall that generates the Traffic logs for the applicaon. Where you can view
applicaon usage stascs also depends in part on the HA configuraon:
• Acve/Passive—The acve device generates the applicaon usage stascs. If a passive device
has seen no user traffic, then only the acve device displays the applicaon usage stascs.
If a passive device has seen traffic, then the passive device only displays the applicaon usage
stascs from the traffic that it has seen.
On a failover, the applicaon usage stascs are based only on the Traffic logs generated on
the newly acve device (the device that was passive before the failover).
• Acve/Acve—The device that owns a session generates the Traffic logs for that session, so
the applicaon usage stascs for a session are only available on the device that owns the
session. If one acve device owns a session, the other acve device does not display that
session’s applicaon usage stascs.
How to Disable Policy Opmizer

Policy Opmizer is enabled by default. Policy Opmizer provides many capabilies that make it
easier to Migrate Port-Based to App-ID Based Security Policy Rules and to Idenfy Security Policy
Rules with Unused Applicaons and remove the unused applicaons from the rules, but if you
wish to disable the feature, you can.
STEP 1 | Navigate to Device > Setup > Management > Policy Rulebase Sengs.
App-ID
STEP 2 | Select the Policy Applicaon Usage check box to enable the feature and deselect the check
box to disable the feature.
App-ID
App-ID Cloud Engine

The App-ID Cloud Engine (ACE) is a new service that enables the firewall or Panorama to
download App-IDs from the cloud for applicaons that do not have specific predefined App-IDs
from the Palo Alto Networks content team. These are the applicaons that the firewall idenfies
as ssl, web-browsing, unknown-tcp, or unknown-udp traffic. Use ACE App-IDs in Security policy
rules to gain visibility into and control those applicaons and use Policy Opmizer to add and
manage applicaons in Security policy. You cannot use ACE App-IDs in any other types of policy
rules. ACE:
• Vastly increases the number of known App-IDs to idenfy and control applicaons. As ACE
defines new App-IDs for applicaons, they become available on the firewall.
• Speeds up the availability and delivery of new App-IDs to the firewall.
• Speeds up and can automate the addion of applicaons to Security policy through the use of
Applicaon Filters in Security policy rules.
• Dramacally increases visibility into applicaons that previously were idenfied as ssl, web-
browsing, unknown-tcp, or unknown-udp.
ACE requires a SaaS Security Inline subscripon. Each appliance that uses ACE must have
a valid device cerficate installed.
All hardware plaorms that support PAN-OS 10.1 or later support ACE and all appliances
on which you want to use ACE require PAN-OS 10.1 or later. Panorama cannot push and
commit ACE-based polices or objects to firewalls that don’t have a SaaS Security Inline
license installed or to firewalls that run an earlier version of PAN-OS than 10.1.
ACE is supported in the US, APAC, and EU GCP regions. The region is selected
automacally based on your CDL region.
Verify that the firewall uses the correct Content Cloud FQDN (Device > Setup > Content-
ID > Content Cloud Seng) for your region and change the FQDN if necessary:
• US—hawkeye.services-edge.paloaltonetworks.com
• EU—eu.hawkeye.services-edge.paloaltonetworks.com
• APAC—apac.hawkeye.services-edge.paloaltonetworks.com
ACE data, including traffic payloads, is sent to the servers in the selected region. If you
specify a Content Cloud FQDN that is outside of your region (for example, if you are in the
EU region but you specify the APAC region FQDN), you may break your country’s or your
organizaon’s privacy and legal regulaons.
Predefined content-delivered App-ID delivers new applicaons once per month and you need
to analyze the new App-IDs before you install them to understand changes that they may make
to Security policy rules. The monthly cadence and need for analysis slows down the adopon of
new App-IDs in policy. Although Palo Alto Networks will connue to provide new App-IDs via
monthly content updates that you need to review, ACE improves the adopon of new App-IDs
by providing on-demand App-IDs for applicaons inially idenfied as any of the following four
types:
App-ID
• ssl—Encrypted SSL traffic is by far the most common type of network traffic, with most experts
claiming that it exceeds 90% of total traffic. If you don’t or can’t decrypt that traffic, the firewall
oen can only idenfy it as ssl instead of as the actual underlying applicaon.
• web-browsing—The firewall can’t specifically idenfy some unencrypted web-browsing traffic
because there are so many applicaons that content-delivered App-ID can’t keep up with the
ever-increasing amount.
• unknown-tcp and unknown-udp—This traffic may be internal or custom applicaons or
unknown external applicaons. It’s important to idenfy that traffic by its specific App-ID so
that you can make intelligent access decisions and construct appropriate Security policy rules
to control and inspect the traffic.
ACE provides specific idenficaon of these applicaons, which enables you to understand them
and control them appropriately in policy.
ACE App-IDs do not idenfy other types of public applicaons and do not idenfy private
and custom applicaons. The ACE App-ID catalog does not contain predefined, content-
provided App-IDs. Content-provided App-IDs sll arrive monthly in content updates.
When the firewall encounters ssl, web-browsing, unknown-tcp, or unknown-udp traffic, the
firewall sends the payload to ACE for analysis. If there is a matching App-ID in the ACE database,
ACE returns the App-ID to the requesng firewall. If ACE has no matching App-ID for the traffic,
ACE sends the payload to the Machine Learning (ML) engine. The ML engine analyzes the payload
and develops the new App-ID in conjuncon with the human content team and drops traffic that
isn’t related to applicaons. When development finishes, the ML engine uploads new App-ID to
the ACE database, and the requesng firewall (and any other firewalls) can download the App-ID
and use it in Security policy.
Because it can take several minutes to retrieve an applicaon from ACE for which it has
an App-ID and longer if a new App-ID must be developed, cloud applicaon detecon is
not inline on the firewall. The firewall does not wait for a verdict to process the applicaon
traffic. The firewall processes the traffic as ssl, web-browsing, unknown-tcp, or unknown-
udp unl it receives an App-ID from ACE and then connues to process the traffic in that
way unl you receive the new App-ID and use it in Security policy.
If you downgrade a firewall or Panorama aer ACE has been enabled and ACE cloud App-
IDs are sll in use in Security policy rules or Applicaon Groups, the downgrade fails. The
fail reason lists the objects that you need to remove from the configuraon in order to
downgrade. Remove those objects from the configuraon and Commit the configuraon,
and then the downgrade will succeed.
• Prepare to Deploy App-ID Cloud Engine

• Enable or Disable the App-ID Cloud Engine
• App-ID Cloud Engine Processing and Usage
• New App Viewer (Policy Opmizer)
• Add Apps to an Applicaon Filter with Policy Opmizer
• Add Apps to an Applicaon Group with Policy Opmizer
• Add Apps Directly to a Rule with Policy Opmizer
App-ID
• Replace an RMA Firewall (ACE)

• Impact of License Expiraon or Disabling ACE
• Commit Failure Due to Cloud Content Rollback
• Troubleshoot App-ID Cloud Engine
Prepare to Deploy App-ID Cloud Engine

There are several onboarding tasks to do before the firewall can use the App-ID Cloud Engine
(ACE). You can deploy ACE on standalone firewalls or use Panorama to deploy ACE on managed
firewalls.
Before a firewall can use ACE to provide specific App-IDs for traffic previously idenfied as ssl,
web-browsing, unknown-tcp, and unknown-udp traffic, the PAN-OS administrator and the SaaS
Security administrator must work together to:
• Install a valid device cerficate on each appliance that will use ACE, including Panorama
appliances that manage ACE firewalls. (PAN-OS administrator.)
• Acvate SaaS Security Inline on each firewall that will use ACE. Panorama doesn’t require a
license. (SaaS Security administrator.)
• Configure a service route for communicaon between the firewall and ACE. (PAN-OS
administrator.)
• Enable ACE on Panorama appliances which manage firewalls that will use ACE. (PAN-OS
administrator.)
On firewalls, ACE is enabled by default aer acvang SaaS Security Inline.
• Create Security policy rule that allows ACE traffic. (PAN-OS administrator.)
• Configure Log Forwarding from the firewall to the Cortex Data Lake (CDL). (PAN-OS
administrator.)
At the appropriate step in the following procedure, the PAN-OS administrator should
nofy the SaaS Security administrator that the deployment is ready for SaaS Security
Inline acvaon. Aer acvang SaaS Security Inline, the SaaS Security Inline
administrator should nofy the PAN-OS administrator that the deployment is ready to
complete on the PAN-OS devices. Communicaon between the administrators is essenal
to achieving a smooth deployment.
Requirements:
• Standalone firewalls, Panorama appliances, and managed firewalls must run PAN-OS 10.1 or
later.
• All ACE firewalls must have purchased a SaaS Security Inline license. Panorama does not
require a license to manage ACE firewalls or push ACE configuraons to managed firewalls.
App-ID
• All ACE appliances must be able to connect to the US, APAC, or EU GCP region, depending on
your locaon (the region is selected automacally based on your CDL region).
Verify that the firewall uses the correct Content Cloud FQDN (Device > Setup > Content-ID >
Content Cloud Seng) for your region and change the FQDN if necessary:
• US—hawkeye.services-edge.paloaltonetworks.com
• EU—eu.hawkeye.services-edge.paloaltonetworks.com
• APAC—apac.hawkeye.services-edge.paloaltonetworks.com
ACE data, including traffic payloads, is sent to the servers in the selected region. If you specify
a Content Cloud FQDN that is outside of your region (for example, if you are in the EU region
but you specify the APAC region FQDN), you may break your country’s or your organizaon’s
privacy and legal regulaons.
The PAN-OS administrator completes the first two steps of the procedure and then hands it off
to the SaaS Security Inline administrator for acvaon (Step 3). Aer acvaon, the SaaS Security
Inline administrator hands the rest of the procedure off to the PAN-OS administrator to complete
on the PAN-OS devices.
STEP 1 | Bring the firewall and Panorama (if using) online. (PAN-OS administrator.)
STEP 2 | Install a Device Cerfcate on individual firewalls so that they can use cloud services or use
Panorama to Install the Device Cerficate for Managed Firewalls. (PAN-OS administrator.)
Hand off the next step to the SaaS Security administrator.
STEP 3 | Acvate SaaS Security Inline on every firewall that will use ACE. Acvaon enables ACE on
the firewalls. (SaaS Security administrator.)
Panorama does not require a SaaS Security Inline license to manage firewalls that
use ACE. Only managed firewalls need licenses, which you must retrieve manually as
shown in the next step.
Hand off the rest of the steps to the PAN-OS administrator.
STEP 4 | Retrieve the SaaS Security Inline license on each firewall—Panorama doesn’t need a license—
and verify that it is acvated. (PAN-OS administrator.)
The SaaS Security administrator’s acvaon sets up the licenses for the firewall, so you don’t
have to go to the Customer Support Portal or obtain Auth Codes.
1. Go to Device > Licenses > License Management and select Retrieve license keys from
license server to retrieve the license.
2. Check Device > Licenses to ensure that the SaaS Security Inline license is acve.
App-ID
STEP 5 | Configure a data services (dataplane) service route so that the firewall can communicate with
the App-ID Cloud Engine. (PAN-OS administrator.)
You can push this configuraon to managed firewalls from Panorama. Both Panorama
and the managed firewalls must run PAN-OS 10.1 or later.
By default, the firewall uses the management interface as the source interface for the data
services service route, but it is recommended that you configure a dataplane interface that has
connecvity to cloud services as the Source Interface and Source Address for data services, as
shown later in this step.
The issue on firewalls is that if an explicit proxy is configured on the management interface and
you use it for the data services service route, then the management interface can only connect
to the Knowledge Cloud Service (KCS), which manages the cloud applicaon and signatures.
When an explicit proxy is configured on the management interface, it cannot connect to the
Detecon Cloud Service (DCS), which checks the applicaon payload against exisng ACE
App-IDs and provides verdicts. KCS and DCS are services in the ACE cloud. If the management
interface has an explicit proxy configured, you can’t use it for the data services service route
for ACE because it can’t connect to all of the services. In this case, you must use a dataplane
interface on the firewall to connect to the data services.
Panorama uses the management port by default to connect to the KCS and does not
connect to the DCS.
To configure the service route on a data plane interface instead of using the default
management interface:
1. Select Device > Setup > Services then in Service Features, select Service Route
Configuraon.
2. Customize a service route.
3. Select the IPv4 protocol.
4. Click Data Services in the Service column to open the Service Route Source dialog box.
5. Select a Source Interface and Source Address (these cannot be the management
interface).
The source interface must have internet connecvity. The best pracce is to use a
dataplane interface that has connecvity to cloud services. See Configure Interfaces and
Create an Address Object for more informaon about creang source interfaces and
addresses.
6. Click OK to set the source interface and address.
7. Click OK to set the Service Route Configuraon.
8. Select Policies > Security and add a Security policy rule that allows traffic from the
source interface you specified earlier in this procedure to the FQDN addresses for the
KCS and DCS services, which are kcs.ace.tpcloud.paloaltonetworks (KCS
service for all regions) and hawkeye.services-edge.paloaltonetworks.com (US
region DCS service), eu.hawkeye.services-edge.paloaltonetworks.com (EU
App-ID
region DCS service), or apac.hawkeye.services-edge.paloaltonetworks.com

(APAC region DCS service).
Also add and allow the following two FQDNs in a new or exisng Security policy rule:
ocsp.paloaltonetworks.com and crl.paloaltonetworks.com for cerficate
verificaon.
Finally, add or modify a Security policy rule to allow ACE traffic by allowing the following
three applicaons: paloalto-ace, paloalto-ace-kcs, and paloalto-dlp-
service.
STEP 6 | Make sure that hawkeye.services-edge.paloaltonetworks.com and

kcs.ace.tpcloud.paloaltonetworks are reachable on firewalls and that
kcs.ace.tpcloud.paloaltonetworks is reachable on Panorama devices. (PAN-OS administrator.)
Run the operaonal command admin@fw1> show cloud-appid connection-to-
cloud. The output informs you whether the connecon is working and if the license is
installed.
STEP 7 | (Panorama only) Enable ACE on any Panorama appliance that manages ACE-enabled
firewalls. (PAN-OS administrator.)
ACE is disabled by default on Panorama.
If you push ACE configuraons to managed groups that do not have ACE-enabled
firewalls (some or all firewalls in the group do not have ACE enabled), the push fails.
1. Navigate to Panorama > Setup > ACE > Sengs.

2. Click edit ( ) and then de-select Disable App-ID Cloud Engine.
3. Click OK.
4. The Enable App-ID Cloud Engine dialog appears.
Click Yes to enable ACE.

5. Commit the change.
STEP 8 | Wait for the App-ID catalog to download. (PAN-OS administrator.)

There are fewer than four thousand content-provided App-IDs. Aer you download the
ACE catalog, you see many thousands more applicaons on the firewall and can confirm by
checking Objects > Applicaons or by using the operaonal CLI command show cloud-
appid cloud-app-data application all to see the new App-IDs.
App-ID
STEP 9 | (Panorama only) Push the desired configuraon to the managed firewall(s). (PAN-OS
administrator.)
STEP 10 | Configure Log Forwarding to Cortex Data Lake (CDL) and enable Log Forwarding with the
correct Log Forwarding profile in Security policy rules. (PAN-OS administrator.)
A SaaS Security Inline connecon to CDL is required for SaaS visibility and to support
SaaS App-ID Policy Recommendaon. At a minimum, you must forward Traffic logs
and URL logs to CDL for SaaS Security Inline to work properly.
Enable or Disable the App-ID Cloud Engine

The App-ID Cloud Engine (ACE) is disabled by default on Panorama and enabled by default on
firewalls when the SaaS Security Inline license is installed. You must enable ACE on Panorama
appliances that manage ACE-enabled firewalls.
To enable or disable ACE:
STEP 1 | Navigate to Device > Setup > ACE > Sengs on the firewall or Panorama > Setup > ACE >
Sengs on Panorama.
STEP 2 | Click edit ( ) and then either de-select Disable App-ID Cloud Engine to enable ACE or select
Disable App-ID Cloud Engine to disable ACE.
ACE is disabled by default.
STEP 3 | Click OK.
STEP 4 | (Only if enabling ACE) If you are enabling ACE, the Enable App-ID Cloud Engine dialog
appears.
If the firewall or Panorama-managed firewalls have the SaaS Security Inline license installed,
click Yes to enable ACE.
STEP 5 | Commit the change.
App-ID Cloud Engine Processing and Usage

When the firewall downloads App-ID Cloud Engine (ACE) App-IDs, it’s important to understand
how the firewall handles those App-IDs and how the firewall handles ACE App-IDs when there are
also predefined content-based App-IDs for the same applicaons. The Palo Alto Networks content
team develops predefined content-based App-IDs and updates them with modified and new App-
IDs through applicaon content updates (a valid support contract is required for updates).
App-ID
ACE requires a SaaS Security Inline license. Firewalls that don’t support ACE have only predefined
content-based App-IDs. The ACE App-ID catalog doesn’t contain content-based App-IDs.
You can only use ACE App-IDs in Security policy rules. You cannot use ACE App-IDs in any
other type of policy rule.
• When the firewall first connects to the App-ID cloud engine, the firewall downloads a catalog
of the available ACE App-IDs, and you can use those App-IDs in Security policy. It does not
download the full signatures. The catalog enables you to use ACE App-IDs in Security policy
even if the applicaons have never been seen on the firewall. ACE pushes catalog updates to
firewalls regularly so that firewalls have access to the latest ACE App-IDs.
If an applicaon arrives at the firewall that is idenfied as ssl, web-browsing, unknown-tcp, or
unknown udp and the firewall doesn’t have its signature, the firewall sends the payload to ACE.
If ACE has an App-ID for the traffic, ACE sends the full signatures back to the firewall. If the
traffic doesn’t match any ACE signatures, then ACE sends the payload to the Machine Learning
(ML) engine. The ML engine analyzes the payload and develops the new App-ID in conjuncon
with the human content team and drops traffic that isn’t related to applicaons. The ML engine
sends the new App-ID to ACE and requesng firewalls can download it and use it in Security
policy.
Because it can take several minutes to retrieve an applicaon from ACE for which it has
an App-ID and longer if a new App-ID must be developed, cloud applicaon detecon
is not inline on the firewall. The firewall does not wait for a verdict to process the
applicaon traffic. The firewall processes the traffic as ssl, web-browsing, unknown-tcp,
or unknown-udp unl it receives an App-ID from ACE and then connues to process
the traffic in that way unl you receive the new App-ID and use it in Security policy.
• When a firewall requests an App-ID from ACE, the firewall doesn’t hold the traffic, it connues
to process the traffic as usual unl it receives an App-ID from ACE.
• The firewall handles cloud App-IDs downloaded from ACE differently than it handles content-
delivered App-IDs. You don’t have to examine how new ACE App-IDs affect Security policy
before they are installed on the firewall because the firewall uses ACE App-IDs according to
previously exisng Security policy. Your exisng Security policy rules control the new ACE App-
IDs unl you explicitly use ACE App-IDs in Security policy. For example:
1. An applicaon is idenfied only as “ssl” and you have a Security policy rule that allows SSL
traffic, so the ssl rule allows that applicaon.
2. The firewall sees the ssl applicaon and sends the payload to ACE.
3. ACE idenfies the actual applicaon. If the applicaon exists in the ACE database, then ACE
sends that App-ID to the firewall. If it’s a new applicaon for which ACE does not have an
App-ID, then ACE forwards the payload to the ML Engine. The firewall does not receive the
App-ID unl the ML Engine and the human content team assign an App-ID and send it to
ACE.
4. The rule that allows ssl traffic sll allows the newly-idenfied applicaon, even though its
App-ID is no longer “ssl”. (However, if you use the new ACE App-ID in Security policy, that
policy controls the traffic. Similarly, traffic previously idenfied as web-browsing, unknown-
App-ID
tcp, and unknown-udp connues to obey the Security policy rules that control those types
of traffic unl you use the ACE App-IDs in Security policy.)
In contrast to ACE App-IDs, if the App-ID was a predefined, content-provided App-

ID, then the rule that allows ssl traffic would not longer match the applicaon. The
firewall would block it if no Security policy rule explicitly allows it.
The excepon to this behavior is if another Security policy rule specifies the App-ID given
to the traffic by ACE. The Security policy rule with the specific App-ID takes precedence
over the rule with the less specific ssl App-ID. If the rule that specifies the actual App-ID is
a block rule, the applicaon is blocked even though there is a rule that allows ssl traffic. The
rule with the more specific (granular) App-ID is the one the firewall acts on.
In this example, if you add the cloud App-ID for the applicaon previously idenfied
as “ssl” to an exisng or cloned rule either directly or by using an Applicaon Filter
or an Applicaon Group, that rule controls the applicaon. The “ssl” rule no longer
controls the applicaon because the applicaon is specifically idenfied in another
rule.
If you don’t explicitly add new ACE App-IDs to Security policy rules, the firewall connues
to control them with the same rules that controlled those applicaons before they had ACE
App-IDs and were idenfied as ssl, web-browsing, unknown-tcp, or unknown-udp traffic. For
example, if the firewall sees an applicaon idenfied as unknown-tcp and then receives an ACE
App-ID for the traffic, but you don’t use that ACE App-ID in a Security policy rule, then the
firewall sll controls that traffic using the rule that controls unknown-tcp traffic—if you block
unknown-tcp traffic, then the traffic is blocked, and if you allow unknown-tcp traffic, the traffic
is allowed.
• The firewall caches some informaon so that the firewall can check the cache and avoid
repeatedly sending data to the cloud and requesng verdicts. If the firewall is waing for a
verdict from ACE, the firewall doesn’t forward the same applicaon data twice.
• A parcular container app and its funconal applicaons are either all cloud-based App-IDs or
all content-based App-IDs. One App-ID delivery method defines a container app and all of its
funconal apps.
• If cloud-based, content-provided, and user-defined custom App-ID names overlap, the order of
precedence is:
1. Custom App-IDs—These App-IDs take precedence over all other App-IDs and if the firewall
aempts to download an ACE applicaon with the same App-ID, the commit fails because
two applicaons on the same firewall cannot have the same App-ID.
In this case, you can rename the custom applicaon, or if the custom applicaon is the same
applicaon as the ACE applicaon, you can delete the custom applicaon and use the ACE
applicaon.
2. Content-based, predefined App-IDs—These App-IDs take precedence over ACE cloud App-
ID definions.
3. ACE cloud App-IDs—Custom and content-based App-IDs take precedence over ACE App-ID
definions.
App-ID
• If an App-ID matches a container app, the firewall downloads the container app’s App-ID and
all of its funconal apps. For example, if the firewall retrieves the facebook container app, it
also retrieves facebook-base, facebook-chat, facebook-post, etc.
• When you take any of the following acons on an ACE App-ID, you affect how Security policy
handles that ACE App-ID because the firewall will take acon based on the specific ACE App-
ID instead of based on the applicaon’s previous ssl, web-browsing, unknown-tcp, or unknown-
udp App-ID:
• Create Applicaon Filters to automate adding ACE App-IDs to Security policy.
Use Applicaon Filters to automate adding ACE App-IDs to Security policy rules.
When a new App-ID matches an Applicaon Filter, the firewall automacally adds
it to the filter. When you use that Applicaon Filter in a Security policy rule, the rule
controls the applicaon traffic for the new App-IDs that were automacally added
to the filter. In other words, Applicaon Filters are your “Easy Buon” for securing
ACE App-IDs automacally to gain maximum applicaon visibility and control with
minimum effort.
• Add the App-IDs to Applicaon Groups.
• Use Policy Opmizer to add the App-IDs to a cloned rule or to an exisng rule, or to an
exisng Applicaon Filter or Applicaon Group. You can use Policy Opmizer to create new
Applicaon Filters and Applicaon Groups directly from within the Policy Opmizer tool.
Use Policy Opmizer’s sorng and filtering tools to priorize the rules to work on and to
assess how many ACE App-IDs match those rules.
• Add an ACE App-ID directly to a new or exisng Security policy rule.
When you add a cloud App-ID to a Security policy rule directly or by using an Applicaon Filter
or an Applicaon Group, that rule controls the applicaon. Unl you take one of these acons
to control cloud-delivered App-IDs, the firewall uses exisng ssl, web-browsing, unknown-tcp,
or unknown-udp Security policy rules to control ACE applicaons.
• When you create Applicaon Filters, exclude ssl and web-browsing from the filters. Together,
ssl and web-browsing match all browser-based cloud applicaons, so an Applicaon Filter that
includes ssl and web-browsing matches all browser-based cloud applicaons.
• Acve/Passive High Availability:
• The Acve firewall syncs the ACE catalog to the passive firewall so that they have idencal
catalogs.
• The Passive firewall does not iniate connecons to ACE unl it becomes the Acve
firewall.
• Acve/Acve High Availability: Each device fetches catalogs and signatures separately, so the
catalogs and signatures are not synced. However, commits fail if the catalog is out-of-sync
on peers and ACE App-IDs are referenced in Security policy rules. If the catalogs of peer HA
firewalls are out-of-sync, wait a few minutes for the updates to reach the devices and become
in-sync again.
App-ID
• A Panorama commit all/push failure to managed firewalls occurs if:

• Managed firewalls do not have a valid SaaS Security Inline license so they do not have the
ACE catalog. In this case, remove the ACE objects from the pushed configuraon and try
again.
• The connecon between a managed firewall and ACE goes down and the pushed
configuraon includes applicaons that are not in the ACE catalog on the firewall. In this
case, check the connecon to the ACE cloud and re-establish the connecon if necessary so
that the firewall can update its catalog.
The operaonal CLI command show cloud-appid connection-to-cloud provides
the cloud connecon status and the ACE cloud server URL.
• The ACE catalog on Panorama and the ACE catalog on managed firewalls is out-of-sync,
which results in pushed configuraons that include ACE apps that are not in the firewall’s
catalog. If the connecon between the firewall and ACE is up, the outdated catalog will
update in the next few minutes automacally and resolve the issue. (Wait five minutes and
try again.)
You can also use the CLI command debug cloud-appid cloud-manual-
pull check-cloud-app-data to update the catalog manually.
• Some Security profiles such as the File Blocking, Anvirus, WildFire, and DLP profiles can
specify applicaons as part of the profile. Only content-provided App-IDs are supported
in Security profiles. ACE App-IDs are not supported in Security profiles. ACE App-IDs are
intended for use in Security policy rules only.
• Because ACE App-IDs are supported only for Security policy, they are not supported in
Applicaon Override, Policy-Based Forwarding (PBF), QoS, or SD-WAN policy rules.
You cannot see ACE App-IDs in Applicaon Override or PBF rule configuraon.
However, ACE App-IDs are visible (able to be selected) in QoS and SD-WAN policy
rule configuraon and may be present in Applicaon Groups or Applicaon Filters
applied to a rule. If you use ACE App-IDs in these rules, the policy doesn’t control the
applicaon traffic and there is no effect on the applicaon traffic—the rules do not
apply to the ACE App-ID traffic even though ACE App-IDs were added to the rule.
New App Viewer (Policy Opmizer)

The Policy Opmizer New App Viewer shows you the Security policy rules that match
downloaded cloud App-IDs from ACE. You can use Policy Opmizer to manage the newly
idenfied applicaons and add them to cloned rules or to exisng rules. Select Policies > Security
to expose the New App Viewer in the Policy Opmizer poron of the interface and then select
New App Viewer.
The upper poron of the screen is similar to Objects > Applicaon Filters. It works in a similar
manner and filters the Security policy rules shown in the lower poron of the screen. You can
filter the rules that allow applicaons by category, subcategory, etc. The only categories and
subcategories available for filtering are the ones that match the new applicaons on the rules
listed in the lower half of the screen, so you don’t waste your me filtering for applicaons that
aren’t there.
App-ID
When you filter the rules, only the rules that include the filtered applicaons are shown in the
lower poron of the screen. Rules that have not seen the apps in the filter are removed from the
list. (You can see them all again by removing the filter.)
Click the number in the Apps Seen column to open the Applicaons & Usage dialog to change
the way the firewall handles the cloud-based applicaons in Security policy. Add ACE App-IDs
to Security policy rules using an Applicaon Filter, an Applicaon Group, Policy Opmizer, or by
directly adding an ACE App-ID to a rule. Unl you take one of these acons to control cloud-
delivered App-IDs, the firewall connues to see the traffic as ssl, web-browsing, unknown-tcp, or
unknown-udp traffic and uses exisng ssl, web-browsing, unknown-tcp, or unknown-udp Security
policy rules to control the applicaons.
Add Apps to an Applicaon Filter with Policy Opmizer

Add App-IDs from the App-ID Cloud Engine (ACE, and/or content-provided App-IDs) to new or
exisng Applicaon Filters to automate how you control cloud App-IDs in Security policy. When
new ACE App-IDs match an Applicaon Filter, the firewall adds them to the filter automacally.
When you use the Applicaon Filter in a Security policy rule, the rule automacally controls new
ACE App-IDs as they arrive at the firewall and are added to the filter.
ACE provides App-IDs for applicaons that were previously idenfied as ssl, web-browsing,
unknown-tcp, or unknown-udp.
Using Applicaon Filters is a best pracce because they:

• Improve your security posture. Applicaon Filters automate adding new ACE App-IDs to
Security policy rules that you design specifically to handle a parcular type of applicaon
traffic, instead of matching the traffic to more general ssl, web-browsing, unknown-tcp, or
unknown-udp rules.
• Save me. Firewall administrators can configure Applicaon Filters to handle different types of
traffic so that adding new ACE App-IDs to policy is automac and requires no further effort by
the administrator.
App-ID
When you create Applicaon Filters, exclude ssl and web-browsing from the filters.
Together, ssl and web-browsing match all browser-based cloud applicaons, so an
Applicaon Filter that includes ssl and web-browsing matches all browser-based cloud
applicaons.
Use Policy Opmizer to add ACE App-IDs to Applicaon Filters and to apply the filters to cloned
or exisng rules and control the ACE App-IDs in Security policy.
STEP 1 | Go to Policies > Security and then select Policy Opmizer > New App Viewer.
If the firewall has idenfied traffic with ACE App-IDs, a number displays next to New App
Viewer in the le navigaon window. The screen displays the Security policy rules that match
cloud App-IDs.
STEP 2 | Click the number in Apps Seen for a Security policy rule to see the cloud-delivered
applicaons that matched the rule in the Applicaons & Usage dialog.
STEP 3 | Select the applicaons that you want to add to an exisng or new Applicaon Filter.
You can sort and filter the applicaons in Apps Seen by subcategory, risk, amount of traffic
seen over the last 30 days, or when the applicaon was first or last seen.
STEP 4 | Select Applicaon Filter from Create Cloned Rule or Add to Exisng Rule, depending on
how you want to handle the applicaons.
The maximum number of applicaons you can clone using Create Cloned Rule is 1,000
applicaons. If there are more than 1,000 applicaons that you want to move to a
different rule, use Add to Exisng Rule instead. If you want to move the applicaons
to a new rule, simply create the rule first (Policies > Security) and then use Policy
Opmizer to add them to that rule.
App-ID
STEP 5 | Select or create the Applicaon Filter for the cloned or exisng rule. Creang an Applicaon
Filter using Policy Opmizer is the almost exactly the same as using Objects > Applicaon
Filters to create an Applicaon Filter—you use the same filtering tools and opons.
Create Cloned Rule:
1. Type the Cloned Rule Name (the name for the cloned rule, which will appear in the Security
policy rulebase immediately above the original rule).
2. Select the Policy Acon (Allow or Deny).
3. Select the Applicaon Filter Name from the menu or type the name of a new Applicaon
Filter.
4. Select whether the filter should Apply to New App-IDs only or if it should apply to all App-
IDs.
5. Use the Category, Subcategory, Risk, Tags, and Characterisc values to filter the types of
applicaons you want to add to the Applicaon Filter. The firewall automacally adds new
applicaons that meet the filter criteria to the Applicaon Filter.
6. Click OK to add the applicaons to the new or exisng Applicaon Filter. The firewall
includes the applicaons that you selected in Step 3 in the Applicaon Filter.
Add to Exisng Rule:
1. Select the Exisng Rule Name to add the selected applicaons to an exisng rule in an
Applicaon Filter.
2. Select the Applicaon Filter Name from the menu or type the name of a new Applicaon
Filter.
3. Select whether the Applicaon Filter is Shared, whether you want to Disable override of
applicaon characteriscs for the filter, and whether the filter should Apply to New App-
IDs only or if it should apply to all App-IDs.
4. Use the Category, Subcategory, Risk, Tags, and Characterisc values to filter the types of
applicaons you want to add to the Applicaon Filter. The firewall automacally adds new
applicaons that meet the filter criteria to the Applicaon Filter.
App-ID
5. Click OK to add the applicaons to the new or exisng Applicaon Filter. The firewall
includes the applicaons that you selected in Step 3 in the Applicaon Filter.
Add Apps to an Applicaon Group with Policy Opmizer

Add App-IDs from the App-ID Cloud Engine (ACE, and/or content-provided App-IDs) to new or
exisng Applicaon Groups and use the Applicaon Groups in Security policy rules to control
cloud App-IDs in Security policy.
Use Policy Opmizer to add ACE App-IDs to Applicaon Groups and to apply the groups to
cloned or exisng rules and control the ACE App-IDs in Security policy.
If the firewall or Panorama has downloaded ACE App-IDs, a number displays next to New App
downloaded cloud App-IDs.
STEP 3 | Select the applicaons that you want to add to an exisng or new Applicaon Group.
App-ID
STEP 4 | Select Applicaon Group from Create Cloned Rule or Add to Exisng Rule, depending on
how you want to handle the applicaons.
STEP 5 | Select or create the Applicaon Group for the cloned or exisng rule. Creang Applicaon
Groups using Policy Opmizer is similar to using Objects > Applicaon Groups to create an
Applicaon Group.
Create Cloned Rule:
1. Type the Cloned Rule Name (the name for the cloned rule, which will appear in the Security
policy rulebase immediately above the original rule).
2. Select the Policy Acon (Allow or Deny).
3. In Add to Applicaon Group, select the Applicaon Group to which you want to add the
applicaons that you selected in 3.
4. Select whether to Add container app (default) or only to Add specific apps seen.
When you add the container app, you also add all of the funconal apps in that container,
including funconal apps that have not yet been seen on the firewall. For example, if you
add the “facebook” container app, that also adds facebook-base, facebook-chat, facebook-
posng, etc., and also any future applicaons added to the container. The container app and
its funconal apps are subject to the Security policy rule to which you add the Applicaon
Group. Selecng the container app essenally future-proofs and automates security for the
container’s apps so that you don’t have to manually add new apps in that container to your
Security policy.
Adding only the specific apps seen means that only the applicaons that you selected are
added to the Applicaon Group. If new applicaons in the same container app arrive at the
firewall, the Applicaon Group doesn’t control them and you have to manually decide how
to handle the new apps.
5. In some cases, the applicaons that you want to place in an Applicaon Group require
(depend on) other applicaons to funcon. In those cases, the Create Cloned Rule dialog
box includes Dependent Applicaons, where you can select whether to add those
App-ID
applicaons to the cloned rule. Add the dependent applicaons to the rule to ensure that
the selected applicaons funcon properly.
6. Click OK to add the applicaons to the new or exisng Applicaon Group.

Add Apps to Exisng Rule:
1. Select the Exisng Rule Name to add the selected applicaons to an exisng rule in an
Applicaon Group.
2. Select the Applicaon Group in Add to Applicaon Group or type the name of a new
Applicaon Group.
3. As with cloning the rule, you can choose whether to Add container app or Add specific
apps seen. Adding the container app adds all the funconal apps in the container and any
future apps added to that container. Adding only the specific apps only adds the specific
selected apps.
4. As with cloning the rule, in some cases, the applicaons that you want to place in an
Applicaon Group require (depend on) other applicaons to funcon. In those cases, the
Add Apps to Exisng Rule dialog box includes Dependent Applicaons, where you can
App-ID
select whether to add those applicaons to the cloned rule. Add the dependent applicaons
to the rule to ensure that the selected applicaons funcon properly.
5. Click OK to add the applicaons to the new or exisng Applicaon Group.

Add Apps Directly to a Rule with Policy Opmizer

You can add App-ID Cloud Engine (ACE, and/or content-provided App-IDs) App-IDs directly to
a cloned or exisng rule with Policy Opmizer. However, consider using Applicaon Filters to
automate adding ACE App-IDs to Security policy as they arrive at the firewall instead of adding
them manually.
If the firewall or Panorama has downloaded ACE App-IDs, a number displays next to New App
downloaded cloud App-IDs.
STEP 3 | Select the applicaons that you want to add to an exisng or cloned Security policy rule.
App-ID
STEP 4 | Select Applicaons from Create Cloned Rule or Add to Exisng Rule, depending on how you
want to handle the applicaons.
STEP 5 | Add the selected applicaons to a cloned rule or to an exisng rule.

Create Cloned Rule:
1. Type the Name (the name for the cloned rule, which will appear in the Security policy
rulebase immediately above the original rule). The cloned rule has the same acon (allow or
deny) as the original rule.
2. Select whether to Add container app (default) or only to Add specific apps seen.
When you add the container app, you also add all of the funconal apps in that container,
including funconal apps that have not yet been seen on the firewall. For example, if you
add the “facebook” container app, that also adds facebook-base, facebook-chat, facebook-
posng, etc., and also any future applicaons added to the container. The container and its
funconal apps are subject to the Security policy rule that you are cloning. Selecng the
container app essenally future-proofs and automates security for the container’s apps so
that you don’t have to manually add new apps in that container to your Security policy.
Adding only the specific apps seen means that only the applicaons that you selected are
added to the cloned rule. If new applicaons in the same container app arrive at the firewall,
the cloned rule doesn’t control them and you have to manually decide how to handle the
new apps.
3. In some cases, the applicaons that you want to add to a rule require (depend on) other
applicaons to funcon. In those cases, the Create Cloned Rule dialog box includes
Dependent Applicaons, where you can select whether to add those applicaons to
App-ID
the cloned rule. Add the dependent applicaons to the rule to ensure that the selected
applicaons funcon properly.
4. Click OK to add the applicaons to the cloned rule.

Add Apps to Exisng Rule:
1. Select the Name of the exisng rule to which you want to add the selected applicaons.
2. As with cloning the rule to add applicaons, you can choose whether to Add container
app or Add specific apps seen. Adding the container app adds all the funconal apps in the
container and any future apps added to that container. Adding only the specific apps only
adds the specific selected apps.
3. As with cloning the rule, in some cases, the applicaons that you want to add to a rule
require (depend on) other applicaons to funcon. In those cases, the Add Apps to Exisng
Rule dialog box includes Dependent Applicaons, where you can select whether to add
App-ID
those applicaons to the cloned rule. Add the dependent applicaons to the rule to ensure
that the selected applicaons funcon properly.
4. Click OK to add the applicaons to the exisng rule.

Replace an RMA Firewall (ACE)

To restore the configuraon on a managed firewall when there is a Return Merchandise
Authorizaon (RMA), the procedure is to:
• Review Before Starng RMA Firewall Replacement.
• On Panorama, replace the serial number of the old firewall with the new firewall’s serial
number.
• In the firewall CLI, check to ensure that the firewall is online and connected to the Knowledge
service so that the firewall can download the cloud applicaon catalog:
2. In Operaonal mode, check the cloud App-ID connecon:
admin@vm1> show cloud-appid connection-to-cloud
If the firewall is connected to the cloud, the show command returns:
ACE Cloud server: kcs.ace.tpcloud.paloaltonetworks.com:443Cloud
connection: connected
Informaon about the connecon also displays. If the firewall is not connected to the cloud,
check whether DNS services are funconing and check for any other network-related
connecvity issues.
• With the firewall connected to the App-ID cloud, Restore the Firewall Configuraon aer
Replacement.
App-ID
Impact of License Expiraon or Disabling ACE

If you enable App-ID Cloud Engine (ACE) on a firewall, download ACE App-IDs to the firewall, and
then use those App-IDs in objects such as Applicaon Filters and in Security policy rules, then you
need to understand what happens if the SaaS Security Inline license expires or if you disable ACE.
Disabling ACE and the SaaS Security Inline license expiring both affect downloaded ACE App-
IDs, the catalog of ACE App-IDs, Security policy rules that control ACE App-IDs, and objects that
include ACE App-IDs. The effect is the same unless otherwise noted:
• ACE App-IDs remain on the firewall, but the firewall stops enforcing ACE App-IDs in Security
policy.
Security policy rules that control ACE App-IDs no longer control ACE App-IDs even though
they are visible in the rule. Traffic that was controlled by ssl, web-browsing, unknown-tcp, or
unknown-udp rules before ACE was enabled on the firewall is controlled by those rules again
unl you update and acvate the SaaS Security Inline license and/or re-enable ACE or change
those rules.
• Enforcement of Security policy rules based on ACE App-IDs stops within 4-6 hours of the
license expiring (based on a mer that periodically checks license status).
Enforcement of Security policy rules based on ACE App-IDs stops immediately aer you
commit the disabling ACE on the firewall.
Disabling ACE stops enforcing Security policy rules based on ACE App-IDs as soon as
you commit the change even if the SaaS Security Inline license is sll valid and acve.
• The catalog of ACE App-IDs remains on the firewall and on Panorama but the cloud engine no
longer updates the catalog.
• The connecon from the firewall to ACE no longer funcons. If you re-enable ACE or renew
the SaaS Security Inline license, it may take some me to download all of the catalog updates.
• If the SaaS Security Inline license expires, the ACE service stops working within 4-6 hours.
Panorama doesn’t require a SaaS Security Inline license, so there is no license to expire
on Panorama. However, when the license expires on managed firewalls, configuraon
pushes to those firewalls from Panorama fail if they contain ACE configuraons in
Security policy or in Applicaon Groups.
• Objects such as Applicaon Filters and Applicaon Groups are not changed, but any ACE App-
IDs that you placed in those objects are no longer enforced even though the ACE App-IDs are
sll visible.
• If you are using SaaS Policy Recommendaon, the firewall can no longer pull SaaS policy
recommendaons, so the SaaS administrator cannot push new policy recommendaons to the
firewall. Policy recommendaons that were downloaded before license expiraon remain in
the configuraon but they are not enforced (same behavior as Security policies configured with
ACE App-IDs when the license expires or ACE is disabled).
Commit Failure Due to Cloud Content Rollback

Although it is extremely unlikely, it is possible that ACE App-IDs may need to be rolled back
(reverted) because of bad metadata or issues with applicaons. If ACE must revert App-IDs and
App-ID
you used those App-IDs in a Security policy rule (directly or in an Applicaon Group), commit
acons fail unl those applicaons are removed from Security policy rules and from objects.
If it becomes necessary to roll back App-IDs, ACE reverts all of the most recently delivered cloud-
based App-IDs, signatures, metadata, categories, subcategories, and tags from the ACE catalog.
Removing the App-IDs from the catalog removes them from the firewall, which is why the commit
acon fails when the App-IDs are used in Security policy.
If you did not use the applicaons that ACE had to roll back in Security policy, there is no
impact to the configuraon and commit acons succeed.
When you aempt to commit a configuraon aer an ACE content rollback, the commit failure
message lists the applicaons that ACE reverted, as in this example Validaon Error:
To fix the issue, you must remove the listed applicaons from Security policy rules, regardless
of whether they were added directly to a rule or were added using an Applicaon Group. If the
applicaon is used in an Applicaon Group, remove it from the Applicaon Group.
In this example, content-qa-test-2 is the reverted applicaon, which is referenced in the
Applicaon Group content-qa-test-apps. Aer you remove content-qa-test-2 from the
Applicaon Group, commit acons succeed.
Troubleshoot App-ID Cloud Engine

This topic provides general troubleshoong informaon for the App-ID Cloud Engine (ACE).
• To check if an appliance has a valid SaaS Security Inline license, run the operaonal CLI
command show cloud-appid connection-to-cloud. If there is an issue, the command
returns the message:
ACE Error: License check failed. Check if SaaS license is installed
and activeCloud connection: failed
In addion, the output shows the me of the last successful connecon, for example: Last
successful gRPC connection: 2021-05-20 16:00:00 -0800 PDT
If the license is installed and the connecon to ACE is good, then the command returns the
URL for the ACE cloud server connecon and the status Cloud connection: connected,
along with connecon stascs and the status of the device cerficate, including the cerficate
validity dates.
App-ID
• Panorama commit all/push to managed firewalls fails. Check if any of the following condions
exist and repair them:
• Do managed firewalls have a valid SaaS Security Inline license? If not, then they do not
have the ACE catalog and the commit all/push operaon fails. Depending on whether you
want to managed firewalls to handle ACE App-IDs, either remove the ACE objects from
the pushed configuraon and try again or install valid SaaS Security Inline licenses on the
managed firewalls, wait for the catalog to download.
There are fewer than four thousand content-provided App-IDs. Aer you download
the ACE catalog, you see many thousands more applicaons on the firewall and
can confirm by checking Objects > Applicaons or by using the operaonal CLI
command show cloud-appid cloud-app-data application all to
see the new App-IDs.
• Has the connecon between a managed firewall and ACE has gone down? Check the
connecon to the ACE cloud and restore the connecon if necessary.
The operaonal CLI command show cloud-appid connection-to-cloud provides
the cloud connecon status and the ACE cloud server URL.
• The ACE catalog on Panorama and the ACE catalog on managed firewalls is out-of-sync,
which results in pushed configuraons that include ACE apps that are not in the firewall’s
catalog. If the connecon between the firewall and ACE is up, the outdated catalog will
update in the next few minutes automacally and resolve the issue. (Wait five minutes and
try again.)
You can also run the operaonal CLI command debug cloud-appid cloud-
manual-pull check-cloud-app-data to update the catalog manually.
• Are the firewalls all running PAN-OS 10.1 or later? (Pushing configuraons that reference
ACE applicaons and objects to firewalls running earlier versions than PAN-10 10.1 is not
allowed.)
• In an HA pair (acve/acve or acve/passive) that has an ACE configuraon, if you run the
operaonal command show session all or show session id <id>, the output for ACE
applicaons may show the global App-ID number instead of the applicaon name. The firewall
only shows the applicaon name if its data plane has the cloud applicaon data. If not, then the
firewall shows the global App-ID number for the applicaon instead.
• To reset the connecon to ACE (the gRPC connecon), run the operaonal CLI command
debug cloud-appid reset connection-to-cloud.
• View the ACE applicaons downloaded to the appliance with the operaonal CLI command
show cloud-appid cloud-app-data application. You can view all downloaded apps
or individual apps by App-ID or applicaon name.
• View pending requests for ACE App-IDs with the operaonal CLI command show cloud-
appid signature-dp pending-request. The output includes how many mes the
firewall sent the request to ACE (tries). Aer eleven tries, the send operaon mes out.
• The operaonal CLI command show cloud-appid has more useful opons:
admin@PAN-ACE-VM-1> show cloud-appid ?
App-ID
> app-objects-in-policy Show application-filter/application-

groups referred in policy
> app-to-filtergroup-mapping Show application to matched filter
and groups
> application Show Application info for UI
> application-filter Show cloud apps in application-
filters
> application-group Show cloud apps in application-
groups
> cloud-app-data Show cloud application, container
and metadata
> connection-to-cloud Show gRPC connection status to cloud
application server
> ha-info Show statistics of cloud application
high availability
> overlap-appid Show duplicated applications in
predefined content
> signature-dp Show cloud signatures and
applications used on DP
> task Show task on management-plane
> transaction Show cloud application transaction
> version Show Cloud-AppID version
• To view the global counters for ACE, run the operaonal CLI command show counter
global filter value all category cad (cad stands for “cloud app-idenficaon).
• To view stascs for bytes and packets received and sent to/from shared memory and to/from
the security client for services such as ACE, DLP, and IoT, run the operaonal command show
ctd-agent statistics.
• If you noce a discrepancy between the number of applicaons that match an Applicaon
Filter when you look in the user interface versus when you look in the CLI, it’s because of the
way the firewall counts matching applicaons in the user interfaces versus in the CLI:
• When you look at an Applicaon Filter in Objects > Applicaon Filters, the firewall displays
all of the matching applicaons in the ACE catalog, regardless of whether the firewall has
actually seen those applicaons and downloaded their App-IDs, and the number count
includes all of those applicaons.
• When you look at an Applicaon Filter in the CLI with the show cloud-appid
application-filter operaonal command, the firewall only displays the number of
matching applicaons for which the firewall has downloaded ACE App-IDs.
For this reason, the user interface may show more matching applicaons than the CLI for the
same Applicaon Filter.
The same thing applies to Applicaon Groups when you look at them in the user
interface versus the CLI.
• ACE App-IDs are supported for Security policy only. ACE App-IDs are not supported for any
other policy type.
However, when you configure QoS or SD-WAN policy, ACE App-IDs are visible (able to be
selected) and may be present in Applicaon Groups or Applicaon Filters applied to the rule,
but adding them to QoS or SD-WAN policy has no effect on the applicaon traffic. (The QoS
and SD-WAN policies don’t control the applicaon traffic.)
App-ID
SaaS App-ID Policy Recommendaon

The rapid proliferaon of SaaS applicaons makes it difficult to assign all of them specific App-
IDs, gain visibility into those applicaons, and control them. Security policy rules that allow ssl,
web-browsing, or “any” applicaon may allow unsanconed SaaS applicaons that can introduce
security risks to your network. To gain visibility into those applicaons and control them on the
firewall, SaaS Security administrators can recommend Security policy rules with specific SaaS
App-IDs provided by the App-ID Cloud Engine (ACE) to PAN-OS firewall administrators. PAN-OS
administrators can import those rules on firewall’s that have a SaaS Security Inline subscripon.
SaaS Policy Recommendaon requires a SaaS Security Inline subscripon. Each appliance
that uses the SaaS Policy Recommendaon Engine needs to generate and install a valid
device cerficate or use Panorama to generate and install a valid device cerficate.
A SaaS Security Inline connecon to Cortex Data Lake (CDL) is required for SaaS
visibility. Configure Log Forwarding to CDL and enable Log Forwarding with the correct
Log Forwarding profile in Security policy rules. At a minimum, you must forward Traffic logs
and URL logs to CDL for SaaS Security Inline to work properly.
All hardware plaorms that support PAN-OS 10.1 or later support SaaS Policy
Recommendaon and all appliances on which you want to use SaaS Policy
Recommendaon require PAN-OS 10.1 or later. Panorama cannot push and commit
SaaS Policy Recommendaons to firewalls that don’t have a SaaS Security Inline license
installed or to firewalls that run an earlier version of PAN-OS than 10.1.
• The SaaS Security Administrator’s Guide describes the SaaS Security administrator’s procedure
for creang Security policy rule recommendaons and then pushing them to the firewall.
• The PAN-OS Administrator’s Guide describes how the PAN-OS administrator imports and
manages policy recommendaons from the SaaS Security administrator.
The SaaS Security administrator creates the new rule, adds applicaons, users, and groups to the
rule, and sets the rule acon. The rule acon can be allow or block; no other acons are permied
for pushed rules. The SaaS Security administrator then pushes the rule to the appropriate
appliances and the rule appears in the firewall interface (Device > Policy Recommendaon >
SaaS).
The PAN-OS administrator evaluates the recommended rule and decides whether to implement
it on the firewall. If the PAN-OS administrator chooses to implement the rule, the administrator
imports it on the firewall and selects where to place the policy rule in the firewall rulebase. When
a PAN-OS administrator imports a policy recommendaon, the firewall creates the required HIP
profiles, tags, and Applicaon Groups automacally (the PAN-OS administrator doesn’t have to do
it manually).
If the SaaS Security administrator pushes Security profiles with the policy recommendaon
and those profiles don’t exist on the firewall, the firewall import fails. If the profiles already
exist on the firewall, the import succeeds.
If the SaaS Security administrator updates a policy rule recommendaon, the PAN-OS
administrator sees the update and imports it into the firewall. If the SaaS Security administrator
App-ID
deletes a policy rule recommendaon, the PAN-OS administrator sees the acon and deletes the
rule from the firewall Security policy rulebase.
If the SaaS Security Inline license expires, the firewall no longer pulls SaaS policy
recommendaons, so you see no new recommendaons. However, Security policy rules
that you already imported connue to work.
If you disable ACE, the firewall no longer receives new cloud applicaon signatures and
App-IDs and the firewall cannot import SaaS policy recommendaons based on new ACE
App-IDs.
The ACE deployment process (connecng to the cloud, installing device cerficates, acvang
the license on the SaaS Security Portal and pushing it to Panorama and firewalls, etc.) also sets up
SaaS Policy Recommendaon.
Update all appliances to the latest Threat content updates.
User interface addions for this new feature include:

• Device > Policy Recommendaon > SaaS displays policy recommendaons from SaaS
administrators and enables firewall administrators to import, update, remove, and control
recommended SaaS policies. The page display includes Applicaon Groups configured by the
SaaS administrator for the policy.
• Role-based interface access (Device > Admin Roles) has a new opon on the Web UI tab for
SaaS policy recommendaon permissions: Device > Policy Recommendaon > SaaS.
• SaaS policy recommendaons are automacally tagged SaaSSecurityRecommended, which is
displayed in the Tags column in the interface.
You can import and update SaaS policy recommendaons pushed by SaaS administrators and
remove SaaS policy recommendaons that the SaaS administrator has deleted.
• Import SaaS Policy Recommendaon
• Import Updated SaaS Policy Recommendaon
• Remove Deleted SaaS Policy Recommendaon
Import SaaS Policy Recommendaon

When a SaaS Security administrator pushes Security policy rule recommendaons to a PAN-OS
firewall, the PAN-OS firewall administrator can import those rules on the firewall to gain visibility
into and control of the applicaons in the policy recommendaon.
See the SaaS Security Administrator’s Guide for the SaaS administrator’s policy recommendaon
and push procedures. This procedure shows PAN-OS administrators how to import policy
recommendaons.
If the SaaS Security administrator pushes Security profiles with the policy recommendaon
and those profiles don’t exist on the firewall, the firewall import fails. If the profiles already
exist on the firewall, the import succeeds.
App-ID
STEP 1 | Device > Policy Recommendaon > SaaS on the firewall and Panorama > Policy
Recommendaon > SaaS on Panorama show all of the SaaS policy recommendaons pushed
from the SaaS administrator. Push policy recommendaons from Panorama to managed
firewalls.
STEP 2 | Refresh ( ) Device > Policy Recommendaon > SaaS (or Panorama > Policy
Recommendaon > SaaS) to ensure that the SaaS policy recommendaons are up-to-date.
Any me you push policy recommendaons from Panorama to managed firewalls,
refresh ( ) the page on the firewalls to ensure that the recommendaons are up-to-
date.
Newly pushed policy recommendaons appear at the top of the screen. Acve
Recommendaons shows the value acve and New Updates Available shows the value Yes.
STEP 3 | Select a new policy recommendaon.

You import one policy recommendaon at a me. The Applicaons column shows an
Applicaon Group for each policy recommendaon. Click the name of the group to see the
applicaons in that group.
The Device column shows the source device that the SaaS administrator configured for the
rule. The term “SaaS” precedes the source device. The source device can be:
• MCD—Managed Compliant Device
• MNCD—Managed Non-compliant Device
• UMCD—Unmanaged Compliant Device
• UMNCD—Unmanaged Non-compliant Device
For example, SaaS - MCD indicates a managed, compliant source device.
STEP 4 | Import Policy Rule.

In the Import Policy Rule dialog:
• Name—Name the imported rule using a name that describes the rule’s intent.
If you specify a rule name that already exists in the Security policy rulebase, the
imported rule overwrites the exisng rule.
• Aer Rule—Select the rule aer which to place the imported SaaS rule. Think about the
firewall’s rulebase and how the new rule may affect exisng rules. If you do not select a
rule (No Rule Selecon), then the rule is placed at the top of the Security policy rulebase.
In some cases, that’s not where you want to place the rule. For example, you may want
some parcular block rules to always be at the top of the rulebase, such as blocking QUIC
App-ID
protocol. Be aware of the intent of the imported rule and be careful not to shadow exisng
rules.
The Descripon comes from the descripon entered when the SaaS administrator created the
rule. You can change it or leave it as-is.
The import process automacally creates an Applicaon Group for the applicaons
in the policy recommendaon. The name of the Applicaon Group is derived from
the Name that the SaaS Security administrator gave to the rule. The firewall also
automacally creates any HIP profiles and tags that the SaaS administrator applied to
the rule.
STEP 5 | Click OK to import the rule and add it to the Security policy rulebase in the posion selected
in Aer Rule.
STEP 6 | When you see the status message “You’ve successfully updated your Security policy rules”,
click OK.
The Locaon column now shows the rule’s locaon (vsys) on the firewall, which corresponds to
the vsys to which the SaaS administrator pushed the rule.
STEP 7 | Confirm that the imported policy rule is in the Security policy rulebase (Security > Policies) at
the specified locaon and that the firewall created the associated objects.
For example, check the Security policy rule for:
• The rule’s Source Device is populated and shows the source device for the rule on the
Source tab.
• The Applicaon Group populates the rule’s Applicaon tab.
• Associated profiles are aached to the rule (Acons tab).
Also check that:
• Objects > Applicaons Group shows the imported Applicaon Group.
• Objects > GlobalProtect > HIP Objects and Objects > GlobalProtect > HIP Profiles show
the HIP informaon pushed from the SaaS Security administrator with the rule.
Import Updated SaaS Policy Recommendaon

firewall (or Panorama), the PAN-OS administrator can import those rules to gain visibility into
and control of the applicaons in the policy recommendaon. However, if the SaaS administrator
updates the rule, for example by adding or removing applicaons, the rule also needs to be
updated on the firewall.
If the SaaS Security administrator pushes new or updated Applicaon Groups, HIP profiles,
or tags, the firewall automacally creates or updates those objects. If the SaaS Security
administrator pushes Security profiles with the policy recommendaon update and those
profiles don’t exist on the firewall, the firewall import fails. If the profiles already exist on
the firewall, the import succeeds.
App-ID
STEP 1 | Refresh ( ) Device > Policy Recommendaon > SaaS (or Panorama > Policy
Recommendaon > SaaS) to ensure that you see all of the latest SaaS policy
recommendaons that the SaaS administrator pushed to the firewall.
STEP 2 | Check New Updates Available.

If the value in the New Updates Available column is No, then there are no updates to the rule.
If the value is Yes, then the SaaS administrator has pushed an update to the rule to the firewall.
In addion, Acve Recommendaons shows the value acve.
STEP 3 | Click the Applicaon Group name in the Applicaons column to see the updated list of
applicaons that the rule controls.
STEP 4 | Select a policy recommendaon to update.

You update only one policy recommendaon at a me.
STEP 5 | Click Import Policy Rule to import the policy (if there are no updates to the rule, this opon is
grayed out and you can’t select it).
The Import Policy Rule dialog appears. The Name is already populated and cannot be changed
because the rule has already been imported. Aer Rule also cannot be changed in the dialog,
but if you want to change the rule’s locaon in the Security policy rulebase, you can do that on
Policies > Security in the same way that you change the posion of any Security policy rule.
You can change the Descripon or leave it as-is.
STEP 6 | Click OK.
STEP 7 | Click Yes in Confirm Change to import the updated rule (or click No if you don’t want to
import the changed rule).
The firewall automacally makes any changes to the Applicaon Group, HIP profiles, and tags
associated with the rule.
Remove Deleted SaaS Policy Recommendaon

appliance, the PAN-OS administrator can import those rules to gain visibility into and control
of the applicaons in the policy recommendaon. However, if the SaaS Security administrator
deletes the rule, you should also delete that rule from the PAN-OS appliance.
When a SaaS Security administrator deletes a rule, the Acve Recommendaon column shows
the value removed (for valid rules, the value is acve).
STEP 1 | Select a rule that the SaaS Security administrator removed (you can select only one rule to
remove at a me).
The Import Policy Rule opon is grayed out because the rule can no longer be
imported.
App-ID
STEP 2 | Click Remove Recommendaon Mapping.

This removes local mapping of the Security policy rule on the firewall. For example, mappings
to locaons, users, and the rule are deleted. The Remove Recommendaon Mapping dialog
box shows you the locaon of the rule so that you know from where the rule is removed.
STEP 3 | Click OK.
STEP 4 | In the Confirm Change dialog, click Yes to remove the rule from the policy recommendaon
database.
This acon only removes the rule from the policy recommendaon rule list. It does NOT
remove the rule from the Security policy rulebase. You must manually remove the rule
from the rulebase.
STEP 5 | A Status dialog appears to confirm that the policy recommendaon mapping has been
removed, but you sll need to remove the rule from the Security policy rulebase.
STEP 6 | Go to Policies > Security and delete the rule from the Security policy rulebase.
App-ID
Applicaon Level Gateways

The Palo Alto Networks firewall does not classify traffic by port and protocol; instead it idenfies
the applicaon based on its unique properes and transacon characteriscs using the App-
ID technology. Some applicaons, however, require the firewall to dynamically open pinholes
to establish the connecon, determine the parameters for the session and negoate the ports
that will be used for the transfer of data; these applicaons use the applicaon-layer payload to
communicate the dynamic TCP or UDP ports on which the applicaon opens data connecons.
For such applicaons, the firewall serves as an Applicaon Level Gateway (ALG), and it opens a
pinhole for a limited me and for exclusively transferring data or control traffic. The firewall also
performs a NAT rewrite of the payload when necessary.
• H.323 (H.225 and H.248) ALG is not supported in gatekeeper routed mode.
• When the firewall serves as an ALG for the Session Iniaon Protocol (SIP), by default
it performs NAT on the payload and opens dynamic pinholes for media ports. In some
cases, depending on the SIP applicaons in use in your environment, the SIP endpoints
have NAT intelligence embedded in their clients. In such cases, you might need to
disable the SIP ALG funconality to prevent the firewall from modifying the signaling
sessions. When SIP ALG is disabled, if App-ID determines that a session is SIP, the
payload is not translated and dynamic pinholes are not opened. See Disable the SIP
Applicaon-level Gateway (ALG).
When you use Dynamic IP and Port (DIPP) NAT, the Palo Alto Networks firewall ALG
decoder needs a combinaon of IP and Port (Sent-by Address and Sent-by Port) under SIP
headers (Contact and Via fields) to be able to translate the menoned headers and open
predict sessions based on them.
The following table lists IPv4, NAT, IPv6, NPTv6 and NAT64 ALGs and indicates with a check mark
whether the ALG supports each protocol (such as SIP).
App-ID IPv4 NAT IPv6 NPTv6 NAT64
SIP — —
SCCP — —
MGCP — — —
FTP —
RTSP —
MySQL — — —
App-ID
App-ID IPv4 NAT IPv6 NPTv6 NAT64
Oracle/ —
SQLNet/ TNS
RPC — — —
RSH — — —
UNISm — — —
H.225 — — —
H.248 — — —
App-ID
Disable the SIP Applicaon-level Gateway (ALG)

The Palo Alto Networks firewall uses the Session Iniaon Protocol (SIP) applicaon-level
gateway (ALG) to open dynamic pinholes in the firewall where NAT is enabled. However, some
applicaons—such as VoIP—have NAT intelligence embedded in the client applicaon. In these
cases, the SIP ALG on the firewall can interfere with the signaling sessions and cause the client
applicaon to stop working.
One soluon to this problem is to define an Applicaon Override Policy for SIP, but using this
approach disables the App-ID and threat detecon funconality. A beer approach is to disable
the SIP ALG, which does not disable App-ID or threat detecon.
The following procedure describes how to disable the SIP ALG.
STEP 1 | Select Objects > Applicaons.
STEP 2 | Select the sip applicaon.

You can type sip in the Search box to help find the sip applicaon.
STEP 3 | Select Customize... for ALG in the Opons secon of the Applicaon dialog box.
STEP 4 | Select the Disable ALG check box in the Applicaon - sip dialog box and click OK.
STEP 5 | Close the Applicaon dialog box and Commit the change.
App-ID
Use HTTP Headers to Manage SaaS Applicaon Access

Unsanconed usage of SaaS applicaons can be a way for your users to transmit sensive
informaon outside of your network, usually by accessing a consumer version of an applicaon.
However, if you need to allow access to the enterprise version of these applicaons for specific
individuals or organizaons, then you can't block the SaaS applicaon enrely.
You can use custom HTTP headers to disallow SaaS consumer accounts while allowing a specific
enterprise account. Many SaaS applicaons allow or disallow access to applicaons based on
informaon contained in specific HTTP headers. You can Create HTTP Header Inseron Entries
using Predefined Types to manage access to popular SaaS applicaons, such as Google G Suite
and Microso Office 365. Palo Alto Networks® uses content updates to maintain predefined rule
sets specific to these applicaons, as well as to add new predefined rule sets.
You can also Create Custom HTTP Header Inseron Entries if you want to manage access to a
SaaS applicaon—that uses HTTP headers to limit service access—for which Palo Alto Networks
has not provided a predefined set of rules.
Be aware that commercial SaaS applicaons always use SSL so decrypon is necessary to perform
HTTP header inseron. You can configure the firewall to decrypt traffic using SSL Forward Proxy
decrypon if traffic is not already decrypted by an upstream firewall.
You don't need a URL Filtering license to use this feature.
To understand how to use HTTP headers to manage SaaS applicaons, see the following:
• Understand SaaS Custom Headers
• Domains used by the Predefined SaaS Applicaon Types
• Create HTTP Header Inseron Entries using Predefined Types
• Create Custom HTTP Header Inseron Entries
Understand SaaS Custom Headers

Before you begin, make sure you understand the custom HTTP headers you will use with the
SaaS applicaon you are managing. You need to understand what you can accomplish with these
headers and the informaon you need to specify to accomplish your goals.
Be aware that SaaS applicaons that use custom headers do not always use them to control
access to types of accounts. For example, Palo Alto Networks® provides predefined support for
YouTube custom headers that determine whether network users can access restricted content.
You should also read the documentaon for the SaaS applicaon to which you want to control
access so that you understand what headers you need to use for that applicaon.
App-ID
The following limits apply to HTTP header inseron:

• Header name character length: 100.
• Header value charactor length: 512.
Be aware that some SaaS applicaons might define custom header names, or assign values
to their custom headers, that exceed these limits. These situaons should be rare, but if a
SaaS applicaon does exceed one or both of these character length limits, then your next-
generaon firewall can not successfully manage access to that SaaS applicaon.
The following table lists the headers that you can use for the SaaS applicaons for which Palo
Alto Networks provides predefined support; each header also includes a link to more informaon
specific to that header.
Applicaon Headers For More Informaon
Dropbox X-Dropbox-allowed- www.dropbox.com/help/business/network-

Team-Ids control
You can allow access to sanconed Enterprise
Dropbox accounts. This header's value is
the business account's team ID, which you
can obtain from the network control secon
of the Dropbox admin console. You must
also enable this funconality from the same
locaon.
For details on managing this header, as well
as how to enable your Dropbox clients so that
you can decrypt their traffic, contact your
Dropbox account representave.
Google G Suite X-GooGApps-Allowed- support.google.com/a/answer/1668854?

Domains hl=en
You can allow access to specific Google
accounts from your domain. The values that
you give to this header are your domain and
subdomains.
To successfully insert headers for Google
applicaons, you must also:
App-ID

1. Create an SSL decrypon profile that
includes the following categories and URLs:
• business-and-economy
• computer-and-internet-info
• content-delivery-networks
• internet-communicaons-and-telephony
• low-risk
• online-storage-and-backup
• search-engine
• web-based-email
• drive.google.com
• *.google.com
• *.googleusercontent.com
• *.gstac.com
2. HTTP header inseron is not currently
supported for HTTP/2. To insert headers,
downgrade HTTP/2 connecons to
HTTP/1.1 using the Strip ALPN feature
in the appropriate decrypon profile. For
more informaon, see App-ID and HTTP/2
Inspecon.
3. Create rules to block the Quick UDP
Internet Connecons (QUIC) App-ID and
place them at the top of your security
policy because the firewall does not
support header inseron for this protocol.
When you do, the app reverts to using
HTTP/2 over TLS, which the firewall
handles in the previous step.
Microso Office Restrict-Access-To- docs.microso.com/en-us/azure/acve-

365 Tenants directory/acve-directory-tenant-restricons
Restrict-Access- You provide Restrict-Access-To-
Context Tenants with a list of tenants you want to
allow your users to access. You can use any
domain that is registered with a tenant to
idenfy the tenant in this list.
You provide Restrict-Access-Context
with the directory ID that is seng the tenant
restricon. You can find your directory ID in
the Azure portal. Sign in as an administrator,
App-ID

select Azure Acve Directory, then select
Properes.
YouTube YouTube-Restrict support.google.com/a/answer/6214622?

hl=en
You provide this header with informaon on
the type of videos you want your users to be
able to view. You can specify either a Strict or
Moderate seng. See support.google.com/a/
answer/6212415 for details on these different
sengs.
Domains used by the Predefined SaaS Applicaon Types

SaaS applicaons use HTTPS so, to insert custom headers into this traffic, custom headers must
be decrypted. If you use the forward-proxy decrypon available on the firewall to decrypt custom
headers, you must idenfy the specific HTTPS traffic you want to decrypt by idenfying the
domains associated with the traffic. The following table idenfies the relevant domains for each of
the SaaS applicaons for which Palo Alto Networks® has provided predefined rules.
Applicaon Domains
Dropbox *.dropbox.com
G Suite *.google.com
gmail.com
Microso Office login.microsoftonline.com

365
login.microsoft.com
login.windows.net
YouTube www.youtube.com
m.youtube.com
youtubei.googleapis.com
youtube.googleapis.com
www.youtube-nocookie.com
App-ID
Create HTTP Header Inseron Entries using Predefined Types

STEP 1 | If there are no upstream devices already decrypng HTTPS traffic, configure Decrypon
using Configure SSL Forward Proxy.
If you are configuring SSL decrypon for Dropbox, then you must also configure your
Dropbox clients to allow SSL traffic. These procedures are specific and private to
Dropbox — to obtain these procedures, contact your Dropbox account representave.
1. Add a Custom URL Category for the SaaS applicaon you are managing (Objects >
Custom Objects > URL Category).
2. Specify a Name for the category.
3. Add the domains specific to the SaaS applicaon you are managing or for which you
want to insert the username and domain in the headers. See Domains used by the
Predefined SaaS Applicaon Types for a list of the domains that you use for each of
the predefined SaaS applicaons. See Insert Username in HTTP Headers for more
informaon on configuring the firewall to include the username and domain in the HTTP
headers.
Each domain name can be up to 254 characters and you can idenfy a maximum
of 50 domains for each entry. The domain list supports wildcards (for example,
*.example.com). As a best pracce, do not nest wildcards (for example, *.*.*) and do
not overlap domains within the same URL profile.
4. For SaaS applicaon management, Create a Decrypon Policy Rule and, as you follow
this procedure, configure the following:
• In the Service/URL Category tab, Add the URL Category that you created in the
previous step.
• In the Opons tab, make sure the Acon is set to Decrypt and that the Type is set to
SSL Forward Proxy.
STEP 2 | Edit or add a URL filtering profile.
STEP 3 | Select HTTP Header Inseron in the URL Filtering Profile dialog.
STEP 4 | Add an entry.

1. Specify a Name (up to 100 characters) for this entry.
2. Select a predefined Type.
This populates the Domains and Headers lists.
3. For each Header, enter a Value.
4. (Oponal) Select Log to enable logging of inseron acvity for the headers.
Allowed traffic is not logged, so header inserons are not logged for allowed traffic.
App-ID
STEP 5 | Add or edit a Security Policy rule (Policies > Security) to include the HTTP header inseron
URL filtering profile.
• For SaaS applicaon management, allow users to access the SaaS applicaon for which you
are configuring this header inseron rule.
• To include the username and domain in the HTTP headers, apply the URL filtering profile to
the security policy rule for HTTP or HTTPS traffic.
1. Choose the URL filtering profile (Acons > URL Filtering) that you edited or created in
Step 2.
2. Click OK to save and then Commit your changes.
STEP 6 | Verify that the firewall correctly inserts the header.

• For Saas applicaon management, from an endpoint, confirm that access to the SaaS
applicaon is working in the way you expect.
1. Try to access an account or content that you expect to be able to access. If you cannot
access the SaaS account or content, then the configuraon is not working.
2. Try to access an account or content that you expect will be blocked. If you can access the
SaaS account or content, then the configuraon is not working.
3. If both of the previous steps work as expected, then you can View Logs (if you configured
logging in step 4.4) and you should see the recorded HTTP header inseron acvity.
Create Custom HTTP Header Inseron Entries

STEP 1 | If there are no upstream devices already decrypng HTTPS traffic, configure Decrypon
using Configure SSL Forward ProxyDecrypon.
1. Add a Custom URL Category for the SaaS applicaon you are managing (Objects >
Custom Objects > URL Category).
2. Specify a Name for the category.
3. Add the domains specific to the SaaS applicaon you are managing.
4. Create a Decrypon Policy Rule and, as you follow this procedure, configure the
following:
• In the Service/URL Category tab, Add the URL Category that you created in the
previous step.
• In the Opons tab, make sure the Acon is set to Decrypt and that the Type is set to
SSL Forward Proxy.
STEP 2 | Edit or create a URL filtering profile.
STEP 3 | Select HTTP Header Inseron in the URL Filtering Profile dialog.
App-ID
STEP 4 | Add an entry.

1. Specify a Name for this entry.
2. Select Custom as the Type.
3. Add domains to the Domains list.
You can add up to 50 domains and each domain name can have up to 256 characters;
wildcards are supported (for example, *.example.com).
HTTP header inseron occurs when a domain in this list matches the domain in
the Host header of the HTTP request.
4. Add headers to the Headers list.
You can add up to 5 headers and each header can have up to 100 characters but cannot
contain any spaces.
5. For each header Value.
6. (Oponal) Select Log to enable logging of inseron acvity for the headers.
STEP 5 | Add or edit a Security Policy rule (Policies > Security) Security Policythat allows users to
access the SaaS applicaon for which you are configuring this header inseron rule.
1. Choose the URL filtering profile (Acons > URL Filtering) that you edited or created in
Step 2.
2. Click OK to save and then Commit your changes.
STEP 6 | Verify that access to the SaaS applicaon is working in the way you expect. From an endpoint
that is connected to your network:
1. Try to access an account or content that you expect to be able to access. If you cannot
access the SaaS account or content, then the configuraon is not working.
2. Try to access an account or content that you expect will be blocked. If you can access the
SaaS account or content, then the configuraon is not working.
3. If both of the previous steps work as expected, then you can View Logs (if you
configured logging in step 4.6) and you should see the recorded HTTP header inseron
acvity.
App-ID
Maintain Custom Timeouts for Data Center Applicaons

Easily maintain custom meouts for applicaons as you move from a port-based policy to an
applicaon-based policy. Use this method to maintain custom meouts instead of overriding App-
ID (losing applicaon visibility) or creang a custom App-ID (expending me and research).
To get started, configure custom meout sengs as part of a service object:
Then add the service object in a policy rule to apply the custom meouts to the applicaon(s) the
rule enforces.
The following steps describe how apply custom meouts to applicaons; to apply custom
meouts to user groups, you can follow the same steps but just make sure to add the service
object to the security policy rule that enforces the users to whom you want the meout to apply.
STEP 1 | Select Objects > Services to add or modify a service object.
You can also create service objects as you are defining match criteria for a security policy rule:
select Policies > Security > Service/URL Category and Add a new Service object to apply to
the applicaon traffic the rule governs.
STEP 2 | Select the protocol for the service to use (TCP or UDP).
STEP 3 | Enter the desnaon port number or a range of port numbers used by the service.
STEP 4 | Define the session meout for the service.

• Inherit from applicaon (default)—No service-based meouts are applied; instead, apply
the applicaon meout.
• Override—Define a custom session meout for the service.
STEP 5 | If you chose to override the applicaon meout and define a custom session meout,
connue to:
• Enter a TCP Timeout value to set the Maximum length of me in seconds that a TCP
session can remain open aer data transmission has started. When this me expires, the
session closes. The value range is 1 - 604800, and the default value is 3600 seconds.
• Enter a TCP Half Closed value to set the maximum length of me in seconds that a
session remains in the session table between receiving the first FIN packet and receiving
App-ID
the second FIN packet or RST packet. If the mer expires, the session closes. The value
range is 1 - 604800, and the default value is 120 seconds.
• Enter a TCP Wait Time value to set the maximum length of me in seconds that a session
remains in the session table aer receiving the second FIN packet or a RST packet. When
the mer expires, the session closes. The value range is 1 - 600, and the default value is
15 seconds.
STEP 6 | Click OK to save the service object.
STEP 7 | Select Policies > Security and Add or modify a policy rule to govern the applicaon traffic
you want to control.
STEP 8 | Select Service/URL Category and Add the service object you just created to the security
policy rule.
Device-ID
> Device-ID Overview
> Prepare to Deploy Device-ID
> Configure Device-ID
> Manage Device-ID
> CLI Commands for Device-ID
865
Device-ID
Device-ID Overview
Whether or not your environment supports a “Bring Your Own Device” (BYOD) policy, you likely
already have a large number of devices in your network; maybe even more than you realize.
Combined with the need for scalability as the number of users and their accompanying devices
on your network increases, not to menon the growing infrastructure of the Internet of Things
(IoT), this presents a constantly growing area of risk with many possibilies for exploitaon by
malicious users. Addionally, once you idenfy these devices, how do you secure them from
vulnerabilies such as outdated operang soware? Using Device-ID™ on your firewall or to push
policy from Panorama, you can get device context for events on your network, obtain policy rule
recommendaons for those devices, write policies based on devices, and enforce Security policy
based on the recommendaons.
Similar to how User-ID provides user-based policy and App-ID provides app-based policy,
Device-ID provides policy rules that are based on a device, regardless of changes to its IP
address or locaon. By providing traceability for devices and associang network events with
specific devices, Device-ID allows you to gain context for how events relate to devices and write
policies that are associated with devices, instead of users, locaons, or IP addresses, which can
change over me. You can use Device-ID in Security, Decrypon, Quality of Service (QoS) and
Authencaon policies.
Device-ID requires an IoT Security license, a Cortex Data Lake (CDL) license, and the
device cerficate.
If you use PAN-OS version 8.1.0 through PAN-OS 9.1.x on a firewall, the IoT Security license
provides device classificaon, behavior analysis, and threat analysis for your devices. If you use
PAN-OS 10.1 or later, you can use Device-ID to obtain IP address-to-device mappings to view
device context for network events, use IoT Security to obtain policy rule recommendaons for
these devices, and gain visibility for devices in reports and the ACC.
You can create a device-based Security policy on any Panorama or firewall that uses PAN-
OS version 10.1 or later. To enforce the Security policy, the device must have a valid IoT
Security license.
To idenfy and classify devices, the IoT Security app uses metadata from logs, network protocols,
and sessions on the firewall. This does not include private or sensive informaon or data that is
not relevant for device idenficaon. Metadata also forms the basis of the expected behavior for
the device, which then establishes the criteria for the policy rule recommendaon that defines
what traffic and protocols to allow for that device.
When a firewall imports security policy rule recommendaons and IP address-to-device mappings
from IoT Security, the firewall sends its device cerficate to an edge server to authencate itself.
The edge server authencates itself to the firewall by sending its own cerficate. The firewall uses
Online Cerficate Status Protocol (OCSP) to validate the server’s cerficate by checking it against
the following sites using HTTP on TCP port 80:
• ocsp.int-x3.letsencrypt.org
• isrg.trusd.ocscp.identrust.com
• crl.identrust.com
Device-ID
Panorama performs the same check to validate the edge server’s cerficate when Panorama
imports policy rule recommendaons from IoT Security.
Aer IoT Security idenfies and classifies the devices in your network using the Palo Alto
Networks firewalls already in your network, so you don’t have to implement new devices or
third-party soluons, Device-ID can leverage this data to match devices with policy rules and
provide device context for network events. Through the visibility that the firewall or Panorama
provides for traffic, apps, users, devices, and threats, you can instantly trace network events back
to individual devices and obtain Security policy rule recommendaons for securing those devices.
All firewall plaorms that support PAN-OS 10.1 support Device-ID and the IoT Security
app with the excepon of the VM-50 series, the VM-200, the CN series, and Prisma
Access.
There are six levels of classificaon (also known as aributes) for devices:
Aribute Example
Category ATM Machine; 3D Printer
Profile Palo Alto Networks Device
Model iPad
OS Version iOS 9.9.3
OS Family Android; iOS
Vendor ASUS; Philips
To obtain policy rule recommendaons for devices in your network, the firewall observes
traffic to generate Enhanced Applicaon logs (EALs). The firewall then forwards the EALs to
the Cortex Data Lake (CDL) for processing. The IoT Security app on the hub receives logs from
CDL for analysis, provides IP address-to-device mappings, and generates the latest policy rule
recommendaons for your devices. Using the IoT Security app, you can review these policy rule
recommendaons and create a Security policy for these devices. Aer you acvate the policy
rules in the IoT Security app, import them to the firewall or Panorama and commit your Security
policy.
The firewall must be able to observe DHCP broadcast and unicast traffic on your network to
idenfy devices. The more traffic the firewall can observe, the more accurate the policy rule
recommendaons are for the device and the more rapid and accurate the IP address-to-device
mappings are for the device. When a device sends DHCP traffic to obtain an IP address, the
firewall observes this type of request, it generates EALs to send to the Cortex Data Lake for
processing and then analysis by IoT Security.
To observe traffic on an L2 interface, you must configure a VLAN for that interface. By
allowing the firewall to treat the interface as an L3 interface for a DHCP relay, it can
observe the DHCP broadcast traffic without impacng traffic or performance.
Device-ID
Because the firewall needs to both detect the devices based on their traffic and then enforce
Security policy for those devices, the firewall acts as both a sensor to collect metadata from
devices and an enforcer by enforcing your Security policy for the devices. The IoT Security app
automacally detects new devices as soon as they send DHCP traffic and can idenfy 95% of
devices within the first week.
Each applicaon has an individual recommendaon that you import to the firewall or Panorama
as a rule. When you import the recommendaon, the firewall or Panorama creates at least two
objects to define the device behavior from the recommendaon:
• A source device object that idenfies the device where the traffic originates
• One or more desnaon objects that idenfy the permied desnaons for the traffic, which
can be a device, IP address, or Fully Qualified Domain Name (FQDN)
If any of the device objects already exist on the firewall or Panorama, the firewall or Panorama
updates the device object instead of creang a new device objects. You can use these device
objects in Security, authencaon, decrypon, and Quality of Service (QoS) policies.
Addionally, the firewall assigns two tags to each rule:
• One that idenfies the source device, including the category (such as NetworkDevice -
TrendNet).
• One that indicates that the rule is an IoT policy rule recommendaon
(IoTSecurityRecommended).
Because the tags that the firewall assigns to the rule are the only way to restore your
mappings if they become out of sync, do not edit or remove the tags.
For opmal deployment and operaon of Device-ID, we recommend the following best pracces:
• Deploy Device-ID on firewalls that are centrally located in your network. For example, if you
have a large environment, deploy Device-ID on a firewall that is upstream from the IP address
management (IPAM) device. If you have a small environment, deploy Device-ID on a firewall
that is acng as a DHCP server.
• During inial deployment, allow Device-ID to collect metadata from your network for at least
fourteen days. If devices are not acve daily, the idenficaon process may take longer.
• Write device-based policy in order of your most crical devices to least crical. Priorize by:
1. Class (secure networked devices first)
2. Crical devices (such as servers or MRI machines)
3. Environment-specific devices (such as fire alarms and badge readers)
4. Consumer-facing IoT devices (such as a smart watch or smart speaker)
• Enable Device-ID on a per-zone basis for internal zones only.
Device-ID
Prepare to Deploy Device-ID

To prepare your network for Device-ID deployment, complete the following predeployment tasks
to enable your firewall to generate and send Enhanced Applicaon logs (EALs) to the Cortex Data
Lake for processing and analysis by IoT Security for policy rule recommendaon generaon.
STEP 1 | If you have not already done so, install the device cerficate on your firewall or Panorama.
If you use Panorama to manage mulple firewalls, Palo Alto Networks strongly
recommends upgrading all firewalls in your Device-ID deployment to PAN-OS 10.0 or a
later version. If you create a rule that uses Device as a match criteria and Panorama
pushes the rule to a firewall that uses PAN-OS 9.1 or an earlier version, the firewall
omits the Device match criteria because it is not supported, which may cause issues
with policy rule traffic matching.
STEP 2 | Acvate your Cortex Data Lake (CDL) instance and connect your firewall to the instance.
1. Acvate a Cortex Data Lake instance.
2. Connect your firewall to Cortex Data Lake.
STEP 3 | (L2 interfaces only) Create a VLAN interface for each L2 interface so the firewall can observe
the DHCP broadcast traffic.
STEP 4 | (Oponal) Configure a service route to allow the necessary traffic for Device-ID and IoT
Security.
By default, the firewall uses the management interface. To use a different interface, complete
the following steps.
1. Select Device > Setup > Services then select Service Route Configuraon.
2. Customize a service route.
3. Select the IPv4 protocol.
Device-ID and IoT Security do not support IPv6.
4. Select Data Services in the Service column.

5. Select a Source Interface and Source Address.
6. Click OK twice.
STEP 5 | Use App-IDs to allow the necessary traffic for Device-ID and IoT Security.
Purpose App-ID
Retrieve policy rule recommendaons and allow paloalto-iot-security

traffic between the IoT Security app and your firewall
or Panorama.
Allow traffic for all EALs and all session logs. paloalto-logging-service
Device-ID
Purpose App-ID
Retrieve IoT Security dynamic updates and Device paloalto-updates

Diconary updates.
If you have a non-Palo Alto Networks firewall between the firewall using Device-ID and
the internet, verify that the non-Palo Alto Networks firewall can access iot.services-
edge.paloaltonetworks.com:443.
STEP 6 | If you use Panorama, allow the necessary traffic for Device-ID and IoT Security.
Purpose Address TCP Port
(PAN-OS versions 10.0.3 enforcer.iot.services- 443

and later) Receive the edge.paloaltonetworks.com
regional FQDN allow
Device-ID to retrieve
IP address-to-device
mappings and policy rule
recommendaons from IoT
Security.
(PAN-OS versions 10.0.0 iot.services- 443

—10.0.2 and later) Allow edge.paloaltonetworks.com
Device-ID to receive policy
rule recommendaons The address above is the regional
and IP address-to-device FQDN for the United States. For
mappings from IoT Security. other regions, upgrade to 10.0.3
or later to specify and connect to
a regional FQDN. Otherwise, the
firewall connects to the US FQDN
by default.
Allow Panorama to send URL varies depending on the CDL 444

queries for logs to Cortex configuraon. For more informaon, refer to
Data Lake. TCP Ports and FQDNs Required for Cortex
Data Lake.
STEP 7 | If you use firewalls, allow the necessary traffic for Device-ID and IoT Security.
(PAN-OS versions 10.0.3 and enforcer.iot.services- N/A

later) Receive the regional edge.paloaltonetworks.com
FQDN to retrieve IP address-to-
device mappings and policy rule
recommendaons from IoT Security.
Device-ID
(PAN-OS versions 10.0.0—10.0.2) iot.services- 443

Allow the firewall to receive policy edge.paloaltonetworks.com
rule recommendaons and IP
address-to-device mappings from IoT
Security.
Download device diconary files updates.paloaltonetworks.com 443

from the update server.
Forward logs to Cortex Data Lake. N/A 444

and
3978
STEP 8 | Configure your firewall to observe and generate logs for DHCP traffic then forward the logs
for processing and analysis by IoT Security.
• If the firewall is acng as a DHCP server:
1. Enable Enhanced Applicaon logging.
2. Create a log forwarding profile to forward the logs to the CDL for processing.
3. (Not supported on the PA-3200, PA-5200, PA-5450, or PA-7000) Enable the DHCP
Broadcast Session opon (Device > Setup > Session > Session Sengs).
4. Create a Security policy rule to allow dhcp as the Applicaon type.
• If the firewall is not a DHCP server, configure an interface as a DHCP relay agent so that the
firewall can generate EALs for the DHCP traffic it receives from clients.
• If your DHCP server is on the same network segment as the interface your firewall, deploy
a virtual wire interface in front of the DHCP server to ensure the firewall generates EALs for
all packets in the inial DHCP exchange with minimal performance impact.
1. Configure a virtual wire interface with corresponding zones and enable the Mulcast
Firewalling opon (Network > Virtual Wires > Add).
2. Configure a rule to allow DHCP traffic to and from the DHCP server between the virtual
wire zones. The policy must allow all exisng traffic that the server currently observes
and use the same log forwarding profile as the rest of your rules.
3. To allow the DHCP servers to check if an IP address is acve before assigning it as a
lease to a new request, configure a rule to allow pings from the DHCP server to the rest
of the subnet.
4. Configure a rule to allow all other traffic to and from the DHCP server that does not
forward logs for traffic matches.
5. Configure the DHCP server host to use the first virtual wire interface and the network
switch to use the second virtual wire interface. To minimize cabling, you can use an
Device-ID
isolated VLAN in the switching infrastructure instead of connecng the DHCP server
host directly to the firewall.
• If you want to use a tap interface to gain visibility into DHCP traffic that the firewall doesn’t
usually observe due to the current configuraon or topology of the network, use the
following configuraon as a best pracce.
1. Configure a tap interface and corresponding zone.
2. Configure a rule to match DHCP traffic that uses the same log forwarding profile as the
rest of your rules.
3. To minimize the session load on the firewall, configure a rule to drop all other traffic.
4. Connect the tap interface to the port mirror on the network switch.
STEP 9 | Add session log types to the log forwarding profile.

If there are no exisng entries in the log forwarding profile, selecng the Enable enhanced
applicaon logging to Cortex Data Lake (including traffic and url logs) opon adds all logs
types.
1. Add a new profile and enter a name.
2. Select traffic as the Log type.
3. Select All logs as the Filter.
4. Select the Cortex Data Lake opon.
5. Click OK.
6. Repeat substeps 1-5 for the threat and, if you have a subscripon, wildfire log types.
Device-ID
Configure Device-ID
Complete the following tasks to import the IP address-to-device mappings and policy rule
recommendaons from IoT Security to your firewall or Panorama.
If you use Panorama to manage mulple firewalls, Palo Alto Networks strongly
recommends upgrading all firewalls in your Device-ID deployment to PAN-OS 10.0 or a
later version. If you create a rule that uses Device as a match criteria and Panorama
pushes the rule to a firewall that uses PAN-OS 9.1 or an earlier version, the firewall omits
the Device match criteria because it is not supported, which may cause issues with
policy rule traffic matching.
STEP 1 | Acvate your IoT Security license on the hub.

1. Follow the instrucons that you received in your email to acvate your IoT Security
license.
2. Inialize your IoT Security app. For more informaon, refer to Get Started with IoT
Security and the IoT Security Best Pracces.
3. Apply the license to the firewalls you want to use to enforce the IoT Security policy.
4. Refresh your license on the firewall or Panorama.
STEP 2 | Define your IoT Security policy on the IoT Security app.
1. On the IoT Security app, select the source device object.
2. Create a new set of policy rules for the source device object.
For more informaon about creang security policies with the IoT Security app, refer to
Recommend Security Policies.
3. Acvate the policy rules to confirm your changes.
Device-ID
STEP 3 | Import the IP address-to-device mappings and policy rule recommendaons to the firewall or
Panorama.
1. Import the policy rule recommendaon.
• On the firewall, select Device > Policy Recommendaon > IoT.
• For Panorama, select Panorama > Policy Recommendaon > IoT then push the policy
rules to the firewalls that Panorama manages.
Aer you push the policy to the firewalls, you must Sync Policy Rules on the
firewalls to create the policy rule recommendaon-to-policy rule mapping.
When you select Policy Recommendaon, the firewall or Panorama communicates
with IoT Security to obtain the latest policy rule recommendaons. The policy rule
recommendaons are not cached on the firewall or Panorama.
Because IoT Security creates the policy rule recommendaon using the trusted
behavior for the device, the default acon for the rule is allow.
2. Select the Source Device Profile.
3. Verify that the Desnaon Device Profile and permied Applicaons are correct.
4. Select Import Policy Rules to import the policy rules.
5. (Panorama only) Select the Locaon of the device group where you want to import the
policy rules.
6. Enter a Name for the policy rules.
7. (Panorama only) Select the Desnaon Type (Pre-Rulebase or Post-Rulebase).
8. Select Aer Rule to define the placement of the rule in the rulebase.
• No Rule Selecon—Places the rule at the top of the rulebase.
• Default One—Places the rule aer the listed rule.
In your Security policy, Device-ID rules must precede any exisng rules that
apply to the devices.
9. Repeat this process for each policy rule recommendaon to create rules to allow access
for each device object to the necessary desnaon(s).
STEP 4 | Enable Device-ID in each zone where you want to use Device-ID to detect devices and
enforce your Security policy.
By default, Device-ID maps all subnetworks in the zones where you enable it. You can modify
which subnetworks Device-ID maps in the Include List and Exclude List.
As a best pracce, enable Device-ID in the source zone to detect devices and enforce
security policy. Only enable Device-ID for internal zones.
1. Select Network > Zones.

2. Select the zone where you want to enable Device-ID.
3. Enable Device Idenficaon then click OK.
Device-ID
STEP 6 | Verify your Security policy is correct.

1. Select Policies then select the rule you created from the policy rule recommendaon.
IoT Security assigns a Descripon that contains the source device object and Tags
to idenfy the source device object and that this rule is a recommendaon from IoT
Security.
Device object names must be unique.
2. Select the Source tab, then verify the Source Device Profile.
3. Select the Desnaon tab and verify the Desnaon Device Profile.
4. Select the Applicaon tab and verify the Applicaons.
5. Select the Acons tab and verify the Acon (default is Allow).
6. Use Explore to verify CDL receives your logs and review which logs CDL receives.
STEP 7 | Create custom device objects for any devices that do not have IoT Security policy rule
recommendaons.
For example, you cannot secure devices such as laptops and smartphones using policy rule
recommendaons, so you must manually create device objects for these types of devices
to use in your Security policy. For more informaon on custom device objects, see Manage
Device-ID.
STEP 8 | Use the device objects to enforce policy rules and to monitor and idenfy potenal issues.
The following list includes some example use cases for device objects.
• Use source device objects and desnaon device objects in Security, Authencaon, QoS, &
decrypon policies.
• Use the decrypon log to idenfy failures and which assets are the most crical to decrypt.
• View device object acvity in ACC to track new devices and device behavior.
• Use device objects to create a custom report (for example, for incident reports or audits).
Device-ID
Manage Device-ID
Perform the following tasks as needed to ensure your policy rule recommendaons and device
objects are current or to restore policy rule recommendaon mappings.
STEP 1 | Update your policy rule recommendaon whenever the New Updates Available column
displays Yes for that recommendaon.
As devices gain new capabilies, IoT Security updates the policy rule recommendaons to
advise what addional traffic or protocols the firewall or Panorama should allow. Check IoT
Security daily for updates and update your policy rule recommendaons as soon as possible.
1. On the IoT Security app, Edit the policy rules then click Next.
2. Select the new recommendaon then click Next.
3. Save your changes.
4. On the firewall or Panorama, click Import Policy Rules then click Yes to confirm that you
want to overwrite the current rule.
This acon overwrites the recommendaon for the rule, not the rule itself.
5. (Panorama only) Repeat the previous step for all device groups.
STEP 2 | Review, update, and maintain the device objects in the Device Diconary.
You must create device objects for any devices that do not have an IoT Security policy
rule recommendaon. For example, you cannot secure devices such as laptops and
smartphones using IoT Security policy rule recommendaons, so you must create
device objects for these types of devices and use them in your Security policy to secure
these devices.
1. Select Objects > Devices.

2. Add a device object.
3. Browse the list or Search using keywords.
The search results can include mulple types of device object aributes (for example,
both Category and Profile).
4. To add a custom device object, enter a Name and oponally a Descripon for the device
object.
Always use a unique name for each device object. Do not change the tags in the
descripon for device objects from policy rule recommendaons.
5. (Panorama only) Select the Shared opon to make this device object available to other
device groups.
6. Select the aributes for the device object (Category, OS, Profile, Osfamily, Model, and
Vendor).
7. Click OK to confirm your changes.
Device-ID
STEP 3 | In some cases (for example, if you restore a previous configuraon), the policy rule
recommendaon-to-policy rule mappings may become out of sync. You must also sync the
mappings on each firewall aer you push the policy rules from Panorama to the firewalls that
Panorama manages. To sync the mappings:
• On the firewall, select Device > Policy Recommendaon > IoT > Sync Policy Rules
• For Panorama, select Panorama > Policy Recommendaon > IoT > Sync Policy Rules.
The firewall or Panorama scans all of the rules in the rulebase to check for tags that idenfy
a rule as an IoT Security policy rule recommendaon, obtains the source device object
informaon, and repopulates the local policy rule recommendaon database.
STEP 4 | Delete any policy rule recommendaons that are no longer needed.
If a policy rule recommendaon no longer applies, you can remove the policy rule
recommendaon. You must also remove the rule for the policy rule recommendaon to enforce
the updated Security policy.
1. On the IoT Security app, select Delete.
2. Click Mark as Removed to select this recommendaon for removal.
3. Remove the mapping.
• On the firewall, select Device > Policy Recommendaon > IoT > Remove Policy
Mapping.
• For Panorama, select Device > Policy Recommendaon > IoT > Remove Policy
Mapping then select the Locaon from which you want to remove the mapping.
4. Click Yes to confirm the mapping removal.
5. Select Policies > Security. For Panorama, select Policies > Security > Pre-Rules/Post-
Rules.
6. Select the rule for the policy rule recommendaon you want to remove then select
Delete.
STEP 5 | Use CLI commands to troubleshoot any issues between the firewall and IoT Security.
Device-ID
CLI Commands for Device-ID

Use the following CLI commands to view informaon for troubleshoong any issues between the
firewall and IoT Security. In general, CLI commands that include eal show counters for outgoing
data and CLI commands that include icd show counters for incoming data.
Example Command
View Enhanced Applicaon Logging (EAL) show iot eal all

counters, such as the number of connecons
between the firewall and the Cortex Data Lake
and the volume of the logs.
View more details about the connecon between show iot eal conn
the firewall and Cortex Data Lake.
View a summary of the EAL counters by plane show iot eal dpi-eal
(dataplane or management plane), such as the
PAN-OS version and serial number.
View EAL counters by plane (dataplane or show iot eal dpi-stats all
management plane) and by protocol.
View EAL counters by protocol. show iot eal dpi-stats subtype

dhcp|http
View a summary of Host Informaon Profile (HIP) show iot eal hipreport-eal
Match report counters.
View EAL log response me counters. show iot eal response-time
View details for the health of the connecon show iot icd statistics all
to the edge service between the firewall and
the IoT Security app and counters for the IP
address-to-device mappings and policy rule
recommendaons.
View counters for the connecon to the edge show iot icd statistics conn
service.
View counters for the IP address-to-device show iot icd statistics

mappings. verdict
View all IP address-to-device mappings on the show iot ip-device-mapping-mp

firewall. all
View the IP address-to-device mapping for a show iot ip-device-mapping-mp

specific IP address. ip IP-address
Device-ID
Example Command
View a list of IP address-to-device mappings on show iot ip-device-mapping all

the dataplane.
Clear the IP address-to-device mappings on the debug iot clear-all type

management plane. device
Clear the IP address-to-device mappings on the clear user-cache all

dataplane.
Device-ID
Threat Prevenon
The Palo Alto Networks® next-generaon firewall protects and defends your network
from commodity threats and advanced persistent threats (APTs). The mul-pronged
detecon mechanisms of the firewall include a signature-based (IPS/Command and
Control/Anvirus) approach, heuriscs-based (bot detecon) approach, sandbox-
based (WildFire) approach, and Layer 7 protocol analysis-based (App-ID) approach.
Commodity threats are exploits that are less sophiscated and more easily detected
and prevented using a combinaon of anvirus, an-spyware, and vulnerability
protecon features along with URL filtering and Applicaon idenficaon capabilies
on the firewall.
Advanced threats are perpetuated by organized cyber adversaries who use
sophiscated aack vectors to target your network, most commonly for intellectual
property the and financial data the. These threats are more evasive and require
intelligent monitoring mechanisms for detailed host and network forensics on
malware. The Palo Alto Networks next-generaon firewall together with WildFire™
and Panorama™ provide a comprehensive soluon that intercepts and breaks the
aack chain and provides visibility to prevent security infringement on your network
infrastructure—both mobile and virtualized.
Aer you implement your threat prevenon configuraons, Export Configuraon Table Data to
create a PDF or CSV report of your configuraons to use for internal review or for auding.
> Best Pracces for Securing Your > Customize the Acon and Trigger
Network from Layer 4 and Layer 7 Condions for a Brute Force
Evasions Signature
> Set Up Anvirus, An-Spyware, and > Enable Evasion Signatures
Vulnerability Protecon > Monitor Blocked IP Addresses
> DNS Security > Threat Signature Categories
> Use DNS Queries to Idenfy Infected > Create Threat Excepons
Hosts on the Network
> Custom Signatures
> Set Up Data Filtering
> Learn More About and Assess
> Predefined Data Filtering Paerns Threats
> Create a Data Filtering Profile > Share Threat Intelligence with Palo
> WildFire Inline ML Alto Networks
> Set Up File Blocking > Threat Prevenon Resources
> Prevent Brute Force Aacks
881
Threat Prevenon
Best Pracces for Securing Your Network from Layer 4

and Layer 7 Evasions
To monitor and protect your network from most Layer 4 and Layer 7 aacks, here are a few
recommendaons.
Upgrade to the most current PAN-OS soware version and content release version to ensure
that you have the latest security updates. See Install Content and Soware Updates.
Enable DNS Security (requires a Threat Prevenon and DNS Security subscripon license) to
sinkhole malicious DNS requests. Palo Alto Networks recommends using the following DNS
Security category configuraon sengs in your An-Spyware profile:
• For the log severity sengs, use the default sengs:

• For the policy acon, set all signature sources to sinkhole.
• For packet capture, set Command and Control Domains to extended-capture. Leave all
other categories to default sengs.
For more informaon on related an-spyware sengs, see Best Pracce Internet Gateway
An-Spyware Profile.
Set up the firewall to act as a DNS proxy and enable evasion signatures:
DNS proxy is not part of the firewall security policy engine; instead, it directs the
firewall to resolve DNS hostnames, while maintaining domain to IP mapping, which is
crucial for prevenng TLS/HTTP evasion.
• Configure a DNS Proxy Object.

When acng as a DNS proxy, the firewall resolves DNS requests and caches hostname-to-IP
address mappings to quickly and efficiently resolve future DNS queries.
• Enable Evasion Signatures
Evasion signatures that detect craed HTTP or TLS requests can send alerts when clients
connect to a domain other than the domain specified in the original DNS request. Make sure
to configure DNS proxy before you enable evasion signatures. Without DNS proxy, evasion
signatures can trigger alerts when a DNS server in the DNS load balancing configuraon
Threat Prevenon
returns different IP addresses—for servers hosng idencal resources—to the firewall and
client in response to the same DNS request.
For servers, create Security policy rules to allow only the applicaon(s) that you sancon on
each server. Verify that the standard port for the applicaon matches the listening port on
the server. For example, to ensure that only SMTP traffic is allowed to your email server, set
the Applicaon to smtp and set the Service to applicaon-default. If your server uses only a
subset of the standard ports (for example, if your SMTP server uses only port 587 while the
SMTP applicaon has standard ports defined as 25 and 587), create a new custom service
that includes only port 587 and use that new service in your security policy rule instead
of applicaon-default. Addionally, make sure you restrict access to specific source and
desnaons zones and sets of IP addresses.
Block all unknown applicaons and traffic using the Security policy. Typically, the only
applicaons classified as unknown traffic are internal or custom applicaons on your network
and potenal threats. Unknown traffic can be either non-compliant applicaons or protocols
that are anomalous or abnormal or it can be known applicaons that are using non-standard
ports, both of which should be blocked. See Manage Custom or Unknown Applicaons.
Threat Prevenon
Set Up File Blocking to block Portable Executable (PE) file types for internet-based SMB (Server
Message Block) traffic from traversing trust to untrust zones (ms-ds-smb applicaons).
Block malicious variants of PE (portable executables), PowerShell scripts, and ELF files in
real-me. Enabling WildFire Inline ML allows you to dynamically analyze files using machine
learning on the firewall. This addional layer of anvirus protecon complements the WildFire-
based signatures to provide extended coverage for files of which signatures do not already
exist.
Threat Prevenon
Create a Zone Protecon profile that is configured to protect against packet-based aacks
(Network > Network Profiles > Zone Protecon):
• Select the opon to drop Malformed IP packets (Packet Based Aack Protecon > IP Drop).
• Enable the drop Mismatched overlapping TCP segment opon (Packet Based Aack
Protecon > TCP Drop).
By deliberately construcng connecons with overlapping but different data in them,
aackers aempt to cause misinterpretaon of the intent of the connecon and deliberately
induce false posives or false negaves. Aackers also use IP spoofing and sequence
number predicon to intercept a user's connecon and inject their own data into that
connecon. Selecng the Mismatched overlapping TCP segment opon specifies that
PAN-OS discards frames with mismatched and overlapping data. Received segments are
Threat Prevenon
discarded when they are contained within another segment, when they overlap with part of
another segment, or when they contain another complete segment.
• Enable the drop TCP SYN with Data and drop TCP SYNACK with Data opons (Packet
Based Aack Protecon > TCP Drop).
Dropping SYN and SYN-ACK packets that contain data in the payload during a three-way
handshake increases security by blocking malware contained in the payload and prevenng
it from extracng unauthorized data before the TCP handshake is completed.
• Strip TCP mestamps from SYN packets before the firewall forwards the packet (Packet
Based Aack Protecon > TCP Drop).
When you enable the Strip TCP Opons - TCP Timestamp opon, the TCP stack on both
ends of the TCP connecon will not support TCP mestamps. This prevents aacks that use
different mestamps on mulple packets for the same sequence number.
Threat Prevenon
If you configure IPv6 addresses on your network hosts, be sure to enable support for IPv6 if
not already enabled (Network > Interfaces > Ethernet > IPv6).
Enabling support for IPv6 allows access to IPv6 hosts and also filters IPv6 packets encapsulated
in IPv4 packets, which prevents IPv6 over IPv4 mulcast addresses from being leveraged for
network reconnaissance.
Enable support for mulcast traffic so that the firewall can enforce policy on mulcast traffic
(Network > Virtual Router > Mulcast).
Threat Prevenon
Disable the opons to Forward datagrams exceeding UDP content inspecon queue and
Forward segments exceeding TCP content inspecon queue (Device > Setup > Content-ID >
Content-ID Sengs).
By default, when the TCP or UDP content inspecon queues are full, the firewall skips content
inspecon for TCP segments or UDP datagrams that exceed the queue limit of 64. Disabling
this opon ensures content inspecon for all TCP and UDP datagrams that the firewall
allows. Only under specific circumstances—for example, if the firewall plaorm is not sized
appropriately to align with a use case—could disabling this seng impact performance.
Disable the Allow HTTP paral response (Device > Setup > Content-ID > Content-ID
Sengs).
The HTTP paral response opon allows a client to fetch only part of a file. When a next-
generaon firewall in the path of a transfer idenfies and drops a malicious file, it terminates
the TCP session with an RST packet. If the web browser implements the HTTP header range
opon, it can start a new session to fetch only the remaining part of the file, which prevents
the firewall from triggering the same signature again due to the lack of context into the inial
session and, at the same me, allows the web browser to reassemble the file and deliver the
malicious content. Disabling this opon prevents this from happening.
Allow HTTP paral response is enabled on the firewall by default. This provides maximum
availability but increases the risk of a successful cyberaack. For maximum security, disable this
opon to prevent the web browser from starng a new session to fetch the rest of a file aer
the firewall terminates the original session due to malicious acvity. Disabling HTTP paral
response affects HTTP-based data transfers which use the RANGE header, which may cause
service anomalies for certain applicaons. Aer you disable HTTP paral response, validate the
operaon of your business-crical applicaons.
If you experience HTTP data transfer disrupon on a business-crical applicaon, you can
create an Applicaon Override policy for that specific applicaon. Because Applicaon
Override bypasses App-ID (including threat and content inspecon), create an Applicaon
Override policy for only the specific business-crical applicaon, and specify sources and
desnaons to limit the rule (principle of least privilege access). Do not create Applicaon
Override policy unless you must. For informaon about Applicaon Override policies, refer to
hps://knowledgebase.paloaltonetworks.com/KCSArcleDetail?id=kA10g000000ClVLCA0.
Create a Vulnerability Protecon Profile that blocks protocol anomalies and all vulnerabilies
with low and high severies.
A protocol anomaly occurs when a protocol behavior deviates from standard and compliant
usage. For example, a malformed packet, poorly wrien applicaon, or an applicaon running
Threat Prevenon
on a non-standard port would all be considered protocol anomalies, and could be used as
evasion tools.
If yours is a mission-crical network, where the business’s highest priority is applicaon
availability, you should begin by alerng on protocol anomalies for a period of me to ensure
that no crical internal applicaons are using established protocols in a non-standard way. If
you find that certain crical applicaons trigger protocol anomaly signatures, you can then
exclude those applicaons from protocol anomaly enforcement. To do this, add another rule to
the Vulnerability Protecon Profile that allows protocol anomalies and aach the profile to the
security policy rule that enforces traffic to and from the crical applicaons.
Make sure that Vulnerability Protecon Profile rules and security policy rules that allow
protocol anomalies for crical internal applicaons are listed above rules that block protocol
anomalies. Traffic is evaluated against security policy rules and associated Vulnerability
Protecon Profiles rules from top to boom, and is enforced based on the first matching rule.
• Begin by alerng on protocol anomalies:
Create a Vulnerability Protecon Profile rule with the Acon set to Alert, the Category set
to protocol-anomaly, and the Severity set to Any. Monitor your traffic to determine if any
crical internal applicaons are using established protocols in non-standard ways. If you find
Threat Prevenon
this to be true, connue to allow protocol anomalies for those applicaons, and then block
protocol anomalies for all other applicaons.
• Block protocol anomalies:

Create a Vulnerability Protecon Profile rule with the Category set to protocol-anomaly, the
rule Acon set to Reset Both, and the Severity set to Any.
Threat Prevenon
• Oponally allow protocol anomalies for crical applicaons that use established protocols
in a non-standard way. To do this, create a Vulnerability Protecon Profile rule that allows
protocol anomalies: set the rule Acon to Allow, the Category to protocol-anomaly, and the
Threat Prevenon
Severity to any. Aach the Vulnerability Protecon Profile rule to the security policy rule
that enforces traffic to and from crical applicaons.
• Add another rule to the Vulnerability Protecon profile to block all vulnerabilies with low
and higher severity. This rule must be listed aer the rule that blocks protocol anomalies.
Connue to aach the following security profiles to your Security policy rules to provide
signature-based protecon:
• An An-Spyware profile to block all spyware with severity low and higher.
• An Anvirus profile to block all content that matches an anvirus signature.
Threat Prevenon
Set Up Anvirus, An-Spyware, and Vulnerability

Protecon
Every Palo Alto Networks next-generaon firewall comes with predefined Anvirus, An-
Spyware, and Vulnerability Protecon profiles that you can aach to Security policy rules. There
is one predefined Anvirus profile, default, which uses the default acon for each protocol (block
HTTP, FTP, and SMB traffic and alert on SMTP, IMAP, and POP3 traffic). There are two predefined
An-Spyware and Vulnerability Protecon profiles:
• default—Applies the default acon to all client and server crical, high, and medium severity
spyware/vulnerability protecon events. It does not detect low and informaonal events.
• strict—Applies the block response to all client and server crical, high and medium severity
spyware/vulnerability protecon events and uses the default acon for low and informaonal
events.
To ensure that the traffic entering your network is free from threats, aach the predefined profiles
to your basic web access policies. As you monitor the traffic on your network and expand your
policy rulebase, you can then design more granular profiles to address your specific security needs.
Use the following workflow to set up the default Anvirus, An-Spyware, and Vulnerability
Protecon Security Profiles.
Palo Alto Networks defines a default acon for all an-spyware and vulnerability
protecon signatures. To see the default acon, select Objects > Security Profiles >
An-Spyware or Objects > Security Profiles > Vulnerability Protecon and then select
a profile. Click the Excepons tab and then click Show all signatures to view the list
of the signatures and the corresponding default Acon. To change the default acon,
create a new profile and specify an Acon, and/or add individual signature excepons to
Excepons in the profile.
STEP 1 | Verify that you have a Threat Prevenon subscripon.

The Threat Prevenon subscripon bundles the anvirus, an-spyware, and vulnerability
protecon features in one license. To verify that you have an acve Threat Prevenon
subscripon, select Device > Licenses and verify that the Threat Prevenon expiraon date is
in the future.
STEP 2 | Download the latest content.

1. Select Device > Dynamic Updates and click Check Now at the boom of the page to
retrieve the latest signatures.
2. In the Acons column, click Download and install the latest Anvirus updates and then
download and then Install the latest Applicaons and Threats updates.
Threat Prevenon
STEP 3 | Schedule content updates.
Review the Best Pracces for Applicaons and Threats Content Updates for
important informaon on deploying updates.
1. Select Device > Dynamic Updates and then click Schedule to automacally retrieve
signature updates for Anvirus and Applicaons and Threats.
2. Specify the frequency and ming for the updates:
• download-only—The firewall automacally downloads the latest updates per the
schedule you define but you must manually Install them.
• download-and-install—The firewall automacally downloads and installs the updates
per the schedule you define.
3. Click OK to save the update schedule; a commit is not required.
4. (Oponal) Define a Threshold to indicate the minimum number of hours aer an
update becomes available before the firewall will download it. For example, seng the
Threshold to 10 means the firewall will not download an update unl it is at least 10
hours old regardless of the schedule.
5. (HA only) Decide whether to Sync To Peer, which enables peers to synchronize content
updates aer download and install (the update schedule does not sync across peers; you
must manually configure the schedule on both peers).
There are addional consideraons for deciding if and how to Sync To Peer depending
on your HA deployment:
• Acve/Passive HA—If the firewalls are using the MGT port for content updates, then
schedule both firewalls to download and install updates independently. However,
if the firewalls are using a data port for content updates, then the passive firewall
will not download or install updates unless and unl it becomes acve. To keep the
schedules in sync on both firewalls when using a data port for updates, schedule
updates on both firewalls and then enable Sync To Peer so that whichever firewall is
acve downloads and installs the updates and also pushes the updates to the passive
firewall.
• Acve/Acve HA—If the firewalls are using the MGT interface for content updates,
then select download-and-install on both firewalls but do not enable Sync To Peer.
However, if the firewalls are using a data port, then select download-and-install on
both firewalls and enable Sync To Peer so that if one firewall goes into the acve-
secondary state, the acve-primary firewall will download and install the updates and
push them to the acve-secondary firewall.
Threat Prevenon
STEP 4 | (Oponal) Create custom security profiles for anvirus, an-spyware, and vulnerability
protecon.
Alternavely, you can use the predefined default or strict profiles.
Transion safely to best pracce Security profiles for the best security posture.
• To create custom Anvirus Profiles, select Objects > Security Profiles > Anvirus and Add a
new profile. Use the Anvirus profile transion steps to safely reach your goal.
• To create custom An-Spyware Profiles, select Objects > Security Profiles > An-Spyware
and Add a new profile. Use the An-Spyware profile transion steps to safely reach your
goal.
• To create custom Vulnerability Protecon Profiles, select Objects > Security Profiles >
Vulnerability Protecon and Add a new profile. Use the Vulnerability Protecon profile
transion steps to safely reach your goal.
STEP 5 | Aach security profiles to your Security policy rules.
When you configure the firewall with a Security policy rule that uses a Vulnerability
Protecon profile to block connecons, the firewall automacally blocks that traffic in
hardware (see Monitor Blocked IP Addresses).
1. Select Policies > Security and select the rule you want to modify.
2. In the Acons tab, select Profiles as the Profile Type.
3. Select the security profiles you created for Anvirus, An-Spyware, and Vulnerability
Protecon.

Click Commit.
Threat Prevenon
DNS Security
DNS Security is a connuously evolving threat prevenon service designed to protect and defend
your network from advanced threats using DNS. By leveraging advanced machine learning and
predicve analycs, the service provides real-me DNS request analysis and rapidly produces and
distributes DNS signatures that are specifically designed to defend against malware using DNS for
C2 and data the. Combined with an extensible cloud architecture, it provides access to a scalable
threat intelligence system to keep your network protecons up to date.
• About DNS Security
• Cloud-Delivered DNS Signatures and Protecons
• DNS Security Analycs
• Enable DNS Security
• DNS Security Data Collecon and Logging
About DNS Security

With an acve Threat Prevenon license, customers can configure their firewalls to sinkhole
DNS requests using a list of domains generated by Palo Alto Networks. These locally-accessed,
customizable DNS signature lists are packaged with anvirus and WildFire updates and include
the most relevant threats for policy enforcement and protecon at the me of publicaon. For
improved coverage against threats using DNS, the DNS Security subscripon enables users
to access real-me protecons using advanced predicve analycs. Using techniques such as
DGA/DNS tunneling detecon and machine learning, threats hidden within DNS traffic can
be proacvely idenfied and shared through an infinitely scalable cloud service. Because the
DNS signatures and protecons are stored in a cloud-based architecture, you can access the
full database of ever-expanding signatures that have been generated using a multude of data
sources. This allows you to defend against an array of threats using DNS in real-me against newly
generated malicious domains. To combat future threats, updates to the analysis, detecon, and
prevenon capabilies of the DNS Security service will be available through content releases.
To access the DNS Security service, you must have a valid Threat Prevenon and DNS Security
license.
The following workflow describes how the DNS Security service uses various data sources to
generate DNS signatures:
Threat Prevenon
Cloud-Delivered DNS Signatures and Protecons

As a cloud-based service, DNS Security allows you to access an infinitely scalable DNS signature
and protecons source to defend your organizaon from malicious domains. Domain signatures
and protecons generated by Palo Alto Networks are derived from a multude of sources,
including WildFire traffic analysis, passive DNS, acve web crawling & malicious web content
analysis, URL sandbox analysis, Honeynet, DGA reverse engineering, telemetry data, whois, the
Unit 42 research organizaon, and third party data sources such as the Cyber Threat Alliance. This
on-demand cloud database provides users with access to the complete Palo Alto Network’s DNS
signature set, including signatures generated using advanced analysis techniques, as well as real-
me DNS request analysis. Locally available, downloadable DNS signature sets (packaged with the
anvirus and WildFire updates) come with a hard-coded capacity limitaon of 100k signatures
and do not include signatures generated through advanced analysis. To beer accommodate the
influx of new DNS signatures being produced on a daily basis, the cloud-based signature database
provides users with instant access to newly added DNS signatures without the need to download
updates. If network connecvity goes down or is otherwise unavailable, the firewall uses the
onbox DNS signature set.
Threat Prevenon
DNS Security Analycs

The DNS Security service operates real-me DNS request analysis using predicve analycs
and machine learning on mulple DNS data sources. This is used to generate protecons for
DNS-based threats, which are accessible in real-me through configuraon of the An-Spyware
Security profile aached to a Security policy rule. Each DNS threat category (the DNS Signature
Source) allows allow you to define separate policy acons as well as a log severity level for a
specific signature type. This enables you to create specific security policies based on the nature
of the threat, according to your network security protocols. Palo Alto Networks also generates
and maintains a list of explicitly allowable domains based on metrics from PAN-DB and Alexa.
These allow list domains are frequently accessed and known to be free of malicious content. The
DNS Security categories and the allow list are updated and extensible through PAN-OS content
releases.
You can view your organizaon’s DNS stascs data generated by the DNS Security Cloud
service using AutoFocus. This provides a fast, visual assessment describing the breakdown of DNS
requests passing through your network based on the available DNS categories. Alternavely, you
can retrieve domain informaon, as well as the transacon details, such as latency and TTL using
the test dns-proxy dns-signature fqdn <domain> command.
Upon upgrade to PAN-OS 10.0 and later, the DNS Security source gets redefined into
new categories to provide extended granular controls; as a result, the new categories will
overwrite the previously defined acon and acquire default sengs. Make sure to reapply
any sinkhole, log severity, and packet captures sengs appropriate for the newly defined
DNS Security Categories.
The DNS Security service currently supports detecon of the following DNS threat categories:
• Command and Control Domains—C2 includes URLs and domains used by malware and/or
compromised systems to surrepously communicate with an aacker’s remote server to
Threat Prevenon
receive malicious commands or exfiltrate data (this includes DNS tunneling detecon and DGA
detecon), or deplete resources on a target authoritave DNS servers (such as NXNSaack).
• DNS Tunnel Detecon—DNS tunneling can be used by aackers to encode data of non-
DNS programs and protocols within DNS queries and responses. This provides aackers
with an open back channel with which they can transfer files or remotely access the system.
DNS tunnel detecon uses machine learning to analyze the behavioral qualies of DNS
queries, including n-gram frequency analysis of domains, entropy, query rate, and paerns to
determine if the query is consistent with a DNS tunneling-based aack. This includes certain
next-generaon DNS tunneling malware that exfiltrates data slowly across mulple domains
to avoid detecon, such as TriFive and Snugy. Combined with the firewall’s automated policy
acons, this allows you to quickly detect C2 or data the hidden in DNS tunnels and to
automacally block it, based on your defined policy rules.
• DGA Domain Detecon—Domain generaon algorithms (DGAs) are used to auto-generate
domains, typically in large numbers within the context of establishing a malicious command-
and-control (C2) communicaons channel. DGA-based malware (such as Pushdo, BankPatch,
and CryptoLocker) limit the number of domains from being blocked by hiding the locaon of
their acve C2 servers within a large number of possible suspects, and can be algorithmically
generated based on factors such as me of day, cryptographic keys, diconary-derived
naming schemes, and other unique values. While most domains generated by a DGA do not
resolve as a valid domain, they must all be idenfied to fully defend against a given threat.
DGA analysis determines whether a domain is likely to have been generated by a machine,
rather than a person, by reverse-engineering and analyzing other frequently used techniques
found in DGAs. Palo Alto Networks then uses these characteriscs to idenfy and block
previously unknown DGA-based threats in real-me.
• NXNSAack—The NXNSAack vulnerability present in the DNS protocol affects all
recursive DNS resolvers and can be used by malicious actors to launch DDos-like
amplificaon aacks to disrupt the normal operaon of vulnerable authoritave DNS
servers. NXNSAack can introduce massive traffic spikes on an authoritave DNS server by
forcing the recursive DNS resolver to issue a large number of invalid requests to potenally
shut down the server.
• DNS Rebinding—DNS rebinding aacks lure users to an aacker-controlled domain
configured with a short TTL parameter to manipulate how domain names are resolved to
exploit and bypass the same-origin policy in browsers. This enables malicious actors to use
the client machine as an intermediary to aack or access a resource contained within a
private network.
• Dynamic DNS Hosted Domains—Dynamic DNS (DDNS) services provide mapping between
hostnames and IP addresses in near real-me to keep changing IP addresses linked to a
specific domain, when stac IPs are unavailable. This provides aackers a method of infiltrang
networks by using DDNS services to change the IP addresses that host command-and-control
servers. Malware campaigns and exploit kits can ulize DDNS services as part of their payload
distribuon strategy. By ulizing DDNS domains as part of their hostname infrastructure,
adversaries can change the IP address associated with given DNS records and more easily avoid
detecon. DNS Security detects exploitave DDNS services by filtering and cross-referencing
DNS data from various sources to generate candidate lists which are then further validated to
maximize accuracy.
• Malware Domains—Malicious domains host and distribute malware and can include
websites that aempt to install various threats (such as executables, scripts, viruses, drive-
Threat Prevenon
by downloads). Malicious domains are disnguishable from C2 domains in that they deliver
malicious payloads into your network via an external source, whereas with C2, infected
endpoints typically aempt to connect to a remote server to retrieve addional instrucons or
other malicious content.
• Newly Registered Domains—Newly registered domains are new, never registered domains, that
have been recently added by a TLD operator or enty. While new domains can be created for
legimate purposes, the vast majority are oen used to facilitate malicious acvies, such as
operang as C2 servers or used to distribute malware, spam, PUP/adware. Palo Alto Networks
detects newly registered domains by monitoring specific feeds (domain registries and registrars)
and using zone files, passive DNS, WHOIS data to detect registraon campaigns.
• Phishing Domains—Phishing domains aempt to lure users into subming sensive data, such
as personal informaon or user credenals, by masquerading as legimate websites through
phishing or pharming. These malicious acvies can be conducted through social engineering
campaigns (whereby a seemingly trusted source manipulates users into subming personal
informaon via email or other forms of electronic communicaons) or through web traffic
redirecon, which directs users to fraudulent sites that appear legimate.
• Grayware Domains—(Available with installaon of PAN-OS content release 8290 and later).
Grayware domains generally do not pose a direct security threat, however, they can facilitate
vectors of aack, produce various undesirable behaviors, or might simply contain quesonable/
offensive content.These can include websites and domains that:
• Aempt to trick users into granng remote access.
• Contain adware and other unsolicited applicaons (such as cryptominers, hijackers, and
PUPs [potenally unwanted programs]).
• Deploy domain idenficaon concealment acons using fast flux techniques.
• Demonstrate malicious behavior and usage as evidenced through DNS security predicave
analycs (malicious NRD).
• Take advantage of user errors when entering web page addresses (typosquang domains).
• Redirect traffic from a legimate source to a malicious website due to an improperly
configured or stale DNS record on an authoritave DNS server that has not been removed
or otherwise corrected (dangling DNS).
• Promote illegal acvies or scams.
• Include wildcard DNS entries, which can be used to evade block lists or enable wildcard
DNS aacks by roung traffic to malicious websites.
• Indicate the presence of DNS traffic with anomalous characteriscs when compared to
established baseline profiles built from collected DNS data.
• Parked Domains—(Available with installaon of PAN-OS content release 8318 and later)
Parked domains are typically inacve websites that host limited content, oen in the form of
click-through ads which may generate revenue for the host enty, but generally do not contain
content that is useful to the end user. While they oen funcon as a legimate placeholder
or as nothing more than a benign nuisance, they could also be used as a possible vector for
distribuon of malware.
• Proxy Avoidance and Anonymizers—(Available with installaon of PAN-OS content release
8340 and later) Proxy Avoidance and Anonymizers is traffic to services that are used to bypass
Threat Prevenon
content filtering policies. Users who aempt to circumvent an organizaon’s content filtering
policies via anonymizer proxy services are blocked at the DNS level.
Enable DNS Security

To enable DNS sinkholing for domain queries using DNS security, you must acvate your DNS
Security subscripon, create (or modify) an An-Spyware policy to reference the DNS Security
service, configure the log severity and policy sengs for each DNS signature category, and then
aach the profile to a security policy rule.
STEP 1 | Acvate Subscripon Licenses.
STEP 2 | Verify that the paloalto-dns-security App-ID in your security policy is configured to enable
traffic from the DNS security cloud security service.
If your firewall deployment routes your management traffic though an Internet-

facing perimeter firewall configured to enforce App-ID security policies, you must
allow the App-IDs on the perimeter firewall; failure to do so will prevent DNS security
connecvity.
Threat Prevenon
STEP 3 | Configure DNS Security signature policy sengs to send malware DNS queries to the
defined sinkhole.
If you use an external dynamic list as a domain allow list, it does not have precedence
over the DNS Security domain policy acons. As a result, when there is a domain
match to an entry in the EDL and a DNS Security domain category, the acon specified
under DNS Security is sll applied, even when the EDL is explicitly configured with an
acon of Allow. If you want to add DNS domain excepons, either configure an EDL
with an Alert acon or add them to the DNS Domain/FQDN Allow List located in the
DNS Excepons tab (step 8).
1. Select Objects > Security Profiles > An-Spyware.

2. Create or modify an exisng profile, or select one of the exisng default profiles and
clone it.
3. Name the profile and, oponally, provide a descripon.
4. Select the DNS Policies tab.
5. In the Signature Source column, beneath the DNS Security heading, there are
individually configurable DNS signature sources, which allow you to define separate
policy acons as well as a log severity level.
Palo Alto Networks recommends changing your default DNS Policies sengs for
signature sources to ensure opmum coverage as well as to assist with incidence
response and remediaon. Follow the best pracces for configuring your DNS
Security sengs as outlined in Best Pracces for Securing Your Network from
Layer 4 and Layer 7 Evasions.
• Specify the log severity level that is recorded when the firewall detects a domain
matching a DNS signature. For more informaon about the various log severity levels,
refer to Threat Severity Levels.
• Select an acon to be taken when DNS lookups are made to known malware sites for
the DNS Security signature source. The opons are alert, allow, block, or sinkhole.
Verify that the acon is set to sinkhole.
• In the Packet Capture drop-down, select single-packet to capture the first packet of
the session or extended-capture to set between 1-50 packets. You can then use the
packet captures for further analysis.
6. In the DNS Sinkhole Sengs secon, verify that Sinkhole is enabled. For your
convenience, the default Sinkhole address (sinkhole.paloaltonetworks.com) is set to
Threat Prevenon
access a Palo Alto Networks server. Palo Alto Networks can automacally refresh this
address through content updates.
If you want to modify the Sinkhole IPv4 or Sinkhole IPv6 address to a local server on
your network or to a loopback address, see Configure the Sinkhole IP Address to a Local
Server on Your Network.
7. Click OK to save the An-Spyware profile.
STEP 4 | Aach the An-Spyware profile to a Security policy rule.

1. Select Policies > Security.
2. Select or create a Security Policy Rule.
3. On the Acons tab, select the Log at Session End check box to enable logging.
4. In the Profile Seng secon, click the Profile Type drop-down to view all Profiles. From
the An-Spyware drop-down and select the new or modified profile.
5. Click OK to save the policy rule.
Threat Prevenon
STEP 5 | Test that the policy acon is enforced.

1. Access the following test domains to verify that the policy acon for a given threat type
is being enforced:
• C2—test-c2.testpanw.com
• DNS Tunneling—test-dnstun.testpanw.com
• DGA—test-dga.testpanw.com
• Dynamic DNS—test-ddns.testpanw.com
• Malware—test-malware.testpanw.com
• Newly Registered Domains—test-nrd.testpanw.com
• Phishing—test-phishing.testpanw.com
• Grayware—test-grayware.testpanw.com
• Parked—test-parked.testpanw.com
• Proxy Avoidance and Anonymizers—test-proxy.testpanw.com
2. To monitor the acvity on the firewall:
1. Select ACC and add a URL Domain as a global filter to view the Threat Acvity and
Blocked Acvity for the domain you accessed.
2. Select Monitor > Logs > Threat and filter by (action eq sinkhole) to view logs
on sinkholed domains.
STEP 6 | Idenfy Infected Traffic Hosts in the Traffic Logs
Threat Prevenon
STEP 7 | (Oponal) Add domain signature excepons in cases where false-posives occur.
2. Select a profile to modify.
3. Add or modify the An-Spyware profile from which you want to exclude the threat
signature, and select DNS Excepons.
4. Search for a DNS signature to exclude by entering the name or FQDN.
5. Select the checkbox for each Threat ID of the DNS signature that you want to exclude
from enforcement.
6. Click OK to save your new or modified An-Spyware profile.
STEP 8 | (Oponal) Add an allow list to specify a list of DNS domains / FQDNs to be explicitly
allowed.
2. Select a profile to modify.
4. To Add a new FQDN Allow List, provide the DNS domain or FQDN locaon and a
descripon.
Threat Prevenon
STEP 9 | (Oponal) Verify your firewall’s connecvity to the DNS Security service. If you
cannot reach the service, verify that the following domain is not being blocked:
dns.service.paloaltonetworks.com.
Use the following CLI command on the firewall to verify your firewall’s connecon availability
to the DNS Security service.
show dns-proxy dns-signature info
For example:
show dns-proxy dns-signture info
Cloud URL: dns.service.paloaltonetworks.com:443
Telemetry URL: io.dns.service.paloaltonetworks.com:443
Last Result: None
Last Server Address:
Parameter Exchange: Interval 300 sec
Allow List Refresh: Interval 43200 sec
Request Waiting Transmission: 0
Request Pending Response: 0
Cache Size: 0
STEP 10 | (Oponal) Retrieve a specified domain’s transacon details, such as latency, TTL, and the
signature category.
Use the following CLI command on the firewall to review the details about the list.
test dns-proxy dns-signature fqdn
For example:
test dns-proxy dns-signature fqdn www.yahoo.com
DNS Signature Query [ www.yahoo.com ]
Completed in 178 ms
DNS Signature Response
Entries: 2
Domain Category GTID

TTL
Threat Prevenon
-----------------------------------------------------------------------------
*.yahoo.com Benign 0
86400
www.yahoo.com Benign 0
3600
STEP 11 | (Oponal) Configure the DNS signature lookup meout seng. If the firewall is unable
to retrieve a signature verdict in the alloed me due to connecvity issues, the request,
including all subsequent DNS responses, are passed through. You can check the average
latency to verify that the requests fall within the configured period. If the average latency
exceeds the configured period, consider updang the seng to a value that is higher than
the average latency to prevent requests from ming out.
1. In the CLI, issue the following command to view the average latency.
show dns-proxy dns-signature

counters
The default meout is 100 milliseconds.

2. Scroll down through the output to the latency secon under the Signature query API
heading and verify that the average latency falls within the defined meout period. This
latency indicates the amount of me it takes, on average, to retrieve a signature verdict
from the DNS security service. Addional latency stascs for various latency periods
can be found below the averages.
Signature query API:

.
.
.
[latency ] :
max 1870 (ms) min 16(ms) avg 27(ms)
50 or less : 47246
100 or less : 113
200 or less : 25
400 or less : 15
else : 21
3. If the average latency is consistency above the default meout value, you can raise the
seng so that the requests fall within a given period. Select Device > Content-ID and
update the Realme Signature Lookup seng.
To view sinkholed DNS queries, refer to the firewall threat logs (Monitor > Logs, then select the
log type from the list):
Threat Prevenon
DNS Security Data Collecon and Logging

The DNS Security service collects server response and request informaon based on your firewall
security policy rules, associated acon, and the DNS query details when performing domain
lookups. The firewall forwards supplemental DNS data to the DNS Security cloud servers and
is used by Palo Alto Networks services to provide more accurate domain informaon (such as
provider ASN, hosng informaon, and geolocaon idenficaon). While this supplemental data is
not necessary to operate the DNS Security service, it provides the resources to generate improved
analycs, DNS detecon, and prevenon capabilies. This acon occurs in less than 30 seconds
aer collecon and batching does not impact firewall performance. In cases where the firewall
is experiencing a high load, DNS data collecon scales down as needed to maintain expected
performance levels.
The firewall can submit the following data fields:
Field Descripon
Acon Displays the policy acon taken on the DNS query.
Type Displays the DNS record type.
Response The IP address that the domain in the DNS query got resolved to.
Response Code The DNS response code that was received as an answer to your DNS
query.
Source IP The IP address of the system that made the DNS request.
Source User When the firewall User-ID feature is enabled, the identy of the DNS
requester is shown.
Source Zone The configured source zone referenced in your security policy rule.
DNS expanded data collecon is bypassed for domains added to the Allow list in DNS
Excepons.
Data fields that can be used to potenally idenfy users (Source IP, Source User, and Source
Zone) can be withheld from automac submission using the following CLI command: set
Threat Prevenon
deviceconfig setting ctd cloud-dns-privacy-mask yes. You must commit the

changes for the update to take effect.
Threat Prevenon
Use DNS Queries to Idenfy Infected Hosts on the

Network
The DNS sinkhole acon in An-Spyware profiles enables the firewall to forge a response to
a DNS query for a known malicious domain or to a custom domain, so that you can idenfy
hosts on your network that have been infected with malware. A compromised host might iniate
communicaon with a command-and-control (C2) server—once the connecon is made, an
aacker can remotely control the infected host, in order to further infiltrate the network or
exfiltrate data.
DNS queries to any domain included in the Palo Alto Networks DNS signatures list is sinkholed to
a Palo Alto Networks server IP address.
The firewall has two sources of DNS signatures that it can use to idenfy malicious and C2
domains:
• (Requires Threat Prevenon) Local DNS signatures—This is a limited, on-box set of DNS
signatures that the firewall can use to idenfy malicious domains. The firewall gets new DNS
signatures as part of daily anvirus updates.
• (Requires DNS Security) DNS Security signatures—The firewall accesses the Palo Alto Networks
DNS Security cloud service to check for malicious domains against the complete database of
DNS signatures. Certain signatures—that only DNS Security provides—can uniquely detect C2
aacks that use machine learning techniques, like domain generaon algorithms (DGAs) and
DNS tunneling.
DNS queries to domains in the local DNS signature set or the DNS Security signature set are
redirected to a Palo Alto Networks server, and the host is unable to access the malicious domain.
The following topics provide details on how to enable DNS sinkholing so that you can idenfy
infected hosts.
• Learn How DNS Sinkholing Works.
• Configure DNS Sinkholing.
• Configure DNS Sinkholing for a List of Custom Domains.
• Enable DNS Security to sinkhole C2 domains.
• Configurethe Sinkhole IPAddress to a Local Server on Your Network.
• See Infected Hosts that Aempted to Connect to a Malicious Domain.
How DNS Sinkholing Works

DNS sinkholing helps you to idenfy infected hosts on the protected network using DNS traffic
in situaons where the firewall cannot see the infected client's DNS query (that is, the firewall
cannot see the originator of the DNS query). In a typical deployment where the firewall is north
of the local DNS server, the threat log will idenfy the local DNS resolver as the source of the
traffic rather than the actual infected host. Sinkholing malware DNS queries solves this visibility
problem by forging responses to the client host queries directed at malicious domains, so that
clients aempng to connect to malicious domains (for command-and-control, for example) will
instead aempt to connect to a default Palo Alto Networks sinkhole IP address (or to IP address
Threat Prevenon
that you define if you choose to Configure DNS Sinkholing for a List of Custom Domains). Infected
hosts can then be easily idenfied in the traffic logs.
Configure DNS Sinkholing

To enable DNS sinkholing, aach the default An-Spyware profile to a security policy rule
(see Set Up Anvirus, An-Spyware, and Vulnerability Protecon). DNS queries to any domain
included in the Palo Alto Networks DNS signature source that you specify are resolved to
the default Palo Alto Networks sinkhole IP address. The IP addresses currently are IPv4—
sinkhole.paloaltonetworks.com and a loopback address IPv6 address—::1. These address are
subject to change and can be updated with content updates.
STEP 1 | Enable DNS sinkholing for the custom list of domains in an external dynamic list.
2. Modify an exisng profile, or select one of the exisng default profiles and clone it.
3. Name the profile and select the DNS Policies tab.
4. Verify that default-paloalto-dns is present in the Signature Source.
5. (Oponal) In the Packet Capture drop-down, select single-packet to capture the first
packet of the session or extended-capture to set between 1-50 packets. You can then
use the packet captures for further analysis.
Threat Prevenon
STEP 2 | Verify the sinkholing sengs on the An-Spyware profile.

1. On the DNS Policies tab, verify that the Policy Acon on DNS queries is sinkhole.
2. In the DNS Sinkhole Sengs secon, verify that Sinkhole is enabled. For your
convenience, the default Sinkhole IP address is set to access a Palo Alto Networks server.
Palo Alto Networks can automacally refresh this IP address through content updates.

1. Select Policies > Security and select a security policy rule.
2. On the Acons tab, select the Log at Session Start check box to enable logging.
the An-Spyware drop-down and select the new profile.
STEP 4 | Test that the policy acon is enforced by monitoring the acvity on the firewall.
2. Select Monitor > Logs > Threat and filter by (action eq sinkhole) to view logs on
sinkholed domains.
Configure DNS Sinkholing for a List of Custom Domains

To enable DNS Sinkholing for a custom list of domains, you must create an External Dynamic List
that includes the domains, enable the sinkhole acon in an An-Spyware profile and aach the
profile to a security policy rule. When a client aempts to access a malicious domain in the list, the
firewall forges the desnaon IP address in the packet to the default Palo Alto Networks server or
to a user-defined IP address for sinkholing.
For each custom domain included in the external dynamic list, the firewall generates DNS-based
spyware signatures. The signature is named Custom Malicious DNS Query <domain name>, and is
of type spyware with medium severity; each signature is a 24-byte hash of the domain name.
Each firewall model supports a maximum of 50,000 domain names total in one or more external
dynamic lists but no maximum limit is enforced for any one list.
Threat Prevenon
STEP 1 | Enable DNS sinkholing for the custom list of domains in an external dynamic list.
2. Modify an exisng profile, or select one of the exisng default profiles and clone it.
3. Name the profile and select the DNS Policies tab.
4. Select an EDL from the External Dynamic Lists signature source.
If you have already created an external dynamic list of type: Domain List, you
can select it from here. The list does not display external dynamic lists of type
URL or IP Address that you may have created.
5. Configure the external dynamic list from the An-Spyware profile (see Configure the
Firewall to Access an External Dynamic List). The Type is preset to Domain List.
6. (Oponal) In the Packet Capture drop-down, select single-packet to capture the first
packet of the session or extended-capture to set between 1-50 packets. You can then
use the packet captures for further analysis.
STEP 2 | Verify the sinkholing sengs on the An-Spyware profile.

1. On the DNS Policies tab, verify that the Policy Acon on DNS queries is sinkhole.
2. In the DNS Sinkhole Sengs secon, verify that Sinkhole is enabled. For your
convenience, the default Sinkhole IP address is set to access a Palo Alto Networks server.
Palo Alto Networks can automacally refresh this IP address through content updates.

1. Select Policies > Security and select a security policy rule.
2. On the Acons tab, select the Log at Session Start check box to enable logging.
the An-Spyware drop-down and select the new profile.
Threat Prevenon

1. View External Dynamic List Entries that belong to the domain list, and access a domain
from the list.
2. Select Monitor > Logs > Threat and filter by (action eq sinkhole) to view logs
on sinkholed domains.
STEP 5 | Verify whether entries in the external dynamic list are ignored or skipped.
Use the following CLI command on the firewall to review the details about the list.
request system external-list show type domain name <list_name>
For example:
request system external-list show type domain name

My_List_of_Domains_2015
vsys1/EBLDomain:
Next update at : Thu May 21 10:15:39 2015
Source : https://1.2.3.4/My_List_of_Domains_2015
Referenced : Yes
Valid : Yes
Number of entries : 3
domains:www.example.com
baddomain.com
qqq.abcedfg.com
STEP 6 | (Oponal) Retrieve the external dynamic list on-demand.

To force the firewall to retrieve the updated list on-demand instead of at the next refresh
interval (the Repeat frequency you defined for the external dynamic list), use the following CLI
command:
request system external-list refresh type domain name <list_name>
As an alternave, you can use the firewall interface to Retrieve an External Dynamic
List from the Web Server.
Configure the Sinkhole IP Address to a Local Server on Your

Network
By default, sinkholing is enabled for all Palo Alto Networks DNS signatures, and the sinkhole IP
address is set to access a Palo Alto Networks server. Use the instrucons in this secon if you
want to set the sinkhole IP address to a local server on your network.
You must obtain both an IPv4 and IPv6 address to use as the sinkhole IP addresses because
malicious soware may perform DNS queries using one or both of these protocols. The DNS
Threat Prevenon
sinkhole address must be in a different zone than the client hosts to ensure that when an infected
host aempts to start a session with the sinkhole IP address, it will be routed through the firewall.
The sinkhole addresses must be reserved for this purpose and do not need to be assigned
to a physical host. You can oponally use a honey-pot server as a physical host to further
analyze the malicious traffic.
The configuraon steps that follow use the following example DNS sinkhole addresses:
IPv4 DNS sinkhole address—10.15.0.20
IPv6 DNS sinkhole address—fd97:3dec:4d27:e37c:5:5:5:5
STEP 1 | Configure the sinkhole interface and zone.

Traffic from the zone where the client hosts reside must route to the zone where the sinkhole
IP address is defined, so traffic will be logged.
Use a dedicated zone for sinkhole traffic, because the infected host will be sending
traffic to this zone.
1. Select Network > Interfaces and select an interface to configure as your sinkhole
interface.
2. In the Interface Type drop-down, select Layer3.
3. To add an IPv4 address, select the IPv4 tab and select Stac and then click Add. In this
example, add 10.15.0.20 as the IPv4 DNS sinkhole address.
4. Select the IPv6 tab and click Stac and then click Add and enter an IPv6 address and
subnet mask. In this example, enter fd97:3dec:4d27:e37c::/64 as the IPv6 sinkhole
address.
5. Click OK to save.
6. To add a zone for the sinkhole, select Network > Zones and click Add.
7. Enter zone Name.
8. In the Type drop-down select Layer3.
9. In the Interfaces secon, click Add and add the interface you just configured.
10. Click OK.
STEP 2 | Enable DNS sinkholing.

By default, sinkholing is enabled for all Palo Alto Networks DNS signatures. To change the
sinkhole address to your local server, see Step Verify the sinkholing sengs on the An-
Spyware profile. in Configure DNS Sinkholing for a List of Custom Domains.
STEP 3 | Edit the security policy rule that allows traffic from client hosts in the trust zone to the
untrust zone to include the sinkhole zone as a desnaon and aach the An-Spyware
profile.
Eding the Security policy rule(s) that allows traffic from client hosts in the trust zone to
the untrust zone ensures that you are idenfying traffic from infected hosts. By adding the
Threat Prevenon
sinkhole zone as a desnaon on the rule, you enable infected clients to send bogus DNS
queries to the DNS sinkhole.
2. Select an exisng rule that allows traffic from the client host zone to the untrust zone.
3. On the Desnaon tab, Add the Sinkhole zone. This allows client host traffic to flow to
the sinkhole zone.
4. On the Acons tab, select the Log at Session Start check box to enable logging. This will
ensure that traffic from client hosts in the Trust zone will be logged when accessing the
Untrust or Sinkhole zones.
5. In the Profile Seng secon, select the An-Spyware profile in which you enabled DNS
sinkholing.
6. Click OK to save the Security policy rule and then Commit.
STEP 4 | To confirm that you will be able to idenfy infected hosts, verify that traffic going from the
client host in the Trust zone to the new Sinkhole zone is being logged.
In this example, the infected client host is 192.168.2.10 and the Sinkhole IPv4 address is
10.15.0.20.
1. From a client host in the trust zone, open a command prompt and run the following
command:
C:\>ping <sinkhole address>
The following example output shows the ping request to the DNS sinkhole address at
10.15.0.2 and the result, which is Request timed out because in this example the
sinkhole IP address is not assigned to a physical host:
C:\>ping 10.15.0.20
Pinging 10.15.0.20 with 32 bytes of data:
Request timed out.
Request timed out.
Ping statistics for 10.15.0.20:
Packets: Sent = 4, Received = 0, Lost = 4 (100% loss)
2. On the firewall, select Monitor > Logs > Traffic and find the log entry with the Source
192.168.2.10 and Desnaon 10.15.0.20. This will confirm that the traffic to the
sinkhole IP address is traversing the firewall zones.
You can search and/or filter the logs and only show logs with the desnaon
10.15.0.20. To do this, click the IP address (10.15.0.20) in the Desnaon
column, which will add the filter (addr.dst in 10.15.0.20) to the search field. Click
the Apply Filter icon to the right of the search field to apply the filter.
Threat Prevenon
STEP 5 | Test that DNS sinkholing is configured properly.

You are simulang the acon that an infected client host would perform when a malicious
applicaon aempts to call home.
1. Find a malicious domain that is included in the firewall’s current Anvirus signature
database to test sinkholing.
1. Select Device > Dynamic Updates and in the Anvirus secon click the Release
Notes link for the currently installed anvirus database. You can also find the anvirus
release notes that list the incremental signature updates under Dynamic Updates on
the Palo Alto Networks support site.
2. In the second column of the release note, locate a line item with a domain extension
(for example, .com, .edu, or .net). The le column will display the domain name. For
example, Anvirus release 1117-1560, includes an item in the le column named
"tbsbana" and the right column lists "net".
The following shows the content in the release note for this line item:
conficker:tbsbana 1
variants: net
2. From the client host, open a command prompt.

3. Perform an NSLOOKUP to a URL that you idenfied as a known malicious domain.
For example, using the URL track.bidtrk.com:
C:\>nslookup
track.bidtrk.com
Server: my-local-dns.local
Address: 10.0.0.222
Non-authoritative answer:
Name: track.bidtrk.com.org
Addresses: fd97:3dec:4d27:e37c:5:5:5:510.15.0.20
In the output, note that the NSLOOKUP to the malicious domain has been forged using
the sinkhole IP addresses that we configured (10.15.0.20). Because the domain matched
a malicious DNS signature, the sinkhole acon was performed.
4. Select Monitor > Logs > Threat and locate the corresponding threat log entry to verify
that the correct acon was taken on the NSLOOKUP request.
5. Perform a ping to track.bidtrk.com, which will generate network traffic to the
sinkhole address.
See Infected Hosts that Aempted to Connect to a Malicious

Domain
Aer you have configured DNS sinkholing and verified that traffic to a malicious domain goes to
the sinkhole address, you should regularly monitor traffic to the sinkhole address, so that you can
track down the infected hosts and eliminate the threat.
Threat Prevenon
Use App Scope to idenfy infected client hosts.

1. Select Monitor > App Scope and select Threat Monitor.
2. Click the Show spyware buon along the top of the display page.
3. Select a me range.
The following screenshot shows three instances of Suspicious DNS queries, which were
generated when the test client host performed an NSLOOKUP on a known malicious
domain. Click the graph to see more details about the event.
Configure a custom report to idenfy all client hosts that have sent traffic to the sinkhole IP
address, which is 10.15.0.20 in this example.
Forward to an SNMP manager, Syslog server and/or Panorama to enable alerts on

these events.
In this example, the infected client host performed an NSLOOKUP to a known malicious
domain that is listed in the Palo Alto Networks DNS Signature database. When this occurred,
the query was sent to the local DNS server, which then forwarded the request through
the firewall to an external DNS server. The firewall security policy with the An-Spyware
profile configured matched the query to the DNS Signature database, which then forged the
reply using the sinkhole address of 10.15.0.20 and fd97:3dec:4d27:e37c:5:5:5:5. The client
aempts to start a session and the traffic log records the acvity with the source host and the
desnaon address, which is now directed to the forged sinkhole address.
Viewing the traffic log on the firewall allows you to idenfy any client host that is sending
traffic to the sinkhole address. In this example, the logs show that the source address
192.168.2.10 sent the malicious DNS query. The host can then be found and cleaned. Without
the DNS sinkhole opon, the administrator would only see the local DNS server as the system
that performed the query and would not see the client host that is infected. If you aempted
Threat Prevenon
to run a report on the threat log using the acon “Sinkhole”, the log would show the local DNS
server, not the infected host.
1. Select Monitor > Manage Custom Reports.
2. Click Add and Name the report.
3. Define a custom report that captures traffic to the sinkhole address as follows:
• Database—Select Traffic Log.
• Scheduled—Enable Scheduled and the report will run every night.
• Time Frame—30 days
• Selected Columns—Select Source address or Source User (if you have User-ID
configured), which will idenfy the infected client host in the report, and Desnaon
address, which will be the sinkhole address.
• In the secon at the boom of the screen, create a custom query for traffic to the
sinkhole address (10.15.0.20 in this example). You can either enter the desnaon
address in the Query Builder window (addr.dst in 10.15.0.20) or select the following
Threat Prevenon
in each column and click Add: Connector = and, Aribute = Desnaon Address,
Operator = in, and Value = 10.15.0.20. Click Add to add the query.
4. Click Run Now to run the report. The report will show all client hosts that have sent
traffic to the sinkhole address, which indicates that they are most likely infected. You can
now track down the hosts and check them for spyware.
5. To view scheduled reports that have run, select Monitor > Reports.
Threat Prevenon
Data Filtering
Use Data Filtering Profiles to prevent sensive, confidenal, and proprietary informaon from
leaving your network. Predefined paerns, built-in sengs, and customizable opons make it easy
for you to protect files that contain certain file properes (such as a document tle or author),
credit card numbers, regulated informaon from different countries (like social security numbers),
and third-party data loss prevenon (DLP) labels.
• Predefined Data Paerns—Easily filter common paerns, including credit card numbers.
Predefined data filtering paerns also idenfy specific (regulated) informaon from different
countries of the world, such as social security numbers (United States), INSEE Idenficaon
numbers (France), and New Zealand Internal Revenue Department Idenficaon Numbers.
Many of the predefined data filtering paerns enable compliance for standards such as HIPAA,
GDPR, Gramm-Leach-Bliley Act.
• Built-In Support for Azure Informaon Protecon and Titus Data Classificaon—Predefined
file properes allow you to filter content based on Azure Informaon Protecon and Titus
labels. Azure Informaon Protecon labels are stored in metadata, so make sure that you know
the GUID of the Azure Informaon Protect label that you want the firewall to filter.
• Custom Data Paerns for Data Loss Prevenon (DLP) Soluons—If you’re using a third-party,
endpoint DLP soluon that populates file properes to indicate sensive content, you can
create a custom data paern to idenfy the file properes and values tagged by your DLP
soluon and then log or block the files that your Data Filtering profile detects based on that
paern.
Create a Data Filtering Profile

Data Filtering profiles can keep sensive informaon from leaving your network.
To get started, you’ll first create a data paern that specifies the informaon types and fields
that you want the firewall to filter. Then, you aach that paern to a data filtering profile, which
specifies how you want to enforce the content that the firewall filters. Add the data filtering
profile to a security policy rule to start filtering traffic matching the rule.
STEP 1 | Define a new data paern object to detect the informaon you want to filter.
1. Select Objects > Custom Objects > Data Paerns and Add a new object.
2. Provide a descripve Name for the new object.
3. (Oponal) Select Shared if you want the data paern to be available to:
• Every virtual system (vsys) on a mul-vsys firewall—If cleared (disabled), the data
paern is available only to the Virtual System selected in the Objects tab.
• Every device group on Panorama—If cleared (disabled), the data paern is available
only to the Device Group selected in the Objects tab.
4. (Oponal—Panorama only) Select Disable override to prevent administrators from
overriding the sengs of this data paern object in device groups that inherit the object.
Threat Prevenon
This selecon is cleared by default, which means administrators can override the sengs
for any device group that inherits the object.
5. (Oponal—Panorama only) Select Data Capture to automacally collect the data that is
blocked by the filter.
Specify a password for Manage Data Protecon on the Sengs page to view
your captured data (Device > Setup > Content-ID > Manage Data Protecon).
6. Set the Paern Type to one of the following:
• Predefined Paern—Filter for credit card, social security numbers, and personally
idenfiable informaon for several compliance standards including HIPAA, GDPR,
Gramm-Leach-Bliley Act.
• Regular Expression—Filter for custom data paerns.
• File Properes—Filter based on file properes and the associated values.
7. Add a new rule to the data paern object.
8. Specify the data paern according to the Paern Type you selected for this object:
• Predefined—Select the Name and choose the predefined data paern on which to
filter.
• Regular Expression—Specify a descripve Name, select the File Type (or types) you
want to scan, and then enter the specific Data Paern you want the firewall to detect.
• File Properes—Specify a descripve Name, select the File Type and File Property
you want to scan, and enter the specific Property Value that you want the firewall to
detect.
• To filter Titus classified documents: Select one of the non-AIP protected file
types, and set the File Property to TITUS GUID. Enter the Titus label GUID as the
Property Value.
• For Azure Informaon Protecon labeled documents: Select any File Type except
Rich Text Format. For the file type you choose, set the File Property to Microso
MIP Label, and enter the Azure Informan Protect label GUID as the Property
Value.
9. Click OK to save the data paern.
Threat Prevenon
STEP 2 | Add the data paern object to a data filtering profile.

1. Select Objects > Security Profiles > Data Filtering and Add or modify a data filtering
profile.
2. Provide a descripve Name for the new profile.
3. Add a new profile rule and select the Data Paern you created in Step .
4. Specify Applicaons, File Types, and what Direcon of traffic (upload or download) you
want to filter based on the data paern.
The file type you select must be the same file type you defined for the data
paern earlier, or it must be a file type that includes the data paern file type.
For example, you could define both the data paern object and the data filtering
profile to scan all Microso Office documents. Or, you could define the data
paern object to match to only Microso PowerPoint Presentaons while the
data filtering profile scans all Microso Office documents.
If a data paern object is aached to a data filtering profile and the configured file types
do not align between the two, the profile will not correctly filter documents matched to
the data paern object.
5. Set the Alert Threshold to specify the number of mes the data paern must be
detected in a file to trigger an alert.
6. Set the Block Threshold to block files that contain at least this many instances of the
data paern.
7. Set the Log Severity recorded for files that match this rule.
8. Click OK to save the data filtering profile.
STEP 3 | Apply the data filtering sengs to traffic.

1. Select Policies > Security and Add or modify a security policy rule.
2. Select Acons and set the Profile Type to Profiles.
3. Aach the Data Filtering profile you created in Step 2 to the security policy rule.
4. Click OK.
STEP 4 | (Recommended) Prevent web browsers from resuming sessions that the firewall has
terminated.
This opon ensures that when the firewall detects and then drops a sensive file, a web
browser cannot resume the session in an aempt to retrieve the file.
1. Select Device > Setup > Content-ID and edit Content-ID Sengs.
2. Clear the Allow HTTP paral response.
3. Click OK.
STEP 5 | Monitor files that the firewall is filtering.

Select Monitor > Data Filtering to view the files that the firewall has detected and blocked
based on your data filtering sengs.
Threat Prevenon
Predefined Data Filtering Paerns

To comply with standards such as HIPAA, GDPR, and the Gramm-Leach-Bliley Act, the firewall
provides predefined data paerns. You can use these paerns to prevent common types of
sensive informaon, like credit cards and social security numbers, from leaving your network.
You can find predefined data paerns by selecng Objects > Custom Objects > Data Paerns and
clicking Add a new object. Then, set the Paern Type to Predefined Paern and Add a new rule
to the data paern object. Select a data paern from the list that appears under Name.
If the type of informaon you want to protect is not covered in the list of predefined
paerns, you can use regular expressions to create custom paerns.
The following is a list of available data paerns:
Paern Descripon
Credit Card Numbers 16-digit credit card numbers
Social Security Numbers 9-digit social security numbers with dashes
Social Security Numbers (without dash 9-digit social security numbers without dashes
separator)
ABA Roung Number The American Banking Associaon Roung

Number
AHV Idenficaon Number Swiss Alters und

Hinterlassenenversicherungsnummer
Threat Prevenon
Codice Fiscale Idenficaon Number Italian Fiscal Tax Code Card Idenficaon
Number
CorporateNumber Idenficaon Number Japanese Naonal Tax Agency Corporate

Number
CUSIP Idenficaon Number Commiee on Uniform Security Idenficaon

Procedures Idenficaon Number
DEA Registraon Number U.S. Drug Enforcement Administraon

Registraon Number
DNI Idenficaon Number Spanish Documento nacional de idendad

Idenficaon Number number
HK Idenficaon Number Hong Kong Residents Idenficaon Number
INSEE Idenficaon Number French Naonal Instute of Stascs and

Economic Studies idenficaon number
IRD Idenficaon Number New Zealand Internal Revenue Department

Idenficaon Number
MyKad Idenficaon Number Malaysia MyKad Identy Card Idenficaon

Number
MyNumber Idenficaon Number Japanese Social Security and Tax Number

System Idenficaon Number
NHI Idenficaon Number New Zealand Naonal Health Index Number
NIF Idenficaon Number Spanish Tax Idenficaon Number
NIN Idenficaon Number Taiwan Idenficaon Card Number
NRIC Idenficaon Number Singapore Naonal Registraon Identy Card

Permanent Account Idenficaon Number India Permanent Account Number of Indian

naonals
PRC Idenficaon Number People's Republic of China Resident

PRN Idenficaon Number Republic of South Korea Resident Registraon

Number
Threat Prevenon
Republic of South Korea Resident Registraon Republic of South Korea Resident Registraon
Number
Threat Prevenon
WildFire Inline ML
The WildFire inline ML opon present in the Anvirus profile enables the firewall dataplane to
apply machine learning on PowerShell scripts, PE (portable executable), and ELF (executable and
linked format) files in real-me. This layer of anvirus protecon complements the WildFire-
based signatures to provide extended coverage for files of which signatures do not already exist.
Each inline ML model dynamically detects malicious files of a specific type by evaluang file
details, including decoder fields and paerns, to formulate a high probability classificaon of a
file. This protecon extends to currently unknown as well as future variants of threats that match
characteriscs that Palo Alto Networks has idenfied as malicious. To keep up with the latest
changes in the threat landscape, inline ML models are added or updated via content releases.
Before you can enable WildFire inline ML, you must possess an acve WildFire subscripon.
Inline ML-based protecon can also be enabled to detect malicious URLs in real-me as part of
your URL Filtering configuraon. For more informaon, refer to: URL Filtering Inline ML
WildFire inline ML is not supported on the VM-50 or VM50L virtual appliance.
Configure WildFire Inline ML

To enable your WildFire inline ML configuraon, aach the Anvirus profile configured with the
inline ML sengs to a security policy rule (see Set Up Anvirus, An-Spyware, and Vulnerability
Protecon).
WildFire inline ML is not currently supported on the VM-50 or VM50L virtual appliance.
STEP 1 | To take advantage of WildFire inline ML, you must have an acve WildFire subscripon to
analyze Windows executables.
Verify that you have a WildFire subscripon. To verify which subscripons that you currently
have licenses for, select Device > Licenses and verify that the appropriate licenses display and
have not expired.
STEP 2 | Create a new or update your exisng Anvirus security profile(s) to use the real-me
WildFire inline ML models.
1. Select an exisng Anvirus Profile or create a new one (select Objects > Security Profiles >
Anvirus and Add a new profile.
2. Configure your Anvirus profile.
3. Select the WildFire Inline ML tab and apply an Acon Seng for each WildFire Inline ML
model. This enforces the WildFire Inline ML Acons sengs configured for each protocol
Threat Prevenon
on a per model basis. The following classificaon engines available: Windows Executables,
PowerShell Scripts 1, and PowerShell Scripts 2.
The following addional analysis models are available upon installaon of the
specified content update:
• Executable Linked Format with installaon of PAN-OS content release 8367 and
later.
• MSOffice (97-03) with installaon of PAN-OS content release 8434 and later.
• enable (inherit per-protocol acons)—WildFire inspects traffic according to your

selecons in the WildFire Inline ML Acon column in the decoders secon of the Acon
tab.
• alert-only (override more strict acons to alert)—WildFire inspects traffic according
to your selecons in the WildFire Inline ML Acon column in the decoders secon of
the Acon tab and overrides any acon with a severity level higher than alert (drop,
reset-client, reset-server, reset-both) alert, which allows traffic to pass
while sll generang and saving an alert in the threat logs.
• disable (for all protocols)—WildFire allows traffic to pass without any policy acon.
4. Click OK to exit the Anvirus Profile configuraon window and Commit your new sengs.
STEP 3 | (Oponal) Add file excepons to your Anvirus security profile if you encounter false-
posives. This is typically done for users who are not forwarding files to WildFire for analysis.
Threat Prevenon
You can add the file excepon details directly to the excepon list or by specifying a file from
the threat logs.
If your WildFire Analysis security profile is configured to forward the filetypes analyzed
using WildFire inline ML, false-posives are automacally corrected as they are
received. If you connue to see ml-virus alerts for files that have been classified as
benign by WildFire Analysis, please contact Palo Alto Networks Support.
• Add file excepons directly to the excepon list.

1. Select Objects > Security Profiles > Anvirus.
2. Select an Anvirus profile for which you want to exclude specific files and then select
WildFire Inline ML.
3. Add the hash, filename, and descripon of the file that you want to exclude from
enforcement.
4. Click OK to save the Anvirus profile and then Commit your updates.
• Add file excepons from threat logs entries.
1. Select Monitor > Logs > Threat and filter the logs for the ml-virus threat type. Select a
threat log for a file that you wish to create a file excepon for.
2. Go to the Detailed Log View and scroll down to the Details pane then select Create
Excepon.
3. Add a Descripon and click OK to add the file excepon.

4. The new file excepon can be found File Excepons list under Objects > Security
Profiles > Anvirus > WildFire Inline ML.
STEP 4 | (Oponal) Verify the status of your firewall’s connecvity to the Inline ML cloud service.
Use the following CLI command on the firewall to view the connecon status.
show mlav cloud-status
For example:
MLAV cloud
Current cloud server: ml.service.paloaltonetworks.com
Threat Prevenon
Cloud connection: connected
If you are unable to connect to the Inline ML cloud service, verify that the following domain is
not being blocked: ml.service.paloaltonetworks.com.
To view informaon about files that have been detected using WildFire Inline ML, examine the
threat logs (Monitor > Logs > Threat, then select the log type from the list). Files that have been
analyzed using WildFire inline ML are labeled with the threat type ml-virus:
Threat Prevenon
Set Up File Blocking

File Blocking Profiles allow you to idenfy specific file types that you want to want to block or
monitor. For most traffic (including traffic on your internal network), block files that are known to
carry threats or that have no real use case for upload/download. Currently, these include batch
files, DLLs, Java class files, help files, Windows shortcuts (.lnk), and BitTorrent files. Addionally,
to provide drive-by download protecon, allow download/upload of executables and archive
files (.zip and .rar), but force users to acknowledge that they are transferring a file so that they
noce that the browser is aempng to download something they were not aware of. For policy
rules that allow general web browsing, be stricter with your file blocking because the risk of users
unknowingly downloading malicious files is much higher. For this type of traffic, aach a more
strict file blocking profile that also blocks portable executable (PE) files.
You can define your own custom File Blocking profiles or choose one of the following predefined
profiles when applying file blocking to a Security policy rule. You can clone and edit the predefined
profiles, which are available with content release version 653 and later, and then follow File
Blocking profile safe transion steps to preserve applicaon availability as you transion to best
pracce file blocking sengs:
• basic file blocking—Aach this profile to the Security policy rules that allow traffic to and
from less sensive applicaons to block files that are commonly included in malware aack
campaigns or that have no real use case for upload/download. This profile blocks upload and
download of PE files ( .scr, .cpl, .dll, .ocx, .pif, .exe) , Java files (.class, .jar), Help files (.chm, .hlp)
and other potenally malicious file types, including .vbe, .hta, .wsf, .torrent, .7z, .rar, .bat.
Addionally, it prompts users to acknowledge when they aempt to download encrypted-rar or
encrypted-zip files. This rule alerts on all other file types to give you complete visibility into all
file types coming in and out of your network.
• strict file blocking—Use this stricter profile on the Security policy rules that allow access to
your most sensive applicaons. This profile blocks the same file types as the other profile, and
addionally blocks flash, .tar, mul-level encoding, .cab, .msi, encrypted-rar, and encrypted-zip
files.
These predefined profiles are designed to provide the most secure posture for your network.
However, if you have business-crical applicaons that rely on some of the applicaons that are
blocked in these default profiles, you can clone the profiles and modify them as necessary. Make
sure you only use the modified profiles for those users who need to upload and/or download a
risky file type. Addionally, to reduce your aack surface, make sure you are using other security
measures to ensure that the files your users are uploading and downloading do not pose a threat
to your organizaon. For example, if you must allow download of PE files, make sure you are
sending all unknown PE files to WildFire foranalysis. Addionally, maintain a strict URL filtering
policy to ensure that users cannot download content from web sites that have been known to
host malicious content.
Threat Prevenon
STEP 1 | Create the file blocking profile.

1. Select Objects > Security Profiles > File Blocking and Add a profile.
2. Enter a Name for the file blocking profile such as Block_EXE.
3. (Oponal) Enter a Descripon, such as Block users from downloading exe
files from websites.
4. (Oponal) Specify that the profile is Shared with:
• Every virtual system (vsys) on a mul-vsys firewall—If cleared (disabled), the profile is
available only to the Virtual System selected in the Objects tab.
• Every device group on Panorama—If cleared (disabled), the profile is available only to
the Device Group selected in the Objects tab.
overriding the sengs of this file blocking profile in device groups that inherit the profile.
This selecon is cleared by default, which means administrators can override the sengs
for any device group that inherits the profile.
STEP 2 | Configure the file blocking opons.

1. Add and define a rule for the profile.
2. Enter a Name for the rule, such as BlockEXE.
3. Select Any or specify one or more specific Applicaons for filtering, such as web-
browsing.
Only web browsers can display the response page (connue prompt) that allows
users to confirm their Choosing any other applicaon results in blocked traffic
for those applicaons because there is no prompt displayed to allow users to
connue.
4. Select Any or specify one or more specific File Types, such as exe.
5. Specify the Direcon, such as download.
6. Specify the Acon (alert, block, or connue). For example, select connue to prompt
users for confirmaon before they are allowed to download an executable (.exe) file.
Alternavely, you could block the specified files or you could configure the firewall to
simply trigger an alert when a user downloads an executable file.
STEP 3 | Apply the file blocking profile to a security policy rule.

1. Select Policies > Security and either select an exisng policy rule or Add a new rule as
described in Set Up a Basic Security Policy.
2. On the Acons tab, select the file blocking profile you configured in the previous step. In
this example, the profile name is Block_EXE.
3. Commit your configuraon.
STEP 4 | To test your file blocking configuraon, access an endpoint PC in the trust zone of the
firewall and aempt to download an executable file from a website in the untrust zone; a
response page should display. Click Connue to confirm that you can download the file. You
Threat Prevenon
can also set other acons, such as alert or block, which do not provide an opon for the user
to connue the download. The following shows the default response page for File Blocking:
STEP 5 | (Oponal) Define custom file blocking response pages (Device > Response Pages). This
allows you to provide more informaon to users when they see a response page. You can
include informaon such as company policy informaon and contact informaon for a
Helpdesk.
When you create a file blocking profile with the connue acon, you can choose only
the web-browsing applicaon. If you choose any other applicaon, traffic that matches
the security policy will not flow through the firewall because users are not prompted
with an opon to connue. Addionally, you need to configure and enable a decrypon
policy for HTTPS websites.
Check your logs to determine the applicaon used when you test this feature. For
example, if you are using Microso SharePoint to download files, even though you are
using a web-browser to access the site, the applicaon is actually sharepoint-
base, or sharepoint-document. (It can help to set the applicaon type to Any for
tesng.)
Threat Prevenon
Prevent Brute Force Aacks

A brute force aack uses a large volume of requests/responses from the same source or
desnaon IP address to break into a system. The aacker employs a trial-and-error method to
guess the response to a challenge or a request.
The Vulnerability Protecon profile on the firewall includes signatures to protect you from brute
force aacks. Each signature has an ID, Threat Name, and Severity and is triggered when a paern
is recorded. The paern specifies the condions and interval at which the traffic is idenfied as a
brute-force aack; some signatures are associated with another child signature that is of a lower
severity and specifies the paern to match against. When a paern matches against the signature
or child signature, it triggers the default acon for the signature.
To enforce protecon:
• Aach the Vulnerability Protecon profile to a Security policy rule. See Set Up Anvirus, An-
Spyware, and Vulnerability Protecon.
• Install content updates that include new signatures to protect against emerging threats. See
Install Content and Soware Updates.
Threat Prevenon
Customize the Acon and Trigger Condions for a Brute

Force Signature
The firewall includes two types of predefined brute force signatures—parent signatures and child
signatures. A child signature is a single occurrence of a traffic paern that matches the signature.
A parent signature is associated with a child signature and is triggered when mulple events occur
within a specified me interval and that matches the traffic paern defined in the child signature.
Typically, the default acon for a child signature is allow because a single event is not indicave
of an aack. This ensures that legimate traffic is not blocked and avoids generang threat logs
for non-noteworthy events. Palo Alto Networks recommends that you do not change the default
acon without careful consideraon.
In most cases, the brute force signature is a noteworthy event due to its recurrent paern. If
needed, you can do one of the following to customize the acon for a brute-force signature:
• Create a rule to modify the default acon for all signatures in the brute force category. You can
choose to allow, alert, block, reset, or drop the traffic.
• Define an excepon for a specific signature. For example, you can search for and define an
excepon for a CVE.
For a parent signature, you can modify both the trigger condions and the acon; for a child
signature, you can modify only the acon.
To effecvely migate an aack, specify the block-ip address acon instead of the drop or
reset acon for most brute force signatures.
STEP 1 | Create a new Vulnerability Protecon profile.

1. Select Objects > Security Profiles > Vulnerability Protecon and Add a profile.
2. Enter a Name for the Vulnerability Protecon profile.
4. (Oponal) Specify that the profile is Shared with:
• Every virtual system (vsys) on a mul-vsys firewall—If cleared (disabled), the profile is
available only to the Virtual System selected in the Objects tab.
• Every device group on Panorama—If cleared (disabled), the profile is available only to
the Device Group selected in the Objects tab.
overriding the sengs of this Vulnerability Protecon profile in device groups that inherit
the profile. This selecon is cleared by default, which means administrators can override
the sengs for any device group that inherits the profile.
Threat Prevenon
STEP 2 | Create a rule that defines the acon for all signatures in a category.
1. On the Rules tab, Add and enter a Rule Name for a new rule.
2. (Oponal) Specify a specific threat name (default is any).
3. Set the Acon. In this example, it is set to Block IP.
If you set a Vulnerability Protecon profile to Block IP, the firewall first uses
hardware to block IP addresses. If aack traffic exceeds the blocking capacity of
the hardware, the firewall then uses soware blocking mechanisms to block the
remaining IP addresses.
4. Set Category to brute-force.
5. (Oponal) If blocking, specify the Host Type on which to block: server or client (default is
any).
6. See Step 3 to customize the acon for a specific signature.
7. See Step 4 to customize the trigger threshold for a parent signature.
8. Click OK to save the rule and the profile.
Threat Prevenon
STEP 3 | (Oponal) Customize the acon for a specific signature.

1. On the Excepons tab, Show all signatures to find the signature you want to modify.
To view all the signatures in the brute-force category, search for category contains
'brute-force'.
2. To edit a specific signature, click the predefined default acon in the Acon column.
3. Set the acon: Allow, Alert, Block Ip, or Drop. If you select Block Ip, complete these
addional tasks:
1. Specify the Time period (in seconds) aer which to trigger the acon.
2. Specify whether to Track By and block the IP address using the IP source or the IP
source and desnaon.
4. Click OK.
5. For each modified signature, select the check box in the Enable column.
6. Click OK.
STEP 4 | Customize the trigger condions for a parent signature.

A parent signature that can be edited is marked with this icon: .
In this example, the search criteria was brute force category and CVE-2008-1447.
1. Edit ( ) the me aribute and the aggregaon criteria for the signature.
2. To modify the trigger threshold, specify the Number of Hits per number of seconds.
3. Specify whether to aggregate the number of hits (Aggregaon Criteria) by source,
desnaon, or source-and-desnaon.
4. Click OK.
Threat Prevenon
STEP 5 | Aach this new profile to a Security policy rule.

1. Select Policies > Security and Add or modify a Security policy rule.
2. On the Acons tab, select Profiles as the Profile Type for the Profile Seng.
3. Select your Vulnerability Protecon profile.
4. Click OK.

1. Click Commit.
Threat Prevenon
Enable Evasion Signatures

Palo Alto Networks evasion signatures detect craed HTTP or TLS requests, and can alert to
instances where a client connects to a domain other than the domain specified in a DNS query.
Evasion signatures are effecve only when the firewall is also enabled to act as a DNS proxy
and resolve domain name queries. As a best pracce, take the following steps to enable evasion
signatures.
STEP 1 | Enable a firewall intermediate to clients and servers to act as a DNS proxy.
Configure a DNS Proxy Object, including:
• Specify the interfaces on which you want the firewall to listen for DNS queries.
• Define the DNS servers with which the firewall communicates to resolve DNS requests.
• Set up stac FQDN-to-IP address entries that the firewall can resolve locally, without
reaching out to DNS servers.
• Enable caching for resolved hostname-to-IP-address mappings.
STEP 2 | Get the latest Applicaons and Threats content version (at least content version 579 or later).
2. Check Now to get the latest Applicaons and Threats content update.
3. Download and Install Applicaons and Threats content version 579 (or later).
STEP 3 | Define how the firewall should enforce traffic matched to evasion signatures.
1. Select Objects > Security Profiles > An-Spyware and Add or modify an An-spyware
profile.
2. Select Excepons and select Show all signatures.
3. Filter signatures based on the keyword evasion.
4. For all evasion signatures, set the Acon to any seng other than allow or the default
acon (the default acon is for evasion signatures is allow). For example, set the Acon
for signature IDs 14978 and 14984 to alert or drop.
5. Click OK to save the updated An-spyware profile.
6. Aach the An-spyware profile to a security policy rule: Select Policies > Security, select
the desired policy to modify and then click the Acons tab. In Profile Sengs, click the
drop-down next to An-Spyware and select the an-spyware profile you just modified to
enforce evasion signatures.

Click Commit.
Threat Prevenon
Monitor Blocked IP Addresses

The firewall maintains a block list of source IP addresses that it’s blocking. When the firewall
blocks a source IP address, such as when you configure either of the following policy rules, the
firewall blocks that traffic in hardware before those packets use CPU or packet buffer resources:
• A classified DoS Protecon policy rule with the acon to Protect (a classified DoS Protecon
policy specifies that incoming connecons match a source IP address, desnaon IP address,
or source and desnaon IP address pair, and is associated with a Classified DoS Protecon
profile, as described in DoS Protecon Against Flooding of New Sessions).
• A Security Policy rule that uses a Vulnerability Protecon profile
Hardware IP address blocking is supported on PA-3200 Series, PA-5200 Series, and PA-7000
Series firewalls.
You can view the block list, get detailed informaon about an IP address on the block list, or view
counts of addresses that hardware and soware are blocking. You can delete an IP address from
the list if you think it shouldn’t be blocked. You can change the source of detailed informaon
about addresses on the list. You can also change how long hardware blocks IP addresses.
View block list entries.

1. Select Monitor > Block IP List.
Entries on the block list indicate in the Type column whether they were blocked by
hardware (hw) or soware (sw).
2. View at the boom of the screen:
• Count of Total Blocked IPs out of the number of blocked IP addresses the firewall
supports.
• Percentage of the block list the firewall has used.
3. To filter the entries displayed, select a value in a column (which creates a filter in the
Filters field) and Apply Filter ( ). Otherwise, the firewall displays the first 1,000 entries.
4. Enter a Page number or click the arrows at the boom of the screen to advance through
pages of entries.
5. To view details about an address on the block list, hover over a Source IP address and
click the down arrow link. Click the Who Is link, which displays Network Soluons Who
Is informaon about the address.
Threat Prevenon
Delete block list entries.
Delete an entry if you determine the IP address shouldn’t be blocked. Then revise the
policy rule that caused the firewall to block the address.
1. Select Monitor > Block IP List.

2. Select one or more entries and click Delete.
3. (Oponal) Select Clear All to remove all entries from the list.
Disable or re-enable hardware IP address blocking for troubleshoong purposes.
While hardware IP address blocking is disabled, the firewall sll performs any soware
IP address blocking you have configured.
> set system setting hardware-acl-blocking [enable | disable]
To conserve CPU and packet buffer resources, leave hardware IP address blocking
enabled unless Palo Alto Networks technical support asks you to disable it, for
example, if they are debugging a traffic flow.
Tune the number of seconds that IP addresses blocked by hardware remain on the block list
(range is 1-3,600; default is 1).
> set system setting hardware-acl-blocking duration <seconds>
Maintain a shorter duraon for hardware block list entries than soware block list
entries to reduce the likelihood of exceeding the blocking capacity of the hardware.
Change the default website for finding more informaon about an IP address from Network
Soluons Who Is to a different website.
# set deviceconfig system ip-address-lookup-url <url>
Threat Prevenon
View counts of source IP addresses blocked by hardware and soware, for example to see the
rate of an aack.
View the total sum of IP address entries on the hardware block table and block list (blocked by
hardware and soware):
> show counter global name flow_dos_blk_num_entries
View the count of IP address entries on the hardware block table that were blocked by
hardware:
> show counter global name flow_dos_blk_hw_entries
View the count of IP address entries on the block list that were blocked by soware:
> show counter global name flow_dos_blk_sw_entries
View block list informaon per slot on a PA-7000 Series firewall.
> show dos-block-table software filter slot <slot-number>
Threat Prevenon
Threat Signature Categories

There are three types of Palo Alto Networks threat signatures, each designed to detect different
types of threats as the firewall scans network traffic:
• Anvirus signatures—Detect viruses and malware found in executables and file types.
• An-spyware signatures—Detects command-and-control (C2) acvity, where spyware on an
infected client is collecng data without the user's consent and/or communicang with a
remote aacker.
• Vulnerability signatures—Detects system flaws that an aacker might otherwise aempt to
exploit.
A signature's severity indicates the risk of the detected event, and a signature's default acon (for
example, block or alert) is how Palo Alto Networks recommends that you enforce matching traffic.
You must Set Up Anvirus, An-Spyware, and Vulnerability Protecon to tell the firewall what
acon to take when it detects a threat, and you can easily use the default security profiles to
start blocking threats based on Palo Alto Networks recommendaons. For each signature type,
category, and even specific signatures you can connue to modify or create new profiles to more
granularly enforce potenal threats.
The following table lists all possible signature categories by type—Anvirus, Spyware, and
Vulnerability—and includes the content update (Applicaons and Threats, Anvirus, or WildFire)
that provides the signatures in each category. You can also go to the Palo Alto Networks Threat
Vault to Learn More About Threat Signatures.
Threat Category Content Update Descripon

that Provides
These Signatures
Anvirus Signatures
apk Anvirus Malicious Android Applicaon (APK) files.

WildFire or
WildFire Private
dmg Anvirus Malicious Apple disk image (DMG) files, that are used
with Mac OS X.
WildFire or
WildFire Private
flash Anvirus Adobe Flash applets and Flash content embedded in

web pages.
Wildfire or
WildFire Private
java-class Anvirus Java applets (JAR/class file types).
Threat Prevenon

that Provides
These Signatures
macho Anvirus Mach object files (Mach-O) are executables, libraries,

and object code that are nave to Mac OS X.
Wildfire or
WildFire Private
office Anvirus Microso Office files, including documents (DOC,

DOCX, RTF), workbooks (XLS, XLSX), and PowerPoint
Wildfire or
presentaons (PPT, PPTX).
WildFire Private
openoffice Anvirus Office Open XML (OOXML) 2007+ documents.

Wildfire or
WildFire Private
pdf Anvirus Portable Document Format (PDF) files.

Wildfire or
WildFire Private
pe Anvirus Portable executable (PE) files can automacally execute

on a Microso Windows system and should be only
Wildfire or
allowed when authorized. These files types include:
WildFire Private
• Object code.
• Fonts (FONs).
• System files (SYS).
• Driver files (DRV).
• Windows control panel items (CPLs).
• DLLs (dynamic-link libraries).
• OCXs (libraries for OLE custom controls, or AcveX
controls).
• SCRs (scripts that can be used to execute other files).
• Extensible Firmware Interface (EFI) files, which run
between an OS and firmware in order to facilitate
device updates and boot operaons.
• Program informaon files (PIFs).
pkg Anvirus Apple soware installer packages (PKGs), used with Mac
OS X.
Wildfire or
WildFire Private
Spyware Signatures
Threat Prevenon

that Provides
These Signatures
adware Applicaons and Detects programs that display potenally unwanted

Threats adversements. Some adware modifies browsers to
highlight and hyperlink the most frequently searched
keywords on web pages-these links redirect users to
adversing websites. Adware can also retrieve updates
from a command-and-control (C2) server and install
those updates in a browser or onto a client system.
Newly-released protecons in this category are rare.
autogen Anvirus These payload-based signatures detect command-and-

control (C2) traffic and are automacally-generated.
Importantly, autogen signatures can detect C2 traffic
even when the C2 host is unknown or changes rapidly.
backdoor Applicaons and Detects a program that allows an aacker to gain

Threats unauthorized remote access to a system.
botnet Applicaons and Indicates botnet acvity. A botnet is a network of

Threats malware-infected computers (“bots”) that an aacker
controls. The aacker can centrally command every
computer in a botnet to simultaneously carry out a
coordinated acon (like launching a DoS aack, for
example).
browser-hijack Applicaons and Detects a plugin or soware that is modifying browser

Threats sengs. A browser hijacker might take over auto search
or track users’ web acvity and send this informaon to
a C2 server.
cryptominer Applicaons and (Somemes known as cryptojacking or miners) Detects

Threats the download aempt or network traffic generated
from malicious programs designed to use compung
resources to mine cryptocurrencies without the user's
knowledge. Cryptominer binaries are frequently
delivered by a shell script downloader that aempts
to determine system architecture and kill other miner
processes on the system. Some miners execute within
other processes, such as a web browser rendering a
malicious web page.
data-the Applicaons and Detects a system sending informaon to a known C2

Threats server.
Threat Prevenon

that Provides
These Signatures
dns Anvirus Detects DNS requests to connect to malicious domains.

dns and dns-wildfire signatures detect the same
malicious domains; however, dns signatures are included
in the daily Anvirus content update and dns-wildfire
signatures are included in the WildFire updates that
release protecons every 5 minutes.
dns-security Anvirus Detects DNS requests to connect to malicious domains.

dns-security includes signatures from dns and dns-
wildfire in addion to the unique signatures generated
by the DNS Security service.
dns-wildfire Wildfire or Detects DNS requests to connect to malicious domains.

WildFire Private
dns and dns-wildfire signatures detect the same
malicious domains; however, dns signatures are included
in the daily Anvirus content update and dns-wildfire
signatures are included in the WildFire updates that
release protecons every 5 minutes.
downloader Applicaons and (Also known as droppers, stagers, or loaders) Detects

Threats programs that use an internet connecon to connect to
a remote server to download and execute malware on
the compromised system. The most common use case
is for a downloader to be deployed as the culminaon
of stage one of a cyber aack, where the downloader’s
fetched payload execuon is considered second stage.
Shell scripts (Bash, PowerShell, etc.), trojans, and
malicious lure documents (also known as maldocs) such
as PDFs and Word files are common downloader types.
fraud Applicaons and (Including form-jacking, phishing, and scams) Detects

Threats access to compromised websites that have been
determined to be injected with malicious JavaScript
code to collect sensive user informaon. (for example,
Name, address, email, credit card number, CVV,
expiraon date) from payment forms that are captured
on the checkout pages of e-commerce websites.
hacktool Applicaons and Detects traffic generated by soware tools that are
Threats used by malicious actors to conduct reconnaissance,
aack or gain access to vulnerable systems, exfiltrate
data, or create a command and control channel to
Threat Prevenon

that Provides
These Signatures
surrepously control a computer system without
authorizaon. These programs are strongly associated
with malware and cyber aacks. Hacking tools might
be deployed in a benign manner when used in Red and
Blue Team operaons, penetraon tests, and R&D. The
use or possession of these tools may be illegal in some
countries, regardless of intent.
keylogger Applicaons and Detects programs that allow aackers to secretly

Threats track user acvity, by logging keystrokes and capturing
screenshots.
Keyloggers use various C2 methods to periodically
sends logs and reports to a predefined e-mail address or
a C2 server. Through keylogger surveillance, an aacker
could retrieve credenals that would enable network
access.
networm Applicaons and Detects a program that self-replicates and spreads

Threats from system to system. Net-worms might use shared
resources or leverage security failures to access target
systems.
phishing-kit Applicaons and Detects when a user aempts to connect to a phishing

Threats kit landing page (likely aer receiving an email with
a link to the malicious site). A phishing website tricks
users into subming credenals that an aacker can
steal to gain access to the network.
In addion to blocking access to phishing

kit landing pages, enable Mul-Factor
Authencaon and Credenal Phishing
Prevenon to prevent phishing aacks at all
stages.
post- Applicaons and Detects acvity that indicates the post-exploitaon

exploitaon Threats phase of an aack, where an aacker aempts to
assess the value of a compromised system. This might
include evaluang the sensivity of the data stored
on the system, and the system’s usefulness in further
compromising the network.
webshell Applicaons and Detects web shells and web shell traffic, including
Threats implant detecon and command and control interacon.
Web shells must first be implanted by a malicious actor
onto the compromised host, most oen targeng a
Threat Prevenon

that Provides
These Signatures
web server or framework. Subsequent communicaon
with the web shell file frequently enables a malicious
actor to establish a foothold in the system, conduct
service and network enumeraon, data exfiltraon, and
remote code execuon in the context of the web server
user. The most common web shell types are PHP, .NET,
and Perl markup scripts. Aackers can also use web
shell-infected web servers (the web servers can be
both internet-facing or internal systems) to target other
internal systems.
spyware Applicaons and Detect outbound C2 communicaon. These signatures

Threats are either auto-generated or are manually created by
Palo Alto Networks researchers.
Spyware and autogen signatures both detect

outbound C2 communicaon; however,
autogen signatures are payload-based and
can uniquely detect C2 communicaons
with C2 hosts that are unknown or change
rapidly.
Vulnerability Signatures
brute force Applicaons and A brute-force signature detects mulple occurrences

Threats of a condion in a parcular me frame. While the
acvity in isolaon might be benign, the brute-force
signature indicates that the frequency and rate at which
the acvity occurred is suspect. For example, a single
FTP login failure does not indicate malicious acvity.
However, many failed FTP logins in a short period likely
indicate an aacker aempng password combinaons
to access an FTP server.
You can tune the acon and trigger condions for brute
force signatures.
code execuon Applicaons and Detects a code execuon vulnerability that an aacker
Threats can leverage to run code on a system with the privileges
of the logged-in user.
code- Applicaons and Detects code that has been transformed to conceal
obfuscaon Threats certain data while retaining its funcon. Obfuscated
code is difficult or impossible to read, so it’s not
apparent what commands the code is execung or
with which programs its designed to interact. Most
Threat Prevenon

that Provides
These Signatures
commonly, malicious actors obfuscate code to conceal
malware. More rarely, legimate developers might
obfuscate code to protect privacy, intellectual property,
or to improve user experience. For example, certain
types of obfuscaon (like minificaon) reduce file size,
which decreases website load mes and bandwidth
usage.
dos Applicaons and Detects a denial-of-service (DoS) aack, where

Threats an aacker aempts to render a targeted system
unavailable, temporarily disrupng the system and
dependent applicaons and services. To perform a
DoS aack, an aacker might flood a targeted system
with traffic or send informaon that causes it to fail.
DoS aacks deprive legimate users (like employees,
members, and account holders) of the service or
resource to which they expect access.
exploit-kit Applicaons and Detects an exploit kit landing page. Exploit kit landing
Threats pages oen contain several exploits that target one or
many common vulnerabilies and exposures (CVEs), for
mulple browsers and plugins. Because the targeted
CVEs change quickly, exploit-kit signatures trigger
based on the exploit kit landing page, and not the CVEs.
When a user visits a website with an exploit kit, the
exploit kit scans for the targeted CVEs and aempts
to silently deliver a malicious payload to the vicm’s
computer.
info-leak Applicaons and Detects a soware vulnerability that an aacker could

Threats exploit to steal sensive or proprietary informaon.
Oen, an info-leak might exist because comprehensive
checks do not exist to guard the data, and aackers can
exploit info-leaks by sending craed requests.
insecure- Applicaons and Detects the use of weak, compromised, and

credenals Threats manufacturer default passwords for soware, network
appliances, and IoT devices.
overflow Applicaons and Detects an overflow vulnerability, where a lack of

Threats proper checks on requests could be exploited by an
aacker. A successful aack could lead to remote code
execuon with the privileges of the applicaon, server
or operang system.
Threat Prevenon

that Provides
These Signatures
phishing Applicaons and Detects when a user aempts to connect to a phishing

Threats kit landing page (likely aer receiving an email with
a link to the malicious site). A phishing website tricks
users into subming credenals that an aacker can
steal to gain access to the network.
In addion to blocking access to phishing

kit landing pages, enable Mul-Factor
Authencaon and Credenal Phishing
Prevenon to prevent phishing aacks at all
stages.
protocol- Applicaons and Detects protocol anomalies, where a protocol

anomaly Threats behavior deviates from standard and compliant usage.
For example, a malformed packet, poorly-wrien
applicaon, or an applicaon running on a non-standard
port would all be considered protocol anomalies, and
could be used as evasion tools. It is a best pracce to
block protocol anomalies of any severity.
sql-injecon Applicaons and Detects a common hacking technique where an aacker

Threats inserts SQL queries into an applicaon’s requests, in
order to read from or modify a database. This type
of technique is oen used on websites that do not
comprehensively sanize user input.
Threat Prevenon
Create Threat Excepons

Palo Alto Networks defines a recommended default acon (such as block or alert) for threat
signatures. You can use a threat ID to exclude a threat signature from enforcement or modify the
acon the firewall enforces for that threat signature. For example, you can modify the acon for
threat signatures that are triggering false posives on your network.
Configure threat excepons for anvirus, vulnerability, spyware, and DNS signatures to change
firewall enforcement for a threat. However, before you begin, make sure the firewall is detecng
and enforcing threats based on the default signature sengs:
• Get the latest Anvirus, Threats and Applicaons, and WildFire signature updates.
• Set Up Anvirus, An-Spyware, and Vulnerability Protecon and apply these security profiles
to your security policy.
STEP 1 | Exclude anvirus signatures from enforcement.
While you can use an Anvirus profile to exclude anvirus signatures from
enforcement, you cannot change the acon the firewall enforces for a specific anvirus
signature. However, you can define the acon for the firewall to enforce for viruses
found in different types of traffic by eding the Decoders (Objects > Security Profiles >
Anvirus > <anvirus-profile> > Anvirus).
1. Select Objects > Security Profiles > Anvirus.

2. Add or modify an exisng Anvirus profile from which you want to exclude a threat
signature and select Signature Excepons.
3. Add the Threat ID for the threat signature you want to exclude from enforcement.
4. Click OK to save the Anvirus profile.
Threat Prevenon
STEP 2 | Modify enforcement for vulnerability and spyware signatures (except DNS signatures; skip
to the next opon to modify enforcement for DNS signatures, which are a type of spyware
signature).
1. Select Objects > Security Profiles > An-Spyware or Objects > Security Profiles >
Vulnerability Protecon.
2. Add or modify an exisng An-Spyware or Vulnerability Protecon profile from which
you want to exclude the threat signature and then select either Signature Excepons for
An-Spyware Protecon profiles or Excepons for Vulnerability Protecon profiles.
3. Show all signatures and then filter to select the signature for which you want to modify
enforcement rules.
4. Check the box under the Enable column for the signature whose enforcement you want
to modify.
5. Select the Acon you want the firewall to enforce for this threat signature.
For signatures that you want to exclude from enforcement because they trigger false
posives, set the Acon to Allow.
6. Click OK to save your new or modified An-Spyware or Vulnerability Protecon profile.
STEP 3 | Modify enforcement for DNS signatures.

By default, the DNS lookups to malicious hostnames that DNS signatures are detect are
sinkholed.
3. Search for the DNS Threat ID for the DNS signature that you want to exclude from
enforcement and select the box of the applicable signature:
Threat Prevenon
Custom Signatures
You can create custom threat signatures to detect and block specific traffic. When the firewall
is managed by a Panorama management server, the ThreatID is mapped to the corresponding
custom threat on the firewall to enable the firewall to generate a threat log populated with the
configured custom ThreatID. Learn more by vising our guide to Custom Applicaon and Threat
Signatures.
Threat Prevenon
Monitor and Get Threat Reports

Features of Threat Vault and AutoFocus are integrated into the firewall to provide visibility into
the nature of the threats the firewall detects and to give a more complete picture of how an
arfact fits into your organizaon’s network traffic (an arfact is property, acvity, or behavior
associated with a file, email link, or session). You can get immediate, contextual informaon about
a threat or to seamlessly shi your threat invesgaon from the firewall to the Threat Vault and
AutoFocus.
Addionally, you can use Threat Signature Categories—which classify types of threat events—to
narrow your view into a certain type of threat acvity or to build custom reports.
• Monitor Acvity and Create Custom Reports Based on Threat Categories
• Learn More About Threat Signatures
• AutoFocus Threat Intelligence for Network Traffic
Monitor Acvity and Create Custom Reports Based on Threat

Categories
Threat categories classify different types of threat signatures to help you understand and draw
connecons between events threat signatures detect. Threat categories are subsets of the more
broad threat signature types: spyware, vulnerability, anvirus, and DNS signatures. Threat log
entries display the Threat Category for each recorded event.
Threat Prevenon
Filter Threat logs by threat category.

1. Select Monitor > Logs > Threat.
2. Add the Threat Category column so you can view the Threat Category for each log entry:
3. To filter based on Threat Category:

• Use the log query builder to add a filter with the Aribute Threat Category and in the
Value field, enter a Threat Category.
• Select the Threat Category of any log entry to add that category to the filter:
Threat Prevenon
Filter ACC acvity by threat category.

1. Select ACC and add Threat Category as a global filter:
2. Select the Threat Category to filter all ACC tabs.
Create custom reports based on threat categories to receive informaon about specific types of
threats that the firewall has detected.
1. Select Monitor > Manage Custom reports to add a new custom report or modify an
exisngone.
2. Choose the Database to use as the source for the custom report—in this case, select
Threat from either of the two types of database sources, summary databases and
Detailed logs. Summary database data is condensed to allow a faster response me when
generang reports. Detailed logs take longer to generate but provide an itemized and
complete set of data for each log entry.
3. In the Query Builder, add a report filter with the Aribute Threat Category and in the
Value field, select a threat category on which to base your report.
4. To test the new report sengs, click Run Now.
5. Click OK to save the report.
Learn More About Threat Signatures

Firewall Threat logs record all threats the firewall detects based on threat signatures (Set Up
Anvirus, An-Spyware, and Vulnerability Protecon) and the ACC displays an overview of the
top threats on your network. Each event the firewall records includes an ID that idenfies the
associated threat signature.
Threat Prevenon
You can use the threat ID found with a Threat log or ACC entry to:
• Easily check if a threat signature is configured as an excepon to your security policy (Create
Threat Excepons).
• Find the latest Threat Vault informaon about a specific threat. Because the Threat Vault is
integrated with the firewall, you can view threat details directly in the firewall context or launch
a Threat Vault search in a new browser window for a threat the firewall logged.
If a signature has been disabled, the signature UTID might be reused for a new signature.
Review the content update release notes for noficaons regarding new and disabled
signatures. Signatures might disabled in cases where: the acvity the signature detects
has fallen out of use by aackers, the signature generated significant false posives, or
the signature was consolidated with other like signatures into a single signature (signature
opmizaon).
STEP 1 | Confirm the firewall is connected to the Threat Vault.

Select Device > Setup > Management and edit the Logging and Reporng seng to Enable
Threat Vault Access. Threat vault access is enabled by default.
STEP 2 | Find the threat ID for threats the firewall detects.

• To see each threat event the firewall detects based on threat signatures, select Monitor >
Logs > Threat. You can find the ID for a threat entry listed in the ID column, or select the log
entry to view log details, including the Threat ID.
• To see an overview of top threats on the network, select ACC > Threat Acvity and take
a look at the Threat Acvity widget. The ID column displays the threat ID for each threat
displayed.
• To see details for threats that you can configure as threat excepons (meaning, the firewall
enforces the threat differently than the default acon defined for the threat signature),
select Objects > Security Profiles > An-Spyware/Vulnerability Protecon. Add or modify
a profile and click the Excepons tab to view configured excepons. If no excepons are
configured, you can filter for threat signatures or select Show all signatures.
Threat Prevenon
STEP 3 | Hover over a Threat Name or the threat ID to open the drop-down, and click Excepon to
review both the threat details and how the firewall is configured to enforce the threat.
For example, find out more about a top threat charted on the ACC:
STEP 4 | Review the latest Threat Details for the threat and launch a Threat Vault search based on the
threat ID.
• Threat details displayed include the latest Threat Vault informaon for the threat, resources
you can use to learn more about the threat, and CVEs associated with the threat.
• Select View in Threat Vault to open a Threat Vault search in a new window and look up the
latest informaon the Palo Alto Networks threat database has for this threat signature.
STEP 5 | Check if a threat signature is configured as an excepon to your security policy.

• If the Used in current security rule column is clear, the firewall is enforcing the threat based
on the recommended default signature acon (for example, block or alert).
• A checkmark anywhere in the Used in current security rule column indicates that a security
policy rule is configured to enforce a non-default acon for the threat (for example, allow),
based on the associated Exempt Profiles sengs.
The Used in security rule column does not indicate if the Security policy rule is enabled,
only if the Security policy rule is configured with the threat excepon. Select Policies >
Security to check if an indicated security policy rule is enabled.
Threat Prevenon
STEP 6 | Add an IP address on which to filter the threat excepon or view exisng Exempt IP
Addresses.
Configure an exempt IP address to enforce a threat excepon only when the associated session
has either a matching source or desnaon IP address; for all other sessions, the threat is
enforced based on the default signature acon.
AutoFocus Threat Intelligence for Network Traffic

With a valid AutoFocus subscripon, you can compare the acvity on your network with the latest
threat data available on the AutoFocus portal. Connecng your firewall and AutoFocus unlocks
the following features:
• View an AutoFocus intelligence summary for session arfacts recorded in the firewall logs.
• Open an AutoFocus search for log arfacts from the firewall.
The AutoFocus intelligence summary reveals the prevalence of an arfact on your network and
on a global scale. The WildFire verdicts and AutoFocus tags listed for the arfact indicate whether
the arfact poses a security risk.
• AutoFocus Intelligence Summary
• Enable AutoFocus Threat Intelligence
• View and Act on AutoFocus Intelligence Summary Data
You can also enforce policy based on AutoFocus findings:

• Export AutoFocus arfacts (IP addresses, URLs, and domains) and use them in an
external dynamic list.
• Use an AutoFocus miner as an external dynamic list source.
AutoFocus Intelligence Summary

The AutoFocus Intelligence Summary offers a centralized view of informaon about an arfact
that AutoFocus has extracted from threat intelligence gathered from other AutoFocus users,
WildFire, the PAN-DB URL filtering database, Unit 42, and open-source intelligence.
Threat Prevenon
Analysis Informaon The Analysis Informaon tab displays the following informaon:
• Sessions—The number of sessions logged in your firewall(s) in which
the firewall detected samples associated with the arfact.
• Samples—A comparison of organizaon and global samples
associated with the arfact and grouped by WildFire verdict
(benign, malware, or grayware). Global refers to samples from all
WildFire submissions, while organizaon refers only to samples
submied to WildFire by your organizaon.
• Matching Tags—The AutoFocus tags matched to the arfact.
AutoFocus Tags indicate whether an arfact is linked to malware or
targeted aacks.
Passive DNS The Passive DNS tab displays passive DNS history that includes the
arfact. This passive DNS history is based on global DNS intelligence
in AutoFocus; it is not limited to the DNS acvity in your network.
Passive DNS history consists of:
• The domain request
• The DNS request type
• The IP address or domain to which the DNS request resolved
(private IP addresses are not displayed)
• The number of mes the request was made
• The date and me the request was first seen and last seen
Matching Hashes The Matching Hashes tab displays the 5 most recently detected
matching samples. Sample informaon includes:
Threat Prevenon

• The SHA256 hash of the sample
• The sample file type
• The date and me that WildFire analyzed a sample and assigned a
WildFire verdict to it
• The WildFire verdict for the sample
• The date and me that WildFire updated the WildFire verdict for
the sample (if applicable)
Enable AutoFocus Threat Intelligence

Acvate the AutoFocus license, and enable the firewall to communicate with AutoFocus. Once
you’re set up, you’ll be able to view the AutoFocus Intelligence Summary for a log or ACC arfact,
to assess its pervasiveness in your network and any associated threats.
STEP 1 | Verify that the AutoFocus license is acvated on the firewall.
1. Select Device > Licenses to verify that the AutoFocus Device License is installed and
valid (check the expiraon date).
2. If the firewall doesn’t show the license, Acvate Subscripon Licenses.
STEP 2 | Connect the firewall to AutoFocus.

1. Select Device > Setup > Management and edit the AutoFocus sengs.
2. Enter the AutoFocus URL:
https://autofocus.paloaltonetworks.com:10443
3. Use the Query Timeout field to set the duraon of me for the firewall to aempt to
query AutoFocus for threat intelligence data. If the AutoFocus portal does not respond
before the end of the specified period, the firewall closes the connecon.
As a best pracce, set the query meout to the default value of 15 seconds.
AutoFocus queries are opmized to complete within this duraon.
4. Select Enabled to allow the firewall to connect to AutoFocus.
5. Click OK.
6. Commit your changes to retain the AutoFocus sengs upon reboot.
Threat Prevenon
STEP 3 | Connect AutoFocus to the firewall.

1. Log in to the AutoFocus portal: hps://autofocus.paloaltonetworks.com
2. Select Sengs.
3. Add new remote systems.
4. Enter a descripve Name to idenfy the firewall.
5. Select PanOS as the System Type.
6. Enter the firewall IP Address.
7. Click Save changes to add the remote system.
8. Click Save changes again on the Sengs page to ensure the firewall is successfully
added.
STEP 4 | Test the connecon between the firewall and AutoFocus.

1. On the firewall, select Monitor > Logs > Traffic.
2. Verify that you can Assess Firewall Arfacts with AutoFocus.
View and Act on AutoFocus Intelligence Summary Data

Interact with the AutoFocus Intelligence Summary to display more informaon about an arfact or
extend your arfact research to AutoFocus. AutoFocus tags reveal if the arfact is associated with
certain types of malware or malicious behavior.
STEP 1 | Confirm that the firewall is connected to AutoFocus.
Enable AutoFocus Threat Intelligence on the firewall (acve AutoFocus subscripon required).
STEP 2 | Find arfacts to invesgate.

You can view an AutoFocus Intelligence Summary for arfacts when you:
• View Logs (Traffic, Threat, URL Filtering, WildFire Submissions, Data Filtering, and Unified
logs only).
• View External Dynamic List Entries.
Threat Prevenon
STEP 3 | Hover over an arfact to open the drop-down, and click AutoFocus.
The AutoFocus Intelligence Summary is only available for the following types of arfacts:
IP address
URL
Domain
User agent
Threat name (only for threats of the subtypes virus and wildfire-virus)
Filename
SHA-256 hash
STEP 4 | Launch an AutoFocus search for the arfact for which you opened the AutoFocus
Intelligence Summary.
Click the Search AutoFocus for... link at the top of the AutoFocus Intelligence Summary
window. The search results include all samples associated with the arfact. Toggle between
the My Samples and All Samples tabs and compare the number of samples to determine the
pervasiveness of the arfact in your organizaon.
STEP 5 | Launch an AutoFocus search for other arfacts in the AutoFocus Intelligence Summary.
Click on the following arfacts to determine their pervasiveness in your organizaon:
• WildFire verdicts in the Analysis Informaon tab
• URLs and IP addresses in the Passive DNS tab
• The SHA256 hashes in the Matching Hashes tab
Threat Prevenon
STEP 6 | View the number of sessions associated with the arfact in your organizaon per month.
Hover over the session bars.
STEP 7 | View the number of samples associated with the arfact by scope and WildFire verdict.
Hover over the samples bars.
STEP 8 | View more details about matching AutoFocus. tags.

Hover over a matching tag to view the tag descripon and other tag details.
STEP 9 | View other samples associated with a matching tag.

Click a matching tag to launch an AutoFocus search for that tag. The search results include all
samples matched to the tag.
Unit 42 tags idenfy threats and campaigns that pose a direct security risk. Click on a Unit 42
matching tag to see how many samples in your network are associated with the threat the tag
idenfies.
Threat Prevenon
STEP 10 | Find more matching tags for an arfact.

Click the ellipsis ( ... ) to launch an AutoFocus search for the arfact. The Tags column in
the search results displays more matching tags for the arfact, which give you an idea of
other malware, malicious behavior, threat actors, exploits, or campaigns where the arfact is
commonly detected.
Threat Prevenon
Share Threat Intelligence with Palo Alto Networks

Telemetry is the process of collecng and transming data for analysis. When you enable
telemetry on the firewall, the firewall periodically collects and sends informaon that includes
applicaons, threats, and device health to Palo Alto Networks. Sharing threat intelligence provides
the following benefits:
• Enhanced vulnerability and spyware signatures delivered to you and other customers
worldwide. For example, when a threat event triggers vulnerability or spyware signatures, the
firewall shares the URLs associated with the threat with the Palo Alto Networks threat research
team, so they can properly classify the URLs as malicious.
• Rapid tesng and evaluaon of experimental threat signatures with no impact to your
network, so that crical threat prevenon signatures can be released to all Palo Alto Networks
customers faster.
• Improved accuracy and malware detecon abilies within PAN-DB URL filtering, DNS-based
command-and-control (C2) signatures, and WildFire.
Palo Alto Networks uses the threat intelligence extracted from telemetry to deliver these benefits
to you and other Palo Alto Networks users. All Palo Alto Networks users benefit from the
telemetry data shared by each user, making telemetry a community-driven approach to threat
prevenon. Palo Alto Networks does not share your telemetry data with other customers or third-
party organizaons.
To read more about telemetry, including its benefits, usages, and configuraon, see Device
Telemetry.
Threat Prevenon
Threat Prevenon Resources

For more informaon on threat prevenon best pracces, refer to the following sources:
• Creang Custom Threat Signatures
• Best Pracces for Securing Your Network from Layer 4 and Layer 7 Evasions
• URL Filtering Best Pracces
• Zero Trust Best Pracces
• DoS and Zone Protecon Best Pracces
To view a list of threats and applicaons that Palo Alto Networks products can idenfy, use the
following links:
• Applipedia—Provides details on the applicaons that Palo Alto Networks can idenfy.
• Threat Vault—Lists threats that Palo Alto Networks products can idenfy. You can search
by Vulnerability, Spyware, or Virus. Click the Details icon next to the ID number for more
informaon about a threat.
Threat Prevenon
Decrypon
Palo Alto Networks firewalls can decrypt and inspect traffic to provide visibility
into threats and to control protocols, cerficate verificaon, and failure handling.
Decrypon can enforce policies on encrypted traffic so that the firewall handles
encrypted traffic according to your configured security sengs. Decrypt traffic to
prevent malicious encrypted content from entering your network and sensive
content from leaving your network concealed as encrypted traffic. Enabling decrypon
can include preparing the keys and cerficates required for decrypon, creang
decrypon profiles and policies, and configuring decrypon port mirroring.
> Decrypon Overview > Decrypon Exclusions
> Decrypon Concepts > Block Private Key Export
> Prepare to Deploy Decrypon > Enable Users to Opt Out of SSL
> Define Traffic to Decrypt Decrypon
> Configure SSL Forward Proxy > Temporarily Disable SSL Decrypon
> Configure SSL Inbound Inspecon > Configure Decrypon Port Mirroring
> Configure SSH Proxy > Verify Decrypon
> Configure Server Cerficate > Troubleshoot and Monitor

Verificaon for Undecrypted Traffic Decrypon
> Acvate Free Licenses for
Decrypon Features
969
Decrypon
Decrypon Overview
The Secure Sockets Layer (SSL) and Secure Shell (SSH) encrypon protocols secure traffic between
two enes, such as a web server and a client. SSL and SSH encapsulate traffic, encrypng data
so that it is meaningless to enes other than the client and server with the cerficates to affirm
trust between the devices and the keys to decode the data. Decrypt SSL and SSH traffic to:
• Prevent malware concealed as encrypted traffic from being introduced into your network. For
example, an aacker compromises a website that uses SSL encrypon. Employees visit that
website and unknowingly download an exploit or malware. The malware then uses the infected
employee endpoint to move laterally through the network and compromise other systems.
• Prevent sensive informaon from moving outside the network.
• Ensure the appropriate applicaons are running on a secure network.
• Selecvely decrypt traffic; for example, create a Decrypon policy and profile to exclude traffic
for financial or healthcare sites from decrypon.
Palo Alto Networks firewall decrypon is policy-based, and can decrypt, inspect, and control
inbound and outbound SSL and SSH connecons. A Decrypon policy enables you to specify
traffic to decrypt by desnaon, source, service, or URL category, and to block, restrict, or forward
the specified traffic according to the security sengs in the associated Decrypon profile. A
Decrypon profile controls SSL protocols, cerficate verificaon, and failure checks to prevent
traffic that uses weak algorithms or unsupported modes from accessing the network. The firewall
uses cerficates and keys to decrypt traffic to plaintext, and then enforces App-ID and security
sengs on the plaintext traffic, including Decrypon, Anvirus, Vulnerability, An-Spyware, URL
Filtering, WildFire, and File-Blocking profiles. Aer decrypng and inspecng traffic, the firewall
re-encrypts the plaintext traffic as it exits the firewall to ensure privacy and security.
The firewall provides three types of Decrypon policy rules: SSL Forward Proxy to control
outbound SSL traffic, SSL Inbound Inspecon to control inbound SSL traffic, and SSH Proxy to
control tunneled SSH traffic. You can aach a Decrypon profile to a policy rule to apply granular
access sengs to traffic, such as checks for server cerficates, unsupported modes, and failures.
SSL decrypon (both forward proxy and inbound inspecon) requires cerficates to establish the
firewall as a trusted third party, and to establish trust between a client and a server to secure an
SSL/TLS connecon. You can also use cerficates when excluding servers from SSL decrypon for
technical reasons (the site breaks decrypon for reasons such as cerficate pinning, unsupported
ciphers, or mutual authencaon). SSH decrypon does not require cerficates.
Use the Decrypon Best Pracces Checklist to plan, implement, and maintain your
decrypon deployment.
You can integrate a hardware security module (HSM) with a firewall to enable enhanced security
for the private keys used in SSL forward proxy and SSL inbound inspecon decrypon. To learn
more about storing and generang keys using an HSM and integrang an HSM with your firewall,
see Secure Keys with a Hardware Security Module.
You can also use Decrypon Mirroring to forward decrypted traffic as plaintext to a third party
soluon for addional analysis and archiving.
Decrypon
If you enable Decrypon mirroring, be aware of local laws and regulaons about what
traffic you can mirror and where and how you can store the traffic, because all mirrored
traffic, including sensive informaon, is forwarded in cleartext.
Decrypon
Decrypon Concepts
Review the following topics to learn more about decrypon features and support:
• Keys and Cerficates for Decrypon Policies
• SSL Forward Proxy
• SSL Forward Proxy Decrypon Profile
• SSL Inbound Inspecon
• SSL Inbound Inspecon Decrypon Profile
• SSL Protocol Sengs Decrypon Profile
• SSH Proxy
• SSH Proxy Decrypon Profile
• SSL Profile for No Decrypon
• SSL Decrypon for Ellipcal Curve Cryptography (ECC) Cerficates
• Perfect Forward Secrecy (PFS) Support for SSL Decrypon
• SSL Decrypon and Subject Alternave Names (SANs)
• TLSv1.3 Decrypon
• High Availability Support for Decrypted Sessions
• Decrypon Mirroring
Keys and Cerficates for Decrypon Policies

Keys are strings of numbers typically generated using a mathemacal operaon involving random
numbers and large primes. Keys transform strings—such as passwords and shared secrets—from
unencrypted plaintext to encrypted ciphertext and from encrypted ciphertext to unencrypted
plaintext. Keys can be symmetric (the same key is used to encrypt and decrypt) or asymmetric (one
key is used for encrypon and a mathemacally related key is used for decrypon). Any system
can generate a key.
X.509 cerficates establish trust between a client and a server to establish an SSL connecon. A
client aempng to authencate a server (or a server authencang a client) knows the structure
of the X.509 cerficate and therefore knows how to extract idenfying informaon about the
server from fields within the cerficate, such as the FQDN or IP address (called a common name
or CN within the cerficate) or the name of the organizaon, department, or user to which the
cerficate was issued. A cerficate authority (CA) must issue all cerficates. Aer the CA verifies a
client or server, the CA issues the cerficate and signs it with a private key.
If you have two CAs (Device > Cerficate Management > Device Cerficates) with the
same subject and key, and one CA expires, delete (custom) or disable (predefined) the
expired CA. If you do not delete or disable an expired CA, the firewall can build a chain to
the expired CA if it is enabled in the trusted chain resulng in a Block page.
When you apply a decrypon policy to traffic, a session between the client and the server is
established only if the firewall trusts the CA that signed the server cerficate. In order to establish
Decrypon
trust, the firewall must have the server root CA cerficate in its cerficate trust list (CTL) and
use the public key contained in that root CA cerficate to verify the signature. The firewall then
presents a copy of the server cerficate signed by the Forward Trust cerficate for the client
to authencate. You can also configure the firewall to use an enterprise CA as a forward trust
cerficate for SSL Forward Proxy. If the firewall does not have the server root CA cerficate in
its CTL, the firewall will present a copy of the server cerficate signed by the Forward Untrust
cerficate to the client. The Forward Untrust cerficate ensures that clients are prompted with a
cerficate warning when aempng to access sites hosted by a server with untrusted cerficates.
For detailed informaon on cerficates, see Cerficate Management.
To control the trusted CAs that your firewall trusts, use the Device > Cerficate
Management > Cerficates > Default Trusted Cerficate Authories tab on the firewall
web interface.
The following table describes the different cerficates Palo Alto Networks firewalls use for
decrypon.
Cerficates Used With Descripon

Decrypon
Forward Trust (Used The cerficate the firewall presents to clients during decrypon if the
for SSL Forward site the client is aempng to connect to has a cerficate signed by a
Proxy decrypon) CA that the firewall trusts. To configure a Forward Trust cerficate on
the firewall to present to clients when the server cerficate is signed
by a trusted CA, see Configure SSL Forward Proxy.
By default, the firewall determines the key size to use for the client
cerficate based on the key size of the desnaon server. However,
you can Configure the Key Size for SSL Proxy Server cerficates. For
added security, consider storing the private key associated with the
Forward Trust cerficate on a hardware security module (see Store
Private Keys on an HSM).
Back up the private key associated with the firewall’s

Forward Trust CA cerficate (not the firewall’s master
key) in a secure repository so that if an issue occurs with
the firewall, you can sll access the Forward Trust CA
cerficate. For added security, consider storing the private
key associated with the Forward Trust cerficate on a
hardware security module (see Store Private Keys on an
HSM).
Forward Untrust The cerficate the firewall presents to clients during decrypon if
(Used for SSL the site the client is aempng to connect to has a cerficate that is
Forward Proxy signed by a CA that the firewall does not trust. To configure a Forward
decrypon) Untrust cerficate on the firewall, see Configure SSL Forward Proxy.
Decrypon
Cerficates Used With Descripon

Decrypon
SSL Inbound The cerficates of the servers on your network for which you want to
Inspecon perform SSL Inbound Inspecon of traffic desned for those servers.
Import the server cerficates onto the firewall.
Beginning in PAN-OS 8.0, firewalls use the Ellipc-Curve

Diffie-Hellman Ephemeral (ECDHE) algorithm to perform
strict cerficate checking. This means that if the firewall
uses an intermediate cerficate, you must reimport the
cerficate from your web server to the firewall aer you
upgrade to a PAN-OS 8.0 or later release and combine the
server cerficate with the intermediate cerficate (install
a chained cerficate). Otherwise, SSL Inbound Inspecon
sessions that have an intermediate cerficate in the chain
will fail. To install a chained cerficate:
1. Open each cerficate (.cer) file in a plain-text editor such
as Notepad.
2. Paste each cerficate end-to-end with the Server
Cerficate at the top with each signer included below.
3. Save the file as a text (.txt) or cerficate (.cer) file (the
name of the file cannot contain blank spaces).
4. Import the combined (chained) cerficate into the
firewall.
SSL Forward Proxy

When you configure the firewall to decrypt SSL traffic going to external sites, it funcons as an
SSL forward proxy. Use an SSL Forward Proxy decrypon policy to decrypt and inspect SSL/TLS
traffic from internal users to the web. SSL Forward Proxy decrypon prevents malware concealed
as SSL encrypted traffic from being introduced into your corporate network by decrypng the
traffic so that the firewall can apply decrypon profiles and security policies and profiles to the
traffic.
In SSL Forward Proxy decrypon, the firewall is a man-in-the-middle between the internal client
and the external server. The firewall uses cerficates to transparently represent the client to
the server and to transparently represent the server to the client, so that the client believes it is
communicang directly with the server (even though the client session is with the firewall), and
server believes it is communicang directly with the client (even though the server session is also
with the firewall). The firewall uses cerficates to establish itself as a trusted third party (man-in-
the-middle) for the client-server session (for details on cerficates, see Keys and Cerficates for
Decrypon Policies).
The following figure shows this process in detail. See Configure SSL Forward Proxy for details on
configuring SSL Forward Proxy.
Decrypon
1. The internal client on your network aempts to iniate a TLS session with an external server.
2. The firewall intercepts the client’s SSL cerficate request. For the client, the firewall acts as the
external server, even though the secure session being established is with the firewall, not with
the actual server.
3. The firewall then forwards the client’s SSL cerficate request to the server to iniate a separate
session with the server. To the server, the firewall looks like the client, the server doesn’t know
there’s a man-in-the-middle, and the server verifies the cerficate.
4. The server sends the firewall a signed cerficate intended for the client.
5. The firewall analyzes the server cerficate. If the server cerficate is signed by a CA that the
firewall trusts and meets the policies and profiles you configure, the firewall generates an SSL
Forward Trust copy of the server cerficate and sends it to the client. If the server cerficate
is signed by a CA that the firewall does not trust, the firewall generates an SSL Forward
Untrust copy of the server cerficate and sends it to the client. The cerficate copy the firewall
generates and sends to the client contains extensions from the original server cerficate and is
called an impersonaon cerficate because it is not the server’s actual cerficate. If the firewall
does not trust the server, the client sees a block page warning message that the site they’re
aempng to connect to is not trusted, and if you Enable Users to Opt Out of SSL Decrypon,
the client can choose to proceed or terminate the session.
6. The client verifies the firewall’s impersonaon cerficate. The client then iniates a session
key exchange with the server, which the firewall proxies in the same manner as it proxies the
cerficates. The firewall forwards the client key to the server, and makes an impersonaon
copy of the server key for the client, so that firewall remains an “invisible” proxy, the client and
server believe their session is with each other, but there are sll two separate sessions, one
between the client and the firewall, and the other between the firewall and the server. Now all
pares have the cerficates and keys required and the firewall can decrypt the traffic.
Decrypon
7. All SSL session traffic between goes through the firewall transparently between the client
and the server. The firewall decrypts the SSL traffic, applies security policies and profiles and
decrypon profiles to the traffic, re-encrypts the traffic, and then forwards it.
When you configure SSL Forward Proxy, the proxied traffic does not support DSCP code
points or QoS.
SSL Forward Proxy Decrypon Profile

The SSL Forward Proxy Decrypon profile (Objects > Decrypon Profile > SSL Decrypon >
SSL Forward Proxy) controls the server verificaon, session mode checks, and failure checks
for outbound SSL/TLS traffic defined in Forward Proxy Decrypon policies to which you aach
the profile. The following figure shows the general best pracce recommendaons for Forward
Proxy Decrypon profile sengs, but the sengs you use also depend on your company’s
security compliance rules and local laws and regulaons. There are also specific best pracces for
perimeter internet gateway decrypon profiles and for data center decrypon profiles.
Server Cerficate Verificaon:

• Block sessions with expired cerficates—Always check this box to block sessions with servers
that have expired cerficates and prevent access to potenally insecure sites. If you don’t
check this box, users can connect with and transact with potenally malicious sites and see
warning messages when they aempt to connect, but the connecon is not prevented.
• Block sessions with untrusted issuers—Always check this box to block sessions with servers
that have untrusted cerficate issuers. An untrusted issuer may indicate a man-in-the-middle
aack, a replay aack, or other aack.
• Block sessions with unknown cerficate status—Blocks the SSL/TLS session when a the
cerficate revocaon status of the server returns with the status “unknown”. Because
cerficate status may be unknown for mulple reasons, for general decrypon security,
checking this box usually ghtens security too much. However, in higher-security areas of the
network such as the data center, checking this box makes sense.
Decrypon
• Block sessions on cerficate status check meout—Whether to block sessions if the status
check mes out depends on your company’s security compliance stance because it’s a tradeoff
between ghter security and a beer user experience. Cerficate status verificaon examines
the Cerficate Revocaon List (CRL) on a revocaon server or uses Online Cerficate Status
Protocol (OCSP) to find out if the issuing CA has revoked the cerficate and the cerficate
should not be trusted. However, revocaon servers can be slow to respond, which can cause
the session to meout and the firewall to block the session even though the cerficate may
be valid. If you Block sessions on cerficate status check meout and the revocaon server
is slow to respond, you can use Device > Setup > Session > Decrypon Sengs and click
Cerficate Revocaon Checking to change the default meout value of five seconds to
another value. For example, you could increase the meout value to eight seconds, as shown
in the following figure. Enable both CRL and OCSP cerficate revocaon checking because
server cerficates can contain the CRL URL in the CRL Distribuon Point (CDP) extension or
the OCSP URL in the Authority Informaon Access (AIA) cerficate extension.
• Restrict cerficate extensions—Checking this box limits the cerficate extensions in the server
cerficate to key usage and extended key usage and blocks cerficates with other extensions.
However, in certain deployments, some other cerficate extensions may be necessary, so only
check this box if your deployment requires no other cerficate extensions.
• Append cerficate’s CN value to SAN extension—Checking this box ensures that when a
browser requires a server cerficate to use a Subject Alternave Name (SAN) and doesn’t
support cerficate matching based on the Common Name (CN), if the cerficate doesn’t have
a SAN extension, users can sll access the requested web resources because the firewall adds
the SAN extension (based on the CN) to the impersonaon cerficate.
Unsupported Mode Checks. If you don’t block sessions with unsupported modes, users receive
a warning message if they connect with potenally unsafe servers, and they can click through
that message and reach the potenally dangerous site. Blocking these sessions protects you from
servers that use weak, risky protocol versions and algorithms:
• Block sessions with unsupported versions—When you configure the SSL Protocol Sengs
Decrypon Profile, you specify the minimum version of SSL protocol to allow on your network
to reduce the aack surface by blocking weak protocols. Always check this box to block
sessions with the weak SSL/TLS protocol versions that you have chosen not to support.
• Block sessions with unsupported cipher suites—Always check this box to block sessions if
the firewall doesn’t support the cipher suite specified in the handshake. You configure which
algorithms the firewall supports on the SSL Protocol Sengs tab of the Decrypon profile.
Decrypon
• Block sessions with client authencaon—If you have no crical applicaons that require
client authencaon, block it because firewall can’t decrypt sessions that require client
authencaon. The firewall needs both the client and the server cerficates to perform bi-
direconal decrypon, but with client authencaon, the firewall only knows the server
cerficate. This breaks decrypon for client authencaon sessions. When you check this box,
the firewall blocks all sessions with client authencaon except sessions from sites on the SSL
Decrypon Exclusion list (Device > Cerficate Management > SSL Decrypon Exclusion).
If you don’t Block sessions with client authencaon, when the firewall aempts to decrypt
a session that uses client authencaon, the firewall allows the session and adds an entry that
contains the server URL/IP address, the applicaon, and the Decrypon profile to its Local
Decrypon Exclusion Cache.
You may need to allow traffic on your network from sites that use client authencaon
and are not in the Predefined sites on the SSL Decrypon Exclusion list. Create
a Decrypon profile that allows sessions with client authencaon. Add it to a
Decrypon policy rule that applies only to the server(s) that host the applicaon. To
increase security even more, you can require Mul-Factor Authencaon to complete
the user login process.
Failure Checks:
• Block sessions if resources not available—If you block sessions when no firewall processing
resources are available, the firewall drops traffic when it doesn’t have the resources to decrypt
the traffic. If you don’t block sessions when the firewall can’t process decrypon due to a
lack of resources, then traffic that you want to decrypt enters the network sll encrypted
and therefore is not inspected. However, blocking sessions when resources aren’t available
may affect the user experience by making sites that users normally can reach temporarily
unreachable. Whether to implement this failure check depends on your company’s security
compliance stance and the importance of the user experience, weighed against ghter security.
Alternavely, consider using firewall models with more processing power so that you can
decrypt more traffic.
• Block sessions if HSM not available—If you use a Hardware Security Module (HSM) to store
your private keys, whether you use one depends on your compliance rules about where the
private key must come from and how you want to handle encrypted traffic if the HSM isn’t
available. For example, if your company mandates the use of an HSM for private key signing,
then block sessions if the HSM isn’t available. However, if your company is less strict about
this, then you can consider not blocking sessions if the HSM isn’t available. (If the HSM is
down, the firewall can process decrypon for sites for which it has cached the response from
the HSM, but not for other sites.) The best pracce in this case depends on your company’s
policies. If the HSM is crical to your business, run the HSM in a high-availability (HA) pair
(PAN-OS 8.1 supports two members in an HSM HA pair).
• Block downgrade on no resource—Prevents the firewall from downgrading TLSv1.3 to TLSv1.2
if the firewall has no available TLSv1.3 processing resources. If you block the downgrade, then
when the firewall runs out of TLSv1.3 resources, it drops traffic that uses TLSv1.3 instead of
downgrading it to TLSv1.2. If you don’t block downgrade, then when the firewall runs out of
TLSv1.3 resources, it downgrades to TLSv1.2. However, blocking downgrade when resources
aren’t available may affect the user experience by making sites that users normally can reach
temporarily unreachable. Whether to implement this failure check depends on your company’s
security compliance stance and the importance of the user experience, weighed against ghter
Decrypon
security. You may want to create a separate Decrypon policy and profile to govern decrypon
for sensive traffic for which you don’t want to downgrade the TLS version.
SSL Inbound Inspecon

Use SSL Inbound Inspecon to decrypt and inspect inbound SSL/TLS traffic from a client to
a targeted network server (any server you have the cerficate for and can import it onto the
firewall) and block suspicious sessions. For example, if an employee is remotely connected
to a web server hosted on the company network and is aempng to add restricted internal
documents to his Dropbox folder (which uses SSL for data transmission), SSL Inbound Inspecon
can ensure that the sensive data does not move outside the secure company network by
blocking or restricng the session.
On the firewall, you must install the cerficate and private key for each server for which you want
to perform SSL Inbound Inspecon. You must also install the public key cerficate as well as the
private key on each firewall that performs SSL Inbound Inspecon. The way the firewall performs
SSL Inbound Inspecon depends on the type of key negoated, Rivest, Shamir, Adleman (RSA) or
Perfect Forward Secrecy (PFS).
For RSA keys, the firewall performs SSL Inbound Inspecon without terminang the connecon.
As the encrypted session flows through the firewall, the firewall transparently makes a copy of it
and decrypts it so that the firewall can apply the appropriate policy to the traffic.
When you configure the SSL Protocol Sengs Decrypon Profile for SSL Inbound
Inspecon traffic, create separate profiles for servers with different security capabilies.
For example, if one set of servers supports only RSA, the SSL Protocol Sengs only need
to support RSA. However, the SSL Protocol Sengs for servers that support PFS should
support PFS. Configure SSL Protocol Sengs for the highest level of security that the
server supports, but check performance to ensure that the firewall resources can handle
the higher processing load that higher security protocols and algorithms require.
For PFS keys using the Diffie-Hellman exchange (DHE) or Ellipc Curve Diffie-Hellman exchange
(ECDHE), the firewall acts as a man-in-the-middle proxy between the external client and the
internal server. Because PFS generates a new key with every session, the firewall can’t simply copy
and decrypt the inbound SSL flow as it passes through, the firewall must act as a proxy device.
If you have enabled SSL Inbound Inspecon using PFS key exchange algorithms, you must
upload a cerficate bundle (a single file) to the firewall with your cerficates arranged as
follows:
1. End-enty (leaf) cerficate
2. Intermediate cerficates (in issuing order)
3. (Oponal) Root cerficate
Uploading the file ensures that clients receive the complete cerficate chain during SSL
handshakes, avoiding client-side server cerficate authencaon issues.
The following figure shows how SSL Inbound Inspecon works when the key exchange algorithm
is RSA. When the key exchange algorithm is PFS, the firewall funcons as a proxy (creates a secure
session between the client and the firewall and another secure session between the firewall and
the server) and must generate a new session key for each secure session.
Decrypon
When you configure SSL Inbound Inspecon and use a PFS cipher, session resumpon is
not supported.
See Configure SSL Inbound Inspecon for details on enabling this feature.
When you configure SSL Inbound Inspecon, the proxied traffic does not support DSCP
code points or QoS.
SSL Inbound Inspecon Decrypon Profile

The SSL Inbound Inspecon Decrypon profile (Objects > Decrypon Profile > SSL Decrypon
> SSL Inbound Inspecon) controls the session mode checks and failure checks for inbound SSL/
TLS traffic defined in the Inbound Inspecon Decrypon policies to which you aach the profile.
The following figure shows the general best pracce recommendaons for Inbound Inspecon
Decrypon profile sengs, but the sengs you use also depend on your company’s security
compliance rules and local laws and regulaons.
Decrypon
Unsupported Mode Checks. If you don’t block sessions with unsupported modes, users receive
a warning message if they connect with potenally unsafe servers, and they can click through
that message and reach the potenally dangerous site. Blocking these sessions protects you from
servers that use weak, risky protocol versions and algorithms:
1. Block sessions with unsupported versions—When you configure the SSL Protocol Sengs
Decrypon Profile, you specify the minimum version of TLS protocol to allow on your network
to reduce the aack surface by blocking weak protocols. Always check this box to block
sessions with the weak SSL and TLS protocol versions that you have chosen not to support.
2. Block sessions with unsupported cipher suites—Always check this box to block sessions if
the firewall doesn’t support the cipher suite specified in the handshake. You configure which
algorithms the firewall supports on the SSL Protocol Sengs tab of the Decrypon profile.
Failure Checks:
• Block sessions if resources not available—If you block sessions when no firewall processing
resources are available, the firewall drops traffic when it doesn’t have the resources to decrypt
the traffic. If you don’t block sessions when the firewall can’t process decrypon due to a
lack of resources, then traffic that you want to decrypt enters the network sll encrypted
and therefore is not inspected. However, blocking sessions when resources aren’t available
may affect the user experience by making sites that users normally can reach temporarily
unreachable. Whether to implement this failure check depends on your company’s security
compliance stance and the importance of the user experience, weighed against ghter security.
Alternavely, consider using firewall models with more processing power so that you can
decrypt more traffic.
• Block sessions if HSM not available—If you use a Hardware Security Module (HSM) to store
your private keys, whether you use one depends on your compliance rules about where the
private key must come from and how you want to handle encrypted traffic if the HSM isn’t
available. For example, if your company mandates the use of an HSM for private key signing,
then block sessions if the HSM isn’t available. However, if your company is less strict about
this, then you can consider not blocking sessions if the HSM isn’t available. (If the HSM is
down, the firewall can process decrypon for sites for which it has cached the response from
the HSM, but not for other sites.) The best pracce in this case depends on your company’s
policies. If the HSM is crical to your business, run the HSM in a high-availability (HA) pair
(PAN-OS 8.1 supports two members in an HSM HA pair).
• Block downgrade on no resource—Prevents the firewall from downgrading TLSv1.3 to TLSv1.2
if the firewall has no available TLSv1.3 processing resources. If you block the downgrade, then
when the firewall runs out of TLSv1.3 resources, it drops traffic that uses TLSv1.3 instead of
downgrading it to TLSv1.2. If you don’t block downgrade, then when the firewall runs out of
TLSv1.3 resources, it downgrades to TLSv1.2. However, blocking downgrade when resources
aren’t available may affect the user experience by making sites that users normally can reach
temporarily unreachable. Whether to implement this failure check depends on your company’s
security compliance stance and the importance of the user experience, weighed against ghter
security. You may want to create a separate Decrypon policy and profile to govern decrypon
for sensive traffic for which you don’t want to downgrade the TLS version.
SSL Protocol Sengs Decrypon Profile

The SSL Protocol Sengs (Objects > Decrypon Profile > SSL Decrypon > SSL Protocol
Sengs) control whether you allow vulnerable SSL/TLS protocol versions, weak encrypon
Decrypon
algorithms, and weak authencaon algorithms. SSL Protocol Sengs apply to outbound SSL
Forward Proxy and inbound SSL Inbound Inspecon traffic. These sengs don’t apply to SSH
Proxy traffic or to traffic that you don’t decrypt.
The following figure shows the general best pracce recommendaons for SSL Protocol Sengs.
There are also specific best pracces for perimeter internet gateway decrypon profiles and for
data center decrypon profiles.
When you configure SSL Protocol Sengs for SSL Inbound Inspecon traffic, create
separate profiles for servers with different security capabilies. For example, if one set of
servers supports only RSA, the SSL Protocol Sengs only need to support RSA. However,
the SSL Protocol Sengs for servers that support PFS should support PFS. Configure SSL
Protocol Sengs for the highest level of security that the target server you are protecng
supports, but check performance to ensure that the firewall resources can handle the
higher processing load that higher security protocols and algorithms require.
Protocol Versions:
• Set the Min Version to TLSv1.2 to provide the strongest security—business sites that value
security support TLSv1.2. If a site (or a category of sites) only supports weaker ciphers, review
the site and determine if it hosts a legimate business applicaon. If it does, make an excepon
for only that site by configuring a Decrypon profile with a Min Version that matches the
strongest cipher the site supports and then applying the profile to a Decrypon policy rule that
limits allowing the weak cipher to only the site or sites in queson. If the site doesn’t host a
legimate business applicaon, don’t weaken your security posture to support the site—weak
protocols (and ciphers) contain known vulnerabilies that aackers can exploit.
If the site belongs to a category of sites that you don’t need for business purposes, use
URL Filtering to block access to the enre category. Don’t support weak encrypon or
authencaon algorithms unless you must to support important legacy sites, and when you
make excepons, create a separate Decrypon profile that allows the weaker protocol just
Decrypon
for those sites. Don’t downgrade the main Decrypon profile that you apply to most sites to
TLSv1.1 just to accommodate a few excepons.
Qualys SSL Labs SSL Pulse web page provides up-to-date stascs on the percentages
of different ciphers and protocols in use on the 150,000 most popular sites in the world
so you can see trends and understand how widespread worldwide support is for more
secure ciphers and protocols.
• Set the Max Version to Max rather than to a parcular version so that as the protocols
improve, the firewall automacally supports the newest and best protocols. Whether you
intend to aach a Decrypon profile to a Decrypon policy rule that governs inbound (SSL
Inbound Inspecon) or outbound (SSL Forward Proxy) traffic, avoid allowing weak algorithms.
If your Decrypon policy supports mobile applicaons, many of which use pinned
cerficates, set the Max Version to TLSv1.2. Because TLSv1.3 encrypts cerficate
informaon that was not encrypted in previous TLS versions, the firewall can’t
automacally add decrypon exclusions based on cerficate informaon, which affects
some mobile applicaons. Therefore, if you enable TLSv1.3, the firewall may drop some
mobile applicaon traffic unless you create a No Decrypon policy for that traffic.
If you know the mobile applicaons you use for business, consider creang a separate
Decrypon policy and profile for those applicaons so that you can enable TLSv1.3 for
all other applicaon traffic.
Key Exchange Algorithms: Leave all three boxes checked (default) to support both RSA and PFS
(DHE and ECDHE) key exchanges unless the minimum version is set to TLSv1.3, which only
supports ECDHE.
To support HTTP/2 traffic, you must leave the ECDHE box checked.
Encrypon Algorithms: When you set the minimum protocol version to TLSv1.2, the older, weaker
3DES and RC4 algorithms are automacally unchecked (blocked). When you set the minimum
protocol version to TLSv1.3, the 3DES, RC4, AES128-CBC, and AES256-CBC algorithms are
automacally blocked. For any traffic for which you must allow a weaker TLS protocol, create a
separate Decrypon profile and apply it only to traffic for that site, and deselect the appropriate
boxes to allow the algorithm. Allowing traffic that uses the 3DES or RC4 algorithms exposes your
network to excessive risk. If blocking 3DES or RC4 prevents you from accessing a site that you
must use for business, create a separate Decrypon profile and policy for that site. Don’t weaken
decrypon for any other sites.
Authencaon Algorithms: The firewall automacally blocks the older, weaker MD5 algorithm.
When TLSv1.3 is the minimum version, the firewall also blocks SHA1. Do not allow MD5
authencated traffic on your network; SHA1 is the weakest authencaon algorithm you should
allow. If no necessary sites use SHA1, block SHA1 traffic to further reduce the aack surface.
SSH Proxy
In an SSH Proxy configuraon, the firewall resides between a client and a server. SSH Proxy
enables the firewall to decrypt inbound and outbound SSH connecons and ensures that aackers
don’t use SSH to tunnel unwanted applicaons and content. SSH decrypon does not require
cerficates and the firewall automacally generates the key used for SSH decrypon when the
Decrypon
firewall boots up. During the boot up process, the firewall checks if there is an exisng key. If
not, the firewall generates a key. The firewall uses the key to decrypt SSH sessions for all virtual
systems configured on the firewall and all SSH v2 sessions.
SSH allows tunneling, which can hide malicious traffic from decrypon. The firewall can’t decrypt
traffic inside an SSH tunnel. You can block all SSH tunnel traffic by configuring a Security policy
rule for the applicaon ssh-tunnel with the Acon set to Deny (along with a Security policy rule to
allow traffic from the ssh applicaon).
SSH tunneling sessions can tunnel X11 Windows packets and TCP packets. One SSH connecon
may contain mulple channels. When you apply an SSH Decrypon profile to traffic, for each
channel in the connecon, the firewall examines the App-ID of the traffic and idenfies the
channel type. The channel type can be:
• session
• X11
• forwarded-tcpip
• direct-tcpip
When the channel type is session, the firewall idenfies the traffic as allowed SSH traffic such
as SFTP or SCP. When the channel type is X11, forwarded-tcpip, or direct-tcpip, the firewall
idenfies the traffic as SSH tunneling traffic and blocks it.
Limit SSH use to administrators who need to manage network devices, log all SSH traffic,
and consider configuring Mul-Factor Authencaon to help ensure that only legimate
users can use SSH to access devices, which reduces the aack surface.
The following figure shows how SSH Proxy decrypon works. See Configure SSH Proxy for how to
enable SSH Proxy decrypon.
When the client sends an SSH request to the server to iniate a session, the firewall intercepts
the request and forwards it to the server. The firewall then intercepts the server response and
Decrypon
forwards it to the client. This establishes two separate SSH tunnels, one between the firewall
and the client and one between the firewall and the server, with firewall funconing as a proxy.
As traffic flows between the client and the server, the firewall checks whether the SSH traffic is
being routed normally or if it is using SSH tunneling (port forwarding). The firewall doesn’t perform
content and threat inspecon on SSH tunnels; however, if the firewall idenfies SSH tunnels, it
blocks the SSH tunneled traffic and restricts the traffic according to configured security policies.
When you configure SSH Proxy, the proxied traffic does not support DSCP code points or
QoS.
SSH Proxy Decrypon Profile

The SSH Proxy Decrypon profile (Objects > Decrypon Profile > SSH Proxy) controls the
session mode checks and failure checks for SSH traffic defined in the SSH Proxy Decrypon
policies to which you aach the profile. The following figure shows the general best pracce
recommendaons for SSH Proxy Decrypon profile sengs, but the sengs you use also depend
on your company’s security compliance rules and local laws and regulaons.
The firewall doesn’t perform content and threat inspecon on SSH tunnels (port
forwarding). However, the firewall disnguishes between the SSH applicaon and the SSH-
tunnel applicaon. If the firewall idenfies SSH tunnels, it blocks the SSH tunneled traffic
and restricts the traffic according to configured security policies.
Unsupported Mode Checks. The firewall supports SSHv2. If you don’t block sessions with
unsupported modes, users receive a warning message if they connect with potenally unsafe
servers, and they can click through that message and reach the potenally dangerous site.
Blocking these sessions protects you from servers that use weak, risky protocol versions and
algorithms:
1. Block sessions with unsupported versions—The firewall has a set of predefined supported
versions. Checking this box blocks traffic with weak versions. Always check this box to block
sessions with the weak protocol versions to reduce the aack surface.
Decrypon
2. Block sessions with unsupported algorithms—The firewall has a set of predefined supported
algorithms. Checking this box blocks traffic with weak algorithms. Always check this box to
block sessions with unsupported algorithms to reduce the aack surface.
Failure Checks:
• Block sessions on SSH errors—Checking this box terminates the session if SSH errors occur.
• Block sessions if resources not available—If you don’t block sessions when firewall processing
resources aren’t available, then encrypted traffic that you want to decrypt enters the network
sll encrypted, risking allowing potenally dangerous connecons. However, blocking sessions
when firewall processing resources aren’t available may affect the user experience by making
sites that users normally can reach temporarily unreachable. Whether to implement failure
checks depends on your company’s security compliance stance and the importance to your
business of the user experience, weighed against ghter security. Alternavely, consider using
firewall models with more processing power so that you can decrypt more traffic.
Profile for No Decrypon

No Decrypon profiles (Objects > Decrypon Profile > No Decrypon) perform server
verificaon checks for traffic that you choose not to decrypt. You aach a No Decrypon profile
to a “No Decrypon” Decrypon policy that defines the traffic to exclude from decrypon. (Don’t
use policy to exclude traffic that you can’t decrypt because a site breaks decrypon for technical
reasons such as a pinned cerficate or mutual authencaon. Instead, add the hostname to the
Decrypon Exclusion List.) The following figure shows the general best pracce recommendaons
for the No Decrypon profile sengs, but the sengs you use also depend on your company’s
security compliance rules and local laws and regulaons.
• Block sessions with expired cerficates—Check this box to block sessions with servers that
have expired cerficates and prevent access to potenally insecure sites. If you don’t check
this box, users can connect with and transact with potenally malicious sites and see warning
messages when they aempt to connect, but the connecon is not prevented.
• Block sessions with untrusted issuers—Check this box to block sessions with servers that have
untrusted cerficate issuers. An untrusted issuer may indicate a man-in-the-middle aack, a
replay aack, or other aack.
Decrypon
Do not aach a No Decrypon profile to Decrypon policies for TLSv1.3 traffic that
you don’t decrypt. Unlike previous versions, TLSv1.3 encrypts cerficate informaon,
so the firewall has no visibility into cerficate data and therefore cannot block sessions
with expired cerficates or untrusted issuers, so the profile has no effect. (The firewall
can perform cerficate checks with TLSv1.2 and earlier because those protocols do not
encrypt cerficate informaon and you should apply a No Decrypon profile to their
traffic.) However, you should create a Decrypon policy for TLSv1.3 traffic that you don’t
decrypt because the firewall doesn’t log undecrypted traffic unless a Decrypon policy
controls that traffic.
(Applies to TLSv1.2 and earlier) If you choose to allow sessions with untrusted issuers (not
recommended) and only Block sessions with expired cerficates, there is a scenario in
which a session with a trusted, expired issuer may be blocked inadvertently. When the
firewall’s cerficate store contains a valid, self-signed Trusted CA and the server sends an
expired CA in the cerficate chain, the firewall does not check its cerficate store. Instead,
the firewall blocks the session based on the expired CA when it should find the trusted,
valid alternave trust anchor and allow the session based on that trusted self-signed
cerficate.
To avoid this scenario, in addion to Block sessions with expired cerficates, enable Block
sessions with untrusted issuers. This forces the firewall to check its cerficate store, find
the self-signed Trusted CA, and allow the session.
SSL Decrypon for Ellipcal Curve Cryptography (ECC) Cerficates

The firewall automacally decrypts SSL traffic from websites and applicaons using ECC
cerficates, including Ellipcal Curve Digital Signature Algorithm (ECDSA) cerficates. As
organizaons transion to using ECC cerficates to benefit from the strong keys and small
cerficate size, you can connue to maintain visibility into and safely enable ECC-secured
applicaon and website traffic.
Decrypon for websites and applicaons using ECC cerficates is not supported for traffic
that is mirrored to the firewall; encrypted traffic using ECC cerficates must pass through
the firewall directly for the firewall to decrypt it.
You can use a hardware security module (HSM) to store the private keys associated with
ECDSA cerficates. For TLSv1.3 traffic, PAN-OS supports HSMs only for SSL Forward
Proxy. It does not support HSMs for SSL Inbound Inspecon.
Perfect Forward Secrecy (PFS) Support for SSL Decrypon

PFS is a secure communicaon protocol that prevents the compromise of one encrypted session
from leading to the compromise of mulple encrypted sessions. With PFS, a server generates
unique private keys for each secure session it establishes with a client. If a server private key is
compromised, only the single session established with that key is vulnerable—an aacker cannot
retrieve data from past and future sessions because the server establishes each connected with
a uniquely generated key. The firewall decrypts SSL sessions established with PFS key exchange
algorithms, and preserves PFS protecon for past and future sessions.
Decrypon
Support for Diffie-Hellman (DHE)-based PFS and ellipcal curve Diffie-Hellman (ECDHE)-
based PFS is enabled by default (Objects > Decrypon Profile > SSL Decrypon > SSL Protocol
Sengs).
If you use the DHE or ECDHE key exchange algorithms to enable PFS support for SSL
decrypon, you can use a hardware security module (HSM) to store the private keys for
SSL Inbound Inspecon.
When you configure SSL Inbound Inspecon and use a PFS cipher, session resumpon is
not supported.
SSL Decrypon and Subject Alternave Names (SANs)

Some browsers require server cerficates to use a Subject Alternave Name (SAN) to specify
the domains the cerficate protects, and no longer support cerficate matching based on a
server cerficate Common Name (CN). SANs enable a single server cerficate to protect mulple
names; CNs are less well-defined than SANs and can protect only a single domain or all first-
level subdomains on a domain. However, if a server cerficates contains only a CN, browsers that
require a SAN will not allow end users to connect to the requested web resource.The firewall can
add a SAN to the impersonaon cerficate it generates to establish itself as a trusted third-party
during SSL decrypon. When a server cerficate contains only a CN, a firewall performing SSL
decrypon copies the server cerficate CN to the impersonaon cerficate SAN. The firewall
presents the impersonaon cerficate with the SAN to the client, and the browser is able to
support the connecon. End users can connue to access the resources they need, and the
firewall can decrypt the sessions.
To enable SAN support for decrypted SSL traffic, update the decrypon profile aached to the
relevant decrypon policy: select Objects > Decrypon Profile > SSL Decrypon > SSL Forward
Proxy > Append cerficate’s CN value to SAN extension).
Decrypon
TLSv1.3 Decrypon
You can decrypt, gain full visibility into, and prevent known and unknown threats in TLSv1.3
traffic. TLSv1.3 is the latest version of the TLS protocol, which provides applicaon security and
performance improvements. Your exisng Decrypon policies work with TLSv1.3 when you
configure the associated Decrypon profile to use TLSv1.3 as the minimum protocol version or to
use TLSv1.3 or Max as the maximum protocol version. The firewall supports TLSv1.3 decrypon
for Forward Proxy, Inbound Inspecon, decrypted Network Packet Broker traffic, and Decrypon
Port Mirroring.
To use TLSv1.3, the client and server must be able to negoate TLSv1.3 ciphers. For websites that
don’t support TLSv1.3, the firewall selects an older version of the TLS protocol that the server
supports.
The firewall supports the following decrypon algorithms for TLSv1.3:
• TLS13-AES-128-GCM-SHA256
• TLS13-AES-256-GCM-SHA384
• TLS13-CHACHA20-POLY1305-SHA256
If the Decrypon profile you apply to decrypted traffic specifies the protocol’s Max Version as
Max, then the profile supports TLSv1.3 and automacally uses TLSv1.3 with sites that support
TLSv1.3. Otherwise, to support TLSv1.3, set the Max Version to Max. When you upgrade to PAN-
OS 10.0, all Decrypon profiles with the Max Version set to Max are reset to TLSv1.2 to provide
automac support for mobile applicaons that use pinned cerficates and prevent that traffic
from dropping.
Decrypon
Not all applicaons support the TLSv1.3 protocol. Follow decrypon best pracces, set the Min
Version of the TLS protocol to TLSv1.2, and leave the Max Version seng as Max. If business
needs require allowing a weaker TLS protocol, create a separate SSL Decrypon profile with a
Min Version that allows the weaker protocol and aach it to a Decrypon policy that defines the
traffic you need to allow with the weaker TLS protocol.
If your Decrypon policy supports mobile applicaons, many of which use pinned cerficates,
set the Max Version to TLSv1.2. Because TLSv1.3 encrypts cerficate informaon that was not
encrypted in previous TLS versions, the firewall can’t automacally add decrypon exclusions
based on cerficate informaon, which affects some mobile applicaons. Therefore, if you enable
TLSv1.3, the firewall may drop some mobile applicaon traffic unless you create a No Decrypon
policy for that traffic. If you know the mobile applicaons you use for business, consider creang
a separate Decrypon policy and profile for those applicaons so that you can enable TLSv1.3 for
all other traffic.
Do not aach a No Decrypon profile to Decrypon policies for TLSv1.3 traffic that
you don’t decrypt if you know that a parcular policy controls only TLSv1.3 traffic. A
change from previous TLS versions is that TLSv1.3 encrypts cerficate informaon, so
the firewall no longer has visibility into that data and therefore cannot block sessions
with expired cerficates or untrusted issuers, so the profile has no effect. (The firewall
can perform cerficate checks with TLSv1.2 and earlier because those protocols do not
encrypt cerficate informaon and you should apply a No Decrypon profile to their
traffic.) However, you can log undecrypted traffic of all types by enabling logging successful
and unsuccessful TLS handshakes in the Decrypon policy (logging unsuccessful TLS
handshakes is enabled by default).
When you allow unsupported modes in the SSL Protocol Sengs Decrypon Profile, the firewall
automacally adds the traffic to the Local Decrypon Exclusion Cache. The firewall sll decrypts
and inspects traffic that is downgraded from TLSv1.3 to TLSv1.2 and the Reason shown in the
cache for adding the server to the cache is TLS13_UNSUPPORTED.
If you downgrade from PAN-OS 10.1 to a previous version, any Decrypon profile that specifies
TLSv1.3 as the Min Version or the Max Version changes to the highest supported version. For
example, downgrading from PAN-OS 10.1 to PAN-OS 9.1 would replace TLSv1.3 with TLSv1.2. If
a Panorama device on PAN-OS 10.1 pushes the configuraon to devices that run older versions
of PAN-OS, any Decrypon profile that specified TLSv1.3 as the Min Version or the Max Version
also changes to highest supported version.
For customers who use Hardware Security Modules (HSMs), PAN-OS supports TLSv1.3
only for SSL Forward Proxy. It does not support HSMs for SSL Inbound Inspecon.
You can configure an SSL Decrypon profile that sets TLSv1.3 as the minimum allowed protocol
version to achieve the ghtest security. However, some applicaons don’t support TLSv1.3 and
may not work if TLSv1.3 is the minimum allowed protocol. Apply a profile that sets TLSv1.3 as the
minimum version only to applicaon traffic that only supports TLSv1.3.
1. Create a new SSL Decrypon profile or edit an exisng profile (Objects > Decrypon >
Decrypon Profile).
If the profile is new, specify a profile Name.
2. Select SSL Protocol Sengs.
Decrypon
3. Change the Min Version to TLSv1.3.
Using Max for the Max Version ensures that the traffic which the profile controls can use the
strongest available protocol version. Min Version sets the weakest version of the protocol that
the traffic can use. Seng the minimum version to TLSv1.3 means that the traffic must use
TLSv1.3 (or greater) and that weaker protocol versions are blocked. (The Decrypon Policy rule
defines the traffic the profile controls.)
When you configure TLSv1.3 as the Min Version, you must use Perfect Forward Secrecy (PFS)
and the weaker key exchange, encrypon, and authencaon algorithms are not available.
4. Configure any other Decrypon profile sengs you need to set or change.
6. Aach the profile to the appropriate Decrypon Policy rule to apply it to the appropriate
traffic.
High Availability Support for Decrypted Sessions

The firewall supports High Availability (HA) sync only for inbound, decrypted SSL sessions, and
only if the sessions were established using non-PFS key exchange algorithms. The firewall does
not support HA sync for any other decrypted traffic. The firewall decrypts new sessions that start
aer the failover based on Decrypon policy.
The following table shows HA sync support for decrypted sessions aer a failover:
Decrypon
Session Type PFS Key Exchange Non-PFS Key Exchange
Inbound SSL Session No HA Sync, firewall drops HA Sync occurs, firewall

(Inbound Inspecon the session allows the session but does
Decrypon) not decrypt the session
Outbound SSL Sessions (SSL No HA Sync, firewall drops No HA Sync, firewall drops
Forward Proxy Decrypon) the session the session
Decrypon Mirroring
Decrypon mirroring creates a copy of decrypted traffic from a firewall and sends it to a traffic
collecon tool such as NetWitness or Solera, which can receive raw packet captures for archiving
and analysis. Organizaons that require comprehensive data capture for forensic and historical
purposes or for data leak prevenon (DLP) can install a free license to enable the feature.
Aer you install the license, connect the traffic collecon tool directly to an Ethernet interface on
the firewall and set the Interface Type to Decrypt Mirror. The firewall simulates a TCP handshake
with the collecon tool and then sends every data packet through that interface, decrypted (as
cleartext).
Decrypon port mirroring is not available on the VM-Series for public cloud plaorms
(AWS, Azure, Google Cloud Plaorm) and VMware NSX.
Keep in mind that the decrypon, storage, inspecon, and/or use of SSL traffic is governed in
certain countries and user consent might be required in order to use the decrypon mirror feature.
Addionally, use of this feature could enable malicious users with administrave access to the
firewall to harvest usernames, passwords, social security numbers, credit card numbers, or other
sensive informaon submied using an encrypted channel. Palo Alto Networks recommends that
you consult with your corporate counsel before acvang and using this feature in a producon
environment.
The following graphic shows the process for mirroring decrypted traffic and the secon Configure
Decrypon Port Mirroring describes how to license and enable this feature.
Decrypon
Prepare to Deploy Decrypon

The most me-consuming part of deploying decrypon isn’t configuring the decrypon policies
and profiles, it’s preparing for the deployment by working with stakeholders to decide what traffic
to decrypt and not to decrypt, educang your user populaon about changes to website access,
developing a private key infrastructure (PKI) strategy, and planning a staged, priorized rollout.
Set goals for decrypon and review Decrypon planning best pracces checklist to ensure that
you understand the recommended best pracces. The best pracce goal is to decrypt as much
traffic as your firewall resources permit and decrypt the most important traffic first.
Migrate from port-based to applicaon-based Security policy rules before you create
and deploy Decrypon policy rules. If you create Decrypon rules based on port-based
Security policy and then migrate to applicaon-based Security policy, the change could
cause the Decrypon rules to block traffic that you intend to allow because Security policy
rules are likely to use applicaon default ports to prevent applicaon traffic from using
non-standard ports. For example, traffic idenfied as web-browsing applicaon traffic
(default port 80) may have underlying applicaons that have different default ports, such
as HTTPS traffic (default port 443). The applicaon-default rule blocks the HTTPS traffic
because it sees the decrypted traffic using a “non-standard” port (443 instead of 80).
Migrang to App-ID based rules before deploying decrypon means that when you test
your decrypon deployment in POCs, you’ll discover Security policy misconfiguraon and
fix it before rolling it out to the general user populaon.
To prepare to deploy Decrypon:

• Work with Stakeholders to Develop a Decrypon Deployment Strategy
• Develop a PKI Rollout Plan
• Size the Decrypon Firewall Deployment
• Plan a Staged, Priorized Deployment
Work with Stakeholders to Develop a Decrypon Deployment

Strategy
Work with stakeholders such as legal, finance, HR, execuves, security, and IT/support to develop
a decrypon deployment strategy. Start by geng the required approvals to decrypt traffic to
secure the corporaon. Decrypng traffic involves understanding how legal regulaons and
business needs affect what you can and can’t decrypt.
Idenfy and priorize the traffic you want to decrypt. The best pracce is to decrypt as much
traffic as you can to gain visibility into potenal threats in encrypted traffic and prevent those
threats. If incorrect firewall sizing prevents you from decrypng all of the traffic you want to
decrypt, priorize the most crical servers, the highest-risk traffic categories, and less trusted
segments and IP subnets. To help priorize, ask yourself quesons such as, “What happens if
this server is compromised?” and “How much risk am I willing to take in relaon to the level of
performance I want to achieve?”
Decrypon
Next, idenfy traffic that you can’t decrypt because the traffic breaks decrypon for technical
reasons such as a pinned cerficate, an incomplete cerficate chain, unsupported ciphers, or
mutual authencaon. Decrypng sites that break decrypon technically results in blocking that
traffic. Evaluate the websites that break decrypon technically and ask yourself if you need access
to those sites for business reasons. If you don’t need access to those sites, allow decrypon to
block them. If you need access to any of those sites for business purposes, add them to the SSL
Decrypon Exclusion list to except them from decrypon. The SSL Decrypon Exclusion list is
exclusively for sites that break decrypon technically.
Idenfy sensive traffic that you choose not to decrypt for legal, regulatory, personal, or other
reasons, such as financial, health, or government traffic, or the traffic of certain execuves. This is
not traffic that breaks decrypon technically, so you don’t use the SSL Decrypon Exclusion list
to except this traffic from decrypon. Instead, you Create a Policy-Based Decrypon Exclusion
to idenfy and control traffic you choose not to decrypt and apply the No Decrypon decrypon
profile to the policy to prevent servers with cerficate issues from accessing the network. Policy-
based decrypon exclusions are only for traffic you choose not to decrypt.
When you plan decrypon policy, consider your company’s security compliance rules, computer
usage policy, and your business goals. Extremely strict controls can impact the user experience
by prevenng access to non-business sites the user used to access, but may be required for
government or financial instuons. There is always a tradeoff between usability, management
overhead, and security. The ghter the decrypon policy, the greater the chance that a website
will become unreachable, which may result in user complaints and possibly modifying the
rulebase.
Although a ght decrypon policy may inially cause a few user complaints, those
complaints can draw your aenon to unsanconed or undesirable websites that are
blocked because they use weak algorithms or have cerficate issues. Use complaints as a
tool to beer understand the traffic on your network.
Different groups of users and even individual users may require different decrypon policies, or
you may want to apply the same decrypon policy to all users. For example, execuves may be
exempted from decrypon policies that apply to other employees. And you may want to apply
different decrypon policies to employee groups, contracts, partners, and guests. Prepare updated
legal and HR computer usage policies to distribute to all employees, contractors, partners, guests,
and any other network users so that when you roll out decrypon, users understand their data can
be decrypted and scanned for threats.
Decrypon
How you handle guest users depends on the access they require. Isolate guests from the
rest of your network by placing them on a separate VLAN and on a separate SSID for
wireless access. If guests don’t need to access your corporate network, don’t let them on it
and there will be no need to decrypt their traffic. If guests need to access your corporate
network, decrypt their traffic:
• Enterprises don’t control guest devices. Decrypt guest traffic and subject it to your
guest Security policy so the firewall can inspect the traffic and prevent threats. To
do this, redirect guest users through an Authencaon Portal, instruct them how to
download and install the CA cerficate, and clearly nofy guests that their traffic
will be decrypted. Include the process in your company’s privacy and computer usage
policy.
• Create separate Decrypon policy rules and Security policy rules to ghtly control
guest access so that guests can only access the areas of your network that they need to
access.
Similarly to different groups of users, decide which devices to decrypt and which applicaons
to decrypt. Today’s networks support not only corporate devices, but BYOD, mobile, remote-
user and other devices, including contractor, partner, and guest devices. Today’s users aempt to
access many sites, both sanconed and unsanconed, and you should decide how much of that
traffic you want to decrypt.
Enterprises don’t control BYOD devices. If you allow BYOD devices on your network,
decrypt their traffic and subject it to the same Security policy that you apply to other
network traffic so the firewall can inspect the traffic and prevent threats. To do this,
redirect BYOD users through an Authencaon Portal, instruct them how to download
and install the CA cerficate, and clearly nofy users that their traffic will be decrypted.
Educate BYOD users about the process and include it in your company’s privacy and
computer usage policy.
Decide what traffic you want to log and invesgate what traffic you can log. Be aware of local
laws regarding what types of data you can log and store, and where you can log and store the
data. For example, local laws may prevent logging and storing personal informaon such as health
and financial data.
Decide how to handle bad cerficates. For example, will you block or allow sessions for which the
cerficate status is unknown? Understanding how you want to handle bad cerficates determines
how you configure the decrypon profiles that you aach to decrypon policies to control which
sessions you allow based on the server cerficate verificaon status.
Develop a PKI Rollout Plan

Plan how to roll out your public key infrastructure (PKI). Network devices need an SSL Forward
Trust CA cerficate for trusted sites and an SSL Forward Untrust CA cerficate for untrusted
sites. Generate separate Forward Trust and Forward Untrust cerficates (do not sign the Forward
Untrust cerficate with the Enterprise Root CA because you want the Untrust cerficate to warn
users that they are trying to access potenally unsafe sites). Palo Alto Networks next-generaon
firewalls have two methods of generang CA cerficates for SSL decrypon:
• Generate the SSL CA cerficates from your Enterprise Root CA as subordinate cerficates—
If you have an exisng Enterprise PKI, this is the best pracce. Generang a subordinate
Decrypon
cerficate from your Enterprise Root CA makes the rollout easier and smoother because
network devices already trust the Enterprise Root CA, so you avoid any cerficate issues when
you begin the deployment phase. If you don’t have an Enterprise Root CA, consider geng one.
• Generate a self-signed Root CA cerficate on the firewall and create subordinate CA
cerficates on that firewall—If you don’t have an Enterprise Root CA, this method provides a
self-signed Root CA cerficate and the subordinate Forward Trust and Untrust CA cerficates.
With this method, you need to install the self-signed cerficates on all of your network devices
so that those devices recognize the firewall’s self-signed cerficates. Because the cerficates
must be deployed to all devices, this method is beer for small deployments and proof-of-
concept (POC) trials than for large deployments.
Do not export the Forward Untrust cerficate to the Cerficate Trust Lists of your network
devices! This is crical because installing the Untrust cerficate in the Trust List results
in devices trusng websites that the firewall does not trust. In addion, users won’t see
cerficate warnings for untrusted sites, so they won’t know the sites are untrusted and
may access those sites, which could expose your network to threats.
Regardless of whether you generate Forward Trust cerficates from your Enterprise
Root CA or use a self-signed cerficate generated on the firewall, generate a separate
subordinate Forward Trust CA cerficate for each firewall. The flexibility of using separate
subordinate CAs enables you to revoke one cerficate when you decommission a device
(or device pair) without affecng the rest of the deployment and reduces the impact in any
situaon in which you need to revoke a cerficate. Separate Forward Trust CAs on each
firewall also helps troubleshoot issues because the CA error message the user sees includes
informaon about the firewall the traffic is traversing. If you use the same Forward Trust
CA on every firewall, you lose the granularity of that informaon.
There is no benefit to using different Forward Untrust cerficates on different firewalls, so you can
use the same Forward Untrust cerficate on all firewalls. If you need addional security for your
private keys, consider storing them on an HSM.
You may need to make special accommodaons for guest users. If guest users don’t need access
to your corporate network, don’t allow access, and then you won’t have to decrypt their traffic or
create infrastructure to support guest access. If you need to support guest users, discuss with your
legal department whether you can decrypt guest traffic.
If you can decrypt guest traffic, treat guests similarly to the way you treat BYOD devices. Decrypt
guest traffic and subject it to the same Security policy that you apply to other network traffic. Do
this by redirecng guest users through an Authencaon Portal, instruct them how to download
and install the CA cerficate, and clearly nofy users that their traffic will be decrypted. Include
the process in your company’s privacy and computer usage policy. In addion, restrict guest traffic
to only the areas guests need to access.
If you can’t decrypt guest traffic for legal reasons, then isolate guest traffic and prevent it from
moving laterally in your network:
• Create a separate zone for guests and restrict guest access to that zone. To prevent lateral
movement, don’t allow guest access to other zones.
• Allow only sanconed applicaons, use URL filtering to prevent access to risky URL categories,
and apply the best pracce Security profiles.
Decrypon
• Apply a No Decrypt decrypon policy and profile to prevent guests from accessing websites
with unknown or expired CAs.
All employees, contractors, partners, and other users should use your normal corporate
infrastructure and you should decrypt and inspect their traffic.
Size the Decrypon Firewall Deployment

Decrypng encrypted traffic consumes firewall CPU resources and can affect throughput. In
general, the ghter the security (the more SSL traffic you decrypt combined with the more
stringent your protocol sengs), the more firewall resources decrypon consumes. Work with
your Palo Alto Networks SE/CE to size your firewall deployment and avoid sizing mistakes. Factors
that affect decrypon resource consumpon and therefore how much traffic the firewall can
decrypt include:
• The amount of SSL traffic you want to decrypt. This varies from network to network. For
example, some applicaons must be decrypted to prevent the injecon of malware or exploits
into the network or unauthorized data transfers, some applicaons can’t be decrypted
due to local laws and regulaons or business reasons, and other applicaons are cleartext
(unencrypted) and don’t need to be decrypted. The more traffic you want to decrypt, the more
resources you need.
• The TLS protocol version. Higher versions are more secure but consume more resources. Use
the highest TLS protocol version you can to maximize security.
• The key size. The larger the key size, the beer the security, but also the more resources the
key processing consumes.
• The key exchange algorithm. Perfect Forward Secrecy (PFS) ephemeral key exchange
algorithms such as Diffie-Hellman Ephemeral (DHE) Ellipc-Curve Diffie-Hellman Exchange
(ECDHE) consume more processing resources than Rivest-Shamir-Adleman (RSA) algorithms.
PFS key exchange algorithms provide greater security than RSA key exchange algorithms
because the firewall has to generate a new cipher key for each session—but generang the new
key consumes more firewall resources. However, if an aacker compromises a session key, PFS
prevents the aacker from using it to decrypt any other sessions between the same client and
server and RSA does not.
• The encrypon algorithm. The key exchange algorithm determines whether the encrypon
algorithm is PFS or RSA.
• The cerficate authencaon method. RSA (not the RSA key exchange algorithm) consumes
less resources than Ellipc Curve Digital Signature Algorithm (ECDSA) but ECDSA is more
secure.
The combinaon of the key exchange algorithm and the cerficate authencaon
method affect throughput performance as shown in RSA and ECDSA benchmark tests.
The performance cost of PFS trades off against the higher security that PFS achieves,
but PFS may not be needed for all types of traffic. You can save firewall CPU cycles
by using RSA for traffic that you want to decrypt and inspect for threats but that isn’t
sensive.
• Average transacon sizes. For example, small average transacon sizes consume more
processing power to decrypt. Measure the average transacon size of all traffic, then measure
the average transacon size of traffic on port 443 (the default port for HTTPS encrypted traffic)
Decrypon
to understand the proporon of encrypted traffic going to the firewall in relaon to your total
traffic and the average transacon sizes. Eliminate anomalous outliers such as unusually large
transacons to get a truer measurement of average transacon size.
• The firewall model and resources. Newer firewall models have more processing power than
older models.
The combinaon of these factors determines how decrypon consumes firewall processing
resources. To best ulize the firewall’s resources, understand the risks of the data you’re
protecng. If firewall resources are an issue, use stronger decrypon for higher-priority traffic and
use less processor-intensive decrypon to decrypt and inspect lower-priority traffic unl you can
increase the available resources. For example, you could use RSA instead of ECDHE and ECDSA
for traffic that isn’t sensive or high-priority to preserve firewall resources for using PFS-based
decrypon for higher priority, sensive traffic. (You’re sll decrypng and inspecng the lower-
priority traffic, but trading off consuming fewer computaonal resources with using algorithms
that aren’t as secure as PFS.) The key is to understand the risks of different traffic types and treat
them accordingly.
Measure firewall performance so that you understand the currently available resources, which
helps you understand whether you need more firewall resources to decrypt the traffic you want to
decrypt. Measuring firewall performance also sets a baseline for performance comparisons aer
deploying decrypon.
When you size the firewall deployment, base it not only on your current needs, but also on your
future needs. Include headroom for the growth of decrypon traffic because Gartner predicts that
through 2019, more than 80 percent of enterprise web traffic will be encrypted, and more than 50
percent of new malware campaigns will use various forms of encrypon. Work with your Palo Alto
Networks representaves and take advantage of their experience in sizing firewalls to help you
size your firewall decrypon deployment.
Plan a Staged, Priorized Deployment

Plan to roll out decrypon in a controlled manner, piece by piece. Don’t roll out your enre
decrypon deployment at one me. Test and ensure that decrypon is working as planned and
that users understand what you are doing and why. Rolling out decrypon in this manner makes
it easier to troubleshoot in case anything doesn’t work as expected and helps users adjust to the
changes.
Educang stakeholders, employees, and other users such as contractors and partners is crical
because decrypon sengs may change their ability to access some websites. Users should
understand how to respond to situaons in which previously reachable websites become
unreachable and what informaon to give technical support. Support should understand what is
being rolled out when and how to help users who encounter issues. Before you roll out decrypon
to the general populaon:
• Idenfy early adopters to help champion decrypon and who will be able to help other
employees who have quesons during the full rollout. Enlist the help of department managers
and help them understand the benefits of decrypng traffic.
• Set up proof-of-concept (POC) trials in each department with early adopters and other
employees who understand why decrypng traffic is important. Educate POC parcipants
about the changes and how to contact technical support if they run into issues. In this way,
decrypon POCs become an opportunity to work with technical support to POC how to
Decrypon
support decrypon and to develop the most painless method for supporng the general rollout.
The interacon between POC users and technical support also allows you to fine-tune policies
and how to communicate with users.
POCs enable you to experiment with priorizing what to decrypt first, so that when you phase
in decrypon in the general populaon, your POC experience helps you understand how to
phase in decrypng different URL Categories. Measure the way decrypon affects firewall
CPU and memory ulizaon to help understand if the firewall sizing is correct or if you need to
upgrade. POCs can also reveal applicaons that break decrypon technically (decrypng them
blocks their traffic) and need to be added to the Decrypon Exclusion list.
When you set up POCs, also set up a user group that can cerfy the operaonal readiness and
procedures prior to the general rollout.
• Educate the user populaon before the general rollout, and plan to educate new users as they
join the company. This is a crical phase of deploying decrypon because the deployment
may affect websites that users previously visited but are not safe, so those sites are no longer
reachable. The POC experience helps idenfy the most important points to communicate.
• Phase in decrypon. You can accomplish this several ways. You can decrypt the highest priority
traffic first (for example, the URL Categories most likely to harbor malicious traffic, such as
gaming) and then decrypt more as you gain experience. Alternavely, you can take a more
conservave approach and decrypt the URL Categories that don’t affect your business first
(so if something goes wrong, no issues occur that affect business), for example, news feeds.
In all cases, the best way to phase in decrypon is to decrypt a few URL Categories, take user
feedback into account, run reports to ensure that decrypon is working as expected, and then
gradually decrypt a few more URL Categories and verify, and so on. Plan to make Decrypon
Exclusions to exclude sites from decrypon if you can’t decrypt them for technical reasons or
because you choose not to decrypt them.
If you Enable Users to Opt Out of SSL Decrypon (users see a response page that allows them
either to opt out of decrypon and end the session without going to the site or to proceed to
the site and agree to have the traffic decrypted), educate them about what it is, why they’re
seeing it, and what their opons are.
• Create realisc deployment schedules that allow me to evaluate each stage of the rollout.
Place firewalls in posions where they can see all of the network traffic so that no
encrypted traffic inadvertently gains access to your network because it bypasses the
firewall.
Decrypon
Define Traffic to Decrypt

A Decrypon policy rule allows you to define traffic that you want the firewall to decrypt and
to define traffic that you choose to exclude from decrypon because the traffic is personal or
because of local regulaons, for example.
Aach a Decrypon profile to each Decrypon policy rule to enable cerficate checks, session
mode checks, failure checks, and protocol and algorithm checks, depending on the profile. These
checks prevent risky connecons, such as sessions with untrusted cerficate issuers, weak
protocols, ciphers, and algorithms, and servers that have cerficate issues.
Review the Decrypon deployment best pracces checklist to ensure that you
understand the recommended best pracces.
Block known dangerous URL Filtering categories such as malware, phishing, dynamic-dns,
unknown, command-and-control, proxy-avoidance-and-anonymizers, copyright-infringement,
extremism, newly-registered-domain, grayware, and parked. If you must allow any of these
categories for business reasons, decrypt them and apply strict Security profiles to the traffic.
URL categories that you should always decrypt if you allow them include: online-storage-and-
backup, web-based-email, web-hosng, personal-sites-and-blogs, and content-delivery-networks.
In Security policy, block Quick UDP Internet Connecons (QUIC) protocol unless for
business reasons, you want to allow encrypted browser traffic. Chrome and some other
browsers establish sessions using QUIC instead of TLS, but QUIC uses proprietary
encrypon that the firewall can’t decrypt, so potenally dangerous traffic may enter the
network as encrypted traffic. Blocking QUIC forces the browser to fall back to TLS and
enables the firewall to decrypt the traffic.
Create a Security policy rule to block QUIC on its UDP service ports (80 and 443) and
create a separate rule to block the QUIC applicaon. For the rule that blocks UDP ports
80 and 443, create a Service (Objects > Services) that includes UDP ports 80 and 443:
Use the Service to specify the UDP ports to block for QUIC. In the second rule, block the
QUIC applicaon:
• Create a Decrypon Profile
Decrypon
• Create a Decrypon Policy Rule
Create a Decrypon Profile

A decrypon profile allows you to perform checks on both decrypted traffic and SSL traffic that
you choose to exclude from decrypon. (If a server breaks SSL decrypon technically due to
cerficate pinning or other reasons, add the server to the Decrypon Exclusion list.) Depending on
your needs, create Decrypon profiles to:
• Block sessions based on cerficate status, including blocking sessions with expired cerficates,
untrusted issuers, unknown cerficate status, cerficate status check meouts, and cerficate
extensions.
• Block sessions with unsupported versions and cipher suites, and that require using client
authencaon.
• Block sessions if the resources to perform decrypon are not available or if a hardware security
module is not available to sign cerficates.
• Define the protocol versions and key exchange, encrypon, and authencaon algorithms
allowed for SSL Forward Proxy and SSL Inbound Inspecon traffic in the SSL Protocol Sengs.
Don’t weaken the main Decrypon profile that you apply to most sites to accommodate weaker
sites. Instead, create one or more separate Decrypon profiles for sites that you need to support
but that don’t support strong ciphers and algorithms. You can also create different Decrypon
profiles for different URL Categories to fine tune security vs. performance for traffic that contains
no sensive material; however, you should always decrypt and inspect all the traffic you can.
Aer you create a decrypon profile, aach it to a decrypon policy rule; the firewall then
enforces the decrypon profile sengs on traffic that matches the decrypon policy rule.
Palo Alto Networks firewalls include a default decrypon profile that you can use to enforce the
basic recommended protocol versions and cipher suites for decrypted traffic. However, the best
pracce is to enable ghter decrypon controls as described in SSL Forward Proxy Decrypon
Profile, SSL Inbound Inspecon Decrypon Profile, and SSL Protocol Sengs Decrypon Profile.
Avoid supporng weak protocols or algorithms because they contain known vulnerabilies
that aackers can exploit. If you must allow a weaker protocol or algorithm to support a
key partner or contractor who uses legacy systems with weak protocols, create a separate
Decrypon profile for the excepon and aach it to a Decrypon policy rule that applies
the profile only to the relevant traffic (for example, the source IP address of the partner).
Don’t allow the weak protocol for all traffic.
STEP 1 | Create a new decrypon profile.

Select Objects > Decrypon Profile, Add or modify a decrypon profile rule, and give the rule
a descripve Name.
STEP 2 | (Oponal) Allow the profile rule to be Shared across every virtual system on a firewall or
every Panorama device group.
Decrypon
STEP 3 | (Decrypon Mirroring Only) Enable an Ethernet Interface for the firewall to use to copy and
forward decrypted traffic.
Separate from this task, follow the steps to Configure Decrypon Port Mirroring. Be aware of
local privacy regulaons that may prohibit mirroring or control the type of traffic that you can
mirror. Decrypon port mirroring requires a decrypon port mirror license.
STEP 4 | (Oponal) Block and control SSL tunneled and/or inbound traffic:
Although applying a Decrypon profile to decrypted traffic is oponal, it is a best

pracce to always apply a Decrypon profile to the policy rules to protect your network
against encrypted threats. You can’t protect yourself against threats you can’t see.
Select SSL Decrypon:

• Select SSL Forward Proxy to configure the sengs to verify cerficates, enforce protocol
versions and cipher suites, and perform failure checks on SSL decrypted traffic. These
sengs are acve only when this profile is aached to a decrypon policy rule configured
to perform SSL Forward Proxy decrypon.
• Select SSL Inbound Inspecon to configure the sengs to enforce protocol versions and
cipher suites and to perform failure checks on inbound SSL traffic. These sengs are acve
only when this profile is aached to a decrypon policy rule that performs SSL Inbound
Inspecon.
• Select SSL Protocol Sengs to configure the sengs that control minimum and maximum
protocol versions and key exchange, encrypon, and authencaon algorithms to
enforce on decrypted SSL traffic. These sengs are acve when this profile is aached to
decrypon policy rules that are set to perform either SSL Forward Proxy decrypon or SSL
Inbound Inspecon.
If the firewall is in FIPS-CC mode and managed by a Panorama™ management

server in standard mode, a decrypon profile must be created locally on the firewall.
Decrypon profiles created on Panorama in standard mode contain references to
3DES and RC4 encrypon algorithms and MD5 authencaon algorithm that are not
supported and cause pushes to the managed firewall to fail.
STEP 5 | (Oponal) Block and control traffic (for example, a URL category) for which you choose to
Create a Policy-Based Decrypon Exclusion.
Although applying a Decrypon profile to traffic that you choose not to decrypt is
oponal, it is a best pracce to always apply a Decrypon profile to the policy rules to
protect your network against sessions with expired cerficates or untrusted issuers.
Select No Decrypon to configure the Profile for No Decrypon and check the Block
sessions with expired cerficates and Block sessions with untrusted issuers boxes to validate
cerficates for traffic that is excluded from decrypon. Create policy-based exclusions only for
traffic that you choose not to decrypt. If a server breaks decrypon for technical reasons, don’t
create a policy-based exclusion, add the server to the SSL Decrypon Exclusion list (Device >
Cerficate Management > SSL Decrypon Exclusion).
These seng are acve only when the decrypon profile is aached to a decrypon policy rule
that disables decrypon for certain traffic.
Decrypon
STEP 6 | (Oponal) Block and control decrypted SSH traffic.

Select SSH Proxy to configure the SSH Proxy Decrypon Profile and configure sengs to
enforce supported protocol versions and to block sessions if system resources are not available
to perform decrypon.
These sengs are acve only when the decrypon profile is aached to a decrypon policy
rule that decrypts SSH traffic.
STEP 7 | Add the decrypon profile when you Create a Decrypon Policy Rule.
The firewall applies the decrypon profile to and enforces the profile’s sengs on the traffic
that matches the decrypon policy rule.
Create a Decrypon Policy Rule

Create a decrypon policy rule to define traffic for the firewall to decrypt and the type of
decrypon you want the firewall to perform: SSL Forward Proxy, SSL Inbound Inspecon, or SSH
Proxy decrypon. You can also use a decrypon policy rule to define Decrypon Mirroring.
STEP 1 | Add a new decrypon policy rule.
Select Policies > Decrypon, Add a new decrypon policy rule, and give the policy rule a
descripve Name.
STEP 2 | Configure the decrypon rule to match to traffic based on network and policy objects:
• Firewall security zones—Select Source and/or Desnaon and match to traffic based on the
Source Zone and/or the Desnaon Zone.
• IP addresses, address objects, and/or address groups—Select Source and/or Desnaon
to match to traffic based on Source Address and/or the Desnaon Address. Alternavely,
select Negate to exclude the source address list from decrypon.
• Users—Select Source and set the Source User for whom to decrypt traffic. You can decrypt
specific user or group traffic, or decrypt traffic for certain types of users, such as unknown
users or pre-logon users (users that are connected to GlobalProtect but are not yet logged
in).
• Ports and protocols—Select Service/URL Category to set the rule to match to traffic based
on service. By default, the policy rule is set to decrypt Any traffic on TCP and UDP ports.
Decrypon
You can Add a service or a service group, and oponally set the rule to applicaon-default
to match to applicaons only on the applicaon default ports.
The applicaon-default seng can be useful when you Create a Policy-Based

Decrypon Exclusion. You can exclude applicaons running on their default ports
from decrypon, while connuing to decrypt the same applicaons when they are
detected on non-standard ports.
• URLs and URL categories—Select Service/URL Category and decrypt traffic based on:
• An externally-hosted list of URLs that the firewall retrieves for policy-enforcement (see
Objects > External Dynamic Lists).
• Palo Alto Networks predefined URL categories, which make it easy to decrypt enre
categories of allowed traffic. This opon is also useful when you create policy-based
decrypon exclusions because you can exclude sensive sites by category instead of
individually. For example, although you can create a custom URL category to group sites
that you do not want to decrypt, you can also exclude financial or healthcare-related
sites from decrypon based on the predefined Palo Alto Networks URL categories. In
addion, you can block risky URL Categories and create comfort pages to communicate
the reason the sites are blocked or Enable Users to Opt Out of SSL Decrypon.
You can use the predefined high-risk and medium-risk URL categories to create a
Decrypon policy rule that decrypts all high-risk and medium-risk URL traffic. Place the
rule at the boom of the rulebase (all decrypon excepons must be above this rule so
that you don’t decrypt sensive informaon) as a safety net to ensure that you decrypt
and inspect all risky traffic. However, if high-risk or medium-risk sites to which you allow
access contain personally idenfiable informaon (PII) or other sensive informaon
that you don’t want to decrypt, either block those sites to avoid allowing encrypted risky
traffic while also avoiding privacy issues, or create a No Decrypon rule to handle the
sensive traffic.
• Custom URL categories (see Objects > Custom Objects > URL Category). For example,
you can create a custom URL Category to specify a group of sites you need to access for
business purposes but that don’t support the safest protocols and algorithms, and then
apply a customized Decrypon profile to allow the looser protocols and algorithms for
just those sites (that way, you don’t decrease security by downgrading the Decrypon
profile you use for most sites).
Decrypon
STEP 3 | Set the rule to either decrypt matching traffic or to exclude matching traffic from decrypon.
Select Opons and set the policy rule Acon:
To decrypt matching traffic:
1. Set the Acon to Decrypt .
2. Set the Type of decrypon for the firewall to perform on matching traffic:
• SSL Forward Proxy
• SSL Inbound Inspecon. If you want to enable SSL Inbound Inspecon, also select the
Cerficate for the desnaon internal server for the inbound SSL traffic.
• SSH Proxy
To exclude matching traffic from decrypon:
Set the Acon to No Decrypt.
STEP 4 | (Oponal) Select a Decrypon Profile to perform addional checks on traffic that matches
the policy rule.
Although applying a Decrypon profile to decrypted traffic is oponal, it is a best

pracce to always apply a Decrypon profile to the policy rules to protect your network
against encrypted threats. You can’t protect yourself against threats you can’t see.
For example, aach a decrypon profile to a policy rule to ensure that server cerficates are
valid and to block sessions using unsupported protocols or ciphers. To Create a Decrypon
Profile, select Objects > Decrypon Profile.
1. Create a decrypon policy rule or open an exisng rule to modify it.
2. Select Opons and select a Decrypon Profile to block and control various aspects of
the traffic matched to the rule.
The profile rule sengs the firewall applies to matching traffic depends on the policy
rule Acon (Decrypt or No Decrypt) and the policy rule Type (SSL Forward Proxy, SSL
Inbound Inspecon, or SSH Proxy). This allows you to use the different decrypon
profiles with different types of decrypon policy rules that apply to different types of
traffic and users.
3. Click OK.
STEP 5 | Configure Decrypon Logging (configure whether to log both successful and unsuccessful
TLS handshakes and configure Decrypon log forwarding).
STEP 6 | Click OK to save the policy.
Decrypon
STEP 7 | Choose your next step to fully enable the firewall to decrypt traffic...
• ConfigureSSL Forward Proxy
• ConfigureSSL Inbound Inspecon
• ConfigureSSH Proxy
• Create policy-based Decrypon Exclusions for traffic you choose not to decrypt and add
sites that break decrypon for technical reasons such as pinned cerficates or mutual
authencaon to the SSL Decrypon Exclusion list.
Decrypon
Configure SSL Forward Proxy

To enable the firewall to perform SSL Forward Proxy decrypon, you must set up the cerficates
required to establish the firewall as a trusted third party (proxy) to the session between the client
and the server. The firewall can use cerficates signed by an enterprise cerficate authority (CA)
or self-signed cerficates generated on the firewall as Forward Trust cerficates to authencate the
SSL session with the client.
• (Best Pracce) Enterprise CA-signed Cerficates—An enterprise CA can issue a signing
cerficate that the firewall can use to sign the cerficates for sites which require SSL
decrypon. When the firewall trusts the CA that signed the cerficate of the desnaon
server, the firewall can send a copy of the desnaon server cerficate to the client, signed by
the enterprise CA. This is a best pracce because usually all network devices already trust the
Enterprise CA (it is usually already installed in the devices’ CA Trust storage), so you don’t need
to deploy the cerficate on the endpoints, so the rollout process is smoother.
• Self-signed Cerficates—The firewall can act as a CA and generate self-signed cerficates
that the firewall can use to sign the cerficates for sites which require SSL decrypon. The
firewall can sign a copy of the server cerficate to present to the client and establish the SSL
session. This method requires that you need to install the self-signed cerficates on all of your
network devices so that those devices recognize the firewall’s self-signed cerficates. Because
the cerficates must be deployed to all devices, this method is beer for small deployments
and proof-of-concept (POC) trials than for large deployments.
Addionally, set up a Forward Untrust cerficate for the firewall to present to clients when the
server cerficate is signed by a CA that the firewall does not trust. This ensures that clients are
prompted with a cerficate warning when aempng to access sites with untrusted cerficates.
Regardless of whether you generate Forward Trust cerficates from your Enterprise
Root CA or use a self-signed cerficate generated on the firewall, generate a separate
subordinate Forward Trust CA cerficate for each firewall. The flexibility of using separate
subordinate CAs enables you to revoke one cerficate when you decommission a device
(or device pair) without affecng the rest of the deployment and reduces the impact in any
situaon in which you need to revoke a cerficate. Separate Forward Trust CAs on each
firewall also helps troubleshoot issues because the CA error message the user sees includes
informaon about the firewall the traffic is traversing. If you use the same Forward Trust
CA on every firewall, you lose the granularity of that informaon.
Aer seng up the Forward Trust and Forward Untrust cerficates required for SSL Forward
Proxy decrypon, create a Decrypon policy rule to define the traffic you want the firewall to
decrypt and create a Decrypon profile to apply SSL controls and checks to the traffic. The
Decrypon policy decrypts SSL tunneled traffic that matches the rule into clear text traffic. The
firewall blocks and restricts traffic based on the Decrypon profile aached to the Decrypon
policy and on the firewall Security policy. The firewall re-encrypts traffic as it exits the firewall.
When you configure SSL Forward Proxy, the proxied traffic does not support DSCP code
points or QoS.
Decrypon
STEP 1 | Ensure that the appropriate interfaces are configured as either virtual wire, Layer 2, or Layer
3 interfaces.
View configured interfaces on the Network > Interfaces > Ethernet tab. The Interface
Type column displays if an interface is configured to be a Virtual Wire or Layer 2, or Layer
3 interface. You can select an interface to modify its configuraon, including what type of
interface it is.
Decrypon
STEP 2 | Configure the Forward Trust cerficate for the firewall to present to clients when a trusted
CA has signed the server cerficate. You can use an enterprise CA-signed cerficate or a self-
signed cerficate as the forward trust cerficate.
(Recommended Best Pracce) Use an enterprise CA-signed cerficate as the Forward Trust
cerficate. Create a uniquely named Forward Trust cerficate on each firewall:
1. Generate a Cerficate Signing Request (CSR) for the enterprise CA to sign and validate:
1. Select Device > Cerficate Management > Cerficates and click Generate.
2. Enter a Cerficate Name. Use a unique name for each firewall.
3. In the Signed By drop-down, select External Authority (CSR).
4. (Oponal) If your enterprise CA requires it, add Cerficate Aributes to further idenfy
the firewall details, such as Country or Department.
5. Click Generate to save the CSR. The pending cerficate is now displayed on the Device
Cerficates tab.
2. Export the CSR:
1. Select the pending cerficate displayed on the Device Cerficates tab.
2. Click Export to download and save the cerficate file.
Leave Export private key unselected in order to ensure that the private key
remains securely on the firewall.
3. Click OK.
3. Provide the cerficate file to your enterprise CA. When you receive the enterprise CA-
signed cerficate from your enterprise CA, save the enterprise CA-signed cerficate to
import onto the firewall.
4. Import the enterprise CA-signed cerficate onto the firewall:
1. Select Device > Cerficate Management > Cerficates and click Import.
2. Enter the pending Cerficate Name exactly. The Cerficate Name that you enter must
exactly match the pending cerficate name in order for the pending cerficate to be
validated.
3. Select the signed Cerficate File that you received from your enterprise CA.
4. Click OK. The cerficate is displayed as valid with the Key and CA check boxes selected.
5. Select the validated cerficate to enable it as a Forward Trust Cerficate to be used for SSL
Forward Proxy decrypon.
6. Click OK to save the enterprise CA-signed forward trust cerficate.
Use a self-signed cerficate as the Forward Trust cerficate:
1. Create a self-signed Root CA cerficate.
2. Click the self-signed root CA cerficate (Device > Cerficate Management > Cerficates
> Device Cerficates) to open Cerficate informaon and then click the Trusted Root CA
checkbox.
3. Click OK.
4. Generate new subordinate CA cerficates for each firewall:
Decrypon
2. Click Generate at the boom of the window.

3. Enter a Cerficate Name.
4. Enter a Common Name, such as 192.168.2.1. This should be the IP or FQDN that will
appear in the cerficate. In this case, we are using the IP of the trust interface. Avoid
using spaces in this field.
5. In the Signed By field, select the self-signed Root CA cerficate that you created.
6. Click the Cerficate Authority check box to enable the firewall to issue the cerficate.
Selecng this check box creates a cerficate authority (CA) on the firewall that is
imported to the client browsers, so clients trust the firewall as a CA.
7. Generate the cerficate.
5. Click the new cerficate to modify it and click the Forward Trust Cerficate checkbox to
configure the cerficate as the Forward Trust Cerficate.
6. Click OK to save the self-signed forward trust cerficate.
7. Repeat this procedure to generate a unique subordinate CA cerficate on each firewall.
STEP 3 | Distribute the forward trust cerficate to client system cerficate stores.
If you are using an enterprise-CA signed cerficate as the forward trust cerficate for SSL
Forward Proxy decrypon, and the client systems already have the enterprise CA installed in
the local trusted root CA list, you can skip this step. (The client systems trust the subordinate
CA cerficates you generate on the firewall because the Enterprise Trusted Root CA has signed
them.)
If you do not install the forward trust cerficate on client systems, users see cerficate
warnings for each SSL site they visit.
On a firewall configured as a GlobalProtect portal:
This opon is supported with Windows and Mac client OS versions, and requires
GlobalProtect agent 3.0.0 or later to be installed on the client systems.
1. Select Network > GlobalProtect > Portals and then select an exisng portal
configuraon or Add a new one.
2. Select Agent and then select an exisng agent configuraon or Add a new one.
3. Add the self-signed firewall Trusted Root CA cerficate to the Trusted Root CA secon.
Aer GlobalProtect distributes the firewall’s Trusted Root CA cerficate to client
Decrypon
systems, the client systems trust the firewall’s subordinate CA cerficates because the
clients trust the firewall’s Root CA cerficate.
4. Install in Local Root Cerficate Store so that the GlobalProtect portal automacally
distributes the cerficate and installs it in the cerficate store on GlobalProtect client
systems.
5. Click OK twice.
Without GlobalProtect:
Export the firewall Trusted Root CA cerficate so that you can import it into client systems.
Highlight the cerficate and click Export at the boom of the window. Choose PEM format.
Do not select the Export private key checkbox! The private key should remain on the
firewall and should not be exported to client systems.
Import the firewall’s Trusted Root CA cerficate into the browser Trusted Root CA list on
the client systems in order for the clients to trust it. When imporng into the client browser,
ensure that you add the cerficate to the Trusted Root Cerficaon Authories cerficate
store. On Windows systems, the default import locaon is the Personal cerficate store. You
can also simplify this process by using a centralized deployment opon, such as an Acve
Directory Group Policy Object (GPO).
STEP 4 | Configure the Forward Untrust cerficate (use the same Forward Untrust cerficate for all
firewalls).
1. Click Generate at the boom of the cerficates page.
2. Enter a Cerficate Name, such as my-ssl-fwd-untrust.
3. Set the Common Name, for example 192.168.2.1. Leave Signed By blank.
4. Click the Cerficate Authority check box to enable the firewall to issue the cerficate.
5. Click Generate to generate the cerficate.
7. Click the new my-ssl-fwd-untrust cerficate to modify it and enable the Forward Untrust
Cerficate opon.
Do not export the Forward Untrust cerficate to the Cerficate Trust Lists of
your network devices! Do not install the Forward Untrust cerficate on client
systems. This is crical because installing the Untrust cerficate in the Trust List
results in devices trusng websites that the firewall does not trust. In addion,
users won’t see cerficate warnings for untrusted sites, so they won’t know the
sites are untrusted and may access those sites, which could expose your network
to threats.
STEP 5 | (Oponal) Configure the Key Size for SSL Forward Proxy Server Cerficates that the firewall
presents to clients. By default, the firewall determines the key size to use based on the key
size of the desnaon server cerficate.
Decrypon
STEP 6 | Create a Decrypon Policy Rule to define traffic for the firewall to decrypt and Create a
Decrypon Profile to apply SSL controls to the traffic.
Although Decrypon profiles are oponal, it is a best pracce to include a Decrypon

profile with each Decrypon policy rule to prevent weak, vulnerable protocols and
algorithms from allowing quesonable traffic on your network.
1. Select Policies > Decrypon, Add or modify an exisng rule, and define traffic to be
decrypted.
2. Select Opons and:
• Set the rule Acon to Decrypt matching traffic.
• Set the rule Type to SSL Forward Proxy.
• (Oponal but a best pracce) Configure or select an exisng Decrypon Profile
to block and control various aspects of the decrypted traffic (for example, create a
decrypon profile to perform cerficate checks and enforce strong cipher suites and
protocol versions).
This opon requires an acve WildFire license and is a WildFire best pracce.
STEP 9 | Choose your next step:

• Enable Users to Opt Out of SSL Decrypon.
• Configure Decrypon Exclusions to disable decrypon for certain types of traffic.
Decrypon
Configure SSL Inbound Inspecon

Use SSL Inbound Inspecon to decrypt and inspect inbound SSL traffic desned for a network
server (you can perform SSL Inbound Inspecon for any server if you load the server cerficate
onto the firewall). With an SSL Inbound Inspecon Decrypon policy enabled, the firewall
decrypts all SSL traffic idenfied by the policy to clear text traffic and inspects it. The firewall
blocks, restricts, or allows the traffic based on the Decrypon profile aached to the policy and
the Security policy that applies to the traffic, including and any configured Anvirus, Vulnerability
Protecon, An-Spyware, URL Filtering, and File Blocking profiles. As a best pracce, enable the
firewall to forward decrypted SSL traffic for WildFire analysis and signature generaon.
Configuring SSL Inbound Inspecon includes installing the targeted server cerficate on the
firewall, creang an SSL Inbound Inspecon Decrypon policy, and applying a Decrypon profile
to the policy.
When you configure SSL Inbound Inspecon, the proxied traffic does not support DSCP
code points or QoS.
SSL Inbound Inspecon does not support Authencaon Portal redirect. To use
Authencaon Portal redirect and decrypon, you must use SSL Forward Proxy.
STEP 1 | Ensure that the appropriate interfaces are configured as either Tap, Virtual Wire, Layer 2, or
Layer 3 interfaces.
You cannot use a Tap mode interface for SSL Inbound Inspecon if the negoated
ciphers include PFS key exchange algorithms (DHE and ECDHE).
View configured interfaces on the Network > Interfaces > Ethernet tab. The Interface Type
column displays if an interface is configured to be a Virtual Wire or Layer 2, or Layer 3
interface. You can select an interface to modify its configuraon, including the interface type.
Decrypon
STEP 2 | Ensure that the targeted server cerficate is installed on the firewall.
If you have enabled SSL Inbound Inspecon using PFS key exchange algorithms, you
must upload a cerficate bundle (a single file) to the firewall with your cerficates
arranged as follows:
1. End-enty (leaf) cerficate
2. Intermediate cerficates (in issuing order)
3. (Oponal) Root cerficate
Uploading the file ensures that clients receive the complete cerficate chain during SSL
handshakes, avoiding client-side server cerficate authencaon issues.
On the web interface, select Device > Cerficate Management > Cerficates > Device
Cerficates to view cerficates installed on the firewall.
To import the targeted server cerficate onto the firewall:
1. On the Device Cerficates tab, select Import.
2. Enter a descripve Cerficate Name.
3. Browse for and select the targeted server Cerficate File.
4. Click OK.
Decrypon Profile to apply SSL controls to the traffic.

decrypted.
• Set the rule Type to SSL Inbound Inspecon.
• Select the Cerficate for the internal server that is the desnaon of the inbound SSL
traffic.
to block and control various aspects of the decrypted traffic (for example, create
Decrypon
a Decrypon profile to terminate sessions with unsupported algorithms and

unsupported cipher suites).
When you configure the SSL Protocol Sengs Decrypon Profile for SSL
Inbound Inspecon traffic, create separate profiles for servers with different
security capabilies. For example, if one set of servers supports only RSA, the
SSL Protocol Sengs only need to support RSA. However, the SSL Protocol
Sengs for servers that support PFS should support PFS. Configure SSL
Protocol Sengs for the highest level of security that the server supports, but
check performance to ensure that the firewall resources can handle the higher
processing load that higher security protocols and algorithms require.
This opon requires an acve WildFire license and is a WildFire best pracce.
STEP 6 | Choose your next step...

Decrypon
Configure SSH Proxy

Configuring SSH Proxy does not require cerficates and the key used to decrypt SSH sessions is
generated automacally on the firewall during boot up. With SSH decrypon enabled, the firewall
decrypts SSH traffic and blocks and or restricts the SSH traffic based on your decrypon policy
and decrypon profile sengs. Traffic is re-encrypted as it exits the firewall.
When you configure SSH Proxy, the proxied traffic does not support DSCP code points or
QoS.
STEP 1 | Ensure that the appropriate interfaces are configured as either virtual wire, Layer 2, or Layer
3 interfaces. Decrypon can only be performed on virtual wire, Layer 2, or Layer 3 interfaces.
View configured interfaces on the Network > Interfaces > Ethernet tab. The Interface
Type column displays if an interface is configured to be a Virtual Wire or Layer 2, or Layer
3 interface. You can select an interface to modify its configuraon, including what type of
interface it is.
Decrypon Profile to apply checks to the SSH traffic.

decrypted.
• Set the rule Type to SSH Proxy.
to block and control various aspects of the decrypted traffic (for example, create a
Decrypon profile to terminate sessions with unsupported versions and unsupported
algorithms).
STEP 4 | (Oponal) Connue to Decrypon Exclusions to disable decrypon for certain types of
traffic.
Decrypon
Configure Server Cerficate Verificaon for

Undecrypted Traffic
You create no-decrypon policies for traffic that you choose not to decrypt because the traffic is
personal, sensive, or subject to local laws and regulaons. For example, you may choose not to
decrypt the traffic of certain execuves or traffic between finance users and finance servers that
contain personal informaon. (Don’t exclude traffic that you can’t decrypt because a site breaks
decrypon for technical reasons such as a pinned cerficate or mutual authencaon by policy.
Instead, add the hostname to the Decrypon Exclusion List.)
However, just because you don’t decrypt the traffic doesn’t mean you should let any and all
undecrypted traffic on your network. It is a best pracce to apply a No Decrypon profile to
undecrypted traffic to block sessions with expired cerficates and untrusted issuers.
STEP 1 | Create a Decrypon Policy Rule to idenfy the undecrypted traffic and Create a Decrypon
Profile to block bad sessions.
1. Select Policies > Decrypon and Add or modify an exisng rule to idenfy the
undecrypted traffic.
• Set the rule Acon to No Decrypt so that the firewall doesn’t decrypt traffic that
matches the rule.
• Ignore the rule Type because the traffic is not decrypted.
• (Oponal but a best pracce) Configure or select an exisng Decrypon profile
for undecrypted traffic to block sessions with expired cerficates and untrusted
cerficate issuers.
Do not aach a No Decrypon profile to Decrypon policies for TLSv1.3

traffic that you don’t decrypt because the firewall can’t read the encrypted
cerficate informaon so it can’t perform cerficate checks. However, you
should sll create a Decrypon policy for TLSv1.3 traffic that you don’t
decrypt because undecrypted traffic isn’t logged unless a Decrypon policy
STEP 3 | Choose your next step:

Decrypon
Decrypon Exclusions
You can exclude two types of traffic from decrypon:
• Traffic that breaks decrypon for technical reasons, such as using a pinned cerficate, an
incomplete cerficate chain, unsupported ciphers, or mutual authencaon (aempng to
decrypt the traffic results in blocking the traffic). Palo Alto Networks provides a predefined
SSL Decrypon Exclusion list (Device > Cerficate Management > SSL Decrypon Exclusion)
that excludes hosts with applicaons and services that are known to break decrypon
technically from SSL Decrypon by default. If you encounter sites that break decrypon
technically and are not on the SSL Decrypon Exclusion list, you can add them to list manually
by server hostname. The firewall blocks sites whose applicaons and services break decrypon
technically unless you add them to the SSL Decrypon Exclusion list.
If the Decrypon profile allows Unsupported Modes (sessions with client authencaon,
unsupported versions, or unsupported cipher suites), the firewall automacally adds servers
and applicaons that use the allowed unsupported modes to the its Local SSL Decrypon
Exclusion Cache (Device > Cerficate Management > SSL Decrypon Exclusion > Show Local
Exclusion Cache). When you block unsupported modes, you increase security but you also
block communicaon with applicaons that use those modes.
• Traffic that you choose not to decrypt because of business, regulatory, personal, or other
reasons, such as financial-services, health-and-medicine, or government traffic. You can choose
to exclude traffic based on source, desnaon, URL category, and service.
You can use asterisks (*) as wildcards to create decrypon exclusions for mulple hostnames
associated with a domain. Asterisks behave the same way that carets (^) behave for URL category
excepons—each asterisk controls one variable subdomain (label) in the hostname. This enables
you to create both very specific and very general exclusions. For example:
• mail.*.com matches mail.company.com but does not match mail.company.sso.com.
• *.company.com matches tools.company.com but does not match eng.tools.company.com.
• *.*.company.com matches eng.tools.company.com but does not match eng.company.com.
• *.*.*.company.com matches corp.exec.mail.company.com, but does not match
corp.mail.company.com.
• mail.google.* matches mail.google.com, but does not match mail.google.uk.com.
• mail.google.*.* matches mail.google.co.uk, but does not match mail.google.com.
For example, to use wildcards to exclude video-stats.video.google.com from decrypon but not to
exclude video.google.com from decrypon, exclude *.*.google.com.
Regardless of the number of asterisk wildcards that precede a hostname (without a non-
wildcard label preceding the hostname), the hostname matches the entry. For example,
*.google.com, *.*.google.com, and *.*.*.google.com all match google.com. However,
*.dev.*.google.com does not match google.com because one label (dev) is not a wildcard.
To increase visibility into traffic and reduce the aack surface as much as possible, don’t make
decrypon excepons unless you must.
• Palo Alto Networks Predefined Decrypon Exclusions
Decrypon
• Exclude a Server from Decrypon for Technical Reasons

• Local Decrypon Exclusion Cache
• Create a Policy-Based Decrypon Exclusion
Palo Alto Networks Predefined Decrypon Exclusions

The firewall provides a predefined SSL Decrypon Exclusion list to exclude from decrypon
commonly used sites that break decrypon because of technical reasons such as pinned
cerficates and mutual authencaon. The predefined decrypon exclusions are enabled by
default and Palo Alto Networks delivers new and updated predefined decrypon exclusions to
the firewall as part of the Applicaons and Threats content update (or the Applicaons content
update, if you do not have a Threat Prevenon license). The firewall does not decrypt traffic that
matches predefined exclusions and allows the encrypted traffic based on the Security policy that
governs that traffic. However, the firewall can’t inspect the encrypted traffic or enforce Security
policy on it.
The SSL Decrypon Exclusion list is not for sites that you choose not to decrypt for legal,
regulatory, business, privacy, or other volional reasons, it is only for sites that break
decrypon technically (decrypng these sites blocks their traffic). For traffic such as IP
addresses, users, URL categories, services, and even enre zones that you choose not to
decrypt, Create a Policy-Based Decrypon Exclusion.
Because the traffic of sites on the SSL Decrypon Exclusion list remains encrypted, the firewall
does not inspect or provide further security enforcement the traffic. You can disable a predefined
exclusion. For example, you may choose to disable predefined exclusions to enforce a strict
security policy that allows only applicaons and services that the firewall can inspect and
on which the firewall can enforce Security policy. However, the firewall blocks sites whose
applicaons and services break decrypon technically if they are not enabled on the SSL
Decrypon Exclusion list.
You can view and manage all Palo Alto Networks predefined SSL decrypon exclusions directly on
the firewall (Device > Cerficate Management > SSL Decrypon Exclusions).
Decrypon
The Hostname displays the name of the host that houses the applicaon or service that breaks
decrypon technically. You can also Add hosts to Exclude a Server from Decrypon for Technical
Reasons if it is not on the predfined list.
The Descripon displays the reason the firewall can’t decrypt the site’s traffic, for example,
pinned-cert (a pinned cerficate) or client-cert-auth (client authencaon).
The firewall automacally removes enabled predefined SSL decrypon exclusions from the list
when they become obsolete (the firewall removes an applicaon that decrypon previously
caused to break when the applicaon becomes supported with decrypon). Show Obsoletes
checks if any disabled predefined exclusions remain on the list and are no longer needed. The
firewall does not remove disabled predefined decrypon exclusions from the list automacally, but
you can select and Delete obsolete entries.
You can select a hostname’s checkbox and then click Disable to remove predefined sites from
the list. Use the SSL Decrypon Exclusion list only for sites that break decrypon for technical
reasons, don’t use it for sites that you choose not to decrypt.
Exclude a Server from Decrypon for Technical Reasons

If decrypon breaks an important applicaon or service technically (decrypng the traffic blocks
it), you can add the hostname of the site that hosts to the applicaon or service to the Palo Alto
Networks predefined SSL Decrypon Exclusion list to create a custom decrypon excepon. The
firewall doesn’t decrypt, inspect, and enforce Security policy on traffic that the SSL Decrypon
Exclusion list allows because the traffic remains encrypted, so be sure that the sites you add to
the list really are sites with applicaons or services you need for business. For example, some
business-crical internal custom applicaons may break decrypon and you can add them to the
list so that the firewall allows the encrypted custom applicaon traffic.
Decrypon
The SSL Decrypon Exclusion list is not for sites that you choose not to decrypt for legal,
regulatory, business, privacy, or other volional reasons, it is only for sites that break
decrypon technically. For traffic (IP addresses, users, URL categories, services, and
even enre zones) that you choose not to decrypt, Create a Policy-Based Decrypon
Exclusion.
Reasons that sites break decrypon technically include pinned cerficates, client authencaon,
incomplete cerficate chains, and unsupported ciphers. For HTTP public key pinning (HPKP), most
browsers that use HPKP permit Forward Proxy decrypon as long as you install the enterprise CA
cerficate (or the cerficate chain) on the client.
If the technical reason for excluding a site from decrypon is an incomplete cerficate
chain, the next-generaon firewall doesn’t automacally fix the chain as a browser would.
If you need to add a site to the SSL Decrypon Exclusion list, manually review the site to
ensure it’s a legimate business site, then download the missing sub-CA cerficates and
load and deploy them onto the firewall.
Aer you add a server to the SSL Decrypon Exclusion list, the firewall compares the server
hostname that you use to define the decrypon exclusion against both the Server Name
Indicaon (SNI) in the client hello message and the Common Name (CN) in the server cerficate. If
either the SNI or CN match the entry in the SSL Decrypon Exclusion list, the firewall excludes the
traffic from decrypon.
STEP 1 | Select Device > Cerficate Management > SSL Decrypon Exclusions.
STEP 2 | Add a new decrypon exclusion, or select an exisng custom entry to modify it.
STEP 3 | Enter the hostname of the website or applicaon you want to exclude from decrypon.
The hostname is case-sensive.
You can use wildcards to exclude mulple hostnames associated with a domain. The
firewall excludes all sessions where the server presents a CN that matches the domain from
decrypon.
Make sure that the hostname field is unique for each custom entry. If a predefined exclusion
matches a custom entry, the custom entry takes precedence.
STEP 4 | (Oponal) Select Shared to share the exclusion across all virtual systems in a mulple virtual
system firewall.
STEP 5 | Exclude the applicaon from decrypon. Alternavely, if you are modifying an exisng
decrypon exclusion, you can clear this checkbox to start decrypng an entry that was
previously excluded from decrypon.
STEP 6 | Click OK to save the new exclusion entry.
Local Decrypon Exclusion Cache

The firewall can add servers to the Local Decrypon Exclusion cache (Device > Cerficate
Management > SSL Decrypon Exclusion > Show Local Exclusion Cache) and exclude their traffic
Decrypon
from decrypon automacally for 12 hours if that traffic breaks decrypon for technical reasons
such as a pinned cerficate or an unsupported cerficate. When the Decrypon profile allows
unsupported modes—sessions with client authencaon, unsupported versions, or unsupported
cipher suites—and the allowed traffic uses an unsupported mode, then the device automacally
adds the server to the local exclusion cache and bypasses decrypon. The firewall doesn’t decrypt,
inspect, and enforce Security policy on traffic that the Local Decrypon Exclusion cache allows
because the traffic remains encrypted. Ensure that the sites you exclude from decrypon (by
applying a Decrypon profile that allows unsupported modes) are sites with applicaons or
services you need for business.
Blocking unsupported modes blocks communicaon with applicaons that use those modes
to increase security. Client authencaon is a common reason for excluding applicaons from
decrypon, which is why the best pracce is to block unsupported versions and unsupported
ciphers and to allow client authencaon in the Decrypon profile. If the Decrypon profile
allows client authencaon, then when a client starts a session with a server that requires the
client to authencate, instead of blocking the traffic because the firewall can’t decrypt it, the
firewall adds the applicaon and server to the local exclusion cache and allows the traffic.
If you allow traffic from sites that use client authencaon and are not in the predefined
sites on the SSL Decrypon Exclusion list, create a Decrypon profile that allows
sessions with client authencaon. Add the profile to a Decrypon policy rule that applies
only to the server(s) that host the applicaon. To increase security even more, you can
require Mul-Factor Authencaon to complete the user login process. Alternavely, you
can add the site to the SSL Decrypon Exclusion list to skip decrypon without using an
explicit Decrypon policy.
The firewall adds Local SSL Decrypon Exclusion cache entries based on the Decrypon policy
and profile that controls the applicaon traffic. If you don’t block Unsupported Mode Checks
in the Decrypon profile, the firewall adds entries to the Local SSL Decrypon Exclusion cache
when:
• The client supports only TLSv1.2 and the server supports only TLSv1.3. In the local cache, the
Reason shown for this exclusion is SSL_UNSUPPORTED.
• The client supports TLSv1.3 and TLSv1.2, and the server supports only TLSv1.2. In this case,
the Reason column shows TLS13_UNSUPPORTED.
When the Reason for adding a server to the Local SSL Decrypon Exclusion cache
is TLS13_UNSUPPORTED, the firewall downgrades the protocol to TLSv1.2 and the
firewall decrypts and inspects the traffic.
• The client adverses a specific cipher that the server doesn’t support.
• The client adverses a specific curve that the server doesn’t support.
The local cache contains a maximum of 1,024 entries. You can’t add local exclusions to the Local
SSL Decrypon Exclusion cache manually (but you can add decrypon exclusions to the SSL
Decrypon Exclusion list manually).
You must have superuser or Cerficate Management administrave access to view the Local
SSL Decrypon Exclusion cache. To view it, navigate to Device > Cerficate Management > SSL
Decrypon Exclusion and then click Show Local Exclusion Cache near the boom of the screen.
The local exclusion cache displays the applicaon, the server, the reason for inclusion in the cache,
Decrypon
the Decrypon profile that controls the traffic, and more for each entry. You can select and delete
entries from the local cache manually.
You can also delete cached entries using the CLI:
clear ssl-decrypt exclude-cache [server <value>] [application

<value>]
If anyone aempts to access the same server before the local cache entry ages out (12 hours), the
firewall matches the session to the cache entry, bypasses decrypon, and allows the traffic. The
firewall flushes the local exclusion cache if you change the Decrypon policy or profile because
those changes may affect the classificaon of the session. If the cache becomes full, the firewall
purges the oldest entries as new entries arrive.
Create a Policy-Based Decrypon Exclusion

Policy-based decrypon exclusions are for excluding traffic that you choose not to decrypt. You
can create a policy-based decrypon exclusion based on any combinaon of the traffic’s source,
desnaon, service, or URL Category. Examples of traffic you may choose not to decrypt include:
• Traffic that you should never decrypt because it contains personally idenfiable informaon
(PII) or other sensive informaon, such as the URL Filtering categories financial-services,
health-and-medicine, and government.
Decrypon
• Traffic that originates or is desned for execuves or other users whose traffic shouldn’t be
decrypted.
• Some devices such as finance servers may need to be excepted from decrypon.
• Depending on the business, some companies may value privacy and the user experience more
than security for some applicaons.
• Laws or local regulaons that prohibit decrypon of some traffic.
An example of not decrypng traffic for regulatory and legal compliance is the European
Union (EU) General Data Protecon Regulaon (GDPR). The EU GDPR will require strong
protecon of all personal data for all individuals. The GDPR affects all companies, including
foreign companies, that collect or process the personal data of EU residents.
Different regulaons and compliance rules may mean that you treat the same data differently
in different countries or regions. Businesses usually can decrypt personal informaon in their
corporate data centers because the business owns the informaon. The best pracce is to
decrypt as much traffic as possible so that you can see it and apply security protecon to it.
You can use predefined URL Categories to except enre categories of websites from decrypon,
you can create custom URL Categories to define a customized list of URLs that you don’t want to
decrypt, or you can create an External Dynamic List (EDL) to define a customized list of URLs that
you don’t want to decrypt.
In environments such as Office 365 that have dynamically changing IP addresses or in
environments where you make frequent changes to the list of URLs that you want to exclude from
decrypon, it’s oen preferable to use an EDL instead of a URL Category to specify the excluded
URLs. Using an EDL is less disrupve in dynamic environments because eding an EDL changes
the URL categories dynamically, without a Commit, while eding a custom URL Category requires
a Commit to take effect.
Create an EDL or a custom URL Category that contains all the categories you choose not
to decrypt so that one Decrypon policy rule governs the encrypted traffic you choose to
allow. Apply a No Decrypon profile to the rule. The ability to add categories to an EDL or
a custom URL Category makes it easy to exclude traffic from decrypon and helps keep
the rulebase clean.
Similar to Security policy rules, the firewall compares incoming traffic to Decrypon policy
rules in the policy rulebase’s sequence. Place Decrypon exclusion rules at the top of
the rulebase to prevent inadvertently decrypng sensive traffic or traffic that laws and
regulaons prevent you from decrypng.
If you create policy-based decrypon exclusions, the best pracce is to place the following
exclusion rules at the top of the decrypon rulebase, in the following order:
1. IP-address based excepons for sensive desnaon servers.
2. Source-user based excepons for execuves and other users or groups.
3. Custom URL or EDL based excepons for desnaon URLs.
4. Sensive predefined URL Category based excepons for desnaon URLs of enre categories
such as financial-services, health-and-medicine, and government.
Place rules that decrypt traffic aer these rules in the decrypon rulebase.
Decrypon
STEP 1 | Exclude traffic from decrypon based on match criteria.

This example shows how to exclude traffic categorized as financial or health-related from SSL
Forward Proxy decrypon.
1. Select Policies > Decrypon and Add or modify a decrypon policy rule.
2. Define the traffic that you want to exclude from decrypon.
In this example:
1. Give the rule a descripve Name, such as No-Decrypt-Finance-Health.
2. Set the Source and Desnaon to Any to apply the No-Decrypt-Finance-Health rule
to all SSL traffic desned for an external server.
3. Select URL Category and Add the URL categories financial-services and health-and-
medicine.
3. Select Opons and set the rule to No Decrypt.

4. (Oponal but a best pracce) Create and aach a No Decrypon profile to the rule to
validate cerficates for sessions the firewall does not decrypt. Configure the profile to
Block sessions with expired cerficates and Block sessions with untrusted issuers.
Excepon: Do not aach a No Decrypon profile to Decrypon policies for

TLSv1.3 traffic that you don’t decrypt because the firewall can’t read the
encrypted cerficate informaon so it can’t perform cerficate checks. However,
you should sll create a Decrypon policy for TLSv1.3 traffic that you don’t
decrypt because undecrypted traffic isn’t logged unless a Decrypon policy
5. Click OK to save the No-Decrypt-Finance-Health decrypon rule.
Decrypon
STEP 2 | Place the decrypon exclusion rule at the top of your decrypon policy rulebase.
The firewall enforces decrypon rules against incoming traffic in the rulebase sequence and
enforces the first rule that match the traffic.
Select the No-Decrypt-Finance-Health policy (Decrypon > Policies), and click Move Up unl
it appears at the top of the list, or drag and drop the rule.

Click Commit.
Decrypon
Block Private Key Export

You can permanently block the export of private keys for cerficates when you generate them in
or import them into PAN-OS or Panorama. Blocking the export of private keys from your PAN-
OS devices hardens your security posture because it prevents rogue administrators or other bad
actors from misusing keys. Administrators with roles that include cerficate management can
block the export of private keys. You can’t block keys that already exist on a device; you can only
block keys at the me that you generate them in or import them into PAN-OS.
When an administrator blocks the export of a private key, no administrator can export that key,
not even Superuser administrators. If you need to export a private key from a PAN-OS appliance,
regenerate the cerficate and the key without selecng the opon to block private key export.
To downgrade to an earlier version of PAN-OS, you must first delete the cerficates whose
private keys are blocked. If you don’t delete the cerficates whose private keys are blocked before
you aempt to downgrade, an error message asks you to delete those cerficates. You can’t
downgrade unl you delete them. Aer you downgrade, reimport or regenerate the deleted
cerficates if you need them.
If you use an enterprise Public Key Infrastructure (PKI) to generate cerficates and private
keys, block the export of private keys because you can install them on new firewalls and
Panoramas from your enterprise cerficate authority (CA), so there is no reason to export
them from PAN-OS.
If you generate self-signed cerficates on the firewall or Panorama and apply the block
private key export opon, you can’t export the cerficate and key to other PAN-OS
appliances.
You can export and import the device state (Device > Setup > Operaons) even if you block
the export of private keys. We include the private keys in device state imports and exports, but
administrators can’t read or decode them.
You can import or load the configuraon of one firewall on another firewall if the master
key is the same on both firewalls. If the master key is different on the firewalls, then
imporng or loading the configuraon doesn’t work and the commit fails while reading the
cerficates.
• Generate a Private Key and Block It

• Import a Private Key and Block It
• Import a Private Key for IKE Gateway and Block It
• Verify Private Key Blocking
Generate a Private Key and Block It

Block the export of a private key to prevent its misuse aer generang a cerficate.
If there is more than one virtual system, select a Locaon or Shared for the cerficate.
Decrypon
STEP 2 | Generate the cerficate.
STEP 3 | Select Block Private Key Export to prevent anyone from exporng the cerficate.
See Generate a Cerficate for informaon about the other cerficate fields.
STEP 4 | Click Generate to generate the new cerficate.
You can also generate a cerficate and block its private key from export using the
operaonal CLI command:
admin@pa-220> request certificate generate block-private-

keys yes
The preceding CLI command can also include the cerficate and other parameters that
are not shown.
Import a Private Key and Block It

Block the export of a private key to prevent its misuse aer imporng a cerficate.
If there is more than one virtual system, select a Locaon or Shared for the cerficate.
STEP 2 | Import the cerficate.
Decrypon
STEP 3 | Select Import Private Key to acvate the opon to block private key export.
STEP 4 | Select Block Private Key Export to prevent anyone from exporng the cerficate.
See Import a Cerficate and Private Key for informaon about the other cerficate import
fields.
STEP 5 | Click OK to import the cerficate.
If you use the SCP operaonal CLI command to import a cerficate or to import a
private key for a cerficate, you can sll block export of the private key:
• admin@pa-220> scp import private-key block-private-
key ...
Each of the preceding CLI commands can also include keywords to specify the source,
the cerficate name, and other parameters that are not shown.
If you use the SCP operaonal CLI command to export a cerficate and include its
private key (scp export certificate passphrase <phrase> remote-
port <1-65536> to <destination> certificate-name <name>
include-key <yes | no> format <der | pem | pkcs10 | pkcs12>),
and if the cerficate’s private key is blocked, the command fails and returns an error
message because you cannot export a blocked private key.
Import a Private Key for IKE Gateway and Block It

Block the export of a private key to prevent its misuse aer generang a cerficate for IKE
Gateway authencaon.
STEP 1 | Select Network > Network Profiles > IKE Gateways.
STEP 2 | Add a new IKE Gateway.
STEP 3 | On the General tab, for Authencaon, select Cerficate.
Decrypon
STEP 4 | For Local Cerficate select Import or Generate depending on whether you want to import an
exisng cerficate or create a cerficate.
STEP 5 | Enter the cerficate informaon. If you are imporng the cerficate, select Import Private
Key to acvate the Block Private Key Export checkbox.
Decrypon
STEP 6 | Select Block Private Key Export to prevent anyone from exporng the key.
For imporng a cerficate, enter and confirm the Passphrase and then click OK
For generang a cerficate, click Generate.
Decrypon
STEP 7 | Enter the Passphrase, confirm it, and then click OK.
Verify Private Key Blocking

You can verify whether a private key is blocked from export in several ways.
Check the Key column in Device > Cerficate Management > Cerficates > Device
Cerficates.
In this example, the forward-trust-cerficate is blocked:
When you aempt to export a cerficate whose private key is blocked from export, the Export
Private Key checkbox is not available and you can’t export the key, you can only export the
cerficate.
Decrypon
Use the following operaonal CLI command to list all cerficates on the device or in a
parcular Vsys that have private keys blocked from export:
admin@pa-220> request certificate show-blocked <shared | vsys>
Use the following operaonal CLI command to check whether a parcular cerficate’s private
key is blocked from export:
admin@pa-220> request certificate is-blocked certificate-name

<name>
If the cerficate is blocked from export, the command returns yes and if the cerficate is not
blocked the command returns no.
Decrypon
Enable Users to Opt Out of SSL Decrypon

In privacy-sensive situaons, you may want to alert your users that the firewall is decrypng
certain web traffic and allow them either to connue to the site with the understanding that their
traffic is decrypted or to terminate the session and be block from going to the site. (There is no
opon to go to the site and also avoid decrypon.)
The first me a user aempts to browse to an HTTPS site or applicaon that matches the
decrypon policy, the firewall displays a response page nofying users that it will decrypt the
session. Users can either click Yes to allow decrypon and connue to the site or click No to opt
out of decrypon and terminate the session. The choice to allow decrypon applies to all HTTPS
sites that users try to access for the next 24 hours, aer which the firewall redisplays the response
page. Users who opt out of SSL decrypon cannot access the requested web page, or any other
HTTPS site, for the next minute. Aer the minute elapses, the firewall redisplays the response
page the next me the users aempt to access an HTTPS site.
The firewall includes a predefined SSL Decrypon Opt-out Page that you can enable. You can
oponally customize the page with your own text and/or images. However, the best pracce is to
not allow users to opt out of decrypon.
Custom response pages larger than the maximum supported size are not decrypted or
displayed to users. In PAN-OS 8.1.2 and earlier PAN-OS 8.1 releases, custom response
pages on a decrypted site cannot exceed 8,191 bytes; the maximum size is increased to
17,999 bytes in PAN-OS 8.1.3 and later releases.
Decrypon
STEP 1 | (Oponal) Customize the SSL Decrypon Opt-out Page.

1. Select Device > Response Pages.
2. Select the SSL Decrypon Opt-out Page link.
3. Select the Predefined page and click Export.
4. Using the HTML text editor of your choice, edit the page.
5. If you want to add an image, host the image on a web server that is accessible from your
end user systems.
6. Add a line to the HTML to point to the image. For example:
<img src="http://cdn.slidesharecdn.com/ Acme-logo-96x96.jpg?

1382722588"/>
7. Save the edited page with a new filename. Make sure that the page retains its UTF-8
encoding.
8. Back on the firewall, select Device > Response Pages.
9. Select the SSL Decrypon Opt-out Page link.
10. Click Import and then enter the path and filename in the Import File field or Browse to
locate the file.
11. (Oponal) Select the virtual system on which this login page will be used from the
Desnaon drop-down or select shared to make it available to all virtual systems.
12. Click OK to import the file.
13. Select the response page you just imported and click Close.
STEP 2 | Enable SSL Decrypon Opt Out.

1. On the Device > Response Pages page, click the Disabled link.
2. Select the Enable SSL Opt-out Page and click OK.
STEP 3 | Verify that the Opt Out page displays when you aempt to browse to a site.
From a browser, go to an encrypted site that matches your decrypon policy.
Verify that the SSL Decrypon Opt-out response page displays.
Decrypon
Temporarily Disable SSL Decrypon

In some cases you may want to temporarily disable SSL decrypon. For example, if you deployed
SSL decrypon too hasly and something doesn’t work correctly but you’re not sure what it is,
and you have a lot of rules to examine, you can use the CLI to temporarily turn off decrypon and
give yourself me to analyze and solve the issue. Aer solving the issue, you can use the CLI to
turn SSL decrypon back on again. Because temporarily disabling and then re-enabling decrypon
using the CLI doesn’t require a Commit operaon, you can do it without disrupng network traffic.
The following CLI commands temporarily disable SSL decrypon without a Commit and re-enable
decrypon without a Commit.
The command to disable SSL decrypon doesn’t persist in the configuraon aer a reboot.
If you turn off decrypon temporarily and then reboot the firewall, regardless of whether
the issue has been fixed, decrypon is turned on again.
Disable SSL Decrypon
set system setting

ssl-decrypt skip-ssl-decrypt yes
Re-enable SSL Decrypon
set system setting

ssl-decrypt skip-ssl-decrypt no
Decrypon
Configure Decrypon Port Mirroring

Before you can enable Decrypon Mirroring, you must obtain and install a Decrypon Port Mirror
license. The license is free of charge and can be acvated through the support portal as described
in the following procedure. Aer you install the Decrypon Port Mirror license and reboot the
firewall, you can enable decrypon port mirroring.
Keep in mind that the decrypon, storage, inspecon, and/or use of SSL traffic is regulated in
certain countries and user consent may be required in order to use the decrypon mirror feature.
Addionally, use of this feature could enable malicious users with administrave access to the
firewall to harvest usernames, passwords, social security numbers, credit card numbers, or other
sensive informaon submied using an encrypted channel. Palo Alto Networks recommends that
you consult with your corporate counsel before acvang and using this feature in a producon
environment.
STEP 1 | Request a license for each firewall on which you want to enable decrypon port mirroring.
1. Log in to the Palo Alto Networks Customer Support website and navigate to the Assets
tab.
2. Select the entry for the firewall you want to license and select Acons.
3. Select Decrypon Port Mirror. A legal noce displays.
4. If you are clear about the potenal legal implicaons and requirements and sll want to
set up decrypon port mirroring, click I understand and wish to proceed.
5. Click Acvate.
Decrypon
STEP 2 | Install the Decrypon Port Mirror license on the firewall.

1. From the firewall web interface, select Device > Licenses.
2. Click Retrieve license keys from license server.
3. Verify that the license has been acvated on the firewall.
4. Reboot the firewall (Device > Setup > Operaons). This feature is not available for
configuraon unl PAN-OS reloads.
STEP 3 | Enable the firewall to forward decrypted traffic. Superuser permission is required to perform
this step.
On a firewall with a single virtual system:
1. Select Device > Setup > Content - ID.
2. Select the Allow forwarding of decrypted content check box.
On a firewall with mulple virtual systems:
1. Select Device > Virtual System.
2. Select a Virtual System to edit or create a new Virtual System by selecng Add.
3. Select the Allow forwarding of decrypted content check box.
STEP 4 | Enable an Ethernet interface to be used for decrypon mirroring.

1. Select Network > Interfaces > Ethernet.
2. Select the Ethernet interface that you want to configure for decrypon port mirroring.
3. Select Decrypt Mirror as the Interface Type.
This interface type will appear only if the Decrypon Port Mirror license is installed.
STEP 5 | Enable mirroring of decrypted traffic.

1. Select Objects > Decrypon Profile.
2. Select an Interface to be used for Decrypon Mirroring.
The Interface drop-down contains all Ethernet interfaces that have been defined as the
type: Decrypt Mirror.
3. Specify whether to mirror decrypted traffic before or aer policy enforcement.
By default, the firewall will mirror all decrypted traffic to the interface before security
policies lookup, which allows you to replay events and analyze traffic that generates
a threat or triggers a drop acon. If you want to only mirror decrypted traffic aer
security policy enforcement, select the Forwarded Only check box. With this opon, only
traffic that is forwarded through the firewall is mirrored. This opon is useful if you are
Decrypon
forwarding the decrypted traffic to other threat detecon devices, such as a DLP device
or another intrusion prevenon system (IPS).
4. Click OK to save the decrypon profile.
STEP 6 | Aach the decrypon profile rule (with decrypon port mirroring enabled) to a decrypon
policy rule. All traffic decrypted based on the policy rule is mirrored.
1. Select Policies > Decrypon.
2. Click Add to configure a decrypon policy or select an exisng decrypon policy to edit.
3. In the Opons tab, select Decrypt and the Decrypon Profile created in step 4.
4. Click OK to save the policy.

Click Commit.
Decrypon
Verify Decrypon
Aer you configure a best pracce decrypon profile and apply it to traffic, you can check both
the Decrypon logs (introduced in PAN-OS 10.0) and the Traffic logs to verify that the firewall is
decrypng the traffic that you intend to decrypt and that the firewall is not decrypng the traffic
that you don’t want to decrypt. This topic shows you how to check decrypon using Traffic logs. In
addion, follow post-deployment decrypon best pracces to maintain the deployment.
View Decrypted Traffic Sessions—Filter the Traffic Logs (Monitor > Logs > Traffic) using the
filter ( flags has proxy ).
This filter displays only logs in which the SSL proxy flag is on, meaning only decrypted traffic—
every log entry has the value yes in the Decrypted column.
You can filter the traffic in a more granular fashion by adding more terms to the filter.
For example, you can filter for decrypted traffic going only to the desnaon IP address
99.84.224.105 by adding the filter ( addr.dst in 99.84.224.105 ):
Decrypon
View SSL Traffic Sessions That Are Not Decrypted—Filter the Traffic Logs (Monitor > Logs >
Traffic) using the filter ( not flags has proxy ) and ( app eq ssl ).
This filter displays only logs in which the SSL proxy flag is off (meaning only encrypted traffic)
and the traffic is SSL traffic; every log entry has the value no in the Decrypted column and the
value ssl in the Applicaon column.
Similar to the example for viewing decrypted traffic logs, you can add terms to filter the traffic
that you don’t decrypt in a more granular fashion.
View The Log for a Parcular Session—To view the Traffic log for a parcular session, filter on
the Session ID.
For example, to see the log for a session with the ID 137020, filter using the term
( sessionid eq 137020). You can find the ID number in the Session ID column in the
log output, as shown in the previous screens. If the Session ID column isn’t displayed, add the
column to the output.
Decrypon
View All TLS and SSH Traffic—Filter the Traffic Logs (Monitor > Logs > Traffic) to view both
decrypted and undecrypted TLS and SSH traffic, use the filter ( s_encrypted neq 0 ):
Decrypon
Drill Down Into the Details—To view more informaon about a parcular log entry, click the
magnifying glass to see a detailed log view. For example, for Session ID 137020 (shown in the
previous bullet), the detailed log looks like this:
The box for the Decrypted flag provides a second way to verify if traffic was decrypted.
You can also take upstream and downstream packet captures of decrypted traffic to view
how the firewall processes SSL traffic and takes acons on packets, or perform deep packet
inspecon.
Decrypon
Troubleshoot and Monitor Decrypon

Troubleshoong tools provide enhanced visibility into TLS traffic so you can monitor your
decrypon deployment. The tools enable you to diagnose and resolve decrypon issues quickly
and easily, ghten weaknesses in your decrypon deployment, and fix decrypon issues to
improve your security posture. For example, you can:
• Idenfy traffic that causes decrypon failures by Service Name Idenficaon (SNI) and
applicaon.
• Idenfy traffic that uses weak protocols and algorithms.
• Examine successful and unsuccessful decrypon acvity in the network.
• View detailed informaon about individual sessions.
• Profile decrypon usage and paerns.
• Monitor detailed decrypon stascs and informaon about adopon, failures, versions,
algorithms, etc.
The following tools provide full visibility into the TLS handshake and help you troubleshoot and
monitor your decrypon deployment:
• ACC > SSL Acvity—The five ACC widgets on this tab (introduced in PAN-OS 10.0) provide
details about successful and unsuccessful decrypon acvity in your network, including
decrypon failures, TLS versions, key exchanges, and the amount and type of decrypted and
undecrypted traffic.
• Monitor > Logs > Decrypon—The Decrypon Log (introduced in PAN-OS 10.0) provides
comprehensive informaon about individual sessions that match a Decrypon policy (use a No
Decrypon policy for traffic you don’t decrypt) and about GlobalProtect sessions when you
enable Decrypon logging in GlobalProtect Portal or GlobalProtect Gateways configuraon.
Select which columns to display to view informaon such as applicaon, SNI, Decrypon Policy
Name, error index, TLS version, key exchange version, encrypon algorithm, cerficate key
types, and many other characteriscs. Filter the informaon in columns to idenfy traffic that
uses parcular TLS versions and algorithms, parcular errors, or any other characteriscs you
want to invesgate. By default, Decrypon policies log only unsuccessful TLS handshakes.
Depending on the available log storage, you can configure Decrypon policies to log successful
TLS handshakes as well.
• Local Decrypon Exclusion Cache—There are two constructs for sites that break decrypon
for technical reasons such as client authencaon or pinned cerficates and therefore need
to be excluded from decrypon: the SSL Decrypon Exclusion List and the Local Decrypon
Exclusion Cache. The SSL Decrypon Exclusion List contains the sites that Palo Alto Networks
has idenfied that break decrypon technically. Content updates keep the list up-to-date and
you can add sites to the list manually. The Local Decrypon Exclusion Cache automacally adds
sites that local users encounter that break decrypon for technical reasons and excludes them
from decrypon, providing that the Decrypon profile applied to the traffic allows unsupported
modes (if unsupported modes are blocked, then the traffic is blocked instead of added to the
local cache).
• Custom Report Templates for Decrypon—You can create custom reports (Monitor >
Manage Custom Reports) using four predefined templates that summarize decrypon acvity
(introduced in PAN-OS 10.0).
Decrypon
The general troubleshoong methodology is to use the new ACC widgets to idenfy traffic that
causes decrypon issues and then use the new Decrypon Log and custom report templates to
drill down into details and gain context about that traffic, which enables you to diagnose issues
accurately and much more easily than in the past. Understanding decrypon issues and their
causes enables you to select the appropriate way to fix each issue, such as:
• Modify Decrypon policy rules (a policy rule defines traffic that the rule affects, the acon
taken on that traffic, log sengs, and the Decrypon profile applied to the traffic)
• Modify Decrypon profiles (acceptable protocols and algorithms for the traffic that a
Decrypon policy rule defines, plus failure checks, unsupported mode checks for items such as
unsupported ciphers and versions, cerficate checks, etc.)
• Add sites that break decrypon for technical reasons to the SSL Decrypon Exclusion List
• Evaluate security decisions about which sites your employees, customers, and partners really
need to access and which sites you can block when sites use weak decrypon protocols or
algorithms
The goals should be to decrypt all the traffic you can decrypt (a decrypon best pracce) so that
you can inspect it and to properly handle traffic that you don’t decrypt.
When you upgrade to PAN-OS 10.0, the device takes 1% of the log space and allocates it to
Decrypon logs. Step 3 in Configure Decrypon Logging shows you how to modify the log space
allocaon to provide more space for Decrypon logs.
If you downgrade from PAN-OS 10.1 or later to PAN-OS 9.1 or earlier, the features introduced
in PAN-OS 10.1 (Decrypon Log, SSL Acvity widgets in the ACC, custom report Decrypon
templates) are removed from the UI. References to Decrypon logs are also removed from Log
Forwarding profiles. In addion, the Local Decrypon Exclusion Cache is only viewable using the
CLI in PAN-OS 9.1 and earlier (PAN-OS 10.1 added the local cache to the UI).
If you push configuraons from Panorama on PAN-OS 10.1 or later to devices that run PAN-OS
9.1 or earlier, Panorama removes the features introduced in PAN-OS 10.0.
• Decrypon Applicaon Command Center Widgets
• Decrypon Log
• Custom Report Templates for Decrypon
• Decrypon Troubleshoong Workflow Examples
Decrypon Applicaon Command Center Widgets

The Applicaon Command Center (ACC) widgets for decrypon (ACC > SSL Acvity) introduced
in PAN-OS 10.1 work with Decrypon Log to help you diagnose and resolve decrypon issues
quickly and easily. Use the SSL Acvity widget to view and analyze network decrypon acvity
such as the number of decrypted and undecrypted sessions, how much traffic uses different TLS
protocol versions, the most common decrypon failure reasons, and which applicaons and Server
Name Idenficaons (SNIs) use weak ciphers and algorithms. Next, use the Decrypon logs to drill
down into sessions and diagnose the exact issue so you can take appropriate acon.
PAN-OS 10.1 introduced five new decrypon widgets. Use the informaon the widgets provide
to idenfy misconfigured Decrypon policies and profiles and to make informed decisions about
what traffic to allow and what traffic to block:
Decrypon
• Traffic Acvity—Shows SSL/TLS acvity compared to non-SSL/TLS acvity by total number of

sessions or by amount of traffic in bytes.
• SSL/TLS Traffic—Shows the amount of decrypted and non-decrypted traffic by number of
sessions or amount of traffic in bytes. Reasons for traffic not being decrypted include:
• No Decrypon policy is applied to the traffic.
• The Decrypon policy intenonally exempted the traffic from decrypon (for example, a No
Decrypon policy).
• The Decrypon policy was misconfigured and the traffic was intended to be decrypted but is
not.
• The site is in the SSL Decrypon Exclusion List (Device > Cerficate Management > SSL
Decrypon Exclusion), which contains sites Palo Alto Networks has idenfied that break
decrypon for technical reasons such as pinned cerficates or client authencaon. For
these sites, the firewall bypasses decrypon.
• The site is in the Local Decrypon Exclusion Cache, which contains sites that local users
encounter which prevent decrypon for technical reasons.
The ACC only populates the next three widgets with data from traffic that a Decrypon policy
controls. If you don’t apply a Decrypon policy to traffic, that traffic does not populate these
widgets.
• Decrypon Failure Reasons—Shows the reasons for decrypon failures: protocol, cerficate,
version, cipher, HSM, resource, resume, or feature issues, by SNI. Use this informaon to
detect problems caused by Decrypon policy or profile misconfiguraon or by traffic that
uses unsupported weak protocols or algorithms. Click a failure reason to drill down and isolate
the number of sessions per SNI that experienced the failure or click an SNI to see all of the
decrypon failures for that SNI.
• Successful TLS Version Acvity—Shows successful TLS connecons by TLS version for
applicaons or SNIs (SNIs are available for Forward Proxy only) so you can evaluate how
much risk you are taking on by allowing weaker TLS protocol versions. Idenfying applicaons
and SNIs that use weak protocols enables you to evaluate each one and decide whether you
need to allow access to it for business reasons. If you don’t need the applicaon for business
purposes, you may want to block the traffic instead of allowing it to reduce risk. Click a TLS
version to drill down and view the SNIs or applicaons which used that TLS version. Click an
applicaon or an SNI to drill down and see how many of those applicaon or SNI sessions used
each TLS version.
• Successful Key Exchange Acvity—Shows successful key exchange acvity per algorithm
for applicaons or SNIs (SNIs are available for Forward Proxy only). Click a key exchange
algorithm to see the acvity for just that algorithm or click an applicaon or SNI to view the
key exchange algorithm acvity for that applicaon or SNI.
The following example of drilling down into ACC data shows you how to examine successful TLS
version acvity:
Decrypon
1. The Successful TLS Version Acvity widget shows that seventeen sessions used TLSv1.3
and seven sessions used TLSv1.2. The SNI list shows the desnaon SNIs and the number of
sessions per SNI.
2. To see which SNIs used TLSv1.2, click the green bar labeled TLS1.2.
Decrypon
3. Now you can see the seven TLSv1.2 sessions were spread among four servers.
4. Clicking Home returns to the home screen. Now, clicking the www.espn.com SNI shows us
which TLS versions it used. We can see that two of the four sessions used TLSv1.3 and two
used TLSv1.2.
For any Decrypon widget, click the Jump to Logs icon to jump directly to the Decrypon logs
that correspond to the data in the ACC:
Decrypon
In the preceding example, at any point in the invesgaon you could jump to the Decrypon
logs for the data to drill down more. For example, you could examine the logs for the individual
sessions that used TLSv1.2 to find out why they didn’t use TLSv1.3.
Decrypon ACC widgets show the name of the decrypted applicaon based on the Palo Alto
Networks App-ID. For populang the ACC, the firewall can only idenfy applicaons that have
a Palo Alto Networks App-ID; the firewall cannot populate the ACC with custom applicaons
or applicaons that do not have an App-ID. Content updates update App-IDs regularly. Other
reasons that the applicaon may be shown as incomplete or unknown are:
• The firewall dropped the session before it could idenfy the applicaon.
• Decrypon logs depend on Traffic logs to populate the Decrypon log applicaon field.
However, if the Traffic log is not completed in 60 seconds or less, the Traffic log does not
populate the applicaon in the Decrypon log and the applicaon displays as incomplete or
unknown.
Decrypon Log
The Decrypon Log (Monitor > Logs > Decrypon) provides comprehensive informaon about
sessions that match a Decrypon policy to help you gain context about that traffic so you can
accurately and easily diagnose and resolve decrypon issues. The firewall does not log traffic if the
traffic does not match a Decrypon policy. If you want to log traffic that you don’t decrypt, create
a policy-based decrypon exclusion and for policies that govern TLSv1.2 and earlier traffic, apply a
No Decrypon profile to the traffic.
PAN-OS supports Decrypon logs for the following types of traffic:
• Forward Proxy—Several fields only display informaon for Forward Proxy traffic, including Root
CA (for trusted cerficates only) and Server Name Idenficaon (SNI).
• Inbound Inspecon.
• No Decrypt (traffic excluded from decrypon by Decrypon policy).
Because the session remains encrypted, the firewall displays less informaon. For
undecrypted TLSv1.3 traffic, there is no cerficate informaon because TLSv1.3
encrypts cerficate informaon.
• GlobalProtect—Covers GlobalProtect Gateway, GlobalProtect Portal, and GlobalProtect
Clientless VPN (client-to-firewall only).
GlobalProtect does not support TLSv1.3.
• Decrypon Mirror
Not all types of traffic support every parameter. Unsupported Parameters by Proxy Type
and TLS Version provides a complete list of unsupported parameters for each type of
decrypon traffic.
The data for Forward Proxy traffic is based on whether the TLS handshake is successful or
unsuccessful. For unsuccessful TLS handshakes, the firewall sends error data for the leg of the
transacon that caused the error, either client-to-firewall or firewall-to-server. For successful TLS
Decrypon
handshakes, the data is from the leg that successfully completes first, which is usually client-to-
firewall.
The firewall does not generate Decrypon log entries for web traffic blocked during SSL/
TLS handshake inspecon. These sessions do not appear in Decrypon logs because the
firewall prevents decrypon when it resets the SSL/TLS connecon, ending the handshake.
You can view details of the blocked sessions in the URL Filtering logs.
Decrypon logs are not supported for SSH Proxy traffic. In addion, cerficate informaon
is not available for session resumpon logs.
By default, the firewall logs all unsuccessful TLS handshake traffic. You can also log successful
TLS handshake traffic if you choose to do so. You can view up to 62 columns of log informaon
such as applicaon, SNI, Decrypon Policy Name, error index, TLS version, key exchange version,
encrypon algorithm, cerficate key types, and many other characteriscs:
Click the magnifying glass icon ( ) to see the Detailed Log View of a session.
Decrypon
The Decrypon log learns each session’s App-ID from the Traffic log, so Traffic logs must
be enabled to see the App-ID in the Decrypon log. If Traffic logs are disabled, the App-ID
shows as incomplete. For example, a lot of GlobalProtect traffic is intrazone traffic (Untrust
zone to Untrust zone), but the default intra-zone policy does not enable Traffic logs. To
see the App-ID for GlobalProtect intrazone traffic, you need to enable the Traffic log for
intrazone traffic.
Another reason that the App-ID may display as incomplete is that for long sessions, the
firewall may generate the Decrypon log before the Traffic log is complete (the Traffic log
is usually generated at session end). In those cases, the App-ID is not available for the
Decrypon log. In addion, when the TLS handshake fails and generates an error log, the
App-ID is not available because the failure terminates the session before the firewall can
determine the App-ID. In these cases, the applicaon may display as ssl or as incomplete.
To troubleshoot issues, use the Decrypon ACC widgets (ACC > SSL Acvity) to idenfy traffic
that causes decrypon issues and then use the Decrypon log and Custom Report Templates for
Decrypon to drill down into details.
When you forward Decrypon logs for storage, ensure that you properly secure log transport and
storage because Decrypon logs contain sensive informaon.
When the Decrypon logs are enabled, the firewall sends HTTP/2 logs as Tunnel
Inspecon logs (when Decrypon logs are disabled, HTTP/2 logs are sent as Traffic logs), so
you need to check the Tunnel Inspecon logs instead of the Traffic logs for HTTP/2 events.
In addion, you must enable Tunnel Content Inspecon to obtain the App-ID for HTTP/2
traffic.
• Configure Decrypon Logging

• Repair Incomplete Cerficate Chains
• Decrypon Log Errors, Error Indexes, and Bitmasks
Configure Decrypon Logging

The firewall generates Decrypon logs for sessions governed by a Decrypon policy, including
sessions with a No Decrypt policy. Configure Decrypon logging in the Decrypon policy that
controls the traffic that you want to log.
Decrypon
STEP 1 | Configure the Decrypon traffic you want to log in Decrypon policy (Policies > Decrypon).
By default, the firewall logs only unsuccessful TLS handshakes:
Log successful handshakes as well as unsuccessful handshakes to gain visibility into

as much decrypted traffic as your device’s available resources permit (don’t decrypt
private or sensive traffic; follow decrypon best pracces and decrypt as much
traffic as you can).
STEP 2 | Create a Log Forwarding profle to forward Decrypon logs to Log Collectors, other storage
devices, or specific administrators and then specify the profile in the Log Forwarding field of
the Decrypon policy Opons tab.
To forward Decrypon logs, you must configure a Log Forwarding profile (Objects > Log
Forwarding) to specify the Decrypon Log Type and the method of forwarding the logs.
If you forward Decrypon logs, be sure that the logs are stored securely because they contain
sensive informaon.
Decrypon
STEP 3 | If you log successful TLS handshakes in addion to unsuccessful TLS handshakes, configure
a larger log storage space quota (Device > Setup > Management > Logging and Reporng
Sengs > Log Storage) for Decrypon logs on the firewall.
The default quota (allocaon) is one percent of the device’s log storage capacity for Decrypon
logs and one percent for the general decrypon summary. There is no default allocaon for
hourly, daily, or weekly decrypon summaries.
Many factors determine the amount of storage you may need for Decrypon logs and they
depend on your deployment. For example, take these factors into account:
• The amount of TLS traffic that passes through the firewall.
• The amount of TLS traffic that you decrypt.
• Your usage of other logs (evaluate from which logs you should take capacity to allocate to
Decrypon logs).
• If you log both successful and unsuccessful TLS handshakes, you probably need significantly
more capacity than you need if you only log unsuccessful TLS handshakes. Depending on
the amount of traffic you decrypt, Decrypon logs could consume as much capacity as
Decrypon
Traffic logs or Threat logs and may require a tradeoff among them if the device’s capacity is
already fully subscribed.
The total combined allocaon of log quotas cannot exceed 100% of the available
firewall log resources.
You may need to experiment to find the right quota for each log category in your parcular
deployment. If you only log unsuccessful handshakes, you could start with the default or
increase the allocaon to two or three percent. If you log both successful and unsuccessful
handshakes, you could start by allocang about half of the space to Decrypon logs that you
allocate to Traffic logs. The logs from which you take the space to allocate to Decrypon logs
depends on your traffic, your business, and your monitoring requirements.
Decrypon Log Errors, Error Indexes, and Bitmasks

The Error Index and Error columns in the Decrypon log provide informaon about the
decrypon error category and details, respecvely. You can also see error and error index
informaon in the Handshake Details secon of the Detailed Log View (click for any log entry).
The Decrypon log Error Index indicates one of eight error categories:
Error Index Error (possible errors shown for the Error Index)
Cerficate Errors such as invalid cerficates, expired cerficates, unsupported client

cerficates, OCSP/CRL check revocaons and failures, untrusted issuer CAs
(sessions signed by an untrusted root, which includes incomplete cerficate
chains), and other cerficate errors.
When the firewall doesn’t have an intermediate cerficate because

the site did not send the full cerficate chain, you can find and install
the missing cerficate to Repair Incomplete Cerficate Chains.
Cipher Unsupported cipher errors where:

• The client tries to negoate a cipher that the firewall supports but that the
Decrypon profile applied to the traffic doesn’t support.
• The client tries to negoate a cipher that the firewall doesn’t support.
• (Rare) Inbound Inspecon is enabled and the server’s capabilies don’t
match the Decrypon profile sengs.
The error message includes the supported client cipher bitmask value and the
supported Decrypon profile cipher bitmask value. Use the bitmask values to
idenfy the cipher the client tried to use and to list the cipher values that the
Decrypon profile supports as described later in this topic.
Feature Errors such as oversized TLS handshakes or unknown handshakes, oversized

cerficate chains (more than five cerficates), and other unsupported features.
Decrypon
Error Index Error (possible errors shown for the Error Index)
HSM Hardware storage module (HSM) errors such as unknown requests, items
not found in the configuraon, request meouts, and other HSM errors and
failures.
Protocol Errors such as TLS handshake failures, private and public key mismatches,
Heartbleed errors, TLS key exchange failures, and other TLS protocol errors.
Protocol errors show when the server doesn’t support the protocols that
the client supports, the server uses cerficate types that the firewall doesn’t
support, and general TLS protocol errors.
Resource Errors such as lack of sufficient memory.
Resume Session resumpon errors concerning resume session IDs and ckets, resume
session entries in the firewall cache, and other session resumpon errors.
Version Errors regarding client and Decrypon profile version mismatches and client
and server version mismatches.
The error message includes bitmask values that idenfy the supported client
and Decrypon profile versions. Use the bitmask values to idenfy the cipher
the client tried to use and to list the cipher values that the Decrypon profile
supports as described later in this topic.
If no suitable error descripon category exists for an error, the default message is General
TLS protocol error.
Version and cipher log error informaon includes bitmask values that you convert to actual values
using operaonal CLI commands:
• Version error bitmask values idenfy mismatches between the TLS protocol versions that the
client and server use and also idenfy TLS protocol mismatches between the client and the
Decrypon profile applied to the traffic. The CLI command to convert version error bitmasks is:
admin@vm1>debug dataplane show ssl-decrypt bitmask-version

<bitmask-value>
The command returns the TLS version that matches the bitmask.
• Cipher error bitmask values idenfy encrypon and other mismatches between the client and
the Decrypon profile applied to the traffic.
admin@vm1>debug dataplane show ssl-decrypt bitmask-cipher <bitmask-

value>
The command returns the cipher that matches the bitmask.

Filter the Decrypon log to find version and cipher errors, plug the bitmask values for sessions
with errors into the appropriate CLI command, obtain the values of the protocol version or cipher
Decrypon
that caused the error, and use the informaon to update the Decrypon policy or profile if you
want to allow access to the site in queson.
• Version Errors
• Cipher Errors
• Root Status “Uninspected”
Version Errors
To idenfy and fix version mismatch errors:
1. Filter the Decrypon Log to idenfy version errors using the filter (err_index eq
Version). The highlighted values are bitmask values:
You can filter the Decrypon log in many ways. For example, to see only TLSv1.3 version
errors, use the filter (err_index eq Version) and (tls_version eq TLS1.3):
2. Log in to the CLI and look up the bitmask values. The version errors in the first screen shot (the
same errors for all three sessions) show an issue with a client and Decrypon profile mismatch
Decrypon
—the supported client version bitmask is 0x08 and the supported Decrypon profile version
bitmask is 0x70:
admin@vm1>debug dataplane show ssl-decrypt bitmask-version 0x08
TLSv1.0
This output shows that the client supports only TLSv1.0.
TLSv1.1
TSLv1.2
TLSv1.3
This output shows that the Decrypon profile supports TLSv1.1, TLSv1.2, and TLSv1.3, but not
TLSv1.0. Now you know the issue is that the client only supports a very old version of the TLS
protocol and the Decrypon profile aached to the Decrypon policy rule that controls the
traffic does not allow TLSv1.0 traffic.
The next thing to do is to decide what acon to take. You could update the client so that it
accepts a more secure TLS version. If the client requires TLSv1.0 for some reason, you can
connue let the firewall connue to block the traffic, or you can update the Decrypon profile
to allow all TLSv1.0 traffic (not recommended), or you can create a Decrypon policy and
profile that allow TLSv1.0 and apply it only to the client devices that must use TLSv1.0 and
cannot support a more secure protocol (most secure opon for allowing the traffic).
The version error in the second screen shot shows a different issue: a client and server version
mismatch. The error indicates the supported client bitmask as 0x20:
TLSv1.2
The output shows that the client supports only TLSv1.2. Since the server does not support
TLSv1.2, it may only support TLSv1.3 or it may support only TLSv1.1 or lower (less secure
protocols). You can use Wireshark or another packet analysis tool to find out which version of
TLS the server supports. Depending on what the server supports, you can:
• If the server only supports TLSv1.3, you could edit the Decrypon profile so that it supports
TLSv1.3.
• If the server only supports TLSv1.1 or lower, evaluate whether you need to access that
server for business reasons. If not, consider blocking the traffic to increase security. If you
need to access the server for business purposes, create or add the server to a Decrypon
Decrypon
policy that applies only to the servers and sites you need to access for business; don’t allow
access to all servers that use less secure TLS versions.
3. To find the Decrypon policy that controls the session traffic, check the Policy Name column in
the log (or click the magnifying glass icon next to the Decrypon log to see the informaon
in the General secon of the Detailed Log View). In the example above, the Decrypon policy
name is Big Brother. To find the Decrypon policy and profile, go to Policies > Decrypon,
select the policy named Big Brother, and then select the Opons tab. Decrypon profile
displays the name of the Decrypon profile.
Go to Objects > Decrypon > Decrypon Profile, select the appropriate Decrypon profile,
and edit it to address the version issue.
Cipher Errors
Using the Decrypon log to hunt down cipher errors is similar to hunng down version errors
—you filter the log to find errors and obtain error bitmasks. Then you go to the CLI, convert the
bitmask to the error value, and then take appropriate acon to fix the issue. For example:
1. Filter the Decrypon Log to idenfy cipher errors using the filter (err_index eq Cipher).
For example, let’s examine a cipher error with the Error message Unsupported cipher.
Supported client cipher bitmask: 0x80000000. Support decrypt profile
cipher bitmask 0x60f79980.
2. Log in to the CLI and look up the bitmask values:
admin@vm1>debug dataplane show ssl-decrypt bitmask-cipher

0x80000000
CHACHA_PLY1305_SHA256
This output shows that client tried to negoate a cipher that the firewall supports (if the
bitmask is all zeros (0x0000000, then the client tried to negoate a cipher that the firewall
doesn’t support):
admin@vm1>debug dataplane show ssl-decrypt bitmask-cipher

0x80000000
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
TLS_RSA_WITH_AES_256_CBC_SHA256
TLS_RSA_WITH_AES_128_CBC_SHA256
TLS_DHE_RSA_WITH_AES_256_CBC_SHA256
TLS_DHE_RSA_WITH_AES_128_CBC_SHA256
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
TLS_RSA_WITH_AES_256_CBC_SHA
TLS_RSA_WITH_AES_128_CBC_SHA
TLS_DHE_RSA_WITH_AES_256_CBC_SHA
TLS13_WITH_AES_256_GCM_SHA384
Decrypon
TLS13_WITH_AES_128_GCM_SHA256
This output shows that the Decrypon profile that controls the traffic supports many ciphers,
but does not support the cipher the client is trying to use.
To fix this issue so that the firewall allows and decrypts the traffic, you need to add support for
the missing cipher to the Decrypon profile.
3. Check the Decrypon log or the Detailed Log View Policy Name to get the name of the
Decrypon policy that controls the traffic. Go to Policies > Decrypon and select the policy.
On the Opons tab, look up the name of the Decrypon profile. Next, Go to Objects >
Decrypon > Decrypon Profile, select the appropriate Decrypon profile, and edit it to
address the version issue.
In this example, the Decrypon profile does not support the
TLS13_WITH_CHACHA_POLY1305_SHA256 cipher, so the client can’t connect:
To fix the issue, select the CHACHA20-POLY1305 encrypon algorithm opon (the Max
Version seng of Max means that the profile already supports TLSv1.3 and the Authencaon
Algorithm seng already includes SHA256, so only the encrypon algorithm support
was missing) and then Commit the configuraon. Aer you commit the configuraon, the
Decrypon profile supports the missing cipher and the decrypon sessions for the traffic
succeed.
If the firewall does not support a cipher suite and you need to allow the traffic for
business purposes, create a Decrypon policy and profile that applies only to that
traffic. In the Decrypon profile, disable the Block sessions with unsupported cipher
suites opon
.
Root Status “Uninspected”

In some cases, the Root Status column displays the value uninspected. There are a number of
reasons why the firewall could not inspect the root status, including:
Decrypon
• Session resumpon.
• Traffic was not decrypted because a No Decrypon policy controlled the traffic, so the firewall
did not decrypt the traffic.
• A decrypon failure occurred before the firewall could inspect the server cerficate.
Filter the Decrypon Log (root_status eq uninspected) and (tls_version eq
TLS1.3) to see Decrypon sessions for which the Root Status is uninspected:
Repair Incomplete Cerficate Chains

Not all websites send their complete cerficate chain even though the RFC 5246 TLSv1.2
standard requires authencated servers to provide a valid cerficate chain leading to an
acceptable cerficate authority. When you enable decrypon and apply a Forward Proxy
Decrypon profile that enables Block sessions with untrusted issuers in the Decrypon policy, if
an intermediate cerficate is missing from the cerficate list the website’s server presents to the
firewall, the firewall can’t construct the cerficate chain to the top (root) cerficate. In these cases,
the firewall presents its Forward Untrust Cerficate to the client because the firewall cannot
construct the chain to the root cerficate and trust cannot be established without the missing
intermediate cerficate.
The firewall only has root cerficates in its Default Trusted Cerficate Authories store.
If a website you need to communicate with for business purposes has one or more missing
intermediate cerficates and the Decrypon profile blocks sessions with untrusted issuers, then
you can find and download the missing intermediate cerficate and install it on the firewall as
a Trusted Root CA so that the firewall trusts the site’s server. (The alternave is to contact the
website owner and ask them to configure their server so that it sends the intermediate cerficate
during the handshake.)
If you allow sessions with untrusted issuers in the Decrypon profile, the firewall
establishes sessions even if the issuer is untrusted; however, it is a best pracce to block
sessions with untrusted issuers for beer security.
STEP 1 | Find websites that cause incomplete cerficate chain errors.

1. Filter the Decrypon log to idenfy Decrypon sessions that failed because of an
incomplete cerficate chain.
In the filter field, type the query (err_index eq Certificate) and (error
contains ‘http’). This query filters the logs for Cerficate errors that contain the
string “hp”, which finds all of the error entries that contain the CA Issuer URL (oen
Decrypon
called the URI). The CA Issuer URL is the Authority Informaon Access (AIA) informaon
for the CA Issuer.
2. Click an Error column entry that begins “Received fatal alert UnknownCA from client. CA
Issuer URL:” followed by the URI.
The firewall automacally adds the selected error to the query and shows the full URI
path (the full URI path may be truncated in the Error column).
STEP 2 | Copy and paste the URI into your browser and then press Enter to download the missing
intermediate cerficate.
STEP 3 | Click the cerficate to open the dialog box.
Decrypon
STEP 4 | Click Open to open the cerficate file.
STEP 5 | Select the Details tab and then click Copy to File....
Follow the export direcons. The cerficate is copied to the folder you designated as you
default download folder.
Decrypon
STEP 6 | Import the cerficate into the firewall.

1. Navigate to Device > Cerficate Management > Cerficates and then select Import.
2. Browse to the folder where you stored the missing intermediate cerficate and select it.
Leave the File Format as Base64 Encoded Cerficate (PEM).
3. Name the cerficate and specify any other opons you want to use, then click OK.
STEP 7 | When the cerficate has imported, select the cerficate from the Device Cerficates list to
open the Cerficate Informaon dialog.
STEP 8 | Select Trusted Root CA to mark the cerficate as a Trusted Root CA on the firewall and then
click OK.
In Device > Cerficate Management > Cerficates > Device Cerficates, the imported
cerficate now appears in the list of cerficates. Check the Usage column to confirm that the
status is Trusted Root CA Cerficate to verify that the firewall considers the cerficate to be a
trusted root CA.
STEP 10 | You have now repaired the broken cerficate chain.

The firewall doesn’t block the traffic because the CA issuer is not untrusted anymore. Repeat
this process for all missing intermediate cerficates to repair their cerficate chains.
Decrypon
Custom Report Templates for Decrypon

You can create Custom Reports and generate them for decrypon events based on Decrypon log
fields and custom templates. Select log fields to include in custom reports and select templates to
refine the log query:
1. Monitor > Manage Custom Reports.
2. Add a custom report.
3. To configure the Decrypon log fields to use in the custom report, select Decrypon as the
Database.
The Available Columns list changes to match the columns available in the Decrypon log.
Select and add the columns (informaon) that you want to include in the custom report. If you
don’t want to refine the custom report any further, click OK to generate the report.
Decrypon
4. If desired, refine the output of the custom Decrypon report using the Query Builder and the
four templates introduced in PAN-OS 10.0. To select a template to filter the report output, click
Load Template and select from the four Decrypon templates:
The Query column shows the filter query that each template represents. Load the desired query
and then click OK to generate the custom report.
Unsupported Parameters by Proxy Type and TLS Version

Decrypon Log fields display decrypon session parameters for each decrypon proxy type.
However, for reasons such as version support, encrypted porons of TLS handshakes, informaon
availability, etc., some parameters are not available for every proxy type or TLS version. The
following table shows unsupported Decrypon log parameters by proxy type and TLS version.
Proxy Type Unsupported Parameter TLS Version
Forward Proxy Negoated EC Curve TLSv1.3
Inbound Inspecon Server Name Idenficaon All

Root Common Name
Negoated EC Curve TLSv1.3
No Decrypt (No Decrypt acon in the Negoated EC Curve TLSv1.2

Decrypon policy rule)
Server Name Idenficaon
Negoated EC Curve TLSv1.3

Server Name Idenficaon
Decrypon
Proxy Type Unsupported Parameter TLS Version

Cerficate Informaon (all cerficate
informaon fields, for example,
Cerficate Start Date, Cerficate End
Date, Cerficate Key Type, etc.)
Network Packet Broker Negoated EC Curve TLSv1.3
GlobalProtect Portal Server Name Idenficaon All

Root Common Name
Decrypon policy name
App-ID
GlobalProtect Gateway Server Name Idenficaon All

Decrypon policy name
App-ID
Clientless SSLVPN Server Name Idenficaon All
SSH Decrypon Log Not Supported
Cleartext Decrypon Log Not Supported
Decrypon Troubleshoong Workflow Examples

The Decrypon Log and the SSL Acvity widgets in the Applicaon Command Center (ACC)
provide powerful Decrypon troubleshoong tools that work both independently and together.
When you gain an understanding of how to use these tools, you can invesgate and address a
wide range of decrypon issues.
The following examples show you how to use the troubleshoong tools to idenfy, invesgate,
and address decrypon issues. Apply these methods to troubleshoot any issues you encounter in
your decrypon deployment.
• Invesgate Decrypon Failure Reasons
• Troubleshoot Unsupported Cipher Suites
• Idenfy Weak Protocols and Cipher Suites
• Idenfy Untrusted CA Cerficates
• Troubleshoot Expired Cerficates
• Troubleshoot Revoked Cerficates
• Troubleshoot Pinned Cerficates
Decrypon
Invesgate Decrypon Failure Reasons

The most common reasons for decrypon failures are TLS protocol errors, cipher version errors
(client and server version mismatches and also client and Decrypon profile version mismatches),
and cerficate errors. To invesgate decrypon errors, start with the Applicaon Command
Center (ACC) to idenfy failures and then go to the Decrypon logs to drill down into details.
STEP 1 | Begin your invesgaon at ACC > SSL Acvity and look at the Decrypon Failure Reasons
widget.
In this example, we invesgate cerficate errors. You can use the same process to invesgate
version and protocol errors.
STEP 2 | Click the green bar next to Cerficate to see which hosts (SNIs) experienced cerficate
errors and see a list of hosts that experienced the largest number of cerficate errors.
Decrypon
STEP 3 | Go to Monitor > Logs > Decrypon to drill down into the logs.
Use the query (err_index eq Certificate) to filter the Decrypon logs to view all
Decrypon sessions that experienced cerficate errors.
The Error column shows the reason for the cerficate error. To filter for all Decrypon sessions
that had the same error, click the error message to add it to the query and then execute the
query. For example, to find all errors based on receiving a fatal alert from the client, clicking the
error produces the query (err_index eq Certificate) and (error eq ‘Received
fatal alert CertificateUnknown from client’):
To filter for the cerficate errors that a specific host received, add that SNI to the query
instead of adding error message text. For example, to find all cerficate errors for
expired.badssl.comm use the query (err_index eq Certificate) and (sni eq
‘expired.badssl.com’):
The Error column shows the specific reason for each cerficate error associated with
expired.badssl.com.
Once you know the reason for the cerficate issue that caused the decrypon failure, you can
address it. For example, if the cerficate chain is incomplete, you can repair the incomplete
Decrypon
cerficate chain. If a cerficate is expired, you can nofy the site administrator or create a
policy-based excepon if you need to access the site.
Troubleshoot Unsupported Cipher Suites

Idenfying and troubleshoong unsupported cipher suites in the Decrypon log is an aspect of
version error invesgaon that is worth examining on its own.
STEP 1 | In the Decrypon log (Monitor > Logs > Decrypon), use the query (error contains
‘Client and decrypt profile mismatch’ to idenfy all cipher suite version
mismatches.
Filtering the logs for these mismatches idenfies finds all instances where the client and the
Decrypon profile cipher suite support don’t match.
To find all Decrypon sessions that experienced the same error, click the error message to add
it to the query and remove the original query, for example:
The hexadecimal codes idenfy the exact version that the client supports and the exact version
that the Decrypon profile supports.
Decrypon
STEP 2 | Log in to the CLI and look up the bitmask values.

The errors show a client and Decrypon profile mismatch. The supported client bitmask is
0x08 and the supported Decrypon profile bitmask is 0x70:
TLSv1.0
This output shows that the client supports only TLSv1.0.
TLSv1.1
TSLv1.2
TLSv1.3
This output shows that the Decrypon profile supports TLSv1.1, TLSv1.2, and TLSv1.3, but not
TLSv1.0. Now you know that the client only supports an old version of the TLS protocol and
the Decrypon profile aached to the Decrypon policy rule that controls the traffic does not
allow that version.
STEP 3 | Decide what acon to take.

You could update the client so that it accepts a more secure TLS version. If the client requires
TLSv1.0 for some reason, you can connue let the firewall connue to block the traffic, or you
can update the Decrypon profile to allow all TLSv1.0 traffic (not recommended), or you can
create a Decrypon policy and profile that allow TLSv1.0 and apply it only to the client devices
that must use TLSv1.0 and cannot support a more secure protocol (most secure opon for
allowing the traffic).
STEP 4 | If you choose to edit the Decrypon profile, to find the Decrypon policy that controls the
session traffic, check the Policy Name column in the log (or click the magnifying glass icon
Decrypon
next to the Decrypon log to see the informaon in the General secon of the Detailed Log
View).
1. In this example, the Decrypon policy name is Big Brother; to find the Decrypon profile,
go to Policies > Decrypon and check the Decrypon Profile column.
The name of the Decrypon profile is bp tls1.1-tls1.3-1. You can also select the Big
Brother policy and then select the Opons tab to see the name of the Decrypon profile.
Go to Objects > Decrypon > Decrypon Profile, select the appropriate Decrypon
profile, and edit it to address the version issue.
2. Go to Objects > Decrypon > Decrypon Profile.
Select the bp tls1.1-tls1.3-1 Decrypon profile and click the SSL Protocol Sengs tab.
The minimum TLS protocol version (Min Version) that the profile supports is TLSv1.1.
To allow the traffic that the version mismatch blocks, you could change the Min Version
to TLSv1.0. However, a more secure opon is to update the client to use a recent TLS
Decrypon
protocol version. If you can’t update the client, you can create a Decrypon policy and
profile that apply only to that user, device, or source address (and to any similar users,
devices, or source addresses so that one policy and profile control all of this traffic)
instead of applying a general Decrypon policy that allows TLSv1.0 traffic.
Idenfy Weak Protocols and Cipher Suites

Weak TLS protocols and weak cipher suites (encrypon algorithms, authencaon algorithms, key
exchange algorithms, and negoated EC curves) weaken your security posture and are easier for
bad actors to exploit than strong TLS protocols and strong cipher suites.
Five fields in the Decrypon log entries show the protocol and cipher suites for a decrypon
session:
Track down old, vulnerable TLS versions and cipher suites so that you can make informed
decisions about whether to allow connecons with servers and applicaons that may compromise
your security posture.
The examples in this topic show how to:
• Idenfy traffic that uses less secure TLS protocol versions.
• Idenfy traffic that uses a parcular key exchange algorithm.
• Idenfy traffic that uses a parcular authencaon algorithm.
• Idenfy traffic that uses a parcular encrypon algorithm.
These examples show you how to use the decrypon troubleshoong tools in various ways so
that you can learn to use them to troubleshoot any decrypon issues you may encounter.
You can use Wireshark or other packet analyzers to double-check whether the client or the
server caused an issue, TLS client and server versions, and other cipher suite informaon.
This can help analyze version mismatches and other issues.
Decrypon
TLS Protocols—Idenfy traffic that uses older, less secure versions of the TLS protocol so that
you can evaluate whether to allow access to servers and applicaons that use weak protocols.
1. Start by checking the Applicaon Command Center (ACC) to see if the firewall allows
weak protocols (ACC > SSL Acvity > Successful TLS Version Acvity) and to get an
overall view of acvity.
The majority of successful TLS acvity in this example is TLSv1.2 and TLSv1.3 acvity.
However, there are a few instances of allowed TLSv1.0 traffic. Let’s click the number 49
Decrypon
to drill down into the TLSv1.0 acvity and see which applicaons are making successful
TLSv1.0 connecons:
We see that the firewall is allowing traffic idenfied as web-browsing traffic. To gain
insight into what that TLSv1.0 web-browsing traffic is and why it’s allowed, we go next to
the Decrypon logs.
2. Filter the Decrypon log to check TLSv1.0 acvity details.
Use the query (tls_version eq TLS1.0) and (err_index eq ‘None’) to
show successful TLSv1.0 Decrypon sessions.
Decrypon logs show successful TLS acvity only if you enable logging
successful TLS handshakes in Decrypon policy when you Configure
Decrypon Logging. If logging successful TLS handshakes is disabled, you can’t
check this informaon.
The Decrypon log shows us that the name of the Decrypon policy that controls the
traffic is Inner Eye and that the name of the host is hq-screening.mt.com. Now we
know the site that uses TLSv1.0 and we can check the Decrypon policy (Policies >
Decrypon
Decrypon) to find the Decrypon profile that controls the traffic and learn why the
traffic is allowed:
We see that the Decrypon profile associated with the policy is old TLS versions
support. We check the profile (Objects > Decrypon > Decrypon Profile) and look at
the SSL Protocol Sengs to find out exactly what traffic the profile allows:
The profile allows TLSv1.0 traffic. The next thing to do is to decide if you want to allow
access to the site (do you need access for business purposes?) or if you want to block it.
Another common scenario that results in the firewall allowing traffic that uses less secure
protocols is when that traffic is not decrypted. When you filter the Decrypon log for
TLSv1.0 traffic, if the Proxy Type column contains the value No Decrypt, then a No
Decrypon
Decrypon policy controls the traffic, so the firewall does not decrypt or inspect it. If you
don’t want to allow the weak protocol, modify the Decrypon profile so that it blocks
TLSv1.0 traffic.
There are many ways you can filter the Decrypon log to find applicaons and sites that
use weak protocols, for example:
• Instead of filtering only for successful TLSv1.0 handshakes, filter for both successful
and unsuccessful TLSv1.0 handshakes using the query (tls_version eq
TLS1.0).
• Filter only for unsuccessful TLSv1.0 handshakes using the query (tls_version eq
TLS1.0) and (err_index neq ‘None’).
• Filter for all less secure protocols (TLSv1.1 and earlier) using the query
(tls_version leq tls1.1).
If you want to filter the logs for other TLS versions, simply replace TLS1.0 or TLS1.1
with another TLS version.
3. Decide what acon to take for sites that use weak TLS protocols.
• If you don’t need to access the site for business purposes, the safest acon is to block
access to the site by eding the Decrypon policy and Decrypon profile that control
the traffic. The Decrypon log Policy Name column provides the policy name and the
Decrypon policy shows the aached Decrypon profile (Opons tab).
• If you need to access the site for business purposes, consider creang a Decrypon
policy and Decrypon profile that apply only to that site (or to that site and other
similar sites) and block all other traffic that uses less secure protocols.
Decrypon
Key Exchange—Idenfy traffic that uses less secure key exchange algorithms.
1. Start by checking the Applicaon Command Center (ACC) to see which key exchange
algorithms the firewall allows (ACC > SSL Acvity > Successful Key Exchange Acvity)
and to get an overall view of acvity.
The majority of the key exchanges use the secure ECDHE key exchange algorithm.
However, some key exchange sessions use the less secure RSA algorithm and a few use
Decrypon
another key algorithm. To begin invesgang traffic that uses RSA key exchanges, for
example, click the number 325 to drill down into the data.
The drill-down shows the applicaons that use RSA key exchanges. We can also click the
SNI radio buon to view the RSA key exchanges by SNI:
Decrypon
Armed with this informaon, we can go to the logs to gain more context about RSA key
exchange usage.
2. Go to the Decrypon log (Monitor > Logs > Decrypon)) and filter them for decrypon
sessions that use the RSA key exchange using the query (tls_keyxchg eq RSA):
From the Policy Name column in the log, we see that the No Decrypt Decrypon policy
controls most of the traffic that uses RSA key exchanges and can infer that the firewall
does not decrypt the traffic and allows it without inspecon. Because the traffic isn’t
Decrypon
decrypted, the firewall can’t idenfy the applicaon and lists it as ssl. If you don’t want to
allow traffic that uses RSA key exchanges, modify the Decrypon profile aached to the
Decrypon policy that controls the traffic.
You can add to the query to further filter the results for a parcular SNI or applicaon
that you saw in the ACC or in the first Decrypon log query.
3. Decide what acon to take for traffic that uses less secure key exchange algorithms.
Block access to sites that use less secure key exchange protocols unless you need to
access them for business purposes. For those sites, consider creang a Decrypon policy
and Decrypon profile that apply only to that site (or to that site and other similar sites)
and block all other traffic that uses less secure key exchange algorithms.
Use the Decrypon logs to idenfy sessions that uses older, less secure authencaon
algorithms.
Filter the Decrypon log to idenfy older, less secure authencaon algorithms.
For example, to idenfy all sessions that use the SHA1 algorithm, use the query (tls_auth
eq SHA):
You can add to the query to further drill down into the results. For example, you can add a
parcular SNI, a key exchange version (such as filtering for SHA1 sessions that also use RSA
key exchanges), a TLS version, or any other metric found in a Decrypon log column.
Decrypon
Use the Decrypon logs to idenfy sessions that use a parcular encrypon algorithm.
For example, to idenfy all sessions that use the AES-128-CBC encrypon algorithm, use the
query (tls_enc eq AES_128_CBC):
You can add to the query to further drill down into the results.
Examples of queries to find other older encrypon algorithms include: (tls_enc eq
DES_CBC), (tls_enc eq 3DES_EDE_CBC), and (tls_enc eq DES40_CBC).
Use this methodology and the log filter builder to create queries to invesgate negoated ECC
curves and any other informaon you find in the Decrypon log.
Idenfy Untrusted CA Cerficates

Blocking access to sites with untrusted CA cerficates and cerficates self-signed by an untrusted
root CA is a best pracce because sites with untrusted CAs may indicate a man-in-the-middle
aack, a replay aack, or other malicious acvity.
Decrypon
STEP 1 | Ensure that you Block sessions with untrusted issuers in the Forward Proxy Decrypon
profile (Objects > Decrypon > Decrypon Profiles) to block sites with untrusted CAs.
When you block sessions with untrusted issuers in the Decrypon profile, the Decrypon log
(Monitor > Logs > Decrypon) logs the error.
STEP 2 | Filter the log to idenfy sessions that failed due to revoked cerficates using the query
(error eq ‘Untrusted issuer CA’).
STEP 3 | (Oponal) Double-check the cerficate expiraon date at the Qualys SSL Labs site.
Enter the hostname of the server (Server Name Idenficaon column of the Decrypon log) in
the Hostname field and Submit it to view cerficate informaon for the host.
Troubleshoot Expired Cerficates

If you follow Decrypon best pracces and Block sessions with expired cerficates in the
Forward Proxy Decrypon profile or in the No Decrypon profile, then if a server presents an
expired cerficate, the firewall blocks the session. However, if site that you need to access for
Decrypon
business reasons allows its cerficate to expire, connecons to that site may be blocked and you
may not know why.
You can use the Decrypon log to check for expired cerficates and to check for cerficates that
will expire soon so you can be aware of the situaon and take appropriate acon.
STEP 1 | Filter the Decrypon log for expired cerficates using the query (error eq ‘Expired
server certificate’).
This query idenfies servers that generate Expired server certificate errors. The
firewall blocks access to these servers because of the expired cerficate.
STEP 3 | Filter the Decrypon log (Monitor > Logs > Decrypon) for cerficates that will expire soon
using a query that idenfies upcoming cerficate end dates.
For example, if today’s date is February 1, 2020 and you want to give yourself two months to
evaluate and prepare in case sites don’t update their cerficates, query the Decrypon log for
cerficates that expire April 1 2020 or earlier (notafter leq ‘2020/4/01’)):
The Cerficate End Date column shows the eact date on which the cerficate expires.
Decrypon
STEP 4 | Determine the acon to take for sites with expired cerficates.
• If you don’t need to access the site for business purposes, the safest acon is to connue to
block access to the site.
• If you need to access the site for business purposes, take one of the following acons:
• Contact the administrator of the site with the expired cerficate and nofy them that
they need to update or renew their cerficate.
• Create a Decrypon policy that applies only to the sites with expired cerficates that
you need for business purposes and a Decrypon profile that allows sites with expired
cerficates. Do not apply the policy to any sites that you don’t need for business
purposes. When a site updates its cerficate, remove it from the policy.
Troubleshoot Revoked Cerficates

A revoked cerficate is no longer valid. It may indicate that there are security issues with a site
and that the cerficate is not trustworthy, although there are also benign reasons why a cerficate
may be revoked.
Don’t trust revoked cerficates; enable cerficate revocaon checking to deny access to
sites with revoked cerficates.
In order to drop sessions with revoked cerficates and troubleshoot revoked cerficates, you
need to enable cerficate revocaon checking. If you don’t enable cerficate revocaon checking,
the firewall doesn’t check for revoked cerficates and you won’t know if a site has a revoked
cerficate.
Decrypon
STEP 1 | Enable cerficate revocaon checking if you haven’t already enabled it.
1. Go to Device > Setup > Session > Decrypon Sengs.
2. Enable both OCSP and CRL cerficate checking.
If you Block sessions on cerficate status check meout in the Forward Proxy
Decrypon profile and are concerned that 5 seconds is not enough me and may result
in too many sessions blocked by meouts, set the Receive Timeout (sec) to a longer
amount of me.
STEP 2 | Filter the Decrypon log (Monitor > Logs > Decrypon) to find cerficate revocaon errors
using the query (error eq ‘OCSP/CRL check: certificate revoked’).
Troubleshoot Pinned Cerficates

Cerficate pinning forces the client applicaon to validate the server’s cerficate against a known
copy to ensure that cerficate really comes from the server. The intent of pinned cerficates is
Decrypon
to protect against man-in-the-middle (MITM) aacks where a device between the client and the
server replaces the server cerficate with another cerficate.
Although this prevents malicious actors from intercepng and manipulang connecons, it also
prevents forward proxy decrypon because the firewall creates an impersonaon cerficate
instead of the server cerficate to present to the client. Instead of one session that connects the
client and server directly, forward proxy creates two sessions, one between the client and the
firewall and another between the firewall and the server. This establishes trust with the client so
that the firewall can decrypt and inspect the traffic.
However, when a cerficate is pinned, the firewall cannot decrypt the traffic because the client
does not accept the firewall’s impersonaon cerficate—the client only accepts the cerficate that
is pinned to the applicaon.
STEP 1 | Filter the Decrypon log (Monitor > Logs > Decrypon) to find pinned cerficates using the
query (error contains ‘UnknownCA’).
The applicaon generates a TLS error code (Alert) when it fails to verify the server’s cerficate.
Different applicaons may use different error codes to indicate a pinned cerficate. The most
common error indicators for pinned cerficates are UnknownCA and BadCerficate. Aer
running the (error contains ‘UnknownCA’) query, run the query (error contains
‘BadCertificate’) to catch more pinned cerficate errors.
You can use Wireshark or other packet analyzers to double-check the error. Look for
the client breaking the connecon immediately aer the TLS handshake to confirm
that it is a pinned cerficate issue.
STEP 2 | Decide what to do about pinned cerficates.

If you don’t need access for business purposes, you can let the firewall connue to block
access. If you need access, then you can Exclude a Server from Decrypon for Technical
Reasons by adding it to the SSL Decrypon Exclusion List (Device > Cerficate Management >
SSL Decrypon Exclusion.
The firewall bypasses decrypon for sites on the SSL Decrypon Exclusion List. The firewall
cannot inspect the traffic, but the traffic is allowed.
Decrypon
Acvate Free Licenses for Decrypon Features

Decrypng SSH traffic and SSL traffic (SSL internet traffic or SSL traffic to an internal server) does
not require a license. However, you must acvate a free license in order to enable Decrypon
Mirroring. The free license requirement ensures that this feature can only be used aer the
approved personnel purposefully acvates the associated license.
In PAN-OS 10.1, the Decrypon Broker feature and free license were replaced with
Network Packet Broker (see the Networking Administrator’s Guide), which expands
the broker’s capabilies to non-decrypted TLS traffic and non-TLS traffic in addion to
decrypted TLS traffic. Network Packet Broker licenses are also free to download and
install from the Customer Support Portal.
Follow these steps on the Palo Alto Networks Customer Support Portal to acvate a decrypon
mirroring feature license.
STEP 1 | Log in to the Customer Support Portal.
STEP 2 | Select Assets > Devices on the le-hand navigaon pane.
STEP 3 | Find the device on which you want to enable decrypon port mirroring and select Acons
(the pencil icon).
STEP 4 | Under Acvate Licenses, select Acvate Feature License.
STEP 5 | Select the feature for which you want to acvate a free license: Decrypon Port Mirror.
STEP 6 | Agree and Submit.
STEP 7 | Install the decrypon mirroring license on the firewall.

1. Select Device > Licenses.
2. Click Retrieve license keys from the license server.
3. Verify that the Decrypon Port Mirror license is now acve on the firewall.
4. Restart the firewall (Device > Setup > Operaons). Decrypon port mirroring is not
available for configuraon unl the firewall reloads.
Decrypon
URL Filtering
Palo Alto Networks URL filtering soluon allows you to monitor and control the sites
users can access, to prevent phishing aacks by controlling the sites to which users
can submit valid corporate credenals, and to enforce safe search for search engines
like Google and Bing.
> About Palo Alto Networks URL > Create a Custom URL Category
Filtering Soluon > URL Category Excepons
> How Advanced URL Filtering Works > Use an External Dynamic List in a
> URL Filtering Inline ML URL Filtering Profile
> URL Filtering Use Cases > Allow Password Access to Certain
> URL Categories Sites
> Plan Your URL Filtering Deployment > Prevent Credenal Phishing
> URL Filtering Best Pracces > Safe Search Enforcement
> Acvate The Advanced URL Filtering > URL Filtering Response Pages
Subscripon > Customize the URL Filtering
> Test URL Filtering Configuraon Response Pages
> Configure URL Filtering > HTTP Header Logging
> Configure URL Filtering Inline ML > Request to Change the Category for
a URL
> Monitor Web Acvity
> Troubleshoot URL Filtering
> Log Only the Page a User Visits
> PAN-DB Private Cloud
> Enable SSL/TLS Handshake
Inspecon
1089
URL Filtering
About Palo Alto Networks URL Filtering Soluon

Palo Alto Networks URL filtering soluon, Advanced URL Filtering, is a subscripon-based feature
that protects against web-based threats by giving you a way to safely enable web access while
controlling how your users interact with online content. The Advanced URL Filtering subscripon
provides all of the funconality offered by the legacy URL Filtering subscripon, while also
providing the added benefit of real-me URL analysis.
Legacy URL Filtering subscripon holders are able to connue using their URL filtering
deployment unl the end of the license term.
You can create policy rules to limit access to sites based on URL categories, users, and groups.
(See URL Filtering Use Cases for different ways you can leverage your Advanced URL Filtering
subscripon to meet your organizaon’s web security needs.)
With Advanced URL Filtering enabled, URL requests are:
• Compared against the PAN-DB URL database, which contains millions of websites that have
been categorized. You can use these URL categories in URL Filtering profiles or as match
criteria to enforce Security policy. You can also use URL filtering to enforce safe search sengs
for your users and to prevent credenal the based on URL category.
• Analyzed in real-me using the cloud-based Advanced URL Filtering detecon modules to
provide protecon against new and unknown threats that do not currently exist in the URL
filtering database.
• Inspected for phishing and malicious JavaScript using inline machine learning (ML), a firewall-
based analysis soluon, which can block unknown malicious web pages in real-me.
If the network security requirements in your enterprise prohibit the firewalls from directly
accessing the Internet, Palo Alto Networks provides an offline URL filtering soluon with the
PAN-DB Private Cloud. This allows you to deploy a PAN-DB private cloud on one or more M-600
appliances that funcon as PAN-DB servers within your network.
URL Filtering
How Advanced URL Filtering Works

Advanced URL Filtering classifies websites based on site content, features, and safety. A URL can
have up to four URL categories, including risk categories (high, medium, and low) that indicate
the likelihood that the site will expose you to threats. As PAN-DB, the Advanced URL Filtering
URL database, categorizes sites, firewalls with Advanced URL Filtering enabled can leverage that
knowledge to enforce your organizaon’s security policies. In addion to the protecon offered by
the PAN-DB database, Advanced URL Filtering provides real-me analysis using machine language
to defend against new and unknown threats. This provides protecon against malicious URLs
that are updated or introduced before URL filtering databases have an opportunity to analyze
and add the content, giving aackers an open period from which they can launch precision aack
campaigns. Advanced URL Filtering compensates for the coverage gaps inherent in database
soluons by providing real me URL analysis on a per request basis. The ML-based models used
by advanced URL filtering have been trained, and are connuously updated, to detect various
malicious URLs, phishing web pages, and C2.
When a user requests a web page, the firewall queries user-added excepons and PAN-DB for
the site’s risk category. PAN-DB uses URL informaon from Unit 42, WildFire, passive DNS,
Palo Alto Networks telemetry data, data from the Cyber Threat Alliance, and applies various
analyzers to determine the category. If the URL displays risky or malicious characteriscs, it is also
submied to Advanced URL Filtering in the cloud for real-me analysis and generates addional
analysis data. The resulng risk category is then retrieved by the firewall and is used to enforce
the web-access rules based on your policy configuraon. Addionally, the firewall caches site
categorizaon informaon for new entries to enable fast retrieval for subsequent requests, while
it removes URLs that users have not accessed recently so that it accurately reflects the traffic
in your network. Addionally, checks built into PAN-DB cloud queries ensure that the firewall
receives the latest URL categorizaon informaon. If you do not have Internet connecvity or an
acve URL filtering license, no queries are made to PAN-DB.
URL Filtering
The firewall determines a website’s URL category by comparing it to entries in 1) custom URL
categories, 2) external dynamic lists (EDLs), and 3) predefined URL categories, in order of
precedence.
Firewalls configured to analyze URLs in real-me using machine learning on the dataplane
provides an addional layer of security against phishing websites and JavaScript exploits. The
inline ML models used to idenfy these URL-based threats extend to currently unknown as well
as future variants of threats that match characteriscs that Palo Alto Networks has idenfied as
malicious. To keep up with the latest changes in the threat landscape, inline ML models are added
or updated via content releases.
When the firewall checks PAN-DB for a URL, it also looks for crical updates, such as URLs that
previously qualified as benign but are now malicious.
If you believe PAN-DB has incorrectly categorized a site, you can submit a URL category change
request in your browser through Test A Site or directly from the firewall logs.
Did you know?

Technically, the firewall caches URLs on both the management plane and the dataplane:
• PAN-OS 9.0 and later releases do not download PAN-DB seed databases. Instead,
upon acvaon of the URL filtering license, the firewall populates the cache as URL
queries are made.
• The management plane holds more URLs and communicates directly with PAN-DB.
When the firewall cannot find a URL’s category in the cache and performs a lookup in
PAN-DB, it caches the retrieved category informaon in the management plane. The
management plane passes that informaon along to the dataplane, which also caches
it and uses it to enforce policy.
• The dataplane holds fewer URLs and receives informaon from the management
plane. Aer the firewall checks URL category excepon lists (custom URL categories
and external dynamic lists) for a URL, the next place it looks is the dataplane. Only
if the firewall cannot find the URL categorized in the dataplane does it check the
management plane and, if the category informaon is not there, PAN-DB.
URL Filtering
URL Filtering Inline ML

URL Filtering inline ML enables the firewall dataplane to apply machine learning on webpages to
alert users when phishing variants are detected while prevenng malicious variants of JavaScript
exploits from entering your network. Inline ML dynamically analyzes and detects malicious
content by evaluang various web page details using a series of ML models. Each inline ML model
detects malicious content by evaluang file details, including decoder fields and paerns, to
formulate a high probability classificaon and verdict, which is then used as part of your larger
web security policy. URLs classified as malicious are forwarded to PAN-DB for addional analysis
and validaon. You can specify URL excepons to exclude any false-posives that might be
encountered. This allows you to create more granular rules for your profiles to support your
specific security needs. To keep up with the latest changes in the threat landscape, inline ML
models are updated regularly and added via content releases. An acve Advanced URL Filtering or
legacy URL Filtering license is required to configure URL Filtering inline ML.
Inline ML-based protecon can also be enabled to detect malicious PE files and PowerShell scripts
in real-me as part of your Anvirus profile configuraon. For more informaon, refer to: WildFire
Inline ML
URL Filtering inline ML is not supported on the VM-50 or VM50L virtual appliance.
URL Filtering
URL Filtering Use Cases

There are many ways to enforce web page access beyond only blocking and allowing certain sites.
For example, you can use mulple categories per URL to allow users to access a site, but block
parcular funcons like subming corporate credenals or downloading files. You can also use
URL categories to enforce different types of policy, such as Authencaon, Decrypon, QoS, and
Security.
Read on for more about the different ways that you can deploy URL filtering.
Control web access based on URL category

You can create a URL Filtering profile that specifies an acon for a URL category and aach the
profile to a policy rule. The firewall enforces policy against traffic based on the sengs in the
profile. For example, to block all gaming websites you could set the block acon for the URL
category games in the URL Filtering profile and aach it to the Security policy rule(s) that allow
web access.
Mul-Category URL Filtering

Every URL can have up to four categories, including a risk category that indicates the likelihood
a site will expose you to threats. More granular URL categorizaons means that you can move
beyond a basic “block-or-allow” approach to web access. Instead, you can control how your users
interact with online content that, while necessary for business, is more likely to be used as part of
a cyberaack.
For instance, you might consider certain URL categories risky to your organizaon, but are
hesitant to block them outright as they also provide valuable resources or services (like cloud
storage services or blogs). Now, you can allow users to visit sites that fall into these types of URL
categories while you protect your network by decrypng and inspecng traffic and enforcing
read-only access to the content.
For a URL category that you want to ghtly control, set the URL Filtering profile acon to alert
as part of the steps to configure URL Filtering. Then connue to follow the URL Filtering best
pracces: decrypt the URL category, block dangerous file downloads, and turn on credenal
phishing prevenon.
You can also define a custom URL category by selecng Category Match and specifying two or
more PAN-DB categories of which the new category will consist. Creang a custom category from
mulple categories allows you to target enforcement for a website or page that matches all of the
categories specified in the custom URL category object.
Block or allow corporate credenal submissions based on URL category

Prevent credenal phishing by enabling the firewall to detect corporate credenal submissions
to sites, and then control those submissions based on URL category. Block users from subming
credenals to malicious and untrusted sites, warn users against entering corporate credenals on
unknown sites or reusing corporate credenals on non-corporate sites, and explicitly allow users
to submit credenals to corporate and sanconed sites.
URL Filtering
Enforce Safe Search Sengs

Many search engines have a safe search seng that filters out adult images and videos from
search results. You can enable the firewall to block search results if the end user is not using the
strictest safe search sengs, and you can transparently enable safe search for your users. The
firewall supports safe search enforcement for the following search providers: Google, Yahoo, Bing,
Yandex, and YouTube. See how to get started with Safe Search Enforcement.
Enforce Password Access to Certain Sites

You can block access to a site for most users while allowing certain users to access the site. See
how to allow password access to certain sites.
Block high-risk file downloads from certain URL categories

You can block high-risk file downloads from specific URL categories by creang a Security policy
with a File Blocking profile aached.
Enforce Security, Decrypon, Authencaon, and QoS policies based on URL category
You can enforce different types of firewall policies based on URL categories. For example, suppose
you have enabled Decrypon, but you want to exclude certain personal informaon from being
decrypted. In this case you could create a Decrypon policy rule that excludes websites that
match the URL categories financial-services and health-and-medicine from decrypon. Another
example would be to use the URL category streaming-media in a QoS policy to apply bandwidth
controls to websites that fall in to this category.
The following table describes the policies that accept URL categories as match criteria:
Policy Type Descripon
Decrypon You can also use URL categories to phase-in decrypon, and to exclude
URL categories that might contain sensive or personal informaon
from decrypon (like financial-services and health-and-medicine).
Plan to decrypt the riskiest traffic first (URL categories most likely to
harbor malicious traffic, such as gaming or high-risk) and then decrypt
more as you gain experience. Alternavely, decrypt the URL categories
that don’t affect your business first (if something goes wrong, it won’t
affect business), for example, news feeds. In both cases, decrypt a few
URL categories, listen to user feedback, run reports to ensure that
decrypon is working as expected, and then gradually decrypt a few
more URL categories, and so on. Plan to make decrypon exclusions to
exclude sites from decrypon if you can’t decrypt them for technical
reasons or because you choose not to decrypt them.
Decrypng traffic based on URL categories is a best pracce

for both URL Filtering and Decrypon.
URL Filtering
Authencaon To ensure that users authencate before being allowed access to a

specific category, you can aach a URL category as a match criterion for
Authencaon policy rules.
QoS Use URL categories to allocate throughput levels for specific website
categories. For example, you may want to allow the streaming-media
category, but limit throughput by adding the URL category to a QoS
policy rule.
Security In Security policy rules, you can use URL categories in two ways:
• Enforce policy based on URL categories by selecng them as match
criteria.
• Aach a URL Filtering profile that specifies the policy acon for each
category.
If for example, the IT-security group in your company needs access
to the hacking category, but all other users are denied access to the
category, you must create the following rules:
• A Security policy rule that allows the IT-Security group to access
content categorized as hacking. The Security policy rule references
the hacking category in the Services/URL Category tab and IT-
Security group in the Users tab.
• Another Security policy rule that allows general web access for all
users. To this rule you aach a URL Filtering profile that blocks the
hacking category.
You must list the policy that allows access to hacking before the policy
that blocks hacking. This is because the firewall evaluates Security policy
rules from the top down, so when a user who is part of the security
group aempts to access a hacking site, the firewall evaluates the policy
rule that allows access first and grants the user access. The firewall
evaluates users from all other groups against the general web access
rule that blocks access to the hacking sites.
URL Filtering
URL Categories
PAN-DB classifies websites based on site content, features, and safety. A URL can have up to four
categories, including risk categories (high, medium, and low), which indicate how likely it is that
the site will expose you to threats. For a complete list of predefined URL categories, see PAN-DB
URL Filtering Categories.
Visit Test A Site to see how PAN-DB categorizes a URL, and to learn about all available URL
categories. You can also use Test A Site to submit a URL category change request, or you can
submit the request directly in the firewall: select Monitor > Logs and open the details for a log
entry. Under the URL category, you’ll see the opon to submit a change request.
Read on to learn more about URL categories:
• URL Filtering Use Cases
• Security-Focused URL Categories
• Malicious URL Categories
• Verified URL Categories
• Policy Acons You Can Take Based on a URL Category
Security-Focused URL Categories

Security-focused URL categories can help you to reduce your aack surface by providing targeted
decrypon and enforcement for sites that pose varying levels of risk, but are not confirmed
malicious. Websites are classified with a security-related category only so long as they meet the
criteria for that category; as site content changes, policy enforcement dynamically adapts. You
cannot submit a change request for security-focused URL categories.
High-Risk High-risk sites include:

• Sites previously confirmed to be malware, phishing, or
C2 sites. These sites will remain in this category for at
least 30 days.
• Unknown domains are classified as high-risk unl PAN-
DB completes site analysis and categorizaon.
• Sites that are associated with confirmed malicious
acvity. For example, a page might be high-risk if there
are malicious hosts on the same domain, even if the
page itself does not contain malicious content.
• Bulletproof ISP-hosted sites.
• Domains classified as DDNS due to the presence of an
acve dynamic DNS configuraon.
• Sites hosted on IPs from ASNs that are known to allow
malicious content.
URL Filtering

Default and Recommended Policy Acon: Alert
Medium-Risk Medium-risk sites include:

• All cloud storage sites (with the URL category online-
storage-and-backup).
• Sites previously confirmed to be malware, phishing, or
C2 sites that have displayed only benign acvity for at
least 30 days. These sites will remain in this category for
an addional 60 days.
• Unknown IP addresses are categorized as medium-
risk unl PAN-DB completes site analysis and
categorizaon.
Default and Recommended Policy Acon: Alert
Low-Risk Sites that are not medium or high risk are considered
low risk. These sites have displayed benign acvity for a
minimum of 90 days.
Default and Recommended Policy Acon: Allow
Newly-Registered Domains Idenfies sites that have been registered within the last
32 days. New domains are frequently used as tools in
malicious campaigns.
Default Policy Acon: Alert
Recommended Policy Acon: Block
Newly-registered domains are oen generated

purposefully or by domain generaon
algorithms and used for malicious acvity. It is
a best pracce to block this URL category.
Malicious URL Categories

We strongly recommend that you block the URL categories that idenfy malicious or exploive
content. To get started, you can clone the default URL Filtering profile which blocks malware,
phishing, and command-and-control URL categories by default. The default URL Filtering
profile also blocks the abused-drugs, adult, gambling, hacking, quesonable, and weapons URL
categories. Whether to block these URL categories depends on your business requirements.
For example, a university probably won’t want to restrict student access to most of these sites
because availability is important, but a business that values security first may block some or all of
them.
• command-and-control—Command-and-control URLs and domains used by malware and/or
compromised systems to surrepously communicate with an aacker's remote server to
receive malicious commands or exfiltrate data.
URL Filtering
• malware—Sites known to host malware or used for command and control (C2) traffic. May also
exhibit Exploit Kits.
• phishing—Known to host credenal phishing pages or phishing for personal idenficaon. This
includes web content that covertly aempts to fool the user in order to harvest informaon,
including login credenals, credit card informaon – voluntarily or involuntarily, account
numbers, PINs, and any informaon considered to be personally idenfiable informaon (PII)
from vicms via social engineering techniques. Technical support scams and scareware are also
included as phishing.
• grayware—Websites and services that do not meet the definion of a virus or pose a direct
security threat but displays obtrusive behavior and influences users to grant remote access
or perform other unauthorized acons. Grayware includes scams, illegal acvies, criminal
acvies, get rich quick sites, adware, and other unwanted or unsolicited applicaons, such as
embedded crypto miners or hijackers that change the elements of the browser. Typosquang
domains that do not exhibit maliciousness and is not owned by the targeted domain will be
categorized as grayware. Prior to Content release version 8206, the firewall placed grayware
in either the malware or quesonable URL category. If you are unsure about whether to block
grayware, start by alerng on grayware, invesgate the alerts, and then decide whether to
block grayware or connue to alert on grayware.
• dynamic-dns—Hosts and domain names for systems with dynamically assigned IP addresses
and which are oenmes used to deliver malware payloads or C2 traffic. Also, dynamic DNS
domains do not go through the same veng process as domains that are registered by a
reputable domain registraon company, and are therefore less trustworthy.
• unknown—Sites that have not yet been idenfied by PAN-DB. If availability is crical to your
business and you must allow the traffic, alert on unknown sites, apply the best pracce Security
profiles to the traffic, and invesgate the alerts.
PAN-DB Real-Time Updates learns unknown sites aer the first aempt to access an
unknown site, so unknown URLs are idenfied quickly and become known URLs that
the firewall can then handle based on the actual URL category.
• newly-registered-domain—Newly registered domains are oen generated purposely or by
domain generaon algorithms and used for malicious acvity.
• copyright-infringement—Domains with illegal content, such as content that allows illegal
download of soware or other intellectual property, which poses a potenal liability risk. This
category was introduced to enable adherence to child protecon laws required in the educaon
industry as well as laws in countries that require internet providers to prevent users from
sharing copyrighted material through their service.
• extremism—Websites promong terrorism, racism, fascism, or other extremist views
discriminang against people or groups of different ethnic backgrounds, religions or other
beliefs. This category was introduced to enable adherence to child protecon laws required in
the educaon industry. In some regions, laws and regulaons may prohibit allowing access to
extremist sites, and allowing access may pose a liability risk.
• proxy-avoidance-and-anonymizers—URLs and services oen used to bypass content filtering
products.
• quesonable— Websites containing tasteless humor, offensive content targeng specific
demographics of individuals, or groups of people.
URL Filtering
• parked—Domains registered by individuals, oenmes later found to be used for

credenal phishing. These domains may be similar to legimate domains, for example,
pal0alto0netw0rks.com, with the intent of phishing for credenals or personal idenfy
informaon. Or, they may be domains that an individual purchases rights to in hopes that it
may be valuable someday, such as panw.net.
For categories that you decide to alert on, instead of block, you can very strictly control how
users interact with site content. For example, give users access to the resources they need
(like developer blogs for research purposes or cloud storage services), but take the following
precauons to reduce exposure to web-based threats:
Follow the An-Spyware, Vulnerability Protecon, and File Blocking best pracces. A
protecve measure would be to block downloads of dangerous file types and blocking
obfuscated JavaScript for sites that you are alerng on.
Target decrypon based on URL category. A good start would be to decrypt high-risk and
medium-risk sites.
Display a response page to users when they visit high-risk and medium-risk sites. Alert them
that the site they are aempng to access is potenally malicious, and advise them on how to
take precauons if they decide to connue to the site.
Stop credenal the by blocking users from subming their corporate credenals to sites
including those that are high-risk and medium-risk.
Verified URL Categories

URLs that are verified by Palo Alto Networks to be a part of a specific group of categories do
not possess an associated risk level; risk levels are only applicable to URLs that have not been
verified. Verified URLs in certain categories (see below) are considered malicious and are blocked
by default because access to these URLs present a risk that is beyond an acceptable level for most
environments. Private IP addresses (and hosts) are unique to the host environment and are not
visible to PAN-DB; and as a result, a risk rang is not generated.
Category Default Acon
Malware Block
Phishing
Command and Control
Grayware
Private IP Addresses Allowed (no default acon)
For more informaon about current URL categories, refer to: Complete List of PAN-DB
URL Filtering Categories
URL Filtering
Policy Acons You Can Take Based on URL Categories

On the firewall, you can use a URL Filtering profile to specify how you would like to enforce URL
categories. By default, site access for all URL categories is set to allow when you create a new
URL Filtering profile. This means that the users will be able to browse to all sites freely and the
traffic is not logged. Customize the URL Filtering profile by deciding what type of Site Access you
want to enforce for each category. To prevent credenal phishing, you can also allow or disallow
User Credenal Submissions based on URL category (for example, you can block user credenal
submissions to medium and high-risk sites). Users can sll access these sites, but cannot enter
submit their corporate credenals to them.
To start enforcing the acons you’ve defined in a URL Filtering, you’ll need to aach the profile to
a Security policy rule. The firewall enforces the profile acons on traffic that matches the Security
policy rule (for details, see Configure URL Filtering).
Learn more about configuring a best pracce URL Filtering profile to ensure protecon
against URLs that have been observed hosng malware or exploitave content.
Acon Descripon
Site Access
alert The website is allowed and a log entry is generated in the URL filtering
log.
Set alert as the Acon for categories of traffic you don’t block
to log and provide visibility into the traffic.
allow The website is allowed and no log entry is generated.
Don’t set allow as the Acon for categories of traffic you

don’t block because you lose visibility into traffic you don’t
log. Instead, set alert as the Acon for categories of traffic
you don’t block to log and provide visibility into the traffic.
block The website is blocked and the user will see a response page and will
not be able to connue to the website. A log entry is generated in the
URL filtering log.
Blocking site access for a URL category also sets User Credenal
Submissions for that URL category to block.
connue The user will be prompted with a response page indicang that the site
has been blocked due to company policy, but the user is prompted with
the opon to connue to the website. The connue acon is typically
used for categories that are considered benign and is used to improve
the user experience by giving them the opon to connue if they feel
the site is incorrectly categorized. The response page message can be
URL Filtering
customized to contain details specific to your company. A log entry is
generated in the URL filtering log.
The Connue page doesn’t display properly on client systems

configured to use a proxy server.
override The user will see a response page indicang that a password is required
to allow access to websites in the given category. With this opon, the
security admin or helpdesk person would provide a password granng
temporary access to all websites in the given category. A log entry
is generated in the URL filtering log. See Allow Password Access to
Certain Sites.
In earlier release versions, URL Filtering category overrides had priority
enforcement ahead of custom URL categories. As part of the upgrade
to PAN-OS 9.0, URL category overrides are converted to custom URL
categories, and no longer receive priority enforcement over other
custom URL categories. Instead of the acon you defined for the
category override in previous release versions, the new custom URL
category is enforced by the security policy rule with the strictest URL
Filtering profile acon. From most strict to least strict, possible URL
Filtering profile acons are: block, override, connue, alert, and allow.
This means that, if you had URL category overrides with the acon
allow, there’s a possibility the overrides might be blocked aer they are
converted to custom URL category in PAN-OS 9.0.
The Override page doesn’t display properly on client systems

configured to use a proxy server.
none The none acon only applies to custom URL categories. Select none to
ensure that if mulple URL Filtering profiles exist, the custom category
will not have any impact on other profiles. For example, if you have two
URL Filtering profiles and the custom URL category is set to block in
one profile, if you do not want the block acon to apply to the other
profile, you must set the acon to none.
Also, in order to delete a custom URL category, it must be set to none in
any profile where it is used.
User Credenal Permissions
These sengs require you to first set up credenal phishing prevenon.
alert Allow users to submit corporate credenals to sites in this URL

category, but generate a URL Filtering alert log each me this occurs.
URL Filtering
allow (default) Allow users to submit corporate credenals to websites in this URL
category.
block Block users from subming corporate credenals to websites in this

category. A default an-phishing response page is displayed to users
when they access sites to which corporate credenal submissions are
blocked. You can choose to create a custom block page to display.
connue Display a response page to users that prompts them to select Connue
to access to access the site. By default, the An Phishing Connue Page
is shown to user when they access sites to which credenal submissions
are discouraged. You can also choose to create a custom response page
to display—for example, if you want to warn users against phishing
aempts or reusing their credenals on other websites.
URL Filtering
Plan Your URL Filtering Deployment

To deploy URL filtering in your network, we recommend that you start with a basic setup that’ll
give you visibility into web acvity paerns while blocking confirmed malicious content:
Start with a (mostly) passive URL Filtering profile that alerts on most categories. This gives you
visibility into the sites your users are accessing, so you can decide what you want allow, limit,
and block.
Block URL categories that we know are bad: malware, C2, and phishing.
Because alerng on all web acvity might create a large amount of log files, you might decide you
only want to do this as you’re inially deploying URL Filtering.
At that me, you can also reduce URL filtering logs by enabling the Log container page
only opon in the URL Filtering profile so only the main page that matches the category
will be logged, not subsequent pages/categories that may be loaded within the container
page.
STEP 1 | At any me, you can use Test A Site to see how PAN-DB—the URL Filtering cloud database—
categorizes a specific URL, and to learn about all possible URL categories.
You can also use Test A Site to submit a change request, if you disagree with how a specific
URL is categorized.
STEP 2 | Create a passive URL Filtering profile, that alerts on all categories so you have visibility into
web traffic.
1. Select Objects > Security Profiles> URL Filtering.
2. Select the default profile and then click Clone. The new profile will be named default-1.
3. Select the default-1 profile and rename it. For example, rename it to URL-Monitoring.
URL Filtering
STEP 3 | Configure the acon for all categories to alert, except for malware, command-and-control,
and phishing, which should remain blocked.
1. In the secon that lists all URL categories, select all categories and then de-select
malware, command-and-control, and phishing.
2. To the right of the Acon column heading, mouse over and select the down arrow and
then select Set Selected Acons and choose alert.
3. Block access to known dangerous URL categories.
Block access to malware, phishing, dynamic-dns, unknown, command-and-

control, extremism, copyright-infringement, proxy-avoidance-and-anonymizers,
newly-registered-domain, grayware, and parked URL categories.
STEP 4 | Apply the URL Filtering profile to the Security policy rule(s) that allows web traffic for users.
1. Select Policies > Security and select the appropriate Security policy to modify it.
2. Select the Acons tab and in the Profile Seng secon, click the drop-down for URL
Filtering and select the new profile.

Click Commit.
STEP 6 | View the URL filtering logs to see all of the website categories that your users are accessing.
The categories you’ve set to block are also logged.
For informaon on viewing the logs and generang reports, see Monitor Web Acvity.
Select Monitor > Logs > URL Filtering. A log entry will be created for any website that exists in
the URL filtering database that is in a category set to any acon other than allow. URL Filtering
reports give you a view of web acvity in a 24-hour period. ( Monitor > Reports).
URL Filtering
STEP 7 | Next Steps:

• PAN-DB categorizes every URL with up to four categories, and every URL has a risk
category (high, medium, and low). While high and medium-risk sites are not confirmed
malicious, they are closely associated with malicious sites. For example, they might be on
the same domain as malicious sites or maybe they hosted malicious content unl only very
recently. For everything that you do not allow or block, you can use risk categories to write
simple policy based on website safety.
You can take precauonary measures to limit your users’ interacon high-risk sites
especially, as there might be some cases where you want to give your users access to
sites that might also present safety concerns (for example, you might want to allow
your developers to use developer blogs for research, yet blogs are a category known to
commonly host malware).
• Pair URL Filtering with User-ID to control web access based on organizaon or department
and to block corporate credenal submissions to unsanconed sites:
• URL Filtering prevents credenal the by detecng corporate credenal submissions to
sites based on the site category. Block users from subming credenals to malicious and
untrusted sites, warn users against entering corporate credenals on unknown sites or
reusing corporate credenals on non-corporate sites, and explicitly allow users to submit
credenals to corporate sites.
• Add or update a Security policy rule with the passive URL Filtering profile so that it
applies to a department user group, for example, Markeng or Engineering ( Policies >
Security > User). Monitor the department acvity, and get feedback from department
members to understand the web resources that are essenal to the work they do.
• Consider all the ways you can use URL Filtering to reduce your aack surface and to control
web usage. For example, if you’re a school, you can use URL Filtering to enforce strict safe
search sengs, where search engines filter out adult images and videos from search results.
Or, if you have a security operaons center, you might give threat analysts password access
to compromised or dangerous sites for research, that you might not want to otherwise open
up to enre organizaons or teams.
• Follow the URL Filtering best pracces.
URL Filtering
URL Filtering Best Pracces

Palo Alto Networks URL filtering soluon protects you from web-based threats, and gives you
a simple way to monitor and control web acvity. To get the most out of your URL filtering
deployment, you should start by creang allow rules for the applicaons you rely on to do
business. Then, review the URL categories that classify malicious and exploive content—we
recommend that you block these outright. Then, for everything else, these best pracces can
guide you how to reduce your exposure to web-based threats, without liming your users’ access
to web content that they need.
• Before you get started, idenfy the applicaons you want to allow and create applicaon allow
rules as part of building a best pracce internet gateway security policy.
Allowed applicaons include not only the applicaons you provision and administer for
business and infrastructure purposes, but also the applicaons that your users need to get their
jobs done and applicaons you might want to allow for personal use.
Aer you’ve idenfied these sanconed applicaons, you can use URL filtering to control and
secure all the web acvity that is not on the allow list.
• Get visibility in to your users web acvity so you can plan the most effecve URL filtering
policy for your organizaon, and roll it out smoothly. This includes:
• Using Test A Site to see how PAN-DB—the Palo Alto Networks URL filtering cloud database
—categorizes a specific URL, and to learn about all possible URL categories.
• Starng with a (mostly) passive URL Filtering profile that alerts on URL categories. This gives
you visibility into the sites your users are accessing, so you can decide what you want to
allow, limit, and block.
• Monitoring web acvity to assess the sites your users are accessing and see how they align
with your business needs.
• Block URL categories that classify malicious and exploive web content. While we know that
these categories are dangerous, always keep in mind that the URL categories that you decide to
block might depend on your business needs.
• Use URL categories to phase-in decrypon, and to exclude sensive or personal informaon
(like financial-services and health-and-medicine) from decrypon.
Plan to decrypt the riskiest traffic first (URL categories most likely to harbor malicious traffic,
such as gaming or high-risk) and then decrypt more as you gain experience. Alternavely,
decrypt the URL categories that don’t affect your business first (if something goes wrong, it
won’t affect business), for example, news feeds. In both cases, decrypt a few URL categories,
listen to user feedback, run reports to ensure that decrypon is working as expected, and then
gradually decrypt a few more URL categories, and so on. Plan to make decrypon exclusions to
exclude sites from decrypon if you can’t decrypt them for technical reasons or because you
choose not to decrypt them.
Targeng decrypon based on URL categories is also a Decrypon best pracce.
• Prevent credenal the by enabling the firewall to detect corporate credenal submissions to
sites, and then control those submissions based on URL category. Block users from subming
credenals to malicious and untrusted sites, warn users against entering corporate credenals
URL Filtering
on unknown sites or reusing corporate credenals on non-corporate sites, and explicitly allow
users to submit credenals to corporate and sanconed sites.
• Block malicious variants of JavaScript exploits and phishing aacks in real-me. Enabling URL
Filtering Inline ML allows you to dynamically analyze web pages using machine learning on the
firewall.
• Decrypt, inspect, and strictly limit how users interact with high-risk and medium-risk content (if
you decided not to block any of the malicious URL categories for business reasons, you should
also strictly limit how users interact with those categories).
The web content that you sancon and the malicious URL categories that you block outright
are just one poron of your overall web traffic. The rest of the content your users are accessing
is a combinaon of benign (low-risk) and risky content (high-risk and medium-risk). High-risk
and medium-risk content is not confirmed malicious but is closely associated with malicious
sites. For example, a high-risk URL might be on the same domain as a malicious site, or maybe it
hosted malicious content in the past.
However, many sites that pose a risk to your organizaon also provide valuable resources
and services to your users (cloud storage services are a good example). While these resources
and services are necessary for business, they are also more likely to be used as part of a
cyberaack. Here’s how to control how users interact with this potenally-dangerous content,
while sll providing them a good user experience:
• In a URL Filtering profile, set the high-risk and medium-risk categories to connue to display
a response page that warns users they’re vising a potenally-dangerous site. Advise them
how to take precauons if they decide to connue to the site. If you don’t want to prompt
users with a response page, alert on the high-risk and medium-risk categories instead.
• Decrypt decrypt high-risk and medium-risk sites.
• Follow the An-Spyware, Vulnerability Protecon, and File Blocking best pracces for high-
risk and medium-risk sites. A protecve measure would be to block downloads of dangerous
file types and blocking obfuscated JavaScript.
• Stop credenal the by blocking users from subming their corporate credenals to high-
risk and medium-risk sites.
• Schools or educaonal instuons should use safe search enforcement to make sure
that search engines filter out adult images and videos from search results. You can even
transparently enable safe search for users.
• Enable the firewall to hold an inial web request as it looks up a website’s URL category with
PAN-DB.
When a user visits a website, a firewall with Advanced URL Filtering enabled checks its local
cache of URL categories to categorize the site. If the firewall doesn’t find the URL’s category in
the cache, it performs a lookup in PAN-DB, the Palo Alto Networks URL database. By default,
the firewall allows the user’s web request during this cloud lookup and enforces policy when
the server responds.
But when you choose to hold web requests, the firewall blocks the request unl it either finds
the URL category or mes out. If the lookup mes out, the firewall considers the URL category
not-resolved.
1. In Device > Setup > Content-ID, check the box for
Hold client request for category lookup.
URL Filtering
Acvate The Advanced URL Filtering Subscripon

Palo Alto Networks URL filtering soluon, the Advanced URL Filtering subscripon, provides
real me URL analysis and malware prevenon. In addion to PAN-DB access, the Palo Alto
Networks-developed URL filtering database for high-performance URL lookups, it also offers
coverage against malicious URLs and IP addresses. This mul-layered protecon soluon is
configured through your URL filtering profile.
STEP 1 | Obtain and install an Advanced URL Filtering license and confirm that it is installed.
The Advanced URL Filtering license includes access to PAN-DB; if the license expires,
the firewall ceases to perform all URL filtering funcons, URL category enforcement,
and URL cloud lookups. Addionally, all other cloud based updates will not funcon
unl you install a valid license.
1. Select Device > Licenses and, in the License Management secon, select the license
installaon method:
• Retrieve license keys from license server
• Acvate feature using authorizaon code
2. Aer installing the license, confirm that the Advanced URL Filtering secon, Date
Expires field, displays a valid date.
When you acvate the Advanced URL Filtering license, your license entlements
for PAN-DB and Advanced URL Filtering might not display correctly on the
firewall — this is a display anomaly, not a licensing issue, and does not affect
access to the services. You can update the licenses on the firewall to recfy
the display issue by using the following CLI command: request license
fetch.
STEP 2 | Download and install the latest PAN-OS content release. PAN-OS Applicaons and Threats
content release 8390-6607 and later allows firewalls operang PAN-OS 9.x and later to
idenfy URLs that have been categorized using the new real-me-detecon category,
idenfying URLs classified by advanced URL filtering. For more informaon about the
update, refer to the Applicaons and Threat Content Release Notes. You can also review
Content Release Notes for apps and threats on the Palo Alto Networks Support Portal or
directly in the firewall web interface: select Device > Dynamic Updates and open the Release
Note for a specific content release version.
Follow the Best Pracces for Applicaons and Threats Content Updates when
updang to the latest content release version.
URL Filtering
STEP 3 | Schedule the firewall to download dynamic updates for Applicaons and Threats.
A Threat Prevenon license is required to receive content updates, which covers

Anvirus and Applicaons and Threats.

2. In the Schedule field in the Applicaons and Threats secon, click the None link to
schedule periodic updates.
You can only schedule dynamic updates if the firewall has direct Internet access.
If updates are already scheduled in a secon, the link text displays the schedule
sengs.
The Applicaons and Threats updates somemes contain updates for URL filtering
related to Safe Search Enforcement.
Next Steps:
1. Configure a URL filtering profile to define your organizaon’s web usage policies.
2. Verify Advanced URL Filtering
URL Filtering
Configure URL Filtering

Aer you determine URL filtering policy requirements, you should have a basic understanding of
the types of websites and website categories your users are accessing. Use this informaon to
create custom URL Filtering profiles and aach them to the Security policy rules that allow web
access. In addion to managing web access with a URL Filtering profile, if you configure User-ID™,
you can manage the sites to which users can submit corporate credenals.
STEP 1 | Create a URL Filtering profile.
If you didn’t already, configure a best pracce URL Filtering profile to ensure
protecon against URLs hosng malware or exploive content.
Select Objects > Security Profiles > URL Filtering and Add or modify a URL Filtering profile.
STEP 2 | Define site access for each URL category.

Select Categories and set the Site Access for each URL category:
• allow traffic desned for that URL category; allowed traffic is not logged.
• Select alert to have visibility into sites that users are accessing. Traffic matching that
category is allowed but a URL filtering log is generated to record when a user accesses a site
in that category.
• Select block to deny access to traffic that matches that category and to enable logging of
the blocked traffic.
• Select connue to display a page to users with a warning and require them to click Connue
to proceed to a site in that category.
• To only allow access if users provide a configured password, select override. For more
details, see Allow Password Access to Certain Sites.
STEP 3 | Configure the URL Filtering profile to detect corporate credenal submissions to websites
that are in allowed URL categories.
To ensure the best performance and a low false posive rate, the firewall automacally
skips checking the credenal submissions for any App-ID™ associated with sites that
have never been observed hosng malware or phishing content—even if you enable
checks in the corresponding category. The list of sites for which the firewall skips
credenal checking is automacally updated through Applicaons and Threats content
updates.
1. Select User Credenal Detecon.

2. Select one of the methods to check for corporate credenal submissions to web pages
from the User Credenal Detecon drop-down:
• Use IP User Mapping—Checks for valid corporate username submissions and verifies
that the username matches the user logged in to the source IP address of the session.
The firewall matches the submied username against its IP address-to-username
URL Filtering
mapping table. You can use any of the user mapping methods described in Map IP
Addresses to Users.
• Use Domain Credenal Filter—Checks for valid corporate usernames and password
submissions and verifies that the username maps to the IP address of the logged-in
user. See Configure User Mapping Using the Windows User-ID Agent for instrucons
on how to set up User-ID to enable this method.
• Use Group Mapping—Checks for valid username submissions based on the user-
to-group mapping table populated when you configure the firewall to map users to
groups.
With group mapping, you can apply credenal detecon to any part of the directory
or to a specific group, such as groups like IT that have access to your most sensive
applicaons.
This method is prone to false posives in environments that do not have

uniquely structured usernames, so you should only use this method to protect
your high-value user accounts.
3. Set the Valid Username Detected Log Severity that the firewall uses to log detecon of
corporate credenal submissions (default is medium).
STEP 4 | Configure the URL Filtering profile to detect phishing and malicious JavaScript in real-me
using URL Filtering Inline ML.
STEP 5 | Allow or block users from subming corporate credenals to sites based on URL category to
prevent credenal phishing.
To ensure the best performance and a low false posive rate, the firewall automacally
skips checking the credenal submissions for any App-ID associated with sites that
have never been observed hosng malware or phishing content—even if you enable
checks in the corresponding category. The list of sites for which the firewall skips
credenal checking is automacally updated through Applicaons and Threats content
updates.
1. For each URL category to which you allow Site Access, select how you want to treat
User Credenal Submissions:
• alert—Allow users to submit credenals to the website but generate a URL filtering
alert log each me a user submits credenals to sites in this URL category.
• allow (default)—Allow users to submit credenals to the website.
• block—Displays the An Phishing Block Page to block users from subming
credenals to the website.
• connue—Present the An Phishing Connue Page to require users to click Connue
to access the site.
2. Configure the URL Filtering profile to detect corporate credenal submissions to
websites that are in allowed URL categories.
URL Filtering
STEP 6 | Define URL category excepon lists to specify websites that should always be blocked or
allowed, regardless of URL category.
For example, to reduce URL filtering logs, you may want to add your corporate websites to
the allow list so that no logs are generated for those sites or, if there is a website that is being
overly used and is not work-related, you can add that site to the block list.
The policy acons configured for custom URL categories have priority enforcement over
matching URLs in external dynamic lists.
Traffic to websites in the block list is always blocked regardless of the acon for the associated
category and traffic to URLs in the allow list is always allowed.
For more informaon on the proper format and wildcard usage, review the URL category
excepon list guidelines.
STEP 7 | Enable Safe Search Enforcement.
STEP 8 | Log only Container Pages for URL filtering events.

1. Select URL Filtering Sengs. Enable Log container page only (default) so that the
firewall logs only the main page that matches the category, not subsequent pages or
categories that loaded within the container page.
2. To enable logging for all pages and categories, disable the Log container page only
opon.
STEP 9 | Enable HTTP Header Logging for one or more of the supported HTTP header fields.
Select URL Filtering Sengs and select one or more of the following fields to log:
• User-Agent
• Referer
• X-Forwarded-For
STEP 10 | Save the URL Filtering profile and commit your changes.
1. Click OK.
2. Click Commit.
STEP 11 | Test your URL filtering policy configuraon.

1. Access a website in the desired URL category and observe the firewall’s behavior.
Use Palo Alto Networks URL Filtering Test Pages (urlfiltering.paloaltonetworks.com/
test-<url-category>) if you want to avoid directly accessing a site. Palo Alto Networks has
test URLs for benign and malicious URL categories. For example, to test your block policy
for malware, visit hps://urlfiltering.paloaltonetworks.com/test-malware.
2. Review the Traffic and URL filtering logs (Monitor > Logs) to confirm that the correct
policy rule is logged.
URL Filtering
STEP 12 | Enable Hold client request for category lookup to block client requests while the firewall
performs URL category lookups.
1. Select Device > Setup > Content-ID.
2. Select Hold client request for category lookup.
Enable this feature as a URL Filtering best pracce.
STEP 13 | Set the amount of me, in seconds, before a URL category lookup mes out.
1. Select Device > Setup > Content-ID > gear icon.
2. Enter a number in Category lookup meout (sec).
3. Click OK.
URL Filtering
Test URL Filtering Configuraon

To test your URL Filtering and Advanced URL Filtering policy configuraons, use Palo Alto
Networks URL Filtering Test Pages. Test pages have been created for the safe tesng of all
predefined URL categories, including real-me-detecon categories applicable only to firewalls
running Advanced URL Filtering.
You must enable SSL decrypon for test pages to work over an HTTPS connecon.
Advanced URL filtering test pages contain “real-me-detecon” in the URL and confirm
that firewalls correctly categorize and analyze malicious URLs in real-me. They do not
verify firewall behavior for any other categories.
You can check the classificaon of a specific website using Palo Alto Networks URL
category lookup tool, Test A Site.
Follow the procedure corresponding to your URL Filtering subscripon:

• Verify URL Filtering
• Verify Advanced URL Filtering
Verify URL Filtering

If you have the legacy URL Filtering subscripon, test and verify that the firewall correctly
categorizes, enforces, and logs URLs in the categories that you access.
STEP 1 | Access a website in the URL category of interest.
Consider tesng sites in blocked URL categories. You can use a test page
(urlfiltering.paloaltonetworks.com/test-<url-category>) to avoid directly accessing a site. For
example, to test your block policy for malware, visit hps://urlfiltering.paloaltonetworks.com/
test-malware.
STEP 2 | Review the Traffic and URL Filtering logs (Monitor > Logs) to verify that your firewall
processes the site correctly.
For example, if you configured a block page to display when someone accesses a site that
violates your organizaon’s policy, check that one appears when you visit the test site.
Verify Advanced URL Filtering

If you have an Advanced URL Filtering subscripon, test and verify that real-me URL analysis is
happening.
URL Filtering
Palo Alto Networks recommends seng the real-me-detecon acon seng to alert for
your acve URL filtering profiles. This provides visibility into URLs analyzed in real-me
and will block (or allow, depending on your policy sengs) based on the category sengs
configured for specific web threats.
The firewall enforces the most severe acon of the acons configured for detected URL
categories of a given URL. For example, suppose example.com is categorized as real-me-
detecon, command-and-control, and shopping—categories with an alert, block, and allow
acon configured, respecvely. The firewall will block the URL because block is the most
severe acon from the detected categories.
STEP 1 | Visit each of the following test URLs to verify that the Advanced URL Filtering service is
properly categorizing URLs:
• Malware—urlfiltering.paloaltonetworks.com/test-real-me-detecon-malware
• Phishing—urlfiltering.paloaltonetworks.com/test-real-me-detecon-phishing
• C2—urlfiltering.paloaltonetworks.com/test-real-me-detecon-command-and-control
• Grayware—urlfiltering.paloaltonetworks.com/test-real-me-detecon-grayware
• Benign (unknown)—urlfiltering.paloaltonetworks.com/test-real-me-detecon
STEP 2 | Monitor the acvity on the firewall to verify that the tested URLs have been properly
categorized as real-me-detecon.
1. Select Monitor > Logs > URL Filtering and filter by (url_category_list contains
real-time-detection) to view logs that have been analyzed using Advanced URL
Filtering.
Addional web page category matches are also displayed and corresponds to the
categories as defined by PAN-DB.
2. Take a detailed look at the logs to verify that each type of web threat is correctly
analyzed and categorized.
In the next example, the URL is categorized as having been analyzed in real-me and
possessing qualies that define it as command-and-control (C2). Because the C2
URL Filtering
category has a more severe acon associated with it than real-me-detecon (block as
opposed to alert), the URL is categorized as command-and-control and blocked.
URL Filtering
Configure URL Filtering Inline ML

To enable your URL Filtering inline ML configuraon, aach the URL Filtering profile configured
with the inline ML sengs to a Security policy rule (see Set Up a Basic Security Policy).
URL Filtering inline ML is not currently supported on the VM-50 or VM50L virtual
appliance.
STEP 1 | To take advantage of URL Filtering inline ML, you must have an acve Advanced URL
Filtering or legacy URL Filtering subscripon.
Verify that you have a 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
display and are not expired. The image below shows the license entry for the legacy URL
Filtering subscripon.
STEP 2 | Create a new or update your exisng URL Filtering security profiles to use URL Filtering
inline ML.
1. Select an exisng URL Filtering Profile or Add a new one (Objects > Security Profiles > URL
Filtering).
2. Select Inline ML and define a policy Acon for each URL Filtering inline ML model.
This enforces the selected policy acon on a per model basis. Currently, there are two
URL Filtering
classificaon engines available: Phishing and JavaScript Exploit, one for each type of
malicious webpage content.
• Block—When the firewall detects a website with phishing content, the firewall generates
a URL Filtering log entry.
• Alert—The firewall allows access to the website but also generates a URL Filtering log
entry.
• Allow—The firewall allows access to the website does not generate a URL Filtering log
entry.
3. Click OK to exit the URL Filtering Profile configuraon dialog and Commit your changes.
URL Filtering
STEP 3 | (Oponal) Add URL excepons to your URL Filtering security profile if you encounter false-
posives. You can add excepons by specifying an external dynamic list from the URL
Filtering profile or by adding a web page entry from the URL Filtering logs.
• Add an external dynamic list of URL excepons.
1. Select Objects > Security Profiles > URL Filtering.
2. Select a URL Filtering profile for which you want to exclude specific URLs and then select
Inline ML.
3. Click Add to select a pre-exisng URL-based external dynamic list. If none is available,
create a new external dynamic list.
4. Click OK to save the URL Filtering profile and Commit your changes.
• Add file excepons from URL Filtering log entries.
1. Select Monitor > Logs > URL Filtering and filter the logs for URL entries with an Inline
ML Verdict of malicious-javascript or phishing. Select a URL Filtering log for a URL that
you wish to create an excepon for.
2. Go to the Detailed Log View and scroll down to the Details pane then select Create
Excepon located next to the Inline ML Verdict.
3. Select a custom category for the URL excepon and click OK.
4. The new URL excepon can be found in the list to which it was added, under Objects >
Custom Objects > URL Category.
STEP 4 | (Oponal) Verify the status of your firewall’s connecvity to the inline ML cloud service.
Use the following CLI command on the firewall to view the connecon status.
For example:
MLAV cloud
Current cloud server: ml.service.paloaltonetworks.com
Cloud connection: connected
If you are unable to connect to the inline ML cloud service, verify that the following domain is
not being blocked: ml.service.paloaltonetworks.com.
URL Filtering
To view informaon about web pages that have been processed using URL Filtering inline ML,
Filter the logs (Monitor > Logs > URL Filtering) based on Inline ML Verdict. Web pages that have
been determined to contain threats are categorized with verdicts of either phishing or malicious-
javascript. For example:
URL Filtering
Monitor Web Acvity

The ACC, URL filtering logs and reports show all user web acvity for URL categories that are set
to alert, block, connue, or override. By monitoring the logs, you can gain a beer understanding
of the web acvity of your user base to determine a web access policy.
The following topics describe how to monitor web acvity:
• Monitor Web Acvity of Network Users
• View the User Acvity Report
• Configure Custom URL Filtering Reports
Monitor Web Acvity of Network Users

You can use the Applicaon Command Center (ACC), URL filtering reports, and logs that are
generated on the firewall to track user acvity.
For a quick view of the most common categories users access in your environment, check the
ACC widgets. Most Network Acvity widgets allow you to sort on URLs. For example, in the
Applicaon Usage widget, you can see that the networking category is the most accessed
category, followed by encrypted tunnel, and ssl. You can also view the list of Threat Acvity
and Blocked Acvity sorted on URLs.
View logs and configure log opons:
URL Filtering
From the ACC, you can jump directly to the logs ( ) or select Monitor > Logs > URL Filtering.
The log acon for each entry depends on the Site Access seng you defined for the
corresponding category:
• Alert log—In this example, the computer-and-internet-info category is set to alert.
• Block log—In this example, the insufficient-content category is set to connue. If the
category had been set to block instead, the log Acon would be block-url.
• Alert log on encrypted website—In this example, the category is private-ip-addresses and
the applicaon is web-browsing. This log also indicates that the firewall decrypted this
traffic.
You can also add several other columns to your URL Filtering log view, such as: to and from
zone, content type, and whether or not a packet capture was performed. To modify what
columns to display, click the down arrow in any column and select the aribute to display.
URL Filtering
To view the complete log details and/or request a category change for the given URL that was
accessed, click the log details icon in the first column of the log.
Generate predefined URL filtering reports on URL categories, URL users, Websites accessed,
Blocked categories, and more.
Select Monitor > Reports and under the URL Filtering Reports secon, select one of the
reports. The reports cover the 24-hour period of the date you select on the calendar. You can
also export the report to PDF, CSV, or XML.
View the User Acvity Report

This report provides a quick method of viewing user or group acvity and also provides an opon
to view browse me acvity.
URL Filtering
STEP 1 | Configure a User Acvity Report.

1. Select Monitor > PDF Reports > User Acvity Report.
2. Add a report and enter a Name for it.
3. Select the report Type:
• Select User to generate a report for one person.
• Select Group for a group of users.
You must enable User-ID in order to be able to select user or group names. If
User-ID is not configured, you can select the type User and enter the IP address
of the user’s computer.
4. Enter the Username/IP Address for a user report or enter the group name for a user
group report.
5. Select the me period. You can select an exisng me period, or select Custom.
6. Select the Include Detailed Browsing check box, so browsing informaon is included in
the report.
URL Filtering
STEP 2 | Run the report.

1. Click Run Now.
2. When the firewall finishes generang report, click one of the links to download it:
• Click Download User Acvity Report to download a PDF version of the report.
• Click Download URL Logs to download a CSV file of the corresponding log entries.
3. Aer downloading the report, click Cancel.

4. If you want to save the user acvity report sengs so you can run the same report again
later, click OK; otherwise click Cancel.
STEP 3 | View the user acvity report by opening the file that you downloaded. The PDF version of
the report shows the user or group on which you based the report, the report me frame,
and a table of contents:
STEP 4 | Click an item in the table of contents to view the report details. For example, click Traffic
Summary by URL Category to view stascs for the selected user or group.
Configure Custom URL Filtering Reports

To generate a detailed report that you can schedule to run regularly, configure a custom URL
Filtering report. You can choose any combinaon of URL Filtering log fields on which to base the
report.
URL Filtering
STEP 1 | Add a new custom report.

1. Select Monitor > Manage Custom Reports and Add a report.
2. Give the report a unique Name, and oponally a Descripon.
3. Select the Database you want to use to generate the report. To generate a detailed URL
Filtering report, select URL from the Detailed Logs secon:
URL Filtering
STEP 2 | Configure report opons.

1. Select a predefined Time Frame or select Custom.
2. Select the log columns to include in the report from the Available Columns list add them (
) to the Selected Columns. For example, for a URL Filtering report you might select:
• Acon
• App Category
• Category
• Desnaon Country
• Source User
• URL
3. If the firewall is enabled to prevent credenal phishing, select the Aribute Flags, the
Operator has and the Value Credenal Detected to also include events in the report that
record when a user submied a valid corporate credenal to a site.
4. (Oponal) Select a Sort By opon to set the aribute to use to aggregate the report
details. If you do not select an aribute to sort by, the report will return the first N
number of results without any aggregaon. Select a Group By aribute to use as an
URL Filtering
anchor for grouping data. The following example shows a report with Group By set to
App Category and Sort By set to a Count of Top 5.
STEP 3 | Run the report.

1. Click the Run Now icon to immediately generate the report, which opens in a new tab.
2. When you are done reviewing the report, go back to the Report Seng tab and either
tune the sengs and run the report again, or connue to the next step to schedule the
report.
3. Select the Schedule check box to run the report once per day. This will generate a daily
report that details web acvity over the last 24 hours.
STEP 5 | View the custom report.

1. Select Monitor > Reports.
2. Expand the Custom Reports pane in the right column and select the report you want to
view. The latest report displays automacally.
3. To view the report for a previous date, select the date from the calendar. You can also
export the report to PDF, CSV, or XML.
URL Filtering
Log Only the Page a User Visits

A container page is the main page that a user accesses when vising a website, but addional
pages might be loaded along with the main page. If the Log Container page only opon is enabled
in a URL Filtering profile (Objects > Security Profiles > URL Filtering), only the main container
page will be logged, not subsequent pages that may be loaded within the container page. Because
URL filtering can potenally generate a lot of log entries, you may want to turn on this opon, so
log entries will only contain those URIs where the requested page file name matches the specific
mime-types. The default set includes the following mime-types:
• applicaon/pdf
• applicaon/soap+xml
• applicaon/xhtml+xml
• text/html
• text/plain
• text/xml
If you enable the Log container page only opon, there may not always be a correlated
URL log entry for threats detected by anvirus or vulnerability protecon.
URL Filtering
Create a Custom URL Category

You can create a custom URL filtering object to specify excepons to URL category enforcement,
and to create a custom URL category based on mulple URL categories:
• Define excepons to URL category enforcement—Create a custom list of URLs that you want
to use as match criteria in a Security policy rule. This is a good way to specify excepons to
URL categories, where you’d like to enforce specific URLs differently than the URL category to
which they belong.
• Define a custom URL category based on mulple PAN-DB categories—This allows you to
target enforcement for websites that match a set of categories. The website or page must
match all the categories defined as part of the custom category.
Follow these steps to create a custom URL category, and define how you’d like the firewall to
enforce the custom URL category:
STEP 1 | Select Objects > Custom Objects > URL Category.
STEP 2 | Add or modify a custom URL category, and give the category a descripve Name.
STEP 3 | Set the category Type to either Category Match or URL List:
• URL List—Add URLs that you want to enforce differently than the URL category to which
they belong. Use this list type to define excepons for URL category enforcement, or to
define a list of URLs as belonging to a custom category. For details on how to populate
this list, such as guidelines on how to use wildcards, see URL Category Excepons.
• Category Match—Provide targeted enforcement for websites that match a set of
categories. The website or page must match all the categories defined as part of the
custom category.
STEP 4 | Select OK to save the custom URL category.
URL Filtering
STEP 5 | Select Objects > Security Profiles > URL Filtering and Add or modify a URL Filtering profile.
Your new custom category will be listed under the Custom URL Categories drop down:
STEP 6 | Decide how you want to enforce Site Access and User Credenal Submissions for the
custom URL category. (To control the sites to which users can submit their corporate
credenals, see Prevent Credenal Phishing).
STEP 7 | Aach the URL Filtering profile to a Security policy rule, to enforce traffic that matches that
rule.
Select Policies > Security > Acons and specify the Security policy rule to enforce traffic
based on the URL Filtering profile you just updated. Make sure to Commit your changes.
You can also use custom URL categories as Security policy match criteria. In this
case, you do not need to define how the category should be enforced as part of a URL
Filtering profile. Aer seng up the custom category, go directly to the Security policy
rule to which you want to add the custom URL category (Policies > Security). Select
Service/URL Category to use the custom URL category as match criteria for the rule.
URL Filtering
URL Category Excepons

You can exclude specific websites from URL category enforcement, ensuring that these websites
are blocked or allowed regardless of the policy acon associated with its URL categories. For
example, you might block the social-networking URL category but allow access to LinkedIn. To
create excepons to URL category policy enforcement:
• Add the IP addresses or URLs of the sites you want to explicitly block or allow to a custom
URL category list (Objects > Custom Objects > URL Category). Then, define site access for the
custom URL category in a URL Filtering profile. Finally, aach the profile to a Security policy
rule.
You can also use a custom URL category as match criteria in a Security policy rule
(Policies > Security, and select Service/URL Category). The excepon rule must be
placed above any rules that block or allow the categories to which the URL excepons
belong.
• Use an external dynamic list in a URL Filtering profile or as match criteria in a Security policy
rule. The benefit to using an external dynamic list is that you can update the list without
performing a configuraon change or commit on the firewall.
The following guidelines describe how to populate URL category block and allow lists, or a text file
that you’re using as the source of an external dynamic list for URLs:
• Basic Guidelines For URL Category Excepon Lists
• Wildcard Guidelines for URL Category Excepon Lists
• URL Category Excepon List—Wildcard Examples
Basic Guidelines For URL Category Excepon Lists

• Enter the IP addresses or URLs of websites that you want to enforce separately from the
associated URL category.
• List entries must be an exact match and are case-insensive.
• Enter a string that is an exact match to the website (and possibly, specific subdomain) for which
you want to control access, or use wildcard characters to allow an entry to match to mulple
website subdomains. For details on using wildcard characters, review Wildcard Guidelines for
URL Category Excepon Lists.
• Omit http and https from URL entries.
• Each URL entry can be up to 255 characters in length.
Wildcard Guidelines for URL Category Excepon Lists

You can use wildcards in URL category excepon lists to easily configure a single entry to match to
mulple website subdomains and pages, without having to specify exact subdomains and pages.
Follow these guidelines when creang wildcard entries:
URL Filtering
• The following characters are considered token separators: . / ? & = ; +

Every string separated by one or two of these characters is a token. Use wildcard characters as
token placeholders, indicang that a specific token can contain any value.
• In place of a token, use either an asterisk (*) or a caret (^) to indicate a wildcard value.
• Wildcard characters must be the only character within a token. For example, www.gmail*.com
would be invalid because the asterisk follows other characters. An entry can contain mulple
wildcards, however.
How to Use Asterisk (*) and Caret (^) Wildcards
* Use to indicate one or more variable

subdomains. If you use *, the entry will match
any addional subdomains, whether at the
beginning or the end of the URL.
Ex:
• *.paloaltonetworks.com matches
www.paloaltonetworks.com and
www.paloaltonetworks.com.uk.
• *.paloaltonetworks.com/ matches
www.paloaltonetworks.com but not
www.paloaltonetworks.com.uk.
^ Use to indicate one variable subdomain.

Ex:
mail.^.com matches to mail.company.com but
not mail.company.sso.com.
Do not create an entry with consecuve asterisk (*) wildcards or more than nine
consecuve caret (^) wildcards—entries like these can affect firewall performance.
For example, do not add an entry like mail.*.*.com; instead, depending on the range
of websites you want to control access to, enter mail.*.com or mail.^.^.com. An
entry like mail.*.com matches to a greater number of sites than mail.^.^.com;
mail.*.com matches to sites with any number of subdomains and mail.^.^.com
matches to sites with exactly two subdomains.
URL Category Excepon List—Wildcard Examples

The following table displays example URL list entries using wildcards and sites matching these
entries.
URL Excepon List Entry Matching Sites
Example Set 1
URL Filtering
URL Excepon List Entry Matching Sites
*.company.com eng.tools.company.com
support.tools.company.com
tools.company.com
docs.company.com
^.company.com tools.company.com
docs.company.com
^.^.company.com eng.tools.company.com
Example Set 2
mail.google.* mail.google.com
mail.google.co.uk
mail.google.example.org
mail.google.^ mail.google.com
mail.google.info
mail.google.^.^ mail.google.co.uk
mail.google.example.info
Example Set 3
site.*.com site.yourname.com
site.abc.xyz.com
site.^.com site.company.com
site.example.com
site.^.^.com site.a.b.com
site.com/* site.com/photos
site.com/blog/latest
any site.com subdirectory
URL Filtering
Use an External Dynamic List in a URL Filtering Profile

To protect your network from newly-discovered threats and malware, you can use external
dynamic lists in URL Filtering profiles. External dynamic lists give you the ability to update the list
without a configuraon change or commit on the firewall. An external dynamic list is a text file
that is hosted on an external web server. You can use this list to import URLs and enforce policy
on these URLs. When the list is updated on the web server, the firewall retrieves the changes and
applies policy to the modified list without requiring a commit on the firewall.
The firewall dynamically imports the list at the configured interval and enforces policy for the
URLs (IP addresses or domains are ignored) in the list. For URL formang guidelines, see URL
Category Excepons.
For more informaon, see External Dynamic List.
STEP 1 | Configure the firewall to access an external dynamic list.
• Ensure that the list does not include IP addresses or domain names; the firewall skips non-
URL entries.
• Use the custom URL list guidelines to verify the list’s formang.
• Select URL List from the Type drop-down.
STEP 2 | Use the external dynamic list in a URL Filtering profile.

2. Add or modify an exisng URL Filtering profile.
3. Name the profile and, in the Categories tab, select the external dynamic list from the
Category list.
4. Click Acon to select a more granular acon for the URLs in the external dynamic list.
If a URL that is included in an external dynamic list is also included in a custom

URL category, or block and allow list, the acon specified in the custom
category or the block and allow list will take precedence over the external
dynamic list.
5. Click OK.
6. Aach the URL Filtering profile to a Security policy rule.
2. Select the Acons tab and, in the Profile Seng secon, select the new profile in the
URL Filtering drop-down.
URL Filtering

1. View the external dynamic list entries and try to access a URL from the list.
2. Verify that the acon you defined is enforced in the browser.
1. Select ACC and add a URL Domain as a global filter to view the Network Acvity and
Blocked Acvity for the URL you accessed.
2. Select Monitor > Logs > URL Filtering to access the detailed log view.
STEP 4 | Verify whether entries in the external dynamic list were ignored or skipped.
In a list of type URL, the firewall skips non-URL entries as invalid and ignores entries that
exceed the maximum limit for the firewall model.
To check whether you have reached the limit for an external dynamic list type, select
Objects > External Dynamic Lists and click List Capacies.
Use the following CLI command on a firewall to review the details for a list.
request system external-list show type url name <list_name>
For example:
request system external-list show type url name My_URL_List

vsys5/My_URL_List:
Next update at: Tue Jan 3 14:00:00 2017
Source: http://example.com/My_URL_List.txt
Referenced: Yes
Valid: Yes
Auth-Valid: Yes
Total valid entries: 3

Total invalid entries: 0
Valid urls:
www.URL1.com
www.URL2.com
www.URL3.com
URL Filtering
Allow Password Access to Certain Sites

In some cases, there may be URL categories that you want to block but allow certain individuals
to access on occasion. In this case, you would set the category acon to override and define a
URL admin override password in the firewall Content-ID configuraon. Users will be required to
provide the override password before they can access sites in these categories. Use the following
procedure to configure URL admin override:
STEP 1 | Set the URL admin override password.
1. Select Device > Setup > Content ID.
2. In the URL Admin Override secon, click Add.
3. In the Locaon field, select the virtual system to which this password applies.
4. Enter the Password and Confirm Password.
5. Select an SSL/TLS Service Profile. The profile specifies the cerficate that the firewall
presents to the user if the site with the override is an HTTPS site. For details, see
Configure an SSL/TLS Service Profile.
6. Select the Mode for prompng the user for the password:
• Transparent—The firewall intercepts the browser traffic desned for site in a URL
category you have set to override and impersonates the original desnaon URL,
issuing an HTTP 302 to prompt for the password, which applies on a per-vsys level.
The client browser will display cerficate errors if it does not trust the
cerficate.
• Redirect—The firewall intercepts HTTP or HTTPS traffic to a URL category set to
override and redirects the request to a Layer 3 interface on the firewall using an HTTP
302 redirect in order to prompt for the override password. If you select this opon,
you must provide the Address (IP address or DNS hostname) to which to redirect the
traffic.
7. Click OK.
STEP 2 | (Oponal) Set a custom override period.

1. Edit the URL Filtering secon.
2. To change the amount of me users can browse to a site in a category for which they
have successfully entered the override password, enter a new value in the URL Admin
Override Timeout field. By default, users can access sites within the category for 15
minutes without re-entering the password.
3. To change the amount of me users are blocked from accessing a site set to override
aer three failed aempts to enter the override password, enter a new value in the URL
Admin Lockout Timeout field. By default, users are blocked for 30 minutes.
4. Click OK.
URL Filtering
STEP 3 | (Redirect mode only) Create a Layer 3 interface to which to redirect web requests to sites in a
category configured for override.
1. Create a management profile to enable the interface to display the URL Filtering
Connue and Override Page response page:
1. Select Network > Interface Mgmt and click Add.
2. Enter a Name for the profile, select Response Pages, and then click OK.
2. Create the Layer 3 interface. Be sure to aach the management profile you just created
(on the Advanced > Other Info tab of the Ethernet Interface dialog).
STEP 4 | (Redirect mode only) To transparently redirect users without displaying cerficate errors,
install a cerficate that matches the IP address of the interface to which you are redirecng
web requests to a site in a URL category configured for override.You can either generate a
self-signed cerficate or import a cerficate that is signed by an external CA.
To use a self-signed cerficate, you must first create a root CA cerficate and then use that CA
to sign the cerficate you will use for URL admin override as follows:
1. To create a root CA cerficate, select Device > Cerficate Management > Cerficates >
Device Cerficates and then click Generate. Enter a Cerficate Name, such as RootCA.
Do not select a value in the Signed By field (this is what indicates that it is self-signed).
Make sure you select the Cerficate Authority check box and then click Generate the
cerficate.
2. To create the cerficate to use for URL admin override, click Generate. Enter a
Cerficate Name and enter the DNS hostname or IP address of the interface as the
Common Name. In the Signed By field, select the CA you created in the previous step.
Add an IP address aribute and specify the IP address of the Layer 3 interface to which
you will be redirecng web requests to URL categories that have the override acon.
4. To configure clients to trust the cerficate, select the CA cerficate on the Device
Cerficates tab and click Export. You must then import the cerficate as a trusted root
CA into all client browsers, either by manually configuring the browser or by adding the
cerficate to the trusted roots in an Acve Directory Group Policy Object (GPO).
STEP 5 | Specify which URL categories require an override password to enable access.
1. Select Objects > URL Filtering and either select an exisng URL Filtering profile or Add a
new one.
2. On the Categories tab, set the Acon to override for each category that requires a
password.
3. Complete any remaining secons on the URL Filtering profile and then click OK to save
the profile.
STEP 6 | Apply the URL Filtering profile to the Security policy rule(s) that allows access to the sites
requiring password override for access.
1. Select Policies > Security and select the appropriate Security policy to modify it.
2. Select the Acons tab and in the Profile Seng secon, click the drop-down for URL
Filtering and select the profile.
URL Filtering

Click Commit.
URL Filtering
Prevent Credenal Phishing

Phishing sites are sites that aackers disguise as legimate websites with the intent to steal user
informaon, especially the credenals that provide access to your network. When a phishing
email enters a network, it takes just a single user to click the link and enter credenals to set a
breach into moon. You can detect and prevent in-progress phishing aacks, thereby prevenng
credenal the, by controlling sites to which users can submit corporate credenals based on the
site’s URL category. This allows you to block users from subming credenals to untrusted sites
while allowing credenal submissions to corporate and sanconed sites.
Credenal phishing prevenon works by scanning username and password submissions to
websites and comparing those submissions against valid corporate credenals. You can choose
what websites you want to either allow or block corporate credenal submissions to based on the
URL category of the website. When the firewall detects a user aempng to submit credenals to
a site in a category you have restricted, it either displays a block response page that prevents the
user from subming credenals or presents a connue page that warns users against subming
credenals to sites in certain URL categories but sll allows them to connue with the submission.
You can customize these block pages to educate users against reusing corporate credenals, even
on legimate, non-phishing sites.
To enable credenal phishing prevenon, you must configure both User-ID to detect when users
submit valid corporate credenals to a site (as opposed to personal credenals) and URL Filtering
to specify the URL categories in which you want to prevent users from entering their corporate
credenals. The following topics describe the different methods you can use to detect credenal
submissions and provide instrucons for configuring credenal phishing protecon.
• Methods to Check for Corporate Credenal Submissions
• Configure Credenal Detecon with the Windows-based User-ID Agent
• Set Up Credenal Phishing Prevenon
Methods to Check for Corporate Credenal Submissions

Before you set up credenal phishing prevenon, decide which method you want the firewall to
use to check if valid corporate credenals have been submied to a web page.
Method to User-ID How does this method detect corporate usernames

Check Submied Configuraon and/or passwords that users submit to websites?
Credenals Requirements
Group Mapping Group Mapping The firewall checks to determine if the username a
configuraon on user submits to a restricted site matches any valid
the firewall corporate username.
To do this, the firewall matches the submied
username to the list of usernames in its user-to-group
mapping table to detect when users submit corporate
usernames to sites in a restricted category.
This method only checks for corporate username
submissions based on LDAP group membership, which
URL Filtering

makes it simple to configure, but more prone to false
posives.
IP User Mapping IP address- The firewall checks to determine if the username a

to- username user submits to a restricted site maps to the IP address
mappings of the login username.
idenfied
To do this, the firewall matches the IP address of the
through User
login username and the username submied to a web
Mapping,
site to its IP address-to-user mapping table to detect
GlobalProtect, or
when users submit their corporate usernames to sites
Authencaon
in a restricted category.
Policy and
Authencaon Because this method matches the IP address of the
Portal. login username associated with the session against
the IP address-to-username mapping table, it is an
effecve method for detecng corporate username
submissions, but it does not detect corporate password
submission. If you want to detect corporate username
and password submission, you must use the Domain
Credenal Filter method.
Domain Windows The firewall checks to determine if the username

Credenal Filter User-ID agent and password a user submits match the same user’s
configured corporate username and password.
with the User-
To do this, the firewall must be able to match credenal
ID credenal
submissions to valid corporate usernames and
service add-on
passwords and verify that the username submied
- AND - maps to the IP address of the login username as
follows:
IP address-
to- username • To detect corporate usernames and passwords—
mappings The firewall retrieves a secure bit mask, called
idenfied a bloom filter, from a Windows User-ID agent
through User equipped with the User-ID credenal service add-
Mapping, on. This add-on service scans your directory for
GlobalProtect, or usernames and password hashes and deconstructs
Authencaon them into a secure bit mask (the bloom filter) and
Policy and delivers it to the Windows User-ID agent. The
Authencaon firewall retrieves the bloom filter from the Windows
Portal. User-ID agent at regular intervals. Whenever it
detects a user subming credenals to a restricted
category, it reconstructs the bloom filter and looks
for a matching username and password hash. The
firewall can only connect to one Windows User-ID
agent running the User-ID credenal service add-
on.
URL Filtering

• To verify that the credenals belong to the login
username—The firewall looks for a mapping
between the IP address of the login username
and the detected username in its IP address-to-
username mapping table.
To learn more how the domain credenal method
works and the requirements for enabling this type of
detecon, see Configure Credenal Detecon with the
Windows-based User-ID Agent.
Configure Credenal Detecon with the Windows User-ID Agent

Domain Credenal Filter detecon enables the firewall to detect passwords submied to web
pages. This credenal detecon method requires the Windows User-ID agent and the User-ID
credenal service, an add-on to the User-ID agent, to be installed on a read-only domain controller
(RODC).
The Domain Credenal Filter detecon method is supported with the Windows User-ID
agent only. You cannot use the PAN-OS integrated User-ID agent to configure this method
of credenal detecon.
An RODC is a Microso Windows server that maintains a read-only copy of an Acve Directory
database that a domain controller hosts. When the domain controller is located at a corporate
headquarters, for example, RODCs can be deployed in remote network locaons to provide local
authencaon services. Installing the User-ID agent on an RODC can be useful for a few reasons:
access to the domain controller directory is not required to enable credenal detecon and you
can support credenal detecon for a limited or targeted set of users. Because the directory the
RODC hosts is read-only, the directory contents remain secure on the domain controller.
Because you must install the Windows User-ID agent on the RODC for credenal
detecon, as a best pracce deploy a separate agent for this purpose. Do not use the User-
ID agent installed on the RODC to map IP addresses to users.
Aer you install the User-ID agent on an RODC, the User-ID credenal service runs in the
background and scans the directory for the usernames and password hashes of group members
that are listed in the RODC password replicaon policy (PRP)—you can define who you want to
be on this list. The User-ID credenal service then takes the collected usernames and password
hashes and deconstructs the data into a type of bit mask called a bloom filter. Bloom filters are
compact data structures that provide a secure method to check if an element (a username or
a password hash) is a member of a set of elements (the sets of credenals you have approved
for replicaon to the RODC). The User-ID credenal service forwards the bloom filter to the
Windows User-ID agent; the firewall retrieves the latest bloom filter from the User-ID agent at
regular intervals and uses it to detect usernames and password hash submissions. Depending
on your sengs, the firewall then blocks, alerts, or allows on valid password submissions to web
URL Filtering
pages, or displays a response page to users warning them of the dangers of phishing, but allowing
them to connue with the submission.
Throughout this process, the User-ID agent does not store or expose any password hashes, nor
does it forward password hashes to the firewall. Once the password hashes are deconstructed into
a bloom filter, there is no way to recover them.
STEP 1 | Configure user mapping using the Windows User-ID agent.
To enable credenal detecon, you must install the Windows User-ID agent on an
RODC. Refer to the Compability Matrix for a list of supported servers. Install a
separate User-ID agent for this purpose.
Important items to remember when seng up User-ID to enable Domain Credenal Filter
detecon:
• Because the effecveness of credenal phishing detecon is dependent on your RODC
setup, make sure that you also review best pracces and recommendaons for RODC
Administraon.
• Download User-ID soware updates:
• User-ID Agent Windows installer—UaInstall-x.x.x-x.msi.
• User-ID Agent Credenal Service Windows installer—UaCredInstall64-x.x.x-x.msi.
• Install the User-ID agent and the User Agent Credenal service on an RODC using an
account that has privileges to read Acve Directory via LDAP (the User-ID agent also
requires this privilege).
• The User-ID Agent Credenal Service requires permission to log on with the local system
account. For more informaon, refer to Create a Dedicated Service Account for the User-
ID Agent.
• The service account must be a member of the local administrator group on the RODC.
For more informaon, refer to the following link.
STEP 2 | Enable the User-ID agent and the User Agent Credenal service (which runs in the
background to scan permied credenals) to share informaon.
1. On the RODC server, launch the User-ID Agent.
2. Select Setup and edit the Setup secon.
3. Select the Credenals tab. This tab only displays if you have already installed the User-ID
Agent Credenal Service.
4. Select Import from User-ID Credenal Agent. This enables the User-ID agent to import
the bloom filter that the User-ID credenal agent creates to represent users and the
corresponding password hashes.
5. Click OK, Save your sengs, and Commit.
URL Filtering
STEP 3 | In the RODC directory, define the group of users for which you want to support credenal
submission detecon.
• Confirm that the groups that should receive credenal submission enforcement are added
to the Allowed RODC Password Replicaon Group.
• Check that none of the groups in the Allowed RODC Password Replicaon Group are also in
the Denied RODC Password Replicaon Group by default. Groups listed in both will not be
subject to credenal phishing enforcement.
STEP 4 | Connue to the next task.

Set up credenal phishing prevenon on the firewall.
Set Up Credenal Phishing Prevenon

Aer you have decided which of the methods to detect corporate credenal submissions you
want to use, take the following steps to enable the firewall to detect when users submit corporate
credenals to web pages and either alert on this acon, block the credenal submission, or require
users to acknowledge the dangers of phishing before connuing with the submission.
Before enabling credenal phishing prevenon, verify that the Primary Username that
you configure on the firewall uses the sAMAccountName aribute. Credenal phishing
prevenon does not support alternate aributes.
STEP 1 | If you have not done so already, enable User-ID.

Each of the methods to check for corporate credenal submissions requires a different User-ID
configuraon:
• If you plan to use the group mapping method, which detects whether a user is subming a
valid corporate username, map users to groups.
• If you plan to use the IP user mapping method, which detects whether a user is subming
a valid corporate username and that username is the same as the login username, map IP
addresses to users.
• If you plan to use the domain credenal filter method, which detects whether a user is
subming a valid username and password and that those credenals belong to the logged-
in user, configure credenal detecon with the Windows-based User-ID agent and map IP
addresses to users.
STEP 2 | If you have not done so already, configure a best pracce URL Filtering profile to ensure
protecon against URLs that have been observed hosng malware or exploive content.
1. Select Objects > Security Profiles > URL Filtering and Add or modify a URL Filtering
profile.
2. Block access to all known dangerous URL categories: malware, phishing, dynamic-dns,
unknown, command-and-control, extremism, copyright-infringement, proxy-avoidance-
and-anonymizers, newly-registered-domain, grayware, and parked.
STEP 3 | Add a Decrypon policy rule to decrypt the traffic you want to monitor for user credenal
submissions.
URL Filtering
STEP 4 | Configure the URL Filtering profile to detect corporate credenal submissions to websites
that are in allowed URL categories.
The firewall does not check credenal submissions for trusted sites, even if you enable
the checks for the URL categories for these sites, to provide best performance. The
trusted sites represent sites where Palo Alto Networks has not observed any malicious
or phishing aacks. Updates for this trusted sites list are delivered through Applicaon
and Threat content updates. For a list of App-IDs that are exempt from credenal
detecon, see Trusted App-IDs That Skip Credenal Submission Detecon on
live.paloaltonetworks.com.
1. Select User Credenal Detecon.

2. Select one of the user credenal detecon methods to web pages from the User
Credenal Detecon drop-down:
Confirm that the format for the primary username is the same as the username
format that the User-ID source provides.
• Use IP User Mapping—Checks for valid corporate username submissions and verifies
that the login username maps to the source IP address of the session. To do this, the
firewall matches the submied username and source IP address of the session against
its IP-address-to-username mapping table. To use this method you can use any of the
user mapping methods described in map IP addresses to users.
• Use Domain Credenal Filter—Checks for valid corporate usernames and password
submissions and verifies that the username maps to the IP address of the logged in
user. See Configure Credenal Detecon with the Windows-based User-ID Agent for
instrucons on how to set up User-ID to enable this method.
• Use Group Mapping—Checks for valid username submissions based on the user-
to-group mapping table populated when you configure the firewall to map users to
groups.
With group mapping, you can apply credenal detecon to any part of the directory,
or for specific groups that have access to your most sensive applicaons, such as IT.
This method is prone to false posives in environments that do not have

uniquely structured usernames. Because of this, you should only use this method
to protect your high-value user accounts.
3. Set the Valid Username Detected Log Severity the firewall uses to log detecon of
corporate credenal submissions. By default, the firewall logs these events as medium
severity.
URL Filtering
STEP 5 | Block (or alert) on credenal submissions to allowed sites.

1. Select Categories.
2. For each Category to which Site Access is allowed, select how you want to treat User
Credenal Submissions:
• alert—Allow users to submit credenals to the website, but generate a URL Filtering
log each me a user submits credenals to sites in this URL category.
• allow—(default) Allow users to submit credenals to the website.
• block—Block users from subming credenals to the website. When a user tries to
submit credenals, the firewall displays the An-Phishing Block Page, prevenng the
credenal submission.
• connue—Present the An-Phishing Connue Page response page to users when
they aempt to submit credenals. Users must select Connue on the response page
to connue with the submission.
3. Select OK to save the URL Filtering profile.
STEP 6 | Apply the URL Filtering profile with the credenal detecon sengs to your Security policy
rules.
1. Select Policies > Security and Add or modify a Security policy rule.
2. On the Acons tab, set the Profile Type to Profiles.
3. Select the new or updated URL Filtering profile to aach it to the Security policy rule.
4. Select OK to save the Security policy rule.
STEP 8 | Monitor credenal submissions the firewall detects.
Select ACC > Hosts Vising Malicious URLs to see the number of users who have
visited malware and phishing sites.
Select Monitor > Logs > URL Filtering.

The new Credenal Detected column indicates events where the firewall detected a HTTP
post request that included a valid credenal:
To display this column, hover over any column header and click the arrow to select the columns
you’d like to display.
Log entry details also indicate credenal submissions:
STEP 9 | Validate and troubleshoot credenal submission detecon.

• Use the following CLI command to view credenal detecon stascs:
> show user credential-filter statistics
The output for this command varies depending on the method configured for the firewall
to detect credenal submissions. For example, if the Domain Credenal Filter method is
URL Filtering
configured in any URL Filtering profile, a list of User-ID agents that have forwarded a bloom
filter to the firewall is displayed, along with the number of credenals contained in the bloom
filter.
• (Group Mapping method only) Use the following CLI command to view group mapping
informaon, including the number of URL Filtering profiles with Group Mapping credenal
detecon enabled and the usernames of group members that have aempted to submit
credenals to a restricted site.
> show user group-mapping statistics
• (Domain Credenal Filter method only) Use the following CLI command to see all Windows-
based User-ID agents that are sending mappings to the firewall:
> show user user-id-agent state all
The command output now displays bloom filter counts that include the number of bloom
filter updates the firewall has received from each agent, if any bloom filter updates failed to
process, and how many seconds have passed since the last bloom filter update.
• (Domain Credenal Filter method only) The Windows-based User-ID agent displays log
messages that reference BF (bloom filter) pushes to the firewall. In the User-ID agent
interface, select Monitoring > Logs.
URL Filtering
Safe Search Enforcement

Many search engines have a safe search seng that filters out adult images and videos in search
query return traffic. You can enable the firewall to block search results if the end user is not using
the strictest safe search sengs, and you can also transparently enable safe search for your users.
The firewall supports safe search enforcement for the following search providers: Google, Yahoo,
Bing, Yandex, and YouTube. Consider that safe search is a best-effort seng and service providers
do not guarantee that it works with every website, and search providers classify sites as safe or
unsafe (not Palo Alto Networks).
To use this feature you must enable the Safe Search Enforcement opon in a URL Filtering profile
and aach it to a Security policy rule. The firewall then blocks any matching search query return
traffic that is not using the strictest safe search sengs. There are two methods to enforce safe
search:
• Block Search Results when Strict Safe Search is not Enabled—When an end user aempts to
perform a search without first enabling the strictest safe search sengs, the firewall blocks
the search query results and displays the URL Filtering Safe Search Block Page. By default, this
page will provide a URL to the search provider sengs for configuring safe search.
• Transparently Enable Safe Search for Users—When an end user aempts to perform a search
without first enabling the strict safe search sengs, the firewall blocks the search results
with an HTTP 503 status code and redirects the search query to a URL that includes the safe
search parameters. You enable this funconality by imporng a new URL Filtering Safe Search
Block Page containing the JavaScript for rewring the search URL to include the strict safe
search parameters. In this configuraon, users will not see the block page, but will instead be
automacally redirected to a search query that enforces the strictest safe search opons. This
safe search enforcement method is supported for Google, Yahoo, and Bing searches.
As safe search sengs differ by search provider, get started by reviewing the different safe search
implementaons. Then, enforce safe search in one of two ways: block search results when safe
search is disabled, or transparently enable safe search for your users.
• Safe Search Sengs for Search Providers
• Block Search Results when Strict Safe Search is not Enabled
• Transparently Enable Safe Search for Users
Safe Search Sengs for Search Providers

Safe search sengs differ for each search provider—review the following sengs to learn more.
Search Provider Safe Search Seng Descripon
Google/YouTube Offers safe search on individual computers or network-

wide through Google’s safe search virtual IP address:
Safe Search Enforcement for Google Searches on
Individual Computers
In the Google Search Sengs, the Filter explicit
results seng enables safe search funconality. When
URL Filtering

enabled, the seng is stored in a browser cookie
as FF= and passed to the server each me the user
performs a Google search.
Appending safe=active to a Google search query
URL also enables the strictest safe search sengs.
Safe Search Enforcement for Google and YouTube
Searches using a Virtual IP Address
Google provides servers thatLock SafeSearch
(forcesafesearch.google.com) sengs in every
Google and YouTube search. By adding a DNS entry
for www.google.com and www.youtube.com
(and other relevant Google and YouTube country
subdomains) that includes a CNAME record poinng
to forcesafesearch.google.com to your DNS
server configuraon, you can ensure that all users
on your network are using strict safe search sengs
every me they perform a Google or YouTube search.
Keep in mind, however, that this soluon is not
compable with Safe Search Enforcement on the
firewall. Therefore, if you are using this opon to
force safe search on Google, the best pracce is to
block access to other search engines on the firewall by
creang custom URL categories and adding them to
the block list in the URL Filtering profile.
URL Filtering

• PAN-OS supports safe search
enforcement for YouTube through HTTP
header inseron. HTTP header inseron
is not currently supported for HTTP/2.
To enforce safe search for YouTube,
App-ID and HTTP/2 Inspecon
downgrade HTTP/2 connecons to
HTTP/1.1 using the Strip ALPN feature
in the appropriate decrypon profile.
• If you plan to use the Google Lock
SafeSearch soluon, consider
configuring DNS Proxy (Network >
DNS Proxy) and seng the inheritance
source as the Layer 3 interface on
which the firewall receives DNS sengs
from service provider via DHCP. You
would configure the DNS proxy with
Stac Entries for www.google.com
and www.youtube.com, using
the local IP address for the
forcesafesearch.google.com server.
Yahoo Offers safe search on individual computers only. The

Yahoo Search Preferences includes three SafeSearch
sengs: Strict, Moderate, or Off. When enabled, the
seng is stored in a browser cookie as vm= and passed
to the server each me the user performs a Yahoo
search.
Appending vm=r to a Yahoo search query URL also
enables the strictest safe search sengs.
When performing a search on Yahoo Japan

(yahoo.co.jp) while logged into a Yahoo
account, end users must also enable the
SafeSearch Lock opon.
Bing Offers safe search on individual computers or through

their Bing in the Classroom program. The Bing Sengs
include three SafeSearch sengs: Strict, Moderate, or
Off. When enabled, the seng is stored in a browser
cookie as adtl= and passed to the server each me
the user performs a Bing search.
Appending adlt=strict to a Bing search query URL
also enables the strictest safe search sengs.
URL Filtering

The Bing SSL search engine does not enforce the safe
search URL parameters and you should therefore
consider blocking Bing over SSL for full safe search
enforcement.
Block Search Results when Strict Safe Search is not Enabled

By default, if you enable safe search enforcement, when a user performs a search without using
the strictest safe search sengs, the firewall will block the search results and display a URL
Filtering Safe Search Block Page. This page provides a link to the search sengs page for the
corresponding search provider so that the end user can enable the safe search sengs. If you plan
to use this default method for enforcing safe search, you should communicate the policy to your
end users before deploying it. For details on how each search provider implements safe search,
see Safe Search Sengs for Search Providers. Oponally, you can customize the URL Filtering
response pages.
Alternavely, you can transparently enable safe search for users so they won’t have to manually
configure the sengs.
STEP 1 | Enable Safe Search Enforcement in the URL Filtering profile.
2. Select an exisng profile to modify, or clone the default profile to create a new profile.
3. On the Sengs tab, select the Safe Search Enforcement check box to enable it.
4. (Oponal) Restrict users to specific search engines:
1. On the Categories tab, set the search-engines category to block.
2. For each search engine that you want end users to be able to access, enter the web
address in the Allow List text box. For example, to allow users access to Google and
Bing searches only, you would enter the following:
www.google.com
www.bing.com
5. Configure other sengs as necessary to:
• Define site access for each URL category.
• Define Block and Allow Lists to specify websites that should always be blocked or
STEP 2 | Add the URL Filtering profile to the Security policy rule that allows traffic from clients in the
trust zone to the Internet.
1. Select Policies > Security and select a rule to which to apply the URL Filtering profile
that you just enabled for Safe Search Enforcement.
2. On the Acons tab, select the URL Filtering profile.
3. Click OK to save the Security policy rule.
URL Filtering
STEP 3 | Enable SSL Forward Proxy decrypon.

Because most search engines encrypt their search results, you must enable SSL Forward
Proxy decrypon so that the firewall can inspect the search traffic and detect the safe search
sengs.
1. Add a custom URL category for the search sites:
1. Select Objects > Custom Objects > URL Category and Add a custom category.
2. Enter a Name for the category, such as SearchEngineDecrypon.
3. Add the following to the Sites list:
www.bing.*
www.google.*
search.yahoo.*
4. Click OK to save the custom URL category object.
2. Follow the steps to configure SSL Forward Proxy.
3. On the Service/URL Category tab in the Decrypon policy rule, Add the custom URL
category you just created and then click OK.
URL Filtering
STEP 4 | (Recommended) Block Bing search traffic running over SSL.

Because the Bing SSL search engine does not adhere to the safe search sengs, for full safe
search enforcement, you must deny all Bing sessions that run over SSL.
1. Add a custom URL category for Bing:
2. Enter a Name for the category, such as EnableBingSafeSearch.
www.bing.com/images/*
www.bing.com/videos/*
2. Create another URL Filtering profile to block the custom category you just created:
2. Add a new profile and give it a descripve Name.
3. Locate the custom category in the Category list and set it to block.
4. Click OK to save the URL Filtering profile.
3. Add a Security policy rule to block Bing SSL traffic:
1. Select Policies > Security and Add a policy rule that allows traffic from your trust zone
to the Internet.
2. On the Acons tab, aach the URL Filtering profile you just created to block the
custom Bing category.
3. On the Service/URL Category tab Add a New Service and give it a descripve Name,
such as bingssl.
4. Select TCP as the Protocol and set the Desnaon Port to 443.
6. Use the Move opons to ensure that this rule is below the rule that has the URL
Filtering profile with safe search enforcement enabled.

Click Commit.
URL Filtering
STEP 6 | Verify the Safe Search Enforcement configuraon.

This verificaon step only works if you are using block pages to enforce safe search. If you are
using transparent safe search enforcement, the firewall block page will invoke a URL rewrite
with the safe search parameters in the query string.
1. From a computer that is behind the firewall, disable the strict search sengs for one of
the supported search providers. For example, on bing.com, click the Preferences icon on
the Bing menu bar.
2. Set the SafeSearch opon to Moderate or Off and click Save.

3. Perform a Bing search and verify that the URL Filtering Safe Search Block page displays
instead of the search results:
4. Use the link in the block page to go to the search sengs for the search provider and set
the safe search seng back to the strictest seng (Strict in the case of Bing) and then
click Save.
5. Perform a search again from Bing and verify that the filtered search results display
instead of the block page.
Transparently Enable Safe Search for Users

If you want to enforce filtering of search query results with the strictest safe search filters, but you
don’t want your end users to have to manually configure the sengs, you can enable transparent
safe search enforcement as follows. This funconality is supported on Google, Yahoo, and Bing
search engines only and requires Content Release version 475 or later.
STEP 1 | Make sure the firewall is running Content Release version 475 or later.
2. Check the Applicaons and Threats secon to determine what update is currently
running.
3. If the firewall is not running the required update or later, click Check Now to retrieve a
list of available updates.
4. Locate the required update and click Download.
5. Aer the download completes, click Install.
URL Filtering
STEP 2 | Enable Safe Search Enforcement in the URL Filtering profile.

2. Select an exisng profile to modify, or clone the default profile to create a new one.
3. On the Sengs tab, select the Safe Search Enforcement check box to enable it.
4. (Oponal) Allow access to specific search engines only:
1. On the Categories tab, set the search-engines category to block.
2. For each search engine that you want end users to be able to access, enter the web
address in the Allow List text box. For example, to allow users access to Google and
Bing searches only, you would enter the following:
www.google.com
www.bing.com
5. Configure other sengs as necessary to:
• Define site access for each URL category.
• Define block and allow lists to specify websites that should always be blocked or
STEP 3 | Add the URL Filtering profile to the Security policy rule that allows traffic from clients in the
trust zone to the Internet.
1. Select Policies > Security and select a rule to which to apply the URL Filtering profile
that you just enabled for Safe Search Enforcement.
2. On the Acons tab, select the URL Filtering profile.
3. Click OK to save the Security policy rule.
URL Filtering
STEP 4 | (Recommended) Block Bing search traffic running over SSL.

Because the Bing SSL search engine does not adhere to the safe search sengs, for full safe
search enforcement, you must deny all Bing sessions that run over SSL.
1. Add a custom URL category for Bing:
2. Enter a Name for the category, such as EnableBingSafeSearch.
www.bing.com/images/*
www.bing.com/videos/*
2. Create another URL Filtering profile to block the custom category you just created:
2. Add a new profile and give it a descripve Name.
3. Locate the custom category you just created in the Category list and set it to block.
4. Click OK to save the URL Filtering profile.
3. Add a Security policy rule to block Bing SSL traffic:
1. Select Policies > Security and Add a policy rule that allows traffic from your trust zone
to the Internet.
2. On the Acons tab, aach the URL Filtering profile you just created to block the
custom Bing category.
3. On the Service/URL Category tab Add a New Service and give it a descripve Name,
such as bingssl.
4. Select TCP as the Protocol, set the Desnaon Port to 443.
6. Use the Move opons to ensure that this rule is below the rule that has the URL
Filtering profile with safe search enforcement enabled.
STEP 5 | Edit the URL Filtering Safe Search Block Page, replacing the exisng code with the JavaScript
for rewring search query URLs to enforce safe search transparently.
1. Select Device > Response Pages > URL Filtering Safe Search Block Page.
2. Select Predefined and then click Export to save the file locally.
3. Use an HTML editor and replace all of the exisng block page text with the following
text and then save the file.
<html>
<head>
<title>Search Blocked</title>
<meta http-equiv="Content-Type" content="text/html;
charset=utf-8">
<meta http-equiv="pragma" content="no-cache">
<meta name="viewport" content="initial-scale=1.0">
<style>
#content {
URL Filtering
border:3px solid#aaa;
background-color:#fff;
margin:1.5em;
padding:1.5em;
font-family:Tahoma,Helvetica,Arial,sans-serif;
font-size:1em;
}
h1 {
font-size:1.3em;
font-weight:bold;
color:#196390;
}
b {
font-weight:normal;
color:#196390;
}
</style>
</head>
<body bgcolor="#e7e8e9">
<div id="content">
<h1>Search Blocked</h1>
<p>
<b>User:</b>
<user/>
</p>
<p>Your search results have been blocked because your
search settings are not in accordance with company policy.
In order to continue, please update your search settings so
that Safe Search is set to the strictest setting. If you are
currently logged into your account, please also lock Safe
Search and try your search again.</p>
<p>
For more information, please refer to:
<a href="<ssurl/>">
<ssurl/>
</a>
</p>
<p id="java_off"> Please enable JavaScript in your
browser.<br></p>
<p><b>Please contact your system administrator if you
believe this message is in error.</b></p>
</div>
</body>
<script>
// Grab the URL that's in the browser.
var s_u = location.href;
//bing
// Matches the forward slashes in the beginning, anything,
then ".bing." then anything followed by a non greedy slash.
Hopefully the first forward slash.
var b_a = /^.*\/\/(.+\.bing\..+?)\//.exec(s_u);
if (b_a) {
s_u = s_u + "&adlt=strict";
window.location.replace(s_u);
document.getElementById("java_off").innerHTML = 'You
are being redirected to a safer search!';
URL Filtering
}
//google
then ".google." then anything followed by a non greedy slash.
var g_a = /^.*\/\/(.+\.google\..+?)\//.exec(s_u);
if (g_a) {
s_u = s_u.replace(/&safe=off/ig,"");
s_u = s_u + "&safe=active";
are being redirected to a safer search!'; }
//yahoo
then ".yahoo."" then anything followed by a non greedy slash.
var y_a = /^.*\/\/(.+\.yahoo\..+?)\//.exec(s_u);
if (y_a) {
s_u = s_u.replace(/&vm=p/ig,"");
s_u = s_u + "&vm=r";
are being redirected to a safer search!';
}
document.getElementById("java_off").innerHTML = ' ';
</script>
</html>
STEP 6 | Import the edited URL Filtering Safe Search Block page onto the firewall.
1. To import the edited block page, select Device > Response Pages > URL Filtering Safe
Search Block Page.
locate the file.
URL Filtering
STEP 7 | Enable SSL Forward Proxy decrypon.

Because most search engines encrypt their search results, you must enable SSL forward
proxy decrypon so that the firewall can inspect the search traffic and detect the safe search
sengs.
1. Add a custom URL category for the search sites:
2. Enter a Name for the category, such as SearchEngineDecrypon.
www.bing.*
www.google.*
search.yahoo.*
2. Follow the steps to configure SSL Forward Proxy.
3. On the Service/URL Category tab in the Decrypon policy rule, Add the custom URL
category you just created and then click OK.

Click Commit.
URL Filtering
URL Filtering Response Pages

The firewall provides three predefined response pages that display by default when a user
aempts to browse to a site in a category that is configured with one of the block acons in the
URL Filtering profile (block, connue, or override) or when Container Pages is enabled:
• URL Filtering and Category Match Block Page
Access blocked by a URL Filtering profile or because the URL category is blocked by a Security
policy rule.
• URL Filtering Connue and Override Page

Page with inial block policy that allows users to bypass the block by clicking Connue. With
URL Admin Override enabled (Allow Password Access to Certain Sites), aer clicking Connue,
the user must supply a password to override the policy that blocks the URL.
• URL Filtering Safe Search Block Page

Access blocked by a Security policy rule with a URL Filtering profile that has the Safe Search
Enforcement opon enabled (see Safe Search Enforcement). The user will see this page if a
URL Filtering
search is performed using Google, Bing, Yahoo, or Yandex and their browser or search engine
account seng for Safe Search is not set to strict.
• An Phishing Block Page

This page displays to users when they aempt to enter corporate credenals (usernames or
passwords) on a web page in a category for which credenal submissions are blocked. The user
can connue to access the site but remains unable to submit valid corporate credenals to any
associated web forms. To control the sites to which users can submit corporate credenals, the
firewall must be configured with User-ID and enabled to prevent credenal phishing based on
URL category.
• An Phishing Connue Page

This page warns users against subming credenals (usernames and passwords) to a web
site. Warning users against subming credenals can help to discourage them from reusing
corporate credenals and to educate them about possible phishing aempts. They must select
Connue to proceed to credenals on the site. To control the sites to which users can submit
corporate credenals, the firewall must be configured with User-ID and enabled to prevent
credenal phishing based on URL category.
URL Filtering
You can either use the predefined pages, or you can customize the URL Filtering response pages
to communicate your specific acceptable use policies and/or corporate branding. In addion, you
can use the URL Filtering response page variables for substuon at the me of the block event
or add one of the supported response page references to external images, sounds, or style sheets.
The browser will not display response pages if you have enabled your firewall to inspect
SSL/TLS handshakes.
Table 2: URL Filtering Response Page Variables
Variable Usage
<user/> The firewall replaces the variable with the username (if available via
User-ID) or IP address of the user when displaying the response page.
<url/> The firewall replaces the variable with the requested URL when
displaying the response page.
<category/> The firewall replaces the variable with the URL filtering category of the
blocked request.
<pan_form/> HTML code for displaying the Connue buon on the URL Filtering
Connue and Override page.
You can also add code that triggers the firewall to display different messages depending on what
URL category the user is aempng to access. For example, the following code snippet from
a response page specifies to display Message 1 if the URL category is games, Message 2 if the
category is travel, or Message 3 if the category is kids:
var cat = "<category/>";

switch(cat)
{
case 'games':
document.getElementById("warningText").innerHTML = "Message 1";
break;
case 'travel':
break;
case 'kids':
break;
}
Only a single HTML page can be loaded into each virtual system for each type of block page.
However, other resources such as images, sounds, and cascading style sheets (CSS files) can be
loaded from other servers at the me the response page is displayed in the browser. All references
must include a fully qualified URL.
URL Filtering
Table 3: Response Page References
Reference Type Example HTML Code
Image
<img src="http://virginiadot.org/images/Stop-Sign
-gif.gif">
Sound
<embed src="http://simplythebest.net/sounds/WAV/W
AV_files/ movie_WAV_files/ do_not_go.wav" volume=
"100" hidden="true" autostart="true">
Style Sheet
<link href="http://example.com/style.css" rel="st
ylesheet" type="text/css" />
Hyperlink
<a href="http://en.wikipedia.org/wiki/Acceptable_
use_policy">View Corporate
Policy</a>
URL Filtering
Customize the URL Filtering Response Pages

The firewall provides predefined URL Filtering response pages that display by default when:
• A user aempts to browse to a site in a category with restricted access.
• A user submits valid corporate credenals to a site for which credenal detecon is enabled
(Prevent Credenal Phishing based on URL category).
• Log Only the Page a User Visits blocks a search aempt.
However, you can create your own custom response pages with your corporate branding,
acceptable use policies, and links to your internal resources.
Custom response pages larger than the maximum supported size are not decrypted or
displayed to users. In PAN-OS 8.1.2 and earlier PAN-OS 8.1 releases, custom response
pages on a decrypted site cannot exceed 8,191 bytes; the maximum size is increased to
17,999 bytes in PAN-OS 8.1.3 and later releases.
STEP 1 | Export the default response page(s).

2. Select the link for the URL Filtering response page you want to modify.
3. Click the response page (predefined or shared) and then click the Export link and save
the file to your desktop.
STEP 2 | Edit the exported page.

1. Using the HTML text editor of your choice, edit the page:
• If you want the response page to display custom informaon about the specific user,
URL, or category that was blocked, add one or more of the supported response page
variables.
• If you want to include custom images (such as your corporate logo), a sound, or style
sheet, or link to another URL, for example to a document detailing your acceptable
web use policy, include one or more of the supported response page references.
2. Save the edited page with a new filename. Make sure that the page retains its UTF-8
encoding. For example, in Notepad you would select UTF-8 from the Encoding drop-
down in the Save As dialog.
STEP 3 | Import the customized response page.

2. Select the link that corresponds to the URL Filtering response page you edited.
locate the file.
URL Filtering
STEP 4 | Save the new response page(s).

Commit the changes.
STEP 5 | Verify that the new response page displays.

From a browser, go to the URL that will trigger the response page. For example, to see a
modified URL Filtering and Category Match response page, browse to URL that your URL
Filtering policy is set to block.
The firewall uses the following ports to display the URL Filtering response pages:
• HTTP—6080
• Default TLS with firewall cerficate—6081
• Custom SSL/TLS profile—6082
URL Filtering
HTTP Header Logging

URL filtering provides visibility and control over web traffic on your network. For improved
visibility into web content, you can configure the URL Filtering profile to log HTTP header
aributes included in a web request. When a client requests a web page, the HTTP header
includes the user agent, referer, and x-forwarded-for fields as aribute-value pairs and forwards
them to the web server. When enabled for logging HTTP headers, the firewall logs the following
aribute-value pairs in the URL Filtering logs.
You can also use HTTP headers to manage access to SaaS applicaons. You don’t need a
URL Filtering license to do this, but you must use a URL Filtering profile to turn this feature
on.
Aribute Descripon
User-Agent The web browser that the user used to access the URL, for
example, Internet Explorer. This informaon is sent in the
HTTP request to the server.
Referer The URL of the web page that linked the user to another web
page; it is the source that redirected (referred) the user to the
web page that is being requested.
X-Forwarded-For (XFF) The opon in the HTTP request header field that preserves
the IP address of the user who requested the web page. If you
have a proxy server on your network, the XFF allows you to
idenfy the IP address of the user who requested the content,
instead of only recording the proxy server’s IP address as
source IP address that requested the web page.
Headers Inserted The type of header and the text of the header that the firewall
inserts.
URL Filtering
Request to Change the Category for a URL

If you think that a URL is not categorized accurately, you can request for us to categorize it
differently. Submit a change request directly in the firewall, or use Test A Site. A change request
triggers PAN-DB—the URL Filtering cloud—to do an immediate analysis of the URL for which
you’re suggesng a category change. If PAN-DB validates that the new category suggeson is
accurate, the change request is approved. If PAN-DB does not find the new category suggeson
to be accurate, the change request is then reviewed by human editors from the Palo Alto
Networks threat research and data science teams.
Aer you’ve submied a change request, you’ll receive an email from us confirming that we’ve
received your request. When we’ve completed our invesgaon, you’ll receive a second email
confirming the results.
You cannot request to change the risk category a URL receives (high risk, medium risk, or low
risk), or for URLs categorized as insufficient content or newly-registered domains.
• Make a Change Request Online
• Make a Bulk Change Request
• Make a Change Request From the Firewall
Make a Change Request Online

Visit Palo Alto Networks URL Filtering Test A Site to make a change request online.
STEP 1 | Go to Test A Site.
You do not need to log in to submit a change request, though you will need to provide your
email as part of the change request form. If you decide not to log in, you’ll need to take a
CAPTCHA test to confirm that you’re a human being (log in to avoid the CAPTCHA test).
STEP 2 | Enter a URL to check its categories:
URL Filtering
STEP 3 | Review the URL categories, and if you don’t think that they’re accurate, select Request
Change.
STEP 4 | Connue to populate and submit the change request form.

Include at least one (and up to two) new category suggesons, and leave an (oponal)
comment to tell us more about your suggeson.
Make a Bulk Change Request

You can also use Test A Site to make a bulk change request, where you want to submit change
requests for mulple URLs at a single me.
STEP 1 | Go to Test A Site.
You don’t need to log in to make a change request; however, you’ll need to provide your email
as part of compleng the change request form. If you decide not to log in, you’ll need to take a
CAPTCHA test to confirm that you’re a human being (log in to avoid the CAPTCHA test).
URL Filtering
STEP 2 | Choose the opon to submit a bulk change request:
STEP 3 | Complete and submit the bulk change request form.
Make a Change Request from the Firewall

You can also submit a URL category change request directly from the firewall. In the URL Filtering
logs, the details for each log entry include an opon to Request Categorizaon Change (Monitor >
Logs > URL Filtering).
From here you can complete the request form, and submit it.
URL Filtering
URL Filtering
Troubleshoot URL Filtering

The following topics provide troubleshoong guidelines for diagnosing and resolving common URL
filtering problems.
• Problems Acvang Advanced URL Filtering
• PAN-DB Cloud Connecvity Issues
• URLs Classified as Not-Resolved
• Incorrect Categorizaon
Problems Acvang Advanced URL Filtering

Use the following workflow to troubleshoot Advanced URL Filtering acvaon issues.
STEP 1 | Access the PAN-OS CLI.
STEP 2 | Verify whether Advanced URL Filtering has been acvated by running the following
command:
show system setting url-database
If the response is paloaltonetworks, PAN-DB, the Palo Alto Networks URL filtering
database, is the acve vendor.
STEP 3 | Verify that the firewall has a valid Advanced URL Filtering license by running the following
command:
request license info
You should see the license entry Feature: Advanced URL Filtering. If the license is
not installed, you will need to obtain and install a license. See Configure URL Filtering.
STEP 4 | Check the PAN-DB cloud connecon status.
PAN-DB Cloud Connecvity Issues

To check connecvity between the firewall and the PAN-DB cloud:
show url-cloud status
If the cloud is accessible, the expected response is similar to the following:

PAN-DB URL Filtering
License : valid
Current cloud server :
serverlist.urlcloud.paloaltonetworks.com
Cloud connection : connected
Cloud mode : public
URL database version - device : 20200624.20296
URL Filtering
URL database version - cloud : 20200624.20296 ( last update time

2020/06/24 12:39:19 )
URL database status : good
URL protocol version - device : pan/2.0.0
URL protocol version - cloud : pan/2.0.0
Protocol compatibility status : compatible
If the cloud is not accessible, the expected response is similar to the following:

PAN-DB URL Filtering
License : valid
Cloud connection : not connected
URL database version - device : 0000.00.00.000
URL protocol version - device : pan/0.0.2
Use the following checklist to idenfy and resolve connecvity issues:

Does the PAN-DB URL Filtering license field shows as invalid? Obtain and install a valid PAN-
DB license.
Does the URL protocol version show as not compable? Upgrade PAN-OS to the latest version.
Can you ping the PAN-DB cloud server from the firewall? Run the following command to
check:
ping source <ip-address> host

serverlist.urlcloud.paloaltonetworks.com <
For example, if your management interface IP address is 10.1.1.5, run the following command:
ping source 10.1.1.5 host serverlist.urlcloud.paloaltonetworks.com
Is the firewall in an HA configuraon? Verify that the HA state of the firewalls is in the acve,
acve-primary, or acve-secondary state. Access to the PAN-DB cloud will be blocked if the
firewall is in a different state. Run the following command on each firewall in the pair to see the
state:
show high-availability state
If you sll have problems with connecvity between the firewall and the PAN-DB cloud, contact
Palo Alto Networks support.
URLs Classified as Not-Resolved

URLs are classified as Not-resolved when your connecon to the PAN-DB URL filtering cloud
service is disrupted, resulng in failed URL lookups. The cloud connecon status and URL
classificaon does not apply to expired subscripon licenses or unlicensed users.
Use the following workflow to troubleshoot why some or all of the URLs being idenfied by PAN-
DB are classified as Not-resolved:
URL Filtering
STEP 1 | Check the PAN-DB cloud connecon by running the following command:
The Cloud connecon: field should show connected. If you see anything other than
connected, any URL that do not exist in the management plane cache will be categorized as
not-resolved. To resolve this issue, see PAN-DB Cloud Connecvity Issues.
STEP 2 | If the cloud connecon status shows connected, check the current ulizaon of the
firewall. If firewall ulizaon is spiking, URL requests may be dropped (may not reach the
management plane), and will be categorized as not-resolved.
To view system resources, run the following command and view the %CPU and %MEM columns:
show system resources
You can also view system resources on the System Resources widget on the Dashboard in the
web interface.
STEP 3 | If the problem persists, contact Palo Alto Networks support.
Incorrect Categorizaon
Somemes you may come across a URL that you believe is categorized incorrectly. Use the
following workflow to determine the URL categorizaon for a site and request a category change,
if appropriate.
STEP 1 | Verify the category in the dataplane by running the following command:
show running url <URL>
For example, to view the category for the Palo Alto Networks website, run the following
command:
show running url paloaltonetworks.com
If the URL stored in the dataplane cache has the correct category (computer-and-internet-
info in this example), then the categorizaon is correct and no further acon is required. If the
category is not correct, connue to the next step.
URL Filtering
STEP 2 | Verify if the category in the management plane by running the command:
test url-info-host <URL>
For example:
test url-info-host paloaltonetworks.com
If the URL stored in the management plane cache has the correct category, remove the URL
from the dataplane cache by running the following command:
clear url-cache url <URL>
The next me the firewall requests the category for this URL, the request will be forwarded to
the management plane. This will resolve the issue and no further acon is required. If this does
not solve the issue, go to the next step to check the URL category on the cloud systems.
STEP 3 | Verify the category in the cloud by running the following command:
test url-info-cloud <URL>
STEP 4 | If the URL stored in the cloud has the correct category, remove the URL from the dataplane
and the management plane caches.
Run the following command to delete a URL from the dataplane cache:
clear url-cache url <URL>
Run the following command to delete a URL from the management plane cache:
delete url-database url <URL>
The next me the firewall queries for the category of the given URL, the request will be
forwarded to the management plane and then to the cloud. This should resolve the category
lookup issue. If problems persist, see the next step to submit a categorizaon change request.
STEP 5 | To submit a change request from the web interface, go to the URL log and select the log
entry for the URL you would like to have changed.
STEP 6 | Click the Request Categorizaon change link and follow instrucons. You can also request
a category change from the Palo Alto Networks Test A Site website by searching for the
URL and then clicking the Request Change icon. To view a list of all available categories
URL Filtering
with descripons of each category, refer to hps://urlfiltering.paloaltonetworks.com/

CategoryList.aspx.
If your change request is approved, you will receive an email noficaon. You then have two
opons to ensure that the URL category is updated on the firewall:
• Wait unl the URL in the cache expires and the next me the URL is accessed by a user, the
new categorizaon update will be put in the cache.
• Run the following command to force an update in the cache:
request url-filtering update url <URL>
URL Filtering
PAN-DB Private Cloud

The PAN-DB private cloud is an on-premises soluon for organizaons that restrict the usage of
cloud services. With this on-premises soluon, you can deploy one or more M-600 appliances
as PAN-DB servers within your network or data center. The firewalls query the PAN-DB private
cloud to perform URL lookups, instead of accessing the PAN-DB public cloud.
The process for performing URL lookups, in both the private and the public cloud is the same
for the firewalls on the network. By default, the firewall is configured to access the public PAN-
DB cloud. If you deploy a PAN-DB private cloud, you must configure the firewalls with a list of IP
addresses or FQDNs to access the server(s) in the private cloud.
Firewalls running PAN-OS 5.0 or later versions can communicate with the PAN-DB private
cloud.
When you set up the PAN-DB private cloud, you can either configure the M-600 appliance(s) to
have direct internet access or keep it completely offline. Because the M-600 appliance requires
database and content updates to perform URL lookups, if the appliance does not have an acve
internet connecon, you must manually download the updates to a server on your network and
then, import the updates using SCP into each M-600 appliance in the PAN-DB private cloud. In
addion, the appliances must be able to obtain the seed database and any other regular or crical
content updates for the firewalls that it services.
To authencate the firewalls that connect to the PAN-DB private cloud, a set of default server
cerficates are packaged with the appliance; you cannot import or use another server cerficate
for authencang the firewalls. If you change the hostname on the M-600 appliance, the
appliance automacally generates a new set of cerficates to authencate the firewalls.
• M-600 Appliance for PAN-DB Private Cloud
• Set Up the PAN-DB Private Cloud
M-600 Appliance for PAN-DB Private Cloud

To deploy a PAN-DB private cloud, you need one or more M-600 appliances. The M-600
appliance ships in Panorama mode, and to be deployed as PAN-DB private cloud you must set
it up to operate in PAN-URL-DB mode. In the PAN-URL-DB mode, the appliance provides URL
categorizaon services for enterprises that do not want to use the PAN-DB public cloud.
The M-600 appliance when deployed as a PAN-DB private cloud uses two ports- MGT (Eth0) and
Eth1; Eth2 is not available for use. The management port is used for administrave access to the
appliance and for obtaining the latest content updates from the PAN-DB public cloud or from a
server on your network. For communicaon between the PAN-DB private cloud and the firewalls
on the network, you can use the MGT port or Eth1.
The M-200 appliance cannot be deployed as a PAN-DB private cloud.
The M-600 appliance in PAN-URL-DB mode:

• Does not have a web interface, it only supports a command line interface (CLI).
• Cannot be managed by Panorama.
URL Filtering
• Cannot be deployed in a high availability pair.

• Does not require a URL Filtering license. The firewalls, must have a valid PAN-DB URL Filtering
license to connect with and query the PAN-DB private cloud.
• Ships with a set of default server cerficates that are used to authencate the firewalls that
connect to the PAN-DB private cloud. You cannot import or use another server cerficate for
authencang the firewalls. If you change the hostname on the M-600 appliance, the appliance
automacally generates a new set of cerficates to authencate the firewalls that it services.
• Can be reset to Panorama mode only. If you want to deploy the appliance as a Dedicated Log
Collector, switch to Panorama mode and then set it in Log Collector mode.
Table 4: Differences Between the PAN-DB Public Cloud and PAN-DB Private Cloud
Differences PAN-DB Public Cloud PAN-DB Private Cloud
Content and Content (regular and crical) updates Content updates and full URL
Database and full database updates are database updates are available once a
Updates published mulple mes during day during the work week.
the day. The PAN-DB public cloud
updates the URL categories malware
and phishing every five minutes. The
firewall checks for crical updates
whenever it queries the cloud
servers for URL lookups.
URL Submit URL categorizaon change Submit URL categorizaon change

Categorizaon requests using the following opons: requests only using the Palo Alto
Requests Networks Test A Site website.
• Palo Alto Networks Test A Site
website.
• URL Filtering profile setup page
on the firewall.
• URL Filtering log on the firewall.
Unresolved If the firewall cannot resolve a URL If the firewall cannot resolve a query,
URL Queries query, the request is sent to the the request is sent to the M-600
servers in the public cloud. appliance(s) in the PAN-DB private
cloud. If there is no match for the
URL, the PAN-DB private cloud sends
a category unknown response to the
firewall; the request is not sent to
the public cloud unless you have
configured the M-600 appliance to
access the PAN-DB public cloud.
If the M-600 appliance(s) that
constute your PAN-DB private cloud
is configured to be completely offline,
URL Filtering
Differences PAN-DB Public Cloud PAN-DB Private Cloud

it does not send any data or analycs
to the public cloud.
Set Up the PAN-DB Private Cloud

To deploy one or more M-600 appliances as a PAN-DB private cloud within your network or data
center, you must complete the following tasks:
• Configure the PAN-DB Private Cloud
• Configure the Firewalls to Access the PAN-DB Private Cloud
• Configure Authencaon with Custom Cerficates on the PAN-DB Private Cloud
Configure the PAN-DB Private Cloud
STEP 1 | Rack mount the M-600 appliance.

Refer to the M-600 Hardware Reference Guide for instrucons.
STEP 2 | Register the M-600 appliance.

For instrucons on registering the M-600 appliance, see Register the Firewall.
STEP 3 | Perform inial configuraon of the M-600 Appliance.
The M-600 appliance in PAN-DB mode uses two ports- MGT (Eth0) and Eth1; Eth2
is not used in PAN-DB mode. The management port is used for administrave access
to the appliance and for obtaining the latest content updates from the PAN-DB public
cloud. For communicaon between the appliance (PAN-DB server) and the firewalls on
the network, you can use the MGT port or Eth1.
1. Connect to the M-600 appliance in one of the following ways:

• Aach a serial cable from a computer to the Console port on the M-600 appliance
and connect using a terminal emulaon soware (9600-8-N-1).
• Aach an RJ-45 Ethernet cable from a computer to the MGT port on the M-600
appliance. From a browser, go to hps://192.168.1.1. Enabling access to this
URL Filtering
URL might require changing the IP address on the computer to an address in the
192.168.1.0 network (for example, 192.168.1.2).
2. When prompted, log in to the appliance. Log in using the default username and password
(admin/admin). The appliance will begin to inialize.
3. Configure network access sengs including the IP address for the MGT interface:
set deviceconfig system ip-address <server-IP>

netmask <netmask> default-gateway <gateway-IP> dns-setting
servers primary <DNS-IP>
where <server-IP> is the IP address you want to assign to the management interface of
the server, <netmask> is the subnet mask, <gateway-IP> is the IP address of the network
gateway, and <DNS-IP> is the IP address of the primary DNS server.
4. Configure network access sengs including the IP address for the Eth1 interface:
set deviceconfig system eth1 ip-address <server-IP>

netmask <netmask> default-gateway <gateway-IP> dns-setting
servers primary <DNS-IP>
where <server-IP> is the IP address you want to assign to the data interface of the server,
<netmask> is the subnet mask, <gateway-IP> is the IP address of the network gateway,
and <DNS-IP> is the IP address of the DNS server.
5. Save your changes to the PAN-DB server.
commit
STEP 4 | Switch to PAN-DB private cloud mode.

1. To switch to PAN-DB mode, use the CLI command:
request system system-mode pan-url-db
You can switch from Panorama mode to PAN-DB mode and back; and from
Panorama mode to Log Collector mode and back. Switching directly from
PAN-DB mode to Log Collector mode or vice versa is not supported. When
switching operaonal mode, a data reset is triggered. With the excepon of
management access sengs, all exisng configuraon and logs will be deleted on
restart.
2. Use the following command to verify that the mode is changed:
show pan-url-cloud-status
hostname: M-600
ip-address: 1.2.3.4
netmask: 255.255.255.0
default-gateway: 1.2.3.1
ipv6-address: unknown
ipv6-link-local-address: fe80:00/64
ipv6-default-gateway:
mac-address: 00:56:90:e7:f6:8e
URL Filtering
time: Mon Apr 27 13:43:59 2015

uptime: 10 days, 1:51:28
family: m
model: M-600
serial: 0073010000xxx
sw-version: 7.0.0
app-version: 492-2638
app-release-date: 2015/03/19 20:05:33
av-version: 0
av-release-date: unknown
wf-private-version: 0
wf-private-release-date: unknown
logdb-version: 7.0.9
platform-family: m
pan-url-db: 20150417-220
system-mode: Pan-URL-DB
operational-mode: normal
3. Use the following command to check the version of the cloud database on the appliance:
show pan-url-cloud-status
Cloud status: Up
URL database version: 20150417-220
URL Filtering
STEP 5 | Install content and database updates.
The appliance only stores the currently running version of the content and one earlier
version.
Pick one of the following methods of installing the content and database updates:
• If the PAN-DB server has direct Internet access use the following commands:
1. To check whether a new version is published use:
request pan-url-db upgrade check
2. To check the version that is currently installed on your server use:
request pan-url-db upgrade info
3. To download and install the latest version:
• request pan-url-db upgrade download latest
• request pan-url-db upgrade install <version latest | file>
4. To schedule the M-600 appliance to automacally check for updates:
set deviceconfig system update-schedule pan-url-db recurring

weekly action download-and-install day-of-week <day of week>
at <hr:min>
• If the PAN-DB server is offline, access the Palo Alto Networks Customer Support web site
to download and save the content updates to an SCP server on your network. You can then
import and install the updates using the following commands:
• scp import pan-url-db remote-port <port-number> from
username@host:path
• request pan-url-db upgrade install file <filename>
URL Filtering
STEP 6 | Set up administrave access to the PAN-DB private cloud.
The appliance has a default admin account. Any addional administrave users that
you create can either be superusers (with full access) or superusers with read-only
access.
PAN-DB private cloud does not support the use of RADIUS VSAs. If the VSAs used on
the firewall or Panorama are used for enabling access to the PAN-DB private cloud, an
authencaon failure will occur.
• To set up a local administrave user on the PAN-DB server:
1. configure
2. set mgt-config users <username> permissions role-based
<superreader | superuser> yes
3. set mgt-config users <username> password
4. Enter password:xxxxx
5. Confirm password:xxxxx
6. commit
• To set up an administrave user with RADIUS authencaon:
1. Create RADIUS server profile.
set shared server-profile radius <server_profile_name>

server <server_name> ip-address <ip_address> port <port_no>
secret <shared_password>
2. Create authencaon-profile.
set shared authentication-profile <auth_profile_name> user-

domain <domain_name_for_authentication> allow-list <all> method
radius server-profile <server_profile_name>
3. Aach the authencaon-profile to the user.
set mgt-config users <username> authentication-

profile <auth_profile_name>

commit
• To view the list of users:.
show mgt-config users

users {
admin {
phash fnRL/G5lXVMug;
permissions {
URL Filtering
role-based {
superuser yes;
}
}
}
admin_user_2 {
permissions {
role-based {
superreader yes;
}
}
authentication-profile RADIUS;
}
}
STEP 7 | Configure the firewalls to access the PAN-DB private cloud.
Configure the Firewalls to Access the PAN-DB Private Cloud

When using the PAN-DB public cloud, each firewall accesses the PAN-DB servers in the AWS
cloud to download the list of eligible servers to which it can connect for URL lookups. With
the PAN-DB private cloud, you must configure the firewalls with a (stac) list of your PAN-DB
private cloud servers that will be used for URL lookups. The list can contain up to 20 entries; IPv4
addresses, IPv6 addresses, and FQDNs are supported. Each entry on the list— IP address or FQDN
—must be assigned to the management port and/or eth1 of the PAN-DB server.
STEP 1 | From the PAN-OS CLI, add a list of stac PAN-DB private cloud servers used for URL
lookups.
• Use the following CLI command to add private PAN-DB server IP addresses:
> configure
# set deviceconfig setting pan-url-db cloud-static-list <IP

addresses>
Or, in the web interface for each firewall, select Device > Setup > Content-ID, edit the URL
Filtering secon and enter the PAN-DB Server IP address(es) or FQDN(s). The list must be
comma separated.
• To delete the entries for the private PAN-DB servers, use the following command:
# delete deviceconfig setting pan-url-db cloud-static-list <IP

addresses>
When you delete the list of private PAN-DB servers, a re-elecon process is triggered on
the firewall. The firewall first checks for the list of PAN-DB private cloud servers and when
it cannot find one, the firewall accesses the PAN-DB servers in the AWS cloud to download
the list of eligible servers to which it can connect.
STEP 2 | Enter # commit to save your changes.
URL Filtering
STEP 3 | To verify that the change is effecve, use the following CLI command on the firewall:
> show url-cloud status

Cloud status: Up
URL database version: 20150417-220
Configure Authencaon with Custom Cerficates on the PAN-DB Private Cloud

By default, a PAN-DB server uses predefined cerficates for mutual authencaon to establish
the SSL connecons used for management access and inter-device communicaon. However, you
can configure authencaon using custom cerficates instead. Custom cerficates allow you to
establish a unique chain of trust to ensure mutual authencaon between your PAN-DB server
and firewalls. In the case of a PAN-DB private cloud, the firewall acts as the client and the PAN-
DB server acts as the server.
STEP 1 | Obtain key pairs and cerficate authority (CA) cerficates for the PAN-DB server and
firewall.
STEP 2 | Import the CA cerficate to validate the cerficate on the firewall.

1. Log in to the CLI on the PAN-DB server and enter configuraon mode.
admin@M-600> configure
2. Use TFTP or SCP to import the CA cerficate.
admin@M-600# {tftp | scp} import certificate from <value>

file <value> remote-port <1-65535> source-ip <ip/netmask>
certificate-name <value> passphrase <value> format {pkcs12 |
pem}
STEP 3 | Use TFTP or SCP to import the key pair that contains the server cerficate and private key
for the PAN-DB M-600 appliance.
admin@M-600# {tftp | scp} import keypair from <value> file <value>

remote-port <1-65535> source-ip <ip/netmask> certificate-
name <value> passphrase <value> format {pkcs12 | pem}
URL Filtering
STEP 4 | Configure a cerficate profile that includes the root CA and intermediate CA. This cerficate
profile defines the device authencaon between the PAN-DB server and the firewall.
1. In the CLI of the PAN-DB server, enter configuraon mode.
2. Name the cerficate profile.
admin@M-600# set shared certificate-profile <name>
3. (Oponal) Set the user domain.
admin@M-600# set shared certificate-profile <name>

domain <value>
4. Configure the CA.
Default-ocsp-url and ocsp-verify-cert are oponal parameters.
admin@M-600# set shared certificate-profile <name> CA <name>

[default-ocsp-url <value>]

[ocsp-verify-cert <value>]
URL Filtering
STEP 5 | Configure an SSL/TLS profile for the PAN-DB M-600 appliance. This profile defines the
cerficate and protocol range that PAN-DB and client devices use for SSL/TLS services.
1. Idenfy the SSL/TLS profile.
admin@M-600# set shared ssl-tls-service-profile <name>
2. Select the cerficate.

certificate <value>
3. Define the SSL/TLS range.
PAN-OS 8.0 and later releases support TLS 1.2 and later TLS versions only. You
must set the max version to TLS 1.2 or max.

protocol-settings min-version {tls1-0 | tls1-1 | tls1-2

protocol-settings max-version {tls1-0 | tls1-1 | tls1-2 | max
STEP 6 | Configure secure server communicaon on PAN-DB.

1. Set the SSL/TLS profile. This SSL/TLS service profile applies to all SSL connecons
between PAN-DB and firewalls.
admin@M-600# set deviceconfig setting management secure-conn-

server ssl-tls-service-profile <ssltls-profile>
2. Set the cerficate profile.

server certificate-profile <certificate-profile>
3. Set the disconnect wait me in number of minutes that PAN-DB should wait before
breaking and reestablishing the connecon with its firewall (range is 0 to 44,640).

server disconnect-wait-time <0-44640
STEP 7 | Import the CA cerficate to validate the cerficate for the PAN-DB M-600 appliance.
2. Import the CA cerficate.
URL Filtering
STEP 8 | Configure a local or a SCEP cerficate for the firewall.

1. If you are a local cerficate, then import the key pair for the firewall.
2. If you are a SCEP cerficate for the firewall, configure a SCEP profile.
STEP 9 | Configure the cerficate profile for the firewall. You can configure this on each firewall
individually or you can push the configuraon from Panorama to the firewalls as part of a
template.
1. Select Device > Cerficate Management > Cerficate Profile for firewalls or Panorama >
Cerficate Management > Cerficate Profile for Panorama.
STEP 10 | Deploy custom cerficates on each firewall. You can either deploy cerficates centrally from
Panorama or configure them manually on each firewall.
2. Select Device > Setup > Management for a firewall or Panorama > Setup > Management
for Panorama and Edit the Secure Communicaon
3. Select the Cerficate Type, Cerficate, and Cerficate Profile from the respecve drop-
downs.
4. In the Customize Communicaon sengs, select PAN-DB Communicaon.
5. Click OK.
Aer comming your changes, the firewalls do not terminate their current sessions with
the PAN-DB server unl aer the Disconnect Wait Time. The disconnect wait me begins
counng down aer you enforce the use of custom cerficates in the next step.
STEP 11 | Aer deploying custom cerficates on all firewalls, enforce custom cerficate authencaon.
1. Log in to the CLI on the PAN-DB server and enter configuraon mode.
2. Enforce the use of custom cerficates.

server disable-pre-defined-cert yes
Aer comming this change, the disconnect wait me begins counng down (if you
configured seng on PAN-DB). When the wait me ends, PAN-DB and its firewall connect
using only the configured cerficates.
STEP 12 | You have two choices when adding new firewalls or Panorama to your PAN-DB private cloud
deployment.
• If you did not enable Custom Cerficates Only then you can add a new firewall to the PAN-
DB private cloud and then deploy the custom cerficate as described above.
• If you enabled Custom Cerficates Only on the PAN-DB private cloud, then you can must
deploy the custom cerficates on the firewalls before connecng them to the PAN-DB
private cloud.
URL Filtering
Enable SSL/TLS Handshake Inspecon

SSL/TLS handshake inspecon closes a gap in threat detecon for SSL/TLS web traffic marked
for decrypon. When enabled, the Content and Threat Detecon (CTD) engine of the firewall
inspects HTTPS traffic for potenal threats during the SSL/TLS handshake. The firewall uses data
in the handshake to idenfy the traffic and enforce applicable Security policy rules. Examining
the handshake improves network security and opmizes our URL Filtering soluon by prevenng
threats and enforcing Security policy acons on web traffic as early as possible.
Specifically, the firewall scans the Client Hello message for the Server Name Indicaon (SNI) field, an
extension to the SSL/TLS protocol that contains the hostname of a requested website. From the
hostname, the firewall can derive the URL category and server desnaon of the traffic. Then, it
evaluates the URL category against the URL Filtering profiles of matching Security policy rules to
determine which acons to enforce. If the firewall detects a threat, such as a malicious web server
in the SNI field, or policy dictates that the website be blocked, it will terminate the handshake and
end the web session immediately. If no threat is detected and the traffic is allowed per policy, the
client and server can complete the SSL/TLS handshake and exchange applicaon data through the
secure connecon.
URL Filtering response pages do not display for sites blocked by the firewall during SSL/
TLS handshake inspecons. Aer detecng traffic from blocked categories, the firewall
resets the HTTPS connecon, ending the handshake and prevenng user noficaon by
response page. Instead, the browser displays a standard connecon error message.
Details of successful SSL/TLS handshakes and sessions will be in the Traffic and Decrypon
logs. If the firewall blocks web sessions during the SSL/TLS handshake, it will not generate
Decrypon logs. You can find details of failed sessions in the URL Filtering logs, however.
The following procedure details the requirements and steps needed to enable SSL/TLS handshake
inspecon:
STEP 1 | Select Device > Licenses to confirm that you have an acve Advanced URL Filtering or
legacy URL Filtering license.
STEP 2 | Verify that you decrypt SSL/TLS traffic through either SSL Forward Proxy or SSL Inbound
Inspecon.
URL Filtering
STEP 3 | Enable inspecon of SSL/TLS handshakes by CTD. By default, the opon is disabled.
URL Filtering
URL Filtering
1. Select Device > Setup > Session > Decrypon Sengs > SSL Decrypon Sengs.
2. Select Send handshake messages to CTD for inspecon.
Alternavely, you can use the set deviceconfig setting ssl-decrypt scan-
handshake <yes|no> CLI command.
3. Click OK.
STEP 4 | Commit your configuraon changes.
Quality of Service
Quality of Service (QoS) is a set of technologies that work on a network to guarantee
its ability to dependably run high-priority applicaons and traffic under limited
network capacity. QoS technologies accomplish this by providing differenated
handling and capacity allocaon to specific flows in network traffic. This enables the
network administrator to assign the order in which traffic is handled, and the amount
of bandwidth afforded to traffic.
Palo Alto Networks Applicaon Quality of Service (QoS) provides basic QoS applied to
networks and extends it to provide QoS to applicaons and users.
Use the following topics to learn about and configure Palo Alto Networks applicaon-
based QoS:
> QoS Overview

> QoS Concepts
> Configure QoS
> Configure QoS for a Virtual System
> Enforce QoS Based on DSCP Classificaon
> QoS Use Cases
Use the Palo Alto Networks product comparison tool to view the QoS features
supported on your firewall model. Select two or more product models and click
Compare Now to view QoS feature support for each model (for example, you can
check if your firewall model supports QoS on subinterfaces and if so, the maximum
number of subinterfaces on which QoS can be enabled).
QoS on Aggregate Ethernet (AE) interfaces is supported on PA-7000 Series, PA-5200
Series, and PA-3200 Series firewalls running PAN-OS 7.0 or later release versions.
1193
Quality of Service
QoS Overview
Use QoS to priorize and adjust quality aspects of network traffic. You can assign the order in
which packets are handled and allot bandwidth, ensuring preferred treatment and opmal levels of
performance are afforded to selected traffic, applicaons, and users.
Service quality measurements subject to a QoS implementaon are bandwidth (maximum rate
of transfer), throughput (actual rate of transfer), latency (delay), and jier (variance in latency).
The capability to shape and control these service quality measurements makes QoS of parcular
importance to high-bandwidth, real-me traffic such as voice over IP (VoIP), video conferencing,
and video-on-demand that has a high sensivity to latency and jier. Addionally, use QoS to
achieve outcomes such as the following:
• Priorize network and applicaon traffic, guaranteeing high priority to important traffic or
liming non-essenal traffic.
• Achieve equal bandwidth sharing among different subnets, classes, or users in a network.
• Allocate bandwidth externally or internally or both, applying QoS to both upload and download
traffic or to only upload or download traffic.
• Ensure low latency for customer and revenue-generang traffic in an enterprise environment.
• Perform traffic profiling of applicaons to ensure bandwidth usage.
QoS implementaon on a Palo Alto Networks firewall begins with three primary configuraon
components that support a full QoS soluon: a QoS Profile, a QoS Policy, and seng up the QoS
Egress Interface. Each of these opons in the QoS configuraon task facilitate a broader process
that opmizes and priorizes the traffic flow and allocates and ensures bandwidth according to
configurable parameters.
The figure QoS Traffic Flow shows traffic as it flows from the source, is shaped by the firewall with
QoS enabled, and is ulmately priorized and delivered to its desnaon.
Figure 6: QoS Traffic Flow
The QoS configuraon opons allow you to control the traffic flow and define it at different points
in the flow. The figure QoS Traffic Flow indicates where the configurable opons define the traffic
flow. A QoS policy rule allows you to define traffic you want to receive QoS treatment and assign
Quality of Service
that traffic a QoS class. The matching traffic is then shaped based on the QoS profile class sengs
as it exits the physical interface.
Each of the QoS configuraon components influence each other and the QoS configuraon
opons can be used to create a full and granular QoS implementaon or can be used sparingly
with minimal administrator acon.
Each firewall model supports a maximum number of ports that can be configured with QoS. Refer
to the spec sheet for your firewall model or use the product comparison tool to view QoS feature
support for two or more firewalls on a single page.
Quality of Service
QoS Concepts
Use the following topics to learn about the different components and mechanisms of a QoS
configuraon on a Palo Alto Networks firewall:
• QoS for Applicaons and Users
• QoS Policy
• QoS Profile
• QoS Classes
• QoS Priority Queuing
• QoS Bandwidth Management
• QoS Egress Interface
• QoS for Clear Text and Tunneled Traffic
QoS for Applicaons and Users

A Palo Alto Networks firewall provides basic QoS, controlling traffic leaving the firewall according
to network or subnet, and extends the power of QoS to also classify and shape traffic according
to applicaon and user. The Palo Alto Networks firewall provides this capability by integrang the
features App-ID and User-ID with the QoS configuraon. App-ID and User-ID entries that exist to
idenfy specific applicaons and users in your network are available in the QoS configuraon so
that you can easily specify applicaons and users for which you want to manage and/or guarantee
bandwidth.
QoS Policy
Use a QoS policy rule to define traffic to receive QoS treatment (either preferenal treatment or
bandwidth-liming) and assigns such traffic a QoS class of service.
Define a QoS policy rule to match to traffic based on:
• Applicaons and applicaon groups.
• Source zones, source addresses, and source users.
• Desnaon zones and desnaon addresses.
• Services and service groups limited to specific TCP and/or UDP port numbers.
• URL categories, including custom URL categories.
• Differenated Services Code Point (DSCP) and Type of Service (ToS) values, which are used to
indicate the level of service requested for traffic, such as high priority or best effort delivery.
You cannot apply DSCP code points or QoS to SSL Forward Proxy, SSL Inbound Inspecon,
and SSH Proxy traffic.
Set up mulple QoS policy rules (Policies > QoS) to associate different types of traffic with
different QoS Classes of service.
Quality of Service
Because QoS is enforced on traffic as it egresses the firewall, your QoS policy rule is applied to
traffic aer the firewall has enforced all other security policy rules, including Network Address
Translaon (NAT) rules. If you want to apply QoS treatment to traffic based on source, make
sure to specify the post-NAT source address in a QoS policy rule (do not use the pre-NAT source
address).
QoS Profile
Use a QoS profile rule to define values of up to eight QoS Classes contained within that single
profile rule.
With a QoS profile rule, you can define QoS Priority Queuing and QoS Bandwidth Management
for QoS classes. Each QoS profile rule allows you to configure individual bandwidth and priority
sengs for up eight QoS classes, as well as the total bandwidth alloted for the eight classes
combined. Aach the QoS profile rule (or mulple QoS profile rules) to a physical interface to
apply the defined priority and bandwidth sengs to the traffic exing that interface.
A default QoS profile rule is available on the firewall. The default profile rule and the classes
defined in the profile do not have predefined maximum or guaranteed bandwidth limits.
To define priority and bandwidth sengs for QoS classes, see Step Add a QoS profile rule.
QoS Classes
A QoS class determines the priority and bandwidth for traffic matching a QoS Policy rule. You can
use a QoS Profile rule to define QoS classes. There are up to eight definable QoS classes in a single
QoS profile. Unless otherwise configured, traffic that does not match a QoS class is assigned a
class of 4.
QoS Priority Queuing and QoS Bandwidth Management, the fundamental mechanisms of a QoS
configuraon, are configured within the QoS class definion (see Step 4). For each QoS class, you
can set a priority (real-me, high, medium, and low) and the maximum and guaranteed bandwidth
for matching traffic. QoS priority queuing and bandwidth management determine the order of
traffic and how traffic is handled upon entering or leaving a network.
Quality of Service
QoS Priority Queuing

One of four priories can be enforced for a QoS class: real-me, high, medium, and low. Traffic
matching a QoS policy rule is assigned the QoS class associated with that rule, and the firewall
treats the matching traffic based on the QoS class priority. Packets in the outgoing traffic flow are
queued based on their priority unl the network is ready to process the packets. Priority queuing
allows you to ensure that important traffic, applicaons, and users take precedence. Real-me
priority is typically used for applicaons that are parcularly sensive to latency, such as voice and
video applicaons.
QoS Bandwidth Management

QoS bandwidth management allows you to control traffic flows on a network so that traffic does
not exceed network capacity (resulng in network congeson) and also allows you to allocate
bandwidth for certain types of traffic and for applicaons and users. With QoS, you can enforce
bandwidth for traffic on a narrow or a broad scale. A QoS profile rule allows you to set bandwidth
limits for individual QoS classes and the total combined bandwidth for all eight QoS classes. As
part of the steps to Configure QoS, you can aach the QoS profile rule to a physical interface to
enforce bandwidth sengs on the traffic exing that interface—the individual QoS class sengs
are enforced for traffic matching that QoS class (QoS classes are assigned to traffic matching QoS
Policy rules) and the overall bandwidth limit for the profile can be applied to all clear text traffic,
specific clear text traffic originang from source interfaces and source subnets, all tunneled traffic,
and individual tunnel interfaces. You can add mulple profile rules to a single QoS interface to
apply varying bandwidth sengs to the traffic exing that interface.
The following fields support QoS bandwidth sengs:
Quality of Service
• Egress Guaranteed—The amount of bandwidth guaranteed for matching traffic. When the
egress guaranteed bandwidth is exceeded, the firewall passes traffic on a best-effort basis.
Bandwidth that is guaranteed but is unused connues to remain available for all traffic.
Depending on your QoS configuraon, you can guarantee bandwidth for a single QoS class, for
all or some clear text traffic, and for all or some tunneled traffic.
Example:
Class 1 traffic has 5 Gbps of egress guaranteed bandwidth, which means that 5 Gbps is
available but is not reserved for class 1 traffic. If Class 1 traffic does not use or only parally
uses the guaranteed bandwidth, the remaining bandwidth can be used by other classes of
traffic. However, during high traffic periods, 5 Gbps of bandwidth is absolutely available for
class 1 traffic. During these periods of congeson, any Class 1 traffic that exceeds 5 Gbps is
best effort.
• Egress Max—The overall bandwidth allocaon for matching traffic. The firewall drops traffic
that exceeds the egress max limit that you set. Depending on your QoS configuraon, you can
set a maximum bandwidth limit for a QoS class, for all or some clear text traffic, for all or some
tunneled traffic, and for all traffic exing the QoS interface.
The cumulave guaranteed bandwidth for the QoS profile rules aached to the
interface must not exceed the total bandwidth allocated to the interface.
To define bandwidth sengs for QoS classes, see Step Add a QoS profile rule. To then apply those
bandwidth sengs to clear text and tunneled traffic, and to set the overall bandwidth limit for a
QoS interface, see Step Enable QoS on a physical interface.
QoS Egress Interface

Enabling a QoS profile rule on the egress interface of the traffic idenfied for QoS treatment
completes a QoS configuraon. The ingress interface for QoS traffic is the interface on which the
traffic enters the firewall. The egress interface for QoS traffic is the interface that traffic leaves the
firewall from. QoS is always enabled and enforced on the egress interface for a traffic flow. The
egress interface in a QoS configuraon can either be the external- or internal-facing interface of
the firewall, depending on the flow of the traffic receiving QoS treatment.
For example, in an enterprise network, if you are liming employees’ download traffic from a
specific website, the egress interface in the QoS configuraon is the firewall’s internal interface,
as the traffic flow is from the Internet, through the firewall, and to your company network.
Alternavely, when liming employees’ upload traffic to the same website, the egress interface in
the QoS configuraon is the firewall’s external interface, as the traffic you are liming flows from
your company network, through the firewall, and then to the Internet.
Quality of Service
Because QoS is enforced on traffic as it egresses the firewall, your QoS policy rule is applied to
traffic aer the firewall has enforced all other security policy rules, including Network Address
Translaon (NAT) rules. If you want to apply QoS treatment to traffic based on source, you must
specify the post-NAT source address in a QoS policy rule (do not use the pre-NAT source address).
Learn more about how to Idenfy the egress interface for applicaons that you want to receive
QoS treatment.
QoS for Clear Text and Tunneled Traffic

At the minimum, enabling a QoS interfaces requires you to select a default QoS profile rule that
defines bandwidth and priority sengs for clear text traffic egressing the interface. However,
when seng up or modifying a QoS interface, you can apply granular QoS sengs to outgoing
clear text traffic and tunneled traffic. QoS preferenal treatment and bandwidth liming can
be enforced for tunneled traffic, for individual tunnel interfaces, and/or for clear text traffic
originang from different source interfaces and source subnets. On Palo Alto Networks firewalls,
tunneled traffic refers to tunnel interface traffic, specifically IPSec traffic in tunnel mode.
Quality of Service
Configure QoS
Follow these steps to configure Quality of Service (QoS), which includes creang a QoS profile,
creang a QoS policy, and enabling QoS on an interface.
STEP 1 | Idenfy the traffic you want to manage with QoS.
This example shows how to use QoS to limit web browsing.
Select ACC to view the Applicaon Command Center page. Use the sengs and charts on the
ACC page to view trends and traffic related to Applicaons, URL filtering, Threat Prevenon,
Data Filtering, and HIP Matches.
Click any applicaon name to display detailed applicaon informaon.
Quality of Service
STEP 2 | Idenfy the egress interface for applicaons that you want to receive QoS treatment.
The egress interface for traffic depends on the traffic flow. If you are shaping incoming
traffic, the egress interface is the internal-facing interface. If you are shaping outgoing
traffic, the egress interface is the external-facing interface.
Select Monitor > Logs > Traffic to view the Traffic logs.
To filter and only show logs for a specific applicaon:
• If an entry is displayed for the applicaon, click the underlined link in the Applicaon
column then click the Submit icon.
• If an entry is not displayed for the applicaon, click the Add Log icon and search for the
applicaon.
The Egress I/F in the traffic logs displays each applicaon’s egress interface. To display the
Egress I/F column if it is not displayed by default:
• Click any column header to add a column to the log:
• Click the spyglass icon to the le of any entry to display a detailed log that includes the
applicaon’s egress interface listed in the Desnaon secon:
Quality of Service
STEP 3 | Add a QoS policy rule.

A QoS policy rule defines the traffic to receive QoS treatment. The firewall assigns a QoS class
of service to the traffic matched to the policy rule.
Because QoS is enforced on traffic as it egresses the firewall, your QoS policy rule is
applied to traffic aer the firewall has enforced all other security policy rules, including
Network Address Translaon (NAT) rules. If you want to apply QoS treatment to traffic
based on source, you must specify the post-NAT source address in a QoS policy rule (do
not use the pre-NAT source address).
1. Select Policies > QoS and Add a new policy rule.

2. On the General tab, give the QoS Policy Rule a descripve Name.
3. Specify traffic to receive QoS treatment based on Source, Desnaon, Applicaon,
Service/URL Category, and DSCP/ToS values (the DSCP/ToS sengs allow you to
Enforce QoS Based on DSCP Classificaon).
For example, select the Applicaon, click Add, and select web-browsing to apply QoS to
web browsing traffic.
4. (Oponal) Connue to define addional parameters. For example, select Source and Add
a Source User to provide QoS for a specific user’s web traffic.
5. Select Other Sengs and assign a QoS Class to traffic matching the policy rule. For
example, assign Class 2 to the user1’s web traffic.
6. Click OK.
Quality of Service
STEP 4 | Add a QoS profile rule.

A QoS profile rule allows you to define the eight classes of service that traffic can receive,
including priority, and enables QoS Bandwidth Management.
You can edit any exisng QoS profile, including the default, by clicking the QoS profile name.
1. Select Network > Network Profiles > QoS Profile and Add a new profile.
2. Enter a descripve Profile Name.
3. Set the overall bandwidth limits for the QoS profile rule:
• Enter an Egress Max value to set the overall bandwidth allocaon for the QoS profile
rule.
• Enter an Egress Guaranteed value to set the guaranteed bandwidth for the QoS
Profile.
Any traffic that exceeds the Egress Guaranteed value is best effort and not
guaranteed. Bandwidth that is guaranteed but is unused connues to remain
available for all traffic.
4. In the Classes secon, specify how to treat up to eight individual QoS classes:
1. Add a class to the QoS Profile.
2. Select the Priority for the class: real-me, high, medium, or low.
3. Enter the Egress Max and Egress Guaranteed bandwidth for traffic assigned to each
QoS class.
5. Click OK.
In the following example, the QoS profile rule Limit Web Browsing limits Class 2 traffic to a
maximum bandwidth of 50Mbps and a guaranteed bandwidth of 2Mbps.
Quality of Service
STEP 5 | Enable QoS on a physical interface.

Part of this step includes the opon to select clear text and tunneled traffic for unique QoS
treatment.
Check if the firewall model you’re using supports enabling QoS on a subinterface by
reviewing a summary of the Product Specificaons.
1. Select Network > QoS and Add a QoS interface.

2. Select Physical Interface and choose the Interface Name of the interface on which to
enable QoS.
In the example, Ethernet 1/1 is the egress interface for web-browsing traffic (see Step 2).
3. Set the Egress Max bandwidth for all traffic exing this interface.
It is a best pracce to always define the Egress Max value for a QoS interface.
Ensure that the cumulave guaranteed bandwidth for the QoS profile rules
aached to the interface does not exceed the total bandwidth allocated to the
interface.
4. Select Turn on QoS feature on this interface.
5. In the Default Profile secon, select a QoS profile rule to apply to all Clear Text traffic
exing the physical interface.
6. (Oponal) Select a default QoS profile rule to apply to all tunneled traffic exing the
interface.
For example, enable QoS on ethernet 1/1 and apply the bandwidth and priority sengs you
defined for the QoS profile rule Limit Web Browsing (Step 4) to be used as the default sengs
for clear text egress traffic.
1. (Oponal) Connue to define more granular sengs to provide QoS for Clear Text and
Tunneled Traffic. Sengs configured on the Clear Text Traffic tab and the Tunneled
Quality of Service
Traffic tab automacally override the default profile sengs for clear text and tunneled
traffic on the Physical Interface tab.
• Select Clear Text Traffic and:
• Set the Egress Guaranteed and Egress Max bandwidths for clear text traffic.
• Click Add and apply a QoS profile rule to enforce clear text traffic based on source
interface and source subnet.
(PA-3200 Series, PA-5200 Series, PA-5400 Series, PA-7000 Series only)

You must also select a desnaon interface when configuring a QoS policy
rule if the rule is applied to a specific subinterface.
• Select Tunneled Traffic and:
• Set the Egress Guaranteed and Egress Max bandwidths for tunneled traffic.
• Click Add and aach a QoS profile rule to a single tunnel interface.
2. Click OK.

Click Commit.
Quality of Service
STEP 7 | Verify a QoS configuraon.

Select Network > QoS and then Stascs to view QoS bandwidth, acve sessions of a
selected QoS class, and acve applicaons for the selected QoS class.
For example, see the stascs for ethernet 1/3 with QoS enabled:
Class 2 traffic limited to 2.343 Mbps of guaranteed bandwidth and a maximum bandwidth of
51.093 Mbps.
Connue to click the tabs to display further informaon regarding applicaons, source users,
desnaon users, security rules and QoS rules.
Bandwidth limits shown on the QoS Stascs window include a hardware adjustment
factor.
Quality of Service
Configure QoS for a Virtual System

QoS can be configured for a single or several virtual systems configured on a Palo Alto
Networks firewall. Because a virtual system is an independent firewall, QoS must be configured
independently for a single virtual system.
Configuring QoS for a virtual system is similar to configuring QoS on a physical firewall, with the
excepon that configuring QoS for a virtual system requires specifying the source and desnaon
of traffic. Because a virtual system exists without set physical boundaries and because traffic in a
virtual environment spans more than one virtual system, specifying source and desnaon zones
and interfaces for traffic is necessary to control and shape traffic for a single virtual system.
The example below shows two virtual systems configured on firewall. VSYS 1 (purple) and VSYS
2 (red) each have QoS configured to priorize or limit two disnct traffic flows, indicated by their
corresponding purple (VSYS 1) and red (VSYS 2) lines. The QoS nodes indicate the points at traffic
is matched to a QoS policy and assigned a QoS class of service, and then later indicate the point at
which traffic is shaped as it egresses the firewall.
Refer to Virtual Systems for informaon on virtual systems and how to configure them.
STEP 1 | Confirm that the appropriate interfaces, virtual routers, and security zones are associated
with each virtual system.
• To view configured interfaces, select Network > Interface.
• To view configured zones, select Network > Zones.
• To view informaon on defined virtual routers, select Network > Virtual Routers.
Quality of Service
STEP 2 | Idenfy traffic to apply QoS to.

Select ACC to view the Applicaon Command Center page. Use the sengs and charts on the
ACC page to view trends and traffic related to Applicaons, URL filtering, Threat Prevenon,
Data Filtering, and HIP Matches.
To view informaon for a specific virtual system, select the virtual system from the Virtual
System drop-down:
Click any applicaon name to display detailed applicaon informaon.
Quality of Service
STEP 3 | Idenfy the egress interface for applicaons that you idenfied as needing QoS treatment.
In a virtual system environment, QoS is applied to traffic on the traffic’s egress point on the
virtual system. Depending the configuraon and QoS policy for a virtual system, the egress
point of QoS traffic could be associated with a physical interface or could be a zone.
This example shows how to limit web-browsing traffic on vsys 1.
Select Monitor > Logs > Traffic to view traffic logs. Each entry has the opon to display
columns with informaon necessary to configure QoS in a virtual system environment:
• virtual system
• egress interface
• ingress interface
• source zone
• desnaon zone
To display a column if it is not displayed by default:
• Click any column header to add a column to the log:
• Click the spyglass icon to the le of any entry to display a detailed log that includes the
applicaon’s egress interface, as well as source and desnaon zones, in the Source and
Desnaon secons:
For example, for web-browsing traffic from VSYS 1, the ingress interface is ethernet 1/2, the
egress interface is ethernet 1/1, the source zone is trust and the desnaon zone is untrust.
Quality of Service
STEP 4 | Create a QoS Profile.

You can edit any exisng QoS Profile, including the default, by clicking the profile name.
1. Select Network > Network Profiles > QoS Profile and click Add to open the QoS Profile
dialog.
2. Enter a descripve Profile Name.
3. Enter an Egress Max to set the overall bandwidth allocaon for the QoS profile.
4. Enter an Egress Guaranteed to set the guaranteed bandwidth for the QoS profile.
Any traffic that exceeds the QoS profile’s egress guaranteed limit is best effort
but is not guaranteed.
5. In the Classes secon of the QoS Profile, specify how to treat up to eight individual QoS
classes:
1. Click Add to add a class to the QoS Profile.
2. Select the Priority for the class.
3. Enter an Egress Max for a class to set the overall bandwidth limit for that individual
class.
4. Enter an Egress Guaranteed for the class to set the guaranteed bandwidth for that
individual class.
6. Click OK to save the QoS profile.
STEP 5 | Create a QoS policy.

In an environment with mulple virtual systems, traffic spans more than one virtual system.
Because of this, when you are enabling QoS for a virtual system, you must define traffic to
receive QoS treatment based on source and desnaon zones. This ensures that the traffic is
Quality of Service
priorized and shaped only for that virtual system (and not for other virtual systems through
which the traffic might flow).
1. Select Policies > QoS and Add a QoS Policy Rule.
2. Select General and give the QoS Policy Rule a descripve Name.
3. Specify the traffic to which the QoS policy rule will apply. Use the Source, Desnaon,
Applicaon, and Service/URL Category tabs to define matching parameters for
idenfying traffic.
For example, select Applicaon and Add web-browsing to apply the QoS policy rule to
that applicaon:
4. Select Source and Add the source zone of vsys 1 web-browsing traffic.
5. Select Desnaon and Add the desnaon zone of vsys 1 web-browsing traffic.
6. Select Other Sengs and select a QoS Class to assign to the QoS policy rule. For
example, assign Class 2 to web-browsing traffic on vsys 1:
7. Click OK to save the QoS policy rule.
Quality of Service
STEP 6 | Enable the QoS Profile on a physical interface.
It is a best pracce to always define the Egress Max value for a QoS interface.
1. Select Network > QoS and click Add to open the QoS Interface dialog.
2. Enable QoS on the physical interface:
1. On the Physical Interface tab, select the Interface Name of the interface to apply the
QoS Profile to.
In this example, ethernet 1/1 is the egress interface for web-browsing traffic on vsys 1
(see Step 2).
2. Select Turn on QoS feature on this interface.

3. On the Physical Interface tab, select the default QoS profile to apply to all Clear Text
traffic.
(Oponal) Use the Tunnel Interface field to apply a default QoS profile to all tunneled
traffic.
4. (Oponal) On the Clear Text Traffic tab, configure addional QoS sengs for clear text
traffic:
• Set the Egress Guaranteed and Egress Max bandwidths for clear text traffic.
• Click Add to apply a QoS Profile to selected clear text traffic, further selecng the
traffic for QoS treatment according to source interface and source subnet (creang a
QoS node).
5. (Oponal) On the Tunneled Traffic tab, configure addional QoS sengs for tunnel
interfaces:
• Set the Egress Guaranteed and Egress Max bandwidths for tunneled traffic.
• Click Add to associate a selected tunnel interface with a QoS Profile.
6. Click OK to save changes.
STEP 7 | Verify QoS configuraon.

• Select Network > QoS to view the QoS Policies page. The QoS Policies page verifies that
QoS is enabled and includes a Stascs link. Click the Stascs link to view QoS bandwidth,
Quality of Service
acve sessions of a selected QoS node or class, and acve applicaons for the selected QoS
node or class.
• In a mul-vsys environment, sessions cannot span mulple systems. Mulple sessions are
created for one traffic flow if the traffic passes through more than one virtual system. To
browse sessions running on the firewall and view applied QoS Rules and QoS Classes, select
Monitor > Session Browser.
Quality of Service
Enforce QoS Based on DSCP Classificaon

A Differenated Services Code Point (DSCP) is a packet header value that can be used to request
(for example) high priority or best effort delivery for traffic. Session-Based DSCP Classificaon
allows you to both honor DSCP values for incoming traffic and to mark a session with a DSCP
value as session traffic exits the firewall. This enables all inbound and outbound traffic for a
session can receive connuous QoS treatment as it flows through your network. For example,
inbound return traffic from an external server can now be treated with the same QoS priority that
the firewall inially enforced for the outbound flow based on the DSCP value the firewall detected
at the beginning of the session. Network devices between the firewall and end user will also then
enforce the same priority for the return traffic (and any other outbound or inbound traffic for the
session).
You cannot apply DSCP code points or QoS to SSL Forward Proxy, SSL Inbound Inspecon,
and SSH Proxy traffic.
Different types of DSCP markings indicate different levels of service:

Compleng this step enables the firewall to mark traffic with the same DSCP value that was
detected at the beginning of a session (in this example, the firewall would mark return traffic
with the DSCP AF11 value). While configuring QoS allows you to shape traffic as it egresses the
firewall, enabling this opon in a security rule allows the other network devices intermediate to
the firewall and the client to connue to enforce priority for DSCP marked traffic.
• Expedited Forwarding (EF): Can be used to request low loss, low latency and guaranteed
bandwidth for traffic. Packets with EF codepoint values are typically guaranteed highest
priority delivery.
• Assured Forwarding (AF): Can be used to provide reliable delivery for applicaons. Packets
with AF codepoint indicate a request for the traffic to receive higher priority treatment than
best effort service provides (though packets with an EF codepoint will connue to take
precedence over those with an AF codepoint).
• Class Selector (CS): Can be used to provide backward compability with network devices that
use the IP precedence field to mark priority traffic.
• IP Precedence (ToS): Can be used by legacy network devices to mark priority traffic (the IP
Precedence header field was used to indicate the priority for a packet before the introducon
of the DSCP classificaon).
• Custom Codepoint: Create a custom codepoint to match to traffic by entering a Codepoint
Name and Binary Value.
For example, select the Assured Forwarding (AF) to ensure traffic marked with an AF codepoint
value has higher priority for reliable delivery over applicaons marked to receive lower priority.Use
the following steps to enable Session-Based DSCP Classificaon. Start by configuring QoS based
on DSCP marking detected at the beginning of a session. You can then connue to enable the
firewall to mark the return flow for a session with the same DSCP value used to enforce QoS for
the inial outbound flow.
STEP 1 | Perform the preliminary steps to Configure QoS.
Quality of Service
STEP 2 | Define the traffic to receive QoS treatment based on DSCP value.
1. Select Policies > QoS and Add or modify an exisng QoS rule and populate required
fields.
2. Select DSCP/ToS and select Codepoints.
3. Add DSCP/ToS codepoints for which you want to enforce QoS.
4. Select the Type of DSCP/ToS marking for the QoS rule to match to traffic:
It is a best pracce to use a single DSCP type to manage and priorize your
network traffic.
5. Match the QoS policy to traffic on a more granular scale by specifying the Codepoint
value. For example, with Assured Forwarding (AF) selected as the Type of DSCP value for
the policy to match, further specify an AF Codepoint value such as AF11.
When Expedited Forwarding (EF) is selected as the Type of DSCP marking, a

granular Codepoint value cannot be specified. The QoS policy rule matches to
traffic marked with any EF codepoint value.
6. Select Other Sengs and assign a QoS Class to traffic matched to the QoS rule. In this
example, assign Class 1 to sessions where a DSCP marking of AF11 is detected for the
first packet in the session.
7. Click OK to save the QoS rule.
STEP 3 | Define the QoS priority for traffic to receive when it is matched to a QoS rule based the
DSCP marking detected at the beginning of a session.
1. Select Network > Network Profiles > QoS Profile and Add or modify an exisng QoS
profile. For details on profile opons to set priority and bandwidth for traffic, see QoS
Concepts and Configure QoS.
2. Add or modify a profile class. For example, because Step 2 showed steps to classify AF11
traffic as Class 1 traffic, you could add or modify a class1 entry.
3. Select a Priority for the class of traffic, such as high.
4. Click OK to save the QoS Profile.
STEP 4 | Enable QoS on an interface.

Select Network > QoS and Add or modify an exisng interface and Turn on QoS feature on
this interface.
In this example, traffic with an AF11 DSCP marking is matched to the QoS rule and assigned
Class 1. The QoS profile enabled on the interface enforces high priority treatment for Class 1
traffic as it egresses the firewall (the session outbound traffic).
Quality of Service
STEP 5 | Enable DSCP Marking.

Mark return traffic with a DSCP value, enabling the inbound flow for a session to be marked
with the same DSCP value detected for the outbound flow.
1. Select Policies > Security and Add or modify a security policy.
2. Select Acons and in the QoS Marking drop-down, choose Follow Client-to-Server
Flow.
Compleng this step enables the firewall to mark traffic with the same DSCP value that
was detected at the beginning of a session (in this example, the firewall would mark return
traffic with the DSCP AF11 value). While configuring QoS allows you to shape traffic as it
egresses the firewall, enabling this opon in a security rule allows the other network devices
intermediate to the firewall and the client to connue to enforce priority for DSCP marked
traffic.

Commit your changes.
Quality of Service
QoS Use Cases

The following use cases demonstrate how to use QoS in common scenarios:
• Use Case: QoS for a Single User
• Use Case: QoS for Voice and Video Applicaons
Use Case: QoS for a Single User

A CEO finds that during periods of high network usage, she is unable to access enterprise
applicaons to respond effecvely to crical business communicaons. The IT admin wants to
ensure that all traffic to and from the CEO receives preferenal treatment over other employee
traffic so that she is guaranteed not only access to, but high performance of, crical network
resources.
STEP 1 | The admin creates the QoS profile CEO_traffic to define how traffic originang from the CEO
will be treated and shaped as it flows out of the company network:
The admin assigns a guaranteed bandwidth (Egress Guaranteed) of 50 Mbps to ensure that the
CEO will have that amount that bandwidth guaranteed to her at all mes (more than she would
need to use), regardless of network congeson.
The admin connues by designang Class 1 traffic as high priority and sets the profile’s
maximum bandwidth usage (Egress Max) to 1000 Mbps, the same maximum bandwidth for the
interface that the admin will enable QoS on. The admin is choosing to not restrict the CEO’s
bandwidth usage in any way.
It is a best pracce to populate the Egress Max field for a QoS profile, even if the max
bandwidth of the profile matches the max bandwidth of the interface. The QoS profile’s
max bandwidth should never exceed the max bandwidth of the interface you are
planning to enable QoS on.
STEP 2 | The admin creates a QoS policy to idenfy the CEO’s traffic (Policies > QoS) and assigns it
the class that he defined in the QoS profile (see prior step). Because User-ID is configured,
the admin uses the Source tab in the QoS policy to singularly idenfy the CEO’s traffic by her
Quality of Service
company network username. (If User-ID is not configured, the administrator could Add the
CEO’s IP address under Source Address. See User-ID.):
The admin associates the CEO’s traffic with Class 1 (Other Sengs tab) and then connues
to populate the remaining required policy fields; the admin gives the policy a descripve
Name (General tab) and selects Any for the Source Zone (Source tab) and Desnaon Zone
(Desnaon tab):
STEP 3 | Now that Class 1 is associated with the CEO’s traffic, the admin enables QoS by checking
Turn on QoS feature on interface and selecng the traffic flow’s egress interface. The egress
interface for the CEO’s traffic flow is the external-facing interface, in this case, ethernet 1/2:
Because the admin wants to ensure that all traffic originang from the CEO is guaranteed by
the QoS profile and associated QoS policy he created, he selects the CEO_traffic to apply to
Clear Text traffic flowing from ethernet 1/2.
STEP 4 | Aer comming the QoS configuraon, the admin navigates to the Network > QoS page to
confirm that the QoS profile CEO_traffic is enabled on the external-facing interface, ethernet
1/2:
Quality of Service
STEP 5 | He clicks Stascs to view how traffic originang with the CEO (Class 1) is being shaped as it
flows from ethernet 1/2:
This case demonstrates how to apply QoS to traffic originang from a single source
user. However, if you also wanted to guarantee or shape traffic to a desnaon user,
you could configure a similar QoS setup. Instead of, or in addion to this work flow,
create a QoS policy that specifies the user’s IP address as the Desnaon Address on
the Policies > QoS page (instead of specifying the user’s source informaon) and then
enable QoS on the network’s internal-facing interface on the Network > QoS page
(instead of the external-facing interface).
Use Case: QoS for Voice and Video Applicaons

Voice and video traffic is parcularly sensive to measurements that the QoS feature shapes and
controls, especially latency and jier. For voice and video transmissions to be audible and clear,
voice and video packets cannot be dropped, delayed, or delivered inconsistently. A best pracce
for voice and video applicaons, in addion to guaranteeing bandwidth, is to guarantee priority to
voice and video traffic.
In this example, employees at a company branch office are experiencing difficules and
unreliability in using video conferencing and Voice over IP (VoIP) technologies to conduct business
communicaons with other branch offices, with partners, and with customers. An IT admin
intends to implement QoS in order to address these issues and ensure effecve and reliable
business communicaon for the branch employees. Because the admin wants to guarantee QoS to
both incoming and outgoing network traffic, he will enable QoS on both the firewall’s internal- and
external-facing interfaces.
Quality of Service
STEP 1 | The admin creates a QoS profile, defining Class 2 so that Class 2 traffic receives real-me
priority and on an interface with a maximum bandwidth of 1000 Mbps, is guaranteed a
bandwidth of 250 Mbps at all mes, including peak periods of network usage.
Real-me priority is typically recommended for applicaons affected by latency, and is
parcularly useful in guaranteeing performance and quality of voice and video applicaons.
On the firewall web interface, the admin selects Network > Network Profiles > Qos Profile
page, clicks Add, enters the Profile Name ensure voip-video traffic and defines Class 2 traffic.
STEP 2 | The admin creates a QoS policy to idenfy voice and video traffic. Because the company
does not have one standard voice and video applicaon, the admin wants to ensure
QoS is applied to a few applicaons that are widely and regularly used by employees to
communicate with other offices, with partners, and with customers. On the Policies > QoS
> QoS Policy Rule > Applicaons tab, the admin clicks Add and opens the Applicaon Filter
window. The admin connues by selecng criteria to filter the applicaons he wants to apply
Quality of Service
QoS to, choosing the Subcategory voip-video, and narrowing that down by specifying only
voip-video applicaons that are both low-risk and widely-used.
The applicaon filter is a dynamic tool that, when used to filter applicaons in the QoS policy,
allows QoS to be applied to all applicaons that meet the criteria of voip-video, low risk, and
widely used at any given me.
The admin names the Applicaon Filter voip-video-low-risk and includes it in the QoS policy:
The admin names the QoS policy Voice-Video and selects Other Sengs to assign all traffic
matched to the policy Class 2. He is going to use the Voice-Video QoS policy for both incoming
and outgoing QoS traffic, so he sets Source and Desnaon informaon to Any:
STEP 3 | Because the admin wants to ensure QoS for both incoming and outgoing voice and video
communicaons, he enables QoS on the network’s external-facing interface (to apply QoS
Quality of Service
to outgoing communicaons) and to the internal-facing interface (to apply QoS to incoming
communicaons).
The admin begins by enabling the QoS profile he created, ensure voice-video traffic (Class 2 in
this profile is associated with policy, Voice-Video) on the external-facing interface, in this case,
ethernet 1/2.
He then enables the same QoS profile ensure voip-video traffic on a second interface, the
internal-facing interface (in this case, ethernet 1/1).
STEP 4 | The admin selects Network > QoS to confirm that QoS is enabled for both incoming and
outgoing voice and video traffic:
The admin has successfully enabled QoS on both the network’s internal- and external-facing
interfaces. Real-me priority is now ensured for voice and video applicaon traffic as it flows
both into and out of the network, ensuring that these communicaons, which are parcularly
sensive to latency and jier, can be used reliably and effecvely to perform both internal and
external business communicaons.
Quality of Service
VPNs
Virtual private networks (VPNs) create tunnels that allow users/systems to connect
securely over a public network, as if they were connecng over a local area network
(LAN). To set up a VPN tunnel, you need a pair of devices that can authencate each
other and encrypt the flow of informaon between them. The devices can be a pair
of Palo Alto Networks firewalls, or a Palo Alto Networks firewall along with a VPN-
capable device from another vendor.
> VPN Deployments

> Site-to-Site VPN Overview
> Site-to-Site VPN Concepts
> Set Up Site-to-Site VPN
> Site-to-Site VPN Quick Configs
1225
VPNs
VPN Deployments
The Palo Alto Networks firewall supports the following VPN deployments:
• Site-to-Site VPN— A simple VPN that connects a central site and a remote site, or a hub and
spoke VPN that connects a central site with mulple remote sites. The firewall uses the IP
Security (IPSec) set of protocols to set up a secure tunnel for the traffic between the two sites.
See Site-to-Site VPN Overview.
• Remote User-to-Site VPN—A soluon that uses the GlobalProtect agent to allow a remote
user to establish a secure connecon through the firewall. This soluon uses SSL and IPSec
to establish a secure connecon between the user and the site. Refer to the GlobalProtect
Administrator’s Guide.
• Large Scale VPN— The Palo Alto Networks GlobalProtect Large Scale VPN (LSVPN) provides
a simplified mechanism to roll out a scalable hub and spoke VPN with up to 1,024 satellite
offices. The soluon requires Palo Alto Networks firewalls to be deployed at the hub and at
every spoke. It uses cerficates for device authencaon, SSL for securing communicaon
between all components, and IPSec to secure data. See Large Scale VPN (LSVPN).
Figure 7: VPN Deployments
VPNs
Site-to-Site VPN Overview

A VPN connecon that allows you to connect two Local Area Networks (LANs) is called a site-to-
site VPN. You can configure route-based VPNs to connect Palo Alto Networks firewalls located at
two sites or to connect a Palo Alto Networks firewall with a third-party security device at another
locaon. The firewall can also interoperate with third-party policy-based VPN devices; the Palo
Alto Networks firewall supports route-based VPN.
The Palo Alto Networks firewall sets up a route-based VPN, where the firewall makes a roung
decision based on the desnaon IP address. If traffic is routed to a specific desnaon through a
VPN tunnel, then it is handled as VPN traffic.
The IP Security (IPSec) set of protocols is used to set up a secure tunnel for the VPN traffic, and
the informaon in the TCP/IP packet is secured (and encrypted if the tunnel type is ESP). The IP
packet (header and payload) is embedded in another IP payload, and a new header is applied and
then sent through the IPSec tunnel. The source IP address in the new header is that of the local
VPN peer and the desnaon IP address is that of the VPN peer on the far end of the tunnel.
When the packet reaches the remote VPN peer (the firewall at the far end of the tunnel), the
outer header is removed and the original packet is sent to its desnaon.
In order to set up the VPN tunnel, first the peers need to be authencated. Aer successful
authencaon, the peers negoate the encrypon mechanism and algorithms to secure the
communicaon. The Internet Key Exchange (IKE) process is used to authencate the VPN peers,
and IPSec Security Associaons (SAs) are defined at each end of the tunnel to secure the VPN
communicaon. IKE uses digital cerficates or preshared keys, and the Diffie Hellman keys to
set up the SAs for the IPSec tunnel. The SAs specify all of the parameters that are required for
secure transmission— including the security parameter index (SPI), security protocol, cryptographic
keys, and the desnaon IP address—encrypon, data authencaon, data integrity, and endpoint
authencaon.
The following figure shows a VPN tunnel between two sites. When a client that is secured by VPN
Peer A needs content from a server located at the other site, VPN Peer A iniates a connecon
request to VPN Peer B. If the security policy permits the connecon, VPN Peer A uses the IKE
Crypto profile parameters (IKE phase 1) to establish a secure connecon and authencate VPN
Peer B. Then, VPN Peer A establishes the VPN tunnel using the IPSec Crypto profile, which
defines the IKE phase 2 parameters to allow the secure transfer of data between the two sites.
Figure 8: Site-to-Site VPN
VPNs
Site-to-Site VPN Concepts

A VPN connecon provides secure access to informaon between two or more sites. In order
to provide secure access to resources and reliable connecvity, a VPN connecon needs the
following components:
• IKE Gateway
• Tunnel Interface
• Tunnel Monitoring
• Internet Key Exchange (IKE) for VPN
• IKEv2
IKE Gateway
The Palo Alto Networks firewalls or a firewall and another security device that iniate and
terminate VPN connecons across the two networks are called the IKE Gateways. To set up the
VPN tunnel and send traffic between the IKE Gateways, each peer must have an IP address—stac
or dynamic—or FQDN. The VPN peers use preshared keys or cerficates to mutually authencate
each other.
The peers must also negoate the mode—main or aggressive—for seng up the VPN tunnel and
the SA lifeme in IKE Phase 1. Main mode protects the identy of the peers and is more secure
because more packets are exchanged when seng up the tunnel. Main mode is the recommended
mode for IKE negoaon if both peers support it. Aggressive mode uses fewer packets to set up
the VPN tunnel and is hence faster but a less secure opon for seng up the VPN tunnel.
See Set Up an IKE Gateway for configuraon details.
Tunnel Interface
To set up a VPN tunnel, the Layer 3 interface at each end must have a logical tunnel interface
for the firewall to connect to and establish a VPN tunnel. A tunnel interface is a logical (virtual)
interface that is used to deliver traffic between two endpoints. If you configure any proxy IDs, the
proxy ID is counted toward any IPSec tunnel capacity.
The tunnel interface must belong to a security zone to apply policy and it must be assigned to a
virtual router in order to use the exisng roung infrastructure. Ensure that the tunnel interface
and the physical interface are assigned to the same virtual router so that the firewall can perform a
route lookup and determine the appropriate tunnel to use.
Typically, the Layer 3 interface that the tunnel interface is aached to belongs to an external zone,
for example the untrust zone. While the tunnel interface can be in the same security zone as the
physical interface, for added security and beer visibility, you can create a separate zone for the
tunnel interface. If you create a separate zone for the tunnel interface, say a VPN zone, you will
need to create security policies to enable traffic to flow between the VPN zone and the trust
zone.
To route traffic between the sites, a tunnel interface does not require an IP address. An IP address
is only required if you want to enable tunnel monitoring or if you are using a dynamic roung
VPNs
protocol to route traffic across the tunnel. With dynamic roung, the tunnel IP address serves as
the next hop IP address for roung traffic to the VPN tunnel.
If you are configuring the Palo Alto Networks firewall with a VPN peer that performs policy-based
VPN, you must configure a local and remote Proxy ID when seng up the IPSec tunnel. Each peer
compares the Proxy-IDs configured on it with what is actually received in the packet in order to
allow a successful IKE phase 2 negoaon. If mulple tunnels are required, configure unique Proxy
IDs for each tunnel interface; a tunnel interface can have a maximum of 250 Proxy IDs. Each Proxy
ID counts towards the IPSec VPN tunnel capacity of the firewall, and the tunnel capacity varies by
the firewall model.
See Set Up an IPSec Tunnel for configuraon details.
Tunnel Monitoring
For a VPN tunnel, you can check connecvity to a desnaon IP address across the tunnel. The
network monitoring profile on the firewall allows you to verify connecvity (using ICMP) to a
desnaon IP address or a next hop at a specified polling interval, and to specify an acon on
failure to access the monitored IP address.
If the desnaon IP is unreachable, you either configure the firewall to wait for the tunnel to
recover or configure automac failover to another tunnel. In either case, the firewall generates
a system log that alerts you to a tunnel failure and renegoates the IPSec keys to accelerate
recovery.
See Set Up Tunnel Monitoring for configuraon details.
Internet Key Exchange (IKE) for VPN

The IKE process allows the VPN peers at both ends of the tunnel to encrypt and decrypt packets
using mutually agreed-upon keys or cerficate and method of encrypon. The IKE process occurs
in two phases: IKE Phase 1 and IKE Phase 2. Each of these phases use keys and encrypon
algorithms that are defined using cryptographic profiles— IKE crypto profile and IPSec crypto
profile—and the result of the IKE negoaon is a Security Associaon (SA). An SA is a set of
mutually agreed-upon keys and algorithms that are used by both VPN peers to allow the flow of
data across the VPN tunnel. The following illustraon depicts the key exchange process for seng
up the VPN tunnel:
VPNs
IKE Phase 1
In this phase, the firewalls use the parameters defined in the IKE Gateway configuraon and the
IKE Crypto profile to authencate each other and set up a secure control channel. IKE Phase
supports the use of preshared keys or digital cerficates (which use public key infrastructure,
PKI) for mutual authencaon of the VPN peers. Preshared keys are a simple soluon for
securing smaller networks because they do not require the support of a PKI infrastructure. Digital
cerficates can be more convenient for larger networks or implementaons that require stronger
authencaon security.
When using cerficates, make sure that the CA issuing the cerficate is trusted by both gateway
peers and that the maximum length of cerficates in the cerficate chain is 5 or less. With IKE
fragmentaon enabled, the firewall can reassemble IKE messages with up to 5 cerficates in the
cerficate chain and successfully establish a VPN tunnel.
The IKE Crypto profile defines the following opons that are used in the IKE SA negoaon:
• Diffie-Hellman (DH) group for generang symmetrical keys for IKE.
The Diffie-Hellman algorithm uses the private key of one party and the public key of the other
to create a shared secret, which is an encrypted key that both VPN tunnel peers share. The DH
groups supported on the firewall are: Group 1—768 bits, Group 2—1024 bits (default), Group 5
—1536 bits, Group 14—2048 bits, Group 19—256-bit ellipc curve group, and Group 20—384-
bit ellipc curve group.
• Authencaon algorithms—sha1, sha 256, sha 384, sha 512, or md5
• Encrypon algorithms—aes-256-gcm, aes-128-gcm, 3des, aes-128-cbc, aes-192-cbc, aes-256-
cbc, or des
IKE Phase 2
Aer the tunnel is secured and authencated, in Phase 2 the channel is further secured for the
transfer of data between the networks. IKE Phase 2 uses the keys that were established in Phase
1 of the process and the IPSec Crypto profile, which defines the IPSec protocols and keys used for
the SA in IKE Phase 2.
The IPSEC uses the following protocols to enable secure communicaon:
VPNs
• Encapsulang Security Payload (ESP)—Allows you to encrypt the enre IP packet, and
authencate the source and verify integrity of the data. While ESP requires that you encrypt
and authencate the packet, you can choose to only encrypt or only authencate by seng
the encrypon opon to Null; using encrypon without authencaon is discouraged.
• Authencaon Header (AH)—Authencates the source of the packet and verifies data integrity.
AH does not encrypt the data payload and is unsuited for deployments where data privacy is
important. AH is commonly used when the main concern is to verify the legimacy of the peer,
and data privacy is not required.
Table 5: Algorithms Supported for IPSEC Authentication and Encryption
ESP AH
Diffie Hellman (DH) exchange opons supported
• Group 1—768 bits

• Group 2—1024 bits (the default)
• Group 5—1536 bits
• Group 14—2048 bits.
• Group 19— 256-bit ellipc curve group
• Group 20—384-bit ellipc curve group
• no-pfs—By default, perfect forward secrecy (PFS) is enabled, which means a new DH key is
generated in IKE phase 2 using one of the groups listed above. This key is independent of
the keys exchanged in IKE phase1 and provides beer data transfer security. If you select
no-pfs, the DH key created at phase 1 is not renewed and a single key is used for the IPSec
SA negoaons. Both VPN peers must be enabled or disabled for PFS.
Encrypon algorithms supported
• 3des Triple Data Encrypon Standard (3DES) with a security strength

of 112 bits
• aes-128-cbc Advanced Encrypon Standard (AES) using cipher block

chaining (CBC) with a security strength of 128 bits
• aes-192-cbc AES using CBC with a security strength of 192 bits
• aes-256-cbc AES using CBC with a security strength of 256 bits
• aes-128-ccm AES using Counter with CBC-MAC (CCM) with a security

strength of 128 bits
• aes-128-gcm AES using Galois/Counter Mode (GCM) with a security strength

of 128 bits
• aes-256-gcm AES using GCM with a security strength of 256 bits
VPNs
ESP AH
• des Data Encrypon Standard (DES) with a security strength of 56

bits
Authencaon algorithms supported
• md5 • md5
• sha 1 • sha 1
• sha 256 • sha 256
• sha 384 • sha 384
• sha512 • sha 512
Methods of Securing IPSec VPN Tunnels (IKE Phase 2)

IPSec VPN tunnels can be secured using manual keys or auto keys. In addion, IPSec configuraon
opons include Diffie-Hellman Group for key agreement, and/or an encrypon algorithm and a
hash for message authencaon.
• Manual Key—Manual key is typically used if the Palo Alto Networks firewall is establishing a
VPN tunnel with a legacy device, or if you want to reduce the overhead of generang session
keys. If using manual keys, the same key must be configured on both peers.
Manual keys are not recommended for establishing a VPN tunnel because the session keys
can be compromised when relaying the key informaon between the peers; if the keys are
compromised, the data transfer is no longer secure.
• Auto Key— Auto Key allows you to automacally generate keys for seng up and maintaining
the IPSec tunnel based on the algorithms defined in the IPSec Crypto profile.
IKEv2
An IPSec VPN gateway uses IKEv1 or IKEv2 to negoate the IKE security associaon (SA) and
IPSec tunnel. IKEv2 is defined in RFC 5996.
Unlike IKEv1, which uses Phase 1 SA and Phase 2 SA, IKEv2 uses a child SA for Encapsulang
Security Payload (ESP) or Authencaon Header (AH), which is set up with an IKE SA.
NAT traversal (NAT-T) must be enabled on both gateways if you have NAT occurring on a device
that sits between the two gateways. A gateway can see only the public (globally routable) IP
address of the NAT device.
IKEv2 provides the following benefits over IKEv1:
• Tunnel endpoints exchange fewer messages to establish a tunnel. IKEv2 uses four messages;
IKEv1 uses either nine messages (in main mode) or six messages (in aggressive mode).
• Built-in NAT-T funconality improves compability between vendors.
VPNs
• Built-in health check automacally re-establishes a tunnel if it goes down. The liveness check
replaces the Dead Peer Detecon used in IKEv1.
• Supports traffic selectors (one per exchange). The traffic selectors are used in IKE negoaons
to control what traffic can access the tunnel.
• Supports Hash and URL cerficate exchange to reduce fragmentaon.
• Resiliency against DoS aacks with improved peer validaon. An excessive number of half-
open SAs can trigger cookie validaon.
Before configuring IKEv2, you should be familiar with the following concepts:
• Liveness Check
• Cookie Acvaon Threshold and Strict Cookie Validaon
• Traffic Selectors
• Hash and URL Cerficate Exchange
• SA Key Lifeme and Re-Authencaon Interval
Aer you Set Up an IKE Gateway, if you chose IKEv2, perform the following oponal tasks related
to IKEv2 as required by your environment:
• Export a Cerficate for a Peer to Access Using Hash and URL
• Import a Cerficate for IKEv2 Gateway Authencaon
• Change the Key Lifeme or Authencaon Interval for IKEv2
• Change the Cookie Acvaon Threshold for IKEv2
• Configure IKEv2 Traffic Selectors
Liveness Check
The liveness check for IKEv2 is similar to Dead Peer Detecon (DPD), which IKEv1 uses as the
way to determine whether a peer is sll available.
In IKEv2, the liveness check is achieved by any IKEv2 packet transmission or an empty
informaonal message that the gateway sends to the peer at a configurable interval, five seconds
by default. If necessary, the sender aempts the retransmission up to ten mes. If it doesn’t get
a response, the sender closes and deletes the IKE_SA and corresponding CHILD_SAs. The sender
will start over by sending out another IKE_SA_INIT message.
Cookie Acvaon Threshold and Strict Cookie Validaon

Cookie validaon is always enabled for IKEv2; it helps protect against half-SA DoS aacks. You
can configure the global threshold number of half-open SAs that will trigger cookie validaon. You
can also configure individual IKE gateways to enforce cookie validaon for every new IKEv2 SA.
• The Cookie Acvaon Threshold is a global VPN session seng that limits the number of
simultaneous half-opened IKE SAs (default is 500). When the number of half-opened IKE SAs
exceeds the Cookie Acvaon Threshold, the Responder will request a cookie, and the Iniator
must respond with an IKE_SA_INIT containing a cookie to validate the connecon. If the cookie
VPNs
validaon is successful, another SA can be iniated. A value of 0 means that cookie validaon is
always on.
The Responder does not maintain a state of the Iniator, nor does it perform a Diffie-Hellman
key exchange, unl the Iniator returns the cookie. IKEv2 cookie validaon migates a DoS
aack that would try to leave numerous connecons half open.
The Cookie Acvaon Threshold must be lower than the Maximum Half Opened SA seng.
If you Change the Cookie Acvaon Threshold for IKEv2 to a very high number (for example,
65534) and the Maximum Half Opened SA seng remained at the default value of 65535,
cookie validaon is essenally disabled.
• You can enable Strict Cookie Validaon if you want cookie validaon performed for every
new IKEv2 SA a gateway receives, regardless of the global threshold. Strict Cookie Validaon
affects only the IKE gateway being configured and is disabled by default. With Strict Cookie
Validaon disabled, the system uses the Cookie Acvaon Threshold to determine whether a
cookie is needed or not.
Traffic Selectors
In IKEv1, a firewall that has a route-based VPN needs to use a local and remote Proxy ID in order
to set up an IPSec tunnel. Each peer compares its Proxy IDs with what it received in the packet in
order to successfully negoate IKE Phase 2. IKE Phase 2 is about negoang the SAs to set up an
IPSec tunnel. (For more informaon on Proxy IDs, see Tunnel Interface.)
In IKEv2, you can Configure IKEv2 Traffic Selectors, which are components of network traffic that
are used during IKE negoaon. Traffic selectors are used during the CHILD_SA (tunnel creaon)
Phase 2 to set up the tunnel and to determine what traffic is allowed through the tunnel. The two
IKE gateway peers must negoate and agree on their traffic selectors; otherwise, one side narrows
its address range to reach agreement. One IKE connecon can have mulple tunnels; for example,
you can assign different tunnels to each department to isolate their traffic. Separaon of traffic
also allows features such as QoS to be implemented.
The IPv4 and IPv6 traffic selectors are:
• Source IP address—A network prefix, address range, specific host, or wildcard.
• Desnaon IP address—A network prefix, address range, specific host, or wildcard.
• Protocol—A transport protocol, such as TCP or UDP.
• Source port—The port where the packet originated.
• Desnaon port—The port the packet is desned for.
During IKE negoaon, there can be mulple traffic selectors for different networks and
protocols. For example, the Iniator might indicate that it wants to send TCP packets from
172.168.0.0/16 through the tunnel to its peer, desned for 198.5.0.0/16. It also wants to send
UDP packets from 172.17.0.0/16 through the same tunnel to the same gateway, desned for
0.0.0.0 (any network). The peer gateway must agree to these traffic selectors so that it knows
what to expect.
It is possible that one gateway will start negoaon using a traffic selector that is a more specific
IP address than the IP address of the other gateway.
• For example, gateway A offers a source IP address of 172.16.0.0/16 and a desnaon IP
address of 192.16.0.0/16. But gateway B is configured with 0.0.0.0 (any source) as the
source IP address and 0.0.0.0 (any desnaon) as the desnaon IP address. Therefore,
VPNs
gateway B narrows down its source IP address to 192.16.0.0/16 and its desnaon address to
172.16.0.0/16. Thus, the narrowing down accommodates the addresses of gateway A and the
traffic selectors of the two gateways are in agreement.
• If gateway B (configured with source IP address 0.0.0.0) is the Iniator instead of the
Responder, gateway A will respond with its more specific IP addresses, and gateway B will
narrow down its addresses to reach agreement.
Hash and URL Cerficate Exchange

IKEv2 supports Hash and URL Cerficate Exchange, which is used during an IKEv2 negoaon of
an SA. You store the cerficate on an HTTP server, which is specified by a URL. The peer fetches
the cerficate from the server based on receiving the URL to the server. The hash is used to check
whether the content of the cerficate is valid or not. Thus, the two peers exchange cerficates
with the HTTP CA rather than with each other.
The hash part of Hash and URL reduces the message size and thus Hash and URL is a way to
reduce the likelihood of packet fragmentaon during IKE negoaon. The peer receives the
cerficate and hash that it expects, and thus IKE Phase 1 has validated the peer. Reducing
fragmentaon occurrences helps protect against DoS aacks.
You can enable the Hash and URL cerficate exchange when configuring an IKE gateway by
selecng HTTP Cerficate Exchange and entering the Cerficate URL. The peer must also use
Hash and URL cerficate exchange in order for the exchange to be successful. If the peer cannot
use Hash and URL, X.509 cerficates are exchanged similarly to how they are exchanged in IKEv1.
If you enable the Hash and URL cerficate exchange, you must export your cerficate to the
cerficate server if it is not already there. When you export the cerficate, the file format should
be Binary Encoded Cerficate (DER). See Export a Cerficate for a Peer to Access Using Hash and
URL.
SA Key Lifeme and Re-Authencaon Interval

In IKEv2, two IKE crypto profile values, Key Lifeme and IKEv2 Authencaon Mulple, control
the establishment of IKEv2 IKE SAs. The key lifeme is the length of me that a negoated IKE
SA key is effecve. Before the key lifeme expires, the SA must be re-keyed; otherwise, upon
expiraon, the SA must begin a new IKEv2 IKE SA re-key. The default value is 8 hours.
The re-authencaon interval is derived by mulplying the Key Lifeme by the IKEv2
Authencaon Mulple. The authencaon mulple defaults to 0, which disables the re-
authencaon feature.
The range of the authencaon mulple is 0-50. So, if you were to configure an authencaon
mulple of 20, for example, the system would perform re-authencaon every 20 re-keys, which
is every 160 hours. That means the gateway could perform Child SA creaon for 160 hours before
the gateway must re-authencate with IKE to recreate the IKE SA from scratch.
In IKEv2, the Iniator and Responder gateways have their own key lifeme value, and the gateway
with the shorter key lifeme is the one that will request that the SA be re-keyed.
VPNs
Set Up Site-to-Site VPN

To set up site-to-site VPN:
Make sure that your Ethernet interfaces, virtual routers, and zones are configured properly. For
more informaon, see Configure Interfaces and Zones.
Create your tunnel interfaces. Ideally, put the tunnel interfaces in a separate zone, so that
tunneled traffic can use different policies.
Set up stac routes or assign roung protocols to redirect traffic to the VPN tunnels. To
support dynamic roung (OSPF, BGP, RIP are supported), you must assign an IP address to the
tunnel interface.
Define IKE gateways for establishing communicaon between the peers across each end of the
VPN tunnel; also define the cryptographic profile that specifies the protocols and algorithms for
idenficaon, authencaon, and encrypon to be used for seng up VPN tunnels in IKEv1
Phase 1. See Set Up an IKE Gateway and Define IKE Crypto Profiles.
Configure the parameters that are needed to establish the IPSec connecon for transfer of
data across the VPN tunnel; See Set Up an IPSec Tunnel. For IKEv1 Phase-2, see Define IPSec
Crypto Profiles.
(Oponal) Specify how the firewall will monitor the IPSec tunnels. See Set Up Tunnel
Monitoring.
Define security policies to filter and inspect the traffic.
If there is a deny rule at the end of the security rulebase, intra-zone traffic is blocked
unless otherwise allowed. Rules to allow IKE and IPSec applicaons must be explicitly
included above the deny rule.
If your VPN traffic is passing through (not originang or terminang on) a PA-7000
Series or PA-5200 Series firewall, configure bi-direconal Security policy rules to allow
the ESP or AH traffic in both direcons.
When these tasks are complete, the tunnel is ready for use. Traffic desned for the zones/
addresses defined in policy is automacally routed properly based on the desnaon route in the
roung table, and handled as VPN traffic. For a few examples on site-to-site VPN, see Site-to-Site
VPN Quick Configs.
For troubleshoong purposes, you can Enable/Disable, Refresh or Restart an IKE Gateway or
IPSec Tunnel.
Set Up an IKE Gateway

To set up a VPN tunnel, the VPN peers or gateways must authencate each other—using pre-
shared keys or digital cerficates—and establish a secure channel in which to negoate the IPSec
security associaon (SA) that will be used to secure traffic between the hosts on each side.
VPNs
STEP 1 | Define the IKE Gateway.

1. Select Network > Network Profiles > IKE Gateways, Add a gateway, and enter the
gateway Name (General tab).
2. Set the Version to IKEv1 only mode, IKEv2 only mode, or IKEv2 preferred mode. The
IKE gateway begins its negoaon with its peer in the mode you specify here. If you
select IKEv2 preferred mode, the two peers will use IKEv2 if the remote peer supports it;
otherwise they will use IKEv1.
The Version you select also determines which opons are available for you to configure
on the Advanced Opons tab.
STEP 2 | Establish the local endpoint of the tunnel (gateway).

1. Select the Address Type: IPv4 or IPv6.
2. Select the physical, outgoing Interface on the firewall where the local gateway resides.
3. From the Local IP Address list, select the IP address that the VPN connecon will use as
the endpoint; this is the external-facing interface with a publicly routable IP address on
the firewall.
STEP 3 | Establish the peer at the far end of the tunnel (gateway).
For Peer IP Address Type, select one of the following and enter the corresponding informaon
for the peer:
• IP—Enter a Peer Address that is either an IPv4 or IPv6 address or enter an address object
that is an IPv4 or IPv6 address.
• FQDN—Enter a Peer Address that is an FQDN string or an address object that uses an
FQDN string. If the FQDN or FQDN address object resolves to more than one IP address,
the firewall selects the preferred address from the set of addresses that match the Address
Type (IPv4 or IPv6) of the IKE gateway as follows:
• If no IKE security associaon (SA) is negoated, the preferred address is the IP address
with the smallest value.
• If the IKE gateway uses an address that is in the set of returned addresses, the firewall
selects that address (whether or not it is the smallest address in the set).
• If the IKE gateway uses an address that isn’t in the set of returned addresses, the firewall
selects a new address, and it is the smallest address in the set.
• Dynamic—Select Dynamic if the peer IP address or FQDN value is unknown so that the
peer will iniate the negoaon.
Using an FQDN or FQDN address object reduces issues in environments where the
peer is subject to dynamic IP address changes (and would otherwise require you to
reconfigure this IKE gateway peer address).
STEP 4 | Specify how to authencate the peer.

Select the Authencaon method: Pre-Shared Key or Cerficate. If you choose a pre-shared
key, proceed to the next step. If you choose a cerficate, skip ahead to Step 6, Configure
cerficate-based authencaon.
VPNs
STEP 5 | Configure a pre-shared key.

1. Enter a Pre-shared Key, which is the security key for authencaon across the tunnel.
Re-enter the value to Confirm Pre-shared Key. Use a maximum of 255 ASCII or non-
ASCII characters.
Generate a key that is difficult to crack with diconary aacks; use a pre-shared
key generator, if necessary.
2. For Local Idenficaon, choose from the following types and enter a value that you
determine: FQDN (hostname), IP address, KEYID (binary format ID string in HEX), and
User FQDN (email address). Local idenficaon defines the format and idenficaon of
the local gateway. If you do not specify a value, the local IP address is used as the local
idenficaon value.
3. For Peer Idenficaon, choose from the following types and enter a value that you
determine: FQDN (hostname), IP address, KEYID (binary format ID string in HEX), and
User FQDN (email address). Peer idenficaon defines the format and idenficaon of
the peer gateway. If you do not specify a value, the peer IP address is used as the peer
idenficaon value.
4. Proceed to Step 7 (Configure advanced opons for the gateway).
VPNs
STEP 6 | Configure cerficate-based authencaon.

Perform the remaining steps in this procedure if you selected Cerficate as the method of
authencang the peer gateway at the opposite end of the tunnel.
1. Select a Local Cerficate—one that is already on the firewall, Import a cerficate, or
Generate a new cerficate.
• If you need to Import a cerficate, then first Import a Cerficate for IKEv2 Gateway
Authencaon and then return to this task.
• If you want to Generate a new cerficate, then first generate a cerficate on the
firewall and then return to this task.
2. (Oponal) Enable (select) the HTTP Cerficate Exchange to configure Hash and URL
(IKEv2 only). For an HTTP cerficate exchange, enter the Cerficate URL. For more
informaon, see Hash and URL Cerficate Exchange.
3. Select the Local Idenficaon type—Disnguished Name (Subject), FQDN (hostname),
IP address, or User FQDN (email address)—and then enter the value. Local idenficaon
defines the format and idenficaon of the local gateway.
4. Select the Peer Idenficaon type—Disnguished Name (Subject), FQDN (hostname),
IP address, or User FQDN (email address)—and then enter the value. Peer idenficaon
defines the format and idenficaon of the peer gateway.
5. Specify the type of Peer ID Check:
• Exact—Ensures that the local seng and peer IKE ID payload match exactly.
• Wildcard—Allows the peer idenficaon to match as long as every character before
the wildcard (*) matches. The characters aer the wildcard need not match.
6. (Oponal) Permit peer idenficaon and cerficate payload idenficaon mismatch
to allow a successful IKE SA even when the peer idenficaon does not match the peer
idenficaon in the cerficate.
7. Choose a Cerficate Profile. A cerficate profile contains informaon about how to
authencate the peer gateway.
8. (Oponal) Enable strict validaon of peer’s extended key use to strictly control how the
key can be used.
VPNs
STEP 7 | Configure advanced opons for the gateway.

1. (Oponal) Enable Passive Mode in the Common Opons (Advanced Opons) to specify
that the firewall only respond to IKE connecon requests and never iniate them.
2. If you have a device performing NAT between the gateways, Enable NAT Traversal to
use UDP encapsulaon on IKE and UDP protocols, which enables them to pass through
intermediate NAT devices.
3. If you configured IKEv1 only mode in Step 1, then, on the IKEv1 tab:
• Select the Exchange Mode: auto, aggressive, or main. When you set a firewall to use
auto exchange mode, it can accept both main mode and aggressive mode negoaon
requests; however, when possible, it will iniate exchanges in main mode.
If you do not set the exchange mode to auto, then you must configure both
peers with the same exchange mode to allow each peer to accept negoaon
requests.
• Select an exisng profile or keep the default profile from the IKE Crypto Profile list. If
needed, you can Define IKE Crypto Profiles.
• (Only when using cerficate-based authencaon and when exchange mode is not
set to aggressive mode) Click Enable Fragmentaon to enable the firewall to operate
with IKE Fragmentaon.
• Click Dead Peer Detecon and enter an Interval (range is 2 to 100 seconds). For
Retry, define the me to delay (range is 2 to 100 seconds) before aempng to
re-check availability. Dead peer detecon idenfies inacve or unavailable IKE
peers by sending an IKE phase 1 noficaon payload to the peer and waing for an
acknowledgment.
4. If you configured IKEv2 only mode or IKEv2 preferred mode in Step 1, then on the IKEv2
tab:
• Select an IKE Crypto Profile, which configures IKE Phase 1 opons such, as the DH
group, hash algorithm, and ESP authencaon. For informaon about IKE crypto
profiles, see IKE Phase 1.
• (Oponal) Enable Strict Cookie Validaon Cookie Acvaon Threshold and Strict
Cookie Validaon.
• (Oponal) Enable Liveness Check and enter an Interval (sec) (default is 5) if you
want to have the gateway send a message request to its gateway peer, requesng a
response. If necessary, the Iniator aempts the liveness check as many as 10 mes.
If it doesn’t get a response, the Iniator closes and deletes the IKE_SA and CHILD_SA.
The Iniator will start over by sending out another IKE_SA_INIT.
Export a Cerficate for a Peer to Access Using Hash and URL

IKEv2 supports Hash and URL Cerficate Exchange as a method of having the peer at the remote
end of the tunnel fetch the cerficate from a server where you have exported the cerficate.
Perform this task to export your cerficate to that server. You must have already created a
cerficate using Device > Cerficate Management.
VPNs
STEP 1 | Select Device > Cerficates, and if your plaorm supports mulple virtual systems, for
Locaon, select the appropriate virtual system.
STEP 2 | On the Device Cerficates tab, select the cerficate to Export to the server.
The status of the cerficate should be valid, not expired. The firewall will not stop you
from exporng an invalid cerficate.
STEP 3 | For File Format, select Binary Encoded Cerficate (DER).
STEP 4 | Leave Export private key clear. Exporng the private key is unnecessary for Hash and URL.
STEP 5 | Click OK.
Import a Cerficate for IKEv2 Gateway Authencaon

Perform this task if you are authencang a peer for an IKEv2 gateway and you did not use a local
cerficate already on the firewall; you want to import a cerficate from elsewhere.
This task presumes that you selected Network > IKE Gateways, added a gateway, and for Local
Cerficate, you clicked Import.
STEP 1 | Import a cerficate.
1. Select Network > IKE Gateways, Add a gateway, and on the General tab, for
Authencaon, select Cerficate. For Local Cerficate, click Import.
2. In the Import Cerficate window, enter a Cerficate Name for the cerficate you are
imporng.
3. Select Shared if this cerficate is to be shared among mulple virtual systems.
4. For Cerficate File, Browse to the cerficate file. Click on the file name and click Open,
which populates the Cerficate File field.
5. For File Format, select one of the following:
• Base64 Encoded Cerficate (PEM)—Contains the cerficate, but not the key. It is
cleartext.
• Encrypted Private Key and Cerficate (PKCS12)—Contains both the cerficate and
the key.
6. Select Import private key if the key is in a different file from the cerficate file. The key is
oponal, with the following excepon:
• You must import a key if you set the File Format to PEM. Enter a Key file by clicking
Browse and navigang to the key file to import.
• Enter a Passphrase and Confirm Passphrase.
7. Click OK.
STEP 2 | Connue to the next task.

Step Configure cerficate-based authencaon.
VPNs
Change the Key Lifeme or Authencaon Interval for IKEv2

This task is oponal; the default seng of the IKEv2 IKE SA re-key lifeme is 8 hours. The
default seng of the IKEv2 Authencaon Mulple is 0, meaning the re-authencaon feature is
disabled. For more informaon, see SA Key Lifeme and Re-Authencaon Interval.
To change the default values, perform the following task. A prerequisite is that an IKE crypto
profile already exists.
STEP 1 | Change the SA key lifeme or authencaon interval for an IKE Crypto profile.
1. Select Network > Network Profiles > IKE Crypto and select the IKE Crypto profile that
applies to the local gateway.
2. For the Key Lifeme, select a unit (Seconds, Minutes, Hours, or Days) and enter a value.
The minimum is three minutes.
3. For IKE Authencaon Mulple, enter a value, which is mulplied by the lifeme to
determine the re-authencaon interval.

Change the Cookie Acvaon Threshold for IKEv2

Perform the following task if you want a firewall to have a threshold different from the default
seng of 500 half-opened SA sessions before cookie validaon is required. For more informaon
about cookie validaon, see Cookie Acvaon Threshold and Strict Cookie Validaon.
STEP 1 | Change the Cookie Acvaon Threshold.
1. Select Device > Setup > Session and edit the VPN Session Sengs. For Cookie
Acvaon Threshold, enter the maximum number of half-opened SAs that are allowed
before the responder requests a cookie from the iniator (range is 0-65,535; default is
500).
2. Click OK.

Configure IKEv2 Traffic Selectors

In IKEv2, you can configure Traffic Selectors, which are components of network traffic that are
used during IKE negoaon. Traffic selectors are used during the CHILD_SA (tunnel creaon)
Phase 2 to set up the tunnel and to determine what traffic is allowed through the tunnel. The two
IKE gateway peers must negoate and agree on their traffic selectors; otherwise, one side narrows
its address range to reach agreement. One IKE connecon can have mulple tunnels; for example,
you can assign different tunnels to each department to isolate their traffic. Separaon of traffic
also allows features such as QoS to be implemented. Use the following workflow to configure
traffic selectors.
STEP 1 | Select Network > IPSec Tunnels > Proxy IDs.
STEP 2 | Select the IPv4 or IPv6 tab.
VPNs
STEP 3 | Click Add and enter the Name in the Proxy ID field.
STEP 4 | In the Local field, enter the Source IP Address.
STEP 5 | In the Remote field, enter the Desnaon IP Address.
STEP 6 | In the Protocol field, select the transport protocol (TCP or UDP).
STEP 7 | Click OK.
Define Cryptographic Profiles

A cryptographic profile specifies the ciphers used for authencaon and/or encrypon between
two IKE peers, and the lifeme of the key. The me period between each renegoaon is known
as the lifeme; when the specified me expires, the firewall renegoates a new set of keys.
For securing communicaon across the VPN tunnel, the firewall requires IKE and IPSec
cryptographic profiles for compleng IKE phase 1 and phase 2 negoaons, respecvely. The
firewall includes a default IKE crypto profile and a default IPSec crypto profile that are ready for
use.
• Define IKE Crypto Profiles
• Define IPSec Crypto Profiles
Define IKE Crypto Profiles

The IKE crypto profile is used to set up the encrypon and authencaon algorithms used for the
key exchange process in IKE Phase 1, and lifeme of the keys, which specifies how long the keys
are valid. To invoke the profile, you must aach it to the IKE Gateway configuraon.
All IKE gateways configured on the same interface or local IP address must use the same
crypto profile when the IKE gateway’s Peer IP Address Type is configured as Dynamic and
IKEv1 main mode or IKEv2 is applied.
STEP 1 | Create a new IKE profile.

1. Select Network > Network Profiles > IKE Crypto and select Add.
2. Enter a Name for the new profile.
VPNs
STEP 2 | Specify the DH (Diffie–Hellman) Group for key exchange and the Authencaon and
Encrypon algorithms.
Click Add in the corresponding secons (DH Group, Authencaon, and Encrypon) and select
from the menus.
If you are not certain what the VPN peers support, add mulple groups or algorithms in the
order of most-to-least secure; the peers negoate the strongest supported group or algorithm
to establish the tunnel.
• DH Group—
• group20
• group19
• group14
• group5
• group2
• group1
• Authencaon—
• sha512
• sha384
• sha256
• sha1
• md5
• (PAN-OS 10.0.3 and later 10.1 releases) none
If you select an AES-GCM algorithm for encrypon, you must select the
Authencaon seng none or the commit will fail. The hash is automacally
selected based on the DH Group selected. DH Group 19 and below uses sha256;
DH Group 20 uses sha384.
• Encrypon—
• (PAN-OS 10.0.3 and later 10.1 releases) aes-256-gcm (requires IKEv2; DH Group should
be set to group20)
• (PAN-OS 10.0.3 and later 10.1 releases) aes-128-gcm (requires IKEv2 and DH Group set
to group19)
• aes-256-cbc
• aes-192-cbc
• aes-128-cbc
• 3des
• des
VPNs
Choose the strongest authencaon and encrypon algorithms the peer can support.
For the authencaon algorithm, use SHA-256 or higher (SHA-384 or higher preferred
for long-lived transacons). Do not use SHA-1 or MD5. For the encrypon algorithm,
use AES; DES and 3DES are weak and vulnerable. AES with Galois/Counter Mode
(AES-GCM) provides the strongest security and has built-in authencaon, so you must
set Authencaon to none if you select aes-256-gcm or aes-128-gcm encrypon.
STEP 3 | Specify the duraon for which the key is valid and the re-authencaon interval.
For details, see SA Key Lifeme and Re-Authencaon Interval.
1. In the Key Lifeme fields, specify the period (in seconds, minutes, hours, or days) for
which the key is valid (range is 3 minutes to 365 days; default is 8 hours). When the
key expires, the firewall renegoates a new key. A lifeme is the period between each
renegoaon.
2. For the IKEv2 Authencaon Mulple, specify a value (range is 0-50; default is 0) that is
mulplied by the Key Lifeme to determine the authencaon count. The default value
of 0 disables the re-authencaon feature.
STEP 4 | Commit your IKE Crypto profile.

Click OK and click Commit.
STEP 5 | Aach the IKE Crypto profile to the IKE Gateway configuraon.
See Configure advanced opons for the gateway.
Define IPSec Crypto Profiles

The IPSec crypto profile is invoked in IKE Phase 2. It specifies how the data is secured within the
tunnel when Auto Key IKE is used to automacally generate keys for the IKE SAs.
VPNs
STEP 1 | Create a new IPSec profile.

1. Select Network > Network Profiles > IPSec Crypto and select Add.
2. Enter a Name for the new profile.
3. Select the IPSec Protocol—ESP or AH—that you want to apply to secure the data as it
traverses across the tunnel.
As a best pracce, select ESP (Encapsulang Security payload) over AH

(Authencaon Header) because ESP offers both confidenality and
authencaon for the connecon whereas AH offers only authencaon.
4. Click Add and select the Authencaon and Encrypon algorithms for ESP, and
Authencaon algorithms for AH, so that the IKE peers can negoate the keys for the
secure transfer of data across the tunnel.
If you are not certain of what the IKE peers support, add mulple algorithms in the order
of most-to-least secure as follows; the peers negoate the strongest supported algorithm
to establish the tunnel:
• Encrypon—aes-256-gcm, aes-256-cbc, aes-192-cbc, aes-128-gcm, aes-128-ccm
(the VM-Series firewall doesn’t support this opon), aes-128-cbc, 3des, des.
As a best pracce, choose the strongest authencaon and encrypon

algorithms the peer can support. For the authencaon algorithm, use
SHA-256 or higher (SHA-384 or higher preferred for long-lived transacons).
Do not use SHA-1, MD5 or none. For the encrypon algorithm, use AES; DES
and 3DES are weak and vulnerable.
• Authencaon—sha512, sha384, sha256, sha1, md5.
STEP 2 | Select the DH Group to use for the IPSec SA negoaons in IKE phase 2.
From DH Group, select the key strength you want to use: group1, group2, group5, group14,
group19, or group20. For highest security, choose the group with the highest number.
If you don’t want to renew the key that the firewall creates during IKE phase 1, select no-
pfs (no perfect forward secrecy); the firewall reuses the current key for the IPSec security
associaon (SA) negoaons.
STEP 3 | Specify the duraon of the key—me and volume of traffic.

Using a combinaon of me and traffic volume allows you to ensure safety of data.
Select the Lifeme or me period for which the key is valid in seconds, minutes, hours, or days
(range is 3 minutes to 365 days). When the specified me expires, the firewall will renegoate
a new set of keys.
Select the Lifesize or volume of data aer which the keys must be renegoated.
STEP 4 | Commit your IPSec profile.

Click OK and click Commit.
STEP 5 | Aach the IPSec Profile to an IPSec tunnel configuraon.

See Set up key exchange.
VPNs
Set Up an IPSec Tunnel

The IPSec tunnel configuraon allows you to authencate and/or encrypt the data (IP packet) as it
traverses the tunnel.
If you are seng up the firewall to work with a peer that supports policy-based VPN, you must
define Proxy IDs. Devices that support policy-based VPN use specific security rules/policies or
access-lists (source addresses, desnaon addresses and ports) for perming interesng traffic
through an IPSec tunnel. These rules are referenced during quick mode/IKE phase 2 negoaon,
and are exchanged as Proxy-IDs in the first or the second message of the process. So, if you
are configuring the firewall to work with a policy-based VPN peer, for a successful phase 2
negoaon you must define the Proxy-ID so that the seng on both peers is idencal. If the
Proxy-ID is not configured, because the firewall supports route-based VPN, the default values
used as Proxy-ID are source ip: 0.0.0.0/0, desnaon ip: 0.0.0.0/0 and applicaon: any; and when
these values are exchanged with the peer, it results in a failure to set up the VPN connecon.
STEP 1 | Select Network > IPSec Tunnels and then Add a new tunnel configuraon.
STEP 2 | On the General tab, enter a Name for the tunnel.
STEP 3 | Select the Tunnel interface on which to set up the IPSec tunnel.
To create a new tunnel interface:
1. Select Tunnel Interface > New Tunnel Interface. (You can also select Network >
Interfaces > Tunnel and click Add.)
2. In the Interface Name field, specify a numeric suffix, such as .2.
3. On the Config tab, select the Security Zone list to define the zone as follows:
Use your trust zone as the terminaon point for the tunnel—Select the zone. Associang the
tunnel interface with the same zone (and virtual router) as the external-facing interface on
which the packets enter the firewall migates the need to create inter-zone roung.
Or:
Create a separate zone for VPN tunnel terminaon (Recommended)—Select New Zone, define
a Name for the new zone (for example vpn-corp), and click OK.
1. For Virtual Router, select default.
2. (Oponal) If you want to assign an IPv4 address to the tunnel interface, select the IPv4
tab, and Add the IP address and network mask, for example 10.31.32.1/32.
3. Click OK.
STEP 4 | (Oponal) Enable IPv6 on the tunnel interface.

1. Select the IPv6 tab on Network > Interfaces > Tunnel > IPv6.
2. Select Enable IPv6 on the interface.
This opon allows you to route IPv6 traffic over an IPv4 IPSec tunnel and will provide
confidenality between IPv6 networks. The IPv6 traffic is encapsulated by IPv4 and then
VPNs
ESP. To route IPv6 traffic to the tunnel, you can use a stac route to the tunnel, or use
OSPFv3, or use a Policy-Based Forwarding (PBF) rule.
3. Enter the 64-bit extended unique Interface ID in hexadecimal format, for example,
00:26:08:FF:FE:DE:4E:29. By default, the firewall will use the EUI-64 generated from the
physical interface’s MAC address.
4. To assign an IPv6 Address to the tunnel interface, Add the IPv6 address and prefix
length, for example 2001:400:f00::1/64. If Prefix is not selected, the IPv6 address
assigned to the interface will be wholly specified in the address text box.
1. Select Use interface ID as host poron to assign an IPv6 address to the interface that
will use the interface ID as the host poron of the address.
2. Select Anycast to include roung through the nearest node.
STEP 5 | Set up key exchange.

On the General tab, configure one of the following types of key exchange:
Set up Auto Key exchange
1. Select the IKE Gateway. To set up an IKE gateway, see Set Up an IKE Gateway.
2. (Oponal) Select the default IPSec Crypto Profile. To create a new IPSec Profile, see
Define IPSec Crypto Profiles.
Set up Manual Key exchange
1. Specify the Local SPI for the local firewall. SPI is a 32-bit hexadecimal index that is added
to the header for IPSec tunneling to assist in differenang between IPSec traffic flows;
it is used to create the SA required for establishing a VPN tunnel.
2. Select the Interface that will be the tunnel endpoint, and oponally select the IP address
for the local interface that is the endpoint of the tunnel.
3. Select the protocol to be used—AH or ESP.
4. For AH, select the Authencaon method and enter a Key and then Confirm Key.
5. For ESP, select the Authencaon method and enter a Key and then Confirm Key. Then,
select the Encrypon method and enter a Key and then Confirm Key, if needed.
6. Specify the Remote SPI for the remote peer.
7. Enter the Remote Address, the IP address of the remote peer.
STEP 6 | Protect against a replay aack.

An-replay is a sub-protocol of IPSec and is part of the Internet Engineering Task Force (IETF)
Request for Comments (RFC) 6479. The an-replay protocol is used to prevent hackers from
injecng or making changes in packets that travel from a source to a desnaon and uses
a unidireconal security associaon in order to establish a secure connecon between two
nodes in the network.
Aer a secure connecon is established, the an-replay protocol uses packet sequence
numbers to defeat replay aacks. When the source sends a message, it adds a sequence
number to its packet; the sequence number starts at 0 and is incremented by 1 for each
subsequent packet. The desnaon maintains the sequence of numbers in a sliding window
format, maintains a record of the sequence numbers of validated received packets, and rejects
all packets that have a sequence number that is lower than the lowest in the sliding window
VPNs
(packets that are too old) or packets that already appear in the sliding window (duplicate or
replayed packets). Accepted packets, aer they are validated, update the sliding window,
displacing the lowest sequence number out of the window if it was already full.
1. On the General tab, select Show Advanced Opons and select Enable Replay Protecon
to detect and neutralize against replay aacks.
2. Select the An Replay Window to use. You can select a an-replay window size of 64,
128, 256, 512, 1024, 2048, or 4096. The default is 1024.
STEP 7 | (Oponal) Preserve the Type of Service header for the priority or treatment of IP packets.
In the Show Advanced Opons secon, select Copy TOS Header. This copies the Type of
Service (TOS) header from the inner IP header to the outer IP header of the encapsulated
packets in order to preserve the original TOS informaon.
If there are mulple sessions inside the tunnel (each with a different TOS value),
copying the TOS header can cause the IPSec packets to arrive out of order.
STEP 8 | (Oponal) Select Add GRE Encapsulaon to enable GRE over IPSec.
Add GRE encapsulaon in cases where the remote endpoint requires traffic to be encapsulated
within a GRE tunnel before IPSec encrypts the traffic. For example, some implementaons
require mulcast traffic to be encapsulated before IPSec encrypts it. Add GRE Encapsulaon
when the GRE packet encapsulated in IPSec has the same source IP address and desnaon IP
address as the encapsulang IPSec tunnel.
STEP 9 | Enable Tunnel Monitoring.
You must assign an IP address to the tunnel interface for monitoring.
To alert the device administrator to tunnel failures and to provide automac failover to another
tunnel interface:
1. Select Tunnel Monitor.
2. Specify a Desnaon IP address on the other side of the tunnel to determine if the
tunnel is working properly.
3. Select a Profile to determine the acon upon tunnel failure. To create a new profile, see
Define a Tunnel Monitoring Profile.
VPNs
STEP 10 | Create a Proxy ID to idenfy the VPN peers.

This step is required only if the VPN peer uses policy-based VPN.
1. Select Network > IPSec Tunnels and click Add.
2. Select the Proxy IDs tab.
3. Select the IPv4 or IPv6 tab.
4. Click Add and enter the Proxy ID name.
5. Enter the Local IP address or subnet for the VPN gateway.
6. Enter the Remote address for the VPN gateway.
7. Select the Protocol:
• Number—Specify the protocol number (used for interoperability with third-party
devices).
• Any—Allows TCP and/or UDP traffic.
• TCP—Specify the Local Port and Remote Port numbers.
• UDP—Specify the Local Port and Remote Port numbers.
8. Click OK.

Set Up Tunnel Monitoring

To provide uninterrupted VPN service, you can use the Dead Peer Detecon capability along with
the tunnel monitoring capability on the firewall. You can also monitor the status of the tunnel.
These monitoring tasks are described in the following secons:
• Define a Tunnel Monitoring Profile
• View the Status of the Tunnels
Define a Tunnel Monitoring Profile

A tunnel monitoring profile allows you to verify connecvity between the VPN peers; you can
configure the tunnel interface to ping a desnaon IP address at a specified interval and specify
the acon if the communicaon across the tunnel is broken.
STEP 1 | Select Network > Network Profiles > Monitor. A default tunnel monitoring profile is
available for use.
STEP 2 | Click Add, and enter a Name for the profile.
STEP 3 | Select the Acon to take if the desnaon IP address is unreachable.

• Wait Recover—the firewall waits for the tunnel to recover. It connues to use the tunnel
interface in roung decisions as if the tunnel were sll acve.
• Fail Over—forces traffic to a back-up path if one is available. The firewall disables the tunnel
interface, and thereby disables any routes in the roung table that use the interface.
In either case, the firewall aempts to accelerate the recovery by negoang new IPSec keys.
VPNs
STEP 4 | Specify the Interval (sec) and Threshold to trigger the specified acon.
• Threshold specifies the number of heartbeats to wait before taking the specified acon
(range is 2-100; default is 5).
• Interval (sec) specifies the me (in seconds) between heartbeats (range is 2-10; default is 3).
STEP 5 | Aach the monitoring profile to the IPsec Tunnel configuraon. See Enable Tunnel
Monitoring.
View the Status of the Tunnels

The status of the tunnel informs you about whether or not valid IKE phase-1 and phase-2 SAs
have been established, and whether the tunnel interface is up and available for passing traffic.
Because the tunnel interface is a logical interface, it cannot indicate a physical link status.
Therefore, you must enable tunnel monitoring so that the tunnel interface can verify connecvity
to an IP address and determine if the path is sll usable. If the IP address is unreachable, the
firewall will either wait for the tunnel to recover or failover. When a failover occurs, the exisng
tunnel is torn down and roung changes are triggered to set up a new tunnel and redirect traffic.
STEP 1 | Select Network > IPSec Tunnels.
STEP 2 | View the Tunnel Status.

• Green indicates a valid IPSec SA tunnel.
• Red indicates that IPSec SA is not available or has expired.
STEP 3 | View the IKE Gateway Status.

• Green indicates a valid IKE phase-1 SA.
• Red indicates that IKE phase-1 SA is not available or has expired.
STEP 4 | View the Tunnel Interface Status.

• Green indicates that the tunnel interface is up.
• Red indicates that the tunnel interface is down, because tunnel monitoring is enabled and
the status is down.
To troubleshoot a VPN tunnel that is not yet up, see Interpret VPN Error Messages.
Enable/Disable, Refresh or Restart an IKE Gateway or IPSec Tunnel

You can enable, disable, refresh or restart an IKE gateway or VPN tunnel to make troubleshoong
easier.
• Enable or Disable an IKE Gateway or IPSec Tunnel
• Refresh and Restart Behaviors
• Refresh or Restart an IKE Gateway or IPSec Tunnel
Enable or Disable an IKE Gateway or IPSec Tunnel

Enable or disable an IKE gateway or IPSec tunnel to make troubleshoong easier.
VPNs
Enable or disable an IKE gateway.

1. Select Network > Network Profiles > IKE Gateways and select the gateway you want to
enable or disable.
2. At the boom of the screen, click Enable or Disable.
Enable or disable an IPSec tunnel.

1. Select Network > IPSec Tunnels and select the tunnel you want to enable or disable.
2. At the boom of the screen, click Enable or Disable.
Refresh and Restart Behaviors

You can Refresh or Restart an IKE Gateway or IPSec Tunnel. The refresh and restart behaviors for
an IKE gateway and IPSec tunnel are as follows:
Phase Refresh Restart
IKE Updates the onscreen stascs for Restarts the selected IKE gateway.
Gateway the selected IKE gateway.
IKEv2: Also restarts any associated child
(IKE Phase
Equivalent to issuing a second show IPSec security associaons (SAs).
1)
command in the CLI (aer an inial
IKEv1: Does not restart the associated
show command).
IPSec SAs.
A restart is disrupve to all exisng
sessions.
Equivalent to issuing a clear, test,
show command sequence in the CLI.
IPSec Updates the onscreen stascs for Restarts the IPSec tunnel.
Tunnel the selected IPSec tunnel.
A restart is disrupve to all exisng
(IKE Phase
Equivalent to issuing a second show sessions.
2)
command in the CLI (aer an inial
Equivalent to issuing a clear, test,
show command).
show command sequence in the CLI.
Refresh or Restart an IKE Gateway or IPSec Tunnel

Keep in mind that the result of restarng an IKE gateway depends on whether it is IKEv1 or IKEv2.
See Refresh and Restart Behaviors for an IKE gateway (IKEv1 and IKEv2) and for an IPSec tunnel.
VPNs
Refresh or restart an IKE gateway.

1. Select Network > IPSec Tunnels and select the tunnel for the gateway you want to
refresh or restart.
2. In the row for that tunnel, under the Status column, click IKE Info.
3. At the boom of the IKE Info screen, click the acon you want:
• Refresh—Updates the stascs on the screen.
• Restart—Clears the SAs, so traffic is dropped unl the IKE negoaon starts over and
the tunnel is recreated.
Refresh or restart an IPSec tunnel.

You might determine that the tunnel needs to be refreshed or restarted because you use
the tunnel monitor to monitor the tunnel status, or you use an external network monitor to
monitor network connecvity through the IPSec tunnel.
1. Select Network > IPSec Tunnels and select the tunnel you want to refresh or restart.
2. In the row for that tunnel, under the Status column, click Tunnel Info.
3. At the boom of the Tunnel Info screen, click the acon you want:
• Refresh—Updates the onscreen stascs.
• Restart—Clears the SAs, so traffic is dropped unl the IKE negoaon starts over and
the tunnel is recreated.
Test VPN Connecvity

Perform this task to test VPN connecvity.
STEP 1 | Iniate IKE phase 1 by either pinging a host across the tunnel or using the following CLI
command:
test vpn ike-sa gateway <gateway_name>
STEP 2 | Enter the following command to test if IKE phase 1 is set up:
show vpn ike-sa gateway <gateway_name>
In the output, check whether the Security Associaon displays. If it doesn’t, review the system
log messages to interpret the reason for failure.
STEP 3 | Iniate IKE phase 2 by either pinging a host from across the tunnel or using the following CLI
command:
test vpn ipsec-sa tunnel <tunnel_name>
VPNs
STEP 4 | Enter the following command to test if IKE phase 2 is set up:
show vpn ipsec-sa tunnel <tunnel_name>
In the output, check whether the Security Associaon displays. If it doesn’t, review the system
log messages to interpret the reason for failure.
STEP 5 | To view the VPN traffic flow informaon, use the following command:
show vpn flow

total tunnels configured: 1
filter - type IPSec, state any
total IPSec tunnel configured: 1

total IPSec tunnel shown: 1
name id state local-ip peer-ip

tunnel-i/f
-----------------------------------------------------------------------------
vpn-to-siteB 5 active
100.1.1.1 200.1.1.1 tunnel.41
Interpret VPN Error Messages

The following table lists some of the common VPN error messages that are logged in the system
log.
Table 6: Syslog Error Messages for VPN Issues
If error is this: Try this:
IKE phase-1 negotiation is failed • Verify that the public IP address

as initiator, main mode. Failed for each VPN peer is accurate in
SA: x.x.x.x[500]-y.y.y.y[500] the IKE Gateway configuraon.
cookie:84222f276c2fa2e9:0000000000000000 • Verify that the IP addresses can
due to timeout. be pinged and that roung issues
or are not causing the connecon
failure.
IKE phase 1 negotiation is failed.
Couldn’t find configuration for
IKE phase-1 request for peer IP
x.x.x.x[1929]
Received unencrypted notify payload (no Check the IKE Crypto profile
proposal chosen) from IP x.x.x.x[500] to configuraon to verify that the
y.y.y.y[500], ignored... proposals on both sides have a
common encrypon, authencaon,
or and DH Group proposal.
VPNs
If error is this: Try this:

IKE phase-1 negotiation is failed.
Unable to process peer’s SA payload.
pfs group mismatched:my: 2peer: 0 Check the IPSec Crypto profile

configuraon to verify that:
or
• pfs is either enabled or disabled
IKE phase-2 negotiation failed when
on both VPN peers
processing SA payload. No suitable
proposal found in peer’s SA payload. • the DH Groups proposed by each
peer has at least one DH Group
in common
IKE phase-2 negotiation failed when The VPN peer on one end is using
processing Proxy ID. Received local id policy-based VPN. You must
x.x.x.x/x type IPv4 address protocol configure a Proxy ID on the Palo
0 port 0, received remote id y.y.y.y/y Alto Networks firewall. See Create a
type IPv4 address protocol 0 port 0. Proxy ID to idenfy the VPN peers..
VPNs
Site-to-Site VPN Quick Configs

The following secons provide instrucons for configuring some common VPN deployments:
• Site-to-Site VPN with Stac Roung
• Site-to-Site VPN with OSPF
• Site-to-Site VPN with Stac and Dynamic Roung
Site-to-Site VPN with Stac Roung

The following example shows a VPN connecon between two sites that use stac routes.
Without dynamic roung, the tunnel interfaces on VPN Peer A and VPN Peer B do not require
an IP address because the firewall automacally uses the tunnel interface as the next hop for
roung traffic across the sites. However, to enable tunnel monitoring, a stac IP address has been
assigned to each tunnel interface.
VPNs
STEP 1 | Configure a Layer 3 interface.

This interface is used for the IKE phase-1 tunnel.
1. Select Network > Interfaces > Ethernet and then select the interface you want to
configure for VPN.
2. Select Layer3 from the Interface Type.
3. On the Config tab, select the Security Zone to which the interface belongs:
• The interface must be accessible from a zone outside of your trust network. Consider
creang a dedicated VPN zone for visibility and control over your VPN traffic.
• If you have not yet created the zone, select New Zone from the Security Zone, define
a Name for the new zone and then click OK.
4. Select the Virtual Router to use.
192.168.210.26/24.
In this example, the configuraon for VPN Peer A is:
• Interface—ethernet1/7
• Security Zone—untrust
• Virtual Router—default
• IPv4—192.168.210.26/24
The configuraon for VPN Peer B is:
• IPv4—192.168.210.120/24
VPNs
STEP 2 | Create a tunnel interface and aach it to a virtual router and security zone.
1. Select Network > Interfaces > Tunnel and click Add.
3. On the Config tab, expand the Security Zone to define the zone as follows:
• To use your trust zone as the terminaon point for the tunnel, select the zone.
• (Recommended) To create a separate zone for VPN tunnel terminaon, click New
Zone. In the Zone dialog, define a Name for new zone (for example vpn-tun), and then
click OK.
4. Select the Virtual Router.
5. (Oponal) Assign an IP address to the tunnel interface, select the IPv4 or IPv6 tab,
click Add in the IP secon, and enter the IP address and network mask to assign to the
interface.
With stac routes, the tunnel interface does not require an IP address. For traffic that is
desned to a specified subnet/IP address, the tunnel interface will automacally become
the next hop. Consider adding an IP address if you want to enable tunnel monitoring.
• Interface—tunnel.10
• Security Zone—vpn_tun
• IPv4—172.19.9.2/24
• IPv4—192.168.69.2/24
STEP 3 | Configure a stac route, on the virtual router, to the desnaon subnet.
1. Select Network > Virtual Router and click the router you defined in the prior step.
2. Select Stac Route, click Add, and enter a new route to access the subnet that is at the
other end of the tunnel.
• Desnaon—192.168.69.0/24
• Desnaon—172.19.9.0/24
VPNs
STEP 4 | Set up the Crypto profiles (IKE Crypto profile for phase 1 and IPSec Crypto profile for phase
2).
Complete this task on both peers and make sure to set idencal values.
1. Select Network > Network Profiles > IKE Crypto. In this example, we use the default
profile.
2. Select Network > Network Profiles > IPSec Crypto. In this example, we use the default
profile.
STEP 5 | Set up the IKE Gateway.

1. Select Network > Network Profiles > IKE Gateway.
2. Click Add and configure the opons in the General tab.
• Local IP address—192.168.210.26/24
• Peer IP type/address—stac/192.168.210.120
• Preshared keys—enter a value
• Local idenficaon—None; this means that the local IP address will be used as the
local idenficaon value.
• The configuraon for VPN Peer B is:
• Local IP address—192.168.210.120/24
• Peer IP type/address—stac/192.168.210.26
• Preshared keys—enter same value as on Peer A
• Local idenficaon—None
3. Select Advanced Phase 1 Opons and select the IKE Crypto profile you created earlier to
use for IKE phase 1.
VPNs
STEP 6 | Set up the IPSec Tunnel.

1. Select Network > IPSec Tunnels.
• Tunnel Interface—tunnel.10
• Type—Auto Key
• IKE Gateway—Select the IKE Gateway defined above.
• IPSec Crypto Profile—Select the IPSec Crypto profile defined in Step 4.
• Type—Auto Key
• IPSec Crypto Profile—Select the IPSec Crypto defined in Step 4.
3. (Oponal) Select Show Advanced Opons, select Tunnel Monitor, and specify a
Desnaon IP address to ping for verifying connecvity. Typically, the tunnel interface IP
address for the VPN Peer is used.
4. (Oponal) To define the acon on failure to establish connecvity, see Define a Tunnel
Monitoring Profile.
STEP 7 | Create policies to allow traffic between the sites (subnets).

2. Create rules to allow traffic between the untrust and the vpn-tun zone and the vpn-
tun and the untrust zone for traffic originang from specified source and desnaon IP
addresses.
STEP 8 | Commit any pending configuraon changes.

Click Commit.
STEP 9 | Test VPN Connecvity.

See also View the Status of the Tunnels.
Site-to-Site VPN with OSPF

In this example, each site uses OSPF for dynamic roung of traffic. The tunnel IP address on each
VPN peer is stacally assigned and serves as the next hop for roung traffic between the two
sites.
VPNs
STEP 1 | Configure the Layer 3 interfaces on each firewall.

configure for VPN.
2. Select Layer3 from the Interface Type list.
• If you have not yet created the zone, select New Zone from the Security Zone list,
define a Name for the new zone and then click OK.
192.168.210.26/24.
• IPv4—100.1.1.1/24
• IPv4—200.1.1.1/24
VPNs
2. In the Interface Name field, specify a numeric suffix, such as, .11.
3. On the Config tab, expand Security Zone to define the zone as follows:
Zone. In the Zone dialog, define a Name for new zone (for example, vpn-tun), and
then click OK.
5. Assign an IP address to the tunnel interface, select the IPv4 or IPv6 tab, click Add in the
IP secon, and enter the IP address and network mask/prefix to assign to the interface,
for example, 172.19.9.2/24.
This IP address will be used as the next hop IP address to route traffic to the tunnel and
can also be used to monitor the status of the tunnel.
• IPv4—2.1.1.141/24
• IPv4—2.1.1.140/24
2).
profile.
profile.
VPNs
STEP 4 | Set up the OSPF configuraon on the virtual router and aach the OSPF areas with the
appropriate interfaces on the firewall.
For more informaon on the OSPF opons that are available on the firewall, see Configure
OSPF.
Use Broadcast as the link type when there are more than two OSPF routers that need to
exchange roung informaon.
1. Select Network > Virtual Routers, and select the default router or add a new router.
2. Select OSPF (for IPv4) or OSPFv3 (for IPv6) and select Enable.
3. In this example, the OSPF configuraon for VPN Peer A is:
• Router ID: 192.168.100.141
• Area ID: 0.0.0.0 that is assigned to the tunnel.1 interface with Link type: p2p
• Area ID: 0.0.0.10 that is assigned to the interface Ethernet1/1 and Link Type:
Broadcast
The OSPF configuraon for VPN Peer B is:
• Router ID: 192.168.100.140
• Area ID: 0.0.0.0 that is assigned to the tunnel.1 interface with Link type: p2p
Broadcast

This examples uses stac IP addresses for both VPN peers. Typically, the corporate office uses
a stacally configured IP address, and the branch side can be a dynamic IP address; dynamic IP
addresses are not best suited for configuring stable services such as VPN.
• Local IP address—100.1.1.1/24
• Peer IP address—200.1.1.1/24
• Peer IP address—100.1.1.1/24
3. Select the IKE Crypto profile you created earlier to use for IKE phase 1.
VPNs

• Type—Auto Key
• IPSec Crypto Profile—Select the IKE Gateway defined above.
• Type—Auto Key
3. Select Show Advanced Opons, select Tunnel Monitor, and specify a Desnaon IP
address to ping for verifying connecvity.
4. To define the acon on failure to establish connecvity, see Define a Tunnel Monitoring
Profile.

addresses.
VPNs
STEP 8 | Verify OSPF adjacencies and routes from the CLI.

Verify that both the firewalls can see each other as neighbors with full status. Also confirm that
the IP address of the VPN peer’s tunnel interface and the OSPF Router ID. Use the following
CLI commands on each VPN peer.
• show routing protocol ospf neighbor
• show routing route type ospf
VPNs

See Set Up Tunnel Monitoring and View the Status of the Tunnels.
Site-to-Site VPN with Stac and Dynamic Roung

In this example, one site uses stac routes and the other site uses OSPF. When the roung
protocol is not the same between the locaons, the tunnel interface on each firewall must be
configured with a stac IP address. Then, to allow the exchange of roung informaon, the
firewall that parcipates in both the stac and dynamic roung process must be configured
with a Redistribuon profile. Configuring the redistribuon profile enables the virtual router to
redistribute and filter routes between protocols—stac routes, connected routes, and hosts—
from the stac autonomous system to the OSPF autonomous system. Without this redistribuon
profile, each protocol funcons on its own and does not exchange any route informaon with
other protocols running on the same virtual router.
In this example, the satellite office has stac routes and all traffic desned to the 192.168.x.x
network is routed to tunnel.41. The virtual router on VPN Peer B parcipates in both the stac
and the dynamic roung process and is configured with a redistribuon profile in order to
propagate (export) the stac routes to the OSPF autonomous system.
VPNs
STEP 1 | Configure the Layer 3 interfaces on each firewall.

configure for VPN.
2. Select Layer3 from the Interface Type.
• If you have not yet created the zone, select New Zone from the Security Zone, define
a Name for the new zone and then click OK.
192.168.210.26/24.
• IPv4—100.1.1.1/24
• IPv4—200.1.1.1/24
2).
profile.
profile.
VPNs

With pre-shared keys, to add authencaon scruny when seng up the IKE phase-1 tunnel,
you can set up Local and Peer Idenficaon aributes and a corresponding value that is
matched in the IKE negoaon process.
• Peer IP type—dynamic
• Local idenficaon—select FQDN(hostname) and enter the value for VPN Peer A.
• Peer idenficaon—select FQDN(hostname) and enter the value for VPN Peer B
• Peer IP address—dynamic
• Local idenficaon—select FQDN(hostname) and enter the value for VPN Peer B
• Peer idenficaon—select FQDN(hostname) and enter the value for VPN Peer A
3. Select the IKE Crypto profile you created earlier to use for IKE phase 1.
VPNs
2. In the Interface Name field, specify a numeric suffix, say, .41.
3. On the Config tab, expand the Security Zone to define the zone as follows:
Zone. In the Zone dialog, define a Name for new zone (for example vpn-tun), and then
click OK.
5. Assign an IP address to the tunnel interface, select the IPv4 or IPv6 tab, click Add in the
IP secon, and enter the IP address and network mask/prefix to assign to the interface,
for example, 172.19.9.2/24.
This IP address will be used to route traffic to the tunnel and to monitor the status of the
tunnel.
• IPv4—2.1.1.141/24
• IPv4—2.1.1.140/24
STEP 5 | Specify the interface to route traffic to a desnaon on the 192.168.x.x network.
1. On VPN Peer A, select the virtual router.
2. Select Stac Routes, and Add tunnel.41 as the Interface for roung traffic with a
Desnaon in the 192.168.x.x network.
VPNs
STEP 6 | Set up the stac route and the OSPF configuraon on the virtual router and aach the OSPF
areas with the appropriate interfaces on the firewall.
1. On VPN Peer B, select Network > Virtual Routers, and select the default router or add a
new router.
2. Select Stac Routes and Add the tunnel IP address as the next hop for traffic in the
172.168.x.x. network.
Assign the desired route metric; using a lower the value makes the a higher priority for
route selecon in the forwarding table.
3. Select OSPF (for IPv4) or OSPFv3 (for IPv6) and select Enable.
4. In this example, the OSPF configuraon for VPN Peer B is:
• Router ID: 192.168.100.140
• Area ID: 0.0.0.0 is assigned to the interface Ethernet 1/12 Link type: Broadcast
Broadcast
• Area ID: 0.0.0.20 is assigned to the interface Ethernet1/15 and Link Type: Broadcast
STEP 7 | Create a redistribuon profile to inject the stac routes into the OSPF autonomous system.
1. Create a redistribuon profile on VPN Peer B.
1. Select Network > Virtual Routers, and select the router you used above.
2. Select Redistribuon Profiles, and click Add.
3. Enter a Name for the profile and select Redist and assign a Priority value. If you have
configured mulple profiles, the profile with the lowest priority value is matched first.
4. Set Source Type as stac, and click OK. The stac route you defined in Step 6 will be
used for the redistribuon.
2. Inject the stac routes in to the OSPF system.
1. Select OSPF > Export Rules (for IPv4) or OSPFv3 > Export Rules (for IPv6).
2. Click Add, and select the redistribuon profile that you just created.
3. Select how the external routes are brought into the OSPF system. The default opon,
Ext2 calculates the total cost of the route using only the external metrics. To use both
internal and external OSPF metrics, use Ext1.
4. Assign a Metric (cost value) for the routes injected into the OSPF system. This opon
allows you to change the metric for the injected route as it comes into the OSPF
system.
5. Click OK.
VPNs

• Type—Auto Key
• Type—Auto Key
3. Select Show Advanced Opons, select Tunnel Monitor, and specify a Desnaon IP
address to ping for verifying connecvity.
4. To define the acon on failure to establish connecvity, see Define a Tunnel Monitoring
Profile.

addresses.
VPNs
STEP 10 | Verify OSPF adjacencies and routes from the CLI.

Verify that both the firewalls can see each other as neighbors with full status. Also confirm that
the IP address of the VPN peer’s tunnel interface and the OSPF Router ID. Use the following
CLI commands on each VPN peer.
• show routing protocol ospf neighbor
• show routing route

The following is an example of the output on each VPN peer.

See Set Up Tunnel Monitoring and View the Status of the Tunnels.
Large Scale VPN (LSVPN)
The GlobalProtect Large Scale VPN (LSVPN) feature on the Palo Alto Networks next-
generaon firewall simplifies the deployment of tradional hub and spoke VPNs,
enabling you to quickly deploy enterprise networks with several branch offices with a
minimum amount of configuraon required on the remote satellites. This soluon uses
cerficates for firewall authencaon and IPSec to secure data.
LSVPN enables site-to-site VPNs between Palo Alto Networks firewalls. To set up a
site-to-site VPN between a Palo Alto Networks firewall and another device, see VPNs.
The following topics describe the LSVPN components and how to set them up to
enable site-to-site VPN services between Palo Alto Networks firewalls:
> LSVPN Overview

> Create Interfaces and Zones for the LSVPN
> Enable SSL Between GlobalProtect LSVPN Components
> Configure the Portal to Authencate Satellites
> Configure GlobalProtect Gateways for LSVPN
> Configure the GlobalProtect Portal for LSVPN
> Prepare the Satellite to Join the LSVPN
> Verify the LSVPN Configuraon
> LSVPN Quick Configs
1273
LSVPN Overview
GlobalProtect provides a complete infrastructure for managing secure access to corporate
resources from your remote sites. This infrastructure includes the following components:
• GlobalProtect Portal—Provides the management funcons for your GlobalProtect LSVPN
infrastructure. Every satellite that parcipates in the GlobalProtect LSVPN receives
configuraon informaon from the portal, including configuraon informaon to enable the
satellites (the spokes) to connect to the gateways (the hubs). You configure the portal on an
interface on any Palo Alto Networks next-generaon firewall.
• GlobalProtect Gateways—A Palo Alto Networks firewall that provides the tunnel end point for
satellite connecons. The resources that the satellites access is protected by security policy
on the gateway. It is not required to have a separate portal and gateway; a single firewall can
funcon both as portal and gateway.
• GlobalProtect Satellite—A Palo Alto Networks firewall at a remote site that establishes
IPSec tunnels with the gateway(s) at your corporate office(s) for secure access to centralized
resources. Configuraon on the satellite firewall is minimal, enabling you to quickly and easily
scale your VPN as you add new sites.
The following diagram illustrates how the GlobalProtect LSVPN components work together.
Create Interfaces and Zones for the LSVPN

You must configure the following interfaces and zones for your LSVPN infrastructure:
• GlobalProtect portal—Requires a Layer 3 interface for GlobalProtect satellites to connect to.
If the portal and gateway are on the same firewall, they can use the same interface. The portal
must be in a zone that is accessible from your branch offices.
• GlobalProtect gateways—Requires three interfaces: a Layer 3 interface in the zone that is
reachable by the remote satellites, an internal interface in the trust zone that connects to the
protected resources, and a logical tunnel interface for terminang the VPN tunnels from the
satellites. Unlike other site-to-site VPN soluons, the GlobalProtect gateway only requires a
single tunnel interface, which it will use for tunnel connecons with all of your remote satellites
(point-to-mul-point). If you plan to use dynamic roung, you must assign an IP address to the
tunnel interface. GlobalProtect supports both IPv6 and IPv4 addressing for the tunnel interface.
• GlobalProtect satellites—Requires a single tunnel interface for establishing a VPN with the
remote gateways (up to a maximum of 25 gateways). If you plan to use dynamic roung, you
must assign an IP address to the tunnel interface. GlobalProtect supports both IPv6 and IPv4
addressing for the tunnel interface.
For more informaon about portals, gateways, and satellites see LSVPN Overview.
The portal and each gateway and satellite all require a Layer 3 interface to enable traffic to be
routed between sites.
If the gateway and portal are on the same firewall, you can use a single interface for both
components.
configure for GlobalProtect LSVPN.
2. Select Layer3 from the Interface Type drop-down.
• If you have not yet created the zone, select New Zone from the Security Zone drop-
down, define a Name for the new zone and then click OK.
5. Assign an IP address to the interface:
• For an IPv4 address, select IPv4 and Add the IP address and network mask to assign
to the interface, for example 203.0.11.100/24.
• For an IPv6 address, select IPv6, Enable IPv6 on the interface, and Add
the IP address and network mask to assign to the interface, for example
2001:1890:12f2:11::10.1.8.160/80.
STEP 2 | On the firewall(s) hosng GlobalProtect gateway(s), configure the logical tunnel interface that
will terminate VPN tunnels established by the GlobalProtect satellites.
IP addresses are not required on the tunnel interface unless you plan to use dynamic
roung. However, assigning an IP address to the tunnel interface can be useful for
troubleshoong connecvity issues.
Make sure to enable User-ID in the zone where the VPN tunnels terminate.

3. On the Config tab, expand the Security Zone drop-down to define the zone as follows:
• To use your trust zone as the terminaon point for the tunnel, select the zone from
the drop-down.
Zone. In the Zone dialog, define a Name for new zone (for example lsvpn-tun), select
the Enable User Idenficaon check box, and then click OK.
5. (Oponal) To assign an IP address to the tunnel interface:
2001:1890:12f2:11::10.1.8.160/80.
STEP 3 | If you created a separate zone for tunnel terminaon of VPN connecons, create a security
policy to enable traffic flow between the VPN zone and your trust zone.
For example, a policy rule enables traffic between the lsvpn-tun zone and the L3-Trust zone.

Click Commit.
Enable SSL Between GlobalProtect LSVPN Components

All interacon between the GlobalProtect components occurs over an SSL/TLS connecon.
Therefore, you must generate and/or install the required cerficates before configuring each
component so that you can reference the appropriate cerficate(s) and/or cerficate profiles in
the configuraons for each component. The following secons describe the supported methods
of cerficate deployment, descripons and best pracce guidelines for the various GlobalProtect
cerficates, and provide instrucons for generang and deploying the required cerficates:
• About Cerficate Deployment
• Deploy Server Cerficates to the GlobalProtect LSVPN Components
• Deploy Client Cerficates to the GlobalProtect Satellites Using SCEP
About Cerficate Deployment

There are two basic approaches to deploying cerficates for GlobalProtect LSVPN:
• Enterprise Cerficate Authority—If you already have your own enterprise cerficate authority,
you can use this internal CA to issue an intermediate CA cerficate for the GlobalProtect portal
to enable it to issue cerficates to the GlobalProtect gateways and satellites. You can also
configure the GlobalProtect portal to act as a Simple Cerficate Enrollment Protocol (SCEP)
client to issue client cerficates to GlobalProtect satellites.
• Self-Signed Cerficates—You can generate a self-signed root CA cerficate on the firewall
and use it to issue server cerficates for the portal, gateway(s), and satellite(s). When using
self-signed root CA cerficates, as a best pracce, create a self-signed root CA cerficate on
the portal and use it to issue server cerficates for the gateways and satellites. This way, the
private key used for cerficate signing stays on the portal.
Deploy Server Cerficates to the GlobalProtect LSVPN

Components
The GlobalProtect LSVPN components use SSL/TLS to mutually authencate. Before deploying
the LSVPN, you must assign an SSL/TLS service profile to each portal and gateway. The profile
specifies the server cerficate and allowed TLS versions for communicaon with satellites. You
don’t need to create SSL/TLS service profiles for the satellites because the portal will issue a
server cerficate for each satellite during the first connecon as part of the satellite registraon
process.
In addion, you must import the root cerficate authority (CA) cerficate used to issue the server
cerficates onto each firewall that you plan to host as a gateway or satellite. Finally, on each
gateway and satellite parcipang in the LSVPN, you must configure a cerficate profile that will
enable them to establish an SSL/TLS connecon using mutual authencaon.
The following workflow shows the best pracce steps for deploying SSL cerficates to the
GlobalProtect LSVPN components:
STEP 1 | On the firewall hosng the GlobalProtect portal, create the root CA cerficate for signing the
cerficates of the GlobalProtect components.
Create a Self-Signed Root CA Cerficate:
Generate.
2. Enter a Cerficate Name, such as LSVPN_CA.
3. Do not select a value in the Signed By field (this is what indicates that it is self-signed).
4. Select the Cerficate Authority check box and then click OK to generate the cerficate.
STEP 2 | Create SSL/TLS service profiles for the GlobalProtect portal and gateways.
For the portal and each gateway, you must assign an SSL/TLS service profile that references a
unique self-signed server cerficate.
The best pracce is to issue all of the required cerficates on the portal, so that the
signing cerficate (with the private key) doesn’t have to be exported.
If the GlobalProtect portal and gateway are on the same firewall interface, you can use
the same server cerficate for both components.
1. Use the root CA on the portal to Generate a Cerficate for each gateway you will deploy:
Generate.
3. Enter the FQDN (recommended) or IP address of the interface where you plan to
configure the gateway in the Common Name field.
4. In the Signed By field, select the LSVPN_CA cerficate you just created.
5. In the Cerficate Aributes secon, click Add and define the aributes to uniquely
idenfy the gateway. If you add a Host Name aribute (which populates the SAN field
of the cerficate), it must exactly match the value you defined for the Common Name.
2. Configure an SSL/TLS Service Profile for the portal and each gateway:
1. Select Device > Cerficate Management > SSL/TLS Service Profile and click Add.
2. Enter a Name to idenfy the profile and select the server Cerficate you just created
for the portal or gateway.
3. Define the range of TLS versions (Min Version to Max Version) allowed for
communicang with satellites and click OK.
STEP 3 | Deploy the self-signed server cerficates to the gateways.
Best Pracces:
• Export the self-signed server cerficates issued by the root CA from the portal and import
them onto the gateways.
• Be sure to issue a unique server cerficate for each gateway.
• The Common Name (CN) and, if applicable, the Subject Alternave Name (SAN) fields of
the cerficate must match the IP address or fully qualified domain name (FQDN) of the
interface where you configure the gateway.
1. On the portal, select Device > Cerficate Management > Cerficates > Device
Cerficates, select the gateway cerficate you want to deploy, and click Export.
2. Select Encrypted Private Key and Cerficate (PKCS12) from the File Format drop-down.
3. Enter (and re-enter) a Passphrase to encrypt the private key associated with the
cerficate and then click OK to download the PKCS12 file to your computer.
4. On the gateway, select Device > Cerficate Management > Cerficates > Device
Cerficates and click Import.
6. Enter the path and name to the Cerficate File you just downloaded from the portal, or
Browse to find the file.
7. Select Encrypted Private Key and Cerficate (PKCS12) as the File Format.
8. Enter the path and name to the PKCS12 file in the Key File field or Browse to find it.
9. Enter and re-enter the Passphrase you used to encrypt the private key when you
exported it from the portal and then click OK to import the cerficate and key.
STEP 4 | Import the root CA cerficate used to issue server cerficates for the LSVPN components.
You must import the root CA cerficate onto all gateways and satellites. For security reasons,
make sure you export the cerficate only, and not the associated private key.
1. Download the root CA cerficate from the portal.
2. Select the root CA cerficate used to issue cerficates for the LSVPN components
and click Export.
3. Select Base64 Encoded Cerficate (PEM) from the File Format drop-down and click
OK to download the cerficate. (Do not export the private key.)
2. On the firewalls hosng the gateways and satellites, import the root CA cerficate.
Import.
2. Enter a Cerficate Name that idenfies the cerficate as your client CA cerficate.
3. Browse to the Cerficate File you downloaded from the CA.
4. Select Base64 Encoded Cerficate (PEM) as the File Format and then click OK.
5. Select the cerficate you just imported on the Device Cerficates tab to open it.
6. Select Trusted Root CA and then click OK.
STEP 5 | Create a cerficate profile.

The GlobalProtect LSVPN portal and each gateway require a cerficate profile that specifies
which cerficate to use to authencate the satellites.
1. Select Device > Cerficate Management > Cerficate Profile and click Add and enter a
profile Name.
2. Make sure Username Field is set to None.
3. In the CA Cerficates field, click Add, select the Trusted Root CA cerficate you
imported in the previous step.
4. (Recommended) Enable use of CRL and/or OCSP to enable cerficate status verificaon.

Click Commit.
Deploy Client Cerficates to the GlobalProtect Satellites Using

SCEP
As an alternave method for deploying client cerficates to satellites, you can configure your
GlobalProtect portal to act as a Simple Cerficate Enrollment Protocol (SCEP) client to a SCEP
server in your enterprise PKI. SCEP operaon is dynamic in that the enterprise PKI generates a
cerficate when the portal requests it and sends the cerficate to the portal.
When the satellite device requests a connecon to the portal or gateway, it also includes its
serial number with the connecon request. The portal submits a CSR to the SCEP server using
the sengs in the SCEP profile and automacally includes the serial number of the device in the
subject of the client cerficate. Aer receiving the client cerficate from the enterprise PKI, the
portal transparently deploys the client cerficate to the satellite device. The satellite device then
presents the client cerficate to the portal or gateway for authencaon.
STEP 1 | Create a SCEP profile.
1. Select Device > Cerficate Management > SCEP and then Add a new profile.
2. Enter a Name to idenfy the SCEP profile.
3. If this profile is for a firewall with mulple virtual systems capability, select a virtual
system or Shared as the Locaon where the profile is available.
STEP 2 | (Oponal) To make the SCEP-based cerficate generaon more secure, configure a SCEP
challenge-response mechanism between the PKI and portal for each cerficate request.
Aer you configure this mechanism, its operaon is invisible, and no further input from you is
necessary.
To comply with the U.S. Federal Informaon Processing Standard (FIPS), use a Dynamic SCEP
challenge and specify a Server URL that uses HTTPS (see Step 7).
Select one of the following opons:
• None—(Default) The SCEP server does not challenge the portal before it issues a cerficate.
• Fixed—Obtain the enrollment challenge password from the SCEP server (for example,
http://10.200.101.1/CertSrv/mscep_admin/) in the PKI infrastructure and then
copy or enter the password into the Password field.
• Dynamic—Enter the SCEP Server URL where the portal-client submits these credenals (for
example, http://10.200.101.1/CertSrv/mscep_admin/), and a username and OTP
of your choice. The username and password can be the credenals of the PKI administrator.
STEP 3 | Specify the sengs for the connecon between the SCEP server and the portal to enable the
portal to request and receive client cerficates.
To idenfy the satellite, the portal automacally includes the device serial number in the CSR
request to the SCEP server. Because the SCEP profile requires a value in the Subject field, you
can leave the default $USERNAME token even though the value is not used in client cerficates
for LSVPN.
1. Configure the Server URL that the portal uses to reach the SCEP server in the PKI (for
example, http://10.200.101.1/certsrv/mscep/).
2. Enter a string (up to 255 characters in length) in the CA-IDENT Name field to idenfy
the SCEP server.
3. Select the Subject Alternave Name Type:
• RFC 822 Name—Enter the email name in a cerficate’s subject or Subject Alternave
Name extension.
• DNS Name—Enter the DNS name used to evaluate cerficates.
• Uniform Resource Idenfier—Enter the name of the resource from which the client
will obtain the cerficate.
• None—Do not specify aributes for the cerficate.
STEP 4 | (Oponal) Configure cryptographic sengs for the cerficate.

• Select the key length (Number of Bits) for the cerficate. If the firewall is in FIPS-CC mode
and the key generaon algorithm is RSA. The RSA keys must be 2048 bits or larger.
• Select the Digest for CSR which indicates the digest algorithm for the cerficate signing
request (CSR): SHA1, SHA256, SHA384, or SHA512.
STEP 5 | (Oponal) Configure the permied uses of the cerficate, either for signing or encrypon.
• To use this cerficate for signing, select the Use as digital signature check box. This enables
the endpoint use the private key in the cerficate to validate a digital signature.
• To use this cerficate for encrypon, select the Use for key encipherment check box. This
enables the client use the private key in the cerficate to encrypt data exchanged over the
HTTPS connecon established with the cerficates issued by the SCEP server.
STEP 6 | (Oponal) To ensure that the portal is connecng to the correct SCEP server, enter the
CA Cerficate Fingerprint. Obtain this fingerprint from the SCEP server interface in the
Thumbprint field.
1. Enter the URL for the SCEP server’s administrave UI (for example, http://
<hostname or IP>/CertSrv/mscep_admin/).
2. Copy the thumbprint and enter it in the CA Cerficate Fingerprint field.
STEP 7 | Enable mutual SSL authencaon between the SCEP server and the GlobalProtect portal.
This is required to comply with the U.S. Federal Informaon Processing Standard (FIPS).
FIPS-CC operaon is indicated on the firewall login page and in its status bar.
Select the SCEP server’s root CA Cerficate. Oponally, you can enable mutual SSL
authencaon between the SCEP server and the GlobalProtect portal by selecng a Client
Cerficate.
STEP 8 | Save and commit the configuraon.

1. Click OK to save the sengs and close the SCEP configuraon.
The portal aempts to request a CA cerficate using the sengs in the SCEP profile and
saves it to the firewall hosng the portal. If successful, the CA cerficate is shown in Device >
Cerficate Management > Cerficates.
STEP 9 | (Oponal) If aer saving the SCEP profile, the portal fails to obtain the cerficate, you can
manually generate a cerficate signing request (CSR) from the portal.
1. Select Device > Cerficate Management > Cerficates > Device Cerficates and then
click Generate.
2. Enter a Cerficate Name. This name cannot contain spaces.
3. Select the SCEP Profile to use to submit a CSR to your enterprise PKI.
4. Click OK to submit the request and generate the cerficate.
Configure the Portal to Authencate Satellites

In order to register with the LSVPN, each satellite must establish an SSL/TLS connecon with the
portal. Aer establishing the connecon, the portal authencates the satellite to ensure that is
authorized to join the LSVPN. Aer successfully authencang the satellite, the portal will issue
a server cerficate for the satellite and push the LSVPN configuraon specifying the gateways to
which the satellite can connect and the root CA cerficate required to establish an SSL connecon
with the gateways.
There are two ways that the satellite can authencate to the portal during its inial connecon:
• Serial number—You can configure the portal with the serial number of the satellite firewalls
that are authorized to join the LSVPN. During the inial satellite connecon to the portal, the
satellite presents its serial number to the portal and if the portal has the serial number in its
configuraon, the satellite will be successfully authencated. You add the serial numbers of
authorized satellites when you configure the portal. See Configure the Portal.
• Username and password—If you would rather provision your satellites without manually
entering the serial numbers of the satellites into the portal configuraon, you can instead
require the satellite administrator to authencate when establishing the inial connecon to
the portal. Although the portal will always look for the serial number in the inial request from
the satellite, if it cannot idenfy the serial number, the satellite administrator must provide a
username and password to authencate to the portal. Because the portal will always fall back
to this form of authencaon, you must create an authencaon profile in order to commit
the portal configuraon. This requires that you set up an authencaon profile for the portal
LSVPN configuraon even if you plan to authencate satellites using the serial number.
The following workflow describes how to set up the portal to authencate satellites against an
exisng authencaon service. GlobalProtect LSVPN supports external authencaon using a
local database, LDAP (including Acve Directory), Kerberos, TACACS+, or RADIUS.
STEP 1 | (External authencaon only) Create a server profile on the portal.

The server profile defines how the firewall connects to an external authencaon service to
validate the authencaon credenals that the satellite administrator enters.
If you use local authencaon, skip this step and instead add a local user for the
satellite administrator: see Add the user account to the local database.
Configure a server profile for the authencaon service type:

You can use RADIUS to integrate with a Mul-Factor Authencaon service.

• Add an LDAP server profile. If you use LDAP to connect to Acve Directory (AD), create a
separate LDAP server profile for every AD domain.

The authencaon profile defines which server profile to use to authencate satellites.
1. Select Device > Authencaon Profile and click Add.
2. Enter a Name for the profile and then select the authencaon Type. If the Type is an
external service, select the Server Profile you created in the previous step. If you added a
local user instead, set the Type to Local Database.
Configure GlobalProtect Gateways for LSVPN

Because the GlobalProtect configuraon that the portal delivers to the satellites includes the
list of gateways the satellite can connect to, it is a good idea to configure the gateways before
configuring the portal.
Before you can configure the GlobalProtect gateway, you must complete the following tasks:
• Create Interfaces and Zones for the LSVPN on the interface where you will configure each
gateway. You must configure both the physical interface and the virtual tunnel interface.
• Enable SSL Between GlobalProtect LSVPN Components by configuring the gateway server
cerficates, SSL/TLS service profiles, and cerficate profile required to establish a mutual SSL/
TLS connecon from the GlobalProtect satellites to the gateway.
Configure each GlobalProtect gateway to parcipate in the LSVPN as follows:
STEP 1 | Add a gateway.
1. Select Network > GlobalProtect > Gateways and click Add.
2. In the General screen, enter a Name for the gateway. The gateway name should have
no spaces and, as a best pracce, should include the locaon or other descripve
informaon to help users and administrators idenfy the gateway.
3. (Oponal) Select the virtual system to which this gateway belongs from the Locaon
field.
STEP 2 | Specify the network informaon that enables satellite devices to connect to the gateway.
If you haven’t created the network interface for the gateway, see Create Interfaces and Zones
for the LSVPN for instrucons.
1. Select the Interface that satellites will use for ingress access to the gateway.
2. Specify the IP Address Type and IP address for gateway access:
• The IP address type can be IPv4 (only), IPv6 (only), or IPv4 and IPv6. Use IPv4 and
IPv6 if your network supports dual stack configuraons, where IPv4 and IPv6 run at
the same me.
• The IP address must be compable with the IP address type. For example,
172.16.1/0 for IPv4 addresses or 21DA:D3:0:2F3B for IPv6 addresses. For dual
stack configuraons, enter both an IPv4 and IPv6 address.
STEP 3 | Specify how the gateway authencates satellites aempng to establish tunnels. If
you haven’t yet created an SSL/TLS Service profile for the gateway, see Deploy Server
Cerficates to the GlobalProtect LSVPN Components.
If you haven’t set up the authencaon profiles or cerficate profiles, see Configure the Portal
to Authencate Satellites for instrucons.
If you have not yet set up the cerficate profile, see Enable SSL Between GlobalProtect LSVPN
Components for instrucons.
On the GlobalProtect Gateway Configuraon dialog, select Authencaon and then configure
any of the following:
• To secure communicaon between the gateway and the satellites, select the SSL/TLS
Service Profile for the gateway.
• To specify the authencaon profile to use to authencate satellites, Add a Client
Authencaon. Then, enter a Name to idenfy the configuraon, select OS: Satellite to
apply the configuraon to all satellites, and specify the Authencaon Profile to use to
authencate the satellite. You can also select a Cerficate Profile for the gateway to use to
authencate satellite devices aempng to establish tunnels.
STEP 4 | Configure the tunnel parameters and enable tunneling.

1. On the GlobalProtect Gateway Configuraon dialog, select Satellite > Tunnel Sengs.
2. Select the Tunnel Configuraon check box to enable tunneling.
3. Select the Tunnel Interface you defined to terminate VPN tunnels established by the
GlobalProtect satellites when you performed the task to Create Interfaces and Zones for
the LSVPN.
4. (Oponal) If you want to preserve the Type of Service (ToS) informaon in the
encapsulated packets, select Copy TOS.
If there are mulple sessions inside the tunnel (each with a different TOS value),
copying the TOS header can cause the IPSec packets to arrive out of order.
STEP 5 | (Oponal) Enable tunnel monitoring.

Tunnel monitoring enables satellites to monitor its gateway tunnel connecon, allowing it to
failover to a backup gateway if the connecon fails. Failover to another gateway is the only
type of tunnel monitoring profile supported with LSVPN.
1. Select the Tunnel Monitoring check box.
2. Specify the Desnaon IP Address the satellites should use to determine if the gateway
is acve. You can specify an IPv4 address, and IPv6 address, or both. Alternavely, if you
configured an IP address for the tunnel interface, you can leave this field blank and the
tunnel monitor will instead use the tunnel interface to determine if the connecon is
acve.
3. Select Failover from the Tunnel Monitor Profile drop-down (this is the only supported
tunnel monitor profile for LSVPN).
STEP 6 | Select the IPSec Crypto profile to use when establishing tunnel connecons.
The profile specifies the type of IPSec encrypon and the authencaon method for securing
the data that will traverse the tunnel. Because both tunnel endpoints in an LSVPN are trusted
firewalls within your organizaon, you can typically use the default (predefined) profile, which
uses ESP as the IPSec protocol, group2 for the DH group, AES-128-CBC for encrypon, and
SHA-1 for authencaon.
In the IPSec Crypto Profile drop-down, select default to use the predefined profile or select
New IPSec Crypto Profile to define a new profile. For details on the authencaon and
encrypon opons, see Define IPSec Crypto Profiles.
STEP 7 | Configure the network sengs to assign the satellites during establishment of the IPSec
tunnel.
You can also configure the satellite to push the DNS sengs to its local clients by
configuring a DHCP server on the firewall hosng the satellite. In this configuraon, the
satellite will push DNS sengs it learns from the gateway to the DHCP clients.
1. On the GlobalProtect Gateway Configuraon dialog, select Satellite > Network Sengs.
2. (Oponal) If clients local to the satellite need to resolve FQDNs on the corporate
network, configure the gateway to push DNS sengs to the satellites in one of the
following ways:
• If the gateway has an interface that is configured as a DHCP client, you can set the
Inheritance Source to that interface and assign the same sengs received by the
DHCP client to GlobalProtect satellites. You can also inherit the DNS suffix from the
same source.
• Manually define the Primary DNS, Secondary DNS, and DNS Suffix sengs to push
to the satellites.
3. To specify the IP Pool of addresses to assign the tunnel interface on the satellites when
the VPN is established, click Add and then specify the IP address range(s) to use.
4. To define what desnaon subnets to route through the tunnel click Add in the Access
Route area and then enter the routes as follows:
• If you want to route all traffic from the satellites through the tunnel, leave this field
blank.
In this case, all traffic except traffic desned for the local subnet will be tunneled
to the gateway.
• To route only some traffic through the gateway (called split tunneling), specify the
desnaon subnets that must be tunneled. In this case, the satellite will route traffic
that is not desned for a specified access route using its own roung table. For
example, you may choose to only tunnel traffic desned for your corporate network,
and use the local satellite to safely enable Internet access.
• If you want to enable roung between satellites, enter the summary route for the
network protected by each satellite.
STEP 8 | (Oponal) Define what routes, if any, the gateway will accept from satellites.
By default, the gateway will not add any routes satellites adverse to its roung table. If you do
not want the gateway to accept routes from satellites, you do not need to complete this step.
1. To enable the gateway to accept routes adversed by satellites, select Satellite > Route
Filter.
2. Select the Accept published routes check box.
3. To filter which of the routes adversed by the satellites to add to the gateway roung
table, click Add and then define the subnets to include. For example, if all the satellites
are configured with subnet 192.168.x.0/24 on the LAN side, configuring a permied
route of 192.168.0.0/16 to enable the gateway to only accept routes from the satellite if
it is in the 192.168.0.0/16 subnet.
STEP 9 | Save the gateway configuraon.

1. Click OK to save the sengs and close the GlobalProtect Gateway Configuraon dialog.
Configure the GlobalProtect Portal for LSVPN

The GlobalProtect portal provides the management funcons for your GlobalProtect LSVPN.
Every satellite system that parcipates in the LSVPN receives configuraon informaon from the
portal, including informaon about available gateways as well as the cerficate it needs in order to
connect to the gateways.
The following secons provide procedures for seng up the portal:
• GlobalProtect Portal for LSVPN Prerequisite Tasks
• Configure the Portal
• Define the Satellite Configuraons
GlobalProtect Portal for LSVPN Prerequisite Tasks

Before configuring the GlobalProtect portal, you must complete the following tasks:
Create Interfaces and Zones for the LSVPN on the interface where you will configure the
portal.
Enable SSL Between GlobalProtect LSVPN Components by creang an SSL/TLS service profile
for the portal server cerficate, issuing gateway server cerficates, and configuring the portal
to issue server cerficates for the GlobalProtect satellites.
Configure the Portal to Authencate Satellites by defining the authencaon profile that the
portal will use to authencate satellites if the serial number is not available.
Configure GlobalProtect Gateways for LSVPN.
Configure the Portal

Aer you have completed the GlobalProtect Portal for LSVPN Prerequisite Tasks, configure the
GlobalProtect portal as follows:
STEP 1 | Add the portal.
1. Select Network > GlobalProtect > Portals and click Add.
2. On the General tab, enter a Name for the portal. The portal name should not contain any
spaces.
3. (Oponal) Select the virtual system to which this portal belongs from the Locaon field.
STEP 2 | Specify the network informaon to enable satellites to connect to the portal.
If you haven’t yet created the network interface for the portal, see Create Interfaces and Zones
for the LSVPN for instrucons.
1. Select the Interface that satellites will use for ingress access to the portal.
2. Specify the IP Address Type and IP address for satellite access to the portal:
• The IP address type can be IPv4 (for IPv4 traffic only), IPv6 (for IPv6 traffic only, or
IPv4 and IPv6. Use IPv4 and IPv6 if your network supports dual stack configuraons,
where IPv4 and IPv6 run at the same me.
• The IP address must be compable with the IP address type. For example,
172.16.1/0 for IPv4 addresses or 21DA:D3:0:2F3B for IPv6 addresses. For dual
stack configuraons, enter both an IPv4 and IPv6 address.
STEP 3 | Specify an SSL/TLS Service profile to use to enable the satellite to establish an SSL/TLS
connecon to the portal.
If you haven’t yet created an SSL/TLS service profile for the portal and issued gateway
cerficates, see Deploy Server Cerficates to the GlobalProtect LSVPN Components.
1. On the GlobalProtect Portal Configuraon dialog, select Authencaon.
2. Select the SSL/TLS Service Profile.
STEP 4 | Specify an authencaon profile and oponal cerficate profile for authencang satellites.
If the portal can’t validate the serial numbers of connecng satellites, it will fall back to
the authencaon profile. Therefore, before you can save the portal configuraon (by
clicking OK), you must Configure an authencaon profile.
Add a Client Authencaon, and then enter a Name to idenfy the configuraon, select OS:
Satellite to apply the configuraon to all satellites, and specify the Authencaon Profile to
use to authencate satellite devices. You can also specify a Cerficate Profile for the portal to
use to authencate satellite devices.
STEP 5 | Connue with defining the configuraons to push to the satellites or, if you have already
created the satellite configuraons, save the portal configuraon.
Click OK to save the portal configuraon or connue to Define the Satellite Configuraons.
Define the Satellite Configuraons

When a GlobalProtect satellite connects and successfully authencates to the GlobalProtect
portal, the portal delivers a satellite configuraon, which specifies what gateways the satellite can
connect to. If all your satellites will use the same gateway and cerficate configuraons, you can
create a single satellite configuraon to deliver to all satellites upon successful authencaon.
However, if you require different satellite configuraons—for example if you want one group of
satellites to connect to one gateway and another group of satellites to connect to a different
gateway—you can create a separate satellite configuraon for each. The portal will then use the
enrollment username/group name or the serial number of the satellite to determine which satellite
configuraon to deploy. As with security rule evaluaon, the portal looks for a match starng
from the top of the list. When it finds a match, it delivers the corresponding configuraon to the
satellite.
For example, the following figure shows a network in which some branch offices require VPN
access to the corporate applicaons protected by your perimeter firewalls and another site needs
VPN access to the data center.
Use the following procedure to create one or more satellite configuraons.

STEP 1 | Add a satellite configuraon.
The satellite configuraon specifies the GlobalProtect LSVPN configuraon sengs to deploy
to the connecng satellites. You must define at least one satellite configuraon.
1. Select Network > GlobalProtect > Portals and select the portal configuraon for which
you want to add a satellite configuraon and then select the Satellite tab.
2. In the Satellite secon, click Add.
3. Enter a Name for the configuraon.
If you plan to create mulple configuraons, make sure the name you define for each is
descripve enough to allow you to disnguish them.
4. To change how oen a satellite should check the portal for configuraon updates specify
a value in the Configuraon Refresh Interval (hours) field (range is 1-48; default is 24).
STEP 2 | Specify the satellites to which to deploy this configuraon.

The portal uses the Enrollment User/User Group sengs and/or Devices serial numbers to
match a satellite to a configuraon. Therefore, if you have mulple configuraons, be sure
to order them properly. As soon as the portal finds a match, it will deliver the configuraon.
Therefore, more specific configuraons must precede more general ones. See Step 5 for
instrucons on ordering the list of satellite configuraons.
Specify the match criteria for the satellite configuraon as follows:
• To restrict this configuraon to satellites with specific serial numbers, select the Devices
tab, click Add, and enter serial number (you do not need to enter the satellite hostname; it
will be automacally added when the satellite connects). Repeat this step for each satellite
you want to receive this configuraon.
• Select the Enrollment User/User Group tab, click Add, and then select the user or group
you want to receive this configuraon. Satellites that do not match on serial number will
be required to authencate as a user specified here (either an individual user or group
member).
Before you can restrict the configuraon to specific groups, you must Map Users to
Groups.
STEP 3 | Specify the gateways that satellites with this configuraon can establish VPN tunnels with.
Routes published by the gateway are installed on the satellite as stac routes. The
metric for the stac route is 10x the roung priority. If you have more than one
gateway, make sure to also set the roung priority to ensure that routes adversed
by backup gateways have higher metrics compared to the same routes adversed by
primary gateways. For example, if you set the roung priority for the primary gateway
and backup gateway to 1 and 10 respecvely, the satellite will use 10 as the metric for
the primary gateway and 100 as the metric for the backup gateway.
1. On the Gateways tab, click Add.

2. Enter a descripve Name for the gateway. The name you enter here should match the
name you defined when you configured the gateway and should be descripve enough
idenfy the locaon of the gateway.
3. Enter the FQDN or IP address of the interface where the gateway is configured in the
Gateways field. The address you specify must exactly match the Common Name (CN) in
the gateway server cerficate.
4. (Oponal) If you are adding two or more gateways to the configuraon, the Roung
Priority helps the satellite pick the preferred gateway. Enter a value in the range of 1-25,
with lower numbers having the higher priority (that is, the gateway the satellite will
connect to if all gateways are available). The satellite will mulply the roung priority by
10 to determine the roung metric.
STEP 4 | Save the satellite configuraon.

1. Click OK to save the satellite configuraon.
2. If you want to add another satellite configuraon, repeat the previous steps.
STEP 5 | Arrange the satellite configuraons so that the proper configuraon is deployed to each
satellite.
• To move a satellite configuraon up on the list of configuraons, select the configuraon
and click Move Up.
• To move a satellite configuraon down on the list of configuraons, select the configuraon
and click Move Down.
STEP 6 | Specify the cerficates required to enable satellites to parcipate in the LSVPN.
1. In the Trusted Root CA field, click Add and then select the CA cerficate used to issue
the gateway server cerficates. The portal will deploy the root CA cerficate you add
here to all satellites as part of the configuraon to enable the satellite to establish an SSL
connecon with the gateways. As a best pracce, all of your gateways should use the
same issuer.
2. Select the method of Client Cerficate distribuon:
• To store the client cerficates on the portal—select Local and select the Root
CA cerficate that the portal will use to issue client cerficates to satellites upon
successfully authencang them from the Issuing Cerficate drop-down.
If the root CA cerficate used to issue your gateway server cerficates is not
on the portal, you can Import it now. See Enable SSL Between GlobalProtect
LSVPN Components for details on how to import a root CA cerficate.
• To enable the portal to act as a SCEP client to dynamically request and issue client
cerficates—select SCEP and then select the SCEP profile used to generate CSRs to
your SCEP server.
If the you have not yet set up the portal to act as a SCEP client, you can add a
New SCEP profile now. See Deploy Client Cerficates to the GlobalProtect
Satellites Using SCEP for details.
STEP 7 | Save the portal configuraon.

1. Click OK to save the sengs and close the GlobalProtect Portal Configuraon dialog.
Prepare the Satellite to Join the LSVPN

To parcipate in the LSVPN, the satellites require a minimal amount of configuraon. Because the
required configuraon is minimal, you can pre-configure the satellites before shipping them to
your branch offices for installaon.
STEP 1 | Configure a Layer 3 Interface.
This is the physical interface the satellite will use to connect to the portal and the gateway.
This interface must be in a zone that allows access outside of the local trust network. As a best
pracce, create a dedicated zone for VPN connecons for visibility and control over traffic
desned for the corporate gateways.
STEP 2 | Configure the logical tunnel interface for the tunnel to use to establish VPN tunnels with the
GlobalProtect gateways.
IP addresses are not required on the tunnel interface unless you plan to use dynamic
roung. However, assigning an IP address to the tunnel interface can be useful for
troubleshoong connecvity issues.

3. On the Config tab, expand the Security Zone drop-down and select an exisng zone or
create a separate zone for VPN tunnel traffic by clicking New Zone and defining a Name
for new zone (for example lsvpnsat).
4. In the Virtual Router drop-down, select default.
5. (Oponal) To assign an IP address to the tunnel interface:
2001:1890:12f2:11::10.1.8.160/80.
STEP 3 | If you generated the portal server cerficate using a Root CA that is not trusted by the
satellites (for example, if you used self-signed cerficates), import the root CA cerficate
used to issue the portal server cerficate.
The root CA cerficate is required to enable the satellite to establish the inial connecon with
the portal to obtain the LSVPN configuraon.
1. Download the CA cerficate that was used to generate the portal server cerficates. If
you are using self-signed cerficates, export the root CA cerficate from the portal as
follows:
2. Select the CA cerficate, and click Export.
3. Select Base64 Encoded Cerficate (PEM) from the File Format drop-down and click
OK to download the cerficate. (You do not need to export the private key.)
2. Import the root CA cerficate you just exported onto each satellite as follows.
Import.
2. Enter a Cerficate Name that idenfies the cerficate as your client CA cerficate.
3. Browse to the Cerficate File you downloaded from the CA.
4. Select Base64 Encoded Cerficate (PEM) as the File Format and then click OK.
5. Select the cerficate you just imported on the Device Cerficates tab to open it.
6. Select Trusted Root CA and then click OK.
STEP 4 | Configure the IPSec tunnel configuraon.

1. Select Network > IPSec Tunnels and click Add.
2. On the General tab, enter a descripve Name for the IPSec configuraon.
3. Select the Tunnel Interface you created for the satellite.
4. Select GlobalProtect Satellite as the Type.
5. Enter the IP address or FQDN of the portal as the Portal Address.
6. Select the Layer 3 Interface you configured for the satellite.
7. Select the IP Address to use on the selected interface. You can select an IPv4 address, an
IPv6 address, or both. Specify if you want IPv6 preferred for portal registraon.
STEP 5 | (Oponal) Configure the satellite to publish local routes to the gateway.
Pushing routes to the gateway enables traffic to the subnets local to the satellite via the
gateway. However, you must also configure the gateway to accept the routes as detailed in
Configure GlobalProtect Gateways for LSVPN.
1. To enable the satellite to push routes to the gateway, on the Advanced tab select Publish
all stac and connected routes to Gateway.
If you select this check box, the firewall will forward all stac and connected routes
from the satellite to the gateway. However, to prevent the creaon of roung loops, the
firewall will apply some route filters, such as the following:
• Default routes
• Routes within a virtual router other than the virtual router associated with the tunnel
interface
• Routes using the tunnel interface
• Routes using the physical interface associated with the tunnel interface
2. (Oponal) If you only want to push routes for specific subnets rather than all routes, click
Add in the Subnet secon and specify which subnet routes to publish.
STEP 6 | Save the satellite configuraon.

1. Click OK to save the IPSec tunnel sengs.
2. Click Commit.
STEP 7 | If required, provide the credenals to allow the satellite to authencate to the portal.
This step is only required if the portal was unable to find a serial number match in its
configuraon or if the serial number didn’t work. In this case, the satellite will not be able to
establish the tunnel with the gateway(s).
1. Select Network > IPSec Tunnels and click the Gateway Info link in the Status column of
the tunnel configuraon you created for the LSVPN.
2. Click the enter credenals link in the Portal Status field and username and password
required to authencate the satellite to the portal.
Aer the portal successfully authencates to the portal, it will receive its signed
cerficate and configuraon, which it will use to connect to the gateway(s). You should
see the tunnel establish and the Status change to Acve.
Verify the LSVPN Configuraon

Aer configuring the portal, gateways, and satellites, verify that the satellites are able to connect
to the portal and gateway and establish VPN tunnels with the gateway(s).
STEP 1 | Verify satellite connecvity with portal.
From the firewall hosng the portal, verify that satellites are successfully connecng by
selecng Network > GlobalProtect > Portal and clicking Satellite Info in the Info column of the
portal configuraon entry.
STEP 2 | Verify satellite connecvity with the gateway(s).

On each firewall hosng a gateway, verify that satellites are able to establish VPN tunnels by
selecng Network > GlobalProtect > Gateways and click Satellite Info in the Info column of
the gateway configuraon entry. Satellites that have successfully established tunnels with the
gateway will display on the Acve Satellites tab.
STEP 3 | Verify LSVPN tunnel status on the satellite.

On each firewall hosng a satellite, verify the tunnel status by selecng Network > IPSec
Tunnels and verify acve Status as indicated by a green icon.
LSVPN Quick Configs

The following secons provide step-by-step instrucons for configuring some common
GlobalProtect LSVPN deployments:
• Basic LSVPN Configuraon with Stac Roung
• Advanced LSVPN Configuraon with Dynamic Roung
• Advanced LSVPN Configuraon with iBGP
Basic LSVPN Configuraon with Stac Roung

This quick config shows the fastest way to get up and running with LSVPN. In this example, a
single firewall at the corporate headquarters site is configured as both a portal and a gateway.
Satellites can be quickly and easily deployed with minimal configuraon for opmized scalability.
The following workflow shows the steps for seng up this basic configuraon:
In this example, the Layer 3 interface on the portal/gateway requires the following
configuraon:
• Security Zone—lsvpn-tun
• IPv4—203.0.113.11/24
To enable visibility into users and groups connecng over the VPN, enable User-ID in
the zone where the VPN tunnels terminate.
In this example, the Tunnel interface on the portal/gateway requires the following
configuraon:
• Security Zone—lsvpn-tun
STEP 3 | Create the Security policy rule to enable traffic flow between the VPN zone where the tunnel
terminates (lsvpn-tun) and the trust zone where the corporate applicaons reside (L3-Trust).
See Create a Security Policy Rule.
STEP 4 | Assign an SSL/TLS Service profile to the portal/gateway. The profile must reference a self-
signed server cerficate.
The cerficate subject name must match the FQDN or IP address of the Layer 3 interface you
create for the portal/gateway.
1. On the firewall hosng the GlobalProtect portal, create the root CA cerficate for signing
the cerficates of the GlobalProtect components. In this example, the root CA cerficate,
lsvpn-CA, will be used to issue the server cerficate for the portal/gateway. In addion,
the portal will use this root CA cerficate to sign the CSRs from the satellites.
2. Create SSL/TLS service profiles for the GlobalProtect portal and gateways.
Because the portal and gateway are on the same interface in this example, they can
share an SSL/TLS Service profile that uses the same server cerficate. In this example,
the profile is named lsvpnserver.
STEP 5 | Create a cerficate profile.

In this example, the cerficate profile lsvpn-profile references the root CA cerficate
lsvpn-CA. The gateway will use this cerficate profile to authencate satellites aempng to
establish VPN tunnels.
STEP 6 | Configure an authencaon profile for the portal to use if the satellite serial number is not
available.
1. Create one type of server profile on the portal:
You can use RADIUS to integrate with a Mul-Factor Authencaon

service.
• Add an LDAP server profile. If you use LDAP to connect to Acve Directory (AD),
create a separate LDAP server profile for every AD domain.
2. Configure an authencaon profile. In this example, the profile lsvpn-sat is used to
authencate satellites.
STEP 7 | Configure GlobalProtect Gateways for LSVPN.

Select Network > GlobalProtect > Gateways and Add a configuraon. This example requires
the following gateway configuraon:
• IP Address—203.0.113.11/24
• SSL/TLS Server Profile—lsvpnserver
• Cerficate Profile—lsvpn-profile
• Primary DNS/Secondary DNS—4.2.2.1/4.2.2.2
• IP Pool—2.2.2.111-2.2.2.120
• Access Route—10.2.10.0/24
STEP 8 | Configure the Portal.

Select Network > GlobalProtect > Portal and Add a configuraon. This example requires the
following portal configuraon:
• IP Address—203.0.113.11/24
• SSL/TLS Server Profile—lsvpnserver
• Authencaon Profile—lsvpn-sat
STEP 9 | Define the Satellite Configuraons.

On the Satellite tab in the portal configuraon, Add a Satellite configuraon and a Trusted
Root CA and specify the CA the portal will use to issue cerficates for the satellites. In this
example the required sengs are as following:
• Gateway—203.0.113.11
• Issuing Cerficate—lsvpn-CA
• Trusted Root CA—lsvpn-CA
STEP 10 | Prepare the Satellite to Join the LSVPN.

The satellite configuraon in this example requires the following sengs:
Interface Configuraon
• Layer 3 interface—ethernet1/1, 203.0.113.13/24
• Tunnel interface—tunnel.2
• Zone—lsvpnsat
Root CA Cerficate from Portal
• lsvpn-CA
IPSec Tunnel Configuraon
• Portal Address—203.0.113.11
• Local IP Address—203.0.113.13/24
• Publish all stac and connected routes to Gateway—enabled
Advanced LSVPN Configuraon with Dynamic Roung

In larger LSVPN deployments with mulple gateways and many satellites, invesng a lile
more me in the inial configuraon to set up dynamic roung will simplify the maintenance of
gateway configuraons because access routes will update dynamically. The following example
configuraon shows how to extend the basic LSVPN configuraon to configure OSPF as the
dynamic roung protocol.
Seng up an LSVPN to use OSPF for dynamic roung requires the following addional steps on
the gateways and the satellites:
• Manual assignment of IP addresses to tunnel interfaces on all gateways and satellites.
• Configuraon of OSPF point-to-mulpoint (P2MP) on the virtual router on all gateways and
satellites. In addion, as part of the OSPF configuraon on each gateway, you must manually
define the tunnel IP address of each satellite as an OSPF neighbor. Similarly, on each satellite,
you must manually define the tunnel IP address of each gateway as an OSPF neighbor.
Although dynamic roung requires addional setup during the inial configuraon of the LSVPN,
it reduces the maintenance tasks associated with keeping routes up to date as topology changes
occur on your network.
The following figure shows an LSVPN dynamic roung configuraon. This example shows how to
configure OSPF as the dynamic roung protocol for the VPN.
For a basic setup of a LSVPN, follow the steps in Basic LSVPN Configuraon with Stac Roung.
You can then complete the steps in the following workflow to extend the configuraon to use
dynamic roung rather than stac roung.
STEP 1 | Add an IP address to the tunnel interface configuraon on each gateway and each satellite.
Complete the following steps on each gateway and each satellite:
1. Select Network > Interfaces > Tunnel and select the tunnel configuraon you created for
the LSVPN to open the Tunnel Interface dialog.
If you have not yet created the tunnel interface, see Step 2 in Create Interfaces and
Zones for the LSVPN.
2. On the IPv4 tab, click Add and then enter an IP address and subnet mask. For example,
to add an IP address for the gateway tunnel interface you would enter 2.2.2.100/24.
3. Click OK to save the configuraon.
STEP 2 | Configure the dynamic roung protocol on the gateway.

To configure OSPF on the gateway:
1. Select Network > Virtual Routers and select the virtual router associated with your VPN
interfaces.
2. On the Areas tab, click Add to create the backbone area, or, if it is already configured,
click on the area ID to edit it.
3. If you are creang a new area, enter an Area ID on the Type tab.
4. On the Interface tab, click Add and select the tunnel Interface you created for the
LSVPN.
5. Select p2mp as the Link Type.
6. Click Add in the Neighbors secon and enter the IP address of the tunnel interface of
each satellite, for example 2.2.2.111.
7. Click OK twice to save the virtual router configuraon and then Commit the changes on
the gateway.
8. Repeat this step each me you add a new satellite to the LSVPN.
STEP 3 | Configure the dynamic roung protocol on the satellite.

To configure OSPF on the satellite:
1. Select Network > Virtual Routers and select the virtual router associated with your VPN
interfaces.
2. On the Areas tab, click Add to create the backbone area, or, if it is already configured,
click on the area ID to edit it.
3. If you are creang a new area, enter an Area ID on the Type tab.
4. On the Interface tab, click Add and select the tunnel Interface you created for the
LSVPN.
5. Select p2mp as the Link Type.
6. Click Add in the Neighbors secon and enter the IP address of the tunnel interface of
each GlobalProtect gateway, for example 2.2.2.100.
7. Click OK twice to save the virtual router configuraon and then Commit the changes on
the gateway.
8. Repeat this step each me you add a new gateway.
STEP 4 | Verify that the gateways and satellites are able to form router adjacencies.
• On each satellite and each gateway, confirm that peer adjacencies have formed and that
roung table entries have been created for the peers (that is, the satellites have routes to
the gateways and the gateways have routes to the satellites). Select Network > Virtual
Router and click the More Runme Stats link for the virtual router you are using for the
LSVPN. On the Roung tab, verify that the LSVPN peer has a route.
• On the OSPF > Interface tab, verify that the Type is p2mp.
• On the OSPF > Neighbor tab, verify that the firewalls hosng your gateways have
established router adjacencies with the firewalls hosng your satellites and vice versa. Also
verify that the Status is Full, indicang that full adjacencies have been established.
Advanced LSVPN Configuraon with iBGP

This use case illustrates how GlobalProtect LSVPN securely connects distributed office locaons
with primary and disaster recovery data centers that house crical applicaons for users and how
internal border gateway protocol (iBGP) eases deployment and upkeep. Using this method, you
can extend up to 500 satellite offices connecng to a single gateway.
BGP is a highly scalable, dynamic roung protocol that is ideal for hub-and-spoke deployments
such as LSVPN. As a dynamic roung protocol, it eliminates much of the overhead associated with
access routes (stac routes) by making it relavely easy to deploy addional satellite firewalls. Due
to its route filtering capabilies and features such as mulple tunable mers, route dampening,
and route refresh, BGP scales to a much higher number of roung prefixes with greater stability
than other roung protocols like RIP and OSPF. In the case of iBGP, a peer group, which includes
all the satellites and gateways in the LSVPN deployment, establishes adjacencies over the tunnel
endpoints. The protocol then implicitly takes control of route adversements, updates, and
convergence.
In this example configuraon, an acve/passive HA pair of PA-5200 firewalls is deployed in the
primary (acve) data center and acts as the portal and primary gateway. The disaster recovery data
center also has two PA-5200s in an acve/passive HA pair acng as the backup LSVPN gateway.
The portal and gateways serve 500 PA-220s deployed as LSVPN satellites in branch offices.
Both data center sites adverse routes but with different metrics. As a result, the satellites prefer
and install the acve data center’s routes. However, the backup routes also exist in the local
roung informaon base (RIB). If the acve data center fails, the routes adversed by that data
center are removed and replaced with routes from the disaster recovery data center’s routes. The
failover me depends on selecon of iBGP mes and roung convergence associated with iBGP.
The following workflow shows the steps for configuring this deployment:
STEP 1 | Create Interfaces and Zones for the LSVPN.

Portal and Primary gateway:
• Zone: LSVPN-Untrust-Primary
• Interface: ethernet1/21
• IPv4: 172.16.22.1/24
• Zone: L3-Trust
• IPv4: 200.99.0.1/16
Backup gateway:
• Zone: LSVPN-Untrust-Primary
• IPv4: 172.16.22.25/24
• Zone: L3-Trust
• IPv4: 200.99.0.1/16
Satellite:
• Zone: LSVPN-Sat-Untrust
• IPv4: 172.16.13.1/22
• Zone: L3-Trust
• Interface: ethernet1/2.1
• IPv4: 200.101.1.1/24
Configure the zones, interfaces, and IP addresses on each satellite. The interface and
local IP address will be different for each satellite. This interface is used for the VPN
connecon to the portal and gateway.
Primary gateway:
• Interface: tunnel.5
• IPv4: 10.11.15.254/22
• Zone: LSVPN-Tunnel-Primary
Backup gateway:
• Interface: tunnel.1
• IPv4: 10.11.15.245/22
• Zone: LSVPN-Tunnel-Backup
STEP 3 | Enable SSL Between GlobalProtect LSVPN Components.

The gateway uses the self-signed root cerficate authority (CA) to issue cerficates for the
satellites in a GlobalProtect LSVPN. Because one firewall houses the portal and primary
gateway, a single cerficate is used for authencang to the satellites. The same CA is used to
generate a cerficate for the backup gateway. The CA generates cerficates that pushed to the
satellites from the portal and then used by the satellites to authencate to the gateways.
You must also generate a cerficate from the same CA for the backup gateway, allowing it to
authencate with the satellites.
1. On the firewall hosng the GlobalProtect portal, create the root CA cerficate for signing
the cerficates of the GlobalProtect components. In this example, the root CA cerficate
is called CA-cert.
2. Create SSL/TLS service profiles for the GlobalProtect portal and gateways. Because the
GlobalProtect portal and primary gateway are the same firewall interface, you can use
the same server cerficate for both components.
• Root CA Cerficate: CA-Cert
• Cerficate Name: LSVPN-Scale
3. Deploy the self-signed server cerficates to the gateways.
4. Import the root CA cerficate used to issue server cerficates for the LSVPN
components.
5. Create a cerficate profile.
6. Repeat steps 2 through 5 on the backup gateway with the following sengs:
• Root CA Cerficate: CA-cert
• Cerficate Name: LSVPN-back-GW-cert
STEP 4 | Configure GlobalProtect Gateways for LSVPN.

1. Select Network > GlobalProtect > Gateways and click Add.
2. On the General tab, name the primary gateway LSVPN-Scale.
3. Under Network Sengs, select ethernet1/21 as the primary gateway interface and
enter 172.16.22.1/24 as the IP address.
4. On the Authencaon tab, select the LSVPN-Scale cerficate created in 3.
5. Select Satellite > Tunnel Sengs and select Tunnel Configuraon. Set the Tunnel
Interface to tunnel.5. All satellites in this use case connect to a single gateway, so a
single satellite configuraon is needed. Satellites are matched based on their serial
numbers, so no satellites will need to authencate as a user.
6. On Satellite > Network Sengs, define the pool of IP address to assign to the tunnel
interface on the satellite once the VPN connecon is established. Because this use case
uses dynamic roung, the Access Routes seng remains blank.
7. Repeat steps 1 through 5 on the backup gateway with the following sengs:
• Name: LSVPN-backup
• Gateway interface: ethernet1/5
• Gateway IP: 172.16.22.25/24
• Server cert: LSVPN-backup-GW-cert
• Tunnel interface: tunnel.1
STEP 5 | Configure iBGP on the primary and backup gateways and add a redistribuon profile to allow
the satellites to inject local routes back to the gateways.
Each satellite office manages its own network and firewall, so the redistribuon profile called
ToAllSat is configured to redistribute local routes back to the GlobalProtect gateway.
1. Select Network > Virtual Routers and Add a virtual router.
2. On Router Sengs, add the Name and Interface for the virtual router.
3. On Redistribuon Profile and select Add.
1. Name the redistribuon profile ToAllSat and set the Priority to 1.
2. Set Redistribute to Redist.
3. Add ethernet1/23 from the Interface drop-down.
4. Click OK.
4. Select BGP on the Virtual Router to configure BGP.
1. On BGP > General, select Enable.
2. Enter the gateway IP address as the Router ID (172.16.22.1) and 1000 as the AS
Number.
3. In the Opons secon, select Install Route.
4. On BGP > Peer Group, click Add a peer group with all the satellites that will connect
to the gateway.
5. On BGP > Redist Rules, Add the ToAllSat redistribuon profile you created
previously.
5. Click OK.
6. Repeat steps 1 through 5 on the backup gateway using ethernet1/6 for the
redistribuon profile.
STEP 6 | Prepare the Satellite to Join the LSVPN.

The configuraon shown is a sample of a single satellite.
Repeat this configuraon each me you add a new satellite to the LSVPN deployment.
1. Configure a tunnel interface as the tunnel endpoint for the VPN connecon to the
gateways.
2. Set the IPSec tunnel type to GlobalProtect Satellite and enter the IP address of the
GlobalProtect Portal.
3. Select Network > Virtual Routers and Add a virtual router.
4. On Router Sengs, add the Name and Interface for the virtual router.
5. Select Virtual Router > Redistribuon Profile and Add a profile with the following
sengs.
1. Name the redistribuon profile ToLSVPNGW and set the Priority to 1.
2. Add an Interface ethernet1/2.1.
3. Click OK.
6. Select BGP > General, Enable BGP and configure the protocol as follows:
1. Enter the gateway IP address as the Router ID (172.16.22.1) and 1000 as the AS
Number.
2. In the Opons secon, select Install Route.
3. On BGP > Peer Group, Add a peer group containing all the satellites that will connect
to the gateway.
4. On BGP > Redist Rules, Add the ToLSVPNGW redistribuon profile you created
previously.
7. Click OK.
STEP 7 | Configure the GlobalProtect Portal for LSVPN.

Both data centers adverse their routes but with different roung priories to ensure that the
acve data center is the preferred gateway.
1. Select Network > GlobalProtect > Portals and click Add.
2. On General, enter LSVPN-Portal as the portal name.
3. On Network Sengs, select ethernet1/21 as the Interface and select
172.16.22.1/24 as the IP Address.
4. On the Authencaon tab, select the previously created primary gateway SSL/TLS
Profile LSVPN-Scale from the SSL/TLS Service Profile drop-down menu.
5. On the Satellite tab, Add a satellite and Name it sat-config-1.
6. Set the Configuraon Refresh Interval to 12.
7. On GlobalProtect Satellite > Devices, add the serial number and hostname of each
satellite device in the LSVPN.
8. On GlobalProtect Satellite > Gateways, add the name and IP address of each gateway.
Set the roung priority of the primary gateway to 1 and the backup gateway to 10 to
ensure that the acve data center is the preferred gateway.
STEP 8 | Verify the LSVPN Configuraon.
STEP 9 | (Oponal) Add a new site to the LSVPN deployment.

1. Select Network > GlobalProtect > Portals > GlobalProtect Portal > Satellite
Configuraon > GlobalProtect Satellite > Devices to add the serial number of the new
satellite to the GlobalProtect portal.
2. Configure the IPSec tunnel on the satellite with the GlobalProtect Portal IP address.
3. Select Network > Virtual Router > BGP > Peer Group to add the satellite to the BGP
Peer Group configuraon on each gateway.
4. Select Network > Virtual Router > BGP > Peer Group to add the gateways to the BGP
Peer Group configuraon on the new satellite.
Policy
Policies allow you to enforce rules and take acon. The different types of policy rules
that you can create on the firewall are: Security, NAT, Quality of Service (QoS), Policy
Based Forwarding (PBF), Decrypon, Applicaon Override, Authencaon, Denial of
Service (DoS), and Zone protecon policies. All these different policies work together
to allow, deny, priorize, forward, encrypt, decrypt, make excepons, authencate
access, and reset connecons as needed to help secure your network. The following
topics describe how to work with policy:
> Policy Types > Use an External Dynamic List in
> Security Policy Policy
> Policy Objects > Register IP Addresses and Tags

Dynamically
> Security Profiles
> Use Dynamic User Groups in Policy
> Track Rules Within a Rulebase
> Use Auto-Tagging to Automate
> Enforce Policy Rule Descripon, Tag, Security Acons
and Audit Comment
> Monitor Changes in the Virtual
> Move or Clone a Policy Rule or Environment
Object to a Different Virtual System
> CLI Commands for Dynamic IP
> Use an Address Object to Represent Addresses and Tags
IP Addresses
> Idenfy Users Connected through a
> Use Tags to Group and Visually Proxy Server
Disnguish Objects
> Policy-Based Forwarding
> Test Policy Rules
1311
Policy
Policy Types
The Palo Alto Networks next-generaon firewall supports a variety of policy types that work
together to safely enable applicaons on your network.
For all policy types, when you Enforce Policy Rule Descripon, Tag, and Audit Comment, you
can use the audit comment archive to view how a policy rule changed over me. The archive,
which includes the audit comment history and the configuraon logs, enables you to compare
configuraon versions and review who created or modified and why.
Security Determine whether to block or allow a session based on traffic

aributes such as the source and desnaon security zone, the source
and desnaon IP address, the applicaon, user, and the service. For
more details, see Security Policy.
NAT Instruct the firewall which packets need translaon and how to do
the translaon. The firewall supports both source address and/or port
translaon and desnaon address and/or port translaon. For details,
see NAT.
QoS Idenfy traffic requiring QoS treatment (either preferenal treatment

or bandwidth-liming) using a defined parameter or mulple
parameters and assign it a class. For more details, see Quality of
Service.
Policy Based Idenfy traffic that should use a different egress interface than the
Forwarding one that would normally be used based on the roung table. For more
details, see Policy-Based Forwarding.
Decrypon Idenfy encrypted traffic that you want to inspect for visibility, control,
and granular security. For more details, see Decrypon.
Applicaon Override Idenfy sessions that you do not want processed by the App-ID
engine, which is a Layer-7 inspecon. Traffic matching an applicaon
override policy forces the firewall to handle the session as a regular
stateful inspecon firewall at Layer-4. For more details, see Manage
Custom or Unknown Applicaons.
Authencaon Idenfy traffic that requires users to authencate. For more details, see
DoS Protecon Idenfy potenal denial-of-service (DoS) aacks and take protecve
acon in response to rule matches. For more details, see DoS
Protecon Profiles.
Policy
Security Policy
Security policy protects network assets from threats and disrupons and helps to opmally
allocate network resources for enhancing producvity and efficiency in business processes. On a
Palo Alto Networks firewall, individual Security policy rules determine whether to block or allow
a session based on traffic aributes, such as the source and desnaon security zone, the source
and desnaon IP address, the applicaon, the user, and the service.
To ensure that end users authencate when they try to access your network resources, the
firewall evaluates Authencaon Policy before Security policy.
All traffic passing through the firewall is matched against a session and each session is matched
against a Security policy rule. When a session match occurs, the firewall applies the matching
Security policy rule to bidireconal traffic in that session (client to server and server to client). For
traffic that doesn’t match any defined rules, the default rules apply. The default rules—displayed
at the boom of the security rulebase—are predefined to allow all intrazone traffic (within a zone)
and deny all interzone traffic (between zones). Although these rules are part of the predefined
configuraon and are read-only by default, you can override them and change a limited number of
sengs, including the tags, acon (allow or block), log sengs, and security profiles.
Security policy rules are evaluated le to right and from top to boom. A packet is matched
against the first rule that meets the defined criteria and, aer a match is triggered, subsequent
rules are not evaluated. Therefore, the more specific rules must precede more generic ones in
order to enforce the best match criteria. Traffic that matches a rule generates a log entry at the
end of the session in the traffic log if you enable logging for that rule. The logging opons are
configurable for each rule and can, for example, be configured to log at the start of a session
instead of, or in addion to, logging at the end of a session.
Aer an administrator configures a rule, you can View Policy Rule Usage to determine when
and how many mes traffic matches the Security policy rule to determine its effecveness. As
your rulebase evolves, change and audit informaon get lost over me unless you archived this
informaon at the me the rule is created or modified. You can Enforce Policy Rule Descripon,
Tag, and Audit Comment to ensure that all administrators enter audit comments so that you can
view the audit comment archive and review comments and configuraon log history and can
compare rule configuraon versions for a selected rule. Together, you now have more visibility
into and control over the rulebase.
• Components of a Security Policy Rule
• Security Policy Acons
• Create a Security Policy Rule
Components of a Security Policy Rule

The Security policy rule construct permits a combinaon of the required and oponal fields as
detailed in the following table:
Policy
Required/Field Descripon
Oponal
Required Name A label (up to 63 characters) that idenfies the rule.
UUID The Universally Unique Idenfier (UUID) is a disnct 32-character

string that permanently idenfies rules so that you can track a rule
regardless of any changes to it, such as the name.
Rule Type Specifies whether the rule applies to traffic within a zone, between
zones, or both:
• universal (default)—Applies the rule to all matching interzone
and intrazone traffic in the specified source and desnaon
zones. For example, if you create a universal rule with source
zones A and B and desnaon zones A and B, the rule would
apply to all traffic within zone A, all traffic within zone B, and all
traffic from zone A to zone B and all traffic from zone B to zone
A.
• intrazone—Applies the rule to all matching traffic within the
specified source zones (you cannot specify a desnaon zone
for intrazone rules). For example, if you set the source zone to
A and B, the rule would apply to all traffic within zone A and all
traffic within zone B, but not to traffic between zones A and B.
• interzone—Applies the rule to all matching traffic between the
specified source and desnaon zones. For example, if you set
the source zone to A, B, and C and the desnaon zone to A
and B, the rule would apply to traffic from zone A to zone B,
from zone B to zone A, from zone C to zone A, and from zone C
to zone B, but not traffic within zones A, B, or C.
Source Zone The zone from which the traffic originates.
Desnaon The zone at which the traffic terminates. If you use NAT, make sure
Zone to always reference the post-NAT zone.
Applicaon The applicaon that you wish to control. The firewall uses App-
ID, the traffic classificaon technology, to idenfy traffic on your
network. App-ID provides applicaon control and visibility in
creang security policies that block unknown applicaons, while
enabling, inspecng, and shaping those that are allowed.
Acon Specifies an Allow or Deny acon for the traffic based on the
criteria you define in the rule. When you configure the firewall
to deny traffic, it either resets the connecon or silently drops
packets. To provide a beer user experience, you can configure
granular opons to deny traffic instead of silently dropping
packets, which can cause some applicaons to break and appear
Policy
Oponal
unresponsive to the user. For more details, see Security Policy
Acons.
Oponal Tag A keyword or phrase that allows you to filter security rules. This
is handy when you have defined many rules and wish to then
review those that are tagged with a keyword such as IT-sanconed
applicaons or High-risk applicaons.
Descripon A text field, up to 1024 characters, used to describe the rule.
Source Address Define host IP addresses, subnets, address objects (of type IP
netmask, IP range, FQDN, or IP wildcard mask), address groups, or
country-based enforcement. If you use NAT, make sure to always
refer to the original IP addresses in the packet (i.e. the pre-NAT IP
address).
Desnaon The locaon or desnaon for the packet. Define IP addresses,

Address subnets, address objects (of type IP netmask, IP range, FQDN, or IP
wildcard mask), address groups, or country-based enforcement. If
you use NAT, make sure to always refer to the original IP addresses
in the packet (i.e. the pre-NAT IP address).
User The user or group of users for whom the policy applies. You must
have User-ID enabled on the zone. To enable User-ID, see User-ID
Overview.
URL Category Using the URL Category as match criteria allows you to customize
security profiles (Anvirus, An-Spyware, Vulnerability, File-
Blocking, Data Filtering, and DoS) on a per-URL-category basis.
For example, you can prevent.exe file download/upload for URL
categories that represent higher risk while allowing them for other
categories. This funconality also allows you to aach schedules to
specific URL categories (allow social-media websites during lunch
& aer-hours), mark certain URL categories with QoS (financial,
medical, and business), and select different log forwarding profiles
on a per-URL-category-basis.
Although you can manually configure URL categories on your
firewall, to take advantage of the dynamic URL categorizaon
updates available on Palo Alto Networks firewalls, you must
purchase a URL filtering license.
Policy
Oponal
To block or allow traffic based on URL category, you
must apply a URL Filtering profile to the security policy
rules. Define the URL Category as Any and aach a
URL Filtering profile to the security policy. See Set Up
a Basic Security Policy for informaon on using the
default profiles in your security policy.
Service Allows you to select a Layer 4 (TCP or UDP) port for the
applicaon. You can choose any, specify a port, or use applicaon-
default to permit use of the standards-based port for the
applicaon. For example, for applicaons with well-known port
numbers such as DNS, the applicaon-default opon will match
against DNS traffic only on TCP port 53. You can also add a custom
applicaon and define the ports that the applicaon can use.
For inbound allow rules (for example, from untrust to

trust), using applicaon-default prevents applicaons
from running on unusual ports and protocols.
Applicaon-default is the default opon; while the
firewall sll checks for all applicaons on all ports, with
this configuraon, applicaons are only allowed on their
standard ports/protocols.
Security Provide addional protecon from threats, vulnerabilies, and data

Profiles leaks. Security profiles are evaluated only for rules that have an
allow acon.
HIP Profile (for Allows you to idenfy clients with Host Informaon Profile (HIP)
GlobalProtect) and then enforce access privileges.
Opons Allow you to define logging for the session, log forwarding sengs,
change Quality of Service (QoS) markings for packets that match
the rule, and schedule when (day and me) the security rule should
be in effect.
Security Policy Acons

For traffic that matches the aributes defined in a security policy, you can apply the following
acons:
Allow (default) Allows the traffic.
Policy
Deny Blocks traffic and enforces the default Deny Acon defined for
the applicaon that is being denied. To view the deny acon
defined by default for an applicaon, view the applicaon details
in Objects > Applicaons or check the applicaon details in
Applipedia.
Drop Silently drops the traffic; for an applicaon, it overrides the default
deny acon. A TCP reset is not sent to the host/applicaon.
For Layer 3 interfaces, to oponally send an ICMP unreachable
response to the client, set Acon: Drop and enable the Send ICMP
Unreachable check box. When enabled, the firewall sends the
ICMP code for communicaon with the desnaon is administravely
prohibited—ICMPv4: Type 3, Code 13; ICMPv6: Type 1, Code 1.
Reset client Sends a TCP reset to the client-side device.
Reset server Sends a TCP reset to the server-side device.
Reset both Sends a TCP reset to both the client-side and server-side devices.
A reset is sent only aer a session is formed. If the session is blocked before a 3-
way handshake is completed, the firewall will not send the reset.
For a TCP session with a reset acon, the firewall does not send an ICMP Unreachable
response.
For a UDP session with a drop or reset acon, if the ICMP Unreachable check box is
selected, the firewall sends an ICMP message to the client.
Create a Security Policy Rule

STEP 1 | (Oponal) Delete the default Security policy rule.
By default, the firewall includes a security rule named rule1 that allows all traffic from Trust
zone to Untrust zone. You can either delete the rule or modify the rule to reflect your zone
naming convenons.
STEP 2 | Add a rule.

1. Select Policies > Security and Add a new rule.
3. Select a Rule Type.
Policy
STEP 3 | Define the matching criteria for the source fields in the packet.
1. In the Source tab, select a Source Zone.
2. Specify a Source IP Address or leave the value set to any.
If you decide to Negate a region as a Source Address, ensure that all regions
that contain private IP addresses are added to the Source Address to avoid
connecvity loss between those private IP addresses.
3. Specify a Source User or leave the value set to any.
STEP 4 | Define the matching criteria for the desnaon fields in the packet.
1. In the Desnaon tab, set the Desnaon Zone.
2. Specify a Desnaon IP Address or leave the value set to any.
If you decide to Negate a region as the Desnaon Address, ensure that all
regions that contain private IP addresses are added to the Desnaon Address
to avoid connecvity loss between those private IP addresses.
As a best pracce, use address objects as the Desnaon Address to enable

access to only specific servers or specific groups of servers especially for
commonly exploited services, such as DNS and SMTP. By restricng users
to specific desnaon server addresses, you can prevent data exfiltraon
and command-and-control traffic from establishing communicaon through
techniques such as DNS tunneling.
STEP 5 | Specify the applicaon that the rule will allow or block.
As a best pracce, always use applicaon-based security policy rules instead of port-
based rules and always set the Service to applicaon-default unless you are using a
more restricve list of ports than the standard ports for an applicaon.
1. In the Applicaons tab, Add the Applicaon you want to safely enable. You can select
mulple applicaons or you can use applicaon groups or applicaon filters.
2. In the Service/URL Category tab, keep the Service set to applicaon-default to ensure
that any applicaons that the rule allows are allowed only on their standard ports.
STEP 6 | (Oponal) Specify a URL category as match criteria for the rule.
In the Service/URL Category tab, select the URL Category.
If you select a URL category, only web traffic will match the rule and only if the traffic is
desned for that specified category.
STEP 7 | Define what acon you want the firewall to take for traffic that matches the rule.
In the Acons tab, select an Acon. See Security Policy Acons for a descripon of each
acon.
Policy
STEP 8 | Configure the log sengs.

• By default, the rule is set to Log at Session End. You can disable this seng if you don’t
want any logs generated when traffic matches this rule or you can select Log at Session
Start for more detailed logging.
• Select a Log Forwarding profile.
As a best pracce, do not select the check box to Disable Server Response Inspecon
(DSRI). Selecng this opon prevents the firewall from inspecng packets from the
server to the client. For the best security posture, the firewall must inspect both the
client-to-server flows and the server-to-client flows to detect and prevent threats.
STEP 9 | Aach security profiles to enable the firewall to scan all allowed traffic for threats.
Make sure you create best pracce security profiles that help protect your network
from both known and unknown threats.
In the Acons tab, select Profiles from the Profile Type drop-down and then select the
individual security profiles to aach to the rule.
Alternavely, select Group from the Profile Type drop-down and select a security Group
Profile to aach.
STEP 10 | Click Commit to save the policy rule to the running configuraon on the firewall.
Policy
STEP 11 | To verify that you have set up your basic security policies effecvely, test whether your
security policy rules are being evaluated and determine which security policy rule applies to a
traffic flow.
The output displays the best rule that matches the source and desnaon IP address specified
in the CLI command.
For example, to verify the policy rule that will be applied for a server in the data center with
the IP address 208.90.56.11 when it accesses the Microso update server:
1. Select Device > Troubleshoong, and select Security Policy Match from the Select Test
drop-down.
2. Enter the Source and Desnaon IP addresses.
4. Execute the security policy match test.
STEP 12 | Aer waing long enough to allow traffic to pass through the firewall, View Policy Rule
Usage to monitor the policy rule usage status and determine the effecveness of the policy
rule.
Policy
Policy Objects
A policy object is a single object or a collecve unit that groups discrete idenes such as IP
addresses, URLs, applicaons, or users. With policy objects that are a collecve unit, you can
reference the object in security policy instead of manually selecng mulple objects one at a
me. Typically, when creang a policy object, you group objects that require similar permissions
in policy. For example, if your organizaon uses a set of server IP addresses for authencang
users, you can group the set of server IP addresses as an address group policy object and reference
the address group in the security policy. By grouping objects, you can significantly reduce the
administrave overhead in creang policies.
If you need to export specific parts of the configuraon for internal review or audit, you
can Export Configuraon Table Data as a PDF or CSV file.
You can create the following policy objects on the firewall:
Policy Object Descripon
Address/Address Allow you to group specific source or desnaon addresses that

Group, Region require the same policy enforcement. The address object can include
an IPv4 or IPv6 address (single IP, range, subnet), an IP wildcard
address (IPv4 address/wildcard mask) or the FQDN. Alternavely, a
region can be defined by the latude and longitude coordinates or you
can select a country and define an IP address or IP range. You can then
group a collecon of address objects to create an address group object.
You can also use dynamic address groups to dynamically update IP
addresses in environments where host IP addresses change frequently.
The predefined External Dynamic Lists (EDLs) on the firewall

count toward the maximum number of address objects that
a firewall model supports.
User/User Group Allow you to create a list of users from the local database, an external
database, or match criteria and group them.
Applicaon Group An Applicaon Filter allows you to filter applicaons dynamically.

and Applicaon Filter It allows you to filter, and save a group of applicaons using the
aributes defined in the applicaon database on the firewall. For
example, you can Create an Applicaon Filter by one or more
aributes—category, sub-category, technology, risk, characteriscs.
With an applicaon filter, when a content update occurs, any new
applicaons that match your filter criteria are automacally added to
your saved applicaon filter.
An Applicaon Group allows you to create a stac group of specific
applicaons that you want to group together for a group of users or for
Policy
Policy Object Descripon

a parcular service, or to achieve a parcular policy goal. See Create an
Applicaon Group.
Service/Service Allows you to specify the source and desnaon ports and protocol
Groups that a service can use. The firewall includes two pre-defined services
—service-hp and service-hps— that use TCP ports 80 and 8080
for HTTP, and TCP port 443 for HTTPS. You can however, create
any custom service on any TCP/UDP port of your choice to restrict
applicaon usage to specific ports on your network (in other words,
you can define the default port for the applicaon).
To view the standard ports used by an applicaon, in

Objects > Applicaons search for the applicaon and click
the link. A succinct descripon displays.
Policy
Security Profiles
While security policy rules enable you to allow or block traffic on your network, security profiles
help you define an allow but scan rule, which scans allowed applicaons for threats, such as
viruses, malware, spyware, and DDOS aacks. When traffic matches the allow rule defined in the
security policy, the security profile(s) that are aached to the rule are applied for further content
inspecon rules such as anvirus checks and data filtering.
Security profiles are not used in the match criteria of a traffic flow. The security profile is
applied to scan traffic aer the applicaon or category is allowed by the security policy.
The firewall provides default security profiles that you can use out of the box to begin protecng
your network from threats. See Set Up a Basic Security Policy for informaon on using the default
profiles in your security policy. As you get a beer understanding about the security needs on
your network, see Create Best Pracce Security Profiles for the Internet Gateway to learn how
you can create custom profiles.
For recommendaons on the best-pracce sengs for security profiles, see Create Best
Pracce Security Profiles for the Internet Gateway.
You can add security profiles that are commonly applied together to Create a Security Profile
Group; this set of profiles can be treated as a unit and added to security policies in one step (or
included in security policies by default, if you choose to set up a default security profile group).
Profile Type Descripon
Anvirus Profiles Anvirus profiles protect against viruses, worms, and trojans as well
as spyware downloads. Using a stream-based malware prevenon
engine, which inspects traffic the moment the first packet is received,
the Palo Alto Networks anvirus soluon can provide protecon for
clients without significantly impacng the performance of the firewall.
This profile scans for a wide variety of malware in executables, PDF
files, HTML and JavaScript viruses, including support for scanning
inside compressed files and data encoding schemes. If you have
enabled Decrypon on the firewall, the profile also enables scanning of
decrypted content.
The default profile inspects all of the listed protocol decoders for
viruses, and generates alerts for SMTP, IMAP, and POP3 protocols
while blocking for FTP, HTTP, and SMB protocols. You can configure
the acon for a decoder or Anvirus signature and specify how the
firewall responds to a threat event:
• Default—For each threat signature and Anvirus signature that
is defined by Palo Alto Networks, a default acon is specified
internally. Typically, the default acon is an alert or a reset-both.
The default acon is displayed in parenthesis, for example default
(alert) in the threat or Anvirus signature.
Policy

• Allow—Permits the applicaon traffic.
The Allow acon does not generate logs related to the

signatures or profiles.
• Alert—Generates an alert for each applicaon traffic flow. The alert
is saved in the threat log.
• Drop—Drops the applicaon traffic.
• Reset Client—For TCP, resets the client-side connecon. For UDP,
drops the connecon.
• Reset Server—For TCP, resets the server-side connecon. For UDP,
• Reset Both—For TCP, resets the connecon on both client and
server ends. For UDP, drops the connecon.
Customized profiles can be used to minimize anvirus inspecon for
traffic between trusted security zones, and to maximize the inspecon
of traffic received from untrusted zones, such as the internet, as well as
the traffic sent to highly sensive desnaons, such as server farms.
The Palo Alto Networks WildFire system also provides signatures
for persistent threats that are more evasive and have not yet been
discovered by other anvirus soluons. As threats are discovered
by WildFire, signatures are quickly created and then integrated into
the standard Anvirus signatures that can be downloaded by Threat
Prevenon subscribers on a daily basis (sub-hourly for WildFire
subscribers).
An-Spyware Profiles An-Spyware profiles blocks spyware on compromised hosts from

trying to phone-home or beacon out to external command-and-
control (C2) servers, allowing you to detect malicious traffic leaving
the network from infected clients. You can apply various levels of
protecon between zones. For example, you may want to have custom
An-Spyware profiles that minimize inspecon between trusted zones,
while maximizing inspecon on traffic received from an untrusted
zone, such as internet-facing zones. When the firewall is managed
by a Panorama management server, the ThreatID is mapped to the
corresponding custom threat on the firewall to enable the firewall to
generate a threat log populated with the configured custom ThreatID.
You can define your own custom An-Spyware profiles, or choose one
of the following predefined profiles when applying An-Spyware to a
Security policy rule:
• Default—Uses the default acon for every signature, as specified by
Palo Alto Networks when the signature is created.
• Strict—Overrides the default acon of crical, high, and medium
severity threats to the block acon, regardless of the acon defined
Policy

in the signature file. This profile sll uses the default acon for low
and informaonal severity signatures.
When the firewall detects a threat event, you can configure the
following acons in an An-Spyware profile:
• Default—For each threat signature and An-Spyware signature
that is defined by Palo Alto Networks, a default acon is specified
internally. Typically the default acon is an alert or a reset-both. The
default acon is displayed in parenthesis, for example default (alert)
in the threat or Anvirus signature.
• Allow—Permits the applicaon traffic

In some cases, when the profile acon is set to reset-

both, the associated threat log might display the acon
as reset-server. This occurs when the firewall detects
a threat at the beginning of a session and presents the
client with a 503 block page. Because the block page
disallows the connecon, the client-side does not need to
be reset and only the server-side connecon is reset.
• Block IP— This acon blocks traffic from either a source or a
source-desnaon pair. It is configurable for a specified period of
me.
In addion, you can enable the DNS Sinkholing acon in An-Spyware
profiles to enable the firewall to forge a response to a DNS query for
a known malicious domain, causing the malicious domain name to
resolve to an IP address that you define. This feature helps to idenfy
infected hosts on the protected network using DNS traffic. Infected
hosts can then be easily idenfied in the traffic and threat logs because
any host that aempts to connect to the sinkhole IP address are most
likely infected with malware.
An-Spyware and Vulnerability Protecon profiles are configured
similarly.
Policy
Vulnerability Vulnerability Protecon profiles stop aempts to exploit system flaws

Protecon Profiles or gain unauthorized access to systems. While An-Spyware profiles
help idenfy infected hosts as traffic leaves the network, Vulnerability
Protecon profiles protect against threats entering the network. For
example, Vulnerability Protecon profiles help protect against buffer
overflows, illegal code execuon, and other aempts to exploit system
vulnerabilies. The default Vulnerability Protecon profile protects
clients and servers from all known crical, high, and medium-severity
threats. You can also create excepons, which allow you to change
the response to a specific signature. When the firewall is managed
by a Panorama management server, the ThreatID is mapped to the
corresponding custom threat on the firewall to enable the firewall to
generate a threat log populated with the configured custom ThreatID.
When the firewall detects a threat event, you can configure the
following acons in an An-Spyware profile:
• Default—For each threat signature and An-Spyware signature
that is defined by Palo Alto Networks, a default acon is specified
internally. Typically the default acon is an alert or a reset-both. The
default acon is displayed in parenthesis, for example default (alert)
in the threat or Anvirus signature.
• Allow—Permits the applicaon traffic

In some cases, when the profile acon is set to reset-

both, the associated threat log might display the acon
as reset-server. This occurs when the firewall detects
a threat at the beginning of a session and presents the
client with a 503 block page. Because the block page
disallows the connecon, the client-side does not need to
be reset and only the server-side connecon is reset.
Policy

• Block IP— This acon blocks traffic from either a source or a
source-desnaon pair. It is configurable for a specified period of
me.
URL Filtering Profiles URL Filtering profiles enable you to monitor and control how users
access the web over HTTP and HTTPS. The firewall comes with a
default profile that is configured to block websites such as known
malware sites, phishing sites, and adult content sites. You can use the
default profile in a security policy, clone it to be used as a starng point
for new URL filtering profiles, or add a new URL profile that will have
all categories set to allow for visibility into the traffic on your network.
You can then customize the newly added URL profiles and add lists
of specific websites that should always be blocked or allowed, which
provides more granular control over URL categories.
Data Filtering Profiles Data filtering profiles prevent sensive informaon such as credit
card or social security numbers from leaving a protected network.
The data filtering profile also allows you to filter on key words, such
as a sensive project name or the word confidenal. It is important to
focus your profile on the desired file types to reduce false posives.
For example, you may only want to search Word documents or Excel
spreadsheets. You may also only want to scan web-browsing traffic, or
FTP.
You can create custom data paern objects and aach them to a Data
Filtering profile to define the type of informaon on which you want to
filter. Create data paern objects based on:
• Predefined Paerns—Filter for credit card and social security
numbers (with or without dashes) using predefined paerns.
• Regular Expressions—Filter for a string of characters.
• File Properes—Filter for file properes and values based on file
type.
If you’re using a third-party, endpoint data loss prevenon

(DLP) soluons to populate file properes to indicate
sensive content, this opon enables the firewall to enforce
your DLP policy.
To get started, Set Up Data Filtering.
File Blocking Profiles The firewall uses file blocking profiles to block specified file types
over specified applicaons and in the specified session flow direcon
(inbound/outbound/both). You can set the profile to alert or block on
upload and/or download and you can specify which applicaons will
be subject to the file blocking profile. You can also configure custom
block pages that will appear when a user aempts to download the
Policy

specified file type. This allows the user to take a moment to consider
whether or not they want to download a file.
You can define your own custom File Blocking profiles, or choose one
of the following predefined profiles when applying file blocking to a
Security policy rule. The predefined profiles, which are available with
content release version 653 and later, allow you to quickly enable best
pracce file blocking sengs:
• basic file blocking—Aach this profile to the Security policy rules
that allow traffic to and from less sensive applicaons to block
files that are commonly included in malware aack campaigns or
that have no real use case for upload/download. This profile blocks
upload and download of PE files ( .scr, .cpl, .dll, .ocx, .pif, .exe) ,
Java files (.class, .jar), Help files (.chm, .hlp) and other potenally
malicious file types, including .vbe, .hta, .wsf, .torrent, .7z, .rar, .bat.
Addionally, it prompts users to acknowledge when they aempt
to download encrypted-rar or encrypted-zip files. This rule alerts on
all other file types to give you complete visibility into all file types
coming in and out of your network.
• strict file blocking—Use this stricter profile on the Security
policy rules that allow access to your most sensive applicaons.
This profile blocks the same file types as the other profile, and
addionally blocks flash, .tar, mul-level encoding, .cab, .msi,
encrypted-rar, and encrypted-zip files.
Configure a file blocking profile with the following acons:
• Alert—When the specified file type is detected, a log is generated in
the data filtering log.
• Block—When the specified file type is detected, the file is blocked
and a customizable block page is presented to the user. A log is also
generated in the data filtering log.
• Connue—When the specified file type is detected, a customizable
response page is presented to the user. The user can click through
the page to download the file. A log is also generated in the data
filtering log. Because this type of forwarding acon requires user
interacon, it is only applicable for web traffic.
To get started, Set Up File Blocking.
WildFire Analysis Use a WildFire analysis profile to enable the firewall to

Profiles forward unknown files or email links for WildFire analysis. Specify
files to be forwarded for analysis based on applicaon, file type,
and transmission direcon (upload or download). Files or email links
matched to the profile rule are forwarded either the WildFire public
cloud or the WildFire private cloud (hosted with a WF-500 appliance),
depending on the analysis locaon defined for the rule. If a profile rule
is set to forward files to the WildFire public cloud, the firewall also
Policy

forwards files that match exisng anvirus signatures, in addion to
unknown files.
You can also use the WildFire analysis profiles to set up a WildFire
hybrid cloud deployment. If you are using a WildFire appliance
to analyze sensive files locally (such as PDFs), you can specify
for less sensive files types (such as PE files) or file types that are
not supported for WildFire appliance analysis (such as APKs) to
be analyzed by the WildFire public cloud. Using both the WildFire
appliance and the WildFire cloud for analysis allows you to benefit
from a prompt verdict for files that have already been processed by the
cloud, and for files that are not supported for appliance analysis, and
frees up the appliance capacity to process sensive content.
DoS Protecon DoS protecon profiles provide detailed control for Denial of Service
Profiles (DoS) protecon policies. DoS policies allow you to control the number
of sessions between interfaces, zones, addresses, and countries based
on aggregate sessions or source and/or desnaon IP addresses. There
are two DoS protecon mechanisms that the Palo Alto Networks
firewalls support.
• Flood Protecon—Detects and prevents aacks where the network
is flooded with packets resulng in too many half-open sessions
and/or services being unable to respond to each request. In this
case the source address of the aack is usually spoofed. See DoS
Protecon Against Flooding of New Sessions.
• Resource Protecon— Detects and prevent session exhauson
aacks. In this type of aack, a large number of hosts (bots) are
used to establish as many fully established sessions as possible to
consume all of a system’s resources.
You can enable both types of protecon mechanisms in a single DoS
protecon profile.
The DoS profile is used to specify the type of acon to take and
details on matching criteria for the DoS policy. The DoS profile defines
sengs for SYN, UDP, and ICMP floods, can enable resource protect
and defines the maximum number of concurrent connecons. Aer
you configure the DoS protecon profile, you then aach it to a DoS
policy.
When configuring DoS protecon, it is important to analyze your
environment in order to set the correct thresholds and due to some of
the complexies of defining DoS protecon policies, this guide will not
go into detailed examples.
Zone Protecon Zone Protecon Profiles provide addional protecon between

Profiles specific network zones in order to protect the zones against aack.
The profile must be applied to the enre zone, so it is important to
carefully test the profiles in order to prevent issues that may arise
Policy

with the normal traffic traversing the zones. When defining packets
per second (pps) thresholds limits for zone protecon profiles, the
threshold is based on the packets per second that do not match a
previously established session.
Security Profile A security profile group is a set of security profiles that can be treated
Group as a unit and then easily added to security policies. Profiles that are
oen assigned together can be added to profile groups to simplify
the creaon of security policies. You can also setup a default security
profile group—new security policies will use the sengs defined in
the default profile group to check and control traffic that matches
the security policy. Name a security profile group default to allow
the profiles in that group to be added to new security policies by
default. This allows you to consistently include your organizaon’s
preferred profile sengs in new policies automacally, without having
to manually add security profiles each me you create new rules.
See Create a Security Profile Group and Set Up or Override a Default
Security Profile Group.
For recommendaons on the best-pracce sengs for

security profiles, see Create Best Pracce Security Profiles
for the Internet Gateway.
Create a Security Profile Group

Use the following steps to create a security profile group and add it to a security policy.
Policy
STEP 1 | Create a security profile group.
If you name the group default, the firewall will automacally aach it to any new
rules you create. This is a me saver if you have a preferred set of security profiles that
you want to make sure get aached to every new rule.
1. Select Objects > Security Profile Groups and Add a new security profile group.
2. Give the profile group a descripve Name, for example, Threats.
3. If the firewall is in Mulple Virtual System Mode, enable the profile to be Shared by all
virtual systems.
4. Add exisng profiles to the group.
5. Click OK to save the profile group.
STEP 2 | Add a security profile group to a security policy.

1. Select Policies > Security and Add or modify a security policy rule.
2. Select the Acons tab.
3. In the Profile Seng secon, select Group for the Profile Type.
4. In the Group Profile drop-down, select the group you created (for example, select the
best-pracce group):
5. Click OK to save the policy and Commit your changes.
STEP 3 | Save your changes.

Click Commit.
Set Up or Override a Default Security Profile Group

Use the following opons to set up a default security profile group to be used in new security
policies, or to override an exisng default group. When an administrator creates a new security
policy, the default profile group will be automacally selected as the policy’s profile sengs, and
traffic matching the policy will be checked according to the sengs defined in the profile group
Policy
(the administrator can choose to manually select different profile sengs if desired). Use the
following opons to set up a default security profile group or to override your default sengs.
If no default security profile exists, the profile sengs for a new security policy are set to
None by default.
Create a security profile group.

1. Select Objects > Security Profile Groups and Add a new security profile group.
2. Give the profile group a descripve Name, for example, Threats.
3. If the firewall is in Mulple Virtual System Mode, enable the profile to be Shared by all
virtual systems.
4. Add exisng profiles to the group. For details on creang profiles, see Security Profiles.
5. Click OK to save the profile group.

6. Add the security profile group to a security policy.
7. Add or modify a security policy rule and select the Acons tab.
8. Select Group for the Profile Type.
9. In the Group Profile drop-down, select the group you created (for example, select the
Threats group):
10. Click OK to save the policy and Commit your changes.
Policy
Set up a default security profile group.

1. Select Objects > Security Profile Groups and add a new security profile group or modify
an exisng security profile group.
2. Name the security profile group default:

4. Confirm that the default security profile group is included in new security policies by
default:
1. Select Policies > Security and Add a new security policy.
2. Select the Acons tab and view the Profile Seng fields:
By default, the new security policy correctly shows the Profile Type set to Group and
the default Group Profile is selected.
Override a default security profile group.

If you have an exisng default security profile group, and you do not want that set of profiles
to be aached to a new security policy, you can connue to modify the Profile Seng fields
according to your preference. Begin by selecng a different Profile Type for your policy
(Policies > Security > Security Policy Rule > Acons).
Policy
Track Rules Within a Rulebase

To keep track of rules within a rulebase, you can refer to the rule number, which changes
depending on the order of a rule in the rulebase. The rule number determines the order in which
the firewall applies the rule.
The universally unique idenfier (UUID) for a rule never changes even if you modify the rule, such
as when you change the rule name. The UUID allows you to track the rule across rulebases even
aer you deleted the rule.
Rule Numbers
The firewall automacally numbers each rule within a rulebase; when you move or reorder
rules, the numbers change based on the new order. When you filter the list of rules to find rules
that match specific criteria, the firewall display each rule with its number in the context of the
complete set of rules in the rulebase and its place in the evaluaon order.
Panorama independently numbers pre-rules, post-rules, and default rules. When Panorama pushes
rules to a firewall, the rule numbering reflects the hierarchy and evaluaon order of shared rules,
device group pre-rules, firewall rules, device group post-rules, and default rules. You can Preview
Rules in Panorama to display an ordered list of the total number of rules on a firewall.
View the numbered list of rules on the firewall.

Select Policies and any rulebase under it. For example, Policies > Security. The le-most
column in the table displays the rule number.
Policy
View the numbered list of rules on Panorama.

Select Policies and any rulebase under it. For example, Policies > Security > Pre-rules.
Aer you push the rules from Panorama, view the complete list of rules with numbers on the
firewall.
From the web interface on the firewall, select Policies and pick any rulebase under it. For
example, select Policies > Security and view the complete set of numbered rules that the
firewall will evaluate.
Policy
Rule UUIDs
The universally unique idenfier (UUID) for a rule is a 32-character string (based on data such as
the network address and the mestamp of creaon) that the firewall or Panorama assigns to the
rule. The UUID uses the format 8-4-4-4-12 (where 8, 4, and 12 represent the number of unique
characters separated by hyphens). UUIDs idenfy rules for all policy rulebases. You can also use
UUIDs to idenfy applicable rules in the following log types: Traffic, Threat, URL Filtering, WildFire
Submission, Data Filtering, GTP, SCTP, Tunnel Inspecon, Configuraon, and Unified.
Using the UUID to search for a rule enables you to locate a specific rule you want to find among
thousands of rules that may have similar or idencal names. UUIDs also simplify automaon and
integraon for rules in third-party systems (such as ckeng or orchestraon) that do not support
names.
In some cases, you may need to generate new UUIDs for exisng rulebases. For example, if you
want to export a configuraon to another firewall, you need to regenerate the UUIDs for the rules
as you import the configuraon to ensure there are no duplicate UUIDs. If you regenerate UUIDs,
you are no longer able to track those rules using their previous UUIDs and the hit data and app
usage data for those rules are reset.
The firewall or Panorama assigns UUIDs when you:
• Create new rules
• Clone exisng rules
• Override the default security rules
• Load a named configuraon and regenerate UUIDs
• Load a named configuraon containing new rules that are not in the running configuraon
• Upgrade the firewall or Panorama to a PAN-OS 9.0 release
When you load a configuraon that contains rules with UUIDs, the firewall considers rules to be
the same if the rule name, rulebase, and virtual system all match. Panorama considers rules to be
the same if the rule name, rulebase, and the device group all match.
Keep in mind the following important points for UUIDs:
• If you manage firewall policy from Panorama, UUIDs are generated on Panorama and therefore
must be pushed from Panorama. If you do not push the configuraon from Panorama prior to
upgrading the firewalls to PAN-OS 9.0, the firewall upgrade will not succeed because it will not
have the UUIDs.
• In addion, if you are upgrading an HA pair, upon upgrade to PAN-OS 9.0, each peer
independently assigns UUIDs for each policy rule. Because of this, the peers will show as out
of sync unl you sync the configuraon (Dashboard > Widgets > System > High Availability >
Sync to peer).
• If you remove an exisng high availability (HA) configuraon aer upgrading to PAN-OS 9.0,
you must regenerate the UUIDs on one of the peers (Device > Setup > Operaons > Load
named configuraon snapshot > Regenerate UUIDs for the selected named configuraon) and
commit the changes to prevent UUID duplicaon.
• All rules pushed from Panorama will share the same UUID; all rules local to a firewall will
have different UUIDs. If you create a rule locally on the firewall aer you push the rules from
Panorama to the firewalls, the rule you created locally has its own UUID.
Policy
• To replace an RMA Panorama, make sure you Retain Rule UUIDs when you load the named
Panorama configuraon snapshot. If you do not select this opon, Panorama removes all
previous rule UUIDs from the configuraon snapshot and assigns new UUIDs to the rules on
Panorama, which means it does not retain informaon associated with the previous UUIDs,
such as the policy rule hit count.
Policy
Display the Rule UUID column for logs and the UUID column for policy rules.
To view the UUIDs, you must display the column, which does not display by default.
• To display the UUID in logs:
1. Select Monitor and then expand the column header ( ).
2. Select Columns.
3. Enable Rule UUID.
• To display UUIDs on the policy rulebase:

1. Select Policies and then expand the column header ( ).
2. Select Columns.
3. Enable Rule UUID.
UUIDs are available for all policy rulebases.
Policy
Policy
Copy the UUID for a log or policy rule.

Copying the UUID allows you to paste the UUID in to searches, the ACC, custom reports,
filters, and anywhere else you want to locate a rule idenfied by that UUID.
1. Select the ellipses that display when you move your cursor over the entry in the Rule
UUID column.
2. Copy the UUID from the pop-up.
You can also go to the Policies tab, click the arrow to the right of the rule name, and
Copy UUID.
Check the Configuraon Logs to view UUIDs for deleted rules.

To view the UUID for a deleted rule, select Monitor > Logs > Configuraon.
Policy
Enforce Policy Rule Descripon, Tag, and Audit

Comment
When creang or modifying rules, you can require a rule descripon, tag, and audit comment to
ensure your policy rulebase is correctly organized and grouped, and to preserve important rule
history for auding purposes. By requiring a rule descripon, tag, and audit comment, you can
simplify your policy rulebase review by ensuring that rules are appropriately grouped, and that
the rule change history is tracked when creang or modifying a rule. For uniformity, you can set
specific requirements for what the audit comment can include.
By default, enforcement of a descripon, tag, and audit comment is not enabled. You can specify
whether a descripon, tag, audit comment, or any combinaon of these three is required to
successfully add or modify a rule. The audit comment archive allows you to view the audit
comments entered for a selected rule, review the configuraon log history, and compare rule
configuraon versions.
STEP 2 | Select Device > Setup > Management and edit the Policy Rulebase Sengs.
STEP 3 | Configure the sengs you want to enforce. In this example, tags and audit comments are
required for all policies.
Enforce audit comments for policy rules to capture the reason an administrator creates
or modifies a rule. Requiring audit comments on policy rules helps maintain an accurate
rule history for auding purposes.
STEP 4 | Configure the Audit Comment Regular Expression to specify the audit comment format.
When administrators create or modify a rule, you can require they enter a comment those
audit comments adhere to a specific format that fits your business and auding needs by
specifying leer and number expressions. For example, you can use this seng to specify
regular expressions that match your ckeng number formats:
• [0-9]{<Number of digits>}—Requires the audit comment to contain a minimum
number of digits that range from 0 to 9. For example, [0-9]{6} requires a minimum of six
digit in a numerical expression with numbers 0 to 9.
• <Letter Expression>—Requires the audit comment to contain a leer expression. For
example, Reason for Change- requires that the administrator begin the audit comment
with this leer expression.
• <Letter Expression>-[0-9]{<Number of digits>}—Requires the audit comment
to contain a predetermined character followed by a minimum number of digits that range
from 0 to 9. For example, SB-[0-9]{6} requires the audit comment format to begin with
SB-, followed by a minimum six digits in a numerical expression with values from 0 to 9. For
example, SB-012345.
• (<Letter Expression>)|(<Letter Expression>)|(<Letter
Expression>)|-[0-9]{<Number of digits>}—Requires the audit comment to
contain a prefix using any one of the predetermined leer expressions with a minimum
number of digits that range from 0 to 9. For example, (SB|XY|PN)-[0-9]{6} requires the
Policy
audit comment format to begin with SB-, XY-, or PN- followed by a minimum of six digits
in a numerical expression with values from 0 to 9. For example, SB-012345, XY-654321,
or PN-012543.
STEP 5 | Click OK to apply the new policy rulebase sengs.
STEP 6 | Commit the changes.
Aer you commit the policy rulebase sengs changes, modify the exisng policy rule
based on the rulebase sengs you decided to enforce.
Policy
STEP 7 | Verify that the firewall is enforcing the new policy rulebase sengs.
1. Select Policies and Add a new rule.
2. Confirm that you must add a tag and enter an audit comment click OK.
Policy
Move or Clone a Policy Rule or Object to a Different

Virtual System
On a firewall that has more than one virtual system (vsys), you can move or clone policy rules and
objects to a different vsys or to the Shared locaon. Moving and cloning save you the effort of
deleng, recreang, or renaming rules and objects. If the policy rule or object that you will move
or clone from a vsys has references to objects in that vsys, move or clone the referenced objects
also. If the references are to shared objects, you do not have to include those when moving or
cloning. You can Use Global Find to Search the Firewall or Panorama Management Server for
references.
When cloning mulple policy rules, the order by which you select the rules will determine
the order they are copied to the device group. For example, if you have rules 1-4 and your
selecon order is 2-1-4-3, the device group where these rules will be cloned will display
the rules in the same order you selected. However, you can reorganize the rules as you see
fit once they have been successfully copied.
STEP 1 | Select the policy type (for example, Policy > Security) or object type (for example, Objects >
Addresses).
STEP 2 | Select the Virtual System and select one or more policy rules or objects.
STEP 3 | Perform one of the following steps:

• Select Move > Move to other vsys (for policy rules).
• Click Move (for objects).
• Click Clone (for policy rules or objects).
STEP 4 | In the Desnaon drop-down, select the new virtual system or Shared.
STEP 5 | (Policy rules only) Select the Rule order:

• Move top (default)—The rule will come before all other rules.
• Move boom—The rule will come aer all other rules.
• Before rule—In the adjacent drop-down, select the rule that comes aer the Selected Rules.
• Aer rule—In the adjacent drop-down, select the rule that comes before the Selected Rules.
STEP 6 | The Error out on first detected error in validaon check box is selected by default. The
firewall stops performing the checks for the move or clone acon when it finds the first
error, and displays just this error. For example, if an error occurs when the Desnaon vsys
doesn’t have an object that the policy rule you are moving references, the firewall will display
the error and stop any further validaon. When you move or clone mulple items at once,
selecng this check box will allow you to find one error at a me and troubleshoot it. If you
clear the check box, the firewall collects and displays a list of errors. If there are any errors in
validaon, the object is not moved or cloned unl you fix all the errors.
Policy
STEP 7 | Click OK to start the error validaon. If the firewall displays errors, fix them and retry the
move or clone operaon. If the firewall doesn’t find errors, the object is moved or cloned
successfully. Aer the operaon finishes, click Commit.
Policy
Use an Address Object to Represent IP Addresses

Create an address object on the firewall to group IP addresses or to specify an FQDN, and then
reference the address object in a firewall policy rule, filter, or other funcon to avoid having to
individually specify mulple IP addresses in the rule, filter, or other funcon.
Furthermore, you can reference the same address object in mulple policy rules, filters, or other
funcons without needing to specify the same individual addresses in each use. For example, you
can create an address object that specifies an IPv4 address range and then reference the address
object in a Security policy rule, a NAT policy rule, and a custom report log filter.
• Address Objects
• Create an Address Object
Address Objects
An address object is a set of IP addresses that you can manage in one place and then use in
mulple firewall policy rules, filters, and other funcons. There are four types of address objects:
IP Netmask, IP Range, IP Wildcard Mask, and FQDN.
An address object of type IP Netmask, IP Range, or FQDN can specify IPv4 or IPv6 addresses. An
address object of type IP Wildcard Mask can specify only IPv4 addresses.
An address object of type IP Netmask requires you to enter the IP address or network using slash
notaon to indicate the IPv4 network or the IPv6 prefix length. For example, 192.168.18.0/24 or
2001:db8:123:1::/64.
An address object of type IP Range requires you to enter the IPv4 or IPv6 range of addresses
separated by a hyphen.
An address object of type FQDN (for example, paloaltonetworks.com) provides further ease of use
because DNS provides the FQDN resoluon to the IP addresses instead of you needing to know
the IP addresses and manually updang them every me the FQDN resolves to new IP addresses.
An address object of type IP Wildcard Mask is useful if you define private IPv4 addresses to
internal devices and your addressing structure assigns meaning to certain bits in the address. For
example, the IP address of cash register 156 in the northeastern U.S. could be 10.132.1.156 based
on these bit assignments:
An address object of type IP Wildcard Mask specifies which source or desnaon addresses are
subject to a Security policy rule. For example, 10.132.1.1/0.0.2.255. A zero (0) bit in the mask
indicates that the bit being compared must match the bit in the IP address that is covered by
the zero. A one (1) bit in the mask (a wildcard bit) indicates that the bit being compared need
not match the bit in the IP address. The following snippets of an IP address and wildcard mask
illustrate how they yield four matches:
Policy
Aer you Create an Address Object:

• You can reference an address object of type IP Netmask, IP Range, or FQDN in a policy rule for
Security, Authencaon, NAT, NAT64, Decrypon, DoS Protecon, Policy-Based Forwarding
(PBF), QoS, Applicaon Override, or Tunnel Inspecon; or in a NAT address pool, VPN tunnel,
path monitoring, External Dynamic List, Reconnaissance Protecon, ACC global filter, log filter,
or custom report log filter.
• You can reference an address object of type IP Wildcard Mask only in a Security policy rule.
Create an Address Object

Create Address Objects to represent one or more IP addresses and then reference the address
objects in one or more policy rules, filters, or other firewall funcons. If you want to change the
set of addresses, you change an address object once rather than change mulple policy rules or
filters, which reduces your operaonal overhead.
STEP 1 | Create an address object.
1. Select Objects > Addresses and Add an address object by Name. The name is case-
sensive, must be unique, and can be up to 63 characters (leers, numbers, spaces,
hyphens, and underscores).
2. Select the Type of address object:
• IP Netmask—Specify a single IPv4 or IPv6 address, an IPv4 network with slash
notaon, or an IPv6 address and prefix. For example, 192.168.80.0/24 or
2001:db8:123:1::/64. Oponally, click Resolve to see the associated FQDN (based
on the DNS configuraon of the firewall or Panorama). To change the address object
type from IP Netmask to FQDN, select the FQDN and click Use this FQDN. The Type
changes to FQDN and the FQDN you select appears in the text field.
• IP Range—Specify a range of IPv4 addresses or IPv6 addresses
separated by a hyphen. For example, 192.168.40.1-192.168.40.255 or
2001:db8:123:1::1-2001:db8:123:1::22.
• IP Wildcard Mask—Specify an IP wildcard address (IPv4 address followed by a slash
and a mask, which must begin with a 0). For example, 10.5.1.1/0.127.248.2. A zero
(0) in the mask indicates the bit being compared must match the bit in the IP address
that is covered by the zero. A one (1) in the mask (wildcard bit) indicates the bit being
compared need not match the bit in the IP address covered by the one.
• FQDN—Specify the domain name. The FQDN inially resolves at commit me. The
firewall subsequently refreshes the FQDN based on the me-to-live (TTL) of the
FQDN in DNS, as long as the TTL is greater than or equal to the Minimum FQDN
Refresh Time you configure (or the default of 30 seconds). The FQDN is resolved
by the system DNS server or a DNS proxy object, if a proxy is configured. Click
Resolve to see the associated IP address (based on the DNS configuraon of the
Policy
firewall or Panorama). To change the address object type from FQDN to IP Netmask,
select an IP Netmask and click Use this address. The Type changes to IP Netmask and
the IP address you select appears in the text field.
3. (Oponal) Enter one or more Use Tags to Group and Visually Disnguish Objects to apply
to the address object.
4. Click OK.
STEP 3 | View logs filtered by address object, address group, or wildcard address.
1. For example, select Monitor > Logs > Traffic to view traffic logs.
2. Select to add a log filter.
3. Select the Address aribute, the in Operator, and enter the name of the address object
for which you want to view logs. Alternavely, enter an address group name or a
wildcard address, such as 10.155.3.4/0.0.240.255.
4. Click Apply.
STEP 4 | View a custom report based on an address object.

1. Select Monitor > Manage Custom Reports and select a report that uses a Database such
as Traffic Log.
2. Select Filter Builder.
3. Select an Aribute such as Address, Desnaon Address or Source Address, select
an Operator, and enter the name of the address object for which you want to view the
report.
STEP 5 | Use a filter in the ACC to view network acvity based on a source IP address or desnaon
IP address that uses an address object.
1. Select ACC > Network Acvity.
2. View the Source IP Acvity—For Global Filters, click to add a filter and select one
of the following: Address or Source > Source Address or Desnaon > Desnaon
Address and select an address object.
3. View the Desnaon IP Acvity—For Global Filters, click the to add a filter and select
one of the following: Address or Source > Source Address or Desnaon > Desnaon
Address and select an address object.
Policy
Use Tags to Group and Visually Disnguish Objects

You can tag objects to group related items and add color to the tag in order to visually disnguish
them for easy scanning. You can create tags for the following objects: address objects, address
groups, user groups, zones, service groups, and policy rules.
The firewall and Panorama support both stac tags and dynamic tags. Dynamic tags are registered
from a variety of sources and are not displayed with the stac tags because dynamic tags are
not part of the configuraon on the firewall or Panorama. See Register IP Addresses and Tags
Dynamically for informaon on registering tags dynamically. The tags discussed in this secon are
stacally added and are part of the configuraon.
You can apply one or more tags to objects and to policy rules, up to a maximum of 64 tags per
object. Panorama supports a maximum of 10,000 tags, which you can apporon across Panorama
(shared and device groups) and the managed firewalls (including firewalls with mulple virtual
systems).
• Create and Apply Tags
• Modify Tags
• View Rules by Tag Group
Create and Apply Tags

Use tags to idenfy the purpose of a rule or configuraon object and to help you beer organize
your rulebase. To ensure that policy rules are properly tagged, see how to Enforce Policy Rule
Descripon, Tag, and Audit Comment. Addionally, you can View Rules by Tag Group by first
creang and then seng the tag as the Group tag.
Policy
STEP 1 | Create tags.
To tag a zone, you must create a tag with the same name as the zone. When the zone
is aached in policy rules, the tag color automacally displays as the background color
against the zone name.
1. Select Objects > Tags.

2. On Panorama or a mulple virtual system firewall, select the Device Group or the Virtual
System to make the tag available.
3. Add a tag and enter a Name to idenfy the tag or select a zone Name to create a tag for
a zone. The maximum length is 127 characters.
4. (Oponal) Select Shared to create the object in a shared locaon for access as a shared
object in Panorama or for use across all virtual systems in a mulple virtual system
firewall.
5. (Oponal) Assign a Color from the 17 predefined colors. By default, Color is None.
6. Click OK and Commit to save your changes.
STEP 2 | Apply tags to policy.

1. Select Policies and any rulebase under it.
2. Add a policy rule and use the tagged objects you created in Step 1.
3. Verify that the tags are in use.
STEP 3 | Apply tags to an address object, address group, service, or service group.
1. Create the object.
For example, to create a service group, select Objects > Service Groups > Add.
2. Select a tag (Tags) or enter a name in the field to create a new tag.
To edit a tag or add color to the tag, see Modify Tags.
Modify Tags
Policy
Select Objects > Tags to perform any of the following operaons with tags:
• Click the Name to edit the properes of a tag.
• Select a tag in the table and Delete the tag from the firewall.
• Clone a tag to duplicate it with the same properes. A numerical suffix is added to the tag
name (for example, FTP-1).
For details on creang tags, see Create and Apply Tags. For informaon on working with tags,
see View Rules by Tag Group.
View Rules by Tag Group

View your policy rulebase as tag groups to visually group rules based on the tagging structure
you created. In this view, you can perform operaonal procedures such as adding, deleng,
and moving the rules in the selected tag group more easily. Viewing the rulebase as tag groups
maintains the rule evaluaon order and a single tag may appear mulple mes throughout the
rulebase to visually preserve the rule hierarchy.
You must create the tag before you can assign it as a group tag on a rule. Policy rules that are
already tagged on upgrade to PAN-OS 9.0 have the first tag automacally assigned as the Group
tag. Before you upgrade to PAN-OS 9.0, review the tagged rules in your rulebase to ensure rules
are correctly grouped. You must manually edit each tag rule and configure the correct Group tag if
your rules are grouped incorrectly aer you upgrade to PAN-OS 9.0.
STEP 2 | Create and Apply Tags you want to use for grouping rules.
STEP 3 | Assign a policy rule to a tag group.

1. Create a policy rule. Refer to Policy for more informaon on creang policy rules.
2. In the Group Rules by Tag field, select the tag from the drop-down and click OK.
Policy
STEP 4 | View your policy rulebase as groups.

1. (Panorama only) From the Device Group, select the device group rulebase to view or
view all Shared rules.
2. Click Policies and select the rulebase where you created the rules in Step 2.
3. Select the View Rulebase as Groups opon (at the boom).
Rules not assigned a tag group display as None.
STEP 5 | Perform Group operaons as needed.

1. Click Group to perform group operaons for rules in the selected tag group.
• (Panorama only) Move rules in group to a different rulebase or device group—Move
all policy rules in the selected tag group to the Pre-Rulebase or Post-Rulebase or
move them to a different device group.
• Change group of all rules—Move all rules in the selected tag group to a different tag
group.
• Move all rules in group—Move all rules in the selected tag group to change the rule
priority order.
• Delete all rules in group—Delete all rules in the selected tag group.
• Clone all rules in group—Clone all rules in the selected tag group.
Policy
Use an External Dynamic List in Policy

An external dynamic list (formerly called dynamic block list) is a text file that you or another
source hosts on an external web server so that the firewall can import objects—IP addresses,
URLs, domains—to enforce policy on the entries in the list. As the list is updated, the firewall
dynamically imports the list at the configured interval and enforces policy without the need to
make a configuraon change or a commit on the firewall.
• External Dynamic List
• Formang Guidelines for an External Dynamic List
• Built-in External Dynamic Lists
• Configure the Firewall to Access an External Dynamic List
• Configure the Firewall to Access an External Dynamic List from the EDL Hosng Service
• Retrieve an External Dynamic List from the Web Server
• View External Dynamic List Entries
• Exclude Entries from an External Dynamic List
• Enforce Policy on an External Dynamic List
• Find External Dynamic Lists That Failed Authencaon
• Disable Authencaon for an External Dynamic List
External Dynamic List

An External Dynamic List is a text file that is hosted on an external web server so that the firewall
can import objects—IP addresses, URLs, domains, Internaonal Mobile Equipment Idenes
(IMEIs), Internaonal Mobile Subscriber Idenes (IMSIs)—included in the list and enforce policy.
To enforce Security policy on the entries included in the external dynamic list, you must reference
the list in a supported policy rule or profile. When mulple lists are referenced, you can priorize
the order of evaluaon to make sure the most important EDLs are commied before capacity
limits are reached. As you modify the list, the firewall dynamically imports the list at the configured
interval and enforces policy without the need to make a configuraon change or a commit on
the firewall. If the web server is unreachable, the firewall uses the last successfully retrieved
list for enforcing policy unl the connecon is restored with the web server. In cases where
authencaon to the EDL fails, the security policy stops enforcing the EDL. To retrieve the
external dynamic list, the firewall uses the interface configured with the Palo Alto Networks
Services service route.
The firewall supports these types of external dynamic lists:
• Predefined IP Address—A predefined IP address list is a type of IP address list that refers
to the built-in, dynamic IP lists with fixed or “predefined” contents. These Built-In External
Dynamic Lists—for bulletproof hosng providers, known malicious, and high-risk IP addresses
—are automacally added to your firewall if you have an acve Threat Prevenon license. A
predefined IP address list can also refer to an EDL that uses one of the built-in lists as a source.
Because you can’t modify the contents of a predefined list, you can use a predefined list as a
source for a different EDL if you want to add or exclude list entries.
Policy
• Predefined URL List—This type of external dynamic list contains pre-populated URLs that
applicaons use for background services, such as updates or Cerficate Revocaon List
(CRL) checks, that the firewall can safely exclude from Authencaon policy. Palo Alto
Networks revises and maintains this type of external dynamic list, which is also known as an
Authencaon Portal Exclude List, through content updates.
• IP Address—The firewall typically enforces policy for a source or desnaon IP address that is
defined as a stac object on the firewall (see Enforce Policy on an External Dynamic List) If you
need agility in enforcing policy for a list of source or desnaon IP addresses that emerge ad
hoc, you can use an external dynamic list of type IP address as a source or desnaon address
object in policy rules, and configure the firewall to deny or allow access to the IP addresses
(IPv4 and IPv6 address, IP range and IP subnets) included in the list. You can also use an IP
address EDL in the source or desnaon of an SD-WAN policy rule. The firewall treats an
external dynamic list of type IP address as an address object; all the IP addresses included in a
list are handled as one address object.
• Domain—This type of external dynamic list allows you to import custom domain names into
the firewall to enforce policy using an An-Spyware profile or SD-WAN policy rule. An EDL
in an An-Spyware profile is very useful if you subscribe to third-party threat intelligence
feeds and want to protect your network from new sources of threat or malware as soon as
you learn of a malicious domain. For each domain you include in the external dynamic list,
the firewall creates a custom DNS-based spyware signature so that you can enable DNS
sinkholing. The DNS-based spyware signature is of type spyware with medium severity and
each signature is named Custom Malicious DNS Query <domain name>. You can
also specify the firewall to include the subdomains of a specifed domain. For example, if
your domain list includes paloaltonetworks.com, all lower level components of the domain
name (e.g., *.paloaltonetworks.com) will also be included as part of the list. When this seng
is enabled, each domain in a given list requires an addional entry, effecvely doubling the
number of entries used by the list. For details on configuring domain lists, see Configure DNS
Sinkholing for a List of Custom Domains.
• URL—This type of external dynamic list gives you the agility to protect your network from new
sources of threat or malware. The firewall handles an external dynamic list with URLs like a
custom URL category and you can use this list in two ways:
• As a match criterion in Security policy rules, Decrypon policy rules, and QoS policy rules
to allow, deny, decrypt, not decrypt, or allocate bandwidth for the URLs in the custom
category.
• In a URL Filtering profile where you can define more granular acons, such as connue,
alert, or override, before you aach the profile to a Security policy rule (see Use an External
Dynamic List in a URL Filtering Profile).
• Equipment Identy—You can reference an external dynamic list of IoT devices defined by
Internaonal Mobile Equipment Idenes (IMEIs) in a Security policy rule that controls traffic
for equipment connected to a 5G or 4G network. Refer to the Mobile Network Infrastructure
Geng Started for informaon about configuring Equipment ID security on supported firewall
models.
• Subscriber Identy—You can reference an external dynamic list of Internaonal Mobile
Subscriber Idenes (IMSIs) in a Security policy rule that controls traffic for subscribers
connected to a 5G or 4G network. Refer to the Mobile Network Infrastructure Geng Started
for informaon about configuring Subscriber ID security on supported firewall models.
Policy
On each firewall model, you can add a maximum of 30 custom EDLs with unique sources to a
single policy rule to enforce policy. The external dynamic list limit is not applicable to Panorama.
When using Panorama to manage a firewall that is enabled for mulple virtual systems, if you
exceed the limit for the firewall, a commit error displays on Panorama. A source is a URL that
includes the IP address or hostname, the path, and the filename for the external dynamic list. The
firewall matches the URL (complete string) to determine whether a source is unique.
While the firewall does not impose a limit on the number of lists of a specific type, the following
limits are enforced:
• IP address—The PA-5200 Series and the PA-7000 Series firewalls support a maximum of
150,000 total IP addresses; all other models support a maximum of 50,000 total IP addresses.
No limits are enforced for the number of IP addresses per list. When the maximum supported
IP address limit is reached on the firewall, the firewall generates a syslog message. The IP
addresses in predefined IP address lists do not count toward the limit.
• URL and domain—The maximum number of URLs and domains supported varies by model.
No limits are enforced for the number of URL or domain entries per list. Refer to the following
table for specifics on your model:
Model URL List Entry Limits Domain List Entry Limits
PA-5200 Series, PA-7000 250,000 4,000,000

Series (upgraded with the
PA-7000 20GXM NPC,
PA-7000 20GQXM NPC,
or the PA-7000 100G
NPC).
PA-7000
appliances
with mixed
NPCs only
support the
standard
capacies.
VM-500, VM-700 100,000 2,000,000
PA-850, PA-820, 100,000 1,000,000

PA-3200 Series
PA-7000 Series (and 100,000 500,000

appliances upgraded
with the PA-7000 20GQ
NPC or the PA-7000 20G
NPC), VM-300
Policy
Model URL List Entry Limits Domain List Entry Limits
PA-220, VM-50, 50,000 50,000

VM-50 (Lite), VM-100,
VM-1000-HV
List entries only count toward the firewall limits if they belong to an external dynamic list that is
referenced in policy.
• When parsing the list, the firewall skips entries that do not match the list type, and
ignores entries that exceed the maximum number supported for the model. To ensure
that the entries do not exceed the limit, check the number of entries currently used in
policy. Select Objects > External Dynamic Lists and click List Capacies.
• An external dynamic list must contain entries. If you want to stop using the list, remove
the reference from the policy rule or profile instead leaving the list blank. If the list does
not contain any entries, the firewall fails to refresh the list and connues to use the last
informaon it retrieved.
• As a best pracce, Palo Alto Networks recommends using shared EDLs when mulple
virtual systems are used. Using individual EDLs with duplicate entries for each virtual
system uses more memory, which might over-ulize firewall resources.
• EDL entry counts on firewalls operang mul-virtual systems take addional factors
into account (such as DAGs, number of virtual systems, rules bases) to generate a more
accurate capacity consumpon lisng. This might result in a discrepancy in capacity
usage aer upgrading from PAN-OS 8.x releases.
• Depending on the features enabled on the firewall, memory usage limits might be
exceeded before EDL capacity limits are met due to memory allocaon updates. As a
best pracce, Palo Alto Networks recommends reviewing EDL capacies and, when
necessary, removing or consolidang EDLs into shared lists to minimize memory usage.
Formang Guidelines for an External Dynamic List

An external dynamic list of one type —IP address, URL or Domain—must include entries of that
type only. The entries in a predefined IP address list comply with the formang guidelines for IP
address lists.
• IP Address List
• Domain List
• URL List
IP Address List
The external dynamic list can include individual IP addresses, subnet addresses (address/mask),
or range of IP addresses. In addion, the block list can include comments and special characters
such as * , : , ; , #, or /. The syntax for each line in the list is [IP address, IP/Mask, or IP
start range-IP end range] [space] [comment].
Enter each IP address/range/subnet in a new line; URLs or domains are not supported in this list.
A subnet or an IP address range, such as 92.168.20.0/24 or 192.168.20.40-192.168.20.50, count
Policy
as one IP address entry and not as mulple IP addresses. If you add comments, the comment must
be on the same line as the IP address/range/subnet. The space at the end of the IP address is the
delimiter that separates a comment from the IP address.
An example IP address list:
192.168.20.10/32
2001:db8:123:1::1 #test IPv6 address
192.168.20.0/24 ; test internal subnet
2001:db8:123:1::/64 test internal IPv6 range
192.168.20.40-192.168.20.50
For an IP address that is blocked, you can display a noficaon page only if the protocol is
HTTP.
Domain List
You can use placeholder characters in domain lists to configure a single entry to match against
mulple website subdomains, pages, including enre top-level domains, as well as matches to
specific web pages.
Follow these guidelines when creang domain list entries:
• Enter each domain name in a new line; URLs or IP addresses are not supported in this list.
• Do not prefix the domain name with the protocol, hp:// or hps://.
• You can use an asterisk (*) to indicate a wildcard value.
• You can use a caret (^) to indicate an exact match value.
• The following characters are considered token separators: . / ? & = ; +
Every string separated by one or two of these characters is a token. Use wildcard characters as
token placeholders, indicang that a specific token can contain any value.
• Wildcard characters must be the only character within a token; however, an entry can contain
mulple wildcards.
• Each domain entry can be up to 255 characters in length.
When to use the asterisk (*) wildcard:
Use an asterisk (*) wildcard to indicate one or mulple variable subdomains. For example,
to specify enforcement for Palo Alto Network’s website regardless of the domain extension
used, which might be one or two subdomains depending on locaon, you would add the entry:
*.paloaltonetworks.com. This entry would match to both docs.paloaltonetworks.com and
support.paloaltonetworks.com.
You can also use this wildcard to indicate enre top-level domains. For example, to specify
enforcement of a TLD named .work, you would add the entry *.work. This matches all websites
ending with .work.
The (*) wildcard can only be prepended in domain entries.
Asterisk (*) examples
Policy
EDL Domain List Entry Matching Sites
*.company.com eng.tools.company.com
tools.company.com
docs.company.com
*.click all websites ending with a top-level domain

of .click.
When to use a caret (^) character:

Use carets (^) to indicate an exact match of a subdomain. For example,
^paloaltonetworks.com matches only paloaltonetworks.com. This entry does not match to
any other site.
Caret (^) examples
EDL Domain List Entry Matching Site
^company.com company.com
êng.company.com eng.company.com
URL List
See URL Category Excepons.
Built-in External Dynamic Lists

With an acve Threat Prevenon license, Palo Alto Networks provides built-in IP address EDLs
that you can use to protect against malicious hosts.
• Palo Alto Networks Bulletproof IP Addresses—Contains IP addresses provided by bulletproof
hosng providers. Because bulletproof hosng providers place few, if any, restricons on
content, aackers frequently use these services to host and distribute malicious, illegal, and
unethical material.
• Palo Alto Networks High-Risk IP Addresses—Contains malicious IP addresses from threat
advisories issued by trusted third-party organizaons. Palo Alto Networks compiles the list of
threat advisories, but does not have direct evidence of the maliciousness of the IP addresses.
• Palo Alto Networks Known Malicious IP Addresses—Contains IP addresses that are verified
malicious based on WildFire analysis, Unit 42 research, and data gathered from telemetry
(Share Threat Intelligence with Palo Alto Networks). Aackers use these IP addresses almost
exclusively to distribute malware, iniate command-and-control acvity, and launch aacks.
• Palo Alto Networks Tor Exit IP Addresses—Contains IP addresses supplied by mulple
providers and validated with Palo Alto Networks threat intelligence data as acve
Policy
Tor exit nodes. Traffic from Tor exit nodes can serve a legimate purpose, however, is
disproporonately associated with malicious acvity, especially in enterprise environments.
The firewall receives updates for these feeds in content updates, allowing the firewall to
automacally enforce policy based on the latest threat intelligence from Palo Alto Networks. You
cannot modify the contents of the built-in lists. Use them as-is (see Enforce Policy on an External
Dynamic List), or create a custom external dynamic list that uses one of the lists as a source (see
Configure the Firewall to Access an External Dynamic List) and exclude entries from the list as
needed.
Configure the Firewall to Access an External Dynamic List

You must establish the connecon between the firewall and the source that hosts the external
dynamic list before you can Enforce Policy on an External Dynamic List.
STEP 1 | (Oponal) Customize the service route that the firewall uses to retrieve external dynamic
lists.
Select Device > Setup > Services > Service Route Configuraon > Customize and modify the
External Dynamic Lists service route.
The firewall does not use the External Dynamic Lists service route to retrieve Built-in
External Dynamic Lists; content updates modify or update the contents of those lists
(acve Threat Prevenon license required).
Policy
STEP 2 | Find an external dynamic list to use with the firewall.

• Create an external dynamic list and host it on a web server. Enter IP addresses, domains, or
URLs in a blank text file. Each list entry must be on a separate line. For example:
financialtimes.co.in
www.wallaby.au/joey
www.exyang.com/auto-tutorials/How-to-enter-Data-for-Success.aspx
See the Formang Guidelines for an External Dynamic List to ensure that the firewall does
not skip list entries. To prevent commit errors and invalid entries, do not prefix hp:// or
hps:// to any of the entries.
• Use an external dynamic list hosted by another source and verify that it follows the
Formang Guidelines for an External Dynamic List.
STEP 3 | Select Objects > External Dynamic Lists.
STEP 4 | Click Add and enter a descripve Name for the list.
STEP 5 | (Oponal) Select Shared to share the list with all virtual systems on a device that is enabled
for mulple virtual systems. By default, the object is created on the virtual system that is
currently selected in the Virtual Systems drop-down.
As a best pracce, Palo Alto Networks recommends using shared EDLs when mulple
virtual systems are used. Using individual EDLs with duplicate entries for each vsys
uses more memory, which might over-ulize firewall resources.
STEP 6 | (Panorama only) Select Disable override to ensure that a firewall administrator cannot
override sengs locally on a firewall that inherits this configuraon through a Device Group
commit from Panorama.
STEP 7 | Select the list Type (for example, URL List).

Ensure that the list only includes entries for the list type. See Verify whether entries in the
external dynamic list were ignored or skipped.
If you using a Domain List, you can oponally enable Automacally expand to include
subdomains to also include the subdomains of a specified domain. For example, if your domain
list includes paloaltonetworks.com, all lower level components of the domain name (e.g.,
*.paloaltonetworks.com) will also be included as part of the list. Keep in mind, when this seng
is enabled, each domain in a given list requires an addional entry, effecvely doubling the
number of entries that are consumed.
STEP 8 | Enter the Source for the list you just created on the web server. The source must include the
full path to access the list. For example, https://1.2.3.4/EDL_IP_2015.
• If you are creang a Predefined IP external dynamic list, select a Palo Alto Networks
malicious IP address feed to use as a source.
• If you are creang a Predefined URL external dynamic list, select panw-auth-portal-
exclude-list as a source.
Policy
STEP 9 | If the list source is secured with SSL (i.e. lists with an HTTPS URL), enable server
authencaon. Select a Cerficate Profile or create a New Cerficate Profile for
authencang the server that hosts the list. The cerficate profile you select must have
root cerficate authority (CA) and intermediate CA cerficates that match the cerficates
installed on the server you are authencang.
Maximize the number of external dynamic lists that you can use to enforce policy. Use
the same cerficate profile to authencate external dynamic lists from the same source
URL. If you assign different cerficate profiles to external dynamic lists from the same
source URL, the firewall counts each list as a unique external dynamic list.
STEP 10 | Enable client authencaon if the list source has an HTTPS URL and requires basic HTTP
authencaon for list access.
1. Select Client Authencaon.
2. Enter a valid Username to access the list.
3. Enter the Password and Confirm Password.
STEP 11 | (Not available on Panorama or for Predefined URL EDLs) Click Test Source URL to verify that
the firewall can connect to the web server.
The Test Source URL funcon is not available when authencaon is used for EDL
access.
STEP 12 | (Oponal) Specify the frequency at which the firewall should Check for updates to the list.
By default, the firewall retrieves the list once every hour and commits the changes.
The interval is relave to the last commit. So, for the five-minute interval, the commit
occurs in 5 minutes if the last commit was an hour ago. To retrieve the list immediately,
see Retrieve an External Dynamic List from the Web Server.
Policy
STEP 14 | (Oponal) EDLs are shown top to boom, in order of evaluaon. Use the direconal controls
at the boom of the page to change the list order. This allows you to or order the lists to
make sure the most important EDLs are commied before capacity limits are reached.
You can only change the EDL order when Group By Type is deselected.
STEP 15 | Enforce Policy on an External Dynamic List.
If the server or client authencaon fails, the firewall ceases to enforce policy based on
the last successfully retrieved external dynamic list. Find External Dynamic Lists That
Failed Authencaon and view the reasons for authencaon failure.
Configure the Firewall to Access an External Dynamic List from the

EDL Hosng Service
Configure the firewall to access an external dynamic list (EDL) from the EDL Hosng Service for
Soware-as-a-Service (SaaS) applicaons
• Create an External Dynamic List Using the EDL Hosng Service
• Convert the GlobalSign Root R1 Cerficate to PEM Format
Create an External Dynamic List Using the EDL Hosng Service

Some Soware-as-a-Service (SaaS) providers publish lists of IP addresses and URLs as desnaon
endpoints for their SaaS applicaons. SaaS providers frequently update the SaaS applicaons
desnaon endpoint lists as support grows and the service expands. This requires you to manually
monitor the SaaS applicaon endpoints for changes and manually update your policy configuraon
to ensure connecvity to these crical SaaS applicaons or set up an external tool to monitor and
update your EDLs.
Configure an EDL using the EDL Hosng Service maintained by Palo Alto Networks to ease
the operaonal burden of maintaining an EDL for a SaaS applicaon. The EDL Hosng Service
provides publicly available Feed URLs for SaaS applicaon endpoints published by the SaaS
applicaon provider. Leveraging a Feed URL as the source in an EDL allows for dynamic
enforcement of SaaS applicaon traffic without the need for you to host and maintain your own
EDL source.
Palo Alto Networks checks the applicaon Feed URLs published by SaaS providers on a daily
basis. For IP based feeds, Palo Alto Networks performs opmizaons to combine entries from a
connuous netmask and deduplicaon is performed if endpoints overlap across mulple areas.
Addionally, the endpoints for the Microso 365 Common and Office Online SaaS applicaon are
always added to every Feed URL in the EDL Hosng Service.
Microso updates all Microso 365 Feed URLs at the end of each calendar month and provides
a 30 day advanced noce prior to update. See the official Microso 365 Web Services page for
more informaon. The EDL Hosng Service availability status and updates are posted to the Palo
Alto Networks Cloud Services Status page.
STEP 1 | Visit the EDL Hosng Service and idenfy the Feed URL for your SaaS applicaon.
Review the Microso 365 documentaon for more informaon which Feed URL is best for
your use case. Addionally, consider the SaaS applicaon and locaon of users accessing
Policy
the SaaS applicaon when idenfying a Feed URL to. For example, if you have a branch in
Germany that only needs to access Exchange Online, select a Feed URL from the Service Area:
Exchange Online for Germany.
For a policy-based forwarding policy rule, use an IP-based Feed URL.
Policy
STEP 2 | (Best Pracces) Create a cerficate profile to authencate the EDL Hosng Service.
1. Download the GlobalSign Root R1 cerficate.
2. Convert the GlobalSign Root R1 Cerficate to PEM Format.
3. Launch the firewall web interface.
4. Import the GlobalSign Root R1 cerficate.
1. Select Device > Cerficate Management > Cerficates and Import a new cerficate.
2. For Cerficate Type, select Local.
3. Enter a descripve Cerficate Name.
4. For the Cerficate File, select Browse and select the cerficate you converted in the
previous step.
5. For the File Format, select Base64 Encoded Cerficate (PEM).
6. Click OK.
5. Create a cerficate authority (CA) cerficate profile.

1. Select Device > Cerficate Management > Cerficate Profile and Add a new
cerficate profile.
2. Enter a descripve Name.
3. For the CA Cerficates, Add the cerficate you imported in the previous step.
4. Click OK.
Policy
6. Commit.
Policy
STEP 3 | Create an EDL using a Feed URL from the EDL Hosng Service.
1. Select Objects > External Dynamic Lists and Add a new EDL.
2. Enter a descripve Name for the EDL.
3. Select the EDL Type.
• For an IP-based EDL, select IP List.
• For a URL-based EDL, select URL List.
4. (Oponal) Enter a Descripon for the EDL
5. Enter the Feed URL as the EDL Source.
Enforce all endpoints within a specific Feed URL. Adding an excluding a specific
endpoint from a Feed URL can cause connecvity issues to the SaaS applicaon.
6. (Best Pracces) Select the Cerficate Profile you created in the previous step.
7. Specify the frequency the firewall should Check for updates to match the update
frequency of the Feed URL.
For example, if the Feed URL is updated daily by Palo Alto Networks then configure the
EDL to check for updates Daily.
Palo Alto Networks displays the update frequency for each Feed URL in the EDL Hosng
Service. Feed URLs are automacally updated with any new endpoints.
8. Click Test Source URL to verify that the firewall can access the Feed URL from the EDL
Hosng Service.
9. Click OK.
Policy
STEP 4 | Enforce Policy on an External Dynamic List.

When you enforce policy on an EDL from the EDL Hosng Service where the EDL is the
source, be specific when configuring which users have access to the SaaS applicaon to avoid
over-provisioning access to the applicaon.
Leverage App-ID alongside EDLs in a policy rule for addional strict enforcement of
SaaS applicaon traffic.
Convert the GlobalSign Root R1 Cerficate to PEM Format

You must convert the GlobalSign Root R1 cerficate to PEM format to create a cerficate profile
for authencang the EDL Hosng Service. Creang the cerficate profile to authencate the
EDL Hosng Service is a best pracce when leveraging the EDL Hosng Service when you
configure the firewall to access an external dynamic list from the EDL Hosng Service.
Refer to the appropriate procedure based on operang system of the device where you
downloaded the GlobalSign Root R1 cerficate.
STEP 1 | Download the GlobalSign Root R1 cerficate if you have not already downloaded the
cerficate.
Policy
STEP 2 | Convert the cerficate.

• Mac and Linux operang systems
1. Open the terminal and convert the GlobalSign Root R1 cerficate you downloaded.
admin: openssl x509 -in <certificate-path>.crt -inform DER -out

<target-export-path>.pem -outform PEM
If no target export path is specified, the converted cerficate is created on the

device desktop.
• Windows operang system
1. Navigate to the locaon where you downloaded the GlobalSign Root1 cerficate.
2. Double click and Open the cerficate.
3. Click Details and Copy to File.
Click Next when prompted to connue.
4. Select Base-64 encoded x.509 (.CER) and click Next
5. Click Browse to navigate to the locaon you want to copy the cerficate and enter a name
for the cerficate that includes .pem appended to the end of file name. For example,
globalsign-root-r1.pem
Save the cerficate. The File Name displayed shows the target export path and the
cerficate name you entered with .cer appended. Delete the appended.cer.
6. Click Next and Finish exporng the cerficate.
Policy
Retrieve an External Dynamic List from the Web Server

When you Configure the Firewall to Access an External Dynamic List, you can configure the
firewall to retrieve the list from the web server on an hourly (default)five minute, daily, weekly,
or monthly basis. If you have added or deleted IP addresses from the list and need to trigger an
immediate refresh, use the following process to fetch the updated list.
STEP 1 | To retrieve the list on demand, select Objects > External Dynamic Lists.
STEP 2 | Select the list that you want to refresh, and click Import Now. The job to import the list is
queued.
STEP 3 | To view the status of the job in the Task Manager, see Manage and Monitor Administrave
Tasks.
STEP 4 | (Oponal) Aer the firewall retrieves the list, View External Dynamic List Entries.
View External Dynamic List Entries

Before you Enforce Policy on an External Dynamic List, you can view the contents of an external
dynamic list directly on the firewall to check if it contains certain IP addresses, domains, or URLs.
The entries displayed are based on the version of the external dynamic list that the firewall most
recently retrieved.
STEP 1 | Select Objects > External Dynamic Lists.
STEP 2 | Click the external dynamic list you want to view.
Policy
STEP 3 | Click List Entries and Excepons and view the objects that the firewall retrieved from the list.
The list might be empty if:

• The EDL has not yet been applied to a Security policy rule. To apply an EDL to a Security
policy rule and populate the EDL, see Enforce Policy on an External Dynamic List.
• The firewall has not yet retrieved the external dynamic list. To force the firewall to retrieve
an external dynamic list immediately, Retrieve an External Dynamic List from the Web
Server.
• The firewall is unable to access the server that hosts the external dynamic list. Click Test
Source URL to verify that the firewall can connect to the server.
STEP 4 | Enter an IP address, domain, or URL (depending on the type of list) in the filter field and
Apply Filter ( ) to check if it’s in the list. Exclude Entries from an External Dynamic List
based on which IP addresses, domains, and URLs you need to block or allow.
STEP 5 | (Oponal) View the AutoFocus Intelligence Summary for a list entry. Hover over an entry to
open the drop-down and then click AutoFocus.
Exclude Entries from an External Dynamic List

As you view the entries of an external dynamic list, you can exclude up to 100 entries from the
list. The ability to exclude entries from an external dynamic list gives you the opon to enforce
policy on some (but not all) of the entries in a list. This is helpful if you cannot edit the contents of
an external dynamic list (such as the Palo Alto Networks High-Risk IP Addresses feed) because it
comes from a third-party source.
STEP 1 | View External Dynamic List Entries.
Policy
STEP 2 | Select up to 100 entries to exclude from the list and click Submit ( ) or manually Add a list
excepon.
• You cannot save your changes to the external dynamic list if you have duplicate entries
in the Manual Excepons list. To idenfy duplicate entries, look for entries with a red
underline.
• A manual excepon must match a list entry exactly. Addionally, you cannot exclude a
specific IP address from within an IP address range. To exclude a specific IP address from an
IP address range, you must add each IP address in the range as a list entry and then exclude
the desired IP address.
The firewall does not support excluding an individual IP address from an IP address range.
STEP 3 | Click OK and Commit to save your changes.
STEP 4 | (Oponal) Enforce Policy on an External Dynamic List.
Enforce Policy on an External Dynamic List

Block or allow traffic based on IP addresses or URLs in an external dynamic list, or use a dynamic
domain list with a DNS sinkhole to prevent access to malicious domains.
Tips for enforcing policy on the firewall with external dynamic lists:
• When viewing external dynamic lists on the firewall (Objects > External Dynamic
Lists), click List Capacies to compare how many IP addresses, domains, and URLs are
currently used in policy with the total number of entries that the firewall supports for
each list type.
• Use Global Find to Search the Firewall or Panorama Management Server for
a domain, IP address, or URL that belongs to one or more external dynamic lists is
used in policy. This is useful for determining which external dynamic list (referenced
in a Security policy rule) is causing the firewall to block or allow a certain domain, IP
address, or URL.
• Use the direconal controls at the boom of the page to change the evaluaon order of
EDLs. This allows you to or order the lists to make sure the most important entries in an
EDL are commied before capacity limits are reached.
You can only change the EDL order when Group By Type is deselected.
Configure DNS Sinkholing for a List of Custom Domains.
Use an External Dynamic List in a URL Filtering Profile.
Policy
Use an External Dynamic List of Type URL as Match Criteria in a Security Policy Rule.
2. Click Add and enter a descripve Name for the rule.
3. In the Source tab, select the Source Zone.
4. In the Desnaon tab, select the Desnaon Zone.
5. In the Service/URL Category tab, click Add to select the appropriate external dynamic
list from the URL Category list.
6. In the Acons tab, set the Acon Seng to Allow or Deny.
8. Verify whether entries in the external dynamic list were ignored or skipped.
Use the following CLI command on a firewall to review the details for a list.
request
system external-list show type <domain | ip | url>
name_of_list
For example:
request system
external-list show type url EBL_ISAC_Alert_List
9. Test that the policy acon is enforced.

1. View External Dynamic List Entries for the URL list, and aempt to access a URL from
the list.
2. Verify that the acon you defined is enforced.
• Select ACC and add a URL Domain as a global filter to view the Network Acvity
and Blocked Acvity for the URL you accessed.
• Select Monitor > Logs > URL Filtering to access the detailed log view.
Policy
Use an IP External Dynamic List or Predefined IP External Dynamic List as a Source or

Desnaon Address Object in a Security Policy Rule.
This capability is useful if you deploy new servers and want to allow access to the newly
deployed servers without requiring a firewall commit.
2. Click Add and give the rule a descripve Name.
3. In the Source/Desnaon tabs, set the external dynamic list to be used as the Source/
Desnaon Address(es).
4. In the Service/ URL Category tab, make sure the Service is set to applicaon-default.
5. In the Acons tab, set the Acon Seng to Allow or Deny.
Create separate external dynamic lists if you want to specify allow and deny
acons for specific IP addresses.
6. Leave all the other opons at the default values.
7. Click OK to save the changes.
9. Test that the policy acon is enforced.
1. View External Dynamic List Entries for the external dynamic list, and aempt to
access an IP address from the list.
2. Verify that the acon you defined is enforced.
3. Select Monitor > Logs > Traffic and view the log entry for the session.
4. To verify the policy rule that matches a flow, select Device > Troubleshoong, and
execute a Security Policy Match test:
Policy
Use a Predefined URL External Dynamic List to exclude benign domains that applicaons use
for background traffic from Authencaon policy.
When you select the panw-auth-portal-exclude-list EDL type, you can easily exclude from
Authencaon policy enforcement the domains that many applicaons use for background
traffic, such as updates and other trusted services. This ensures that the firewall does not block
the necessary traffic for these services and applicaon maintenance is not interrupted.
1. Select Policies > Authencaon.
2. On the Service/URL Category tab, select the Predefined URL EDL as the URL Category.
3. On the Acons tab, select default-no-captive-portal as the Authencaon
Enforcement.
4. Click OK.
5. Move the rule to the top so that it is the first rule in the policy.
Find External Dynamic Lists That Failed Authencaon

When an external dynamic list that requires SSL fails client or server authencaon, the firewall
generates a system log of crical severity. The log is crical because the firewall connues to
enforce policy based on the last successful external dynamic list aer it fails authencaon,
instead of using the latest version. Use the following process to view crical system log messages
nofying you of authencaon failure related to external dynamic lists.
STEP 1 | Select Monitor > Logs > System.
STEP 2 | Construct the following filters to view all messages related to authencaon failure, and
apply the filters. For more informaon, review the complete workflow to Filter Logs.
• Server authencaon failure—(eventid eq tls-edl-auth-failure)
• Client authencaon failure—(eventid eq edl-cli-auth-failure)
STEP 3 | Review the system log messages. The message descripon includes the name of the external
dynamic list, the source URL for the list, and the reason for the authencaon failure.
The server that hosts the external dynamic list fails authencaon if the cerficate is expired. If
you have configured the cerficate profile to check cerficate revocaon status via Cerficate
Policy
Revocaon List (CRL) or Online Cerficate Status Protocol (OCSP), the server may also fail
authencaon if:
• The cerficate is revoked.
• The revocaon status of the cerficate is unknown.
• The connecon mes out as the firewall is aempng to connect to the CRL/OCSP service.
For more informaon on cerficate profile sengs, refer to the steps to Configure a Cerficate
Profile.
Verify that you added the root CA and intermediate CA of the server to the cerficate
profile configured with the external dynamic list. Otherwise, the firewall will not
authencate the list properly.
Client authencaon fails if you have entered the incorrect username and password
combinaon for the external dynamic list.
STEP 4 | (Oponal) Disable Authencaon for an External Dynamic List that failed authencaon as
a stop-gap measure unl the list owner renews the cerficate(s) of the server that hosts the
list.
Disable Authencaon for an External Dynamic List

Palo Alto Networks recommends that you enable authencaon for the servers that host the
external dynamic lists configured on your firewall. However, if you Find External Dynamic Lists
That Failed Authencaon and prefer to disable server authencaon for those lists, you can do
so through the CLI. The procedure below only applies to external dynamic lists secured with SSL
(i.e., lists with an HTTPS URL); the firewall does not enforce server authencaon on lists with an
HTTP URL.
Disabling server authencaon for an external dynamic list also disables client
authencaon. With client authencaon disabled, the firewall will not be able to connect
to an external dynamic list that requires a username and password for access.
STEP 1 | Launch the CLI and switch to configuraon mode as follows:
username@hostname> configure
Entering configuration mode
[edit]
username@hostname#
The change from the > to the # symbol indicates that you are now in configuraon mode.
Policy
STEP 2 | Enter the appropriate CLI command for the list type:
• IP Address
set external-list <external dynamic list name> type ip

certificate-profile None
• Domain
set external-list <external dynamic list name> type domain

• URL
set external-list <external dynamic list name> type url

STEP 3 | Verify that authencaon is disabled for the external dynamic list.
Trigger a refresh for the list (see Retrieve an External Dynamic List from the Web Server). If the
firewall retrieves the list successfully, server authencaon is disabled.
Policy
Register IP Addresses and Tags Dynamically

To migate the challenges of scale, lack of flexibility, and performance, network architectures
today allow for virtual machines (VMs) and applicaons to be provisioned, changed, and deleted
on demand. This agility, though, poses a challenge for security administrators because they have
limited visibility into the IP addresses of the dynamically provisioned VMs and the plethora of
applicaons that can be enabled on these virtual resources.
Firewalls (hardware-based and VM-Series models) support the ability to register IP addresses, IP
sets (IP ranges and subnets), and tags dynamically. The IP addresses and tags can be registered on
the firewall directly or from Panorama. You can also automacally remove tags on the source and
desnaon IP addresses included in a firewall log.
PAN-OS only supports IPv4 IP subnets and ranges in dynamic address groups.
You can enable the dynamic registraon process using any of the following opons:
• User-ID agent for Windows—In an environment where you’ve deployed the User-ID agent, you
can enable the User-ID agent to monitor up to 100 VMware ESXi servers, vCenter Servers, or a
combinaon of the two. As you provision or modify virtual machines on these VMware servers,
the agent can retrieve the IP address changes and share them with the firewall.
• VM Informaon Sources—Enables you to monitor VMware ESXi, vCenter Server, AWS-VPCs,
and Google Compute Engines navely on the firewall and to retrieve IP address changes when
you provision or modify virtual machines on these sources. VM Informaon Sources opon
polls for a predefined set of aributes and does not require external scripts to register the IP
addresses through the XML API. See Monitor Changes in the Virtual Environment.
• Panorama Plugin—You can enable a Panorama™ M-Series or virtual appliance to connect to
your Azure or AWS public cloud environment and retrieve informaon on the virtual machines
deployed within your subscripon or VPC. Panorama then registers the VM informaon to the
managed Palo Alto Networks firewalls that you configured for noficaon and then you can
use these aributes to define dynamic address groups and aach them to Security policy rules
to allow or deny traffic to and from these VMs.
• VMware Service Manager (Integrated NSX soluons only)—The integrated NSX soluon
is designed for automated provisioning and distribuon of the Palo Alto Networks Next-
Generaon Security Operang Plaorm® and the delivery of dynamic context-based Security
policies using Panorama. The NSX Manager updates Panorama with the latest informaon
on the IP addresses, IP sets, and tags associated with the virtual machines deployed in this
integrated soluon. For informaon on this soluon, see Set Up a VM-Series NSX Edion
Firewall.
• XML API—The firewall and Panorama support an XML API that uses standard HTTP requests
to send and receive data. You can use this API to register IP addresses and tags with the
firewall or Panorama. You can make API calls directly from command-line ulies, such as
cURL, or by using any scripng or applicaon framework that supports REST-based services.
Refer to the PAN-OS XML API Usage Guide for details.
• Auto-Tag—Tag the source or desnaon IP address automacally when a log is generated on
the firewall and register the IP address and tag mapping to a User-ID agent on the firewall or on
Panorama, or to a remote User-ID agent using an HTTP server profile. For example, whenever
Policy
the firewall generates a threat log, you can configure the firewall to tag the source IP address
in the threat log with a specific tag name. For more informaon, refer to Use Auto-Tagging to
Automate Security Acons.
Addionally, you can configure the firewall to dynamically unregister a tag aer a configured
amount of me using a meout. For example, you can configure the meout to be the same
duraon as the DHCP lease meout for the IP address. This allows the IP address-to-tag
mapping to expire at the same me as the DHCP lease so that you don’t unintenonally apply
policy when the IP address is reassigned.
See Forward Logs to an HTTP(S) Desnaon.
For informaon on creang and using Dynamic Address Groups, see Use Dynamic Address Groups
in Policy.
For the CLI commands for registering tags dynamically, see CLI Commands for Dynamic IP
Addresses and Tags.
Policy
Use Dynamic User Groups in Policy

Dynamic user groups help you to create policy that provides auto-remediaon for anomalous
user behavior and malicious acvity while maintaining user visibility. Aer you create the group
and commit the changes, the firewall registers the users and associated tags then automacally
updates the dynamic user group’s membership. Because updates to dynamic user group
membership are automac, using dynamic user groups instead of stac group objects allows you
to respond to changes in user behavior or potenal threats without manual policy changes.
To determine what users to include as members, a dynamic user group uses tags as filtering
criteria. As soon as a user matches the filtering criteria, that user becomes a member of the
dynamic user group. The tag-based filter uses logical and and or operators. Each tag is a metadata
element or aribute-value pair that you register on the source stacally or dynamically. Stac tags
are part of the firewall configuraon, while dynamic tags are part of the runme configuraon. As
a result, you don’t need to commit updates to dynamic tags if they are already associated with a
policy that you have commied on the firewall
To dynamically register tags, you can use:
• the XML API
• the User-ID agent
• Panorama
• the web interface on the firewall
The firewall redistributes the tags for the dynamic user group to the listening redistribuon
agents, which includes other firewalls, Panorama, or a Dedicated Log Collector, as well as Cortex
applicaons.
To support redistribuon for dynamic user group tags, all firewalls must use PAN-OS 9.1 to
receive the tags from the registraon sources.
The firewall redistributes the tags for the dynamic user group to the next hop and you can
configure log forwarding to send the logs to a specific server. Log forwarding also allows you
to use auto-tagging to automacally add or remove members of dynamic user groups based on
events in the logs.
STEP 1 | Select Objects > Dynamic User Groups and Add a new dynamic user group.
Policy
STEP 2 | Define the membership of the dynamic user group.

1. Enter a Name for the group.
2. (Oponal) Enter a Descripon for the group.
3. Add Match Criteria using dynamic tags to define the members in the dynamic user
group.
4. (Oponal) Use the And or Or operators with the tag(s) that you want to use to filter for
or match against.
5. Click OK.
6. (Oponal) Select the Tags you want to assign to the group itself.
This tag displays in the Tags column in the Dynamic User Group list and defines
the dynamic group object, not the members in the group.
If you update the user group object filter, you must commit the changes to
update the configuraon.
STEP 3 | Depending on the log informaon that you want to use as match criteria, configure auto-
tagging by creang a log forwarding profile or configuring the log sengs.
• For Authencaon, Data, Threat, Traffic, Tunnel Inspecon, URL, and WildFire logs, create a
log forwarding profile.
• For User-ID, GlobalProtect, and IP-Tag logs, configure the log sengs.
STEP 4 | (Oponal) To return dynamic user group members to their original groups aer a specific
duraon of me, enter a Timeout value in minutes (default is 0, range is 0-43200).
STEP 5 | Use the dynamic user group in a policy to regulate traffic for the members of the group.
You will need to create at least two rules: one to allow inial traffic to populate the dynamic
user group and one to deny traffic for the acvity you want to prevent. To tag users, the rule to
allow traffic must have a higher rule number in your rulebase than the rule that denies traffic.
1. Select the dynamic user group from Step 1 as the Source User.
2. Create the rule where the Acon denies traffic to the dynamic user group members.
3. Create the rule that allows the traffic to populate the dynamic user group members.
4. If you configured a Log Forwarding profile in Step 3, select it to add it to the policy.
Policy
STEP 6 | (Oponal) Refine the group’s membership and define the registraon source for the user-to-
tag mapping updates.
If the inial user-to-tag mapping retrieves users who should not be members or if it does not
include users who should be, modify the members of the group to include the users for whom
you want to enforce the policy and specify the source for the mappings.
1. In the Users column, select more.
2. Register Users to add them to the group and select the Registraon Source for the tags
and user-to-tag mappings.
• Local (Default)—Register the tags and mappings for the dynamic user group members
locally on the firewall.
• Panorama User-ID Agent—Register the tags and mappings for the dynamic user group
members on a User-ID agent connected to Panorama. If the dynamic user group
originates from Panorama, the row displays in yellow and the group name, descripon,
match criteria, and tags are read-only. However, you can sll register or unregister
users from the group.
• Remote device User-ID Agent—Register the tags and mappings for the dynamic
user group members on a remote User-ID agent. To select this opon, you must first
configure an HTTP server profile.
3. Select the Tags you want to register on the source using the tag(s) you used to configure
the group.
4. (Oponal) To return dynamic user group members to their original groups aer a specific
duraon of me, enter a Timeout value in minutes (default is 0, range is 0-43200).
5. Add or Delete users as necessary.
6. (Oponal) Unregister Users to remove their tags and user-to-tag mappings.
STEP 7 | Verify the firewall correctly populates the users in the dynamic user group.
1. Confirm the Dynamic User Group column in the Traffic, Threat, URL Filtering, WildFire
Submissions, Data Filtering, and Tunnel Inspecon logs displays the dynamic user groups
correctly.
2. Use the show user group list dynamic command to display a list of all dynamic
user groups as well as the total number of dynamic user groups.
3. Use the show object registered-user all command to display a list of users
who are registered members of dynamic user groups.
4. Use the show user group name group-name command to display informaon
about the dynamic user group, such as the source type.
Policy
Use Auto-Tagging to Automate Security Acons

Auto-tagging allows the firewall or Panorama to tag a policy object when it receives a log that
matches specific criteria and establish IP address-to-tag or user-to-tag mapping. For example,
when the firewall generates a threat log, you can configure the firewall to tag the source IP
address or source user in the threat log with a specific tag name. You can then use these tags to
automacally populate policy objects such as dynamic user groups or dynamic address groups,
which can then be used to automate security acons in security, authencaon, or decrypon
policies. For example, when you create a filter for the URL logs for yes in the Credenal Detected
column, you can apply a tag to the user that enforces an authencaon policy that requires user
to authencate using mul-factor authencaon (MFA).
Dynamic user groups do not support auto-tagging from HIP Match logs.
Redistribute the mappings across your network by registering the IP address-to-tag and user-to-
tag mappings to a PAN-OS integrated User-ID agent on the firewall or Panorama or to a remote
User-ID agent using an HTTP server profile. The firewall can automacally remove (unregister)
a tag associated with an IP address or user when you configure a meout as part of a built-in
acon for a log forwarding profile or as part of log forwarding sengs. For example, if the firewall
detects a user has potenally compromised credenals, you could configure the firewall to require
MFA authencaon for that user for a given period of me, then configure a meout to remove
the user from the MFA requirement group.
STEP 1 | Depending on the type of log you want to use for tagging, create a log forwarding profile or
configure the log sengs to define how you want the firewall or Panorama to handle logs.
• For Authencaon, Data, Threat, Traffic, Tunnel Inspecon, URL, and WildFire logs, create
a log forwarding profile.
• For User-ID, GlobalProtect, and IP-Tag logs, configure the log sengs.
STEP 2 | Define the match list criteria that determine when the firewall or Panorama adds the tag to
the policy object.
For example, you can use a filter to configure a threshold or define a value (such as user eq
“unknown” to idenfy users that the firewall has not yet mapped); when the firewall reaches
that threshold or finds that value, the firewall adds the tag.
• To create a log forwarding profile, Add it and select the Log Type you want to monitor for
match list criteria (Objects > Log Forwarding).
• To configure log sengs, Add the log sengs for the type of log you want to monitor for
match list criteria (Device > Log Sengs).
STEP 3 | Copy and paste a Filter value or use the Filter Builder to define the match criteria for the tag.
Policy
STEP 4 | Add a built-in acon to tag the policy object.

1. Add the Built-in Acons you want the firewall or Panorama to take when the logs
contain an entry that meets the match list criteria.
2. Name the acon.
3. Select the type of Target that you want to tag (Desnaon Address, Source Address,
User, or X-Forwarded-For Address).
4. Confirm that Add Tag is the Acon.
5. Select the Registraon source for the tag to determine how the firewall or Panorama
redistributes the IP address-to-tag mapping.
• Local User-ID—Redistribute the IP address-to-tag mapping on the User-ID agent on
the firewall or Panorama.
• Panorama User-ID—Redistribute the IP address-to-tag mapping on Panorama.
• Remote User-ID—Redistribute the IP address-to-tag mapping on another User-ID
agent using an HTTP server profile. If you select this opon, you must configure an
HTTP server profile (see Step 5).
6. Enter or select the Tags you want to add to the policy object.
You may need to click outside of the field or press Enter to enable the OK buon.
7. Click OK.
Policy
STEP 5 | (Remote User-ID only) Configure an HTTP server profile to forward logs to a remote User-ID
agent.
1. Select Device > Server Profiles > HTTP.
2. Add a profile and specify a Name for the server profile.
3. (Virtual systems only) Select the Locaon. The profile can be Shared across all virtual
systems or can belong to a specific virtual system.
4. Select Tag Registraon to enable the firewall to register the IP address and tag mapping
with the User-ID agent on a remote firewall. With tag registraon enabled, you cannot
specify the payload format.
5. Add the server connecon details to access the remote User-ID agent and click OK.
6. Select the log forwarding profile you created then select this server profile as the HTTP
server profile for your Remote User-ID tag Registraon.
STEP 6 | Define the policy objects to which you want to apply the tags.
1. Create or select one of the following policy objects: dynamic address groups, Use
Dynamic User Groups in Policy, addresses, address groups, zones, policy rules, services,
or service groups.
2. Enter the tags you want to apply to the object as the Match criteria.
Confirm that the tag is idencal to the tag in Step 4.
STEP 7 | Add the tagged policy objects to your policy.

This workflow uses a Security policy as an example, but you can also use tagged policy objects
in Authencaon policy.
2. Click Add and enter a Name and oponally a Descripon for the policy.
3. Add the Source Zone where the traffic originates.
4. Add the Desnaon Zone where the traffic terminates.
5. Select the Source object you created in Step 5.1.
6. Select whether the rule will Allow or Deny the traffic.
STEP 8 | If you configured a log forwarding profile, assign it to your Security policy.
You can assign one log forwarding profile for each policy but you can assign mulple methods
and acons per profile. For an example, refer to Use Dynamic Address Groups in Policy.
Policy
STEP 10 | (Oponal) Configure a meout to remove the tag from the policy object aer the specified
me has elapsed.
Specify the amount of me (in minutes) that passes before the firewall removes the tag from
the policy object. The range is from 0 to 43,200. If you set the meout to zero, the IP address-
to-tag mapping does not meout and must be removed with an explicit acon. If you set the
meout to the maximum of 43,200 minutes, the firewall removes the tag aer 30 days.
You cannot configure a Timeout with a Remove Tag acon.
1. Select the log forwarding profile.

2. Add or edit one of the Built-in Acons.
3. Specify the Timeout (in minutes). When the specified me has elapsed, the firewall or
Panorama removes the tag.
Set the IP-tag meout to the same amount of me as the DHCP lease meout
for that IP address. This allows the IP address-to-tag mapping to expire at the
same me as the DHCP lease so that you do not unintenonally apply policy
when the IP address is reassigned.
Policy
Monitor Changes in the Virtual Environment

To secure applicaons and prevent threats in an environment where new users and servers are
constantly emerging, your security policy must be nimble. To be nimble, the firewall must be
able to learn about new or modified IP addresses and consistently apply policy without requiring
configuraon changes on the firewall.
This capability is provided by the coordinaon between the VM Informaon Sources and
Dynamic Address Groups features on the firewall. The firewall and Panorama provide an
automated way to gather informaon on the virtual machine (or guest) inventory on each
monitored source and create policy objects that stay in sync with the dynamic changes on the
network.
• Enable VM Monitoring to Track Changes on the Virtual Network
• Aributes Monitored on Virtual Machines in Cloud Plaorms
• Use Dynamic Address Groups in Policy
Enable VM Monitoring to Track Changes on the Virtual Network

VM informaon sources provides an automated way to gather informaon on the Virtual Machine
(VM) inventory on each monitored source (host); the firewall can monitor the VMware ESXi,
vCenter Server, AWS-VPC, Microso Azure VNet, and Google Cloud. As virtual machines (guests)
are deployed or moved, the firewall collects a predefined set of aributes (or metadata elements)
as tags; these tags can then be used to define Dynamic Address Groups (see Use Dynamic
Address Groups in Policy) and matched against in policy.
You can directly configure the firewall or use Panorama templates to monitor up to 10 VM
informaon sources. VM Informaon Sources offers easy configuraon and enables you to
monitor a predefined set of 16 metadata elements or aributes. See Aributes Monitored on
Virtual Machines in Cloud Plaorms for the list. By default, the traffic between the firewall and the
monitored sources uses the management (MGT) port on the firewall.
Policy
• When monitoring ESXi hosts that are part of the VM-Series NSX edion soluon,
use Dynamic Address Groups instead of using VM Informaon Sources to learn about
changes in the virtual environment. For the VM-Series NSX edion soluon, the NSX
Manager provides Panorama with informaon on the NSX security group to which an
IP address belongs. The informaon from the NSX Manager provides the full context
for defining the match criteria in a Dynamic Address Group because it uses the service
profile ID as a disnguishing aribute and allows you to properly enforce policy when
you have overlapping IP addresses across different NSX security groups. Up to a
maximum of 32 tags (from vCenter server and NSX Manager) that can be registered to
an IP address.
• For monitoring the virtual machines within your Azure deployment, instead of VM
Monitoring Sources, you need to deploy the VM Monitoring script that runs on a
virtual machine within the Azure public cloud. This script collects the IP address-to-
tag mapping informaon for your Azure assets and publishes it to the firewalls and
corresponding virtual systems you specify in the script.
• For Panorama version 8.1.3 and later, you can also use the Panorama plugin for AWS
or Azure to retrieve VM Informaon and register it to the managed firewalls. See
Aributes Monitored on Virtual Machines in Cloud Plaormsfor details.
STEP 1 | Enable VM Monitoring.
You can configure up to 10 VM informaon sources for each firewall, or for each virtual
system on a mulple virtual systems capable firewall.
If your firewalls are configured in a high availability configuraon:

• In an acve/passive setup, only the acve firewall monitors the VM sources.
• In an acve/acve setup, only the firewall with the priority value of primary monitors the
VM sources.
1. Select Device > VM Informaon Sources. This example shows you how to add VMware
ESX(i) or vCenter Server.
2. Click Add and enter the following informaon:
• A Name to idenfy the source that you want to monitor.
• Select the Type to indicate whether the source is an AWS VPC, a Google Compute
Engine instance, a VMware ESX(i) server, or a VMware vCenter Server.
The type chosen determines the fields displayed.
• Enter the Port on which the source is listening.

• To change the default value, select the check box to Enable meout when the source
is disconnected and specify the value. When the specified limit is reached or if the
Policy
host cannot be accessed or does not respond, the firewall will close the connecon to
the source.
• Add the credenals (Username and Password) to authencate to the server specified
above.
• Define the Source—hostname or IP address.
• (Oponal) Modify the Update interval to a value between 5-600 seconds. By default,
the firewall polls every 5 seconds. The API calls are queued and retrieved within
every 60 seconds, so updates may take up to 60 seconds plus the configured polling
interval.
• Click OK, and Commit the changes.

• Verify that the connecon Status displays as connected.
STEP 2 | Verify the connecon status.

Verify that the connecon Status displays as connected.
If the connecon status is pending or disconnected, verify that the source is operaonal and
that the firewall is able to access the source. If you use a port other than the MGT port for
communicang with the monitored source, you must change the service route (Device > Setup
> Services, click the Service Route Configuraon link and modify the Source Interface for the
VM Monitor service).
Aributes Monitored on Virtual Machines in Cloud Plaorms

As you provision or remove virtual machines in the private or public cloud, you can use a
Panorama plugin, a VM Monitoring script, or the VM Informaon Source on the next-gen firewall
to monitor changes on virtual machines (VMs) deployed in the virtual environments.
Policy
VM Informaon Sources—On a hardware or a VM-Series firewall you can monitor virtual

machine instances and retrieves changes as you provision or modify the guests configured
on the monitored sources—AWS, ESXi or vCenter Server, or AWS. For each firewall (and/or
virtual system if your firewall has mulple virtual system capability), you can configure up to 10
sources.For informaon on how VM Informaon Sources and Dynamic Address Groups work
synchronously and enable you to monitor changes in the virtual environment, refer to the VM-
Series Deployment Guide .If your firewalls are configured in a high availability configuraon:
• In an acve/passive setup, only the acve firewall monitors the VM informaon sources.
• In an acve/acve setup, only the primary firewall monitors the VM informaon sources.
Panorama Plugin—On a Panorama —hardware appliance or virtual appliance running version
8.1.3—you can install the plugin for Microso Azure and AWS. The plugin allows you to connect
Panorama to your Azure public cloud subscripons or AWS VPCs and retrieve the IP address-
to-tag mapping for your virtual machines. Panorama then registers the VM informaon to the
managed Palo Alto Networks® firewall(s) that you have configured for noficaon.
Use the following secons to review the opons supported on each cloud vendor and the virtual
machine aributes that you can monitor to create Dynamic Address Groups:
• VMware ESXi
• Amazon Web Services (AWS)
• Microso Azure
• Google
VMware ESXi
Each VM on a monitored ESXi or vCenter server must have VMware Tools installed and running.
VMware Tools provide the capability to glean the IP address(es) and other values assigned to each
VM.
When monitoring ESXi hosts that are part of the VM-Series NSX edion soluon, use
Dynamic Address Groups (instead of using VM Informaon Sources) to learn about
changes in the virtual environment. For the VM-Series NSX edion soluon, the NSX
Manager provides Panorama with informaon on the NSX security group to which an
IP address belongs. The informaon from the NSX Manager provides the full context for
defining the match criteria in a Dynamic Address Group because it uses the service profile
ID as a disnguishing aribute and allows you to properly enforce policy when you have
overlapping IP addresses across different NSX security groups.
Up to 32 tags (from vCenter server and NSX Manager) can be registered to an IP address.
To collect the values assigned to the monitored VMs, use the VM Informaon Sources on the
firewall to monitor the following predefined set of ESXi aributes:
Aributes Monitored on a VMware Source
UUID
Name
Policy
Aributes Monitored on a VMware Source
Guest OS
VM State — the power state can be poweredOff, poweredOn, standBy, and unknown.
Annotaon
Version
Network — Virtual Switch Name, Port Group Name, and VLAN ID
Container Name —vCenter Name, Data Center Object Name, Resource Pool Name, Cluster
Name, Host, Host IP address.
Amazon Web Services (AWS)

As you provision or modify virtual machines in your AWS VPCs, you have two ways of monitoring
these instances and retrieving the tags for use as match criteria in dynamic address groups.
• VM Informaon Source—On a next-gen firewall, you can monitor up to a total of 32 tags—14
pre-defined and 18 user-defined key-value pairs (tags). The following aributes (or tag names)
are available as match criteria for dynamic address groups.
• AWS Plugin on Panorama—The Panorama plugin for AWS allows you to connect Panorama to
your AWS VPCs and retrieve the IP address-to-tag mapping for your AWS virtual machines.
Panorama then registers the VM informaon to the managed Palo Alto Networks® firewall(s)
that you have configured for noficaon. With the plugin, Panorama can retrieve a total of 32
tags for each virtual machine, 11 predefined tags and up to 21 user-defined tags.
Aributes VM Informaon Source on the AWS Plugin on Panorama

Monitored on the Firewall
AWS-VPC
Architecture Yes No
Guest OS Yes No
AMI ID Yes Yes
IAM Instance No Yes

Profile
Instance ID Yes No
Instance State Yes No
Instance Type Yes No
Key Name Yes Yes
Policy
Aributes VM Informaon Source on the AWS Plugin on Panorama

Monitored on the Firewall
AWS-VPC
Owner ID No Yes
Placement— Yes Yes

Tenancy
Placement—Group Yes Yes

Name
Placement— Yes Yes

Availability Zone
Private DNS Name Yes No
Public DNS Name Yes Yes
Subnet ID Yes Yes
Security Group ID No Yes
Security Group No Yes

Name
VPC ID Yes Yes
Tag (key, value) Yes; Yes;

Up to a maximum of 18 user Up to a maximum of 21 user defined
defined tags are supported. The tags are supported. The user-defined
user-defined tags are sorted tags are sorted alphabecally, and the
alphabecally, and the first 18 first 21 tags are available for use on
tags are available for use on the Panorama and the firewalls.
firewalls.
Microso Azure
For VM Monitoring on Azure you need to retrieve the IP address-to-tag mapping for your Azure
VMs and make it available as match criteria in dynamic address groups. The Panorama plugin for
Microso Azure allows you to connect Panorama to your Azure public cloud subscripons and
retrieve the IP address-to-tag mapping for your Azure virtual machines. Panorama can retrieve
a total of 26 tags for each virtual machine, 11 predefined tags and up to 15 user-defined tags
and registers the VM informaon to the managed Palo Alto Networks® firewall(s) that you have
configured for noficaon.
With the Panorama plugin for Azure, you can monitor the following set of virtual machine
aributes within your Microso Azure deployment.
Policy
Aributes Monitored on Microso Azure Azure Plugin on Panorama
VM Name Yes
VM Size No
Network Security Group Name Yes
OS Type Yes
OS Publisher Yes
OS Offer Yes
OS SKU Yes
Subnet Yes
VNet Yes
Azure Region Yes
Resource Group Name Yes
Subscripon ID Yes
User Defined Tags Yes

Up to a maximum of 15 user defined
tags are supported. The user-defined
tags aresorted alphabecally, and the
first 15 tags are available for use on
Panorama and the firewalls.
Google
Using VM Informaon Sources on the next-gen firewall, you can monitor the following predefined
set of Google Compute Engine (GCE) aributes.
High Availability is not supported on the firewalls.
Aributes Monitored on Google Compute Engine
Hostname of the VM
Machine type
Project ID
Policy
Aributes Monitored on Google Compute Engine
Source (OS type)
Status
Subnetwork
VPC Network
Use Dynamic Address Groups in Policy

Dynamic address groups are used in policy. They allow you to create policy that automacally
adapts to changes—adds, moves, or deleons of servers. It also enables the flexibility to apply
different rules to the same server based on tags that define its role on the network, the operang
system, or the different kinds of traffic it processes.
A dynamic address group uses tags as a filtering criteria to determine its members. The filter uses
logical and and or operators. All IP addresses or address groups that match the filtering criteria
become members of the dynamic address group. Tags can be defined stacally on the firewall
and/or registered (dynamically) to the firewall. The difference between stac and dynamic tags
is that stac tags are part of the configuraon on the firewall, and dynamic tags are part of the
runme configuraon. This implies that a commit is not required to update dynamic tags; the tags
must however be used by Dynamic Address Groups that are referenced in policy, and the policy
must be commied on the firewall.
To dynamically register tags, you can use the XML API or the VM Monitoring agent on the firewall
or on the User-ID agent. Each tag is a metadata element or aribute-value pair that is registered
on the firewall or Panorama. For example, IP1 {tag1, tag2,.....tag32}, where the IP address and the
associated tags are maintained as a list; each registered IP address can have up to 32 tags such as
the operang system, the datacenter or the virtual switch to which it belongs. Aer receiving the
API call, the firewall registers the IP address and associated tags, and automacally updates the
membership informaon for the dynamic address group(s).
The maximum number of IP addresses that can be registered for each model is different. Use the
following table for specifics on your model:
Model Maximum number of dynamically registered

IP addresses
M-Series and Panorama Virtual 500,000

Appliances
PA-5200 Series, VM-7000 SMC-B Series 500,000
VM-500, VM-700 300,000
PA-3200 Series, VM-300 200,000
Policy
Model Maximum number of dynamically registered

IP addresses
PA-7000 Series 100,000
PA-850, VM-100 2,500
PA-820, PA-220, VM-50 1,000
An IP set, such as an IP range or subnet, is considered as a single registered IP address

when counted towards the maximum number of registered IP addresses supported by each
firewall model.
The following example shows how dynamic address groups can simplify network security
enforcement. The example workflow shows how to:
• Enable the VM Monitoring agent on the firewall, to monitor the VMware ESX(i) host or vCenter
Server and register VM IP addresses and the associated tags.
• Create dynamic address groups and define the tags to filter. In this example, two address
groups are created. One that only filters for dynamic tags and another that filters for both stac
and dynamic tags to populate the members of the group.
• Validate that the members of the dynamic address group are populated on the firewall.
• Use dynamic address groups in policy. This example uses two different security policies:
• A security policy for all Linux servers that are deployed as FTP servers; this rule matches on
dynamically registered tags.
• A security policy for all Linux servers that are deployed as web servers; this rule matches on
a dynamic address group that uses stac and dynamic tags.
• Validate that the members of the dynamic address groups are updated as new FTP or web
servers are deployed. This ensure that the security rules are enforced on these new virtual
machines too.
STEP 1 | Enable VM Source Monitoring.
See Enable VM Monitoring to Track Changes on the Virtual Network.
STEP 2 | Create dynamic address groups on the firewall.
View the tutorial to see a big picture view of the feature.
1. Log in to the web interface of the firewall.

2. Select Object > Address Groups.
3. Click Add and enter a Name and a Descripon for the address group.
4. Select Type as Dynamic.
5. Define the match criteria. You can select dynamic and stac tags as the match criteria to
populate the members of the group. Click Add Match Criteria, and select the And or Or
Policy
operator and select the aributes that you would like to filter for or match against. and
then click OK.
6. Click Commit.
STEP 3 | The match criteria for each dynamic address group in this example is as follows:
p_server: matches on the guest operang system “Linux 64-bit” and annotated as
“p” ('guestos.Ubuntu Linux 64-bit' and 'annotaon.p').
web-servers: matches on two criteria—the tag black or if the guest operang system is Linux
64-bit and the name of the server us Web_server_Corp. ('guestos.Ubuntu Linux 64-bit' and
'vmname.WebServer_Corp' or 'black')
STEP 4 | Use dynamic address groups in policy.
View the tutorial.

2. Click Add and enter a Name and a Descripon for the policy.
3. Add the Source Zone to specify the zone from which the traffic originates.
4. Add the Desnaon Zone at which the traffic is terminang.
5. For the Desnaon Address, select the Dynamic address group you just created.
6. Specify the acon— Allow or Deny—for the traffic, and oponally aach the default
security profiles to the rule.
7. Repeats Steps 1 through 6 to create another policy rule.
8. Click Commit.
Policy
STEP 5 | This example shows how to create two policies: one for all access to FTP servers and the
other for access to web servers.
STEP 6 | Validate that the members of the dynamic address group are populated on the firewall.
1. Select Policies > Security, and select the rule.
2. Select the drop-down arrow next to the address group link, and select Value. You can
also verify that the match criteria is accurate.
3. Click the more link and verify that the list of registered IP addresses is displayed.
Policy will be enforced for all IP addresses that belong to this address group, and are
displayed here.
If you want to delete all registered IP addresses, use the CLI command debug
object registered-ip clear all and then reboot the firewall aer clearing
the tags.
Policy
CLI Commands for Dynamic IP Addresses and Tags

The Command Line Interface on the firewall and Panorama give you a detailed view into the
different sources from which tags and IP addresses are dynamically registered. It also allows you to
audit registered and unregistered tags. The following examples illustrate the capabilies in the CLI.
Example CLI Command
View all registered IP addresses that

match the tag, state.poweredOn or show log iptag tag_name equal state.p
that are not tagged as vSwitch0. oweredOn
show log iptag tag_name not-equal swi
tch.vSwitch0
View all dynamically registered IP

addresses that were sourced by show vm-monitor source source-name vm
VM Informaon Source with name ware1 tag state.poweredOn registered-
vmware1 and tagged as poweredOn. ip all
registered IP Tag
s
---------------------- ------------
---
fe80::20c:29ff:fe69:2f76 "state.powe
redOn"
10.1.22.100 "state.powe
redOn"
2001:1890:12f2:11:20c:29ff:fe69:2f76"
state.poweredOn"
fe80::20c:29ff:fe69:2f80 "state.power
edOn"
192.168.1.102 "state.power
edOn"
10.1.22.105 "state.power
edOn"
2001:1890:12f2:11:2cf8:77a9:5435:c0d"
state.poweredOn"
fe80::2cf8:77a9:5435:c0d "state.power
edOn"
Clear all IP addresses and tags learned

from a specific VM Monitoring source debug vm-monitor clear source-name <n
without disconnecng the source. ame>
Display IP addresses registered from all

sources. show object registered-ip all
Policy
Example CLI Command
Display the count for IP addresses

registered from all sources. show object registered-ip all option
count
Clear IP addresses registered from all

sources debug object registered-ip clear all
Add or delete tags for a given IP

address that was registered using the debug object registered-ip test [<reg
XML API. ister/unregister>] <ip/netmask><tag>
View all tags registered from a specific

informaon source. show vm-monitor source source-name vm
ware1 tag all
vlanId.4095
vswitch.vSwitch1
host-ip.10.1.5.22
portgroup.TOBEUSED
hostname.panserver22
portgroup.VM Network 2
datacenter.ha-datacenter
vlanId.0
state.poweredOn
vswitch.vSwitch0
vmname.Ubuntu22-100
vmname.win2k8-22-105
resource-pool.Resources
vswitch.vSwitch2
guestos.Ubuntu Linux 32-bit
guestos.Microsoft Windows Server 2008
32-bit
annotation.
version.vmx-08
portgroup.VM Network
vm-info-source.vmware1
uuid.564d362c-11cd-b27f-271f-c361604d
fad7
uuid.564dd337-677a-eb8d-47db-293bd669
2f76
Total: 22
View all tags registered from a specific • To view tags registered from the CLI:
data source, for example from the VM
Monitoring Agent on the firewall, the show log iptag datasource_type equ
XML API, Windows User-ID Agent or al unknown
the CLI.
Policy
Example CLI Command

• To view tags registered from the XML API:
show log iptag datasource_type equ

al xml-api
• To view tags registered from VM Informaon

sources:

al vm-monitor
• To view tags registered from the Windows User-

ID agent:

al xml-api datasource_subtype equa
l user-id-agent
View all tags that are registered for a

specific IP address (across all sources). debug object registered-ip show tag-s
ource ip ip_address tag all
Policy
Enforce Policy on Endpoints and Users Behind an

Upstream Device
If you have an upstream device, such as an explicit proxy server or load balance, deployed
between the users on your network and the firewall, the firewall might see the upstream device IP
address as the source IP address in HTTP/HTTPS traffic that the proxy forwards rather than the
IP address of the client that requested the content. In many cases, the upstream device adds an X-
Forwarded-For (XFF) header to HTTP requests that include the actual IPv4 or IPv6 address of the
client that requested the content or from whom the request originated.
In such cases, you can configure the firewall to extract the IP address from the XFF field and map
it to a user with User-ID or apply security policy based on the IP address.
• Use X-Forwarded-For Header in User-ID—This enables you enforce user-based policy to safely
enable access to web-based applicaons for your users behind a proxy server. In addion, if
User-ID is able to map the XFF IP address to a username, the firewall displays that username as
the Source user in Traffic, Threat, WildFire Submissions, and URL Filtering logs for visibility into
the web acvity of users behind the proxy.
• Use X-Forwarded-For Header in Security Policy—This enables you to enforce security
policy based on source IP address using the IP address in the XFF field of the HTTP header.
Addionally, when policy is applied to traffic that includes an IP address in the XFF field,
you can configure the Traffic, Threat, Data Filtering, and Wildfire Submission logs to assist in
troubleshoong and remediaon.
To ensure that aackers can’t read and exploit the XFF values in web request packets that exit the
firewall to retrieve content from an external server, you can also configure the firewall to strip the
XFF values from outgoing packets. Using the XFF IP address for User-ID or in policy and stripping
the XFF value are not mutually exclusive: if you configure both, the firewall zeroes out XFF values
only aer using them in policy enforcement and logging.
You cannot configure the firewall to use the IP address in the XFF field in User-ID and
security policy at the same me.
• Use XFF Values for Policies and Logging Source Users

• Use XFF IP Address Values in Security Policy and Logging
• Use the IP Address in the XFF Header to Troubleshoot Events
Use XFF Values for Policy Based on Source Users

You can configure the firewall map the IP address in the XFF header to a username using User-
ID so that you can have visibility into and user-based policy control over the web traffic of users
behind a proxy server who cannot otherwise be idenfied. In order to map the IP addresses from
the XFF headers to usernames, you must first Enable User-ID.
With this opon enabled, the firewall uses the IP address in the XFF header for user mapping
purposes only. The source IP address the firewall logs is sll that of the proxy server, not that of
the source user. When you see a log event aributed to a user that the firewall mapped using
and IP address extracted from an XFF header, it can be difficult to track down the specific device
associated with the event. To simplify debugging and troubleshoong of events aributed to users
Policy
behind the proxy server, you must also configure the firewall to populate the X-Forwarded-For
column in the URL Filtering log with the IP address in the XFF header so that you can track down
the specific user and device associated with an log event that is correlated with the URL Filtering
log entry.
The XFF header your proxy server adds must contain the source IP address of the end user who
originated the request. If the header contains mulple IP addresses, the firewall uses the first IP
address only. If the header contains informaon other than an IP address, the firewall will not be
able to perform user mapping.
Enabling the firewall to use the X-Forwarded-For headers to perform user mapping
does not enable the firewall to use the client IP address in the XFF header as the source
address in the logs; the logs sll display the proxy server IP address as the source address.
However, to simplify the debugging and troubleshoong process you can configure the
firewall to Add XFF Values to URL Filtering Logs to display the client IP address from the
XFF header in the URL Filtering logs.
STEP 1 | Enable the firewall to use XFF values in policies and in the source user fields of logs.
1. Select Device > Setup > Content-ID and edit the X-Forwarded-For Headers sengs.
2. Select Use X-Forwarded-For Header in User-ID.
STEP 2 | Remove XFF values from outgoing web requests.

1. Select Strip X-Forwarded-For Header.
STEP 3 | Verify the firewall is populang the source user fields of logs.
1. Select a log type that has a source user field (for example, Monitor > Logs > Traffic).
2. Verify that the Source User column displays the usernames of users who access web
applicaons.
Use XFF IP Address Values in Security Policy and Logging

You can configure the firewall to use the IP address in the X-Forwarded-For (XFF) field of the
HTTP header to enforce security policy. If the packet passes through a single proxy server before
reaching the firewall, the XFF field contains the IP address of the originang endpoint and the
firewall can use that IP address to enforce security policy. However, if the packet passes through
mulple upstream devices, the firewall uses the most-recently added IP address to enforce policy
or use other features that rely on IP informaon.
• Use XFF Values in Policy

• Display XFF Values in Logs
Policy
• Display XFF Values in Reports
Use XFF Values in Policy

Complete the following procedure to use the client IP address in the XFF header when enforcing
security policy.
In Microso Azure, by default, an applicaon gateway inserts the original source IP

address and port in the XFF header. To use XFF headers in policy on your firewall, you
must configure the applicaon gateway to omit the port from the XFF header. For more
informaon, see Azure documentaon.
STEP 1 | Log in to your firewall.
STEP 2 | Select Device > Setup > Content-ID > X-Forwarded-For Headers.
STEP 3 | Click the edit icon.
STEP 4 | Select Enabled for Security Policy from the Use X-Forwarded-For Header drop-down.
You cannot enabled Use X-Forwarded-For Header for security policy and User-ID at the
same me.
STEP 5 | (Oponal) Select Strip X-Forwarded-For Header. Selecng this opon removes the XFF
header before the firewall forwards the request. This opon does not disable the use of XFF
headers; the firewall uses the XFF header for policy enforcement and logging.
STEP 6 | Click OK.
Display XFF Values in Logs

In addion to XFF header usage in security policy, you can view the XFF IP address in various logs,
reports, and the Applicaon Command Center (ACC) to aide in monitoring and troubleshoong.
You can add the X-Forwarded-For column in Traffic, Threat, Data Filtering, and Wildfire
Submissions logs.
For non-URL Filtering logs, XFF IP logging is supported only when packet capture is no
enabled.
To view the XFF IP address in your logs, complete the following steps.
Policy
STEP 2 | Select Monitoring > Logs.
STEP 3 | Select Traffic, Threat, Data Filtering, or Wildfire Submissions.
STEP 4 | Click the arrow to the right of any column header and select Columns.
STEP 5 | Select X-Forwarded-For IP to display the XFF IP in your log.
Display XFF Values in Reports

Predefined reports generate the firewall do not contain XFF values. To view XFF IP addresses in
reports, the firewall includes built-in report templates that include XFF informaon.
STEP 2 | Select Monitor > Manage Custom Reports > Add.
STEP 3 | Click Load Template.
Policy
STEP 4 | Enter XFF into the search bar and click the search buon to locate the built-in XFF report
templates.
STEP 5 | Click Load.
STEP 6 | Configure your custom report Time Frame, Sort By, and Group By to display the XFF
informaon in the manner best suited to your needs.
STEP 7 | (Oponal) Click Run Now to generate your report on demand instead of, or in addion to, a
Scheduled Time.
Use the IP Address in the XFF Header to Troubleshoot Events

By default, the firewall does not log the source address of a client behind a proxy server, even if
you are using this address from the X-Forwarded-For (XFF) header for user mapping. Therefore,
while you can idenfy the specific user associated with a log event, you will not be able to
easily idenfy the source device that originated the log event. To simplify the debugging and
troubleshoong of events for users behind a proxy server, you must enable the X-Forwarded-For
opon within HTTP Header Logging in the URL Filtering profile that you aach to security policy
rules that allow access to web-based applicaons. With this opon enabled, the firewall logs the
IP address from the XFF header as the Source address for all traffic that matches the rule.
Enabling the firewall to use the XFF header as the Source address in URL Filtering logs
does not enable user mapping of the source address. To populate the source user fields, see
Use XFF Values for Policies and Logging Source Users.
Policy
STEP 1 | Enable the X-Forwarded-For opon within HTTP Header Logging in the URL Filtering profile.
1. Select Objects > Security Profiles > URL Filtering and select the URL Filtering profile you
want to configure, or add a new one.
You can’t enable XFF logging in the default URL Filtering profile.
2. Select the Sengs tab and select X-Forwarded-For.

STEP 2 | Aach the URL Filtering profile to the security policy rule(s) that enable access to web
applicaons.
1. Select Policies > Security and click the rule.
2. Select the Acons tab, set the Profile Type to Profiles, and select the URL Filtering
profile you just configured for X-Forwarded-For HTTP Header Logging.
STEP 3 | Verify the firewall is logging XFF values.

1. Select Monitor > Logs > URL Filtering.
2. View the XFF values in one of the following ways:
• To display the XFF value for a single URL Filtering log—Click the spyglass icon for the
log to displays its details. The HTTP Headers secon displays the X-Forwarded-For
value.
• To display the XFF values for all URL Filtering logs—Open the drop-down in any
column header, select Columns, and select X-Forwarded-For. The page then displays
an X-Forwarded-For column.
STEP 4 | Use the XFF field in the URL Filtering log to troubleshoot a log event in another log type.
Although only the URL Filtering logs display the IP address of the source user in the X-
Forwarded-For column of the logs, if you noce an event associated with HTTP/HTTPS traffic
but that you cannot idenfy the source IP address because it is that of the proxy server, you
can use the X-Forwarded-For value in a correlated URL Filtering log to help you idenfy the
source address associated with the log event. To do this:
1. Find an event you want invesgate in a Traffic, Threat, or WildFire Submissions logs that
is showing the IP address of the proxy server as the source address.
2. Click the spyglass icon for the log to display its details and look for an associated URL
Filtering log at the boom of the Detailed Log Viewer window.
3. Select the header row and then select X-Forwarded-For from the Columns drop-down
to display this value. The IP address in this column of the X-Forwarded-For column
represents the IP address of the source user behind the proxy server. Use this IP address
to track down the device that triggered the event you are invesgang.
Policy
Policy-Based Forwarding
Normally, the firewall uses the desnaon IP address in a packet to determine the outgoing
interface. The firewall uses the roung table associated with the virtual router to which the
interface is connected to perform the route lookup. Policy-Based Forwarding (PBF) allows you
to override the roung table, and specify the outgoing or egress interface based on specific
parameters such as source or desnaon IP address, or type of traffic.
• PBF
• Create a Policy-Based Forwarding Rule
• Use Case: PBF for Outbound Access with Dual ISPs
PBF
PBF rules allow traffic to take an alternave path from the next hop specified in the route table,
and are typically used to specify an egress interface for security or performance reasons. Let's
say your company has two links between the corporate office and the branch office: a cheaper
internet link and a more expensive leased line. The leased line is a high-bandwidth, low-latency
link. For enhanced security, you can use PBF to send applicaons that aren’t encrypted traffic,
such as FTP traffic, over the private leased line and all other traffic over the internet link. Or, for
performance, you can choose to route business-crical applicaons over the leased line while
sending all other traffic, such as web browsing, over the cheaper link.
• Egress Path and Symmetric Return
• Path Monitoring for PBF
• Service Versus Applicaons in PBF
Egress Path and Symmetric Return

Using PBF, you can direct traffic to a specific interface on the firewall, drop the traffic, or direct
traffic to another virtual system (on systems enabled for mulple virtual systems).
In networks with asymmetric routes, such as in a dual ISP environment, connecvity issues occur
when traffic arrives at one interface on the firewall and leaves from another interface. If the route
is asymmetrical, where the forward (SYN packet) and return (SYN/ACK) paths are different, the
firewall is unable to track the state of the enre session and this causes a connecon failure. To
ensure that the traffic uses a symmetrical path, which means that the traffic arrives at and leaves
from the same interface on which the session was created, you can enable the Symmetric Return
opon.
With symmetric return, the virtual router overrides a roung lookup for return traffic and instead
directs the flow back to the MAC address from which it received the SYN packet (or first packet).
However, if the desnaon IP address is on the same subnet as the ingress/egress interface’s IP
address, a route lookup is performed and symmetric return is not enforced. This behavior prevents
traffic from being silently discarded.
To determine the next hop for symmetric returns, the firewall uses an Address Resoluon
Protocol (ARP) table. The maximum number of entries that this ARP table supports is
limited by the firewall model and the value is not user configurable. To determine the limit
for your model, use the CLI command: show pbf return-mac all.
Policy
Path Monitoring for PBF

Path monitoring allows you to verify connecvity to an IP address so that the firewall can direct
traffic through an alternate route, when needed. The firewall uses ICMP pings as heartbeats to
verify that the specified IP address is reachable.
A monitoring profile allows you to specify the threshold number of heartbeats to determine
whether the IP address is reachable. When the monitored IP address is unreachable, you can
either disable the PBF rule or specify a fail-over or wait-recover acon. Disabling the PBF rule
allows the virtual router to take over the roung decisions. When the fail-over or wait-recover
acon is taken, the monitoring profile connues to monitor whether the target IP address is
reachable, and when it comes back up, the firewall reverts back to using the original route.
The following table lists the difference in behavior for a path monitoring failure on a new session
versus an established session.
Behavior of a session If the rule stays enabled when If rule is disabled when the
on a monitoring failure the monitored IP address is monitored IP address is
unreachable unreachable
For an established wait-recover—Connue to use wait-recover—Connue to use

session egress interface specified in egress interface specified in the
the PBF rule PBF rule
fail-over—Use path fail-over—Use path determined by

determined by roung table roung table (no PBF)
(no PBF)
For a new session wait-recover—Use path wait-recover—Check the remaining

determined by roung table PBF rules. If no match, use the
(no PBF) roung table
fail-over—Use path fail-over—Check the remaining

determined by roung table PBF rules. If no match, use the
(no PBF) roung table
Service Versus Applicaons in PBF

PBF rules are applied either on the first packet (SYN) or the first response to the first packet (SYN/
ACK). This means that a PBF rule may be applied before the firewall has enough informaon to
determine the applicaon. Therefore, applicaon-specific rules are not recommended for use with
PBF. Whenever possible, use a service object, which is the Layer 4 port (TCP or UDP) used by the
protocol or applicaon.
However, if you specify an applicaon in a PBF rule, the firewall performs App-ID caching. When
an applicaon passes through the firewall for the first me, the firewall does not have enough
informaon to idenfy the applicaon and therefore cannot enforce the PBF rule. As more
packets arrive, the firewall determines the applicaon and creates an entry in the App-ID cache
and retains this App-ID for the session.When a new session is created with the same desnaon
IP address, desnaon port, and protocol ID, the firewall could idenfy the applicaon as the
Policy
same from the inial session (based on the App-ID cache) and apply the PBF rule. Therefore, a
session that is not an exact match and is not the same applicaon, can be forwarded based on the
PBF rule.
Further, applicaons have dependencies and the identy of the applicaon can change as the
firewall receives more packets. Because PBF makes a roung decision at the start of a session,
the firewall cannot enforce a change in applicaon identy. YouTube, for example, starts as web-
browsing but changes to Flash, RTSP, or YouTube based on the different links and videos included
on the page. However with PBF, because the firewall idenfies the applicaon as web-browsing at
the start of the session, the change in applicaon is not recognized thereaer.
You cannot use custom applicaons, applicaon filters, or applicaon groups in PBF rules.
Create a Policy-Based Forwarding Rule

Use a PBF rule to direct traffic to a specific egress interface on the firewall and override the
default path for the traffic.
Policy
STEP 1 | Create a Policy-Based Forwarding (PBF) rule.

When creang a PBF rule, you must specify a name for the rule, a source zone or interface, and
an egress interface. All other components are either oponal or have a default value.
You can specify the source and desnaon addresses using an IP address, an address
object, or an FQDN.
1. Select Policies > Policy Based Forwarding and Add a PBF policy rule.
2. Give the rule a descripve name (General).
3. Select Source and configure the following:
1. Select the Type (Zone or Interface) to which you will apply the forwarding policy and
specify the relevant zone or interface. If you want to enforce symmetric return, you
must select a source interface.
Only Layer 3 interfaces support PBF; loopback interfaces do not support PBF.
2. (Oponal) Specify the Source Address to which the PBF rule applies. For example, a
specific IP address or subnet IP address from which you want to forward traffic to the
interface or zone specified in this rule.
Click Negate to exclude one or more Source Addresses from the PBF rule.
For example, if your PBF rule directs all traffic from the specified zone to the
internet, Negate allows you to exclude internal IP addresses from the PBF
rule.
The evaluaon order is top down. A packet is matched against the first rule that meets
the defined criteria; aer a match is triggered, subsequent rules are not evaluated.
3. (Oponal) Add and select the Source User or groups of users to whom the policy
applies.
4. Select Desnaon/Applicaon/Service and configure the following:
1. Desnaon Address—By default, the rule applies to Any IP address. Click Negate to
exclude one or more desnaon IP addresses from the PBF rule.
2. Add any Applicaon and Service that you want to control using PBF.
We do not recommend applicaon-specific rules for use with PBF because

PBF rules may be applied before the firewall has enough informaon to
determine the applicaon. Whenever possible, use a service object, which is
the Layer 4 port (TCP or UDP) used by the protocol or applicaon. For more
details, see Service Versus Applicaons in PBF.
Policy
STEP 2 | Specify how to forward packets that match the rule.
If you are configuring PBF in a mul-VSYS environment, you must create separate
PBF rules for each virtual system (and create the appropriate Security policy rules to
enable the traffic).
1. Select Forwarding.
2. Set the Acon to take when matching a packet:
• Forward—Directs the packet to the specified Egress Interface.
• Forward to VSYS (On a firewall enabled for mulple virtual systems)—Select the
virtual system to which to forward the packet.
• Discard—Drops the packet.
• No PBF—Excludes packets that match the criteria for source, desnaon, applicaon,
or service defined in the rule. Matching packets use the route table instead of PBF;
the firewall uses the route table to exclude the matched traffic from the redirected
port.
3. To trigger the specified Acon at a daily, weekly, or non-recurring frequency, create and
aach a Schedule.
4. For Next Hop, select one of the following:
• IP Address—Enter an IP address or select an address object of type IP Netmask to
which the firewall forwards matching packets. An IPv4 address object must have a /32
netmask and an IPv6 address object must have a /128 netmask.
• FQDN—Enter an FQDN (or select or create an address object of type FQDN) to which
the firewall forwards matching packets. The FQDN can resolve to an IPv4 address, an
IPv6 address, or both. If the FQDN resolves to both IPv4 and IPv6 addresses, then the
PBF rule has two next hops: one IPv4 address and one IPv6 address. You can use the
same PBF rule for both IPv4 and IPv6 traffic. IPv4 traffic is forwarded to the IPv4 next
hop; IPv6 traffic is forwarded to the IPv6 next hop.
This FQDN must resolve to an IP address that belongs to the same subnet
as the interface you configured for PBF; otherwise, the firewall rejects the
resoluon and the FQDN remains unresolved.
The firewall uses only one IP address (from each IPv4 or IPv6 family type)
from the DNS resoluon of the FQDN. If the DNS resoluon returns more
than one address, the firewall uses the preferred IP address that matches
the IP family type (IPv4 or IPv6) configured for the next hop. The preferred
IP address is the first address the DNS server returns in its inial response.
The firewall retains this address as preferred as long as the address appears in
subsequent responses, regardless of order.
• None—No next hop mean the desnaon IP address of the packet is used as the next
hop. Forwarding fails if the desnaon IP address is not in the same subnet as the
egress interface.
5. (Oponal) Enable monitoring to verify connecvity to a target IP address or to the Next
Hop IP address if no IP address is specified. Select Monitor and aach a monitoring
Policy
Profile (default or custom) that specifies the acon when the monitored address is
unreachable.
• You can Disable this rule if nexthop/monitor ip is unreachable.
• Enter a target IP Address to monitor.
The Egress Interface can have both IPv4 and IPv6 addresses and the Next Hop FQDN
can resolve to both IPv4 and IPv6 addresses. In this case:
1. If the egress interface has both IPv4 and IPv6 addresses and the next hop FQDN
resolves to only one address family type, the firewall monitors the resolved IP address.
If the FQDN resolves to both IPv4 and IPv6 addresses but the egress interface has
only one address family type address, the firewall monitors the resolved next hop
address that matches the address family of the egress interface.
2. If both the egress interface and next hop FQDN have both IPv4 and IPv6 addresses,
the firewall monitors the IPv4 next hop address.
3. If the egress interface has one address family address and the next hop FQDN
resolves to a different address family address, the firewall does not monitor anything.
6. (Required for asymmetric roung environments; otherwise, oponal) Enforce Symmetric
Return and Add one or more IP addresses in the Next Hop Address List. You can add up
to 8 next-hop IP addresses; tunnel and PPoE interfaces are not available as a next-hop IP
address.
Enabling symmetric return ensures that return traffic (such asfrom the Trust zone on the
LAN to the internet) is forwarded out through the same interface through which traffic
ingresses from the internet.
STEP 3 | Commit your changes. The PBF rule is in effect.
Use Case: PBF for Outbound Access with Dual ISPs

In this use case, the branch office has a dual ISP configuraon and implements PBF for redundant
internet access. The backup ISP is the default route for traffic from the client to the web servers.
In order to enable redundant internet access without using an internetwork protocol such as BGP,
we use PBF with desnaon interface-based source NAT and stac routes, and configure the
firewall as follows:
• Enable a PBF rule that routes traffic through the primary ISP, and aach a monitoring profile
to the rule. The monitoring profile triggers the firewall to use the default route through the
backup ISP when the primary ISP is unavailable.
• Define Source NAT rules for both the primary and backup ISP that instruct the firewall to
use the source IP address associated with the egress interface for the corresponding ISP. This
ensures that the outbound traffic has the correct source IP address.
• Add a stac route to the backup ISP, so that when the primary ISP is unavailable, the default
route comes into effect and the traffic is directed through the backup ISP.
Policy
Policy
STEP 1 | Configure the ingress and the egress interfaces on the firewall.
Egress interfaces can be in the same zone.
1. Select Network > Interfaces and select the interface you want to configure.
The interface configuraon on the firewall used in this example is as follows:
• Ethernet 1/19 connected to the primary ISP:
• Zone: TwoISP
• IP Address: 1.1.1.2/30
• Virtual Router: Default
• Ethernet 1/20 connected to the backup ISP:
• Zone: TwoISP
• IP Address: 2.2.2.2/30
• Ethernet 1/2 is the ingress interface, used by the network clients to connect to the
internet:
• Zone: Corporate
• IP Address: 192.168. 54.1/24
Policy
STEP 2 | On the virtual router, add a stac route to the backup ISP.
1. Select Network > Virtual Router and select the default link to open the Virtual Router
dialog.
2. Select Stac Routes and click Add. Enter a Name for the route and specify the
Desnaon IP address for which you are defining the stac route. In this example, we
use 0.0.0.0/0 for all traffic.
3. Select the IP Address radio buon and set the Next Hop IP address for your router that
connects to the backup internet gateway (you cannot use a domain name for the next
hop). In this example, 2.2.2.1.
4. Specify a cost metric for the route.
5. Click OK twice to save the virtual router configuraon.
Policy
STEP 3 | Create a PBF rule that directs traffic to the interface that is connected to the primary ISP.
Make sure to exclude traffic desned to internal servers/IP addresses from PBF. Define a
negate rule so that traffic desned to internal IP addresses is not routed through the egress
interface defined in the PBF rule.
1. Select Policies > Policy Based Forwarding and click Add.
2. Give the rule a descripve Name in the General tab.
3. In the Source tab, set the Source Zone; in this example, the zone is Corporate.
4. In the Desnaon/Applicaon/Service tab, set the following:
1. In the Desnaon Address secon, Add the IP addresses or address range for servers
on the internal network or create an address object for your internal servers. Select
Negate to exclude the IP addresses or address object listed above from using this rule.
2. In the Service secon, Add the service-hp and service-hps services to allow HTTP
and HTTPS traffic to use the default ports. For all other traffic that is allowed by
security policy, the default route will be used.
To forward all traffic using PBF, set the Service to Any.
Policy
STEP 4 | Specify where to forward traffic.

1. In the Forwarding tab, specify the interface to which you want to forward traffic and
enable path monitoring.
2. To forward traffic, set the Acon to Forward, and select the Egress Interface and specify
the Next Hop. In this example, the egress interface is ethernet1/19, and the next hop IP
address is 1.1.1.1 (you cannot use a FQDN for the next hop).
3. Enable Monitor and aach the default monitoring profile to trigger a failover to the
backup ISP. In this example, we do not specify a target IP address to monitor. The firewall
will monitor the next hop IP address; if this IP address is unreachable, the firewall will
direct traffic to the default route specified on the virtual router.
4. (Required if you have asymmetric routes) Select Enforce Symmetric Return to ensure
that return traffic from the Corporate zone to the internet is forwarded out on the same
interface through which traffic ingressed from the internet.
5. NAT ensures that the traffic from the internet is returned to the correct interface/IP
address on the firewall.
6. Click OK to save the changes.
Policy
STEP 5 | Create NAT rules based on the egress interface and ISP. These rules ensure that the correct
source IP address is used for outbound connecons.
2. In this example, the NAT rule we create for each ISP is as follows:
NAT for Primary ISP
In the Original Packet tab,
Source Zone: Corporate
Desnaon Zone: TwoISP
In the Translated Packet tab, under Source Address Translaon
Translaon Type: Dynamic IP and Port
Address Type: Interface Address
Interface: ethernet1/19
IP Address: 1.1.1.2/30
NAT for Backup ISP
In the Original Packet tab,
Source Zone: Corporate
Desnaon Zone: TwoISP
In the Translated Packet tab, under Source Address Translaon
Translaon Type: Dynamic IP and Port
Address Type: Interface Address
Interface: ethernet1/20
IP Address: 2.2.2.2/30
Policy
STEP 6 | Create security policy to allow outbound access to the internet.

To safely enable applicaons, create a simple rule that allows access to the internet and aach
the security profiles available on the firewall.
2. Give the rule a descripve Name in the General tab.
3. In the Source tab, set the Source Zone to Corporate.
4. In the Desnaon tab, Set the Desnaon Zone to TwoISP.
5. In the Service/ URL Category tab, leave the default applicaon-default.
6. In the Acons tab, complete these tasks:
1. Set the Acon Seng to Allow.
2. Aach the default profiles for Anvirus, An-Spyware, Vulnerability Protecon and
URL Filtering, under Profile Seng.
7. Under Opons, verify that logging is enabled at the end of a session. Only traffic that
matches a security rule is logged.
STEP 7 | Save the policies to the running configuraon on the firewall.

Click Commit.
STEP 8 | Verify that the PBF rule is acve and that the primary ISP is used for internet access.
1. Launch a web browser and access a web server. On the firewall, check the traffic log for
web-browsing acvity.
2. From a client on the network, use the ping ulity to verify connecvity to a web server
on the internet, and check the traffic log on the firewall.
C:\Users\pm-user1>ping 198.51.100.6
Pinging 198.51.100.6 with 32 bytes of data:
Reply from 198.51.100.6: bytes=32 time=34ms TTL=117
Ping statistics for 198.51.100.6:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milliseconds:
Minimum = 3ms, Maximum = 34ms, Average = 18ms
3. To confirm that the PBF rule is acve, use the following CLI command:
admin@PA-NGFW> show pbf rule all

Rule ID Rule State Action Egress IF/VSYS NextHop
Policy
========== === ========== ====== ==============

Use ISP-Pr 1 Active Forward ethernet1/1 1.1.1.1
STEP 9 | Verify that the failover to the backup ISP occurs and that the Source NAT is correctly applied.
1. Unplug the connecon to the primary ISP.
2. Confirm that the PBF rule is inacve with the following CLI command:
admin@PA-NGFW> show pbf rule all

Rule ID Rule State Action Egress IF/VSYS NextHop
========== === ========== ====== ============== ===
Use ISP-Pr 1 Disabled Forward ethernet1/19 1.1.1.1
3. Access a web server, and check the traffic log to verify that traffic is being forwarded
through the backup ISP.
4. View the session details to confirm that the NAT rule is working properly.
admin@PA-NGFW> show session all

---------------------------------------------------------
ID Application State Type Flag Src[Sport]/Zone/Proto
(translated IP[Port]) Vsys Dst[Dport]/Zone (translated
IP[Port])
---------------------------------------------------------
87212 ssl ACTIVE FLOW NS 192.168.54.56[53236]/Corporate/6
(2.2.2.2[12896]) vsys1 204.79.197.200[443]/TwoISP
(204.79.197.200[443])
5. Obtain the session idenficaon number from the output and view the session details.
The PBF rule is not used and hence is not listed in the output.
admin@PA-NGFW> show session id 87212

Session 87212
c2s flow:
source: 192.168.54.56 [Corporate]
dst: 204.79.197.200
proto: 6
sport: 53236 dport: 443
state: ACTIVE type: FLOW
src user: unknown
dst user: unknown
s2c flow:
source: 204.79.197.200 [TwoISP]
dst: 2.2.2.2
proto: 6
sport: 443 dport:
12896
Policy
state:
ACTIVE type: FLOW
src user:
unknown
dst user:
unknown
start time : Wed Nov5 11:16:10 2014
timeout : 1800 sec
time to live : 1757 sec
total byte count(c2s) : 1918
total byte count(s2c) : 4333
layer7 packet count(c2s) : 10
layer7 packet count(s2c) : 7
vsys : vsys1
application : ssl
rule : Corp2ISP
session to be logged at end : True
session in session ager : True
session synced from HA peer : False
address/port translation : source
nat-rule : NAT-Backup ISP(vsys1)
layer7 processing : enabled
URL filtering enabled : True
URL category : search-engines
session via syn-cookies : False
session terminated on host : False
session traverses tunnel : False
authentication portal session : False
ingress interface : ethernet1/2
egress interface : ethernet1/20
session QoS rule : N/A (class 4)
Policy
Test Policy Rules

Test the policy rules in your running configuraon to ensure that your policies appropriately allow
and deny traffic and access to applicaons and websites in compliance with your business needs
and requirements. You can test and verify that your policy rules are allowing and denying the
correct traffic by execung policy match tests for your firewalls directly from the web interface.
STEP 2 | Select Device > Troubleshoong to perform a policy match or connecvity test.
STEP 3 | Enter the required informaon to perform the policy match test. In this example, we run a
NAT policy match test.
1. Select Test—Select NAT Policy Match.
2. From—Select the zone traffic is originang from.
3. To—Select the target zone of the traffic.
4. Source—Enter the IP address from which traffic originated.
5. Desnaon—Enter the IP address of the target device for the traffic.
6. Desnaon Port—Enter the port used for the traffic. This port varies depending on the
IP protocol used in the following step.
7. Protocol—Enter the IP protocol used for the traffic.
8. If necessary, enter any addional informaon relevant for your NAT policy rule tesng.
STEP 4 | Execute the NAT policy match test.
STEP 5 | Review the NAT Policy Match Result to see the policy rules that match the test criteria.
Policy
Virtual Systems
This topic describes virtual systems, their benefits, typical use cases, and how to
configure them. It also provides links to other topics where virtual systems are
documented as they funcon with other features.
> Virtual Systems Overview

> Communicaon Between Virtual Systems
> Shared Gateway
> Configure Virtual Systems
> Configure Inter-Virtual System Communicaon within the Firewall
> Configure a Shared Gateway
> Customize Service Routes for a Virtual System
> Virtual System Funconality with Other Features
1423
Virtual Systems
Virtual Systems Overview

Virtual systems are separate, logical firewall instances within a single physical Palo Alto Networks
firewall. Rather than using mulple firewalls, managed service providers and enterprises can use
a single pair of firewalls (for high availability) and enable virtual systems on them. Each virtual
system (vsys) is an independent, separately-managed firewall with its traffic kept separate from the
traffic of other virtual systems.
• Virtual System Components and Segmentaon
• Benefits of Virtual Systems
• Use Cases for Virtual Systems
• Plaorm Support and Licensing for Virtual Systems
• Administrave Roles for Virtual Systems
• Shared Objects for Virtual Systems
Virtual System Components and Segmentaon

A virtual system is an object that creates an administrave boundary, as shown in the following
figure.
A virtual system consists of a set of physical and logical interfaces and subinterfaces (including
VLANs and virtual wires), virtual routers, and security zones. You choose the deployment mode(s)
(any combinaon of virtual wire, Layer 2, or Layer 3) of each virtual system. By using virtual
systems, you can segment any of the following:
• Administrave access
Virtual Systems
• The management of all policies (Security, NAT, QoS, Policy-based Forwarding, Decrypon,
Applicaon Override, Tunnel Inspecon, Authencaon, and DoS protecon)
• All objects (such as address objects, applicaon groups and filters, external dynamic lists,
security profiles, decrypon profiles, custom objects, etc.)
• User-ID
• Cerficate management
• Server profiles
• Logging, reporng, and visibility funcons
Virtual systems affect the security funcons of the firewall, but virtual systems alone do not affect
networking funcons such as stac and dynamic roung. You can segment roung for each virtual
system by creang one or more virtual routers for each virtual system, as in the following use
cases:
• If you have virtual systems for departments of one organizaon, and the network traffic for
all of the departments is within a common network, you can create a single virtual router for
• If you want roung segmentaon and each virtual system’s traffic must be isolated from other
virtual systems, you can create one or more virtual routers for each virtual system.
• If you want to segment the user mappings so that not all mappings are shared across virtual
systems, you can configure the User-ID sources on a virtual system that is not a User-ID hub.
See Share User-ID Mappings Across Virtual Systems.
Benefits of Virtual Systems

Virtual systems provide the same basic funcons as a physical firewall, along with addional
benefits:
• Segmented administraon—Different organizaons (or customers or business units) can control
(and monitor) a separate firewall instance, so that they have control over their own traffic
without interfering with the traffic or policies of another firewall instance on the same physical
firewall.
• Scalability—Aer the physical firewall is configured, adding or removing customers or business
units can be done efficiently. An ISP, managed security service provider, or enterprise can
provide different security services to each customer.
• Reduced capital and operaonal expenses—Virtual systems eliminate the need to have
mulple physical firewalls at one locaon because virtual systems co-exist on one firewall. By
not having to purchase mulple firewalls, an organizaon can save on the hardware expense,
electric bills, and rack space, and can reduce maintenance and management expenses.
• Ability to share IP-address-to-username mappings—By assigning a virtual system as a User-ID
hub, you can share the IP-address-to-username mappings across virtual systems to leverage the
full User-ID capacity of the firewall and reduce operaonal complexity.
Use Cases for Virtual Systems

There are many ways to use virtual systems in a network. One common use case is for an ISP
or a managed security service provider (MSSP) to deliver services to mulple customers with
a single firewall. Customers can choose from a wide array of services that can be enabled or
Virtual Systems
disabled easily. The firewall’s role-based administraon allows the ISP or MSSP to control each
customer’s access to funconality (such as logging and reporng) while hiding or offering read-
only capabilies for other funcons.
Another common use case is within a large enterprise that requires different firewall instances
because of different technical or confidenality requirements among mulple departments.
Like the above case, different groups can have different levels of access while IT manages the
firewall itself. Services can be tracked and/or billed back to departments to thereby make separate
financial accountability possible within an organizaon.
Plaorm Support and Licensing for Virtual Systems

Virtual systems are supported on PA-3200 Series, PA-5200 Series, and PA-7000 Series firewalls.
Each firewall series supports a base number of virtual systems; the number varies by plaorm. A
Virtual Systems license is required to support mulple virtual systems on PA-3200 Series firewalls,
and to create more than the base number of virtual systems supported on a plaorm.
For license informaon, see Subscripons. For the base and maximum number of virtual systems
supported, see Compare Firewalls tool.
Mulple virtual systems are not supported on the PA-220, PA-800 Series, or VM-Series firewalls.
The default is vsys1. You cannot delete vsys1 because it is relevant to the internal
hierarchy on the firewall; vsys1 appears even on firewall models that don’t support
You can limit the resource allocaons for sessions, rules and VPN tunnels allowed for a virtual
system, and thereby control firewall resources. Each resource seng displays the valid range of
values, which varies per firewall model. The default seng is 0, which means the limit for the
virtual system is the limit for the firewall model. However, the limit for a specific seng isn’t
replicated for each virtual system. For example, if a firewall has four virtual systems, each virtual
system can’t have the total number of Decrypon Rules allowed per firewall. Aer the total
number of Decrypon Rules for all of the virtual systems reaches the firewall limit, you cannot add
more.
Administrave Roles for Virtual Systems

A Superuser administrator can create virtual systems and add a Device administrator,
vsysadmin, or vsysreader. A Device administrator can access all virtual systems, but cannot add
administrators. When you create an Admin Role profile and select the role to be Virtual System,
the role applies to specific virtual systems on the firewall. From the Command Line tab, the two
types of virtual system administrave roles are:
• vsysadmin—Has access to specific virtual systems on the firewall to create and manage specific
aspects of virtual systems. A vsysadmin doesn’t have access to network interfaces, VLANs,
virtual wires, virtual routers, IPSec tunnels, GRE tunnels, DHCP, DNS Proxy, QoS, LLDP, or
network profiles. Persons with vsysadmin permission can commit configuraons for only the
virtual systems assigned to them.
• vsysreader—Has read-only access to specific virtual systems on the firewall and specific aspects
of virtual systems. A vsysreader doesn’t have access to network interfaces, VLANs, virtual
wires, virtual routers, IPSec tunnels, GRE tunnels, DHCP, DNS Proxy, QoS, LLDP, or network
profiles.
Virtual Systems
A virtual system administrator can view logs of only the virtual systems assigned to that
administrator. A Superuser or Device administrator can view all of the logs, select a virtual system
to view, or configure a virtual system as a User-ID hub.
Shared Objects for Virtual Systems

If your administrator account extends to mulple virtual systems, you can choose to configure
objects (such as an address object) and policies for a specific virtual system or as shared objects,
which apply to all of the virtual systems on the firewall. If you try to create a shared object with
the same name and type as an exisng object in a virtual system, the virtual system object is used.
Virtual Systems
Communicaon Between Virtual Systems

There are two typical scenarios where communicaon between virtual systems (inter-vsys traffic)
is desirable. In a mul-tenancy environment, communicaon between virtual systems can occur
by having traffic leave the firewall, go through the Internet, and re-enter the firewall. In a single
organizaon environment, communicaon between virtual systems can remain within the firewall.
This secon discusses both scenarios.
• Inter-VSYS Traffic That Must Leave the Firewall
• Inter-VSYS Traffic That Remains Within the Firewall
• Inter-VSYS Communicaon Uses Two Sessions
Inter-VSYS Traffic That Must Leave the Firewall

An ISP that has mulple customers on a firewall (known as mul-tenancy) can use a virtual system
for each customer, and thereby give each customer control over its virtual system configuraon.
The ISP grants vsysadmin permission to customers. Each customer’s traffic and management are
isolated from the others. Each virtual system must be configured with its own IP address and one
or more virtual routers in order to manage traffic and its own connecon to the Internet.
If the virtual systems need to communicate with each other, that traffic goes out the firewall to
another Layer 3 roung device and back to the firewall, even though the virtual systems exist on
the same physical firewall, as shown in the following figure.
Virtual Systems
Inter-VSYS Traffic That Remains Within the Firewall

Unlike the preceding mul-tenancy scenario, virtual systems on a firewall can be under the control
of a single organizaon. The organizaon wants to both isolate traffic between virtual systems
and allow communicaons between virtual systems. This common use case arises when the
organizaon wants to provide departmental separaon and sll have the departments be able to
communicate with each other or connect to the same network(s). In this scenario, the inter-vsys
traffic remains within the firewall, as described in the following topics:
• External Zone
• External Zones and Security Policies For Traffic Within a Firewall
External Zone
The communicaon desired in the use case above is achieved by configuring security policies that
point to or from an external zone. An external zone is a security object that is associated with a
specific virtual system that it can reach; the zone is external to the virtual system. A virtual system
can have only one external zone, regardless of how many security zones the virtual system has
within it. External zones are required to allow traffic between zones in different virtual systems,
without the traffic leaving the firewall.
The virtual system administrator configures the security policies needed to allow traffic between
two virtual systems. Unlike security zones, an external zone is not associated with an interface;
it is associated with a virtual system. The security policy allows or denies traffic between the
security (internal) zone and the external zone.
Because external zones do not have interfaces or IP addresses associated with them, some zone
protecon profiles are not supported on external zones.
Remember that each virtual system is a separate instance of a firewall, which means that each
packet moving between virtual systems is inspected for security policy and App-ID evaluaon.
External Zones and Security Policies For Traffic Within a Firewall

In the following example, an enterprise has two separate administrave groups: the departmentA
and departmentB virtual systems. The following figure shows the external zone associated with
each virtual system, and traffic flowing from one trust zone, out an external zone, into an external
zone of another virtual system, and into its trust zone.
Virtual Systems
To create external zones, the firewall administrator must configure the virtual systems so that they
are visible to each other. External zones do not have security policies between them because their
virtual systems are visible to each other.
To communicate between virtual systems, the ingress and egress interfaces on the firewall are
either assigned to a single virtual router or else they are connected using inter-virtual router
stac routes. The simpler of these two approaches is to assign all virtual systems that must
communicate with each other to a single virtual router.
There might be a reason that the virtual systems need to have their own virtual router, for
example, if the virtual systems use overlapping IP address ranges. Traffic can be routed between
the virtual systems, but each virtual router must have stac routes that point to the other virtual
router(s) as the next hop.
Referring to the scenario in the figure above, we have an enterprise with two administrave
groups: departmentA and departmentB. The departmentA group manages the local network and
the DMZ resources. The departmentB group manages traffic in and out of the sales segment
of the network. All traffic is on a local network, so a single virtual router is used. There are two
external zones configured for communicaon between the two virtual systems. The departmentA
virtual system has three zones used in security policies: deptA-DMZ, deptA-trust, and deptA-
External. The departmentB virtual system also has three zones: deptB-DMZ, deptB-trust, and
deptB-External. Both groups can control the traffic passing through their virtual systems.
In order to allow traffic from deptA-trust to deptB-trust, two security policies are required. In the
following figure, the two vercal arrows indicate where the security policies (described below the
figure) are controlling traffic.
• Security Policy 1: In the preceding figure, traffic is desned for the deptB-trust zone. Traffic
leaves the deptA-trust zone and goes to the deptA-External zone. A security policy must allow
traffic from the source zone (deptA-trust) to the desnaon zone (deptA-External). A virtual
system allows any policy type to be used for this traffic, including NAT.
No policy is needed between external zones because traffic sent to an external zone appears
in and has automac access to the other external zones that are visible to the original external
zone.
• Security Policy 2: In the preceding figure, the traffic from deptB-External is sll desned to the
deptB-trust zone, and a security policy must be configured to allow it. The policy must allow
traffic from the source zone (deptB-External) to the desnaon zone (deptB-trust).
The departmentB virtual system could be configured to block traffic from the departmentA virtual
system, and vice versa. Like traffic from any other zone, traffic from external zones must be
explicitly allowed by policy to reach other zones in a virtual system.
Virtual Systems
In addion to external zones being required for inter-virtual system traffic that does not
leave the firewall, external zones are also required if you configure a Shared Gateway, in
which case the traffic is intended to leave the firewall.
Inter-VSYS Communicaon Uses Two Sessions

It is helpful to understand that communicaon between two virtual systems uses two sessions,
unlike the one session used for a single virtual system. Let’s compare the scenarios.
Scenario 1—Vsys1 has two zones: trust1 and untrust1. A host in the trust1 zone iniates traffic
when it needs to communicate with a device in the untrust1 zone. The host sends traffic to
the firewall, and the firewall creates a new session for source zone trust1 to desnaon zone
untrust1. Only one session is needed for this traffic.
Scenario 2—A host from vsys1 needs to access a server on vsys2. A host in the trust1 zone
iniates traffic to the firewall, and the firewall creates the first session: source zone trust1 to
desnaon zone untrust1. Traffic is routed to vsys2, either internally or externally. Then the
firewall creates a second session: source zone untrust2 to desnaon zone trust2. Two sessions
are needed for this inter-vsys traffic.
Virtual Systems
Shared Gateway
This topic includes the following informaon about shared gateways:
• External Zones and Shared Gateway
• Networking Consideraons for a Shared Gateway
External Zones and Shared Gateway

A shared gateway is an interface that mulple virtual systems share in order to communicate over
the Internet. Each virtual system requires an External Zone, which acts as an intermediary, for
configuring security policies that allow or deny traffic from the virtual system’s internal zone to the
shared gateway.
The shared gateway uses a single virtual router to route traffic for all virtual systems. A shared
gateway is used in cases when an interface does not need a full administrave boundary around it,
or when mulple virtual systems must share a single Internet connecon. This second case arises
if an ISP provides an organizaon with only one IP address (interface), but mulple virtual systems
need external communicaon.
Unlike the behavior between virtual systems, security policy and App-ID evaluaons are not
performed between a virtual system and a shared gateway. That is why using a shared gateway to
access the Internet involves less overhead than creang another virtual system to do so.
In the following figure, three customers share a firewall, but there is only one interface accessible
to the Internet. Creang another virtual system would add the overhead of App-ID and security
policy evaluaon for traffic being sent to the interface through the added virtual system. To avoid
adding another virtual system, the soluon is to configure a shared gateway, as shown in the
following diagram.
The shared gateway has one globally-routable IP address used to communicate with the outside
world. Interfaces in the virtual systems have IP addresses too, but they can be private, non-
routable IP addresses.
Virtual Systems
You will recall that an administrator must specify whether a virtual system is visible to other virtual
systems. Unlike a virtual system, a shared gateway is always visible to all of the virtual systems on
the firewall.
A shared gateway ID number appears as sg<ID> on the web interface. It is recommended that you
name your shared gateway with a name that includes its ID number.
When you add objects such as zones or interfaces to a shared gateway, the shared gateway
appears as an available virtual system in the vsys menu.
A shared gateway is a limited version of a virtual system; it supports NAT and policy-based
forwarding (PBF), but does not support Security, DoS policies, QoS, Decrypon, Applicaon
Override, or Authencaon policies.
Networking Consideraons for a Shared Gateway

Keep the following in mind while you are configuring a shared gateway.
• The virtual systems in a shared gateway scenario access the Internet through the shared
gateway’s physical interface, using a single IP address. If the IP addresses of the virtual systems
are not globally routable, configure source NAT to translate those addresses to globally-
routable IP addresses.
• A virtual router routes the traffic for all of the virtual systems through the shared gateway.
• The default route for the virtual systems should point to the shared gateway.
• Security policies must be configured for each virtual system to allow the traffic between the
internal zone and external zone, which is visible to the shared gateway.
• A firewall administrator should control the virtual router, so that no member of a virtual system
can affect the traffic of other virtual systems.
• Within a Palo Alto Networks firewall, a packet may hop from one virtual system to another
virtual system or a shared gateway. A packet may not traverse more than two virtual systems
or shared gateways. For example, a packet cannot go from vsys1 to vsys2 to vsys3, or similarly
from vsys1 to vsys2 to shared gateway1. Both examples involve more than two virtual systems,
which is not permied.
To save configuraon me and effort, consider the following advantages of a shared gateway:
• Rather than configure NAT for mulple virtual systems associated with a shared gateway, you
can configure NAT for the shared gateway.
• Rather than configure policy-based roung (PBR) for mulple virtual systems associated with a
shared gateway, you can configure PBR for the shared gateway.
Virtual Systems
Configure Virtual Systems

Creang a virtual system requires that you have the following:
• A superuser administrave role.
• An interface configured.
• A Virtual Systems license if you are creang more than the base number of virtual systems
supported on the plaorm. See Plaorm Support and Licensing for Virtual Systems.
STEP 1 | Enable virtual systems.
1. Select Device > Setup > Management and edit the General Sengs.
2. Select the Mul Virtual System Capability check box and click OK. This acon triggers a
commit if you approve it.
Only aer enabling virtual systems will the Device tab display the Virtual Systems and
Shared Gateways opons.
STEP 2 | Create a virtual system.

1. Select Device > Virtual Systems, click Add and enter a virtual system ID, which is
appended to “vsys” (range is 1-255).
The default is vsys1. You cannot delete vsys1 because it is relevant to the
internal hierarchy on the firewall; vsys1 appears even on firewall models that
don’t support mulple virtual systems.
2. Select Allow forwarding of decrypted content if you want to allow the firewall to
forward decrypted content to an outside service. For example, you must enable this
opon for the firewall to be able to send decrypted content to WildFire for analysis.
3. Enter a descripve Name for the virtual system. A maximum of 31 alphanumeric, space,
and underscore characters is allowed.
Virtual Systems
STEP 3 | Assign interfaces to the virtual system.

The virtual routers, virtual wires, or VLANs can either be configured already or you can
configure them later, at which point you specify the virtual system associated with each.
1. On the General tab, select a DNS Proxy object if you want to apply DNS proxy rules to
the interface.
2. In the Interfaces field, click Add to enter the interfaces or subinterfaces to assign to the
virtual system. An interface can belong to only one virtual system.
3. Do any of the following, based on the deployment type(s) you need in the virtual system:
• In the VLANs field, click Add to enter the VLAN(s) to assign to the vsys.
• In the Virtual Wires field, click Add to enter the virtual wire(s) to assign to the vsys.
• In the Virtual Routers field, click Add to enter the virtual router(s) to assign to the
vsys.
4. In the Visible Virtual System field, check all virtual systems that should be made visible
to the virtual system being configured. This is required for virtual systems that need to
communicate with each other.
In a mul-tenancy scenario where strict administrave boundaries are required, no
virtual systems would be checked.
5. Click OK.
STEP 4 | (Oponal) Limit the resource allocaons for sessions, rules, and VPN tunnels allowed for the
virtual system. The flexibility of being able to allocate limits per virtual system allows you to
effecvely control firewall resources.
1. On the Resource tab, oponally set limits for a virtual system. Each field displays the
valid range of values, which varies per firewall model. The default seng is 0, which
means the limit for the virtual system is the limit for the firewall model. However, the
limit for a specific seng isn’t replicated for each virtual system. For example, if a firewall
has four virtual systems, each virtual system can’t have the total number of Decrypon
Virtual Systems
Rules allowed per firewall. Aer the total number of Decrypon Rules for all of the
virtual systems reaches the firewall limit, you cannot add more.
• Sessions Limit
If you use the show session meter CLI command, it displays the Maximum
number of sessions allowed per dataplane, the Current number of sessions
being used by the virtual system, and the Throled number of sessions per
virtual system. On a PA-5200 or PA-7000 Series firewall, the Current number
of sessions being used can be greater than the Maximum configured for
Sessions Limit because there are mulple dataplanes per virtual system. The
Sessions Limit you configure on a PA-5200 Series or PA-7000 Series firewall
is per dataplane, and will result in a higher maximum per virtual system.
• Security Rules
• NAT Rules
• Decrypon Rules
• QoS Rules
• Applicaon Override Rules
• Policy Based Forwarding Rules
• Authencaon Rules
• DoS Protecon Rules
• Site to Site VPN Tunnels
• Concurrent SSL VPN Tunnels
2. Click OK.
Virtual Systems
STEP 5 | (Oponal) Configure a virtual system as a User-ID hub to Share User-ID Mappings Across
Virtual Systems.
IP-address-and-port-to-username mapping informaon from Terminal Server agents

and group mapping data is not shared between the virtual system hub and the
connected virtual systems.
1. For any exisng virtual systems, transfer the configuraon for the User-ID sources you
want to share (such as monitored servers and User-ID agents) to the virtual system you
will use as a hub.
2. On the Resource tab, select Make this vsys a User-ID data hub.
3. Click Yes to confirm, then click OK.

If you want to change the User-ID hub to a different virtual system or disable it, select
the virtual system currently configured as a User-ID hub, then select Resource > Change
Hub.
Virtual Systems
Select the New User-ID hub from the list, or select none to disable the User-ID hub and
stop sharing mappings across virtual systems.
Click Proceed to confirm and commit your changes.

Click Commit. The virtual system is now an object accessible from the Objects tab.
Virtual Systems
STEP 7 | Create at least one virtual router for the virtual system in order to make the virtual system
capable of networking funcons, such as stac and dynamic roung.
Alternavely, your virtual system might use a VLAN or a virtual wire, depending on your
deployment.
1. Select Network > Virtual Routers and Add a virtual router by Name.
2. For Interfaces, click Add and select the interfaces that belong to the virtual router.
3. Click OK.
STEP 8 | Configure a security zone for each interface in the virtual system.
For at least one interface, create a Layer 3 security zone. See Configure Interfaces and Zones.
STEP 9 | Configure the security policy rules that allow or deny traffic to and from the zones in the
virtual system.
See Create a Security Policy Rule.

Click Commit.
Aer creang a virtual system, you can use the CLI to commit a configuraon for only a
specific virtual system:
commit partial vsys <vsys-id>
STEP 11 | (Oponal) View the security policies configured for a virtual system.
Open an SSH session to use the CLI. To view the security policies for a virtual system, in
operaonal mode, use the following commands:
set system setting target-vsys <vsys-id>
show running security-policy
Virtual Systems
Configure Inter-Virtual System Communicaon within

the Firewall
Perform this task if you have a use case, perhaps within a single enterprise, where you want the
virtual systems to be able to communicate with each other within the firewall. Such a scenario is
described in Inter-VSYS Traffic That Remains Within the Firewall. This task presumes:
• You completed the task, Configure Virtual Systems.
• When configuring the virtual systems, in the Visible Virtual System field, you checked the
boxes of all virtual systems that must communicate with each other to be visible to each other.
STEP 1 | Configure an external zone for each virtual system.
1. Select Network > Zones and Add a new zone by Name.
2. For Locaon, select the virtual system for which you are creang an external zone.
3. For Type, select External.
4. For Virtual Systems, click Add and enter the virtual system that the external zone can
reach.
5. (Oponal) Select a Zone Protecon Profile (or configure one later) that provides flood,
reconnaissance, or packet-based aack protecon.
6. (Oponal) In Log Seng, select a log forwarding profile for forwarding zone protecon
logs to an external system.
7. (Oponal) Select Enable User Idenficaon to enable User-ID for the external zone.
8. Click OK.
STEP 2 | Configure the Security policy rules to allow or deny traffic from the internal zones to the
external zone of the virtual system, and vice versa.
• See Create a Security Policy Rule.
• See Inter-VSYS Traffic That Remains Within the Firewall.

Click Commit.
Virtual Systems
Configure a Shared Gateway

Perform this task if you need mulple virtual systems to share an interface (a Shared Gateway) to
the Internet. This task presumes:
• You configured an interface with a globally-routable IP address, which will be the shared
gateway.
• You completed the prior task, Configure Virtual Systems. For the interface, you chose the
external-facing interface with the globally-routable IP address.
• When configuring the virtual systems, in the Visible Virtual System field, you checked the
boxes of all virtual systems that must communicate to be visible to each other.
STEP 1 | Configure a Shared Gateway.
1. Select Device > Shared Gateway, click Add and enter an ID.
2. Enter a helpful Name, preferably including the ID of the gateway.
3. In the DNS Proxy field, select a DNS proxy object if you want to apply DNS proxy rules
to the interface.
4. Add an Interface that connects to the outside world.
5. Click OK.
STEP 2 | Configure the zone for the shared gateway.
When adding objects such as zones or interfaces to a shared gateway, the shared
gateway itself will be listed as an available vsys in the VSYS menu.
1. Select Network > Zones and Add a new zone by Name.

2. For Locaon, select the shared gateway for which you are creang a zone.
3. For Type, select Layer3.
4. (Oponal) Select a Zone Protecon Profile (or configure one later) that provides flood,
reconnaissance, or packet-based aack protecon.
5. (Oponal) In Log Seng, select a log forwarding profile for forwarding zone protecon
logs to an external system.
6. (Oponal) Select Enable User Idenficaon to enable User-ID for the shared gateway.
7. Click OK.

Click Commit.
Virtual Systems
Customize Service Routes for a Virtual System

When a firewall is enabled for mulple virtual systems, the virtual systems inherit the global
service and service route sengs. For example, the firewall can use a shared email server to
originate email alerts to all virtual systems. In some scenarios, you’d want to create different
service routes for each virtual system.
One use case for configuring service routes at the virtual system level is if you are an ISP who
needs to support mulple individual tenants on a single Palo Alto Networks firewall. Each tenant
requires custom service routes to access service such as DNS, Kerberos, LDAP, NetFlow, RADIUS,
TACACS+, Mul-Factor Authencaon, email, SNMP trap, syslog, HTTP, User-ID Agent, VM
Monitor, and Panorama (deployment of content and soware updates). Another use case is an
IT organizaon that wants to provide full autonomy to groups that set servers for services. Each
group can have a virtual system and define its own service routes.
You can select a virtual router for a service route in a virtual system; you cannot select
the egress interface. Aer you select the virtual router and the firewall sends the packet
from the virtual router, the firewall selects the egress interface based on the desnaon
IP address. Therefore, if a virtual system has mulple virtual routers, packets to all of the
servers for a service must egress out of only one virtual router. A packet with an interface
source address may egress a different interface, but the return traffic would be on the
interface that has the source IP address, creang asymmetric traffic.
• Customize Service Routes to Services for Virtual Systems

• Configure a PA-7000 Series Firewall for Logging Per Virtual System
• Configure Administrave Access Per Virtual System or Firewall
Customize Service Routes to Services for Virtual Systems

When you enable Mul Virtual System Capability, any virtual system that does not have specific
service routes configured inherits the global service and service route sengs for the firewall. You
can instead configure a virtual system to use a different service route, as described in the following
workflow.
A firewall with mulple virtual systems must have interfaces and subinterfaces with non-
overlapping IP addresses. A per-virtual system service route for SNMP traps or for Kerberos is for
IPv4 only.
The service route for a service strictly follows how you configured the server profile for the
service:
• If you define a server profile (Device > Server Profiles) for the Shared locaon, the firewall uses
the global service route for that service.
• If you define a server profile for a specific virtual system, the firewall uses the virtual system-
specific service route for that service.
• If you define a server profile for a specific virtual system but the virtual system-specific service
route for that service is not configured, the firewall uses the global service route for that
service.
Virtual Systems
The firewall supports syslog forwarding on a virtual system basis. When mulple virtual
systems on a firewall are connecng to a syslog server using SSL transport, the firewall can
generate only one cerficate for secure communicaon. The firewall does not support each
virtual system having its own cerficate.
STEP 1 | Customize service routes for a virtual system.

1. Select Device > Setup > Services > Virtual Systems, and select the virtual system you
want to configure.
2. Click the Service Route Configuraon link.
3. Select one:
• Inherit Global Service Route Configuraon—Causes the virtual system to inherit the
global service route sengs relevant to a virtual system. If you choose this opon,
skip the step to customize.
• Customize—Allows you to specify a source address for each service.
4. If you chose Customize, select the IPv4 or IPv6 tab, depending on what type of
addressing the server offering the service uses. You can specify both IPv4 and IPv6
addresses for a service. Click on a service. (Only services that are relevant to a virtual
system are available.)
To easily use the same source address for mulple services, select the checkbox
for the services, click Set Selected Routes, and connue.
• To limit the list for Source Address, select a Source Interface, then select a Source
Address (from that interface) as the service route. Selecng Any Source Interface
makes all IP addresses on all interfaces for the virtual system available in the Source
Address list from which you select an address. You can select Inherit Global Seng.
• Source Address will indicate Inherited if you selected Inherit Global Seng for the
Source Interface or it will indicate the source address you selected. If you selected
Any for Source Interface, select an IP address or enter an IP address (using the IPv4 or
IPv6 format that matches the tab you chose) to specify the source address that will be
used in packets sent to the external service.
• If you modify an address object and the IP family type (IPv4/IPv6) changes, a Commit
is required to update the service route family to use.
5. Click OK.
6. Repeat the prior steps to configure source addresses for other external services.
7. Click OK.

Click Commit and OK.
If you are configuring per-virtual system service routes for logging services for a PA-7000
Series firewall, connue to the task Configure a PA-7000 Series Firewall for Logging Per Virtual
System.
Virtual Systems
Configure a PA-7000 Series Firewall for Logging Per Virtual System

For Traffic, HIP Match, Threat, and WildFire log types, the PA-7000 Series firewall does not use
service routes for SNMP Trap, Syslog, and email services. Instead, the PA-7000 Series firewall
supports using a logging card.
Depending on your firewall configuraon, you might have one of the following card types:
• Log Processing Card (LPC)—Supports virtual system-specific paths from LPC subinterfaces to
an on-premise switch to the respecve service on a server. For System and Config logs, the
PA-7000 Series firewall uses global service routes, and not the LPC. If your firewall has an LPC
installed, you need to configure a log card port.
• Log Forwarding Card (LFC)—Supports high-speed log forwarding of all dataplane logs to an
external log collector (for example, Panorama and syslog servers). If your firewall has an LFC
installed, you do not need to configure a log card port.
Log forwarding to an external server is not yet supported on LFC subinterfaces.
In other Palo Alto Networks models, the dataplane sends logging service route traffic to the
management plane, which sends the traffic to logging servers. In a PA-7000 Series firewall, the
LPC or LFC have only one interface, and dataplanes for mulple virtual systems send logging
server traffic (types menoned above) to the PA-7000 Series firewall logging card. The logging
card is configured with mulple subinterfaces, over which the plaorm sends the logging service
traffic out to a customer’s switch, which can be connected to mulple logging servers.
Each subinterface can be configured with a subinterface name and a doed subinterface number.
The subinterface is assigned to a virtual system, which is configured for logging services. The other
service routes on a PA-7000 Series firewall funcon similarly to service routes on other Palo Alto
Networks plaorms. For informaon about the LPC or LFC, see the PA-7000 Series Hardware
Reference Guide.
• Configure a PA-7000 Series LPC for Logging per Virtual System
• Configure a PA-7000 Series LFC for Logging per Virtual System
Configure a PA-7000 Series LPC for Logging per Virtual System

If you have enabled mul-vsys capability on a PA-7000 Series firewall with a Log Processing Card
(LPC) installed, you can configure logging for different virtual systems as described in the following
workflow.
STEP 1 | Create a Log Card subinterface.
1. Select Network > Interfaces > Ethernet and select the interface to be the Log Card
interface.
2. Enter the Interface Name.
3. For Interface Type, select Log Card.
4. Click OK.
Virtual Systems
STEP 2 | Add a subinterface for each tenant on the LPCs physical interface.
1. Highlight the Ethernet interface that is a Log Card interface type and click Add
Subinterface.
2. For Interface Name, aer the period, enter the subinterface assigned to the tenant’s
virtual system.
3. For Tag, enter a VLAN tag value.
Make the tag the same as the subinterface number for ease of use, but it could
be a different number.
4. (Oponal) Enter a Comment.
5. On the Config tab, in the Assign Interface to Virtual System field, select the virtual
system to which the LPC subinterface is assigned. Alternavely, you can click Virtual
Systems to add a new virtual system.
6. Click OK.
STEP 3 | Enter the addresses assigned to the subinterface, and configure the default gateway.
1. Select the Log Card Forwarding tab, and do one or both of the following:
• For the IPv4 secon, enter the IP Address and Netmask assigned to the subinterface.
Enter the Default Gateway (the next hop where packets will be sent that have no
known next hop address in the Roung Informaon Base [RIB]).
• For the IPv6 secon, enter the IPv6 Address assigned to the subinterface. Enter the
IPv6 Default Gateway.
2. Click OK.

STEP 5 | If you haven’t already done so, configure the remaining service routes for the virtual system.
Customize Service Routes for a Virtual System.
Configure a PA-7000 Series LFC for Logging per Virtual System

If you have enabled mulple virtual system (mul-vsys) capability on a PA-7000 Series firewall
with a Log Forwarding Card (LFC) installed, you can configure logging for different virtual systems.
The LFC can then forward logs to a Panorama Log Collector or syslog server.
You can choose to configure only the physical interface. Because syslog forwarding via
subinterfaces is not yet supported on LFCs, each virtual system uses the single untagged
physical interface.
If you configure an LFC subinterface to forward logs externally, the interfaces will no longer
work as expected.
To configure a separate subinterface for each virtual system, add subinterfaces to the physical
interface and assign the necessary tag to segment the subinterface traffic.
Virtual Systems
For a PA-7000 Series firewall managed by a Panorama management server, you cannot
override or revert the LFC configuraon locally on the firewall if the LFC configuraon is
pushed from Panorama. To override the LFC configuraon pushed from Panorama, you
must log in to the firewall CLI and delete the Panorama pushed configuraon.
admin> configure
admin# delete deviceconfig log-fwd-card
admin# commit
Configure Administrave Access Per Virtual System or Firewall

If you have a superuser administrave account, you can create and configure granular permissions
for a vsysadmin or device admin role.
STEP 1 | Create an Admin Role Profile that grants or disables permission to an Administrator to
configure or read-only various areas of the web interface.
1. Select Device > Admin Roles and Add an Admin Role Profile.
2. Enter a Name and oponal Descripon of the profile.
3. For Role, specify which level of control the profile affects:
• Device—The profile allows the management of the global sengs and any virtual
systems.
• Virtual System—The profile allows the management of only the virtual system(s)
assigned to the administrator(s) who have this profile. (The administrator will be able
to access Device > Setup > Services > Virtual Systems, but not the Global tab.)
4. On the Web UI tab for the Admin Role Profile, scroll down to Device, and leave the
green check mark (Enable).
• Under Device, enable Setup. Under Setup, enable the areas to which this profile
will grant configuraon permission to the administrator, as shown below. (The Read
Only lock icon appears in the Enable/Disable rotaon if Read Only is allowed for that
seng.)
• Management—Allows an admin with this profile to configure sengs on the
Management tab.
• Operaons—Allows an admin with this profile to configure sengs on the
Operaons tab.
• Services—Allows an admin with this profile to configure sengs on the Services
tab. An admin must have Services enabled in order to access the Device > Setup
Virtual Systems
Services > Virtual Systems tab. If the Role was specified as Virtual System in the
prior step, Services is the only seng that can be enabled under Device > Setup.
• Content-ID—Allows an admin with this profile to configure sengs on the
Content-ID tab.
• WildFire—Allows an admin with this profile to configure sengs on the WildFire
tab.
• Session—Allows an admin with this profile to configure sengs on the Session tab.
• HSM—Allows an admin with this profile to configure sengs on the HSM tab.
5. Click OK.
6. (Oponal) Repeat the enre step to create another Admin Role profile with different
permissions, as necessary.
STEP 2 | Apply the Admin role profile to an administrator.

1. Select Device > Administrators, click Add and enter the Name to add an Administrator.
2. (Oponal) Select an Authencaon Profile.
3. (Oponal) Select Use only client cerficate authencaon (Web) to have bi-direconal
authencaon; to get the server to authencate the client.
4. Enter a Password and Confirm Password.
5. (Oponal) Select Use Public Key Authencaon (SSH) if you want to use a much
stronger, key-based authencaon method using an SSH public key rather than just a
password.
6. For Administrator Type, select Role Based.
7. For Profile, select the profile that you just created.
8. (Oponal) Select a Password Profile.
9. Click OK.

Click Commit.
Virtual Systems
Virtual System Funconality with Other Features

Many firewall features and funconality are capable of being configured, viewed, logged, or
reported per virtual system. Therefore, virtual systems are menoned in other relevant locaons
in the documentaon and that informaon is not repeated here. Some of the specific chapters are
the following:
• If you are configuring Acve/Passive HA, the two firewalls must have the same virtual system
capability (single or mulple virtual system capability). See High Availability.
• To configure QoS for virtual systems, see Configure QoS for a Virtual System.
• For informaon about configuring a firewall with virtual systems in a virtual wire deployment
that uses subinterfaces (and VLAN tags), see Virtual Wire Interfaces.
• If you have configured User-ID and mulple virtual systems, you can share user mappings
across virtual systems. See Share User-ID Mappings Across Virtual Systems.
Zone Protecon and DoS Protecon
Segmenng the network into funconal and organizaonal zones reduces the
network’s aack surface—the poron of the network exposed to potenal aackers.
Zone protecon defends network zones against flood aacks, reconnaissance
aempts, packet-based aacks, and aacks that use non-IP protocols. Tailor a Zone
Protecon profile to protect each zone (you can apply the same profile to similar
zones). Denial-of-service (DoS) protecon defends specific crical systems against
flood aacks, especially devices that user access from the internet such as web
servers and database servers, and protects resources from session floods. Tailor DoS
Protecon profiles and policy rules to protect each set of crical devices. Visit the
Best Pracces documentaon portal to get a checklist of Zone Protecon and DoS
Protecon best pracces.
Check and monitor firewall dataplane CPU consumpon to ensure that each firewall is properly
sized to support DoS and Zone Protecon along with any other features that consume CPU cycles,
such as decrypon. If you use Panorama to manage your firewalls, use Device Monitor (Panorama >
Managed Devices > Health) to check and monitor the CPU consumpon of all managed firewalls at
one me.
> Network Segmentaon Using Zones

> How Do Zones Protect the Network?
> Zone Defense
> Configure Zone Protecon to Increase Network Security
> DoS Protecon Against Flooding of New Sessions
1449
Zone Protecon and DoS Protecon
Network Segmentaon Using Zones

The larger the network, the more difficult it is to protect. A large, unsegmented network presents
a large aack surface that can be difficult to manage and protect. Because traffic and applicaons
have access to the enre network, once an aacker gains entry to a network, the aacker can
move laterally through the network to access crical data. A large network is also more difficult
to monitor and control. Segmenng the network limits an aacker’s ability to move through the
network by prevenng lateral movement between zones.
A security zone is a group of one or more physical or virtual firewall interfaces and the network
segments connected to the zone’s interfaces. You control protecon for each zone individually
so that each zone receives the specific protecons it needs. For example, a zone for the finance
department may not need to allow all of the applicaons that a zone for IT allows.
To fully protect your network, all traffic must flow through the firewall. Configure Interfaces
and Zones to create separate zones for different funconal areas such as the internet gateway,
sensive data storage, and business applicaons, and for different organizaonal groups such
as finance, IT, markeng, and engineering. Wherever there is a logical division of funconality,
applicaon usage, or user access privileges, you can create a separate zone to isolate and protect
the area and apply the appropriate security policy rules to prevent unnecessary access to data
and applicaons that only one or some groups need to access. The more granular the zones, the
greater the visibility and control you have over network traffic. Dividing your network into zones
helps to create a Zero Trust architecture that executes a security philosophy of trusng no users,
devices, applicaons, or packets, and verifying everything. The end goal is to create a network that
allows access only to the users, devices, and applicaons that have legimate business needs, and
to deny all other traffic.
How to appropriately restrict and permit access to zones depends on the network environment.
For example, environments such as semiconductor manufacturing floors or roboc assembly
plants, where the workstaons control sensive manufacturing equipment, or highly restricted
access areas, may require physical segmentaon that permits no access from outside devices (no
mobile device access).
In environments where users can access the network with mobile devices, enabling User-ID
and App-ID in conjuncon with segmenng the network into zones ensures that users receive
the appropriate access privileges regardless of where they access the network, because access
privileges are ed to a user or a user group instead of to a device in one parcular zone.
The protecon requirements for different funconal areas and groups may also differ. For
example, a zone that handles a large amount of traffic may require different flood protecon
thresholds than a zone that normally handles less traffic. The ability to define the appropriate
protecon for each zone is another reason to segment the network. What appropriate protecon
is depends on your network architecture, what you want to protect, and what traffic you want to
permit and deny.
How Do Zones Protect the Network?

Zones not only protect your network by segmenng it into smaller, more easily managed areas,
zones also protect the network because you can control access to zones and traffic movement
between zones.
Zones prevent uncontrolled traffic from flowing through the firewall interfaces into your network
because firewall interfaces can’t process traffic unl you assign them to zones. The firewall applies
zone protecon on ingress interfaces, where traffic enters the firewall in the direcon of flow from
the originang client to the responding server (c2s), to filter traffic before it enters a zone.
The firewall interface type and the zone type (Tap, virtual wire, L2, L3, Tunnel, or External) must
match, which helps to protect the network against adming traffic that doesn’t belong in a zone.
For example, you can assign an L2 interface to an L2 zone or an L3 interface to an L3 zone, but
you can’t assign an L2 interface to an L3 zone.
In addion, a firewall interface can belong to one zone only. Traffic desned for different zones
can’t use the same interface, which helps to prevent inappropriate traffic from entering a zone
and enables you to configure the protecon appropriate for each individual zone. You can connect
more than one firewall interface to a zone to increase bandwidth, but each interface can connect
to only one zone.
Aer the firewall admits traffic to a zone, traffic flows freely within that zone and is not logged.
The more granular you make each zone, the greater the control you have over the traffic that
accesses each zone, and the more difficult it is for malware to move laterally across the network
between zones. Traffic can’t flow between zones unless a security policy rule allows it and the
zones are of the same zone type (Tap, virtual wire, L2, L3, Tunnel, or External). For example, a
security policy rule can allow traffic between two L3 zones, but not between an L3 zone and an
L2 zone. The firewall logs traffic that flows between zones when a security policy rule permits
interzone traffic.
By default, security policy rules prevent lateral movement of traffic between zones, so malware
can’t gain access to one zone and then move freely through the network to other targets.
Tunnel zones are for non-encrypted tunnels. You can apply different security policy rules
to the tunnel content and to the zone of the outer tunnel, as described in the Tunnel
Content Inspecon Overview.
Zone Defense
Zone Protecon profiles defend zones against flood, reconnaissance, packet-based, and non-
IP-protocol-based aacks. DoS Protecon profiles used in DoS Protecon policy rules defend
specific, crical devices against targeted flood and resource-based aacks. A DoS aack overloads
the network or targeted crical systems with large amounts of unwanted traffic an aempt to
disrupt network services.
Plan to defend your network against different types of DoS aacks:
• Applicaon-Based Aacks—Target weaknesses in a parcular applicaon and try to exhaust its
resources so legimate users can’t use it. An example of this is the Slowloris aack.
• Protocol-Based Aacks—Also known as state-exhauson aacks, these aacks target protocol
weaknesses. A common example is a SYN flood aack.
• Volumetric Aacks—High-volume aacks that aempt to overwhelm the available network
resources, especially bandwidth, and bring down the target to prevent legimate users from
accessing those resources. An example of this is a UDP flood aack.
There are no default Zone Protecon profiles or DoS Protecon profiles and DoS Protecon
policy rules. Configure and apply zone protecon based on each zone’s traffic characteriscs and
configure DoS protecon based on the individual crical systems you want to protect in each
zone.
• Zone Defense Tools
• How Do the Zone Defense Tools Work?
• Firewall Placement for DoS Protecon
• Zone Protecon Profiles
• Packet Buffer Protecon
• DoS Protecon Profiles and Policy Rules
Zone Defense Tools

Effecve defense against DoS aacks requires a layered approach. The first layer of defense
should be a dedicated, high-volume DDoS protecon device at the internet-facing network
perimeter and a perimeter router, switch, or other hardware-based packet drop device with
appropriate access control lists (ACLs) to defend against volumetric aacks that the session-based
firewall isn’t designed to handle. The firewall adds more granular layers of DoS aack defense and
also visibility into applicaon traffic that dedicated DDoS devices don’t provide.
Palo Alto Networks firewalls provide four complementary tools to layer in DoS protecon for your
network zones and crical devices:
• Zone Protecon profiles defend the ingress zone edge against IP flood aacks, reconnaissance
port scans and host sweeps, IP packet-based aacks, and non-IP protocol aacks. The ingress
zone is where traffic enters the firewall in the direcon of flow from the client to the server
(c2s), where the client is the originator of the flow and the server is the responder. Zone
Protecon profiles provide a second layer of broad defense against DoS aacks, based on the
aggregate traffic entering the zone, by liming the new connecons-per-second (CPS) to the
zone. Zone Protecon profiles don’t take individual devices (IP addresses) into account because
the profiles apply to the aggregate traffic entering the zone.
Zone protecon profiles defend the network as a session is formed, before the firewall
performs DoS Protecon policy and Security policy rule lookups, and consume fewer CPU
cycles than a DoS Protecon policy or Security policy rule lookup. If a Zone Protecon profile
denies traffic, the firewall doesn’t spend CPU cycles on policy rule lookups.
Apply Zone Protecon profiles to every zone, both internet-facing and internal.
• DoS Protecon profiles and policy rules defend specific individual endpoints and resources
against flood aacks, especially high-value targets that users access from the internet. While
a Zone Protecon profile defends the zone from flood aacks, a DoS Protecon policy rule
with an appropriate DoS Protecon profile defends crical individual systems in a zone from
targeted flood aacks, providing a granular third layer of defense against DoS aacks.
Because the intent of DoS protecon is to defend crical devices and because it
consumes resources, DoS protecon defends only the devices you specify in a DoS
Protecon policy rule. No other devices are protected.
DoS Protecon profiles set flood protecon thresholds (new CPS limits) for individual devices
or groups of devices, resource protecon thresholds (session limits for specified endpoints and
resources), and whether the profile applies to aggregate or classified traffic. DoS Protecon
policy rules specify match criteria (source, desnaon, service ports), the acon to take when
traffic matches the rule, and the aggregate and classified DoS Protecon profiles associated
with each rule.
Aggregate DoS Protecon policy rules apply the CPS thresholds defined in an aggregate DoS
Protecon profile to the combined traffic of all the devices that meet the DoS Protecon
policy rule match criteria. For example, if you configure the aggregate DoS Protecon profile
to limit the CPS rate to 20,000, the 20,000 CPS limit applies to the aggregate number of
connecons for the enre group. In this case, one device could receive the majority of the
allowed connecons.
Classified DoS Protecon policy rules apply the CPS thresholds defined in a classified DoS
Protecon profile to each individual device that matches the policy rule. For example, if you
configure the classified DoS Protecon profile to limit the CPS rate to 4,000, then no device in
the group can accept more than 4,000 CPS. A DoS Protecon policy can have one aggregate
profile and one classified profile.
Classified profiles can classify connecons by source IP, desnaon IP, or both. For
internet-facing zones, classify by desnaon IP only because the firewall can’t scale to
hold the internet roung table.
Apply DoS Protecon only to crical devices, especially popular aack targets that users access
from the internet, such as web servers and database servers.
• For exisng sessions, Packet Buffer Protecon protects the firewall (and therefore the zone)
against single-session DoS aacks that aempt to overwhelm the firewall’s packet buffer, using
thresholds and mers to migate abusive sessions. You configure Packet Buffer Protecon
sengs globally and apply them per zone.
• Security Policy rules affect both the ingress and egress flows of a session. To establish a
session, incoming traffic must match an exisng Security policy rule. If there is no match, the
firewall discards the packet. A Security policy allows or denies traffic between zones (interzone)
and within zones (intrazone) using criteria including zones, IP addresses, users, applicaons,
services, and URL categories.
Apply the best pracce Vulnerability Protecon profile to each Security policy rule to
help defend against DoS aacks.
The default Security policy rules don’t permit traffic to travel between zones, so you need to
configure a Security policy rule if you want to allow interzone traffic. All intrazone traffic is
allowed by default. You can configure Security policy rules to match and control intrazone,
interzone, or universal (intrazone and interzone) traffic.
Zone Protecon profiles, DoS Protecon profiles and policy rules, and Security policy
rules only affect dataplane traffic on the firewall. Traffic originang on the firewall
management interface does not cross the dataplane, so the firewall does not match
management traffic against these profiles or policy rules.
• You can also search the Palo Alto Networks Threat Vault (requires a valid support account and
login) for threats by hash, CVE, signature ID, domain name, URL, or IP address.
How Do the Zone Defense Tools Work?

When a packet arrives at the firewall, the firewall aempts to match the packet to an exisng
session, based on the ingress zone, egress zone, source IP address, desnaon IP address,
protocol, and applicaon derived from the packet header. If the firewall finds a match, then the
packet uses the Security policy rules that already control the session. If the packet doesn’t match
an exisng session, the firewall uses Zone Protecon profiles, DoS Protecon profiles and policy
rules, and Security policy rules to determine whether to establish a session or discard the packet,
and the level of access the packet receives.
Aer traffic passes through your dedicated DDoS device at the internet-facing network edge,
the first protecon the firewall applies is the broad defense of the Zone Protecon profile, if
one is aached to the zone. The firewall determines the zone from the interface on which the
packet arrives (each interface is assigned to only one zone and all interfaces that carry traffic
must belong to a zone). If the Zone Protecon profile denies the packet, the firewall discards the
packet and saves resources by not needing to look up the DoS Protecon policy or Security policy.
The firewall applies Zone Protecon profiles only to new sessions (packets that do not match an
exisng session). Aer the firewall establishes a session, the firewall bypasses the Zone Protecon
profile lookup for succeeding packets in that session.
If the Zone Protecon profile doesn’t drop the packet, the second protecon the firewall applies
is a DoS Protecon policy rule. If a Zone Protecon profile allows a packet based on the total
aggregate amount of traffic going to the zone, a DoS Protecon policy rule may deny the packet
if it is going to a parcular desnaon or coming from a parcular source that has exceeded the
flood protecon or resource protecon sengs in the rule’s DoS Protecon profile. If the packet
matches a DoS Protecon policy rule, the firewall applies the rule to the packet. If the rule denies
access, the firewall discards the packet and doesn’t perform a Security policy lookup. If the rule
allows access, the firewall performs a Security policy lookup. Like the Zone Protecon profile, the
firewall enforces DoS Protecon policy only on new sessions.
The third protecon the firewall applies is a Security policy lookup, which happens only if the
Zone Protecon profile and DoS Protecon policy rules allow the packet. If the firewall finds no
Security policy rule match for the packet, the firewall discards the packet. If the firewall finds a
matching Security policy rule, the firewall applies the rule to the packet. The firewall enforces the
Security policy rule on traffic in both direcons (c2s and s2c) for the life of the session. Apply the
best pracce Vulnerability Protecon profile to all Security policy rules to help defend against DoS
aacks.
The fourth protecon the firewall applies is packet buffer protecon, which you apply globally
to protect the device and can also apply individually to zones to prevent single-session DoS
aacks that aempt to overwhelm the firewall’s packet buffer. For global protecon, the firewall
used Random Early Drop (RED) to drop packets (not sessions) when the level of traffic crosses
protecon thresholds. For per-zone protecon, the firewall blocks the source IP address if it
violates the packet buffer thresholds. Unlike zone and DoS protecon, packet buffer protecon
applies to exisng sessions.
Firewall Placement for DoS Protecon

The firewall is a session-based device that isn’t designed to scale to millions of connecons-per-
second (CPS) to defend against large volumetric DoS aacks. The firewall treats each unique
flow (based on ingress and egress zone, source and desnaon IP, protocol, and applicaon) as a
session, spends CPU cycles on packet inspecon at the port and the IP level to provide visibility
into applicaon traffic, and must count each session for the flood threshold counters, so firewall
placement is crical to avoid flooding the firewall.
For the best DoS protecon, place firewalls as close to the resources you’re protecng as possible. This
reduces the number of sessions the firewall needs to handle and therefore the amount of firewall
resources required to provide DoS protecon.
At the internet-facing perimeter, do not place firewalls you use for DoS protecon or zone
protecon in front of dedicated DDoS devices and perimeter routers and switches. Make those
high-volume devices your first line of DoS defense to migate volumetric flood aacks. For zone
and DoS protecon at the perimeter, use high-capacity firewalls and place them behind the high-
volume devices. As a rule, the closer a firewall is to the perimeter, the higher capacity it must be to
handle the volume of traffic.
The way you segment your network into zones can help migate internal DoS aacks. Smaller
zones provide greater visibility into traffic and prevent lateral movement of malware beer
because more traffic must cross zones, and to allow interzonal traffic requires you to create a
specific Security policy rule (all intrazonal traffic is allowed by default). Consider revising your
segmentaon approach if your network is relavely unsegmented.
Baseline CPS Measurements for Seng Flood Thresholds

Flood protecon thresholds determine the number of new connecons-per-second (CPS) to allow
for a zone (Zone Protecon profile), for a group of devices in a zone (aggregate DoS Protecon
policy), or for individual devices in a zone (classified DoS Protecon policy), when to throle new
connecons to begin migang a potenal flood aack, and when to drop all new connecons.
The default Zone Protecon profile and DoS Protecon profile flood protecon thresholds aren’t
appropriate for most networks because each network is unique. You need to understand the
aggregate normal and peak CPS for each zone to set effecve Zone Protecon profile thresholds,
and for the individual crical systems you want to defend to set effecve DoS Protecon
profile thresholds that don’t inadvertently set thresholds too high and allow flood aacks or set
thresholds too low and throle traffic.
• CPS Measurements to Take

• How to Measure CPS
CPS Measurements to Take

Measure average and peak CPS traffic over the course of at least five business days or unl
you’re confident that the measurements reflect the network’s typical traffic paerns; the longer
measurement period, the more accurate the measurements. Take into account special events,
quarterly events, and annual events that may spike the number of CPS you need to support. You
may need to adjust Zone Protecon profiles and schedule adjusted DoS Protecon policy rules to
accommodate these types of events if your firewalls have the capacity to handle extra traffic. Take
the following baseline measurements:
• For Zone Protecon profiles, measure the average and peak CPS ingressing each zone.
• For aggregate DoS Protecon profiles, measure the combined average and peak CPS for each
group of devices you want to protect.
• For classified DoS Protecon profiles, measure the average and peak CPS of the individual
devices you want to protect.
Also understand the capacity of your firewalls and how other resource-consuming features such
as decrypon affect the number of connecons each firewall can control. As a general rule, the
closer a firewall is to the perimeter, the greater its capacity needs to be because it handles more
traffic. The datasheet for each firewall model includes the total new sessions per second (CPS) the
firewall supports and the Firewall Comparison Tool enables you to compare the CPS (and other
metrics) of different firewall models.
How to Measure CPS

There are many ways to measure CPS:
• If you use Panorama to manage your firewalls, use Device Monitoring to measure CPS coming
into a firewall (Panorama > Managed Devices > Health > All Devices). Device Monitoring can
also show you a 90-day trend line of CPU average and peak use to help you understand the
typical available capacity of each firewall.
• Run the operaonal CLI command show session info.
The operaonal CLI command show counter interface displays two mes the
actual CPS value. If you use this command, divide the CPS value by two to derive the
real CPS value.
• For seng appropriate DoS Protecon profile thresholds, work with applicaon teams to
understand the normal and peak CPS to their servers and the maximum CPS those servers can
support.
In addion, you can filter firewall Traffic logs and Threat logs for the desnaon IP addresses of
the crical devices you want to protect to obtain normal and peak session acvity informaon.
• Use third-party tools such as Wireshark or NetFlow to collect and analyze network traffic.
• Use scripts to automate CPS informaon collecon and connuous monitoring, and to mine
informaon from the logs.
• Configure every Security policy rule on the firewall to Log at Session End. If you have no
monitoring tools such as NetFlow or Wireshark, and cannot obtain or develop automated
scripts, Log at Session End captures the number of connecons at the session end. While
this doesn’t provide CPS informaon, it does show you the number of sessions ending in the
selected me duraon and you can make an approximate calculaon of the sessions per second
from that informaon.
To conserve resources, the firewall measures the aggregate CPS at ten-second intervals.
For this reason, measurements you see on the firewall may not catch bursts within the ten-
second interval. Although the average CPS measurements aren’t affected, the peak CPS
measurements may not be precise. For example, if the firewall logs report a 5,000 CPS
average in a ten-second interval, it’s possible that 4,000 CPS came in a one-second burst
and the other 1,000 CPS were spread out over the remaining nine seconds.
To gather historical CPS data over me, if you use an SNMP server, you can use your own
management tools to poll SNMP MIBs. However, it is important to understand that the CPS
measurements in the MIBs show twice the actual CPS value (for example, if the true CPS
measurement is 10,000, the MIBs show 20,000 as the value). You can sll see trends from the
MIBs and you can divide the CPS values by two to derive the true values. The SNMP MIB OIDs
are: PanZoneAcveTcpCps, PanZoneAcveUdpCps, and PanZoneOtherIpCps. Because the firewall
only takes measurements and updates the SNMP server every 10 seconds, poll every 10 seconds.
In addion, create separate log forwarding profiles for flood events so the appropriate
administrator receives emails that contain only flood (potenal DoS aack) events. Set Log
Forwarding for both zone protecon and DoS protecon threshold events.
Aer you implement Zone and DoS protecon, use these methods to monitor the
deployment, so as your network evolves and traffic paerns change, you adjust flood
protecon thresholds.
Zone Protecon Profiles

Apply a Zone Protecon profile to each zone to defend it based on the aggregate traffic entering
the ingress zone.
In addion to configuring zone protecon and DoS protecon, apply the best pracce
Vulnerability Protecon profile to each Security policy rule to help defend against DoS
aacks.
• Flood Protecon
• Reconnaissance Protecon
• Packet-Based Aack Protecon
• Protocol Protecon
• Ethernet SGT Protecon
Flood Protecon
A Zone Protecon profile with flood protecon configured defends an enre ingress zone against
SYN, ICMP, ICMPv6, UDP, and other IP flood aacks. The firewall measures the aggregate amount
of each flood type entering the zone in new connecons-per-second (CPS) and compares the
totals to the thresholds you configure in the Zone Protecon profile. (You protect crical individual
devices within a zone with DoS Protecon profiles and policy rules.)
Measure and monitor firewall dataplane CPU consumpon to ensure that each firewall is
properly sized to support DoS and Zone Protecon and any other features that consume
CPU cycles, such as decrypon. If you use Panorama to manage your firewalls, Device
Monitoring (Panorama > Managed Devices > Health > All Devices) shows you the CPU
and memory consumpon of each managed firewall. It can also show you a 90-day trend
line of CPU average and peak use to help you understand the typical available capacity of
each firewall.
For each flood type, you set three thresholds for new CPS entering the zone, and you can set a
drop Acon for SYN floods. If you know the baseline CPS rates for the zone, use these guidelines
to set the inial thresholds, and then monitor and adjust the thresholds as necessary.
• Alarm Rate—The new CPS threshold to trigger an alarm. Target seng the Alarm Rate to
15-20% above the average CPS rate for the zone so that normal fluctuaons don’t cause alerts.
• Acvate—The new CPS threshold to acvate the flood protecon mechanism and begin
dropping new connecons. For ICMP, ICMPv6, UDP, and other IP floods, the protecon
mechanism is Random Early Drop (RED, also known as Random Early Detecon). For SYN
floods only, you can set the drop Acon to SYN Cookies or RED. Target seng the Acvate
rate to just above the peak CPS rate for the zone to begin migang potenal floods.
• Maximum—The number of connecons-per-second to drop incoming packets when RED is the
protecon mechanism. Target seng the Maximum rate to approximately 80-90% of firewall
capacity, taking into account other features that consume firewall resources.
If you don’t know the baseline CPS rates for the zone, start by seng the Maximum CPS rate
to approximately 80-90% of firewall capacity and use it to derive reasonable flood migaon
alarm and acvaon rates. Set the Alarm Rate and Acvate rate based on the Maximum rate.
For example, you could set the Alarm Rate to half the Maximum rate and adjust it depending on
how many alarms you receive and the firewall resources being consumed. Be careful seng the
Acvate Rate since it begins to drop connecons. Because normal traffic loads experience some
fluctuaon, it’s best not to drop connecons too aggressively. Err on the high side and adjust the
rate if firewall resources are impacted.
SYN Flood Protecon is the only type for which you set the drop Acon. Start by seng
the Acon to SYN Cookies. SYN Cookies treats legimate traffic fairly and only drops
traffic that fails the SYN handshake, while using Random Early Drop drops traffic
randomly, so RED may affect legimate traffic. However, SYN Cookies is more resource-
intensive because the firewall acts as a proxy for the target server and handles the
three-way handshake for the server. The tradeoff is not dropping legimate traffic (SYN
Cookies) versus preserving firewall resources (RED). Monitor the firewall, and if SYN
Cookies consumes too many resources, switch to RED. If you don’t have a dedicated DDoS
prevenon device in front of the firewall, always use RED as the drop mechanism.
When SYN Cookies is acvated, the firewall does not honor the TCP opons that the
server sends because it does not know these values at the me that it proxies the SYN/
ACK. Therefore, values such as the TCP server’s window size and MSS values cannot be
negoated during the TCP handshake and the firewall will use its own default values. In
the scenario where the MSS of the path to the server is smaller than the firewall’s default
MSS value, the packet will need to be fragmented.
The default threshold values are high so that acvang a Zone Protecon profile doesn’t
unexpectedly drop legimate traffic. Adjust the thresholds to values appropriate for your
network’s traffic. The best method for understanding how to set reasonable flood thresholds is
to take baseline measurements of average and peak CPS for each flood type to determine the
normal traffic condions for each zone and to understand the capacity of the firewall, including
the impact of other resource-consuming features such as decrypon. Monitor and adjust the flood
thresholds as needed and as your network evolves.
Firewalls with mulple dataplane processors (DPs) distribute connecons across DPs. In
general, the firewall divides the CPS threshold sengs equally across its DPs. For example,
if a firewall has five DPs and you set the Alarm Rate to 20,000 CPS, each DP has an
Alarm Rate of 4,000 CPS (20,000 / 5 = 4,000), so if the new sessions on a DP exceeds
4,000, it triggers the Alarm Rate threshold for that DP.
Reconnaissance Protecon
Similar to the military definion of reconnaissance, the network security definion of
reconnaissance is when aackers aempt to gain informaon about your network’s vulnerabilies
by secretly probing the network to find weaknesses. Reconnaissance acvies are oen preludes
to a network aack. Enable Reconnaissance Protecon on all zones to defend against port scans and
host sweeps:
• Port scans discover open ports on a network. A port scanning tool sends client requests to a
range of port numbers on a host, with the goal of locang an acve port to exploit in an aack.
Zone Protecon profiles defend against TCP and UDP port scans.
• Host sweeps examine mulple hosts to determine if a specific port is open and vulnerable.
You can use reconnaissance tools for legimate purposes such as pen tesng of network security
or the strength of a firewall. You can specify up to 20 IP addresses or netmask address objects
to exclude from Reconnaissance Protecon so that your internal IT department can conduct pen
tests to find and fix network vulnerabilies.
You can set the acon to take when reconnaissance traffic (excluding pen tesng traffic) exceeds
the configured threshold when you Configure Reconnaissance Protecon. Retain the default
Interval and Threshold to log a few packets for analysis before blocking the reconnaissance
operaon.
Packet-Based Aack Protecon

Packet-based aacks take many forms. Zone Protecon profiles check IP, TCP, ICMP, IPv6, and
ICMPv6 packet headers and protect a zone by:
• Dropping packets with undesirable characteriscs.
• Stripping undesirable opons from packets before adming them to the zone.
Select the drop characteriscs for each packet type when you Configure Packet Based Aack
Protecon. The best pracces for each IP protocol are:
• IP Drop—Drop Unknown and Malformed packets. Also drop Strict Source Roung and Loose
Source Roung because allowing these opons allows adversaries to bypass Security policy
rules that use the Desnaon IP address as the matching criteria. For internal zones only, check
Spoofed IP Address so only traffic with a source address that matches the firewall roung table
can access the zone.
• TCP Drop—Retain the default TCP SYN with Data and TCP SYNACK with Data drops, drop
Mismatched overlapping TCP segment and Split Handshake packets, and strip the TCP
Timestamp from packets.
Enabling Rematch Sessions (Device > Setup > Session > Session Sengs) is a best
pracce that applies commied newly configured or edited Security Policy rules to
exisng sessions. However, if you configure Tunnel Content Inspecon on a zone
and Rematch Sessions is enabled, you must also disable Reject Non-SYN TCP (change
the selecon from Global to No), or else when you enable or edit a Tunnel Content
Inspecon policy, the firewall drops all exisng tunnel sessions. Create a separate Zone
Protecon profile to disable Reject Non-SYN TCP only on zones that have Tunnel
Content Inspecon policies and only when you enable Rematch Sessions.
• ICMP Drop—There are no standard best pracce sengs because dropping ICMP packets
depends on how you use ICMP (or if you use ICMP). For example, if you want to block ping
acvity, you can block ICMP Ping ID 0.
• IPv6 Drop—If compliance maers, ensure that the firewall drops packets with non-compliant
roung headers, extensions, etc.
• ICMPv6 Drop—If compliance maers, ensure that the firewall drops certain packets if the
packets don’t match a Security policy rule.
Protocol Protecon
In a Zone Protecon profile, Protocol Protecon defends against non-IP protocol based aacks.
Enable Protocol Protecon to block or allow non-IP protocols between security zones on a
Layer 2 VLAN or on a virtual wire, or between interfaces within a single zone on a Layer 2 VLAN
(Layer 3 interfaces and zones drop non-IP protocols so non-IP Protocol Protecon doesn’t apply).
Configure Protocol Protecon to reduce security risks and facilitate regulatory compliance by
prevenng less secure protocols from entering a zone, or an interface in a zone.
If you don’t configure a Zone Protecon profile that prevents non-IP protocols in the
same zone from going from one Layer 2 interface to another, the firewall allows the
traffic because of the default intrazone allow Security policy rule. You can create a Zone
Protecon profile that blocks protocols such as LLDP within a zone to prevent discovery
of networks reachable through other zone interfaces.
If you need to discover which non-IP protocols are running on your network, use monitoring
tools such as NetFlow, Wireshark, or other third-party tools discover non-IP protocols on your
network. Examples of non-IP protocols you can block or allow are LLDP, NetBEUI, Spanning Tree,
and Supervisory Control and Data Acquision (SCADA) systems such as Generic Object Oriented
Substaon Event (GOOSE), among many others.
Create an Exclude List or an Include List to configure Protocol Protecon for a zone. The Exclude
List is a block list—the firewall blocks all of the protocols you place in the Exclude List and allows
all other protocols. The Include List is an allow list—the firewall allows only the protocols you
specify in the list and blocks all other protocols.
Use include lists for Protocol Protecon instead of exclude lists. Include lists specifically
sancon only the protocols you want to allow and block the protocols you don’t need or
didn’t know were on your network, which reduces the aack surface and blocks unknown
traffic.
A list supports up to 64 Ethertype entries, each idenfied by its IEEE hexadecimal Ethertype code.
Other sources of Ethertype codes are standards.ieee.org/develop/regauth/ethertype/eth.txt
and hp://www.cavebear.com/archive/cavebear/Ethernet/type.html. When you configure zone
protecon for non-IP protocols on zones that have Aggregated Ethernet (AE) interfaces, you can’t
block or allow a non-IP protocol on only one AE interface member because AE interface members
are treated as a group.
Protocol Protecon doesn’t allow blocking IPv4 (Ethertype 0x0800), IPv6 (0x86DD), ARP
(0x0806), or VLAN-tagged frames (0x8100). The firewall always implicitly allows these
four Ethertypes in an Include List even if you don’t explicitly list them and doesn’t permit
you to add them to an Exclude List.
Ethernet SGT Protecon

In a Cisco TrustSec network, a Cisco Identy Services Engine (ISE) assigns a Layer 2 Security
Group Tag (SGT) of 16 bits to a user’s or endpoint’s session. You can create a Zone Protecon
profile with Ethernet SGT protecon when your firewall is part of a Cisco TrustSec network.
The firewall can inspect headers with 802.1Q (Ethertype 0x8909) for specific Layer 2 security
group tag (SGT) values and drop the packet if the SGT matches the list you configure for the Zone
Protecon profile aached to the interface. Determine which SGT values you want to deny access
to a zone.
Packet Buffer Protecon

Packet Buffer Protecon defends your firewall and network from single session DoS aacks that
can overwhelm the firewall’s packet buffer and cause legimate traffic to drop. Although you
don’t configure Packet Buffer Protecon in a Zone Protecon profile or in a DoS Protecon profile
or policy rule, Packet Buffer Protecon defends ingress zones. While zone and DoS protecon
apply to new sessions (connecons) and are granular, Packet Buffer Protecon applies to exisng
sessions and is global.
You Configure Packet Buffer Protecon globally to protect the enre firewall and you also enable
Packet Buffer Protecon on each zone to protect zones:
• Global Packet Buffer Protecon—The firewall monitors sessions from all zones (regardless
of whether Packet Buffer Protecon is enabled in a zone) and how those sessions ulize the
packet buffer. You must configure Packet Buffer Protecon globally (Device > Setup > Session
Sengs) to protect the firewall and to enable it on individual zones. When packet buffer
consumpon reaches the configured Acvate percentage, the firewall used Random Early Drop
(RED) to drop packets from the offending sessions (the firewall doesn’t drop complete sessions
at the global level).
• Per-Zone Packet Buffer Protecon—Enable Packet Buffer Protecon on each zone (Network
> Zones) to layer in a second level of protecon. When packet buffer consumpon crosses
the Acvate threshold and global protecon begins to apply RED to session traffic, that starts
the Block Hold Time mer. The Block Hold Time is the amount of me in seconds that the
offending session can connue before the firewall blocks the enre session. The offending
session remains blocked unl the Block Duraon me expires.
You must enable Packet Buffer Protecon globally in order for it to be acve in zones.
There are two types of packet buffer protecon:

• Packet Buffer Protecon Based on Buffer Ulizaon
• Packet Buffer Protecon Based on Latency
Packet Buffer Protecon Based on Buffer Ulizaon

Packet Buffer Protecon based on buffer ulizaon is enabled by default. Take baseline
measurements of firewall packet buffer ulizaon over a period of me—at least one business
week, but a longer measurement period provides a beer baseline—to understand typical usage.
To see packet buffer ulizaon for a specified period of me (or to see the top five sessions that
use as least 2 percent of the packet buffer), use the operaonal CLI command:
admin1138@thxvm1>show running resource-monitor [day | hour | ingress-

backlogs | minute | second | week]
The CLI command provides a snapshot of buffer ulizaon for the specified period of me,
but is neither automated nor connuous. To automate connuous packet buffer ulizaon
measurements so you can monitor changes in behavior and anomalous events, use a script. Your
Palo Alto Networks account team can provide a sample script that you can modify to develop
your own script; however, the script is not officially supported and there is no technical support
available for script usage or modificaon.
If baseline measurements consistently show abnormally high packet buffer ulizaon, then
the firewall’s capacity may be undersized for typical traffic loads. In this case, consider resizing
the firewall deployment. Otherwise, you need to tune the Packet Buffer Protecon thresholds
carefully to prevent impacted buffers from overflowing (and to prevent dropping legimate traffic).
When firewall sizing is correct for the deployment, only an aack should cause a large spike in
buffer usage.
Overrunning the firewall packet buffer negavely impacts the firewall’s packet forwarding
capabilies. When the buffers are full, no packets can enter the firewall on any interface,
not just the interface that experienced the aack.
The best pracces for seng the thresholds are:

• Alert and Acvate—Start with the default threshold values, monitor packet buffer ulizaon,
and adjust the thresholds as necessary. The Alert threshold defaults to 50%; when packet
buffer ulizaon exceeds the threshold for more than 10 seconds, the firewall creates an
alert entry in the System log every minute. The Acvate threshold defaults to 80%; when the
threshold is reached, the firewall begins to migate the most abusive sessions. If the firewall is
sized correctly, buffer ulizaon should be well below 50%.
• Block Hold Time—When packet buffer ulizaon triggers the Acvate threshold, the Block
Hold Time sets the amount of me the offending session can connue before the firewall
blocks the session. During the Block Hold Time, the firewall connues to apply RED to the
packets of offending sessions. Start with the default Block Hold Time threshold value (60
seconds), monitor packet buffer ulizaon, and adjust the threshold as necessary. If the
packet buffer ulizaon percentage falls below the Acvate threshold before the Block Hold
Time expires, the mer resets and doesn’t start unl the Acvate threshold is crossed again.
Increasing the Block Hold Time imposes a greater penalty on offending sessions and reducing it
imposes a lesser penalty on offending sessions.
• Block Duraon—When the Block Hold Time expires, the firewall blocks the offending session
for the period of me defined by the Block Duraon. Start with the default threshold value
(3600 seconds), monitor packet buffer ulizaon, and adjust the threshold as necessary. When
you enable Packet Buffer Protecon on a zone, Block Duraon affects every session from the
IP address even if only one session from an IP address overulizes the packet buffer. If you
believe that blocking an IP address for one hour (3600 seconds) is too great a penalty, reduce
the Block Duraon to an acceptable value.
In addion to monitoring the buffer ulizaon of individual sessions, Packet Buffer Protecon can
also block an IP address if certain criteria are met. While the firewall monitors the packet buffers,
if it detects a source IP address rapidly creang sessions that would not individually be seen as an
aack, it blocks that IP address for the configured Block Duraon.
Network Address Translaon (NAT) (an external source that has translated its internet-
bound traffic using source NAT) can give the appearance of greater packet buffer
ulizaon because of IP address translaon acvity. If this occurs, adjust the thresholds in
a way that penalizes individual sessions but doesn’t penalize the underlying IP addresses
(so other sessions from the same IP address aren’t affected). To do this, reduce the Block
Hold Time so the firewall blocks individual sessions that overulize the buffers faster, and
reduce the Block Duraon so that the underlying IP address is not unduly penalized.
Packet Buffer Protecon Based on Latency

As an alternave to packet buffer protecon based on ulizaon, you can trigger packet buffer
protecon based on packet latency caused by dataplane packet buffering, which indicates
congeson on the firewall. Such packet buffer protecon migates head-of-line blocking by
alerng you to the congeson and performing random early drop (RED) on packets. Packet buffer
protecon based on latency can trigger the protecon before latency-sensive protocols or
applicaons are affected.
If your traffic includes protocols or applicaons that are latency-sensive, then packet buffer
protecon based on latency will be more helpful than packet buffer protecon based on buffer
ulizaon.
Packet buffer protecon based on latency includes seng a Latency Alert threshold (in
milliseconds), above which the firewall starts generang an Alert log event. The Latency Acvate
threshold indicates when the firewall acvates RED on incoming packets and starts generang an
Acvate log. The Latency Max Tolerate threshold indicates when the firewall uses with RED with
almost 100% drop probability.
The Block Hold Time and Block Duraon sengs funcon for packet buffer protecon based on
latency in the same way they do for packet buffer protecon based on ulizaon.
DoS Protecon Profiles and Policy Rules

DoS Protecon profiles and DoS Protecon policy rules combine to protect specific groups of
crical resources and individual crical resources against session floods. Compared to Zone
Protecon profiles, which protect enre zones from flood aacks, DoS protecon provides
granular defense for specific systems, especially crical systems that users access from the
internet and are oen aack targets, such as web servers and database servers. Apply both types
of protecon because if you only apply a Zone Protecon profile, then a DoS aack that targets
a parcular system in the zone can succeed if the total connecons-per-second (CPS) doesn’t
exceed the zone’s Acvate and Maximum rates.
DoS Protecon is resource-intensive, so use it only for crical systems. Similar to Zone Protecon
profiles, DoS Protecon profiles specify flood thresholds. DoS Protecon policy rules determine
the devices, users, zones, and services to which DoS Profiles apply.
In addion to configuring DoS protecon and zone protecon, apply the best pracce
Vulnerability Protecon profile to each Security policy rule to help defend against DoS
aacks.
• Classified Versus Aggregate DoS Protecon

• DoS Protecon Profiles
• DoS Protecon Policy Rules
Classified Versus Aggregate DoS Protecon

You can configure aggregate and classified DoS Protecon Profiles, and apply one profile or one of
each type of profile to DoS Protecon Policy Rules when you configure DoS Protecon.
• Aggregate—Sets thresholds that apply to the enre group of devices specified in a DoS
Protecon policy rule instead of to each individual device, so one device could receive the
majority of the allowed connecon traffic. For example, a Max Rate of 20,000 CPS means
the total CPS for the group is 20,000, and an individual device can receive up to 20,000 CPS
if other devices don’t have connecons. Aggregate DoS Protecon policies provide another
layer of broad protecon (aer your dedicated DDoS device at the internet perimeter and
Zone Protecon profiles) for a parcular group of crical devices when you want to apply extra
constraints on specific subnets, users, or services.
• Classified—Sets flood thresholds that apply to each individual device specified in a DoS
Protecon policy rule. For example, if you set an Max Rate of 5,000 CPS, each device specified
in the rule can accept up to 5,000 CPS before it drops new connecons. If you apply a
classified DoS Protecon policy rule to more than one device, the devices governed by the rule
should be similar in terms of capacity and how you want to control their CPS rates because
classified thresholds apply to each individual device. Classified profiles protect individual crical
resources.
When you configure a DoS Protecon policy rule with a classified DoS Protecon profile
(Opon/Protecon > Classified > Address), use the Address field to specify whether
incoming connecons count toward the profile thresholds based on matching the source-ip-
only, desnaon-ip-only, or scr-dest-ip-both (the firewall counts both the source and the
desnaon IP addresses matches toward the thresholds). Counters consume resources, so the
way you count address matches affects firewall resource consumpon. You can use classified
DoS protecon to:
• Protect crical individual devices, especially servers that users access from the internet
and are oen aack targets, such as web servers, database servers, and DNS servers. Set
appropriate flood and resource protecon thresholds in a classified DoS Protecon profile.
Create a DoS Protecon policy rule that applies the profile to each server’s IP address by
adding the IP addresses as the rule’s desnaon criteria, and set the Address to desnaon-
ip-only.
Do not use source-IP-only or src-dest-ip-both classificaon for internet-facing

zones in classified DoS Protecon policy rules because the firewall doesn’t have the
capacity to store counters for every possible IP address on the internet. Increment
the threshold counter for source IPs only for internal zone or same-zone rules. In
perimeter zones, use desnaon-ip-only.
• Monitor the CPS rate for a suspect host or group of hosts (the zone that contains the hosts
cannot be internet-facing). Set an appropriate alarm threshold in a classified DoS Protecon
profile to nofy you if a host iniates an unusually large number of connecons. Create a
DoS Protecon policy rule that applies the profile to the individual source or source address
group and set the Address to source-ip-only. Invesgate hosts that iniate enough new
connecons to set off the alarm.
How you configure the Address (source-ip-only, desnaon-ip-only, or src-dest-ip-both) for
classified profiles depends on your DoS protecon goals, what you are protecng, and whether
the protected device(s) are in internet-facing zones.
The firewall uses more resources to track src-dest-ip-both as the Address than to track
source-IP-only or desnaon-ip-only because the counters consume resources for both
the source and desnaon IP addresses instead of just one of the two.
If you apply both an aggregate and a classified DoS Protecon profile to the same DoS Protecon
policy rule, the firewall applies the aggregate profile first and then applies the classified profile
if needed. For example, we protect a group of five web servers with both types of profiles in a
DoS Protecon policy rule. The aggregate profile configuraon drops new connecons when
the combined total for the group reaches a Max Rate of 25,000 CPS. The classified profile
configuraon drops new connecons to any individual web server in the group when it reaches a
Max Rate of 6,000 CPS. There are three scenarios where new connecon traffic crosses Max Rate
thresholds:
• The new CPS rate exceeds the aggregate Max Rate but doesn’t exceed the classified Max Rate.
In this scenario, the firewall applies the aggregate profile and blocks all new connecons for the
configured Block Duraon.
• The new CPS rate doesn’t exceed the aggregate Max Rate, but the CPS to one of the web
servers exceeds the classified Max Rate. In this scenario, the firewall checks the aggregate
profile and finds that the rate for the group is less than 25,000 CPS, so the firewall doesn’t
block new connecons based on that. Next, the firewall checks the classified profile and finds
that the rate for a parcular server exceeds 6,000 CPS. The firewall applies the classified
profile and blocks new connecons to that parcular server for the configured Block Duraon.
Because the other servers in the group are within the classified profile’s Max Rate, their traffic
is not affected.
• The new CPS rate exceeds the aggregate Max Rate and also exceeds the classified Max Rate
for one of the web servers. In this scenario, the firewall checks the aggregate profile and finds
that the rate for the group exceeds 25,000 CPS, so the firewall blocks new connecons to limit
the group’s total CPS. The firewall then checks the classified profile and finds that the rate for
a parcular server exceeds 6,000 CPS (so the aggregate profile enforced the group’s combined
limit, but that wasn’t enough to protect this parcular server). The firewall applies the classified
profile and blocks new connecons to that parcular server for the configured Block Duraon.
Because the other servers in the group are within the classified profile’s Max Rate, their traffic
is not affected.
If you want both an aggregate and a classified DoS Protecon profile to apply to the same
traffic, you must apply both profiles to the same DoS Protecon policy rule. If you apply
the aggregate profile to one rule and the classified profile to a different rule, even if they
specify exactly the same traffic, the firewall can apply only one profile because when
the traffic matches the first DoS Protecon policy rule, the firewall executes the Acon
specified in that rule and doesn’t compare to the traffic to any subsequent rules, so the
traffic never matches the second rule and the firewall can’t apply its acon. (This is the
same way that Security policy rules work.)
DoS Protecon Profiles

DoS Protecon profiles set thresholds that protect against new session IP flood aacks and
provide resource protecon (maximum concurrent session limits for specified endpoints and
resources). DoS Protecon profiles protect specific devices (classified profiles) and groups of
devices (aggregate profiles) against SYN, UDP, ICMP, ICMPv6, and Other IP flood aacks.
Configuring Flood Protecon thresholds in a DoS Protecon profile is similar to configuring Flood
Protecon in a Zone Protecon profile, but Zone Protecon profiles protect enre ingress zones,
while DoS protecon profiles and policy rules are granular and targeted, and can even be classified
to a single device (IP address). The firewall measures the aggregate number of connecons-per-
second (CPS) to a group of devices (aggregate profile) or measures the CPS to individual devices
(classified profile).
Measure and monitor firewall dataplane CPU consumpon to ensure that each firewall is
properly sized to support DoS and Zone Protecon and any other features that consume
CPU cycles, such as decrypon. If you use Panorama to manage your firewalls, Device
Monitoring (Panorama > Managed Devices > Health > All Devices) shows you the CPU
and memory consumpon of each managed firewall. It can also show you a 90-day trend
line of CPU average and peak use to help you understand the typical available capacity of
each firewall.
For each flood type, you set three thresholds for new CPS to a group of devices (aggregate) or to
individual devices (classified) and a Block Duraon, and you can set a drop Acon for SYN floods:
• Alarm Rate—When new CPS exceeds this threshold, the firewall generates a DoS alarm. For
classified profiles, set the rate to 15-20% above the device’s average CPS rate so that normal
fluctuaons don’t cause alerts. For aggregate profiles, set the rate to 15-20% above the group’s
average CPS rate.
• Acvate Rate—When new CPS exceeds this threshold, the firewall begins to drop new
connecons to migate the flood unl the CPS rate drops below the threshold. For classified
profiles, the Max Rate should be an acceptable CPS rate for the device(s) you’re protecng
(the Max Rate won’t flood the crical device(s)). You can set the Acvate Rate to the same
threshold as the Max Rate so that the firewall doesn’t use RED or SYN Cookies to begin
dropping traffic before it reaches the Max Rate. Set the Acvate Rate lower than the Max Rate
only if you want to drop traffic before it reaches the Max Rate. For aggregate profiles, set the
threshold just above the average peak CPS rate for the group to begin migang floods using
RED (or SYN Cookies for SYN floods).
• Max Rate—When new CPS exceeds this threshold, the firewall blocks (drops) all new
connecons from the offending IP address for the specified Block Duraon me period.
For classified profiles, base the Max Rate threshold on the capacity of the device(s) you’re
protecng so that the CPS rate can’t flood them. For aggregate profiles, set to 80-90% of the
group’s capacity.
• Block Duraon—When new CPS exceeds the Max Rate, the firewall blocks new connecons
from the offending IP address. The Block Duraon specifies the amount of me the
firewall connues to block the IP address’s new connecons. While the firewall blocks new
connecons, it doesn’t count incoming connecons and doesn’t increment the threshold
counters. For classified and aggregate profiles, use the default value (300 seconds) to block the
aacking session without penalizing legimate sessions from the source for too long a period
of me.
SYN Flood Protecon is the only type for which you set the drop Acon. Start by seng
the Acon to SYN Cookies. SYN Cookies treats legimate traffic fairly and only drops
traffic that fails the SYN handshake, while using Random Early Drop drops traffic
randomly, so RED may affect legimate traffic. However, SYN Cookies is more resource-
intensive because the firewall acts as a proxy for the target server and handles the
three-way handshake for the server. The tradeoff is not dropping legimate traffic (SYN
Cookies) versus preserving firewall resources (RED). Monitor the firewall, and if SYN
Cookies consumes too many resources, switch to RED. If you don’t have a dedicated DDoS
prevenon device in front of the firewall, always use RED as the drop mechanism.
The default threshold values are high so that DoS Protecon profiles don’t unexpectedly drop
legimate traffic. Monitor connecon traffic and adjust the thresholds to values appropriate for
your network. Start by taking baseline measurements of average and peak CPS for each flood
type to determine the normal traffic condions for the crical devices you want to protect.
Because normal traffic loads experience some fluctuaon, it’s best not to drop connecons too
aggressively. Monitor and adjust the flood thresholds as needed and as your network evolves.
Another method of seng flood thresholds is to use the baseline measurements to set the
maximum CPS you want to allow and work back from there to derive reasonable flood migaon
alarm and acvaon rates.
Firewalls with mulple dataplane processors (DPs) distribute connecons across DPs. In
general, the firewall divides the CPS threshold sengs equally across its DPs. For example,
if a firewall has five DPs and you set the Alarm Rate to 20,000 CPS, each DP has an
Alarm Rate of 4,000 CPS (20,000 / 5 = 4,000), so if the new sessions on a DP exceeds
4,000, it triggers the Alarm Rate threshold for that DP.
In addion to seng IP flood thresholds, you can also use DoS Protecon profiles to detect and
prevent session exhauson aacks in which a large number of hosts (bots) establish as many
sessions as possible to consume a target’s resources. On the profile’s Resources Protecon tab,
you can set the maximum number of concurrent sessions that the device(s) defined in the DoS
Protecon policy rule to which you apply the profile can receive. When the number of concurrent
sessions reaches its maximum limit, new sessions are dropped.
The maximum number of concurrent sessions to set depends on your network context.
Understand the number of concurrent sessions that the resources you are protecng (defined in
the DoS Protecon policy rule to which you aach the profile) can handle. Set the threshold to
approximately 80% of the resources’ capacity, then monitor and adjust the threshold as needed.
For aggregate profiles, the Resources Protecon threshold applies to all traffic of the devices
defined in the policy rule (source and desnaon). For classified profiles, the Resources Protecon
threshold applies to the traffic based on whether the classified policy rule applies to the source IP
only, to the desnaon IP only, or to both the source and desnaon IPs.
DoS Protecon Policy Rules

DoS Protecon policy rules control the systems to which the firewall applies DoS protecon (the
flood thresholds configured in DoS Protecon profiles that you aach to DoS Protecon policy
rules), what acon to take when traffic matches the criteria defined in the rule, and how to log
DoS traffic. Because DoS protecon consumes firewall resources, use it only to defend specific
crical resources against session floods, especially common targets that users access from the
internet, such as web servers and database servers. Use Zone Protecon profiles to protect enre
zones against floods and other aacks. DoS Protecon policy rules provide granular matching
criteria so that you have the flexibility to define exactly what you want to protect:
• Source zone, interface, IP address (including whole regions), and user.
• Desnaon zone, interface, and IP address (including whole regions).
• Services (by port and protocol). DoS protecon applies only to the services you specify.
However, specifying services doesn’t allow the services and implicitly block all other services.
Specifying services limits DoS protecon to those services, but doesn’t block other services.
In addion to protecng service ports in use on crical servers, you can also protect
against DoS aacks on the unused service ports of crical servers. For crical systems,
you can do this by creang one DoS Protecon policy rule and profile to protect ports
with services running, and a different DoS Protecon policy rule and profile to protect
ports with no services running. For example, you can protect a web server’s normal
service ports, such as 80 and 443, with one policy/profile, and protect all of the other
service ports with the other policy/profile. Be aware of the firewall’s capacity so that
servicing the DoS counters doesn’t impact performance.
When traffic matches a DoS Protecon policy rule, the firewall takes one of three acons:
• Deny—The firewall denies access and doesn’t apply a DoS Protecon profile. Traffic that
matches the rule is blocked.
• Allow—The firewall permits access and doesn’t apply a DoS Protecon profile. Traffic that
matches the rule is allowed.
• Protect—The firewall protects the devices defined in the DoS Protecon policy rule by applying
the specified DoS Protecon profile or profiles thresholds to traffic that matches the rule. A
rule can have one aggregate DoS Protecon profile and one classified DoS Protecon profile,
and for classified profiles, you can use the source IP, desnaon IP, or both to increment the
flood threshold counters, as described in Classified Versus Aggregate DoS Protecon. Incoming
packets count against both DoS Protecon profile thresholds if the they match the rule.
The firewall applies DoS Protecon profiles only if the Acon is Protect. If the DoS Protecon
policy rule’s Acon is Protect, specify the appropriate aggregate and/or classified DoS Protecon
profiles in the rule so that the firewall applies the DoS Protecon profile’s thresholds to traffic that
matches the rule. Most rules are Protect rules.
The Allow and Deny acons enable you to make excepons within larger groups but do not apply
DoS protecon to the traffic. For example, you can deny the traffic from most of a group but allow
a subset of that traffic. Conversely, you can allow the traffic from most of a group and deny a
subset of that traffic.
You can Schedule when a DoS Protecon policy rule is acve (start and end me, recurrence
period). One use case for scheduling is to apply different flood thresholds at different mes of
the day or week. For example, if your business experiences significantly less traffic at night than
during the day, you may want to apply higher flood thresholds during the day than at night.
Another use case is to schedule special thresholds for special events, providing that the firewall
supports the CPS rates.
For easier management and granular reporng, configure Log Forwarding to separate DoS
protecon logs from other threat logs. Forward DoS threshold violaon events directly to the
administrators via email in addion to forwarding the logs to a server such an SNMP or syslog
server. Providing that the firewalls are appropriately sized, threshold breaches should not be
frequent and will be strong indicators of an aack aempt.
Configure Zone Protecon to Increase Network Security

The following topics provide zone protecon configuraon examples:
• Configure Reconnaissance Protecon
• Configure Packet Based Aack Protecon
• Configure Protocol Protecon
• Configure Packet Buffer Protecon
• Configure Packet Buffer Protecon Based on Latency
• Configure Ethernet SGT Protecon
Configure Reconnaissance Protecon

Configure one of the following Reconnaissance Protecon acons for the firewall to take in
response to the corresponding reconnaissance aempt:
• Allow—The firewall allows the port scan or host sweep reconnaissance to connue.
• Alert—The firewall generates an alert for each port scan or host sweep that matches the
configured threshold within the specified me interval. Alert is the default acon.
• Block—The firewall drops all subsequent packets from the source to the desnaon for the
remainder of the specified me interval.
• Block IP—The firewall drops all subsequent packets for the specified Duraon, in seconds
(the range is 1-3,600). Track By determines whether the firewall blocks source or source-and-
desnaon traffic.
STEP 1 | Configure Reconnaissance Protecon.
1. Select Network > Network Profiles > Zone Protecon.
2. Select a Zone Protecon profile or Add a new profile and enter a Name for it.
3. On the Reconnaissance Protecon tab, select the scan types to protect against.
4. Select an Acon for each scan. If you select Block IP, you must also configure Track By
(source or source-and-desnaon) and Duraon.
5. Set the Interval in seconds. This opons defines the me interval for port scan and host
sweep detecon.
6. Set the Threshold. The threshold defines the number of port scan events or host sweeps
that occurs within the interval configured above that triggers an acon.
STEP 2 | (Oponal) Configure a Source Address Exclusion.

1. On the Reconnaissance Protecon tab, Add a Source Address Exclusion.
1. Enter a descripve Name for the address you want to exclude.
2. Set the Address Type to IPv4 or IPv6 and then select an address object or enter an IP
address.
3. Click OK.
2. Click OK to save the Zone Protecon profile.
Configure Packet Based Aack Protecon

To enhance security for a zone, Packet-Based Aack Protecon allows you to specify whether the
firewall drops IP, IPv6, TCP, ICMP, or ICMPv6 packets that have certain characteriscs or strips
certain opons from the packets.
For example, you can drop TCP SYN and SYN-ACK packets that contain data in the payload during
a TCP three-way handshake. A Zone Protecon profile by default is set to drop SYN and SYN-ACK
packets with data (you must apply the profile to the zone).
The TCP Fast Open opon (RFC 7413) preserves the speed of a connecon setup by including
data in the payload of SYN and SYN-ACK packets. A Zone Protecon profile treats handshakes
that use the TCP Fast Open opon separately from other SYN and SYN-ACK packets; the profile
by default is set to allow the handshake packets if they contain a valid Fast Open cookie.
If you have exisng Zone Protecon profiles in place when you upgrade to PAN-OS 8.0,
the three default sengs will apply to each profile and the firewall will act accordingly.
Beginning with PAN-OS 8.1.2 and later releases, you can use a CLI command (Step 4 in this task)
to enable the firewall to generate a Threat log when the firewall receives and drops the following
types of packets, so that you can more easily analyze these occurrences and also fulfill audit and
compliance requirements:
• Teardrop aack
• DoS aack using ping of death
Furthermore, the same CLI command also enables the firewall to generate Threat logs for the
following types of packets if you enable the corresponding Packet Based Aack Protecon:
• Fragmented IP packets
• IP address spoofing
• ICMP packets larger than 1024 bytes
• Packets containing ICMP fragments
• ICMP packets embedded with an error message
• First packets for a TCP session that are not SYN packets
STEP 1 | Create a Zone Protecon profile and configure Packet-Based Aack Protecon sengs.
1. Select Network > Network Profiles > Zone Protecon and Add a new profile.
2. Enter a Name for the profile and an oponal Descripon.
3. Select Packet Based Aack Protecon.
4. On each tab (IP Drop, TCP Drop, ICMP Drop, IPv6 Drop, and ICMPv6 Drop), select the
Packet-Based Aack Protecon sengs you want to enforce to protect a zone.
5. Click OK.
STEP 2 | Apply the Zone Protecon profile to a security zone that is assigned to interfaces you want
to protect.
1. Select Network > Zones and select the zone where you want to assign the Zone
2. Add the Interfaces belonging to the zone.
3. For Zone Protecon Profile, select the profile you just created.
4. Click OK.
STEP 4 | (PAN-OS 8.1.2 and later releases) Enable the firewall to generate Threat logs for a teardrop
aack and a DoS aack using ping of death, and also generate Threat logs for the types of
packets listed above if you enable the corresponding packet-based aack protecon (in Step
1). For example, if you enable packet-based aack protecon for Spoofed IP address, using
the following CLI causes the firewall to generate a Threat log when the firewall receives and
drops a packet with a spoofed IP address.
1. Access the CLI.
2. Use the operaonal CLI command set system setting additional-threat-
log on. Default is off.
Configure Protocol Protecon

Protect virtual wire or Layer 2 security zones from non-IP protocol packets by using Protocol
Protecon.
• Use Case: Non-IP Protocol Protecon Between Security Zones on Layer 2 Interfaces
• Use Case: Non-IP Protocol Protecon Within a Security Zone on Layer 2 Interfaces
Use Case: Non-IP Protocol Protecon Between Security Zones on Layer 2 Interfaces
In this use case, the firewall is in a Layer 2 VLAN divided into two subinterfaces. VLAN 100 is
192.168.100.1/24, subinterface .6. VLAN 200 is 192.168.100.1/24, subinterface .7. Non-IP
protocol protecon applies to ingress zones. In this use case, if the Internet zone is the ingress
zone, the firewall blocks the Generic Object Oriented Substaon Event (GOOSE) protocol. If
the User zone is the ingress zone, the firewall allows the GOOSE protocol. The firewall implicitly
allows IPv4, IPv6, ARP, and VLAN-tagged frames in both zones.
STEP 1 | Configure two VLAN subinterfaces.

1. Select Network > Interfaces > VLAN and Add an interface.
2. Interface Name defaults to vlan. Aer the period, enter 7.
3. On the Config tab, Assign Interface To the VLAN 200.
4. Click OK.
5. Select Network > Interfaces > VLAN and Add an interface.
6. Interface Name defaults to vlan. Aer the period, enter 6.
7. On the Config tab, Assign Interface To the VLAN 100.
8. Click OK.
STEP 2 | Configure protocol protecon in a Zone Protecon profile to block GOOSE protocol packets.
1. Select Network > Network Profiles > Zone Protecon and Add a profile.
2. Enter the Name Block GOOSE.
3. Select Protocol Protecon.
4. Choose Rule Type of Exclude List.
5. Enter the Protocol Name, GOOSE, to easily idenfy the Ethertype on the list. The
firewall doesn’t verify that the name you enter matches the Ethertype code; it uses only
the Ethertype code to filter.
6. Enter Ethertype code 0x88B8. The Ethertype must be preceded by 0x to indicate a
hexadecimal value. Range is 0x0000 to 0xFFFF.
7. Select Enable to enforce the protocol protecon. You can disable a protocol on the list,
for example, for tesng.
8. Click OK.
STEP 3 | Apply the Zone Protecon profile to the Internet zone.

1. Select Network > Zones and Add a zone.
2. Enter the Name of the zone, Internet.
3. For Locaon, select the virtual system where the zone applies.
5. Add the Interface that belongs to the zone, vlan.7.
6. For Zone Protecon Profile, select the profile Block GOOSE.
7. Click OK.
STEP 4 | Configure protocol protecon to allow GOOSE protocol packets.

Create another Zone protecon profile named Allow GOOSE, and choose Rule Type of Include
List.
When configuring an Include list, include all required non-IP protocols; an incomplete
list can result in legimate non-IP traffic being blocked.
STEP 5 | Apply the Zone Protecon profile to the User zone.

1. Select Network > Zones and Add a zone.
2. Enter the Name of the zone, User.
5. Add the Interface that belongs to the zone, vlan.6.
6. For Zone Protecon Profile, select the profile Allow GOOSE.
7. Click OK.
STEP 6 | Commit.
Click Commit.
STEP 7 | View the number of non-IP packets the firewall has dropped based on protocol protecon.
Access the CLI.
> show counter global name pkt_nonip_pkt_drop

> show counter global name pkt_nonip_pkt_drop delta yes
Use Case: Non-IP Protocol Protecon Within a Security Zone on Layer 2 Interfaces
If you don’t implement a Zone Protecon profile with non-IP protocol protecon, the firewall
allows non-IP protocols in a single zone to go from one Layer 2 interface to another. In this use
case, blocking LLDP packets ensures that LLDP for one network doesn’t discover a network
reachable through another interface in the zone.
In the following figure, the Layer 2 VLAN named Datacenter is divided into two subinterfaces:
192.168.1.1/24, subinterface .7 and 192.168.1.2/24, subinterface .8. The VLAN belongs to the
User zone. By applying a Zone Protecon profile that blocks LLDP to the User zone:
• Subinterface .7 blocks LLDP from its switch to the firewall at the red X on the le, prevenng
that traffic from reaching subinterface .8.
• Subinterface .8 blocks LLDP from its switch to the firewall at the red X on the right, prevenng
that traffic from reaching subinterface .7.
STEP 1 | Create a subinterface for an Ethernet interface.

1. Select Network > Interfaces > Ethernet and select a Layer 2 interface, in this example,
ethernet1/1.
2. Select Add Subinterfaces.
3. The Interface Name defaults to the interface (ethernet 1/1). Aer the period, enter 7.
4. For Tag, enter 300.
5. For Security Zone, select User.
6. Click OK.
STEP 2 | Create a second subinterface for the Ethernet interface.

1. Select Network > Interfaces > Ethernet and select the Layer 2 interface: ethernet1/1.
2. Select Add Subinterfaces.
3. The Interface Name defaults to the interface (ethernet 1/1). Aer the period, enter 8.
4. For Tag, enter 400.
5. For Security Zone, select User.
6. Click OK.
STEP 3 | Create a VLAN for the Layer2 interface and two subinterfaces.
1. Select Network > VLANs and Add a VLAN.
2. Enter the Name of the VLAN; for this example, enter Datacenter.
3. For VLAN Interface, select None.
4. For Interfaces, click Add and select the Layer 2 interface: ethernet1/1, and two
subinterfaces: ethernet1/1.7 and ethernet1/1.8.
5. Click OK.
STEP 4 | Block non-IP protocol packets in a Zone Protecon profile.

1. Select Network > Network Profiles > Zone Protecon and Add a profile.
2. Enter the Name, in this example, Block LLDP.
3. Enter a profile Descripon—Block LLDP packets from an LLDP network to other
interfaces in the zone (intrazone).
4. Select Protocol Protecon.
5. Choose Rule Type of Exclude List.
6. Enter Protocol Name LLDP.
7. Enter Ethertype code 0x88cc. The Ethertype must be preceded by 0x to indicate a
hexadecimal value.
8. Select Enable.
9. Click OK.
STEP 5 | Apply the Zone Protecon profile to the security zone to which Layer 2 VLAN belongs.
2. Add a zone.
3. Enter the Name of the zone, User.
6. Add an Interface that belongs to the zone, ethernet1/1.7
7. Add an Interface that belongs to the zone, ethernet1/1.8.
8. For Zone Protecon Profile, select the profile Block LLDP.
9. Click OK.
STEP 6 | Commit.
Click Commit.
STEP 7 | View the number of non-IP packets the firewall has dropped based on protocol protecon.
Access the CLI.
> show counter global name pkt_nonip_pkt_drop

> show counter global name pkt_nonip_pkt_drop delta yes
Configure Packet Buffer Protecon

You can configure Packet Buffer Protecon at two levels: the device level (global) and if enabled
globally, you can also enable it at the zone level. Global packet buffer protecon (Device > Setup
> Session) is to protect firewall resources and ensure that malicious traffic does not cause the
firewall to become non-responsive.
Packet buffer protecon per ingress zone (Network > Zones) is a second layer of protecon that
starts blocking the offending IP address if it connues to exceed the packet buffer protecon
thresholds. The firewall can block all traffic from the offending source IP address. Keep in mind
that if the source IP address is a translated NAT IP address, many users can be using the same
IP address. If one abusive user triggers packet buffer protecon and the ingress zone has packet
buffer protecon enabled, all traffic from that offending source IP address (even from non-abusive
users) can be blocked when the firewall puts the IP address on its block list.
The most effecve way to block DoS aacks against a service behind the firewall is to configure
packet buffer protecon globally and per ingress zone.
You can Enable Packet Buffer Protecon for a zone, but it is not acve unl you enable packet
buffer protecon globally and specify the sengs.
STEP 1 | Enable packet buffer protecon globally.
1. Select Device > Setup > Session and edit the Session Sengs.
2. Select Packet Buffer Protecon.
3. Define the packet buffer protecon behavior:
• Alert (%)—When packet buffer ulizaon exceeds this threshold for more than 10
seconds, the firewall creates a log event every minute. Range s 0% to 99%; default is
50%. If the value is 0%, the firewall does not create a log event.
• Acvate (%)—When packet buffer ulizaon reaches this threshold, the firewall
begins to migate the most abusive sessions by applying random early drop (RED).
Range is 0% to 99%; default is 50%. If the value is 0%, the firewall does not apply
RED. If the abuser is ingressing a zone that has Packet Buffer Protecon enabled, the
firewall can also discard the abusive session or block the offending source IP address.
Start with the default threshold and adjust it if necessary.
The firewall records alert events in the System log, and records events for
dropped traffic, discarded sessions, and blocked IP address in the Threat log.
• Block Hold Time (sec)—Number of seconds a RED-migated session is allowed to
connue before the firewall discards it. Range is 0 to 65,535; default is 60. If the value
is 0, the firewall does not discard sessions based on packet buffer protecon.
• Block Duraon (sec)—Number of seconds a session remains discarded or an IP
address remains blocked. Range is 1 to 15,999,999; default is 3,600.
4. Click OK.
STEP 2 | Enable addional packet buffer protecon on an ingress zone.

2. Choose an ingress zone and click on its name.
3. Enable Packet Buffer Protecon in the Zone Protecon secon.
4. Click OK.
Configure Packet Buffer Protecon Based on Latency

Configure packet buffer protecon based on latency and apply it to zones that have traffic
consisng of protocols and applicaons that are latency-sensive.
STEP 1 | Select Device > Setup > Session.
STEP 2 | Edit the Session Sengs secon and enable Packet Buffer Protecon.
STEP 3 | Enable Buffering Latency Based.
STEP 4 | Enter the Latency Alert (milliseconds) threshold above which the firewall starts generang an
Alert log event every minute; range is 1 to 20,000; default is 50.
STEP 5 | Enter the Latency Acvate (milliseconds) threshold above which the firewall acvates
random early drop (RED) on incoming packets and starts generang an Acvate log every 10
seconds; range is 1 to 20,000ms; default is 200ms.
STEP 6 | Enter the Latency Max Tolerate (milliseconds) threshold above which the firewall uses RED
with close to 100% drop probability; range is 1 to 20,000ms; default is 500ms.
If the current latency is a value between the Latency Acvate threshold and the Latency Max
Tolerate threshold, the firewall calculates the RED drop probability as follows: (current latency
- Latency Acvate threshold) / (Latency Max Tolerate threshold - Latency Acvate threshold).
For example, if the current latency is 300, Latency Acvate is 200, and Latency Max Tolerate
is 500, then (300-200)/(500-200) = 1/3, meaning the firewall uses approximately 33% RED
drop probability.
STEP 7 | Configure the Block Hold Time and Block Duraon as for Packet Buffer Protecon based on
ulizaon.
STEP 8 | Click OK.
STEP 9 | Enable the second layer of protecon for each zone where you want packet buffer protecon
based on latency.
1. Select Network > Zones and select a zone.
2. Enable Packet Buffer Protecon.
STEP 10 | Commit.
Configure Ethernet SGT Protecon

Use the following task to configure an Ethernet SGT Protecon profile.
STEP 1 | Create a Zone Protecon profile to provide Ethernet SGT Protecon.
1. Select Network > Network Profiles > Zone Protecon.
2. Add a Zone Protecon profile by Name.
3. Select Ethernet SGT Protecon.
4. Add a Layer 2 SGT Exclude List by name.
5. Enter one or more Tag values for the list; range is 0 to 65,535. You can enter individual
entries that are a conguous range of tag values (for example, 100-500). You can add up
to 100 (individual or range) tag entries in an Exclude List.
6. Enable the Layer 2 SGT Exclude List. You can disable the list at any me.
7. Click OK.
STEP 2 | Apply the Zone Protecon profile to the security zone to which the Layer 2, virtual wire, or
tap interfaces belong.
2. Add a zone.
3. Enter the Name of the zone.
5. For Type, select Layer2, Virtual Wire, or Tap.
6. Add an Interface that belongs to the zone.
7. For Zone Protecon Profile, select the profile you created.
8. Click OK.
STEP 3 | Commit.
STEP 4 | View the global counter of packets that the firewall dropped as a result of all Zone Protecon
profiles that employ Ethernet SGT Protecon.
1. Access the CLI.
2. > show counter global name pan_flow_dos_l2_sec_tag_drop
DoS Protecon Against Flooding of New Sessions

DoS protecon against flooding of new sessions is beneficial against high-volume single-session
and mulple-session aacks. In a single-session aack, an aacker uses a single session to target
a device behind the firewall. If a Security rule allows the traffic, the session is established and the
aacker iniates an aack by sending packets at a very high rate with the same source IP address
and port number, desnaon IP address and port number, and protocol, trying to overwhelm the
target. In a mulple-session aack, an aacker uses mulple sessions (or connecons per second
[cps]) from a single host to launch a DoS aack.
This feature defends against DoS aacks of new sessions only, that is, traffic that has
not been offloaded to hardware. An offloaded aack is not protected by this feature.
However, this topic describes how you can create a Security policy rule to reset the client;
the aacker reiniates the aack with numerous connecons per second and is blocked by
the defenses illustrated in this topic.
DoS Protecon Profiles and Policy Rules work together to provide protecon against flooding
of many incoming SYN, UDP, ICMP, and ICMPv6 packets, and other types of IP packets. You
determine what thresholds constute flooding. In general, the DoS Protecon profile sets the
thresholds at which the firewall generates a DoS alarm, takes acon such as Random Early Drop,
and drops addional incoming connecons. A DoS Protecon policy rule configured to protect
(rather than to allow or deny packets) determines the criteria for packets to match (such as source
address) in order to be counted toward the thresholds. This flexibility allows you to block certain
traffic, or allow certain traffic and treat other traffic as DoS traffic. When the incoming rate
exceeds your maximum threshold, the firewall blocks incoming traffic from the source address.
• Mulple-Session DoS Aack
• Single-Session DoS Aack
• Configure DoS Protecon Against Flooding of New Sessions
• End a Single Session DoS Aack
• Idenfy Sessions That Use Too Much of the On-Chip Packet Descriptor
• Discard a Session Without a Commit
Mulple-Session DoS Aack

Configure DoS Protecon Against Flooding of New Sessions by configuring a DoS Protecon
policy rule, which determines the criteria that, when matched by incoming packets, trigger the
Protect acon. The DoS Protecon profile counts each new connecon toward the Alarm Rate,
Acvate Rate, and Max Rate thresholds. When the incoming new connecons per second exceed
the Acvate Rate, the firewall takes the acon specified in the DoS Protecon profile.
The following figure and table describe how the Security policy rules, DoS Protecon policy rules
and profile work together in an example.
Sequence of Events as Firewall Quarannes an IP Address
In this example, an aacker launches a DoS aack at a rate of

10,000 new connecons per second to UDP port 53. The aacker
also sends 10 new connecons per second to HTTP port 80.
The new connecons match criteria in the DoS Protecon

policy rule, such as a source zone or interface, source IP address,
desnaon zone or interface, desnaon IP address, or a service,
among other sengs. In this example, the policy rule specifies
UDP.
The DoS Protecon policy rule also specifies the Protect acon
and Classified, two sengs that dynamically put the DoS
Protecon profile sengs into effect. The DoS Protecon profile
specifies that a Max Rate of 3000 packets per second is allowed.
When incoming packets match the DoS Protecon policy rule,
Sequence of Events as Firewall Quarannes an IP Address

new connecons per second are counted toward the Alert,
Acvate, and Max Rate thresholds.
You can also use a Security policy rule to block all

traffic from the source IP address if you deem that
address to be malicious all the me.
The 10,000 new connecons per second exceed the Max Rate
threshold. When all of the following occur:
• the threshold is exceeded,
• a Block Duraon is specified, and
• Classified is set to include source IP address,
the firewall puts the offending source IP address on the block list.
An IP address on the block list is in quaranne, meaning all traffic

from that IP address is blocked. The firewall blocks the offending
source IP address before addional aack packets reach the
Security policy.
The following figure describes in more detail what happens aer an IP address that matches the
DoS Protecon policy rule is put on the block list. It also describes the Block Duraon mer.
Every one second, the firewall allows the IP address to come off the block list so that the firewall
can test the traffic paerns and determine if the aack is ongoing. The firewall takes the following
acon:
• During this one-second test period, the firewall allows packets that don’t match the DoS
Protecon policy criteria (HTTP traffic in this example) through the DoS Protecon policy rules
to the Security policy for validaon. Very few packets, if any, have me to get through because
the first aack packet that the firewall receives aer the IP address is let off the block list will
match the DoS Protecon policy criteria, quickly causing the IP address to be placed back on
the block list for another second. The firewall repeats this test each second unl the aack
stops.
• The firewall blocks all aack traffic from going past the DoS Protecon policy rules (the address
remains on the block list) unl the Block Duraon expires.
The 1-second checks illustrated in the preceding figure occur on firewall models that have
mulple dataplane CPUs and a hardware network processor. All single dataplane systems
or systems without a hardware network processor perform this migaon in soware and
use a 5-second interval.
When the aack stops, the firewall does not put the IP address back on the block list. The firewall
allows non-aack traffic to proceed through the DoS Protecon policy rules to the Security policy
rules for evaluaon. You must configure a Security policy rule to allow or deny traffic because
without one, an implicit Deny rule denies all traffic.
The block list is based on a source zone and source address combinaon. This behavior allows
duplicate IP addresses to exist as long as they are in different zones belonging to separate virtual
routers.
The Block Duraon seng in a DoS Protecon profile specifies how long the firewall blocks the
[offending] packets that match a DoS Protecon policy rule. The aack traffic remains blocked
unl the Block Duraon expires, aer which the aack traffic must again exceed the Max Rate
threshold to be blocked again.
If the aacker uses mulple sessions or bots that iniate mulple aack sessions, the
sessions count toward the thresholds in the DoS Protecon profile without a Security
policy deny or drop rule in place. Hence, a single-session aack requires a Security policy
deny or drop rule in order for each packet to count toward the thresholds; a mulple-
session aack does not.
Therefore, the DoS protecon against flooding of new sessions allows the firewall to efficiently
defend against a source IP address while aack traffic is ongoing and to permit non-aack traffic
to pass as soon as the aack stops. Pung the offending IP address on the block list allows the
DoS protecon funconality to take advantage of the block list, which is designed to quaranne
all acvity from that source IP address, such as packets with a different applicaon. Quaranning
the IP address from all acvity protects against a modern aacker who aempts a rotang
applicaon aack, in which the aacker simply changes applicaons to start a new aack or uses
a combinaon of different aacks in a hybrid DoS aack. You can Monitor Blocked IP Addresses
to view the block list, remove entries from it, and get addional informaon about an IP address
on the block list.
Beginning with PAN-OS 7.0.2, it is a change in behavior that the firewall places the
aacking source IP address on the block list. When the aack stops, non-aack traffic is
allowed to proceed to Security policy enforcement. The aack traffic that matched the
DoS Protecon profile and DoS Protecon policy rules remains blocked unl the Block
Duraon expires.
Single-Session DoS Aack

A single-session DoS aack typically will not trigger Zone or DoS Protecon profiles because
they are aacks that are formed aer the session is created. These aacks are allowed by the
Security policy because a session is allowed to be created, and aer the session is created, the
aack drives up the packet volume and takes down the target device.
Configure DoS Protecon Against Flooding of New Sessions to protect against flooding of new
sessions (single-session and mulple-session flooding). In the event of a single-session aack that
is underway, addionally End a Single Session DoS Aack.
Configure DoS Protecon Against Flooding of New Sessions

STEP 1 | Configure Security policy rules to deny traffic from the aacker’s IP address and allow other
traffic based on your network needs. You can specify any of the match criteria in a Security
policy rule, such as source IP address. (Required for single-session aack migaon or aacks
that have not triggered the DoS Protecon policy threshold; oponal for mulple-session
aack migaon).
This step is one of the steps typically performed to stop an exisng aack. See End a
Single Session DoS Aack.
• Create a Security Policy Rule
STEP 2 | Configure a DoS Protecon profile for flood protecon.
Because flood aacks can occur over mulple protocols, as a best pracce, acvate
protecon for all of the flood types in the DoS Protecon profile.
1. Select Objects > Security Profiles > DoS Protecon and Add a profile Name.
2. Select Classified as the Type.
3. For Flood Protecon, select all types of flood protecon:
• SYN Flood
• UDP Flood
• ICMP Flood
• ICMPv6 Flood
• Other IP Flood
4. When you enable SYN Flood, select the Acon that occurs when connecons per
second (cps) exceed the Acvate Rate threshold:
1. Random Early Drop—The firewall uses an algorithm to progressively start dropping
that type of packet. If the aack connues, the higher the incoming cps rate (above
the Acvate Rate) gets, the more packets the firewall drops. The firewall drops
packets unl the incoming cps rate reaches the Max Rate, at which point the firewall
drops all incoming connecons. Random Early Drop (RED) is the default acon for
SYN Flood, and the only acon for UDP Flood, ICMP Flood, ICMPv6 Flood, and
Other IP Flood. RED is more efficient than SYN Cookies and can handles larger
aacks, but doesn’t discern between good and bad traffic.
2. SYN Cookies—Rather than immediately sending the SYN to the server, the firewall
generates a cookie (on behalf of the server) to send in the SYN-ACK to the client. The
client responds with its ACK and the cookie; upon this validaon the firewall then
sends the SYN to the server. The SYN Cookies acon requires more firewall resources
than Random Early Drop; it’s more discerning because it affects bad traffic.
5. (Oponal) On each of the flood tabs, change the following thresholds to suit your
environment:
• Alarm Rate (connecons/s)—Specify the threshold rate (cps) above which a DoS alarm
is generated. (Range is 0-2,000,000; default is 10,000.)
• Acvate Rate (connecons/s)—Specify the threshold rate (cps) above which a DoS
response is acvated. When the Acvate Rate threshold is reached, Random Early
Drop occurs. Range is 0-2,000,000; default is 10,000. (For SYN Flood, you can select
the acon that occurs.)
• Max Rate (connecons/s)—Specify the threshold rate of incoming connecons per
second that the firewall allows. When the threshold is exceeded, new connecons
that arrive are dropped. (Range is 2-2,000,000; default is 40,000.)
The default threshold values in this step are only starng points and might not
be appropriate for your network. You must analyze the behavior of your network
to properly set inial threshold values.
6. On each of the flood tabs, specify the Block Duraon (in seconds), which is the length
of me the firewall blocks packets that match the DoS Protecon policy rule that
references this profile. Specify a value greater than zero. (Range is 1-21,600; default is
300.)
Set a low Block Duraon value if you are concerned that packets you incorrectly
idenfy as aack traffic will be blocked unnecessarily.
Set a high Block Duraon value if you are more concerned about blocking volumetric
aacks than you are about incorrectly blocking packets that aren’t part of an aack.
7. Click OK.
STEP 3 | Configure a DoS Protecon policy rule that specifies the criteria for matching the incoming
traffic.
The firewall resources are finite, so you wouldn’t want to classify using source address
on an internet-facing zone because there can be an enormous number of unique
IP addresses that match the DoS Protecon policy rule. That would require many
counters and the firewall would run out of tracking resources. Instead, define a DoS
Protecon policy rule that classifies using the desnaon address (of the server you are
protecng).
1. Select Policies > DoS Protecon and Add a Name on the General tab. The name is case-
sensive and can be a maximum of 31 characters, including leers, numbers, spaces,
hyphens, and underscores.
2. On the Source tab, choose the Type to be a Zone or Interface, and then Add the zone(s)
or interface(s). Choose zone or interface depending on your deployment and what you
want to protect. For example, if you have only one interface coming into the firewall,
choose Interface.
3. (Oponal) For Source Address, select Any for any incoming IP address to match the rule
or Add an address object such as a geographical region.
4. (Oponal) For Source User, select any or specify a user.
5. (Oponal) Select Negate to match any sources except those you specify.
6. (Oponal) On the Desnaon tab, choose the Type to be a Zone or Interface, and then
Add the desnaon zone(s) or interface(s). For example, enter the security zone you
want to protect.
7. (Oponal) For Desnaon Address, select Any or enter the IP address of the device you
want to protect.
8. (Oponal) On the Opon/Protecon tab, Add a Service. Select a service or click Service
and enter a Name. Select TCP or UDP. Enter a Desnaon Port. Not specifying a
parcular service allows the rule to match a flood of any protocol type without regard to
an applicaon-specific port.
9. On the Opon/Protecon tab, for Acon, select Protect.
10. Select Classified.
11. For Profile, select the name of the DoS Protecon profile you created.
12. For Address, select source-ip-only or src-dest-ip-both, which determines the type of IP
address to which the rule applies. Choose the seng based on how you want the firewall
to idenfy offending traffic:
• Specify source-ip-only if you want the firewall to classify only on the source IP
address. Because aackers oen test the enre network for hosts to aack, source-
ip-only is the typical seng for a wider examinaon.
• Specify src-dest-ip-both if you want to protect against DoS aacks only on the server
that has a specific desnaon address, and you also want to ensure that every source
IP address won’t surpass a specific cps threshold to that server.
13. Click OK.
STEP 4 | Commit.
Click Commit.
End a Single Session DoS Aack

To migate a single-session DoS aack, you would sll Configure DoS Protecon Against Flooding
of New Sessions in advance. At some point aer you configure the feature, a session might be
established before you realize a DoS aack (from the IP address of that session) is underway.
When you see a single-session DoS aack, perform the following task to end the session, so that
subsequent connecon aempts from that IP address trigger the DoS protecon against flooding
of new sessions.
STEP 1 | Idenfy the source IP address that is causing the aack.
For example, use the firewall Packet Capture feature with a desnaon filter to collect a
sample of the traffic going to the desnaon IP address. Alternavely, use the ACC to filter on
desnaon address to view the acvity to the target host being aacked.
STEP 2 | Create a DoS Protecon policy rule that will block the aacker’s IP address aer the aack
thresholds are exceeded.
STEP 3 | Create a Security policy rule to deny the source IP address and its aack traffic.
STEP 4 | End any exisng aacks from the aacking source IP address by execung the clear
session all filter source <ip-address> operaonal command.
Alternavely, if you know the session ID, you can execute the clear session id <value>
command to end that session only.
If you use the clear session all filter source <ip-address>

command, all sessions matching the source IP address are discarded, which can include
both good and bad sessions.
Aer you end the exisng aack session, any subsequent aempts to form an aack session
are blocked by the Security policy. The DoS Protecon policy counts all connecon aempts
toward the thresholds. When the Max Rate threshold is exceeded, the source IP address is
blocked for the Block Duraon, as described in Mulple-Session DoS Aack.
Idenfy Sessions That Use Too Much of the On-Chip Packet

Descriptor
When a firewall exhibits signs of resource depleon, it might be experiencing an aack that is
sending an overwhelming number of packets. In such events, the firewall starts buffering inbound
packets. You can quickly idenfy the sessions that are using an excessive percentage of the on-
chip packet descriptor and migate their impact by discarding them.
Perform the following task on any hardware-based firewall model (not a VM-Series firewall) to
idenfy, for each slot and dataplane, the on-chip packet descriptor percentage used, the top
five sessions using more than two percent of the on-chip packet descriptor, and the source IP
addresses associated with those sessions. Having that informaon allows you to take appropriate
acon.
STEP 1 | View firewall resource usage, top sessions, and session details. Execute the following
operaonal command in the CLI (sample output from the command follows):
admin@PA-7050> show running resource-monitor ingress-backlogs

-- SLOT:s1, DP:dp1 -- USAGE - ATOMIC: 92% TOTAL: 93%
TOP SESSIONS:SESS-ID PCT GRP-ID COUNT
6 92% 1 156 7 1732
SESSION DETAILS SESS-
ID PROTO SZONESRC SPORT DST DPORT IGR-IF EGR-
IF APP
6 6 trust 192.168.2.35 55653 10.1.8.89 80 ethernet1/21
ethernet1/22 undecided
The command displays a maximum of the top five sessions that each use 2% or more of the on-
chip packet descriptor.
The sample output above indicates that Session 6 is using 92% of the on-chip packet
descriptor with TCP packets (protocol 6) coming from source IP address 192.168.2.35.
• SESS-ID—Indicates the global session ID that is used in all other show session
commands. The global session ID is unique within the firewall.
• GRP-ID—Indicates an internal stage of processing packets.
• COUNT—Indicates how many packets are in that GRP-ID for that session.
• APP—Indicates the App-ID extracted from the Session informaon, which can help you
determine whether the traffic is legimate. For example, if packets use a common TCP or
UDP port but the CLI output indicates an APP of undecided, the packets are possibly
aack traffic. The APP is undecided when Applicaon IP Decoders cannot get enough
informaon to determine the applicaon. An APP of unknown indicates that Applicaon
IP Decoders cannot determine the applicaon; a session of unknown APP that uses a high
percentage of the on-chip packet descriptor is also suspicious.
To restrict the display output:
On a PA-7000 Series model only, you can limit output to a slot, a dataplane, or both. For
example:
admin@PA-7050> show running resource-monitor ingress-backlogs slot

s1
admin@PA-7050> show running resource-monitor ingress-backlogs slot
s1 dp dp1
On PA-5200 Series and PA-7000 Series models only, you can limit output to a dataplane. For
example:
admin@PA-5260> show running resource-monitor ingress-backlogs dp

dp1
STEP 2 | Use the command output to determine whether the source at the source IP address using a
high percentage of the on-chip packet descriptor is sending legimate or aack traffic.
In the sample output above, a single-session aack is likely occurring. A single session (Session
ID 6) is using 92% of the on-chip packet descriptor for Slot 1, DP 1, and the applicaon at that
point is undecided.
• If you determine a single user is sending an aack and the traffic is not offloaded, you can
End a Single Session DoS Aack. At a minimum, you can Configure DoS Protecon Against
Flooding of New Sessions.
• On a hardware model that has a field-programmable gate array (FPGA), the firewall offloads
traffic to the FPGA when possible to increase performance. If the traffic is offloaded to
hardware, clearing the session does not help because then it is the soware that must
handle the barrage of packets. You should instead Discard a Session Without a Commit.
To see whether a session is offloaded or not, use the show session id <session-id>
operaonal command in the CLI as shown in the following example. The layer7processing
value indicates completed for sessions offloaded or enabled for sessions not offloaded.
If the show session id <session-id> command output shows informaon similar to

the following, the output implies that the session has not yet been installed on the PAN-OS
firewall. One reason why this can occur is because the traffic is denied due to a configured
Security policy rule.
> show session id xxxxxxxxxx
Session xxxxxxxxxx
Bad Key: c2s: ‘c2s’
Bad Key: s2c: ‘s2c’
index(local): : yyyyyyy
Discard a Session Without a Commit

Perform this task to permanently discard a session, such as a session that is overloading the packet
buffer or on-chip packet descriptor. No commit is required; the session is discarded immediately
aer execung the command. The commands apply to both offloaded and non-offloaded sessions.
STEP 1 | In the CLI, execute the following operaonal command on any hardware model:
admin@PA-7050> request session-discard [timeout <seconds>]

[reason <reason-string>] id <session-id>
The default meout is 3,600 seconds.
STEP 2 | Verify that sessions have been discarded.
admin@PA-7050> show session all filter state discard
Cerficaons
The following topics describe how to configure Palo Alto Networks® firewalls and
appliances to support the Common Criteria and the Federal Informaon Processing
Standard 140-2 (FIPS 140-2), which are security cerficaons that ensure a standard
set of security assurances and funconalies. These cerficaons are oen required
by civilian U.S. government agencies and government contractors.
For details about product cerficaons and third-party validaon, refer to the
Cerficaons page.
> Enable FIPS and Common Criteria Support

> FIPS-CC Security Funcons
> Scrub Swap Memory on a Firewall or Appliances in FIPS-CC Mode
1493
Cerficaons
Enable FIPS and Common Criteria Support

Use the following procedures to enable FIPS-CC mode on a soware version that supports
Common Criteria and the Federal Informaon Processing Standards 140-2 (FIPS 140-2). When
you enable FIPS-CC mode, all FIPS and CC funconality is included.
FIPS-CC mode is supported on all Palo Alto Networks next-generaon firewalls and appliances
—including VM-Series firewalls. To enable FIPS-CC mode, first boot the firewall into the
Maintenance Recovery Tool (MRT) and then change the operaonal mode from normal mode to
FIPS-CC mode. The procedure to change the operaonal mode is the same for all firewalls and
appliances but the procedure to access the MRT varies.
When you enable FIPS-CC mode, the firewall will reset to the factory default sengs; all
configuraon will be removed.
• Access the Maintenance Recovery Tool (MRT)

• Change the Operaonal Mode to FIPS-CC Mode
Access the Maintenance Recovery Tool (MRT)

The Maintenance Recovery Tool (MRT) enables you to perform several tasks on Palo Alto
Networks firewalls and appliances. For example, you can revert the firewall or appliance to factory
default sengs, revert PAN-OS or a content update to a previous version, run diagnoscs on the
file system, gather system informaon, and extract logs. Addionally, you can use the MRT to
Change the Operaonal Mode to FIPS-CC Mode or from FIPS-CC mode to normal mode.
The following procedures describe how to access the Maintenance Recovery Tool (MRT) on
various Palo Alto Networks products.
Cerficaons
Access the MRT on hardware firewalls and appliances (such as PA-220 firewalls, PA-7000
Series firewalls, or M-Series appliances).
1. Establish a serial console session to the firewall or appliance.
1. Connect a serial cable from the serial port on your computer to the console port on
the firewall or appliance.
If your computer does not have a 9-pin serial port but does have a USB port,
use a serial-to-USB converter to establish the connecon. If the firewall has a
micro USB console port, connect to the port using a standard Type-A USB
to micro USB cable.
2. Open terminal emulaon soware on your computer and set to 9600-8-N-1 and then
connect to the appropriate COM port.
On a Windows system, you can go to the Control Panel to view the COM port
sengs for Device and Printers to determine which COM port is assigned to
the console.
3. Log in using an administrator account. (The default username/password is admin/
admin.)
2. Enter the following CLI command and press y to confirm:
3. Aer the firewall or appliance boots to the MRT welcome screen (in approximately 2 to 3
minutes), press Enter on Continue to access the MRT main menu.
You can also access the MRT by reboong the firewall or appliance and entering
maint at the maintenance mode prompt. A direct serial console connecon is
required.
Aer the firewall or appliance boots into the MRT, you can access the MRT remotely by
establishing an SSH connecon to the management (MGT) interface IP address. At the
login prompt, enter maint as the username and the firewall or appliance serial number
as the password.
Cerficaons
Access the MRT on VM-Series firewalls deployed in a private cloud (such as on a VMware ESXi
or KVM hypervisor).
1. Establish an SSH session to the management IP address of the firewall and log in using an
administrator account.
It will take approximately 2 to 3 minutes for the firewall to boot to the MRT.
During this me, your SSH session will disconnect.
3. Aer the firewall boots to the MRT welcome screen, log in based on the operaonal
mode:
• Normal mode—Establish an SSH session to the management IP address of the firewall
and log in using maint as the username and the firewall or appliance serial number as
the password.
• FIPS-CC mode—Access the virtual machine management ulity (such as the vSphere
client) and connect to the virtual machine console.
4. From the MRT welcome screen, press Enter on Continue to access the MRT main
menu.
Access the MRT on VM-Series firewalls deployed in the public cloud (such as AWS or Azure).
1. Establish an SSH session to the management IP address of the firewall and log in using an
administrator account.
It will take approximately 2 to 3 minutes for the firewall to boot to the MRT.
During this me, your SSH session will disconnect.
3. Aer the firewall boots to the MRT welcome screen, log in based on the virtual machine
type:
• AWS—Log in as ec2-user and select the SSH public key associated with the virtual
machine when you deployed it.
• Azure—Enter the credenals you created when you deployed the VM-Series firewall.
• GCP—Log in as gcp-user and select the SSH public key associated with the virtual
machine when you deployed it.
4. From the MRT welcome screen, press Enter on Continue to access the MRT main
menu.
Change the Operaonal Mode to FIPS-CC Mode

The following procedure describes how to change the operaonal mode of a Palo Alto Networks
product from normal mode to FIPS-CC mode.
Cerficaons
When the appliance is in FIPS-CC mode, you will not be able to configure any sengs via
the console, including the management interface sengs. Before enabling FIPS-CC mode,
make sure that your network is set up to allow access to the management interface via
SSH or the web interface. The management interface will default to a stac address of
192.168.1.1 if using a PA-Series firewall or to an address retrieved via DHCP if it is a VM-
Series firewall. The WildFire, virtual Panorama, and M-series Panorama appliances will
default to a stac address of 192.168.1.1.
Once FIPS-CC mode is enabled, all configuraons and sengs are erased. If an
administrator has configuraons or sengs they would like to reuse aer FIPS-CC mode is
enabled, the administrator can save and export the configuraon before changing to FIPS-
CC mode. The configuraon can then be imported once the operaonal mode change is
complete. The imported configuraon must be edited per the FIPS-CC Security Funcons
or else the import process will fail.
Keys, passwords, and other crical security parameters cannot be shared across modes.
If you change the operaonal mode of a firewall or Dedicated Log Collector managed by
a Panorama management server to FIPS-CC mode, you must also change the operaonal
mode of Panorama to FIPS-CC mode. This is required to secure password hashes for local
admin passwords pushed from Panorama.
STEP 1 | (Public Cloud VM-Series firewalls or Public Cloud Panorama Virtual Appliances only) Create
an SSH key and log in to the firewall or Panorama.
On some public cloud plaorms, such as Microso Azure, you must have an SSH key to
prevent an authencaon failure aer changing to FIPS-CC mode. Verify that you have
deployed the firewall to authencate using the SSH key. Although on Azure you can deploy
the VM-Series firewall or Panorama and log in using a username and password, you will be
unable to authencate using the username and password aer changing the operaonal mode
to FIPS-CC. Aer reseng to FIPS-CC mode, you must use the SSH key to log in and can then
configure a username and password that you can use for subsequently logging in to the firewall
web interface.
STEP 2 | Connect to the firewall or appliance and Access the Maintenance Recovery Tool (MRT).
STEP 3 | Select Set FIPS-CC Mode from the menu.
STEP 4 | Select Enable FIPS-CC Mode. The mode change operaon begins a full factory reset and
a status indicator shows the progress. Aer the mode change is complete, the status shows
Success.
All configuraons and sengs are erased and cannot be retrieved once the mode
change is complete.
Cerficaons
STEP 5 | When prompted, select Reboot.
If you change the operaonal mode on a VM-Series firewall deployed in the public
cloud and you lose your SSH connecon to the MRT before you are able to Reboot,
you must wait 10-15 minutes for the mode change to complete, log back into the MRT,
and then reboot the firewall to complete the operaon. Aer reseng to FIPS-CC
mode, on some virtual form factors (Panorama or VM-Series) you can only log in using
the SSH key, and if you have not set up authencaon using an SSH key, you can no
longer log in to the firewall on reboot.
Aer you switch to FIPS-CC mode, you see the following status: FIPS-CC mode enabled
successfully.
In addion, the following changes are in effect:
• FIPS-CC displays at all mes in the status bar at the boom of the web interface.
• The default administrator login credenals change to admin/paloalto.
See FIPS-CC Security Funcons for details on the security funcons that are enforced in FIPS-
CC mode.
Cerficaons
FIPS-CC Security Funcons

When FIPS-CC mode is enabled, the following security funcons are enforced on all firewalls and
appliances:
To log in, the browser must be TLS 1.1 (or later) compable; on a WF-500 appliance, you
manage the appliance only through the CLI and you must connect using an SSHv2-compable
client applicaon.
All passwords must be at least eight characters.
You must ensure that Failed Aempts and Lockout Time (min) are greater than 0 in
authencaon sengs. If an administrator reaches the Failed Aempts threshold, the
administrator is locked out for the duraon defined in the Lockout Time (min) field.
You must ensure that the Idle Timeout is greater than 0 in authencaon sengs. If a login
session is idle for more than the specified me, the administrator is automacally logged out.
You can configure the Absolute Session Length to set the maximum length of me in minutes
that a user can be logged in. The minimum length that can be set is 60 minutes. You will receive
a session terminaon warning 5 minutes before meout. This feature cannot be disabled in
FIPS-CC mode and defaults at a session of 30 days.
You can configure the Max No. of Sessions to set how many users can be concurrently logged
in to the same administrator account.
The firewall or appliance automacally determines the appropriate level of self-tesng and
enforces the appropriate level of strength in encrypon algorithms and cipher suites.
Unapproved FIPS-CC algorithms are not decrypted—they are ignored during decrypon.
MS-CHAPv2 is not compable with FIPS-CC mode. It is recommended to use RADIUS with
TLS.
When configuring an IPSec VPN, the administrator must select a cipher suite opon presented
to them during the IPSec setup.
(For Panorama and WildFire only) IPSec can be enabled on the management interface to
protect protocols such as NTP, RADIUS, TACACS, and DNS.
Self-generated and imported cerficates must contain public keys that are either RSA 2,048
bits (or more) or ECDSA 256 bits (or more); you must also use a digest of SHA256 or greater.
You cannot use a hardware security module (HSM) to store the private ECDSA keys
used for SSL Forward Proxy or SSL Inbound Inspecon.
Telnet, TFTP, and HTTP management connecons are not available.
You must enable encrypon for the HA1 control link. You must set automac rekeying
parameters; you must set the data parameter to a value no greater than 1000 MB (you cannot
let it default) and you must set a me interval (you cannot leave it disabled).
The serial console port in FIPS-CC mode funcons as a limited status output port only; CLI
access is not available.
The serial console port on hardware and private-cloud VM-Series firewalls booted into the
MRT provides interacve access to the MRT.
Cerficaons
Interacve console access is not supported in the hypervisor environment private-cloud VM-
Series firewalls booted into the MRT; you can access the MRT only using SSH.
You must manually configure a new master key before the old master key expires; Auto Renew
Master Key is not supported in FIPS-CC mode.
If the master key expires, the firewall or Panorama automacally reboots in Maintenance mode.
You must then Reset the Firewall to Factory Default Sengs.
Zero Touch Provisioning (ZTP) mode is disabled on the PA-5450 Firewall and the PA-400 Series
Firewalls if FIPS-CC mode is enabled.
(Panorama managed firewalls) A firewall in FIPS-CC mode must be managed by a Panorama™
management server in FIPS-CC mode.
Management of a firewall in FIPS-CC mode is not supported for a Panorama not in FIPS-CC
mode.
Cerficaons
Scrub the Swap Memory on Firewalls or Appliances

Running in FIPS-CC Mode
You should ensure that sensive informaon is removed from the swap memory before you
decommission a firewall or appliance (in FIPS-CC mode) or before you send it in for repair. Use this
procedure to remove all cryptographic security parameter (CSP) informaon from swap parons.
If you send a firewall that is managed by Panorama in for repair, see Before Starng RMA
Firewall Replacement.
STEP 1 | Open an SSH management session to the firewall or appliance.
STEP 2 | Run the following operaonal command:

request [restart | shutdown] system with-swap-scrub [dod | nnsa]
For example, to shut down the firewall or appliance and perform a Department of Defense
(DoD) scrub, run the following command:
request shutdown system with-swap-scrub dod
STEP 3 | Press Y at the warning prompt to start the scrub.
STEP 4 | Verify that the scrub completed successfully. View the System log and filter on the word
swap. The System log indicates the scrub status for each swap paron (either one or two
parons depending on the model) and also displays a log entry that indicates the overall
status of the scrub. If the scrub completed successfully on all swap parons, the System log
shows Swap space scrub was successful.
If the scrub failed on one or more swap parons, the System log shows Swap space scrub
was unsuccessful. The following screen capture shows the log results for a firewall that
has two parons.
To view the scrub logs using the CLI, run the show log system | match swap
command.
If you iniate the scrub using the shutdown command, the firewall or appliance will
power off aer the scrub completes. Before you can power on the firewall or appliance,
you must first disconnect and reconnect the power source.
Cerficaons

Pan Os Admin 10.1

Uploaded by

Copyright:

Available Formats

Pan Os Admin 10.1

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 Admin 10.1

Uploaded by

Copyright:

Available Formats

PAN-OS® Administrator’s Guide

About the Documentaon

Revert Firewall Conﬁguraon Changes.................................................................... 94

Device Telemetry........................................................................................... 209

Mul-Factor Authencaon..................................................................................... 218

Cerﬁcate Management.............................................................................. 293

Configure Revocaon Status Verificaon of Cerficates Used for SSL/TLS

Threat Map Report......................................................................................................475

Conﬁgure Email Alerts........................................................................................................... 540

Share User-ID Mappings Across Virtual Systems................................................ 764

Commit Failure Due to Cloud Content Rollback..................................................843

Conﬁgure WildFire Inline ML................................................................................... 927

Create a Decrypon Proﬁle....................................................................................1001

Conﬁgure URL Filtering...................................................................................................... 1111

Quality of Service....................................................................................... 1193

Large Scale VPN (LSVPN)......................................................................... 1273

LSVPN Overview.................................................................................................................. 1274

Use an External Dynamic List in Policy.......................................................................... 1353

Virtual Systems............................................................................................ 1423

Inter-VSYS Traﬃc That Remains Within the Firewall....................................... 1429

Zone Protecon and DoS Protecon.....................................................1449

Enable FIPS and Common Criteria Support...................................................................1494

> Integrate the Firewall into Your Management Network

Integrate the Firewall into Your Management Network

Determine Your Management Strategy

Perform Inial Conﬁguraon

STEP 2 | Gather the required informaon from your network administrator.

STEP 3 | Connect your computer to the ﬁrewall.

STEP 4 | When prompted, log in to the ﬁrewall.

STEP 5 | Set a secure password for the admin account.

1. Select Device > Administrators.

4. Click OK to save your sengs.

STEP 6 | Conﬁgure the MGT interface.

To prevent unauthorized access to the management interface, it is a an

STEP 7 | Conﬁgure DNS, update server, and proxy server sengs.

1. Select Device > Setup > Services.

STEP 8 | Conﬁgure date and me (NTP) sengs.

3. (Oponal) Enter a Secondary NTP Server address.

STEP 9 | (Oponal) Conﬁgure general ﬁrewall sengs as needed.

STEP 10 | Commit your changes.

STEP 11 | Connect the ﬁrewall to your network.

STEP 12 | Open an SSH management session to the ﬁrewall.

Device not found on this update server

Set Up Network Access for External Services

STEP 2 | Log in to the web interface.

8. To save the interface conﬁguraon, click OK.

STEP 5 | Conﬁgure the Service Routes.

3. Click OK to save the sengs.

STEP 7 | Create a NAT policy rule.

Device not found on this update server

Register the Firewall

Create a New Support Account and Register a Firewall

STEP 2 | Click Create my account.

STEP 5 | Complete the registraon form.

STEP 1 | Log in to the ﬁrewall web interface.

STEP 2 | Locate your serial number and copy it to the clipboard.

STEP 4 | Register the ﬁrewall.

(Oponal) Perform Day 1 Conﬁguraon

STEP 4 | Fill out all ﬁelds under Logging.