Official CHFI Study Guide
Official CHFI Study Guide
Administrator’s
Guide
Version 7.1
Contact Information
Corporate Headquarters:
Palo Alto Networks
3000 Tannery Way
Santa Clara, CA 95054
www.paloaltonetworks.com/company/contact-support
This guide takes you through the configuration and maintenance of your Palo Alto Networks next-generation
firewall. For additional information, refer to the following resources:
For information on how to configure other components in the Palo Alto Networks Next-Generation Security
Platform, go to the Technical Documentation portal: https://www.paloaltonetworks.com/documentation or
search the documentation.
For access to the knowledge base and community forums, refer to https://live.paloaltonetworks.com.
For contacting support, for information on support programs, to manage your account or devices, or to open a
support case, refer to https://www.paloaltonetworks.com/support/tabs/overview.html.
For the most current PAN-OS and Panorama 7.1 release notes, go to
https://www.paloaltonetworks.com/documentation/71/pan-os/pan-os-release-notes.html.
To provide feedback on the documentation, please write to us at: [email protected].
Getting Started . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Integrate the Firewall into Your Management Network. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Determine Your Management Strategy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Perform Initial Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Set Up Network Access for External Services. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
Register the Firewall . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
Activate Licenses and Subscriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
Install Content and Software Updates. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Segment Your Network Using Interfaces and Zones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
Network Segmentation for a Reduced Attack Surface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
Configure Interfaces and Zones. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
Set Up a Basic Security Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
Assess Network Traffic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
Enable Basic Threat Prevention Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
Enable Basic WildFire Forwarding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
Scan Traffic for Threats. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
Control Access to Web Content . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
Enable AutoFocus Threat Intelligence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
Best Practices for Completing the Firewall Deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
Firewall Administration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
Management Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
Use the Web Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
Launch the Web Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
Configure Banners, Message of the Day, and Logos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
Use the Administrator Login Activity Indicators to Detect Account Misuse . . . . . . . . . . . . 64
Manage and Monitor Administrative Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
Commit, Validate, and Preview Firewall Configuration Changes. . . . . . . . . . . . . . . . . . . . . . 66
Use Global Find to Search the Firewall or Panorama Management Server . . . . . . . . . . . . . 68
Manage Locks for Restricting Configuration Changes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
Manage Configuration Backups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
Back Up a Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
Restore a Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
Manage Firewall Administrators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
Administrative Roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
Administrative Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
Configure Administrative Accounts and Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
Configure an Administrative Account. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
Configure Kerberos SSO and External or Local Authentication for Administrators . . . . . . 77
Configure Certificate-Based Administrator Authentication to the Web Interface . . . . . . . 78
Configure SSH Key-Based Administrator Authentication to the CLI . . . . . . . . . . . . . . . . . . 80
Configure RADIUS Vendor-Specific Attributes for Administrator Authentication . . . . . . . 80
Authentication. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141
Configure an Authentication Profile and Sequence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .142
Configure Kerberos Single Sign-On . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .145
Configure Local Database Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .146
Configure External Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .147
Configure Authentication Server Profiles. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .147
Configure a RADIUS Server Profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .147
Set CHAP or PAP Authentication for RADIUS Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . .148
RADIUS Vendor-Specific Attributes Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .149
Configure a TACACS+ Server Profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .149
Configure an LDAP Server Profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .150
Configure a Kerberos Server Profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .152
Enable External Authentication for Users and Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . .153
Test Authentication Server Connectivity. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .154
Run the Test Authentication Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .154
Test a Local Database Authentication Profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .155
Test a RADIUS Authentication Profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .156
Test a TACACS+ Authentication Profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .158
Test an LDAP Authentication Profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .159
Test a Kerberos Authentication Profile. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .160
Troubleshoot Authentication Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .162
Configure Revocation Status Verification of Certificates Used for SSL/TLS Decryption 170
Configure the Master Key . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172
Obtain Certificates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173
Create a Self-Signed Root CA Certificate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173
Generate a Certificate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174
Import a Certificate and Private Key. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175
Obtain a Certificate from an External CA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176
Export a Certificate and Private Key . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178
Configure a Certificate Profile. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179
Configure an SSL/TLS Service Profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181
Replace the Certificate for Inbound Management Traffic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182
Configure the Key Size for SSL Forward Proxy Server Certificates . . . . . . . . . . . . . . . . . . . . . . 183
Revoke and Renew Certificates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184
Revoke a Certificate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184
Renew a Certificate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184
Secure Keys with a Hardware Security Module. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185
Set up Connectivity with an HSM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185
Encrypt a Master Key Using an HSM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190
Store Private Keys on an HSM. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192
Manage the HSM Deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193
Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255
Use the Dashboard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .256
Use the Application Command Center . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .257
ACC—First Look . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .258
ACC Tabs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .259
ACC Widgets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .260
Widget Descriptions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .261
ACC Filters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .265
Interact with the ACC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .266
Use Case: ACC—Path of Information Discovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .269
App Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .276
Summary Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .277
Change Monitor Report. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .278
Threat Monitor Report. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .279
Threat Map Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .280
Network Monitor Report. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .281
Traffic Map Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .282
Use the Automated Correlation Engine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .283
Automated Correlation Engine Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .283
View the Correlated Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .284
Interpret Correlated Events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .285
Use the Compromised Hosts Widget in the ACC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .287
Take Packet Captures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .288
Types of Packet Captures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .288
Disable Hardware Offload. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .289
Take a Custom Packet Capture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .290
Take a Threat Packet Capture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .294
Take an Application Packet Capture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .295
Take a Packet Capture on the Management Interface. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .298
Monitor Applications and Threats. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .300
Monitor and Manage Logs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .301
Log Types and Severity Levels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .301
User-ID . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .377
User-ID Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 378
User-ID Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 380
Group Mapping. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 380
User Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 380
Enable User-ID. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 385
Map Users to Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 389
Map IP Addresses to Users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 392
Create a Dedicated Service Account for the User-ID Agent . . . . . . . . . . . . . . . . . . . . . . . . 393
Configure User Mapping Using the Windows User-ID Agent . . . . . . . . . . . . . . . . . . . . . . . 396
Configure User Mapping Using the PAN-OS Integrated User-ID Agent . . . . . . . . . . . . . . 403
Configure User-ID to Receive User Mappings from a Syslog Sender . . . . . . . . . . . . . . . . . 405
Map IP Addresses to Usernames Using Captive Portal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 416
Configure User Mapping for Terminal Server Users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 422
App-ID . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 445
App-ID Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .446
Manage Custom or Unknown Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .447
Manage New App-IDs Introduced in Content Releases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .448
Review New App-IDs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .448
Review New App-IDs Since Last Content Version . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .449
Review New App-ID Impact on Existing Policy Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .450
Disable or Enable App-IDs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .451
Prepare Policy Updates for Pending App-IDs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .452
Use Application Objects in Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .454
Create an Application Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .454
Create an Application Filter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .455
Create a Custom Application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .456
Applications with Implicit Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .461
Application Level Gateways . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .464
Disable the SIP Application-level Gateway (ALG). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .465
Identify Sessions That Use an Excessive Percentage of the Packet Buffer . . . . . . . . . . . . 508
Discard a Session Without a Commit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 511
Content Delivery Network Infrastructure for Dynamic Updates . . . . . . . . . . . . . . . . . . . . . . . . 512
Threat Prevention Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 513
Decryption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .515
Decryption Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 516
Decryption Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 517
Keys and Certificates for Decryption Policies. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 517
SSL Forward Proxy. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 518
SSL Inbound Inspection. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 519
SSH Proxy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 520
Decryption Exceptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 521
Decryption Mirroring. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 522
Define Traffic to Decrypt. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 523
Create a Decryption Profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 523
Create a Decryption Policy Rule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 525
Configure SSL Forward Proxy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 527
Configure SSL Inbound Inspection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 531
Configure SSH Proxy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 533
Configure Decryption Exceptions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 534
Exclude Traffic from Decryption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 534
Exclude a Server from Decryption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 535
Enable Users to Opt Out of SSL Decryption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 536
Configure Decryption Port Mirroring. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 538
Temporarily Disable SSL Decryption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 540
VPNs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 627
Networking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .707
Interface Deployments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 708
Virtual Wire Deployments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 708
NAT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 796
NAT Policy Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 796
Source NAT and Destination NAT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 799
NAT Rule Capacities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 800
Dynamic IP and Port NAT Oversubscription. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 801
Dataplane NAT Memory Statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 803
Configure NAT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 804
NAT Configuration Examples. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 811
NPTv6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 819
NPTv6 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 819
How NPTv6 Works . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 821
NDP Proxy. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 822
NPTv6 and NDP Proxy Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 824
Create an NPTv6 Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 825
NAT64 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 828
NAT64 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 828
IPv4-Embedded IPv6 Address . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 829
DNS64 Server. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 829
Path MTU Discovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 829
Configure NAT64 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 830
ECMP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 840
ECMP Load-Balancing Algorithms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 840
ECMP Platform, Interface, and IP Routing Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 841
Configure ECMP on a Virtual Router . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 842
Enable ECMP for Multiple BGP Autonomous Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 843
Verify ECMP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 845
LLDP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 846
LLDP Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 846
Supported TLVs in LLDP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 847
LLDP Syslog Messages and SNMP Traps. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 848
Configure LLDP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 849
View LLDP Settings and Status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 851
Clear LLDP Statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 852
BFD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 853
BFD Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 853
Configure BFD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 856
Reference: BFD Details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 864
Policy. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .867
Policy Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 868
Security Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 869
Components of a Security Policy Rule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 869
Security Policy Actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 872
Create a Security Policy Rule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 872
Policy Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 875
Security Profiles. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 876
Antivirus Profiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 877
Anti-Spyware Profiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 877
Certifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .973
Enable FIPS and Common Criteria Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 974
FIPS-CC Security Functions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 975
All Palo Alto Networks firewalls provide an out-of-band management port (MGT) that you can use to
perform the firewall administration functions. By using the MGT port, you separate the management
functions of the firewall from the data processing functions, safeguarding access to the firewall and
enhancing performance. When using the web interface, you must perform all initial configuration 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 updating the threat and application 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.
The following topics describe how to perform the initial configuration steps that are necessary to integrate
a new firewall into the management network and deploy it in a basic security configuration.
Determine Your Management Strategy
Perform Initial Configuration
Set Up Network Access for External Services
The following topics describe how to integrate a single Palo Alto Networks next-generation
firewall into your network. However, for redundancy, consider deploying a pair of firewalls in a
High Availability configuration.
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 administrative overhead in managing configuration, policies, software and
dynamic content updates. Using device groups and templates on Panorama, you can effectively manage
firewall-specific configuration 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
Application Command Center (ACC) on Panorama provides a single glass pane for unified reporting
across all the firewalls, allowing you to centrally analyze, investigate and report on network traffic,
security incidents and administrative modifications.
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 Initial Configuration and verify that the firewall
can establish a connection to Panorama. From that point on you can use Panorama to configure your firewall
centrally.
By default, the firewall has an IP address of 192.168.1.1 and a username/password of admin/admin. For
security reasons, you must change these settings before continuing with other firewall configuration tasks.
You must perform these initial configuration 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 connection to the console port on
the firewall.
Set Up Network Access to the Firewall
Step 1 Gather the required information from • IP address for MGT port
your network administrator. • Netmask
• Default gateway
• DNS server address
Step 2 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 emulation software
(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-500 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. Note that 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, in order to
access this URL.
Step 3 When prompted, log in to the firewall. You must log in using the default username and password
(admin/admin). The firewall will begin to initialize.
Step 4 Configure the MGT interface. 1. Select Device > Setup > Management and edit the
Management Interface Settings.
2. Configure the address settings for the MGT interface using
one of the following methods:
• To configure static IP address settings for the MGT
interface, set the IP Type to Static and enter the IP
Address, Netmask, and Default Gateway.
• To dynamically configure the MGT interface address
settings, set the IP Type to DHCP. 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 best practice to Add the Permitted IP
Addresses from which an administrator can access the
MGT interface.
3. Set the Speed to auto-negotiate.
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 credentials.
5. Click OK.
Set Up Network Access to the Firewall (Continued)
Step 5 Configure DNS, update server, and 1. Select Device > Setup > Services.
proxy server settings. • For multi-virtual system platforms, select Global and edit
You must manually configure at the Services section.
least one DNS server on the • For single virtual system platforms, edit the Services
firewall or it will not be able to section.
resolve hostnames; it will not use
2. On the Services tab, for DNS, click one of the following:
DNS server settings from
another source, such as an ISP. • 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.
Step 6 Configure date and time (NTP) settings. 1. Select Device > Setup > Services.
• For multi-virtual system platforms, select Global and edit
the Services section.
• For single virtual system platforms, edit the Services
section.
2. On the NTP tab, to use the virtual cluster of time 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. (Optional) Enter a Secondary NTP Server address.
4. (Optional) To authenticate time updates from the NTP
server(s), for Authentication Type, select one of the following
for each server:
• None—(Default) Disables NTP authentication.
• Symmetric Key—Firewall uses symmetric key exchange
(shared secrets) to authenticate time updates.
– Key ID—Enter the Key ID (1-65534).
– Algorithm—Select the algorithm to use in NTP
authentication (MD5 or SHA1).
• Autokey—Firewall uses autokey (public key cryptography)
to authenticate time updates.
5. Click OK.
Set Up Network Access to the Firewall (Continued)
Step 7 (Optional) Configure general firewall 1. Select Device > Setup > Management and edit the General
settings as needed. Settings.
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 authorization to access the firewall
management functions.
As a best practice, avoid using welcoming verbiage.
Additionally, you should ask your legal department to
review the banner message to ensure it adequately
warns that unauthorized access is prohibited.
4. Enter the Latitude and Longitude to enable accurate
placement of the firewall on the world map.
5. Click OK.
Step 8 Set a secure password for the admin 1. Select Device > Administrators.
account. 2. Select the admin role.
3. Enter the current default password and the new password.
4. Click OK to save your settings.
Step 9 Commit your changes. Click Commit at the top right of the web interface. The firewall can
When the configuration changes take up to 90 seconds to save your changes.
are saved, you lose connectivity
to the web interface because the
IP address has changed.
Step 10 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-negotiation.
Step 11 Open an SSH management session to Using a terminal emulation software, such as PuTTY, launch an SSH
the firewall. session to the firewall using the new IP address you assigned to it.
Set Up Network Access to the Firewall (Continued)
Step 12 Verify network access to external 1. Use the ping utility to verify network connectivity to the Palo
services required for firewall Alto Networks Update server as shown in the following
management, such as the Palo Alto example. Verify that DNS resolution occurs and the response
Networks Update Server. includes the IP address for the Update server; the update
You can do this in one of the following server does not respond to a ping request.
ways: admin@PA-200 > ping host
• If you do not want to allow external updates.paloaltonetworks.com
network access to the MGT interface, PING updates.paloaltonetworks.com (10.101.16.13)
56(84) bytes of data.
you will need to set up a data port to
From 192.168.1.1 icmp_seq=1 Destination Host
retrieve required service updates.
Unreachable
Continue to Set Up Network Access
From 192.168.1.1 icmp_seq=2 Destination Host
for External Services. Unreachable
• If you do plan to allow external From 192.168.1.1 icmp_seq=3 Destination Host
network access to the MGT interface, Unreachable
verify that you have connectivity and From 192.168.1.1 icmp_seq=4 Destination Host
then proceed to Register the Firewall Unreachable
and Activate Licenses and After verifying DNS resolution, press Ctrl+C to stop the
Subscriptions. ping request.
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.
This task requires familiarity with firewall interfaces, zones, and policies. For more information on
these topics, see Configure Interfaces and Zones and Set Up a Basic Security Policy.
Set Up a Data Port for Access to External Services
Step 1 Decide which port you want to use for The interface you use must have a static IP address.
access to external services and connect
it to your switch or router port.
Step 2 Log in to the web interface. Using a secure connection (https) from your web browser, log in
using the new IP address and password you assigned during initial
configuration (https://<IP address>). You will see a certificate
warning; that is okay. Continue to the web page.
Step 3 (Optional) The firewall comes You must delete the configuration in the following order:
preconfigured with a default virtual wire 1. To delete the default security policy, select Policies >
interface between ports Ethernet 1/1 Security, select the rule, and click Delete.
and Ethernet 1/2 (and a corresponding
default security policy and zones). If you 2. To delete the default virtual wire, select Network > Virtual
do not plan to use this virtual wire Wires, select the virtual wire and click Delete.
configuration, you must manually delete 3. To delete the default trust and untrust zones, select Network
the configuration to prevent it from > Zones, select each zone and click Delete.
interfering with other interface settings
4. To delete the interface configurations, select Network >
you define.
Interfaces and then select each interface (ethernet1/1 and
ethernet1/2) and click Delete.
5. Commit the changes.
Set Up a Data Port for Access to External Services (Continued)
Step 4 Configure the interface you plan to use 1. Select Network > Interfaces and select the interface that
for external access to management corresponds to the port you cabled in Step 1.
services. 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 Static radio button, and click
Add in the IP section, and enter the IP address and network
mask to assign to the interface, for example
192.168.1.254/24. You must use a static 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.
These services provide management access to the
firewall, so only select the services that correspond to
the management activities you want to allow on this
interface. For example, if you plan to use the MGT
interface for firewall configuration tasks through the
web interface or CLI, you would not want to enable
HTTP, HTTPS, SSH, or Telnet so that you could
prevent unauthorized access through this interface
(and if you did allow those services, you should limit
access to a specific set of Permitted IP Addresses).
For details, see Use Interface Management Profiles to
Restrict Access.
8. To save the interface configuration, click OK.
Set Up a Data Port for Access to External Services (Continued)
Step 5 Configure the service routes. 1. Select Device > Setup > Services > Global and click Service
By default, the firewall uses the MGT Route Configuration.
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 For the purposes of activating your licenses and
routes. getting the most recent content and software updates,
This example shows how to set you will want to change the service route for DNS,
up global service routes. For Palo Alto Updates, URL Updates, WildFire, and
information on setting up AutoFocus.
network access to external 2. Click the Customize radio button, and select one of the
services on a virtual system basis following:
rather than a global basis, see
• For a predefined service, select IPv4 or IPv6 and click the
Per-Virtual System Service
link for the service. To limit the drop-down list for Source
Routes.
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 select
an IP address.
• To create a service route for a custom destination, select
Destination, and click Add. Enter a Destination IP address.
An incoming packet with a destination 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 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 settings.
4. Repeat steps 2-3 above for each service route you want to
modify.
5. Commit your changes.
Step 6 Configure an external-facing interface 1. Select Network > Interfaces and then select the
and an associated zone and then create a external-facing interface. Select Layer3 as the Interface Type,
security policy rule to allow the firewall Add the IP address (on the IPv4 or IPv6 tab), and create the
to send service requests from the associated Security Zone (on the Config tab), such as Internet.
internal zone to the external zone. This interface must have a static 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 practice when creating Security policy rules,
use application-based rules instead of port-based rules
to ensure that you are accurately identifying the
underlying application regardless of the port, protocol,
evasive tactics, or encryption in use. Always leave the
Service set to application-default. In this case, create
a security policy rule that allows access to the update
server (and other Palo Alto Networks services).
Set Up a Data Port for Access to External Services (Continued)
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
destination zone, Management to Internet in this case
(Original Packet tab), and define the source address
translation settings (Translated Packet tab) and then click OK.
2. Commit your changes.
Set Up a Data Port for Access to External Services (Continued)
Step 8 Verify that you have connectivity from 1. Use the ping utility to verify network connectivity to the Palo
the data port to the external services, Alto Networks Update server as shown in the following
including the default gateway, and the example. Verify that DNS resolution occurs and the response
Palo Alto Networks Update Server. includes the IP address for the Update server; the update
After you verify you have the required server does not respond to a ping request.
network connectivity, continue to admin@PA-200 > ping host
Register the Firewall and Activate updates.paloaltonetworks.com
Licenses and Subscriptions. PING updates.paloaltonetworks.com (10.101.16.13)
56(84) bytes of data.
From 192.168.1.1 icmp_seq=1 Destination Host
Unreachable
From 192.168.1.1 icmp_seq=2 Destination Host
Unreachable
From 192.168.1.1 icmp_seq=3 Destination Host
Unreachable
From 192.168.1.1 icmp_seq=4 Destination Host
Unreachable
After verifying DNS resolution, press Ctrl+C to stop the
ping request.
Before you can activate support and other licenses and subscriptions, you must first register the firewall.
If you are registering a VM-Series firewall, refer to the VM-Series Deployment Guide.
Register the Firewall
Step 1 Log in to the web interface. Using a secure connection (https) from your web browser, log in
using the new IP address and password you assigned during initial
configuration (https://<IP address>).
Step 2 Locate your serial number and copy it to On the Dashboard, locate your Serial Number in the General
the clipboard. Information section of the screen.
Step 3 Go to the Palo Alto Networks Customer In a new browser tab or window, go to
Support portal and log in. https://www.paloaltonetworks.com/support/tabs/overview.html.
Step 4 Register the firewall. If you already have a support account, log in and register the
You must have a support account hardware-based firewall as follows:
to register a firewall. If you do not 1. Select Assets > Devices.
yet have a support account, click
2. Click Register New Device.
the Register link on the support
login page and follow the 3. Select Register device using Serial Number or Authorization
instructions to get your account Code and click Submit.
set up and register the firewall. 4. Enter the firewall Serial Number (you can copy and paste it
from the firewall Dashboard).
5. (Optional) Enter the Device Name and Device Tag.
6. Provide information about where you plan to deploy the
firewall including the City, Postal Code, and Country.
7. Read the end-user license agreement (EULA) and then click
Agree and Submit.
Before you can start using your firewall to secure the traffic on your network, you must activate the licenses
for each of the services you purchased. Available licenses and subscriptions include the following:
Threat Prevention—Provides antivirus, anti-spyware, and vulnerability protection.
Decryption Mirroring—Provides the ability to create a copy of decrypted traffic from a firewall and send
it to a traffic collection tool that is capable of receiving raw packet captures—such as NetWitness or
Solera—for archiving and analysis.
URL Filtering—Allows you create security policy to enforce web access based on dynamic URL
categories. You must purchase and install a subscription for one of the supported URL filtering databases:
PAN-DB or BrightCloud. With PAN-DB, you can set up access to the PAN-DB public cloud or to the
PAN-DB private cloud. For more information about URL filtering, see Control Access to Web Content.
Virtual Systems—This license is required to enable support for multiple virtual systems on PA-2000 and
PA-3000 Series firewalls. In addition, 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-4000 Series, PA-5000
Series, and PA-7000 Series firewalls (the base number varies by platform). The PA-500, PA-200, and
VM-Series firewalls do not support virtual systems.
WildFire—Although basic WildFire support is included as part of the Threat Prevention license, the
WildFire subscription service provides enhanced services for organizations that require immediate
coverage for threats, frequent WildFire signature updates, advanced file type forwarding (APK, PDF,
Microsoft Office, and Java Applet), as well as the ability to upload files using the WildFire API. A WildFire
subscription is also required if your firewalls will be forwarding files to a WF-500 appliance.
GlobalProtect—Provides mobility solutions and/or large-scale VPN capabilities. By default, you can
deploy GlobalProtect portals and gateways (without HIP checks) without a license. If you want to use HIP
checks, you will also need gateway licenses (subscription) for each gateway.
AutoFocus—Provides a graphical analysis of firewall traffic logs and identifies potential risks to your
network using threat intelligence from the AutoFocus portal. With an active license, you can also open
an AutoFocus search based on logs recorded on the firewall.
Activate Licenses and Subscriptions
Step 1 Locate the activation codes for the When you purchased your subscriptions you should have received
licenses you purchased. an email from Palo Alto Networks customer service listing the
activation code associated with each subscription. If you cannot
locate this email, contact Customer Support to obtain your
activation codes before you proceed.
Step 2 Activate your Support license. 1. Log in to the web interface and then select Device > Support.
You will not be able to update your 2. Click Activate support using authorization code.
PAN-OS software if you do not have a
3. Enter your Authorization Code and then click OK.
valid Support license.
Activate Licenses and Subscriptions (Continued)
Step 3 Activate each license you purchased. Select Device > Licenses and then activate your licenses and
subscriptions in one of the following ways:
• Retrieve license keys from license server—Use this option if
you activated your license on the Customer Support portal.
• Activate feature using authorization code—Use this option to
enable purchased subscriptions using an authorization code for
licenses that have not been previously activated on the support
portal. When prompted, enter the Authorization Code and then
click OK.
• Manually upload license key—Use this option if your firewall
does not have connectivity to the Palo Alto Networks Customer
Support web site. 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 was successfully On the Device > Licenses page, verify that the license was
activated successfully activated. For example, after activating the WildFire
license, you should see that the license is valid:
Step 5 (WildFire subscriptions only) Perform a After activating a WildFire subscription, a commit is required for
commit to complete WildFire the firewall to begin forwarding advanced file types. You should
subscription activation. either:
• Commit any pending changes.
• Check that the WildFire Analysis profile rules include the
advanced file types that are now supported with the WildFire
subscription. If no change to any of the rules is required, make a
minor edit to a rule description and perform a commit.
To ensure that you are always protected from the latest threats (including those that have not yet been
discovered), you must ensure that you keep your firewalls up-to-date with the latest content and software
updates published by Palo Alto Networks.
The following content updates are available, depending on which subscriptions you have:
Antivirus—Includes new and updated antivirus signatures, including signatures discovered by the
WildFire cloud service. You must have a Threat Prevention subscription to get these updates. New
antivirus signatures are published daily.
Applications—Includes new and updated application signatures. This update does not require any
additional subscriptions, but it does require a valid maintenance/support contract. New application
updates are published weekly. To ensure that Application updates do not impact your existing policy,
review the policy impact of new application updates (see Manage New App-IDs Introduced in Content
Releases) and be sure to follow the Best Practices for Application and Threat Content Updates.
Applications and Threats—Includes new and updated application and threat signatures. This update is
available if you have a Threat Prevention subscription (and you get it instead of the Applications update).
New Applications and Threats updates are published weekly. To ensure that Application updates do not
impact your existing policy, review the policy impact of new application updates (see Manage New
App-IDs Introduced in Content Releases) and be sure to follow the Best Practices for Application and
Threat Content Updates.
WildFire—Provides near real-time malware and antivirus signatures created as a result of the analysis
done by the WildFire cloud service. To ensure that you get the latest signatures within a minute of
availability, the best practice is to set the update schedule for WildFire to one minute. If you do not have
a WildFire subscription, you must wait 24 to 48 hours for the signatures to roll into the antivirus update.
GlobalProtect Data File—Contains the vendor-specific information for defining and evaluating host
information profile (HIP) data returned by GlobalProtect agents. You must have a GlobalProtect gateway
license and create an update schedule in order to receive these updates.
BrightCloud URL Filtering—Provides updates to the BrightCloud URL Filtering database only. You must
have a BrightCloud subscription to get these updates. New BrightCloud URL database updates are
published daily. If you have a PAN-DB license, scheduled updates are not required as firewalls remain
in-sync with the servers automatically.
Install Content and Software Updates
Step 1 Ensure that the firewall has access to the 1. By default, the firewall accesses the Update Server at
update server. updates.paloaltonetworks.com so that the firewall
receives content updates from the server to which it is closest
in the CDN infrastructure. If the firewall has restricted access
to the Internet, set the update server address to use the
hostname staticupdates.paloaltonetworks.com or
the IP address 199.167.52.15 instead of dynamically
selecting a server from the CDN infrastructure.
2. (Optional) Click Verify Update Server Identity for an extra
level of validation to enable the firewall to check that the
server’s SSL certificate is signed by a trusted authority.
3. (Optional) If the firewall needs to use a proxy server to reach
Palo Alto Networks update services, in the Proxy Server
window, enter:
• Server—IP address or host name of the proxy server.
• Port—Port for the proxy server. Range: 1-65535.
• User—Username to access the server.
• Password—Password for the user to access the proxy
server. Re-enter the password at Confirm Password.
Install Content and Software Updates (Continued)
Step 2 Check for the latest content updates. Select Device > Dynamic Updates and click Check Now (located in
the lower left-hand corner of the window) to check for the latest
updates. The link in the Action column indicates whether an update
is available:
• Download—Indicates that a new update file is available. Click
the link to begin downloading the file directly to the firewall.
After successful download, the link in the Action column
changes from Download to Install.
Step 3 Install the content updates. Click the Install link in the Action column. When the installation
Installation can take up to 20 completes, a check mark displays in the Currently Installed
minutes on a PA-200, PA-500, or column.
PA-2000 Series firewall and up to
two minutes on a PA-3000
Series, PA-4000 Series, PA-5000
Series, PA-7000 Series, or
VM-Series firewall.
Install Content and Software Updates (Continued)
Step 4 Schedule each content update. 1. Set the schedule of each update type by clicking the None link.
Repeat this step for each update you
want to schedule.
Although you can manually install
content updates, the best 2. Specify how often you want the updates to occur by selecting
practice is to schedule content a value from the Recurrence drop-down. The available values
updates so that they get vary by content type (WildFire updates are available Every
downloaded and installed Minute, Every 15 Minutes, Every 30 minutes, or Every Hour
automatically. When scheduling whereas Applications and Threats updates can be scheduled
the updates, be sure to stagger for Daily or Weekly update and Antivirus updates can be
the update schedules because scheduled for Hourly, Daily, or Weekly).
the firewall can only download As new WildFire signatures are made available every
one update at a time. If you five minutes, set the firewall to retrieve WildFire
schedule the updates to updates Every Minute to get the latest signatures
download during the same time within a minute of availability.
interval, only the first download 3. Specify the Time and (or, minutes past the hour in the case of
will succeed. WildFire), if applicable depending on the Recurrence value
you selected, Day of the week that you want the updates to
occur.
4. Specify whether you want the system to Download Only or, as
a best practice, Download And Install the update.
5. Enter how long after a release to wait before performing a
content update in the Threshold (Hours) field. In rare
instances, errors in content updates may be found. For this
reason, you may want to delay installing new updates until
they have been released for a certain number of hours.
If you have mission critical applications that must be
100% available, set the threshold for Applications or
Applications and Threats updates to a minimum of 24
hours and follow the Best Practices for Application and Threat
Content Updates.
Install Content and Software Updates (Continued)
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
identify where the traffic came from and where it is going. On a Palo Alto Networks next-generation 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 sensitive applications and
data and the more protection 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 preventing unauthorized internal or external access to the
data stored in that segment.
Network Segmentation for a Reduced Attack Surface
Configure Interfaces and Zones
The following diagram shows a very basic example of how you can create zones to segment your network.
The more granular you make your zones (and the corresponding security policy rules that allows traffic
between zones), the more you reduce the attack 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) until you
define a Security policy rule that allows it. Additionally, an interface cannot process traffic until you have
assigned it to a zone. Therefore, by segmenting your network into granular zones you have more control over
access to sensitive applications or data and you can prevent malicious traffic from establishing a
communication channel within your network, thereby reducing the likelihood of a successful attack on your
network.
After you identify how you want to segment your network and the zones you will need to create to achieve
the segmentation (as well as the interfaces to map to each zone), you can begin configuring the interfaces
and zones on the firewall. Each interface on the firewall supports all Interface Deployments and the
deployment you will use depends on the topology of each part of the network you are connecting to. The
following workflow shows how to configure Layer 3 interfaces and assign them to zones. For details on
integrating the firewall using a different type of interface deployments (for example Virtual Wire
Deployments or Layer 2 Deployments), see Networking.
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 configuration and commit
the change before proceeding to prevent it from interfering with other settings you define. For
instructions on how to delete the default virtual wire and its associated security policy and zones,
see Step 3 in Set Up a Data Port for Access to External Services.
Set Up Interfaces and Zones
Step 1 Configure a default route to your 1. Select Network > Virtual Router and then select the default
Internet router. link to open the Virtual Router dialog.
2. Select the Static Routes tab and click Add. Enter a Name for
the route and enter the route in the Destination field (for
example, 0.0.0.0/0).
3. Select the IP Address radio button 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 configuration.
Step 2 Configure the external interface (the 1. Select Network > Interfaces and then select the interface you
interface that connects to the Internet). want to configure. In this example, we are configuring
Ethernet1/16 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 section, and enter the IP address and
network mask to assign to the interface, for example
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.
7. To save the interface configuration, click OK.
Set Up Interfaces and Zones (Continued)
Step 3 Configure the interface that connects to 1. Select Network > Interfaces and select the interface you want
your internal network. to configure. In this example, we are configuring Ethernet1/15
In this example, the interface as the internal interface our users connect to.
connects to a network segment 2. Select Layer3 as the Interface Type.
that uses private IP addresses.
3. On the Config tab, expand the Security Zone drop-down and
Because private IP addresses
select New Zone. In the Zone dialog, define a Name for new
cannot be routed externally, you
zone, for example Users, and then click OK.
will have to configure NAT.
4. Select the same Virtual Router you used previously, default in
this example.
5. To assign an IP address to the interface, select the IPv4 tab,
click Add in the IP section, and enter the IP address and
network mask to assign to the interface, for example
192.168.1.4/24.
6. To enable you to ping the interface, select the management
profile that you just created.
7. To save the interface configuration, click OK.
Step 4 Configure the interface that connects to 1. Select the interface you want to configure.
your data center applications. 2. Select Layer3 from the Interface Type drop-down. In this
Although this basic security example, we are configuring Ethernet1/1 as the interface that
policy example configuration provides access to your data center applications.
depicts using a single zone for all
3. On the Config tab, expand the Security Zone drop-down and
of your data center applications,
select New Zone. In the Zone dialog, define a Name for new
as a best practice you would
zone, for example Data Center Applications, and then click OK.
want to define more granular
zones to prevent unauthorized 4. Select the same Virtual Router you used previously, default in
access to sensitive applications this example.
or data and eliminate the 5. To assign an IP address to the interface, select the IPv4 tab,
possibility of malware moving click Add in the IP section, and enter the IP address and
laterally within your data center. network mask to assign to the interface, for example
10.1.1.1/24.
6. To enable you to ping the interface, select the management
profile that you created.
7. To save the interface configuration, click OK.
Step 5 (Optional) 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.
Set Up Interfaces and Zones (Continued)
Step 7 Cable the firewall. Attach 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 active. Select Dashboard and verify that the interfaces you configured
show as green in the Interfaces widget.
Now that you have defined some zones and attached them to interfaces, you are ready to begin creating
your Security Policy. The firewall will not allow any traffic to flow from one zone to another unless there is
a Security policy rule to allow it. When a packet enters a firewall interface, the firewall matches the attributes
in the packet against the Security policy rules to determine whether to block or allow the session based on
attributes such as the source and destination security zone, the source and destination IP address, the
application, user, and the service. The firewall evaluates incoming traffic against the security policy rulebase
from left to right and from top to bottom and then takes the action 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 bottom to ensure that the firewall is enforcing policy as expected.
The following workflow shows how to set up a very basic Internet gateway security policy that enables
access to the network infrastructure, to data center applications, and to the Internet. This will enable you to
get the firewall up and running so that you can verify that you have successfully configured the firewall. This
policy is not comprehensive enough to protect your network. After you verify that you have successfully
configured the firewall and integrated it into your network, proceed to Policy to learn how to create a Best
Practice Internet Gateway Security Policy that will safely enable application access while protecting your
network from attack.
Define Basic Security Policy Rules
Step 1 (Optional) Delete the default security By default, the firewall includes a security rule named rule1 that
policy rule. allows all traffic from Trust zone to Untrust zone. You can either
delete the rule or modify the rule to reflect your zone naming
conventions.
Step 2 Create the File Blocking profiles you will 1. Configure a File Blocking profile for general use. You will
need to prevent upload/download of attach this profile to most of your security profiles to block
malicious files and for drive-by download files known to carry threats or that have no real business use
protection. for upload/download.
2. Configure a File Blocking profile for risky traffic. You will
attach this profile to security policy rules that allow general
web access to prevent users from unknowingly downloading
malicious files from the Internet.
Define Basic Security Policy Rules (Continued)
Step 3 Allow access to your network 1. Select Policies > Security and click Add.
infrastructure resources. 2. Enter a descriptive Name for the rule in the General tab.
3. In the Source tab, set the Source Zone to Users.
4. In the Destination tab, set the Destination Zone to IT
Infrastructure.
As a best practice, consider using address objects in
the Destination Address field to enable access to
specific servers or groups of servers only, particularly
for services such as DNS and SMTP that are commonly
exploited. By restricting users to specific destination
server addresses you can prevent data exfiltration and
command and control traffic from establishing
communication through techniques such as DNS
tunneling.
5. In the Applications tab, Add the applications that correspond
to the network services you want to safely enable. For
example, select dns, ntp, ocsp, ping, smtp.
6. In the Service/URL Category tab, keep the Service set to
application-default.
7. In the Actions tab, set the Action Setting to Allow.
8. Select Profiles as the Profile Type. Select the default profiles
for Antivirus and URL Filtering and the strict profiles for
Vulnerability Protection and Anti-Spyware and select the
File Blocking profile you configured for general traffic.
9. Verify that Log at Session End is enabled. Only traffic that
matches a security rule will be logged.
10. Click OK.
Define Basic Security Policy Rules (Continued)
Step 4 Enable access to general Internet 1. Select Policies > Security and click Add.
applications. 2. Enter a descriptive Name for the rule in the General tab.
This is a temporary rule that
3. In the Source tab, set the Source Zone to Users.
allows you to gather information
about the traffic on your 4. In the Destination tab, set the Destination Zone to Internet.
network. After you have more 5. In the Applications tab, Add an Application Filter and enter a
insight into what applications Name. To safely enable access to legitimate web-based
your users need access to, you applications, set the Category in the application filter to
can make informed decisions general-internet and then click OK. To enable access to
about what applications to allow encrypted sites, Add the ssl application.
and create more granular
application-based rules for each 6. In the Service/URL Category tab, keep the Service set to
user group. application-default.
7. In the Actions tab, set the Action Setting to Allow.
8. Select Profiles as the Profile Type. Select the default profiles
for Antivirus and URL Filtering and the strict profiles for
Vulnerability Protection and Anti-Spyware and select the
File Blocking strict profile you configured for risky traffic.
9. Verify that Log at Session End is enabled. Only traffic that
matches a security rule will be logged.
10. Click OK.
Step 5 Enable access to data center 1. Select Policies > Security and click Add.
applications. 2. Enter a descriptive Name for the rule in the General tab.
3. In the Source tab, set the Source Zone to Users.
4. In the Destination tab, set the Destination Zone to Data
Center Applications.
5. In the Applications tab, Add the applications that correspond
to the network services you want to safely enable. For
example, select activesync, imap, kerberos, ldap,
ms-exchange, and ms-lync.
6. In the Service/URL Category tab, keep the Service set to
application-default.
7. In the Actions tab, set the Action Setting to Allow.
8. Select Profiles as the Profile Type. Select the default profiles
for Antivirus and URL Filtering and the strict profiles for
Vulnerability Protection and Anti-Spyware and select the
File Blocking profile you configured for general traffic.
9. Verify that Log at Session End is enabled. Only traffic that
matches a security rule will be logged.
10. Click OK.
Define Basic Security Policy Rules (Continued)
Step 7 To verify that you have set up your basic To verify the policy rule that matches a flow, use the following CLI
policies effectively, test whether your command:
security policy rules are being evaluated test security-policy-match source <IP_address>
and determine which security policy rule destination <IP_address> destination port <port_number>
applies to a traffic flow. application <application_name> protocol
<protocol_number>
The output displays the best rule that matches the source and
destination IP address specified in the CLI command.
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:
test security-policy-match source 10.35.14.150
destination 10.43.2.2 application dns protocol 53
"Network Infrastructure" {
from Users;
source any;
source-region none;
to Data_Center;
destination any;
destination-region none;
user any;
category any;
application/service dns/any/any/any;
action allow;
icmp-unreachable: no
terminal yes;
}
Now that you have a basic security policy, you can review the statistics and data in the Application Command
Center (ACC), traffic logs, and the threat logs to observe trends on your network. Use this information to
identify where you need to create more granular security policy rules.
Monitor Network Traffic
• Use the Application Command Center and Use In the ACC, review the most used applications and the high-risk
the Automated Correlation Engine. applications on your network. The ACC graphically summarizes the
log information to highlight the applications traversing the
network, who is using them (with User-ID enabled), and the
potential security impact of the content to help you identify what
is happening on the network in real time. You can then use this
information to create appropriate security policy rules that block
unwanted applications, while allowing and enabling applications in
a secure manner.
The Compromised Hosts widget in ACC > Threat Activity displays
potentially compromised hosts on your network and the logs and
match evidence that corroborates the events.
• Work with 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 Application Usage
widget in the ACC, however, records applications and
statistics regardless of policy configuration; 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.
Monitor Network Traffic
• View AutoFocus Threat Data for Logs. Review the AutoFocus intelligence summary for artifacts in your
logs. An artifact is an item, property, activity, or behavior
associated with logged events on the firewall. The intelligence
summary reveals the number of sessions and samples in which
WildFire detected the artifact. Use WildFire verdict information
(benign, grayware, malware) and AutoFocus matching tags to look
for potential risks in your network.
AutoFocus tags created by Unit 42, the Palo Alto Networks
threat intelligence team, call attention to advanced,
targeted campaigns and threats in your network.
From the AutoFocus intelligence summary, you can start an
AutoFocus search for artifacts and assess their
pervasiveness within global, industry, and network
contexts.
• Monitor Web Activity 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 attached with an action
of alert, continue, override or block.
The Palo Alto Networks next-generation firewall has unique threat prevention capabilities that allow it to
protect your network from attack despite the use of evasion, tunneling, or circumvention techniques. The
threat prevention features on the firewall include the WildFire service, Security Profiles that support
Antivirus, Anti-Spyware, Vulnerability Protection, URL Filtering, File Blocking and Data Filtering capabilities,
the Denial of Service (DoS) and Zone protection functionality, and AutoFocus threat intelligence.
Threat Prevention contains more in-depth information on how to protect your network from threats. For
details on how to scan encrypted (SSH or SSL) traffic for threats, see Decryption. Visit Applipedia and Threat
Vault to learn more about the applications and threats that Palo Alto Networks products can identify,
respectively.
Before you can apply threat prevention features, you must first configure zones—to identify one
or more source or destination interfaces—and security policy rules. To configure interfaces, zones,
and the policies that are needed to apply threat prevention features, see Configure Interfaces and
Zones and Set Up a Basic Security Policy.
WildFire is a cloud-based virtual environment that analyzes and executes unknown samples (files and email
links) and determines the samples to be malicious, 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 and distributes it to all firewalls with active WildFire
licenses. This enables global firewalls to detect and prevent malware found by a single firewall.
A basic WildFire service is included as part of the Palo Alto Networks next generation firewall and does not
require a WildFire subscription. With the basic WildFire service, you can enable the firewall to forward
portable executable (PE) files. Additionally, if do not have a WildFire subscription, but you do have a Threat
Prevention subscription, you can receive signatures for malware WildFire identifies every 24- 48 hours (as
part of the antivirus updates).
Beyond the basic WildFire service, a WildFire subscription is required for the firewall to:
Get the latest WildFire signatures every five minutes.
Forward advanced file types and email links for analysis.
Use the WildFire API.
Use a WF-500 appliance to host a WildFire private cloud or a WildFire hybrid cloud.
If you have a WildFire subscription, go ahead and get started with WildFire to get the most out of your
subscription. Otherwise, take the following steps to enable basic WildFire forwarding:
Enable Basic WildFire Forwarding
Step 1 Confirm that your firewall is registered 1. Go to the Palo Alto Networks Customer Support web site, log
and that you have a valid support in, and select My Devices.
account as well as any subscriptions you 2. Verify that the firewall is listed. If it is not listed, see Register
require. the Firewall.
3. (Optional) If you have a Threat Prevention subscription, be
sure to Activate Licenses and Subscriptions.
Step 2 Configure WildFire forwarding settings. 1. Select Device > Setup > WildFire and edit the General
Settings.
2. Set the WildFire Public Cloud field to:
wildfire.paloaltonetworks.com.
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 practice, set the Size Limit for PEs
to the maximum available limit of 10 MB.
Step 3 Enable the firewall to forward PEs for 1. Select Objects > Security Profiles > WildFire Analysis and
analysis. Add a new profile rule.
2. Name the new profile rule.
3. Click Add to create a forwarding rule and enter a name.
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 1. Select Policies > Security and either select an existing policy
to traffic that the firewall allows. or create a new policy as described in Set Up a Basic Security
Policy.
2. Select Actions and in the Profile Settings section, 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 allows.
4. Click OK.
Step 5 Enable the firewall to forward decrypted SSL traffic for WildFire analysis.
Step 6 Review and implement WildFire best practices to ensure that you are getting the most of WildFire detection
and prevention capabilities.
Step 8 Verify that the firewall is forwarding PE Select Monitor > Logs > WildFire Submissions to view log entries
files to the WildFire public cloud. for PEs the firewall successfully submitted for WildFire analysis.
The Verdict column displays whether WildFire found the PE to be
malicious, grayware, or benign.
Enable Basic WildFire Forwarding
Step 9 (Threat Prevention subscription only) If 1. Select Device > Dynamic Updates.
you have a Threat Prevention 2. Check that the firewall is set to retrieve, download, and install
subscription, but do not have a WildFire Antivirus updates.
subscription, you can still receive
WildFire signature updates every 24- 48
hours.
Security Profiles provide threat protection in security policies. For example, you can apply an antivirus profile
to a security policy and all traffic that matches the security policy will be scanned for viruses.
The following sections provide steps for setting up a basic threat prevention configuration:
Set Up Antivirus, Anti-Spyware, and Vulnerability Protection
Set Up File Blocking
Every Palo Alto Networks next-generation firewall comes with redefined Antivirus, Anti-Spyware, and
Vulnerability Protection profiles that you can attach to security policies. There is one predefined Antivirus
profile, default, which uses the default action for each protocol (block HTTP, FTP, and SMB traffic and alert
on SMTP, IMAP, and POP3 traffic). There are two predefined Anti-Spyware and Vulnerability Protection
profiles:
default—Applies the default action to all client and server critical, high, and medium severity
spyware/vulnerability protection events. It does not detect low and informational events.
strict—Applies the block response to all client and server critical, high and medium severity
spyware/vulnerability protection events and uses the default action for low and informational events.
To ensure that the traffic entering your network is free from threats, attach 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.
Set up Antivirus/Anti‐Spyware/Vulnerability Protection
Step 1 Verify that you have a Threat Prevention • The Threat Prevention license bundles the Antivirus,
license. Anti-Spyware, and the Vulnerability Protection features in one
license.
• Select Device > Licenses to verify that the Threat Prevention
license is installed and valid (check the expiration date).
Step 2 Download the latest antivirus threat 1. Select Device > Dynamic Updates and click Check Now at the
signatures. bottom of the page to retrieve the latest signatures.
2. In the Actions column, click Download to install the latest
Antivirus, and Applications and Threats signatures.
Set up Antivirus/Anti‐Spyware/Vulnerability Protection (Continued)
Step 3 Schedule signature updates. 1. From Device > Dynamic Updates, click the text to the right of
Perform a download-and-install Schedule to automatically retrieve signature updates for
on a daily basis for antivirus Antivirus and Applications and Threats.
updates and weekly for 2. Specify the frequency and timing for the updates and whether
applications and threats updates. the update will be downloaded and installed or only
downloaded. If you select Download Only, you would need to
manually go in and click the Install link in the Action column
to install the signature. When you click OK, the update is
scheduled. No commit is required.
3. (Optional) You can also enter the number of hours in the
Threshold field to indicate the minimum age of a signature
before a download will occur. For example, if you entered 10,
the signature must be at least 10 hours old before it will be
downloaded, regardless of the schedule.
4. In an HA configuration, you can also click the Sync To Peer
option to synchronize the content update with the HA peer
after download/install. This will not push the schedule settings
to the peer firewall; you need to configure the schedule on
each firewall.
Set up Antivirus/Anti‐Spyware/Vulnerability Protection (Continued)
Step 4 Attach the security profiles to a security 1. Select Policies > Security, select the desired policy to modify
policy. it and then click the Actions tab.
Attach a clone of a predefined 2. In Profile Settings, click the drop-down next to each security
security profile to your basic profile you would like to enable. In this example we choose
Security policy rules. That way, if default for Antivirus and WildFire Analysis, and strict for
you want to customize the profile you Vulnerability Protection and Anti-Spyware.
can do so without deleting the read-only If you don’t see drop-downs for selecting profiles,
predefined strict or default profile and select Profiles from the Profile Type drop-down.
attaching a customized profile.
File Blocking Profiles allow you to identify specific file types that you want to want to block or monitor. For
most traffic (including traffic on your internal network) you will want to 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. Additionally, to provide drive-by
download protection, 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 will notice that the browser is attempting to
download something they were not aware of. For policy rules that allow general web browsing, be more
strict with your file blocking because the risk of users unknowingly downloading malicious files is much
higher. For this type of traffic you will want to attach a more strict file blocking profile that also blocks
portable executable (PE) files.
Configure File Blocking
Step 6 Configure a File Blocking profile for 1. Select Objects > Security Profiles > File Blocking and click
general use. Add.
2. Enter a Name for the file blocking profile, for example
general-file-blocking.
3. Optionally enter a Description, such as block-risky-apps. Click
Add to define the profile settings.
4. Enter a Name, such as block-risky.
5. Set File Types to block. For example, Add the following: bat,
dll, jar, hlp, lnk, and torrent.
6. Leave the Direction set to both.
7. Set the Action to block.
8. Add a second rule and enter a Name, for example continue exe
and archive.
9. Set File Types to continue. For example, Add the following:
PE, zip and rar.
10. Leave the Direction set to both.
11. Set the Action to block.
12. Click OK to save the profile.
Step 7 Configure a File Blocking profile for risky 1. On the Objects > Security Profiles > File Blocking page,
traffic. select the file blocking profile you just created for general
When users are web browsing it traffic and click Clone. Select the profile to clone and click OK.
is much more likely that they will 2. Select the cloned profile and give it a new Name, such as
download a malicious file strict-block-risky-apps.
unintentionally. Therefore, it is
3. Click in the File Types section of the block rule and Add the PE
important to attach a stricter file
file type.
blocking policy than you would
attach to Security policy rules 4. Click in the File Types section of the continue rule, select PE
that allow access to less and click Delete.
risk-prone application traffic. 5. Click OK to save the profile.
Step 8 Attach the file blocking profile to the 1. Select Policies > Security and either select an existing policy
security policies that allow access to or create a new policy as described in Set Up a Basic Security
content. Policy.
2. Click the Actions tab within the security policy.
3. In the Profile Settings section, click the drop-down and select
the file blocking profile you created.
If you don’t see drop-downs for selecting profiles,
select Profiles from the Profile Type drop-down.
Configure File Blocking (Continued)
Step 9 Enable response pages in the 1. Select Network > Network Profiles > Interface Mgmt and
management profile for each interface then select an interface profile to edit or click Add to create a
on which you are attaching file blocking new profile.
profile with a continue action. 2. Select Response Pages, as well as any other management
services required on the interface.
3. Click OK to save the interface management profile.
4. Select Network > Interfaces and select the interface to which
to attach the profile.
5. On the Advanced > Other Info tab, select the interface
management profile you just created.
6. Click OK to save the interface settings.
Step 11 Test the file blocking configuration. From a client PC in the trust zone of the firewall, attempt to
download an.exe file from a website in the Internet zone. Make
sure the file is blocked as expected based on the action you defined
in the file blocking profile:
• If you selected alert as the action, check the data filtering log to
make sure you see a log entry for the request.
• If you selected block as the action, the File Blocking Block Page
response page should display.
• If you selected the continue action, the File Blocking Continue
Page response page should display. Click Continue to download
the file. The following shows the default File Blocking Continue
Page.
URL Filtering provides visibility and control over web traffic on your network. With URL filtering enabled,
the firewall can categorize web traffic into one or more (from approximately 60) categories. You can then
create policies that specify whether to allow, block, or log (alert) traffic based on the category to which it
belongs. The following workflow shows how to enable PAN-DB for URL filtering, create security profiles,
and attach them to security policies to enforce a basic URL filtering policy.
Configure URL Filtering
Step 1 Confirm license information for URL 1. Obtain and install a URL Filtering license. See Activate
Filtering. Licenses and Subscriptions for details.
2. Select Device > Licenses and verify that the URL Filtering
license is valid.
Step 2 Download the seed database and 1. To download the seed database, click Download next to
activate the license. Download Status in the PAN-DB URL Filtering section of the
Licenses page.
2. Choose a region (North America, Europe, APAC, Japan) and
then click OK to start the download.
3. After the download completes, click Activate.
Step 3 Create a URL filtering profile. 1. Select Objects > Security Profiles > URL Filtering.
Because the default URL filtering 2. Select the default profile and then click Clone. The new profile
profile blocks risky and will be named default-1.
threat-prone content, clone this
3. Select the new profile and rename it.
profile when creating a new
profile in order to preserve the
default settings.
Configure URL Filtering (Continued)
Step 4 Define how to control access to web 1. For each category that you want visibility into or control over,
content. select a value from the Action column as follows:
If you are not sure what traffic you want • If you do not care about traffic to a particular category (that
to control, consider setting the is you neither want to block it nor log it), select allow.
categories (except for those blocked by • For visibility into traffic to sites in a category, select alert.
default) to alert. You can then use the • To present a response page to users attempting to access a
visibility tools on the firewall, such as the particular category to alert them to the fact that the
ACC and App Scope, to determine which content they are accessing might not be work appropriate,
web categories to restrict to specific select continue.
groups or to block entirely. You can then
• To prevent access to traffic that matches the associated
go back and modify the profile to block
policy, select block (this also generates a log entry).
and allow categories as desired.
You can also define specific sites to
always allow or always block regardless
of category and enable the safe search
option to filter search results when
defining the URL Filtering profile.
Step 5 Attach the URL filtering profile to a 1. Select Policies > Security.
security policy. 2. Select the desired policy to modify it and then click the
Actions tab.
3. If this is the first time you are defining a security profile, select
Profiles from the Profile Type drop-down.
4. In the Profile Settings list, select the profile you just created
from the URL Filtering drop-down. (If you don’t see
drop-downs for selecting profiles, select Profiles from the
Profile Type drop-down.)
5. Click OK to save the profile.
6. Commit the configuration.
Configure URL Filtering (Continued)
Step 6 Enable response pages in the 1. Select Network > Network Profiles > Interface Mgmt and
management profile for each interface then select an interface profile to edit or click Add to create a
on which you are filtering web traffic. new profile.
2. Select Response Pages, as well as any other management
services required on the interface.
3. Click OK to save the interface management profile.
4. Select Network > Interfaces and select the interface to which
to attach the profile.
5. On the Advanced > Other Info tab, select the interface
management profile you just created.
6. Click OK to save the interface settings.
Step 8 Test the URL filtering configuration. Access a client PC in the trust zone of the firewall and attempt to
access a site in a blocked category. Make sure URL filtering is
applied based on the action you defined in the URL filtering profile:
• If you selected alert as the action, check the data filtering log to
make sure you see a log entry for the request.
• If you selected the continue action, the URL Filtering Continue
and Override Page response page should display. Continue to
the site.
• If you selected block as the action, the URL Filtering and
Category Match Block Page response page should display as
follows:
With a valid AutoFocus subscription, you can compare the activity on your network with the latest threat
data available on the AutoFocus portal. Connecting your firewall and AutoFocus unlocks the following
features:
Ability to view an AutoFocus intelligence summary for session artifacts recorded in the firewall logs.
Ability to open an AutoFocus search for log artifacts from the firewall.
The AutoFocus intelligence summary reveals the prevalence of an artifact on your network and on a global
scale. The WildFire verdicts and AutoFocus tags listed for the artifact indicate whether the artifact poses a
security risk.
Enable AutoFocus Threat Intelligence on the Firewall
Step 1 Verify that the AutoFocus license is activated on 1. Select Device > Licenses to verify that the AutoFocus
the firewall. Device License is installed and valid (check the
expiration date).
2. If the firewall doesn’t detect the license, see Activate
Licenses and Subscriptions.
Step 2 Connect the firewall to AutoFocus. 1. Select Device > Setup > Management and edit the
AutoFocus settings.
2. Enter the AutoFocus URL:
https://autofocus.paloaltonetworks.com:1044
3
3. Use the Query Timeout field to set the duration of
time for the firewall to attempt 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 connection.
As a best practice, set the query timeout to
the default value of 15 seconds. AutoFocus
queries are optimized to complete within this
duration.
4. Select Enabled to allow the firewall to connect to
AutoFocus.
5. Click OK.
6. Commit your changes to retain the AutoFocus
settings upon reboot.
Step 4 Test the connection between the firewall and 1. On the firewall, select Monitor > Logs > Traffic.
AutoFocus. 2. Verify that you can View AutoFocus Threat Data for
Logs.
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:
Learn about the different Management Interfaces that are available to you and how to access and use
them.
Replace the Certificate for Inbound Management Traffic. By default, the firewall ships with a default
certificate that enables HTTPS access to the web interface over the management (MGT) interface or any
other interface that supports HTTPS management traffic. To improve the security of inbound
management traffic, replace the default certificate with a new certificate issued specifically for your
organization.
Configure a best-practice security policy rulebase to safely enable applications and protect your
network from attack. See Best Practice Internet Gateway Security Policy for details.
Set up High Availability—High availability (HA) is a configuration in which two firewalls are placed in a
group and their configuration and session tables are synchronized to prevent a single point to failure on
your network. A heartbeat connection between the firewall peers ensures seamless failover in the event
that a peer goes down. Setting up a two-firewall cluster provides redundancy and allows you to ensure
business continuity.
Manage Firewall Administrators—Every Palo Alto Networks firewall and appliance is preconfigured with
a default administrative account (admin) that provides full read-write access (also known as superuser
access) to the firewall. As a best practice, create a separate administrative account for each person who
needs access to the administrative or reporting functions of the firewall. This allows you to better
protect the firewall from unauthorized configuration (or modification) and to enable logging of the
actions of each individual administrator.
Enable User Identification (User-ID)—User-ID is a Palo Alto Networks next-generation firewall feature
that allows you to create policies and perform reporting based on users and groups rather than
individual IP addresses.
Enable Decryption—Palo Alto Networks firewalls provide the capability to decrypt and inspect traffic for
visibility, control, and granular security. Use decryption on a firewall to prevent malicious content from
entering your network or sensitive content from leaving your network concealed as encrypted or
tunneled traffic.
Enable Passive DNS Collection for Improved Threat Intelligence—Enable this opt-in feature to enable
the firewall to act as a passive DNS sensor and send select DNS information to Palo Alto Networks for
analysis in order to improve threat intelligence and threat prevention capabilities.
Follow the Best Practices for Securing Your Network from Layer 4 and Layer 7 Evasions.
Management Interfaces
You can use the following user interfaces to manage the Palo Alto Networks firewall and Panorama:
Use the Web Interface to complete administrative tasks and generate reports from the web interface
with relative ease. This graphical interface allows you to access the firewall using HTTPS and it is the best
way to perform administrative tasks.
Use the Command Line Interface (CLI) to enter commands in rapid succession to complete a series of
tasks. The CLI is a no-frills interface that supports two command modes and each mode has its own
hierarchy of commands and statements. When you become familiar with the nesting structure and syntax
of the commands, the CLI provides quick response times and administrative efficiency.
Use the XML API to streamline your operations and integrate with existing, internally developed
applications and repositories. The XML API is a web service implemented using HTTP/HTTPS requests
and responses.
The following topics describe how to use the firewall web interface. For detailed information 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 Activity Indicators to Detect Account Misuse
Manage and Monitor Administrative Tasks
Commit, Validate, and Preview Firewall Configuration Changes
Use Global Find to Search the Firewall or Panorama Management Server
Manage Locks for Restricting Configuration Changes
The following web browsers are supported for access to the web interface:
Internet Explorer 11+
Firefox 3.6+
Safari 5+
Chrome 11+
Launch the Web Interface
Step 1 Launch an Internet browser and enter the IP address of the firewall in the URL field (https://<IP address>).
By default, the management (MGT) interface allows only HTTPS access to the web interface. To
enable other protocols, select Device > Setup > Management and edit the Management Interface
Settings.
Step 2 Enter your user Name and Password. If this is your first login session, enter the default admin for both fields.
Step 3 If the login dialog has a banner, read it. If the dialog requires you to acknowledge reading the banner, select I
Accept and Acknowledge the Statement Below.
A login banner is optional text that you can add to the login page so that administrators will see information
they must know before they log in. For example, you could add a message to notify users of restrictions on
unauthorized use of the firewall.
You can add colored bands that highlight overlaid text across the top (header banner) and bottom (footer
banner) of the web interface to ensure administrators see critical information, such as the classification level
for firewall administration.
A message of the day dialog automatically displays after you log in. The dialog displays messages that Palo
Alto Networks embeds to highlight important information associated with a software or content release. You
can also add one custom message to ensure administrators see information, 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 organization.
Configure Banners, Message of the Day, and Logos
Step 1 Configure the login banner. 1. Select Device > Setup > Management and edit the General
Settings.
2. Enter the Login Banner (up to 3,200 characters).
3. (Optional) 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 activate the Login button.
4. Click OK.
Step 2 Set the message of the day. 1. Select Device > Setup > Management and edit the Banners
and Messages settings.
2. Enable the Message of the Day.
3. Enter the Message of the Day (up to 3,200 characters).
After you enter the message and click OK,
administrators who subsequently log in, and active
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 configuration changes. Based on the
commit time that your message specifies, the
administrators can then decide whether to complete,
save, or undo their changes.
4. (Optional) Select Allow Do Not Display Again (default is
disabled) to give administrators the option to suppress a
message of the day after 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 option.
5. (Optional) Enter a header Title for the message of the day
dialog (default is Message of the Day).
Configure Banners, Message of the Day, and Logos (Continued)
Step 3 Configure the header and footer 1. Enter the Header Banner (up to 3,200 characters).
banners. 2. (Optional) Clear Same Banner Header and Footer (enabled by
A bright background color and default) to use different header and footer banners.
contrasting text color can
3. Enter the Footer Banner (up to 3,200 characters) if the header
increase the likelihood that
and footer banners differ.
administrators will notice and
read a banner. You can also use 4. Click OK.
colors that correspond to
classification levels in your
organization.
Step 4 Replace the logos on the login page and 1. Select Device > Setup > Operations and click Custom Logos in
in the header. the Miscellaneous section.
The maximum size for any logo 2. Perform the following steps for both the Login Screen logo
image is 128KB. The supported and the Main UI (header) logo:
file types are png, gif, and jpg. a. Click upload .
The firewall does not support
b. Select a logo image and click Open.
image files that are interlaced or
that contain alpha channels. You can preview the image to see how PAN-OS
will crop it to fit.
c. Click Close.
3. Commit your changes.
Step 5 Verify that the banners, message of the 1. Log out to return to the login page, which displays the new
day, and logos display as expected. logos you selected.
2. Enter your login credentials, review the banner, select I Accept
and Acknowledge the Statement Below to enable the Login
button, 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 left
arrows along the sides of the dialog or click a page selector
at the bottom of the dialog.
3. (Optional) 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.
The last login time and failed login attempts 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
information to determine if someone else logged in using your credentials and use the failed login attempts
indicator to determine if your account is being targeted in a brute-force attack.
Use the Login Activity Indicators to Detect Account Misuse
Step 1 View the login activity indicators to 1. Log in to the web interface on your firewall or Panorama
monitor recent activity on your account. management server.
2. View the last login details located at the bottom left of the
window and verify that the timestamp corresponds to your
last login.
3. Look for a caution symbol to the right of the last login time
information for failed login attempts.
The failed login indicator appears if one or more failed login
attempts occurred using your account since the last successful
login.
a. If you see the caution symbol, hover over it to display the
number of failed login attempts.
Use the Login Activity Indicators to Detect Account Misuse (Continued)
Step 2 Take the following actions if you detect 1. Select Monitor > Logs > Configuration and view the
an account compromise. configuration 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
configuration and the configuration that was running just prior
to the configuration you suspect was changed using your
credentials. You can also do this using Panorama.
If your administrator account was used to create a new
account, performing a configuration audit helps you
detect changes that are associated with any
unauthorized accounts, as well.
3. Revert the configuration to a known good configuration 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 configuration, review
it to ensure that it contains the correct settings. For
example, the configuration that you revert to may not
contain recent changes, so apply those changes after
you commit the backup configuration.
Use the following best practices to help prevent brute-force attacks on privileged accounts.
• Limit the number of failed attempts allowed before the firewall locks a privileged account by setting the
number of Failed Attempts and the Lockout Time (min) in the authentication profile or in the Authentication
Settings for the Management interface (Device > Setup > Management > Authentication Settings).
• Use Interface Management Profiles to Restrict Access.
• Enforce complex passwords for privileged accounts.
The Task Manager displays details about all the operations that you and other administrators initiated (such
as manual commits) or that the firewall initiated (such as scheduled report generation) since the last firewall
reboot. You can use the Task Manager to troubleshoot failed operations, investigate 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
configuration changes.
Manage and Monitor Administrative Tasks
Step 2 Show only Running tasks (in progress) or All tasks (default). Optionally, filter the tasks by type:
• Jobs—Administrator-initiated commits, firewall-initiated commits, and software or content downloads and
installations.
• Reports—Scheduled reports.
• Log Requests—Log queries that you trigger by accessing the Dashboard or a Monitor page.
A commit is the process of activating changes that you made to the firewall configuration. The firewall
queues commit operations in the order you and other administrators initiate them. If the queue already has
the maximum number of commits (which varies by platform), you must wait for the firewall to process a
pending commit before initiating a new commit. To cancel pending commits or view details about commits
of any status, see Manage and Monitor Administrative Tasks. To check which changes a commit will activate,
you can run a commit preview.
For details on candidate and running configurations, see Manage Configuration Backups.
To prevent multiple administrators from making configuration changes during concurrent sessions, see Manage
Locks for Restricting Configuration Changes.
When you initiate a commit, the firewall checks the validity of the changes before activating them. The
validation output displays conditions that either block the commit (errors) or that are important to know but
that do not block the commit (warnings). For example, validation could indicate an invalid route destination
that you need to fix for the commit to succeed. To identify and fix configuration errors before initiating a
commit, you can validate changes without committing. A pre-commit validation displays the same errors and
warnings as a commit, including reference errors, rule shadowing, and application dependency warnings.
Pre-commit validations are useful if your organization allows commits only within certain time windows; you
can find and fix errors to avoid failures that could cause you to miss a commit window.
Preview, Validate, or Commit Firewall Configuration Changes
Step 1 Configure the commit, validation, or 1. Click Commit at the top of the web interface.
preview options. 2. (Optional) Exclude certain types of configuration changes.
These options are included (enabled) by default.
If dependencies between the configuration changes
you included and excluded cause a validation error,
perform the commit with all the changes included. For
example, if your changes introduce a new Log
Forwarding profile (an object) that references a new
Syslog server profile (a device setting), the commit
must include both the policy and object configuration
and the device and network configuration.
• Include Device and Network configuration
• Include Policy and Object configuration—This is available
only on firewalls for which multiple virtual systems
capability is disabled.
• Include Shared Object configuration—This is available only
on firewalls with multiple virtual systems.
• Include Virtual System configuration—This is available
only on firewalls with multiple virtual systems. Select All
virtual systems (default) or Select one or more virtual
systems in the list.
3. (Optional) Enter a Description for the commit. A brief
summary of what changed in the configuration is useful to
other administrators who want to know what changes were
made without performing a configuration audit.
Step 2 (Optional) Preview the changes that the 1. Click Preview Changes.
commit will activate. This can be useful 2. Select the Lines of Context, which is the number of lines from
if, for example, you don’t remember all the compared configuration files to display before and after
your changes and you’re not sure you each highlighted difference. These additional lines help you
want to activate all of them. correlate the preview output to settings in the web interface.
The firewall displays the changes in a Because the preview results display in a new window,
new window that shows the running and your browser must allow pop-up windows. If the
candidate configurations side by side preview window does not open, refer to your browser
using colors to highlight the differences documentation for the steps to unblock pop-up
line by line. windows.
3. Close the preview window when you finish reviewing the
changes.
Step 3 (Optional) Validate the changes before 1. Click Validate Changes. The results display all the errors and
you commit to ensure the commit will warnings that an actual commit would display.
succeed. 2. Resolve any errors that the validation results identify.
Preview, Validate, or Commit Firewall Configuration Changes (Continued)
Global Find enables you to search the candidate configuration on a firewall or on Panorama for a particular
string, such as an IP address, object name, policy rule name, threat ID, or application name. The search results
are grouped by category and provide links to the configuration location 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 identify other
objects that depend on or make reference to the search term or string. For example, when deprecating 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 configuration page and make the necessary change. After all references are
removed, you can then delete the profile. You can do this for any configuration item that has dependencies.
Watch the video.
Global Find will 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 attribute, 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 identified 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 configuration.
Use Global Find
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 configuration area, click the drop-down next to an item and
select Global Find:
Use Global Find (Continued)
For example, click Global Find on a zone named l3-vlan-trust to search the candidate
configuration for each location where the zone is referenced. The following screen capture shows the
search results for the zone l3-vlan-trust:
Search tips:
• If you initiate a search on a firewall that has multiple virtual systems enabled or if custom Administrative Roles
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 operations. For example, if you search on corp policy, the
search results include instances where corp and policy exist in the configuration.
• To find an exact phrase, enclose the phrase in quotation 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.
You can use configuration locks to prevent other administrators from changing the candidate configuration
or from committing configuration changes until you manually remove the lock or the firewall automatically
removes it (after a commit). Locks ensure that administrators don’t make conflicting changes to the same
settings or interdependent settings during concurrent login sessions.
The firewall queues commit requests and performs them in the order that administrators initiate the commits.
For details, see Commit, Validate, and Preview Firewall Configuration Changes. To view the status of queued
commits, see Manage and Monitor Administrative Tasks.
Manage Locks for Restricting Configuration Changes
• View details about current locks. Click the lock at the top of the web interface. An adjacent
For example, you can check whether other number indicates the number of current locks.
administrators have set locks and read
comments they entered to explain the locks.
Manage Locks for Restricting Configuration Changes (Continued)
• Lock a configuration. 1. Click the lock at the top of the web interface.
The lock image varies based on whether existing locks
are or are not set.
• Unlock a configuration. 1. Click the lock at the top of the web interface.
Only a superuser or the administrator who 2. Select the lock entry in the list.
locked the configuration can manually unlock it.
3. Click Remove Lock, OK, and Close.
However, the firewall automatically removes a
lock after completing the commit operation.
• Configure the firewall to automatically apply a 1. Select Device > Setup > Management and edit the General
commit lock when you change the candidate Settings.
configuration. This setting applies to all 2. Select Automatically Acquire Commit Lock and then click OK
administrators. and Commit.
The running configuration comprises all settings you have committed and that are therefore active, such as
policy rules that currently block or allow various types of traffic in your network. The candidate configuration
is a copy of the running configuration plus any inactive changes that you made after the last commit. Backing
up versions of the running or candidate configuration enables you to later restore those versions on the
firewall. For example, if a commit validation shows that the current candidate configuration has more errors
than you are able or have time to fix, then you can restore a previous candidate configuration or revert to
the running configuration.
See Commit, Validate, and Preview Firewall Configuration Changes for related information.
Back Up a Configuration
Restore a Configuration
Back Up a Configuration
Creating configuration backups enables you to later Restore a Configuration. This is useful when you want
to revert the firewall to all the settings of an earlier configuration because you can perform the restoration
as a single operation instead of manually reconfiguring each setting in the current configuration. You can
either save backups locally on the firewall or export backups to an external host.
When you commit changes, the firewall automatically saves a new version of the running configuration. If a
system event or administrator action causes the firewall to reboot, it automatically reverts to the current
version of the running configuration, which the firewall stores in a file named running-config.xml. However,
the firewall does not automatically save a backup of the candidate configuration; you must manually save a
backup of the candidate configuration as a snapshot file using either the default name (.snapshot.xml) or a
custom name.
When you edit a setting and click OK, the firewall updates the candidate configuration but does
not save a backup snapshot.
Additionally, saving changes does not activate them. To activate changes, perform a commit (see
Commit, Validate, and Preview Firewall Configuration Changes).
As a best practice, back up any important configuration to a host external to the firewall.
Back Up a Configuration
Step 1 Save a local backup snapshot of the Perform one of the following tasks based on whether you want to
candidate configuration if it contains overwrite the default snapshot (.snapshot.xml) or create a snapshot
changes that you want to preserve in with a custom name:
the event the firewall reboots. • Overwrite the default snapshot—Click Save at the top of the
These are changes you are not ready to web interface.
commit—for example, changes you • Create a custom-named snapshot:
cannot finish in the current login session. a. Select Device > Setup > Operations and Save named
configuration snapshot.
b. Enter a Name for the snapshot or select an existing
snapshot to overwrite.
c. Click OK and Close.
Step 2 Export a candidate configuration, a Select Device > Setup > Operations and click an export option:
running configuration, or the firewall • Export named configuration snapshot—Export the current
state information to a host external to running configuration, a named candidate configuration
the firewall. snapshot, or a previously imported configuration (candidate or
running). The firewall exports the configuration as an XML file
with the Name you specify.
• Export configuration version—Select a Version of the running
configuration to export as an XML file. The firewall creates a
version whenever you commit configuration changes.
• Export device state—Export the firewall state information as a
bundle. Besides the running configuration, the state information
includes device group and template settings pushed from
Panorama. If the firewall is a GlobalProtect portal, the
information also includes certificate information, a list of
satellites, and satellite authentication information. If you replace
a firewall or portal, you can restore the exported information on
the replacement by importing the state bundle.
Restore a Configuration
Restoring a firewall configuration overwrites the current candidate configuration with another
configuration. This is useful when you want to revert all firewall settings used in an earlier configuration; you
can perform this restoration as a single operation instead of manually reconfiguring each setting in the
current configuration.
The firewall automatically saves a new version of the running configuration whenever you commit changes
and you can restore any of those versions. However, you must manually save a candidate configuration to
later restore it (see Back Up a Configuration).
Restore a Configuration
• Restore the current running configuration. 1. Select Device > Setup > Operations and Revert to running
This operation undoes all the changes you made configuration.
to the candidate configuration since the last 2. Click Yes to confirm the operation.
commit.
Restore a Configuration (Continued)
• Restore the default snapshot of the candidate 1. Select Device > Setup > Operations and Revert to last saved
configuration. configuration.
This is the snapshot that you create or overwrite 2. Click Yes to confirm the operation.
when you click Save at the top right of the web
3. (Optional) Click Commit to overwrite the running
interface.
configuration with the snapshot.
• Restore a previous version of the running 1. Select Device > Setup > Operations and Load configuration
configuration that is stored on the firewall. version.
The firewall creates a version whenever you 2. Select a configuration Version and click OK.
commit configuration changes.
3. (Optional) Click Commit to overwrite the running
configuration with the version you just restored.
• Restore one of the following: 1. Select Device > Setup > Operations and click Load named
• Current running configuration (named configuration snapshot.
running-config.xml) 2. Select the snapshot Name and click OK.
• Custom-named version of the running 3. (Optional) Click Commit to overwrite the running
configuration that you previously imported configuration with the snapshot.
• Custom-named candidate configuration
snapshot (instead of the default snapshot)
• Restore a running or candidate configuration 1. Select Device > Setup > Operations, click Import named
that you previously exported to an external configuration snapshot, Browse to the configuration file on
host. the external host, and click OK.
2. Click Load named configuration snapshot, select the Name of
the configuration file you just imported, and click OK.
3. (Optional) Click Commit to overwrite the running
configuration with the snapshot you just imported.
Administrative accounts specify roles and authentication methods for the administrators of Palo Alto
Networks firewalls. Every Palo Alto Networks firewall has a predefined default administrative account
(admin) that provides full read-write access (also known as superuser access) to the firewall.
As a best practice, create a separate administrative account for each person who needs access to
the administrative or reporting functions of the firewall. This enables you to better protect the
firewall from unauthorized configuration and enables logging of the actions of individual
administrators.
Administrative Roles
Administrative Authentication
Configure Administrative Accounts and Authentication
Administrative Roles
A role defines the type of access that an administrator has to the firewall.
Administrative Role Types
Configure an Admin Role Profile
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
administrative user with superuser privileges.
Virtual system administrator Full access to a selected virtual system (vsys) on the firewall.
Virtual system administrator (read-only) Read-only access to a selected vsys on the firewall.
Device administrator Full access to all firewall settings except for defining new accounts or virtual
systems.
Device administrator (read-only) Read-only access to all firewall settings except password profiles (no access)
and administrator accounts (only the logged in account is visible).
Admin Role Profiles—Custom roles you can configure for more granular access control over the
functional areas of the web interface, CLI, and XML API. For example, you can create an Admin Role
profile for your operations staff that provides access to the firewall and network configuration areas of
the web interface and a separate profile for your security administrators that provides access to security
policy definitions, logs, and reports. On a multi-vsys firewall, you can select whether the role defines
access for all virtual systems or for a specific vsys. When new features are added to the product, you must
update the roles with corresponding access privileges: the firewall does not automatically add new
features to custom role definitions. For details on the privileges you can configure for custom
administrator roles, see Reference: Web Interface Administrator Access.
Admin Role profiles enable you to define granular administrative access privileges to ensure protection for
sensitive company information and privacy for end users.
As a best practice, create Admin Role profiles that allow administrators to access only the areas of the
management interfaces that they need to access to perform their jobs.
Configure an Admin Role Profile
Step 3 For the scope of the Role, select Device or Virtual System.
Step 4 In the Web UI and XML API tabs, click the icon for each functional area to toggle it to the desired setting:
Enable, Read Only, or Disable. For details on the Web UI options, see Web Interface Access Privileges.
Step 5 Select the Command Line tab and select a CLI access option. The Role scope controls the available options:
• Device role—superuser, superreader, deviceadmin, devicereader, or None
• Virtual System role—vsysadmin, vsysreader, or None
Administrative Authentication
Local Local (no The administrator account credentials and the authentication mechanisms are local
database) to the firewall. You can further secure local accounts by setting global password
complexity and expiration settings for all accounts or by creating a password profile
that defines password expiration settings for specific accounts. For details, see
Configure an Administrative Account.
Local Local database The firewall uses a local database to store the administrator account credentials and
to perform authentication. If your network supports Kerberos single sign-on (SSO),
you can configure local authentication as a fallback in case SSO fails. For details, see
Configure Kerberos SSO and External or Local Authentication for Administrators.
Local SSL-based The administrator accounts are local to the firewall, but authentication is based on
SSH certificates (for CLI access) or client certificates (for web interface access). For
details, see Configure SSH Key-Based Administrator Authentication to the CLI and
Configure Certificate-Based Administrator Authentication to the Web Interface.
Local External service The administrator accounts are local to the firewall, but external services (LDAP,
Kerberos, TACACS+, or RADIUS) handle the authentication functions. If your
network supports Kerberos single sign-on (SSO), you can configure external
authentication as a fallback in case SSO fails. For details, see Configure Kerberos SSO
and External or Local Authentication for Administrators.
External External service An external RADIUS server handles account management and authentication. You
must define Vendor-Specific Attributes (VSAs) on your RADIUS server that map to
the administrator role, access domain, user group (if applicable), and virtual system (if
applicable). For details, see Configure RADIUS Vendor-Specific Attributes for
Administrator Authentication.
If you have already configured Administrative Roles and external authentication services (if applicable), you
can Configure an Administrative Account. Otherwise, perform one of the other procedures listed below to
configure administrative accounts for specific types of authentication.
Administrative accounts specify how administrators authenticate to the firewall. To configure how the firewall
authenticates to administrators, see Replace the Certificate for Inbound Management Traffic.
Administrative accounts specify roles and authentication methods for the administrators of Palo Alto
Networks firewalls.
Configure an Administrative Account
Step 1 (Optional) Define password complexity 1. Define global password complexity and expiration settings for
and expiration settings for administrator all local administrators.
accounts that are local to the firewall. a. Select Device > Setup > Management and edit the
These settings can help protect the Minimum Password Complexity settings.
firewall against unauthorized access by b. Select Enabled.
making it harder for attackers to guess c. Define the password settings and click OK.
passwords.
2. Define a Password Profile if you want certain local
You cannot configure these
administrators to have password expiration settings that
settings for local accounts that
override the global settings.
use a local database or external
service for authentication. a. Select Device > Password Profiles and Add a profile.
b. Enter a Name to identify the profile.
c. Define the password expiration settings and click OK.
Step 2 Add an administrative account. 1. Select Device > Administrators and Add an administrator.
2. Enter a user Name.
3. Select an Authentication Profile or sequence if you
configured either for the user.
The default option (None) specifies that the firewall will locally
manage and authenticate the account without a local
database. In this case, you must enter and confirm a
Password.
4. 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.
5. (Optional) Select a Password Profile for local administrators.
This option is available only if you set the Authentication
Profile to None.
6. Click OK and Commit.
You can configure the firewall to first try Kerberos single sign-on (SSO) authentication and, if that fails, fall
back to External service or Local database authentication.
Configure Kerberos SSO and External or Local Authentication for Administrators
Step 1 Configure a Kerberos keytab for the Create a Kerberos keytab. A keytab is a file that contains Kerberos
firewall. account information (principal name and hashed password) for the
Required for Kerberos SSO firewall.
authentication.
Configure Kerberos SSO and External or Local Authentication for Administrators (Continued)
Step 2 Configure a local database or external • Local database authentication—Perform the following tasks:
server profile. a. Configure the user account.
Required for local database or external b. (Optional) Configure a user group.
authentication. • External authentication—Perform one of the following tasks:
• Configure a RADIUS Server Profile.
• Configure a TACACS+ Server Profile.
• Configure an LDAP Server Profile.
• Configure a Kerberos Server Profile.
As a more secure alternative to password-based authentication to the web interface of a Palo Alto Networks
firewall, you can configure certificate-based authentication for administrator accounts that are local to the
firewall. Certificate-based authentication involves the exchange and verification of a digital signature instead
of a password.
Configure Certificate‐Based Administrator Authentication to the Web Interface
Configure Certificate‐Based Administrator Authentication to the Web Interface (Continued)
Step 3 Configure the firewall to use the 1. Select Device > Setup > Management and edit the
certificate profile for authenticating Authentication Settings.
administrators. 2. Select the Certificate Profile you created for authenticating
administrators and click OK.
Step 4 Configure the administrator accounts to For each administrator who will access the firewall web interface,
use client certificate authentication. Configure an Administrative Account and select Use only client
certificate authentication.
If you have already deployed client certificates that your enterprise
CA generated, skip to Step 8. Otherwise, go to Step 5.
Step 5 Generate a client certificate for each Generate a Certificate. In the Signed By drop-down, select a
administrator. self-signed root CA certificate.
Step 6 Export the client certificate. 1. Export a Certificate and Private Key.
2. Commit your changes. The firewall restarts and terminates
your login session. Thereafter, administrators can access the
web interface only from client systems that have the client
certificate you generated.
Step 7 Import the client certificate into the Refer to your web browser documentation.
client system of each administrator who
will access the web interface.
Step 8 Verify that administrators can access the 1. Open the firewall IP address in a browser on the computer
web interface. that has the client certificate.
2. When prompted, select the certificate you imported and click
OK. The browser displays a certificate warning.
3. Add the certificate to the browser exception list.
4. Click Login. The web interface should appear without
prompting you for a username or password.
For administrators who use Secure Shell (SSH) to access the CLI of a Palo Alto Networks firewall, SSH keys
provide a more secure authentication method than passwords. SSH keys almost eliminate the risk of
brute-force attacks, provide the option for two-factor authentication (key and passphrase), and don’t send
passwords over the network. SSH keys also enable automated scripts to access the CLI.
Configure SSH Key‐Based Administrator Authentication to the CLI
Step 1 Use an SSH key generation tool to For the commands to generate the keypair, refer to your SSH client
create an asymmetric keypair on the documentation.
client system of the administrator. The public key and private key are separate files. Save both to a
The supported key formats are IETF location that the firewall can access. For added security, enter a
SECSH and Open SSH. The supported passphrase to encrypt the private key. The firewall prompts the
algorithms are DSA (1,024 bits) and RSA administrator for this passphrase during login.
(768-4,096 bits).
Step 3 Configure the SSH client to use the Perform this task on the client system of the administrator. For the
private key to authenticate to the steps, refer to your SSH client documentation.
firewall.
Step 4 Verify that the administrator can access 1. Use a browser on the client system of the administrator to go
the firewall CLI using SSH key to the firewall IP address.
authentication. 2. Log in to the firewall CLI as the administrator. After 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 creating
the keys.
The following procedure provides an overview of the tasks required to use RADIUS Vendor-Specific
Attributes (VSAs) for administrator authentication to Palo Alto Networks firewalls. For detailed instructions,
refer to the following Knowledge Base articles:
For Windows 2003 Server, Windows 2008 (and later), and Cisco ACS 4.0—RADIUS Vendor-Specific
Attributes (VSAs)
For Cisco ACS 5.2—Configuring Cisco ACS 5.2 for use with Palo Alto VSA
Use RADIUS Vendor‐Specific Attributes for Account Authentication
Step 1 Configure the firewall. 1. Configure an Admin Role Profile if the administrator will use a
custom role.
2. Configure an access domain if the firewall has more than one
virtual system (vsys):
a. Select Device > Access Domain, Add an access domain, and
enter a Name to identify the access domain.
b. Add each vsys that the administrator will access, and then
click OK.
3. Configure a RADIUS Server Profile.
4. Configure an authentication profile. Set the authentication
Type to RADIUS and assign the RADIUS Server Profile.
5. Configure the firewall to use the authentication profile for
administrator access—Select Device > Setup > Management,
edit the Authentication Settings, and select the
Authentication Profile.
6. Click OK and Commit.
Step 2 Configure the RADIUS server. 1. Add the firewall IP address or hostname as the RADIUS client.
2. Define the VSAs for administrator authentication. You must
specify the vendor code (25461 for Palo Alto Networks
firewalls) and the VSA name, number, and value: see RADIUS
Vendor-Specific Attributes Support.
When configuring the advanced vendor options on a
Cisco ACS, you must set both the Vendor Length Field
Size and Vendor Type Field Size to 1. Otherwise,
authentication will fail.
You can configure privileges for an entire firewall or for one or more virtual systems (on platforms that
support multiple virtual systems). Within that Device or Virtual System designation, 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
information. You can create custom roles for firewall administrators (see Configure an Administrative
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
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
administrative account. For example, you could create an Admin Role Profile for your operations 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 button. 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 Settings in the Admin Role Profile
Restrict Administrator Access to Commit and Validate Functions
Provide Granular Access to Global Settings
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.
Dashboard Controls access to the Dashboard tab. If you disable Yes No Yes
this privilege, the administrator will not see the tab
and will not have access to any of the Dashboard
widgets.
Monitor Controls access to the Monitor tab. If you disable this Yes No Yes
privilege, the administrator will not see the Monitor
tab and will not have access to any of the logs, packet
captures, session information, reports or to App
Scope. For more granular control over what
monitoring information the administrator can see,
leave the Monitor option 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 disable this Yes No Yes
privilege, the administrator will not see the Policies
tab and will not have access to any policy information.
For more granular control over what policy
information the administrator can see, for example to
enable access to a specific type of policy or to enable
read-only access to policy information, leave the
Policies option enabled and then enable or disable
specific nodes on the tab as described in Provide
Granular Access to the Policy Tab.
Objects Controls access to the Objects tab. If you disable this Yes No Yes
privilege, the administrator will not see the Objects
tab and will not have access to any objects, security
profiles, log forwarding profiles, decryption profiles,
or schedules. For more granular control over what
objects the administrator can see, leave the Objects
option 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 disable this Yes No Yes
privilege, the administrator 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 configuration
information or to the network profiles. For more
granular control over what objects the administrator
can see, leave the Network option enabled and then
enable or disable specific nodes on the tab as
described in Provide Granular Access to the Network
Tab.
Device Controls access to the Device tab. If you disable this Yes No Yes
privilege, the administrator will not see the Device tab
and will not have access to any firewall-wide
configuration information, such as User-ID, high
availability, server profile or certificate configuration
information. For more granular control over what
objects the administrator can see, leave the Objects
option enabled and then enable or disable specific
nodes on the tab as described in Provide Granular
Access to the Device Tab.
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.
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 operations administrators to the Config and System logs only,
because they do not contain sensitive user data. Although this section of the administrator role definition
specifies what areas of the Monitor tab the administrator can see, you can also couple privileges in this
section 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 still show usernames and IP addresses
even if you disable that functionality in the role. For this reason, if you do not want the administrator to see
any of the private user information, 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.
Monitor Enables or disables access to the Monitor Firewall: Yes Yes No Yes
tab. If disabled, the administrator will not Panorama: Yes
see this tab or any of the associated logs or Device Group/Template: Yes
reports.
Logs Enables or disables access to all log files. Firewall: Yes Yes No Yes
You can also leave this privilege enabled Panorama: Yes
and then disable specific logs that you do Device Group/Template: Yes
not want the administrator to see. Keep in
mind that if you want to protect the
privacy of your users while still providing
access to one or more of the logs, you can
disable the Privacy > Show Full Ip
Addresses option and/or the Show User
Names In Logs And Reports option.
Traffic Specifies whether the administrator can Firewall: Yes Yes No Yes
see the traffic logs. Panorama: Yes
Device Group/Template: Yes
Threat Specifies whether the administrator can Firewall: Yes Yes No Yes
see the threat logs. Panorama: Yes
Device Group/Template: Yes
URL Filtering Specifies whether the administrator can Firewall: Yes Yes No Yes
see the URL filtering logs. Panorama: Yes
Device Group/Template: Yes
WildFire Specifies whether the administrator can Firewall: Yes Yes No Yes
Submissions see the WildFire logs. These logs are only Panorama: Yes
available if you have a WildFire Device Group/Template: Yes
subscription.
Data Filtering Specifies whether the administrator can Firewall: Yes Yes No Yes
see the data filtering logs. Panorama: Yes
Device Group/Template: Yes
HIP Match Specifies whether the administrator can Firewall: Yes Yes No Yes
see the HIP Match logs. HIP Match logs are Panorama: Yes
only available if you have a GlobalProtect Device Group/Template: Yes
portal license and gateway subscription.
Configuration Specifies whether the administrator can Firewall: Yes Yes No Yes
see the configuration logs. Panorama: Yes
Device Group/Template: No
System Specifies whether the administrator can Firewall: Yes Yes No Yes
see the system logs. Panorama: Yes
Device Group/Template: No
Alarms Specifies whether the administrator can Firewall: Yes Yes No Yes
see system-generated alarms. Panorama: Yes
Device Group/Template: Yes
Correlation Specifies whether the administrator can Firewall: Yes Yes No Yes
Objects view and enable/disable the correlation Panorama: Yes
objects. Device Group/Template: Yes
Packet Specifies whether the administrator can Firewall: Yes Yes Yes Yes
Capture see packet captures (pcaps) from the Panorama: No
Monitor tab. Keep in mind that packet Device Group/Template: No
captures are 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 pcap
and you should therefore disable the
Packet Capture privilege if you are
concerned about user privacy.
App Scope Specifies whether the administrator can Firewall: Yes Yes No Yes
see the App Scope visibility and analysis Panorama: Yes
tools. Enabling App Scope enables access Device Group/Template: Yes
to all of the App Scope charts.
Session Specifies whether the administrator can Firewall: Yes Yes No Yes
Browser browse and filter current running sessions Panorama: No
on the firewall. Keep in mind that the Device Group/Template: No
session browser shows 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.
Botnet Specifies whether the administrator can Firewall: Yes Yes Yes Yes
generate and view botnet analysis reports Panorama: No
or view botnet reports in read-only mode. Device Group/Template: No
Disabling the Show Full IP Addresses
privileges will not obfuscate the IP address
in scheduled botnet reports and you
should therefore disable the Botnet
privilege if you are concerned about user
privacy.
PDF Reports Enables or disables access to all PDF Firewall: Yes Yes No Yes
reports. You can also leave this privilege Panorama: Yes
enabled and then disable specific PDF Device Group/Template: Yes
reports that you do not want the
administrator to see. Keep in mind that if
you want to protect the privacy of your
users while still providing access to one or
more of the reports, you can disable the
Privacy > Show Full Ip Addresses option
and/or the Show User Names In Logs And
Reports option.
Manage PDF Specifies whether the administrator can Firewall: Yes Yes Yes Yes
Summary view, add or delete PDF summary report Panorama: Yes
definitions. With read-only access, the Device Group/Template: Yes
administrator can see PDF summary report
definitions, but not add or delete them. If
you disable this option, the administrator
can neither view the report definitions nor
add/delete them.
PDF Summary Specifies whether the administrator can Firewall: Yes Yes No Yes
Reports see the generated PDF Summary reports in Panorama: Yes
Monitor > Reports. If you disable this Device Group/Template: Yes
option, the PDF Summary Reports
category will not display in the Reports
node.
User Activity Specifies whether the administrator can Firewall: Yes Yes Yes Yes
Report view, add or delete User Activity report Panorama: Yes
definitions and download the reports. Device Group/Template: Yes
With read-only access, the administrator
can see User Activity report definitions,
but not add, delete, or download them. If
you disable this option, the administrator
cannot see this category of PDF report.
SaaS Specifies whether the administrator can Firewall: Yes Yes Yes Yes
Application view, add or delete a SaaS application Panorama: Yes
Usage Report usage report. With read-only access, the Device Group/Template: Yes
administrator can see the SaaS application
usage report definitions, but cannot add or
delete them. If you disable this option, the
administrator can neither view the report
definitions nor add or delete them.
Report Specifies whether the administrator can Firewall: Yes Yes Yes Yes
Groups view, add or delete report group Panorama: Yes
definitions. With read-only access, the Device Group/Template: Yes
administrator can see report group
definitions, but not add or delete them. If
you disable this option, the administrator
cannot see this category of PDF report.
Email Specifies whether the administrator can Firewall: Yes Yes Yes Yes
Scheduler schedule report groups for email. Because Panorama: Yes
the generated reports that get emailed Device Group/Template: Yes
may contain sensitive user data that is not
removed by disabling the Privacy > Show
Full Ip Addresses option and/or the Show
User Names In Logs And Reports options
and because they may also show log data
to which the administrator does not have
access, you should disable the Email
Scheduler option if you have user privacy
requirements.
Manage Enables or disables access to all custom Firewall: Yes Yes No Yes
Custom report functionality. You can also leave this Panorama: Yes
Reports privilege enabled and then disable specific Device Group/Template: Yes
custom report categories that you do not
want the administrator to be able to
access. Keep in mind that if you want to
protect the privacy of your users while still
providing access to one or more of the
reports, you can disable the Privacy >
Show Full Ip Addresses option and/or the
Show User Names In Logs And Reports
option.
Reports that are scheduled to run
rather than run on demand will
show IP address and user
information. In this case, be sure to
restrict access to the
corresponding report areas. In
addition, 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.
Application Specifies whether the administrator can Firewall: Yes Yes No Yes
Statistics create a custom report that includes data Panorama: Yes
from the application statistics database. Device Group/Template: Yes
Data Filtering Specifies whether the administrator can Firewall: Yes Yes No Yes
Log create a custom report that includes data Panorama: Yes
from the Data Filtering logs. Device Group/Template: Yes
Threat Log Specifies whether the administrator can Firewall: Yes Yes No Yes
create a custom report that includes data Panorama: Yes
from the Threat logs. Device Group/Template: Yes
Threat Specifies whether the administrator can Firewall: Yes Yes No Yes
Summary create a custom report that includes data Panorama: Yes
from the Threat Summary database. Device Group/Template: Yes
Traffic Log Specifies whether the administrator can Firewall: Yes Yes No Yes
create a custom report that includes data Panorama: Yes
from the Traffic logs. Device Group/Template: Yes
Traffic Specifies whether the administrator can Firewall: Yes Yes No Yes
Summary create a custom report that includes data Panorama: Yes
from the Traffic Summary database. Device Group/Template: Yes
URL Log Specifies whether the administrator can Firewall: Yes Yes No Yes
create a custom report that includes data Panorama: Yes
from the URL Filtering logs. Device Group/Template: Yes
Hipmatch Specifies whether the administrator can Firewall: Yes Yes No Yes
create a custom report that includes data Panorama: Yes
from the HIP Match logs. Device Group/Template: Yes
WildFire Log Specifies whether the administrator can Firewall: Yes Yes No Yes
create a custom report that includes data Panorama: Yes
from the WildFire logs. Device Group/Template: Yes
View Specifies whether the administrator can Firewall: Yes Yes No Yes
Scheduled view a custom report that has been Panorama: Yes
Custom scheduled to generate. Device Group/Template: Yes
Reports
View Specifies whether the administrator can Firewall: Yes Yes No Yes
Predefined view Application Reports. Privacy Panorama: Yes
Application privileges do not impact reports available Device Group/Template: Yes
Reports on the Monitor > Reports node and you
should therefore disable access to the
reports if you have user privacy
requirements.
View Specifies whether the administrator can Firewall: Yes Yes No Yes
Predefined view Threat Reports. Privacy privileges do Panorama: Yes
Threat not impact reports available on the Device Group/Template: Yes
Reports Monitor > Reports node and you should
therefore disable access to the reports if
you have user privacy requirements.
View Specifies whether the administrator can Firewall: Yes Yes No Yes
Predefined view URL Filtering Reports. Privacy Panorama: Yes
URL Filtering privileges do not impact reports available Device Group/Template: Yes
Reports on the Monitor > Reports node and you
should therefore disable access to the
reports if you have user privacy
requirements.
View Specifies whether the administrator can Firewall: Yes Yes No Yes
Predefined view Traffic Reports. Privacy privileges do Panorama: Yes
Traffic not impact reports available on the Device Group/Template: Yes
Reports Monitor > Reports node and you should
therefore disable access to the reports if
you have user privacy requirements.
If you enable the Policy option 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 user name or IP address) must be explicitly defined, privacy
settings that disable the ability to see full IP addresses or user names 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 restrictions.
Security Enable this privilege to allow the administrator to Yes Yes Yes
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 seeing the security
rulebase, disable this privilege.
NAT Enable this privilege to allow the administrator to Yes Yes Yes
view, add, and/or delete 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 administrator to Yes Yes Yes
view, add, and/or delete 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 administrator to Yes Yes Yes
Forwarding 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.
Decryption Enable this privilege to allow the administrator to Yes Yes Yes
view, add, and/or delete decryption 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 decryption
rulebase, disable this privilege.
Application Override Enable this privilege to allow the administrator to Yes Yes Yes
view, add, and/or delete application 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 application override rulebase, disable this
privilege.
Captive Portal Enable this privilege to allow the administrator to Yes Yes Yes
view, add, and/or delete Captive Portal 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 Captive
Portal rulebase, disable this privilege.
DoS Protection Enable this privilege to allow the administrator to Yes Yes Yes
view, add, and/or delete DoS protection 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 DoS
protection rulebase, disable this privilege.
An object is a container that groups specific policy filter values—such as IP addresses, URLs, applications, or
services—for simplified rule definition. For example, an address object might contain specific IP address
definitions for the web and application 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 definition responsibilities. 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.
Addresses Specifies whether the administrator can view, add, or Yes Yes Yes
delete address objects for use in security policy.
Address Groups Specifies whether the administrator can view, add, or Yes Yes Yes
delete address group objects for use in security policy.
Regions Specifies whether the administrator can view, add, or Yes Yes Yes
delete regions objects for use in security, decryption,
or DoS policy.
Applications Specifies whether the administrator can view, add, or Yes Yes Yes
delete application objects for use in policy.
Application Groups Specifies whether the administrator can view, add, or Yes Yes Yes
delete application group objects for use in policy.
Application Filters Specifies whether the administrator can view, add, or Yes Yes Yes
delete application filters for simplification of repeated
searches.
Services Specifies whether the administrator can view, add, or Yes Yes Yes
delete service objects for use in creating policy rules
that limit the port numbers an application can use.
Service Groups Specifies whether the administrator can view, add, or Yes Yes Yes
delete service group objects for use in security policy.
Tags Specifies whether the administrator can view, add, or Yes Yes Yes
delete tags that have been defined on the firewall.
GlobalProtect Specifies whether the administrator can view, add, or Yes No Yes
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 restricting HIP Object or
HIP Profile access.
HIP Objects Specifies whether the administrator can view, add, or Yes Yes Yes
delete HIP objects, which are used to define HIP
profiles. HIP Objects also generate HIP Match logs.
HIP Profiles Specifies whether the administrator can view, add, or Yes Yes Yes
delete HIP Profiles for use in security policy and/or for
generating HIP Match logs.
Dynamic Block Lists Specifies whether the administrator can view, add, or Yes Yes Yes
delete dynamic block lists for use in security policy.
Custom Objects Specifies whether the administrator can see the Yes No Yes
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 restricting access to each type of
signature.
Data Patterns Specifies whether the administrator can view, add, or Yes Yes Yes
delete custom data pattern signatures for use in
creating custom Vulnerability Protection profiles.
Spyware Specifies whether the administrator can view, add, or Yes Yes Yes
delete custom spyware signatures for use in creating
custom Vulnerability Protection profiles.
Vulnerability Specifies whether the administrator can view, add, or Yes Yes Yes
delete custom vulnerability signatures for use in
creating custom Vulnerability Protection profiles.
URL Category Specifies whether the administrator can view, add, or Yes Yes Yes
delete custom URL categories for use in policy.
Security Profiles Specifies whether the administrator can see security Yes No Yes
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 restricting access
to each type of profile.
Antivirus Specifies whether the administrator can view, add, or Yes Yes Yes
delete antivirus profiles.
Anti-Spyware Specifies whether the administrator can view, add, or Yes Yes Yes
delete Anti-Spyware profiles.
Vulnerability Specifies whether the administrator can view, add, or Yes Yes Yes
Protection delete Vulnerability Protection profiles.
URL Filtering Specifies whether the administrator can view, add, or Yes Yes Yes
delete URL filtering profiles.
File Blocking Specifies whether the administrator can view, add, or Yes Yes Yes
delete file blocking profiles.
Data Filtering Specifies whether the administrator can view, add, or Yes Yes Yes
delete data filtering profiles.
DoS Protection Specifies whether the administrator can view, add, or Yes Yes Yes
delete DoS protection profiles.
Security Profile Groups Specifies whether the administrator can view, add, or Yes Yes Yes
delete security profile groups.
Log Forwarding Specifies whether the administrator can view, add, or Yes Yes Yes
delete log forwarding profiles.
Decryption Profile Specifies whether the administrator can view, add, or Yes Yes Yes
delete decryption profiles.
Schedules Specifies whether the administrator can view, add, or Yes Yes Yes
delete schedules for limiting a security policy to a
specific date and/or time range.
When deciding whether to allow access to the Network tab as a whole, determine whether the administrator
will have network administration responsibilities, including GlobalProtect administration. 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 configurations.
Giving read-only access allows the administrator to view the already-defined configuration, but not create
or delete any. Disabling a node prevents the administrator from seeing the node in the web interface.
Interfaces Specifies whether the administrator can view, add, or Yes Yes Yes
delete interface configurations.
Zones Specifies whether the administrator can view, add, or Yes Yes Yes
delete zones.
VLANs Specifies whether the administrator can view, add, or Yes Yes Yes
delete VLANs.
Virtual Wires Specifies whether the administrator can view, add, or Yes Yes Yes
delete virtual wires.
Virtual Routers Specifies whether the administrator can view, add, Yes Yes Yes
modify or delete virtual routers.
IPSec Tunnels Specifies whether the administrator can view, add, Yes Yes Yes
modify, or delete IPSec Tunnel configurations.
DHCP Specifies whether the administrator can view, add, Yes Yes Yes
modify, or delete DHCP server and DHCP relay
configurations.
DNS Proxy Specifies whether the administrator can view, add, Yes Yes Yes
modify, or delete DNS proxy configurations.
GlobalProtect Specifies whether the administrator can view, add, Yes No Yes
modify GlobalProtect portal and gateway
configurations. You can disable access to the
GlobalProtect functions entirely, or you can enable
the GlobalProtect privilege and then restrict the role
to either the portal or gateway configuration areas.
Portals Specifies whether the administrator can view, add, Yes Yes Yes
modify, or delete GlobalProtect portal configurations.
Gateways Specifies whether the administrator can view, add, Yes Yes Yes
modify, or delete GlobalProtect gateway
configurations.
MDM Specifies whether the administrator can view, add, Yes Yes Yes
modify, or delete GlobalProtect MDM server
configurations.
Device Block List Specifies whether the administrator can view, add, Yes Yes Yes
modify, or delete device block lists.
QoS Specifies whether the administrator can view, add, Yes Yes Yes
modify, or delete QoS configurations.
LLDP Specifies whether the administrator can view add, Yes Yes Yes
modify, or delete LLDP configurations.
Network Profiles Sets the default state to enable or disable for all of the Yes No Yes
Network settings described below.
IKE Gateways Controls access to the Network Profiles > IKE Yes Yes Yes
Gateways node. If you disable this privilege, the
administrator will not see the IKE Gateways node or
define gateways that include the configuration
information necessary to perform IKE protocol
negotiation with peer gateway.
If the privilege state is set to read-only, you can view
the currently configured IKE Gateways but cannot
add or edit gateways.
GlobalProtect IPSec Controls access to the Network Profiles > Yes Yes Yes
Crypto GlobalProtect IPSec Crypto node.
If you disable this privilege, the administrator will not
see that node, or configure algorithms for
authentication and encryption in VPN tunnels
between a GlobalProtect gateway and clients.
If you set the privilege to read-only, the administrator
can view existing GlobalProtect IPSec Crypto profiles
but cannot add or edit them.
IPSec Crypto Controls access to the Network Profiles > IPSec Yes Yes Yes
Crypto node. If you disable this privilege, the
administrator will not see the Network Profiles >
IPSec Crypto node or specify protocols and
algorithms for identification, authentication, and
encryption in VPN tunnels based on IPSec SA
negotiation.
If the privilege state is set to read-only, you can view
the currently configured IPSec Crypto configuration
but cannot add or edit a configuration.
IKE Crypto Controls how devices exchange information to ensure Yes Yes Yes
secure communication. Specify the protocols and
algorithms for identification, authentication, and
encryption in VPN tunnels based on IPsec SA
negotiation (IKEv1 Phase-1).
Monitor Controls access to the Network Profiles > Monitor Yes Yes Yes
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.
If the privilege state is set to read-only, you can view
the currently configured monitor profile configuration
but cannot add or edit a configuration.
Interface Mgmt Controls access to the Network Profiles > Interface Yes Yes Yes
Mgmt node. If you disable this privilege, the
administrator will not see the Network Profiles >
Interface Mgmt node or be able to specify the
protocols that are used to manage the firewall.
If the privilege state is set to read-only, you can view
the currently configured Interface management
profile configuration but cannot add or edit a
configuration.
Zone Protection Controls access to the Network Profiles > Zone Yes Yes Yes
Protection node. If you disable this privilege, the
administrator will not see the Network Profiles >
Zone Protection node or be able to configure a profile
that determines how the firewall responds to attacks
from specified security zones.
If the privilege state is set to read-only, you can view
the currently configured Zone Protection profile
configuration but cannot add or edit a configuration.
QoS Profile Controls access to the Network Profiles > QoS node. Yes Yes Yes
If you disable this privilege, the administrator will not
see the Network Profiles > QoS node or be able to
configure a QoS profile that determines how QoS
traffic classes are treated.
If the privilege state is set to read-only, you can view
the currently configured QoS profile configuration but
cannot add or edit a configuration.
LLDP Profile Controls access to the Network Profiles > LLDP node. Yes Yes Yes
If you disable this privilege, the administrator will not
see the Network Profiles > LLDP node or be able to
configure an LLDP profile that controls whether the
interfaces on the firewall can participate in the Link
Layer Discovery Protocol.
If the privilege state is set to read-only, you can view
the currently configured LLDP profile configuration
but cannot add or edit a configuration.
BFD Profile Controls access to the Network Profiles > BFD Profile Yes Yes Yes
node. If you disable this privilege, the administrator
will not see the Network Profiles > BFD Profile node
or be able to configure a BFD profile. A Bidirectional
Forwarding Detection (BFD) profile allows you to
configure BFD settings to apply to one or more static
routes or routing protocols. Thus, BFD detects a failed
link or BFD peer and allows an extremely fast failover.
If the privilege state is set to read-only, you can view
the currently configured BFD profile but cannot add
or edit a BFD profile.
To define granular access privileges for the Device tab, when creating or editing an admin role profile (Device
> Admin Roles), scroll down to the Device node on the WebUI tab.
Setup Controls access to the Setup node. If you disable this Yes Yes Yes
privilege, the administrator will not see the Setup
node or have access to firewall-wide setup
configuration information, such as Management,
Operations, Service, Content-ID, Wildfire or Session
setup information.
If the privilege state is set to read-only, you can view
the current configuration but cannot make any
changes.
Management Controls access to the Management node. If you Yes Yes Yes
disable this privilege, the administrator will not be able
to configure settings such as the hostname, domain,
timezone, authentication, logging and reporting,
Panorama, management interface, banner, message,
and password complexity settings, and more.
If the privilege state is set to read-only, you can view
the current configuration but cannot make any
changes.
Operations Controls access to the Operations node. If you disable Yes Yes Yes
this privilege, the administrator cannot:
• Load firewall configurations.
• Save or revert the firewall configuration.
• Create custom logos.
• Configure SNMP monitoring of firewall settings.
• Configure the Statistics Service feature.
Only administrators with the predefined Superuser
role can export or import firewall configurations and
shut down the firewall.
Only administrators with the predefined 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 configurations through the Device >
Operations options.
Services Controls access to the Services node. If you disable Yes Yes Yes
this privilege, the administrator will not be able to
configure services for DNS servers, an update server,
proxy server, or NTP servers, or set up service routes.
If the privilege state is set to read-only, you can view
the current configuration but cannot make any
changes.
Content-ID Controls access to the Content-ID node. If you disable Yes Yes Yes
this privilege, the administrator will not be able to
configure URL filtering or Content-ID.
If the privilege state is set to read-only, you can view
the current configuration but cannot make any
changes.
WildFire Controls access to the WildFire node. If you disable Yes Yes Yes
this privilege, the administrator will not be able to
configure WildFire settings.
If the privilege state is set to read-only, you can view
the current configuration but cannot make any
changes.
Session Controls access to the Session node. If you disable Yes Yes Yes
this privilege, the administrator will not be able to
configure session settings or timeouts for TCP, UDP
or ICMP, or configure decryption or VPN session
settings.
If the privilege state is set to read-only, you can view
the current configuration but cannot make any
changes.
HSM Controls access to the HSM node. If you disable this Yes Yes Yes
privilege, the administrator will not be able to
configure a Hardware Security Module.
If the privilege state is set to read-only, you can view
the current configuration but cannot make any
changes.
Config Audit Controls access to the Config Audit node. If you Yes No Yes
disable this privilege, the administrator will not see the
Config Audit node or have access to any firewall-wide
configuration information.
Admin Roles Controls access to the Admin Roles node. This No Yes Yes
function can only be allowed for read-only access.
If you disable this privilege, the administrator will not
see the Admin Roles node or have access to any
firewall-wide information concerning Admin Role
profiles configuration.
If you set this privilege to read-only, you can view the
configuration information for all administrator roles
configured on the firewall.
Virtual Systems Controls access to the Virtual Systems node. If you Yes Yes Yes
disable this privilege, the administrator will not see or
be able to configure virtual systems.
If the privilege state is set to read-only, you can view
the currently configured virtual systems but cannot
add or edit a configuration.
Shared Gateways Controls access to the Shared Gateways node. Shared Yes Yes Yes
gateways allow virtual systems to share a common
interface for external communications.
If you disable this privilege, the administrator will not
see or be able to configure shared gateways.
If the privilege state is set to read-only, you can view
the currently configured shared gateways but cannot
add or edit a configuration.
User Identification Controls access to the User Identification node. If you Yes Yes Yes
disable this privilege, the administrator will not see the
User Identification node or have access to
firewall-wide User Identification configuration
information, such as User Mapping, User-ID Agents,
Service, Terminal Services Agents, Group Mappings
Settings or Captive Portal Settings.
If you set this privilege to read-only, the administrator
can view configuration information for the firewall but
is not allowed to perform any configuration
procedures.
VM Information Source Controls access to the VM Information Source node Yes Yes Yes
that allows you to configure the firewall/Windows
User-ID agent to collect VM inventory automatically.
If you disable this privilege, the administrator will not
see the VM Information Source node.
If you set this privilege to read-only, the administrator
can view the VM information sources configured but
cannot add, edit, or delete any sources.
This privilege is not available to Device Group
and Template administrators.
High Availability Controls access to the High Availability node. If you Yes Yes Yes
disable this privilege, the administrator will not see the
High Availability node or have access to firewall-wide
high availability configuration information such as
General setup information or Link and Path
Monitoring.
If you set this privilege to read-only, the administrator
can view High Availability configuration information
for the firewall but is not allowed to perform any
configuration procedures.
Certificate Sets the default state to enable or disable for all of the Yes No Yes
Management Certificate settings described below.
Certificates Controls access to the Certificates node. If you Yes Yes Yes
disable this privilege, the administrator will not see the
Certificates node or be able to configure or access
information regarding Device Certificates or Default
Trusted Certificate Authorities.
If you set this privilege to read-only, the administrator
can view Certificate configuration information for the
firewall but is not allowed to perform any
configuration procedures.
Certificate Profile Controls access to the Certificate Profile node. If you Yes Yes Yes
disable this privilege, the administrator will not see the
Certificate Profile node or be able to create
certificate profiles.
If you set this privilege to read-only, the administrator
can view Certificate Profiles that are currently
configured for the firewall but is not allowed to create
or edit a certificate profile.
OCSP Responder Controls access to the OCSP Responder node. If you Yes Yes Yes
disable this privilege, the administrator will not see the
OCSP Responder node or be able to define a server
that will be used to verify the revocation status of
certificates issues by the firewall.
If you set this privilege to read-only, the administrator
can view the OCSP Responder configuration for the
firewall but is not allowed to create or edit an OCSP
responder configuration.
SSL/TLS Service Profile Controls access to the SSL/TLS Service Profile node. Yes Yes Yes
If you disable this privilege, the administrator will not
see the node or configure a profile that specifies a
certificate and a protocol version or range of versions
for firewall services that use SSL/TLS.
If you set this privilege to read-only, the administrator
can view existing SSL/TLS Service profiles but cannot
create or edit them.
SCEP Controls access to the SCEP node. If you disable this Yes Yes Yes
privilege, the administrator will not see the node or be
able to define a profile that specifies simple certificate
enrollment protocol (SCEP) settings for issuing unique
device certificates.
If you set this privilege to read-only, the administrator
can view existing SCEP profiles but cannot create or
edit them.
Response Pages Controls access to the Response Pages node. If you Yes Yes Yes
disable this privilege, the 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.
If you set this privilege to read-only, the administrator
can view the Response Page configuration for the
firewall but is not allowed to create or edit a response
page configuration.
Log Settings Sets the default state to enable or disable for all of the Yes No Yes
Log settings described below.
System Controls access to the Log Settings > System node. If Yes Yes Yes
you disable this privilege, the administrator will not
see the Log Settings > System node or be able to
specify the severity levels of the system log entries
that are logged remotely with Panorama and sent as
SNMP traps, syslog messages, and/or email
notifications.
If you set this privilege to read-only, the administrator
can view the Log Settings > System configuration for
the firewall but is not allowed to create or edit a
configuration.
Config Controls access to the Log Settings > Config node. If Yes Yes Yes
you disable this privilege, the administrator will not
see the Log Settings > Config node or be able to
specify the configuration log entries that are logged
remotely with Panorama, and sent as syslog messages
and/or email notification.
If you set this privilege to read-only, the administrator
can view the Log Settings > Config configuration for
the firewall but is not allowed to create or edit a
configuration.
HIP Match Controls access to the Log Settings > HIP Match node. Yes Yes Yes
If you disable this privilege, the administrator will not
see the Log Settings > HIP Match node or be able to
specify the Host Information Profile (HIP) match log
settings that are used to provide information on
security rules that apply to GlobalProtect clients
If you set this privilege to read-only, the administrator
can view the Log Settings > HIP configuration for the
firewall but is not allowed to create or edit a
configuration.
Alarms Controls access to the Log Settings > Alarms node. If Yes Yes Yes
you disable this privilege, the administrator will not
see the Log Settings > Alarms node or be able to
configure notifications that are generated when a
security rule (or group of rules) has been hit
repeatedly in a set period of time.
If you set this privilege to read-only, the administrator
can view the Log Settings > Alarms configuration for
the firewall but is not allowed to create or edit a
configuration.
Manage Logs Controls access to the Log Settings > Manage Logs Yes Yes Yes
node. If you disable this privilege, the administrator
will not see the Log Settings > Manage Logs node or
be able to clear the indicated logs.
If you set this privilege to read-only, the administrator
can view the Log Settings > Manage Logs information
but cannot clear any of the logs.
Server Profiles Sets the default state to enable or disable for all of the Yes No Yes
Server Profiles settings described below.
SNMP Trap Controls access to the Server Profiles > SNMP Trap Yes Yes Yes
node. If you disable this privilege, the administrator
will not see the Server Profiles > SNMP Trap node or
be able to specify one or more SNMP trap
destinations to be used for system log entries.
If you set this privilege to read-only, the administrator
can view the Server Profiles > SNMP Trap Logs
information but cannot specify SNMP trap
destinations.
Syslog Controls access to the Server Profiles > Syslog node. Yes Yes Yes
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.
If you set this privilege to read-only, the administrator
can view the Server Profiles > Syslog information but
cannot specify syslog servers.
Email Controls access to the Server Profiles > Email node. Yes Yes Yes
If you disable this privilege, the administrator will not
see the Server Profiles > Email node or be able to
configure an email profile that can be used to enable
email notification for system and configuration log
entries
If you set this privilege to read-only, the administrator
can view the Server Profiles > Email information but
cannot configure and email profile.
Netflow Controls access to the Server Profiles > Netflow Yes Yes Yes
node. If you disable this privilege, the administrator
will not see the Server Profiles > Netflow 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.
If you set this privilege to read-only, the administrator
can view the Server Profiles > Netflow information
but cannot define a Netflow profile.
RADIUS Controls access to the Server Profiles > RADIUS Yes Yes Yes
node. If you disable this privilege, the administrator
will not see the Server Profiles > RADIUS node or be
able to configure settings for the RADIUS servers that
are identified in authentication profiles.
If you set this privilege to read-only, the administrator
can view the Server Profiles > RADIUS information
but cannot configure settings for the RADIUS servers.
TACACS+ Controls access to the Server Profiles > TACACS+ Yes Yes Yes
node.
If you disable this privilege, the administrator will not
see the node or configure settings for the TACACS+
servers that authentication profiles reference.
If you set this privilege to read-only, the administrator
can view existing TACACS+ server profiles but cannot
add or edit them.
LDAP Controls access to the Server Profiles > LDAP node. Yes Yes Yes
If you disable this privilege, the administrator will not
see the Server Profiles > LDAP node or be able to
configure settings for the LDAP servers to use for
authentication by way of authentication profiles.
If you set this privilege to read-only, the administrator
can view the Server Profiles > LDAP information but
cannot configure settings for the LDAP servers.
Kerberos Controls access to the Server Profiles > Kerberos Yes Yes Yes
node. If you disable this privilege, the administrator
will not see the Server Profiles > Kerberos node or
configure a Kerberos server that allows users to
authenticate natively to a domain controller.
If you set this privilege to read-only, the administrator
can view the Server Profiles > Kerberos information
but cannot configure settings for Kerberos servers.
Local User Database Sets the default state to enable or disable for all of the Yes No Yes
Local User Database settings described below.
Users Controls access to the Local User Database > Users Yes Yes Yes
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
authentication information for remote access users,
firewall administrators, and captive portal users.
If you set this privilege to read-only, the administrator
can view the Local User Database > Users
information but cannot set up a local database on the
firewall to store authentication information.
User Groups Controls access to the Local User Database > Users Yes Yes Yes
node. If you disable this privilege, the administrator
will not see the Local User Database > Users node or
be able to add user group information to the local
database.
If you set this privilege to read-only, the administrator
can view the Local User Database > Users
information but cannot add user group information to
the local database.
Authentication Profile Controls access to the Authentication Profile node. If Yes Yes Yes
you disable this privilege, the administrator will not
see the Authentication Profile node or be able to
create or edit authentication profiles that specify local
database, RADIUS, TACACS+, LDAP, or Kerberos
settings that can be assigned to administrator
accounts.
If you set this privilege to read-only, the administrator
can view the Authentication Profile information but
cannot create or edit an authentication profile.
Access Domain Controls access to the Access Domain node. If you Yes Yes Yes
disable this privilege, the administrator will not see the
Access Domain node or be able to create or edit an
access domain.
If you set this privilege to read-only, the administrator
can view the Access Domain information but cannot
create or edit an access domain.
Scheduled Log Export Controls access to the Scheduled Log Export node. If Yes No Yes
you disable this privilege, the administrator will not
see the 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.
If you set this privilege to read-only, the administrator
can view the Scheduled Log Export Profile
information but cannot schedule the export of logs.
Software Controls access to the Software node. If you disable Yes Yes Yes
this privilege, the administrator will not see the
Software node or view the latest versions of the
PAN-OS software available from Palo Alto Networks,
read the release notes for each version, and select a
release to download and install.
If you set this privilege to read-only, the administrator
can view the Software information but cannot
download or install software.
GlobalProtect Client Controls access to the GlobalProtect Client node. If Yes Yes Yes
you disable this privilege, the administrator will not
see the GlobalProtect Client node or view available
GlobalProtect releases, download the code or activate
the GlobalProtect agent.
If you set this privilege to read-only, the administrator
can view the available GlobalProtect Client releases
but cannot download or install the agent software.
Dynamic Updates Controls access to the Dynamic Updates node. If you Yes Yes Yes
disable this privilege, the 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.
If you set this privilege to read-only, the administrator
can view the available Dynamic Updates releases,
read the release notes but cannot upload or install the
software.
Licenses Controls access to the Licenses node. If you disable Yes Yes Yes
this privilege, the administrator will not see the
Licenses node or be able to view the licenses installed
or activate licenses.
If you set this privilege to read-only, the administrator
can view the installed Licenses, but cannot perform
license management functions.
Support Controls access to the Support node. If you disable Yes Yes Yes
this privilege, the administrator cannot see the
Support node, activate support, or access production
and security alerts from Palo Alto Networks.
If you set this privilege to read-only, the administrator
can see the Support node and access production and
security alerts but cannot activate support.
Only administrators with the predefined Superuser
role can use the Support node to generate tech
support files or generate and download stats dump
and core files.
Master Key and Controls access to the Master Key and Diagnostics Yes Yes Yes
Diagnostics node. If you disable this privilege, the administrator
will not see the Master Key and Diagnostics node or
be able to specify a master key to encrypt private keys
on the firewall.
If you set this privilege to read-only, the administrator
can view the Master Key and Diagnostics node and
view information about master keys that have been
specified but cannot add or edit a new master key
configuration.
To define what private end user data an administrator has access to, when creating or editing an admin role
profile (Device > Admin Roles), scroll down to the Privacy option on the WebUI tab.
Privacy Sets the default state to enable or disable for all of the Yes N/A Yes
privacy settings described below.
Show Full IP addresses When disabled, full IP addresses obtained by traffic Yes N/A Yes
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.
Scheduled reports that are displayed in the
interface through Monitor > Reports and
reports that are sent via scheduled emails will
still display full IP addresses. Because of this
exception, we recommend that the following
settings within the Monitor tab be set to
disable: Custom Reports, Application Reports,
Threat Reports, URL Filtering Reports, Traffic
Reports and Email Scheduler.
Show User Names in When disabled, user names obtained by traffic Yes N/A Yes
Logs and Reports running through the Palo Alto Networks firewall are
not shown in logs or reports. Columns where the user
names 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 still display
user names. Because of this exception, we
recommend that the following settings within the
Monitor tab be set to disable: Custom Reports,
Application Reports, Threat Reports, URL Filtering
Reports, Traffic Reports and Email Scheduler.
View PCAP Files When disabled, packet capture files that are normally Yes N/A Yes
available within the Traffic, Threat and Data Filtering
logs are not displayed.
To restrict access to commit and validate functions when creating or editing an admin role profile (Device >
Admin Roles), scroll down to the Commit and Validate options on the WebUI tab.
Commit When disabled, an administrator cannot commit any Yes N/A Yes
changes to a configuration.
To define what global settings and administrator has access to, when creating or editing an admin role profile
(Device > Admin Roles), scroll down to the Global option on the WebUI tab.
Global Sets the default state to enable or disable for all of the Yes N/A Yes
global settings described below. In effect, this setting
is only for System Alarms at this time.
System Alarms When disabled, an administrator cannot view or Yes N/A Yes
acknowledge alarms that are generated.
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.
Setup Specifies whether the administrator can Panorama: Yes Yes Yes Yes
view or edit Panorama setup Device Group/Template: No
information, such as Management,
Operations, Services, WildFire, or
HSM.
If you set the privilege to:
• read-only, the administrator can see
the information but cannot edit it.
• disable this privilege, the
administrator cannot see or edit the
information.
High Availability Specifies whether the administrator can Panorama: Yes Yes Yes Yes
view and manage high availability (HA) Device Group/Template: No
settings for the Panorama management
server.
If you set this privilege to read-only, the
administrator can view HA
configuration information for the
Panorama management server but can’t
manage the configuration.
If you disable this privilege, the
administrator can’t see or manage HA
configuration settings for the Panorama
management server.
Config Audit Specifies whether the administrator can Panorama: Yes Yes No Yes
run Panorama configuration audits. If Device Group/Template: No
you disable this privilege, the
administrator can’t run Panorama
configuration audits.
Administrators Specifies whether the administrator can Panorama: Yes No Yes Yes
view Panorama administrator account Device Group/Template: No
details.
You can’t enable full access to this
function: 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 information about his or her own
account but no other Panorama
administrator accounts.
If you disable this privilege, the
administrator can’t see information
about any Panorama administrator
account, including his or her own.
Admin Roles Specifies whether the administrator can Panorama: Yes No Yes Yes
view Panorama administrator roles. Device Group/Template: No
You can’t enable full access to this
function: just read-only access. (Only
Panorama administrators with a
dynamic role can add, edit, or delete
custom Panorama roles.) With
read-only access, the administrator can
see Panorama administrator role
configurations but can’t manage them.
If you disable this privilege, the
administrator can’t see or manage
Panorama administrator roles.
Access Domain Specifies whether the administrator can Panorama: Yes Yes Yes Yes
view, add, edit, delete, or clone access Device Group/Template: No
domain configurations for Panorama You assign access
administrators. (This privilege controls domains to Device
access only to the configuration of Group and Template
access domains, not access to the administrators so they
device groups, templates, and firewall can access the
contexts that are assigned to access configuration and
domains.) monitoring data within
If you set this privilege to read-only, the the device groups,
administrator can view Panorama templates, and firewall
access domain configurations but can’t contexts that are
manage them. assigned to those
If you disable this privilege, the access domains.
administrator can’t see or manage
Panorama access domain
configurations.
Authentication Specifies whether the administrator can Panorama: Yes Yes Yes Yes
Profile view, add, edit, delete, or clone Device Group/Template: No
authentication profiles for Panorama
administrators.
If you set this privilege to read-only, the
administrator can view Panorama
authentication profiles but can’t
manage them.
If you disable this privilege, the
administrator can’t see or manage
Panorama authentication profiles.
Authentication Specifies whether the administrator can Panorama: Yes Yes Yes Yes
Sequence view, add, edit, delete, or clone Device Group/Template: No
authentication sequences for Panorama
administrators.
If you set this privilege to read-only, the
administrator can view Panorama
authentication sequences but can’t
manage them.
If you disable this privilege, the
administrator can’t see or manage
Panorama authentication sequences.
Managed Specifies whether the administrator can Panorama: Yes Yes Yes Yes
Devices view, add, edit, tag, or delete firewalls as Device Group/Template: Yes (No for
managed devices, and install software Device
or content updates on them. Group
If you set this privilege to read-only, the and
administrator can see managed firewalls Templat
but can’t add, delete, tag, or install e roles)
updates on them.
If you disable this privilege, the
administrator can’t view, add, edit, tag,
delete, or install updates on managed
firewalls.
This privilege applies only to the
Panorama > Managed Devices
page. An administrator with
Device Deployment privileges
can still use the Panorama >
Device Deployment pages to
install updates on managed
firewalls.
Templates Specifies whether the administrator can Panorama: Yes Yes Yes Yes
view, edit, add, or delete templates and Device Group/Template: Yes (No for
template stacks. Device Group and Device
If you set the privilege to read-only, the Template Group
administrator can see template and administrators can see and
stack configurations but can’t manage only the templates and Templat
them. stacks that are within e
If you disable this privilege, the the access domains admins)
administrator can’t see or manage assigned to those
template and stack configurations. administrators.
Device Groups Specifies whether the administrator can Panorama: Yes Yes Yes Yes
view, edit, add, or delete device groups. Device Group/Template: Yes
If you set this privilege to read-only, the Device Group and
administrator can see device group Template
configurations but can’t manage them. administrators can
If you disable this privilege, the access only the device
administrator can’t see or manage groups that are within
device group configurations. the access domains
assigned to those
administrators.
Managed Specifies whether the administrator can Panorama: Yes Yes Yes Yes
Collectors view, edit, add, or delete managed Device Group/Template: No
collectors.
If you set this privilege to read-only, the
administrator can see managed
collector configurations but can’t
manage them.
If you disable this privilege, the
administrator can’t view, edit, add, or
delete managed collector
configurations.
This privilege applies only to the
Panorama > Managed
Collectors page. An
administrator with Device
Deployment privileges can still
use the Panorama > Device
Deployment pages to install
updates on managed collectors.
Collector Specifies whether the administrator can Panorama: Yes Yes Yes Yes
Groups view, edit, add, or delete Collector Device Group/Template: No
Groups.
If you set this privilege to read-only, the
administrator can see Collector Groups
but can’t manage them.
If you disable this privilege, the
administrator can’t see or manage
Collector Groups.
VMware Service Specifies whether the administrator can Panorama: Yes Yes Yes Yes
Manager view and edit VMware Service Manager Device Group/Template: No
settings.
If you set this privilege to read-only, the
administrator can see the settings but
can’t perform any related configuration
or operational procedures.
If you disable this privilege, the
administrator can’t see the settings or
perform any related configuration or
operational procedures.
Certificate Sets the default state, enabled or Panorama: Yes Yes No Yes
Management disabled, for all of the Panorama Device Group/Template: No
certificate management privileges.
Certificates Specifies whether the administrator can Panorama: Yes Yes Yes Yes
view, edit, generate, delete, revoke, Device Group/Template: No
renew, or export certificates. This
privilege also specifies whether the
administrator can import or export HA
keys.
If you set this privilege to read-only, the
administrator can see Panorama
certificates but can’t manage the
certificates or HA keys.
If you disable this privilege, the
administrator can’t see or manage
Panorama certificates or HA keys.
Certificate Specifies whether the administrator can Panorama: Yes Yes Yes Yes
Profile view, add, edit, delete or clone Device Group/Template: No
Panorama certificate profiles.
If you set this privilege to read-only, the
administrator can see Panorama
certificate profiles but can’t manage
them.
If you disable this privilege, the
administrator can’t see or manage
Panorama certificate profiles.
SSL/TLS Service Specifies whether the administrator can Panorama: Yes Yes Yes Yes
Profile view, add, edit, delete or clone SSL/TLS Device Group/Template: No
Service profiles.
If you set this privilege to read-only, the
administrator can see SSL/TLS Service
profiles but can’t manage them.
If you disable this privilege, the
administrator can’t see or manage
SSL/TLS Service profiles.
Log Settings Sets the default state, enabled or Panorama: Yes Yes No Yes
disabled, for all the log setting Device Group/Template: No
privileges.
System Specifies whether the administrator can Panorama: Yes Yes Yes Yes
see and configure the settings that Device Group/Template: No
control the forwarding of System logs to
external services (syslog, email, or
SNMP trap servers).
If you set this privilege to read-only, the
administrator can see the System log
forwarding settings but can’t manage
them.
If you disable this privilege, the
administrator can’t see or manage the
settings.
On a Panorama M-Series
appliance, this privilege pertains
only to System logs that
Panorama generates. On a
Panorama virtual appliance, this
privilege applies to System logs
that Panorama generates and to
System logs that Panorama
collects from firewalls. The
Panorama > Collector Groups
page controls the forwarding of
System logs that an M-Series
appliance collects from
firewalls. The Device > Log
Settings page controls the
forwarding of System logs
directly from firewalls to
external services (without
aggregation on Panorama).
Config Specifies whether the administrator can Panorama: Yes Yes Yes Yes
see and configure the settings that Device Group/Template: No
control the forwarding of Config logs to
external services (syslog, email, or
SNMP trap servers).
If you set this privilege to read-only, the
administrator can see the Config log
forwarding settings but can’t manage
them.
If you disable this privilege, the
administrator can’t see or manage the
settings.
On a Panorama M-Series
appliance, this privilege pertains
only to Config logs that
Panorama generates. On a
Panorama virtual appliance, this
privilege applies to Config logs
that Panorama generates and to
Config logs that Panorama
collects from firewalls. The
Panorama > Collector Groups
page controls the forwarding of
Config logs that an M-Series
appliance collects from
firewalls. The Device > Log
Settings page controls the
forwarding of Config logs
directly from firewalls to
external services (without
aggregation on Panorama).
HIP Match Specifies whether the administrator can Panorama: Yes Yes Yes Yes
see and configure the settings that Device Group/Template: No
control the forwarding of HIP Match
logs from a Panorama virtual appliance
to external services (syslog, email, or
SNMP trap servers).
If you set this privilege to read-only, the
administrator can see the forwarding
settings of HIP Match logs but can’t
manage them.
If you disable this privilege, the
administrator can’t see or manage the
settings.
The Panorama > Collector
Groups page controls the
forwarding of HIP Match logs
from a Panorama M-Series
appliance. The Device > Log
Settings page controls the
forwarding of HIP Match logs
directly from firewalls to
external services (without
aggregation on Panorama).
Correlation Specifies whether the administrator can Panorama: Yes Yes Yes Yes
see and configure the settings that Device Group/Template: No
control the forwarding of Correlation
logs to external services (syslog, email,
or SNMP trap servers).
If you set this privilege to read-only, the
administrator can see the Correlation
log forwarding settings but can’t
manage them.
If you disable this privilege, the
administrator can’t see or manage the
settings.
The Panorama > Collector
Groups page controls the
forwarding of Correlation logs
from a Panorama M-Series
appliance. The Device > Log
Settings page controls the
forwarding of Correlation logs
directly from firewalls to
external services (without
aggregation on Panorama).
Traffic Specifies whether the administrator can Panorama: Yes Yes Yes Yes
see and configure the settings that Device Group/Template: No
control the forwarding of Traffic logs
from a Panorama virtual appliance to
external services (syslog, email, or
SNMP trap servers).
If you set this privilege to read-only, the
administrator can see the forwarding
settings of Traffic logs but can’t manage
them.
If you disable this privilege, the
administrator can’t see or manage the
settings.
The Panorama > Collector
Groups page controls the
forwarding of Traffic logs from a
Panorama M-Series appliance.
The Objects > Log Forwarding
page controls the forwarding of
Traffic logs directly from
firewalls to external services
(without aggregation on
Panorama).
Threat Specifies whether the administrator can Panorama: Yes Yes Yes Yes
see and configure the settings that Device Group/Template: No
control the forwarding of Threat logs
from a Panorama virtual appliance to
external services (syslog, email, or
SNMP trap servers).
If you set this privilege to read-only, the
administrator can see the forwarding
settings of Threat logs but can’t manage
them.
If you disable this privilege, the
administrator can’t see or manage the
settings.
The Panorama > Collector
Groups page controls the
forwarding of Threat logs from a
Panorama M-Series appliance.
The Objects > Log Forwarding
page controls the forwarding of
Threat logs directly from
firewalls to external services
(without aggregation on
Panorama).
Wildfire Specifies whether the administrator can Panorama: Yes Yes Yes Yes
see and configure the settings that Device Group/Template: No
control the forwarding of WildFire logs
from a Panorama virtual appliance to
external services (syslog, email, or
SNMP trap servers).
If you set this privilege to read-only, the
administrator can see the forwarding
settings of WildFire logs but can’t
manage them.
If you disable this privilege, the
administrator can’t see or manage the
settings.
The Panorama > Collector
Groups page controls the
forwarding of WildFire logs
from a Panorama M-Series
appliance. The Objects > Log
Forwarding page controls the
forwarding of WildFire logs
directly from firewalls to
external services (without
aggregation on Panorama).
Server Profiles Sets the default state, enabled or Panorama: Yes Yes No Yes
disabled, for all the server profile Device Group/Template: No
privileges.
These privileges pertain only to
the server profiles that are used
for forwarding logs that
Panorama generates or collects
from firewalls and the server
profiles that are used for
authenticating Panorama
administrators. The Device >
Server Profiles pages control
the server profiles that are used
for forwarding logs directly from
firewalls to external services
(without aggregation on
Panorama) and for
authenticating firewall
administrators.
SNMP Trap Specifies whether the administrator can Panorama: Yes Yes Yes Yes
see and configure SNMP trap server Device Group/Template: No
profiles.
If you set this privilege to read-only, the
administrator can see SNMP trap server
profiles but can’t manage them.
If you disable this privilege, the
administrator can’t see or manage
SNMP trap server profiles.
Syslog Specifies whether the administrator can Panorama: Yes Yes Yes Yes
see and configure Syslog server profiles. Device Group/Template: No
If you set this privilege to read-only, the
administrator can see Syslog server
profiles but can’t manage them.
If you disable this privilege, the
administrator can’t see or manage
Syslog server profiles.
Email Specifies whether the administrator can Panorama: Yes Yes Yes Yes
see and configure email server profiles. Device Group/Template: No
If you set this privilege to read-only, the
administrator can see email server
profiles but can’t manage them.
If you disable this privilege, the
administrator can’t see or manage email
server profiles.
RADIUS Specifies whether the administrator can Panorama: Yes Yes Yes Yes
see and configure the RADIUS server Device Group/Template: No
profiles that are used to authenticate
Panorama administrators.
If you set this privilege to read-only, the
administrator can see the RADIUS
server profiles but can’t manage them.
If you disable this privilege, the
administrator can’t see or manage the
RADIUS server profiles.
TACACS+ Specifies whether the administrator can Panorama: Yes Yes Yes Yes
see and configure the TACACS+ server Device Group/Template: No
profiles that are used to authenticate
Panorama administrators.
If you disable this privilege, the
administrator can’t see the node or
configure settings for the TACACS+
servers that authentication profiles
reference.
If you set this privilege to read-only, the
administrator can view existing
TACACS+ server profiles but can’t add
or edit them.
LDAP Specifies whether the administrator can Panorama: Yes Yes Yes Yes
see and configure the LDAP server Device Group/Template: No
profiles that are used to authenticate
Panorama administrators.
If you set this privilege to read-only, the
administrator can see the LDAP server
profiles but can’t manage them.
If you disable this privilege, the
administrator can’t see or manage the
LDAP server profiles.
Kerberos Specifies whether the administrator can Panorama: Yes Yes Yes Yes
see and configure the Kerberos server Device Group/Template: No
profiles that are used to authenticate
Panorama administrators.
If you set this privilege to read-only, the
administrator can see the Kerberos
server profiles but can’t manage them.
If you disable this privilege, the
administrator can’t see or manage the
Kerberos server profiles.
Scheduled Specifies whether the administrator can Panorama: Yes Yes No Yes
Config Export view, add, edit, delete, or clone Device Group/Template: No
scheduled Panorama configuration
exports.
If you set this privilege to read-only, the
administrator can view the scheduled
exports but can’t manage them.
If you disable this privilege, the
administrator can’t see or manage the
scheduled exports.
Software Specifies whether the administrator Panorama: Yes Yes Yes Yes
can: view information about Panorama Device Group/Template: No
software updates; download, upload, or
install the updates; and view the
associated release notes.
If you set this privilege to read-only, the
administrator can view information
about Panorama software updates and
view the associated release notes but
can’t perform any related operations.
If you disable this privilege, the
administrator can’t see Panorama
software updates, see the associated
release notes, or perform any related
operations.
This privilege pertains only to
software installed on a
Panorama management server.
The Panorama > Device
Deployment > Software page
controls access to PAN-OS
software deployed on firewalls
and Panorama software
deployed on Dedicated Log
Collectors.
Dynamic Specifies whether the administrator Panorama: Yes Yes Yes Yes
Updates can: view information about Panorama Device Group/Template: No
content updates (for example, WildFire
updates); download, upload, install, or
revert the updates; and view the
associated release notes.
If you set this privilege to read-only, the
administrator can view information
about Panorama content updates and
view the associated release notes but
can’t perform any related operations.
If you disable this privilege, the
administrator can’t see Panorama
content updates, see the associated
release notes, or perform any related
operations.
This privilege pertains only to
content updates installed on a
Panorama management server.
The Panorama > Device
Deployment > Dynamic
Updates page controls access to
content updates deployed on
firewalls and Dedicated Log
Collectors.
Support Specifies whether the administrator Panorama: Yes Yes Yes Yes
can: view Panorama support license Device Group/Template: No
information, product alerts, and security
alerts; activate a support license,
generate Tech Support files, and
manage cases
If you set this privilege to read-only, the
administrator can view Panorama
support information, product alerts, and
security alerts, but can’t activate a
support license, generate Tech Support
files, or manage cases.
If you disable this privilege, the
administrator can’t: see Panorama
support information, product alerts, or
security alerts; activate a support
license, generate Tech Support files, or
manage cases.
Device Sets the default state, enabled or Panorama: Yes Yes No Yes
Deployment disabled, for all the device deployment Device Group/Template: Yes
privileges.
These privilege pertain only to
software and content updates
that Panorama administrators
deploy on firewalls and
Dedicated Log Collectors. The
Panorama > Software and
Panorama > Dynamic Updates
pages control the software and
content updates installed on a
Panorama management server.
Software Specifies whether the administrator Panorama: Yes Yes Yes Yes
can: view information about the Device Group/Template: Yes
software updates installed on firewalls
and Log Collectors; download, upload,
or install the updates; and view the
associated release notes.
If you set this privilege to read-only, the
administrator can see information about
the software updates and view the
associated release notes but can’t
deploy the updates to firewalls or
dedicated Log Collectors.
If you disable this privilege, the
administrator can’t see information
about the software updates, see the
associated release notes, or deploy the
updates to firewalls or Dedicated Log
Collectors.
SSL VPN Client Specifies whether the administrator Panorama: Yes Yes Yes Yes
can: view information about SSL VPN Device Group/Template: Yes
client software updates on firewalls;
download, upload, or activate the
updates; and view the associated
release notes.
If you set this privilege to read-only, the
administrator can see information about
SSL VPN client software updates and
view the associated release notes but
can’t activate the updates on firewalls.
If you disable this privilege, the
administrator can’t see information
about SSL VPN client software updates,
see the associated release notes, or
activate the updates on firewalls.
GlobalProtect Specifies whether the administrator Panorama: Yes Yes Yes Yes
Client can: view information about Device Group/Template: Yes
GlobalProtect agent/app software
updates on firewalls; download, upload,
or activate the updates; and view the
associated release notes.
If you set this privilege to read-only, the
administrator can see information about
GlobalProtect agent/app software
updates and view the associated release
notes but can’t activate the updates on
firewalls.
If you disable this privilege, the
administrator can’t see information
about GlobalProtect agent/app
software updates, see the associated
release notes, or activate the updates
on firewalls.
Dynamic Specifies whether the administrator Panorama: Yes Yes Yes Yes
Updates can: view information about the content Device Group/Template: Yes
updates (for example, Applications
updates) installed on firewalls and
Dedicated Log Collectors; download,
upload, or install the updates; and view
the associated release notes.
If you set this privilege to read-only, the
administrator can see information about
the content updates and view the
associated release notes but can’t
deploy the updates to firewalls or
Dedicated Log Collectors.
If you disable this privilege, the
administrator can’t see information
about the content updates, see the
associated release notes, or deploy the
updates to firewalls or Dedicated Log
Collectors.
Licenses Specifies whether the administrator can Panorama: Yes Yes Yes Yes
view, refresh, and activate firewall Device Group/Template: Yes
licenses.
If you set this privilege to read-only, the
administrator can view firewall licenses
but can’t refresh or activate those
licenses.
If you disable this privilege, the
administrator can’t view, refresh, or
activate firewall licenses.
Master Key and Specifies whether the administrator can Panorama: Yes Yes Yes Yes
Diagnostics view and configure a master key by Device Group/Template: No
which to encrypt private keys on
Panorama.
If you set this privilege to read-only, the
administrator can view the Panorama
master key configuration but can’t
change it.
If you disable this privilege, the
administrator can’t see or edit the
Panorama master key configuration.
The custom Panorama administrator roles allow you to define access to the options 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.
Dashboard Controls access to the Dashboard tab. If you disable Yes No Yes
this privilege, the administrator will not see the tab
and will not have access to any of the Dashboard
widgets.
Monitor Controls access to the Monitor tab. If you disable this Yes No Yes
privilege, the administrator will not see the Monitor
tab and will not have access to any of the logs, packet
captures, session information, reports or to App
Scope. For more granular control over what
monitoring information the administrator can see,
leave the Monitor option 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 disable this Yes No Yes
privilege, the administrator will not see the Policies
tab and will not have access to any policy information.
For more granular control over what policy
information the administrator can see, for example to
enable access to a specific type of policy or to enable
read-only access to policy information, leave the
Policies option enabled and then enable or disable
specific nodes on the tab as described in Provide
Granular Access to the Policy Tab.
Objects Controls access to the Objects tab. If you disable this Yes No Yes
privilege, the administrator will not see the Objects
tab and will not have access to any objects, security
profiles, log forwarding profiles, decryption profiles,
or schedules. For more granular control over what
objects the administrator can see, leave the Objects
option 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 disable this Yes No Yes
privilege, the administrator 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 configuration
information or to the network profiles. For more
granular control over what objects the administrator
can see, leave the Network option enabled and then
enable or disable specific nodes on the tab as
described in Provide Granular Access to the Network
Tab.
Device Controls access to the Device tab. If you disable this Yes No Yes
privilege, the administrator will not see the Device tab
and will not have access to any firewall-wide
configuration information, such as User-ID, High
Availability, server profile or certificate configuration
information. For more granular control over what
objects the administrator can see, leave the Device
option enabled and then enable or disable specific
nodes on the tab as described in 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 tab. If you disable Yes No Yes
this privilege, the administrator will not see the
Panorama tab and will not have access to any
Panorama-wide configuration information, such as
Managed Devices, Managed Collectors, or Collector
Groups.
For more granular control over what objects the
administrator can see, leave the Panorama option
enabled and then enable or disable specific nodes on
the tab as described in Provide Granular Access to the
Panorama Tab.
Commit Sets the default state (enabled or disabled) for all the Yes No Yes
commit settings described below (Panorama, Device
Groups, Templates, Force Template Values, Collector
Groups).
Force Template Values This privilege controls access to the Force Template Yes No Yes
Values option in the Commit dialog.
When disabled, an administrator cannot replace
overridden settings in local firewall configurations
with settings that Panorama pushes from a template.
Global Controls access to the global settings (system alarms) Yes No Yes
described in Provide Granular Access to Global
Settings.
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 Functions
Ports Used for HA
Ports Used for Panorama
Ports Used for GlobalProtect
Ports Used for User-ID
The firewall and Panorama use the following ports for management functions.
22 TCP Used for communication from a client system to the firewall CLI interface.
80 TCP The port the firewall listens on for Online Certificate Status Protocol (OCSP)
updates when acting as an OCSP responder.
443 TCP Used for communication from a client system to the firewall web interface. This is
also the port the firewall and User-ID agent listens on for VM Information source
updates.
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.
162 UDP Port the firewall, Panorama, or a Log Collector uses to Forward Traps to an SNMP
Manager.
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 documentation of
your SNMP management software.
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
514 UDP server if you Configure Syslog Monitoring, and the ports that the PAN-OS
integrated User-ID agent or Windows-based User-ID agent listens on for
6514 SSL authentication syslog messages if you Configure User-ID to Receive User
Mappings from a Syslog Sender.
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 Captive Portal: 6080 for NT LAN Manager (NTLM) authentication,
6081 TCP 6081 for Captive Portal in transparent mode, and 6082 for Captive Portal in
redirect mode.
6082 TCP
Firewalls configured as High Availability (HA) peers must be able to communicate with each other to
maintain state information (HA1 control link) and synchronize data (HA2 data link). In Active/Active 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 encryption.
28769 TCP Used for the HA1 control link for clear text communication between the HA peer
28260 TCP firewalls. The HA1 link is a Layer 3 link and requires an IP address.
28 TCP Used for the HA1 control link for encrypted communication (SSH over TCP)
between the HA peer firewalls.
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
29281 UDP associations and ARP tables between firewalls in an HA pair. Data flow on the
HA2 link is always unidirectional (except for the HA2 keep-alive); it flows from the
active firewall (Active/Passive) or active-primary (Active/Active) to the passive
firewall (Active/Passive) or active-secondary (Active/Active). 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.
22 TCP Used for communication from a client system to the Panorama CLI interface.
443 TCP Used for communication from a client system to the Panorama web interface.
3978 TCP Used for communication between Panorama and managed firewalls or managed
collectors, as well as for communication among managed collectors in a Collector
Group:
• For communication between Panorama and firewalls, this is a bi-directional
connection on which the firewalls forward logs to Panorama and Panorama
pushes configuration changes to the firewalls. Context switching commands
are sent over the same connection.
• Log Collectors use this destination port to forward logs to Panorama.
• For communication with the default Log Collector on an M-Series appliance in
Panorama mode and with Dedicated Log Collectors (M-Series appliances in Log
Collector mode).
28769 (5.1 and later) TCP Used for the HA connectivity and synchronization between Panorama HA peers
28260 (5.0 and later) TCP using clear text communication. Communication can be initiated by either peer.
28 TCP Used for the HA connectivity and synchronization between Panorama HA peers
using encrypted communication (SSH over TCP). Communication can be initiated
by either peer.
28270 (6.0 and later) TCP Used for communication among Log Collectors in a Collector Group for log
49190 (5.1 and distribution.
earlier)
2049 TCP Used by the Panorama virtual appliance to write logs to the NFS datastore.
443 TCP Used for communication between GlobalProtect agents and portals, or
GlobalProtect agents and gateways and for SSL tunnel connections.
GlobalProtect gateways also use this port to collect host information from
GlobalProtect agents and perform host information profile (HIP) checks.
4501 UDP Used for IPSec tunnel connections between GlobalProtect agents and gateways.
For tips 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 to be Accessed on any Port?.
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 activity on your network (for example, to be able
to quickly track down a user who may be the victim 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 Services agent must be able to connect to directory services on your network
to perform Group Mapping and User Mapping. Additionally, 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 communication requirements for User-ID along with
the port numbers required to establish connections.
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 Active Directory global catalog server
(plaintext or Start TLS) to Map Users to Groups.
636 TCP Port the firewall uses for LDAP over SSL connections with an LDAP server to Map
Users to Groups.
3269 TCP Port the firewall uses for LDAP over SSL connections with an Active Directory
global catalog server to Map Users to Groups.
514 TCP Port the PAN-OS integrated User-ID agent or Windows-based User-ID agent
514 UDP listens on for authentication syslog messages if you Configure User-ID to Receive
User Mappings from a Syslog Sender.
6514 SSL
5007 TCP Port the firewall listens on for user mapping information from the User-ID or
Terminal Services agent. The agent sends the IP address and username mapping
along with a timestamp whenever it learns of a new or updated mapping. In
addition, 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
communication is typically the system running a script that invokes the API.
88 UDP/TCP Port the User-ID agent uses to authenticate to a Kerberos server. The firewall
tries UDP first and falls back to TCP.
1812 UDP Port the User-ID agent uses to authenticate to a RADIUS server.
135 TCP Port the User-ID agent uses to establish TCP-based WMI connections with the
Microsoft 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 connection to make RPC queries for Exchange Server or AD
server security logs, session tables. This is also the port used to access Terminal
Services.
The User-ID agent also uses this port to connect to client systems to perform
Windows Management Instrumentation (WMI) probing.
139 TCP Port the User-ID agent uses to establish TCP-based NetBIOS connections to the
AD server so that it can send RPC queries for security logs and session
information.
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 Active Directory (AD) using
TCP-based SMB connections to the AD server for access to user logon
information (print spooler and Net Logon).
Resetting the firewall to factory defaults will result in the loss of all configuration settings and logs.
Reset the Firewall to Factory Default Settings
Step 1 Set up a console connection to the 1. Connect a serial cable from your computer to the Console port
firewall. and connect to the firewall using terminal emulation software
(9600-8-N-1).
If your computer does not have a 9-pin serial port, use
a USB-to-serial port connector.
Step 2 Reset the system to factory default 1. When the firewall reboots, press Enter to continue to the
settings. maintenance mode menu.
2. Select Factory Reset and press Enter.
3. Select Factory Reset and press Enter again.
The firewall will reboot without any configuration settings.
The default username and password to log in to the firewall is
admin/admin.
To perform initial configuration on the firewall and to set up
network connectivity, see Integrate the Firewall into Your
Management Network.
Bootstrapping speeds up the process of configuring and licensing the firewall to make it operational on the
network with or without Internet access. Bootstrapping allows you to choose whether to configure the
firewall with a basic configuration file (init-cfg.txt) so that it can connect to Panorama and obtain the
complete configuration or to fully configure the firewall with the basic configuration and the optional
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
The USB flash drive that bootstraps a hardware-based Palo Alto Networks firewall must support one of the
following:
File Allocation Table 32 (FAT32)
Third Extended File System (ext3)
The firewall can bootstrap from the following flash drives with USB2.0 or USB3.0 connectivity:
USB Flash Drives Supported
An init-cfg.txt file is required for the bootstrap process; this file is a basic configuration file that you create
using a text editor. You create this file is Step 5 in Prepare a USB Flash Drive for Bootstrapping a Firewall.
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 (Static 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-gateway=2001:400:f00::2 ipv6-default-gateway=
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-vsys,jumbo-frame op-command-modes=multi-vsys,jumbo-frame
dhcp-send-hostname=no dhcp-send-hostname=yes
dhcp-send-client-id=no dhcp-send-client-id=yes
dhcp-accept-server-hostname=no dhcp-accept-server-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 static, the IP
address, default gateway and netmask are required, or the IPv6 address and IPv6 default gateway are
required.
Fields in the init‐cfg.txt File
Field Description
ip-address (Required for IPv4 static management address) IPv4 address. The firewall ignores this
field if the type is dhcp-client.
default-gateway (Required for IPv4 static management address) IPv4 default gateway for the
management interface. The firewall ignores this field if the type is dhcp-client.
netmask (Required for IPv4 static management address) IPv4 netmask. The firewall ignores
this field if the type is dhcp-client.
ipv6-address (Required for IPv6 static management address) IPv6 address and /prefix length of the
management interface. The firewall ignores this field if the type is dhcp-client.
ipv6-default-gateway (Required for IPv6 static management address) IPv6 default gateway for the
management interface. The firewall ignores this field if the type is dhcp-client.
Fields in the init‐cfg.txt File
Field Description
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-hostname (DHCP client type only) The DHCP server determines a value of yes or no. If yes, the
firewall accepts its hostname from the DHCP server.
dhcp-accept-server-domain (DHCP client type only) The DHCP server determines a value of yes or no. If yes, the
firewall accepts its DNS server from the DHCP server.
You can use a USB flash drive to bootstrap a physical firewall. However, to do so you must upgrade to
PAN-OS 7.1 and Reset the Firewall to Factory Default Settings. For security reasons, you can bootstrap a
firewall only when it is in factory default state or has all private data deleted.
Prepare a USB Flash Drive for Bootstrapping a Firewall
Step 2 Register S/Ns of new firewalls on the 1. Go to support.paloaltonetworks.com, log in, and select Assets
Customer Support portal. > Register New Device > Register device using Serial
Number or Authorization Code.
2. Follow the steps to Register the Firewall.
3. Click Submit.
Prepare a USB Flash Drive for Bootstrapping a Firewall (Continued)
Step 3 Activate authorization codes on the 1. Go to support.paloaltonetworks.com, log in, and select the
Customer Support portal, which creates Assets tab.
license keys. 2. For each S/N you just registered, click the Action link.
3. Select Activate Auth-Code.
4. Enter the Authorization 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
configuration 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 multiple 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 (Optional) Create the bootstrap.xml file. The optional bootstrap.xml file is a complete firewall configuration
that you can export from an existing production firewall.
1. Select Device > Setup > Operations > Export named
configuration snapshot.
2. Select the Name of the saved or the running configuration.
3. Click OK.
4. Rename the file as bootstrap.xml.
Prepare a USB Flash Drive for Bootstrapping a Firewall (Continued)
Step 7 Create and download the bootstrap Use one of the following methods to create and download the
bundle from the Customer Support bootstrap bundle:
portal. • Use Method 1 to create a bootstrap bundle specific to a remote
For a physical firewall, the bootstrap site (you have only one init-cfg.txt file).
bundle requires only the /license and • Use Method 2 to create one bootstrap bundle for multiple sites.
/config directories.
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. (Optional) 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.
Step 8 Import the tar.gz file you created to a Access the CLI and enter one of the following commands:
PAN-OS 7.1 firewall using Secure Copy • tftp import bootstrap-bundle file <path and filename>
(SCP) or TFTP. 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_b
ootstrap_bundle.tar.gz
Prepare a USB Flash Drive for Bootstrapping a Firewall (Continued)
Step 9 Prepare the USB flash drive. 1. Insert the USB flash drive into the firewall that you used in
Step 8.
2. Enter the following CLI operational 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 continue. 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 If you used Method 2 to create the bootstrap bundle, you can use
remote site. the same USB flash drive content for bootstrapping firewalls at
multiple remote sites. You can translate the content into multiple
USB flash drives or a single USB flash drive used multiple times.
After you receive a new Palo Alto Networks firewall and a USB flash drive loaded with bootstrap files, you
can bootstrap the firewall.
Microsoft Windows and Apple Mac operating systems are unable to read the bootstrap USB flash
drive because the drive is formatted using an ext4 file system. You must install third-party
software or use a Linux system to read the USB drive.
Bootstrap a Firewall Using a USB Flash Drive
Step 1 The firewall must be in a factory default state or must have all private data deleted.
Step 2 To ensure connectivity with your corporate headquarters, cable the firewall by connecting 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.
Bootstrap a Firewall Using a USB Flash Drive
Step 4 Verify bootstrap completion. 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 settings and configuration by accessing the web interface and selecting
Dashboard > Widgets > System or by using the CLI operational commands show system info and show
config running.
3. Verify the license installation by selecting Device > Licenses or by using the CLI operational command
request license info.
4. If you have Panorama configured, manage the content versions and software versions from Panorama.
If you do not have Panorama configured, use the web interface to manage content versions and
software versions.
An authentication profile defines the authentication service that validates the login credentials of firewall or
Panorama administrators and Captive Portal or GlobalProtect end users. The authentication service can be
a local database (firewalls only), an external service (RADIUS, TACACS+, LDAP, or Kerberos server), or
Kerberos single sign-on (SSO).
Some networks have multiple databases for different users and user groups (for example, TACACS+ and
LDAP). To authenticate users in such cases, configure an authentication sequence, which is a ranked order
of authentication profiles that the firewall or Panorama matches a user against during login. The firewall or
Panorama checks against each profile in sequence until one successfully authenticates the user (the firewall
always checks the local database first if the sequence includes one). A user is denied access only if
authentication fails for all the profiles in the authentication sequence.
Configure an Authentication Profile and Sequence
Step 1 Create a Kerberos keytab. Create a Kerberos keytab. A keytab is a file that contains Kerberos
Required if the firewall or Panorama will account information (principal name and hashed password) for the
use Kerberos SSO authentication. firewall or Panorama.
Step 2 Configure a local database (firewall only) • Local database authentication—Perform the following tasks:
or external server profile (firewall or a. Configure the user account.
Panorama). b. (Optional) Configure a user group.
Required for local database or external • External authentication—Perform one of the following tasks:
authentication.
• Configure a RADIUS Server Profile.
• Configure a TACACS+ Server Profile.
• Configure an LDAP Server Profile.
• Configure a Kerberos Server Profile.
Configure an Authentication Profile and Sequence (Continued)
Step 3 Configure an authentication profile. 1. Select Device > Authentication Profile and Add the
Define one or both of the following: authentication profile.
• Kerberos SSO—The firewall or 2. Enter a Name to identify the authentication profile.
Panorama first tries SSO 3. If the firewall has more than one virtual system (vsys), select a
authentication. If that fails, it falls back Location (a vsys or Shared) where the profile is available.
to the specified authentication Type.
4. Select the authentication Type. If you select RADIUS,
• Local database or external
TACACS+, LDAP, or Kerberos, select the authentication
authentication—The firewall or
Server Profile from the drop-down.
Panorama prompts the user to enter
login credentials, and uses its local If the Type is LDAP, define the Login Attribute. For
database (firewalls only) or an external Active Directory, enter sAMAccountName as the
service to authenticate the user. value.
5. (Optional) Select the User Domain and Username Modifier
options as follows to modify the domain/username string that
the user will enter during login. This is useful when the
authentication service requires the string in a particular format
and you don’t want to rely on users to correctly enter the
domain.
• To send only the unmodified user input, leave the User
Domain blank (the default) and set the Username Modifier
to the variable %USERINPUT% (the default).
• To prepend a domain to the user input, enter a User
Domain and set the Username Modifier to
%USERDOMAIN%\%USERINPUT%.
• To append a domain to the user input, enter a User Domain
and set the Username Modifier to
%USERINPUT%@%USERDOMAIN%.
6. 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.
7. Select Advanced and Add the users and groups that can
authenticate with this profile. You can select users and groups
from the local database or, if you configured an LDAP server
profile, from an LDAP-based directory service such as Active
Directory. Selecting all allows every user to authenticate. By
default, the list is empty, meaning no users can authenticate.
You can also create and allow custom groups based on
LDAP filters: see Map Users to Groups.
Configure an Authentication Profile and Sequence (Continued)
Step 4 Configure an authentication sequence. 1. Select Device > Authentication Sequence and Add the
Required if you want the firewall or authentication sequence.
Panorama to try multiple authentication 2. Enter a Name to identify the authentication sequence.
profiles to authenticate users. The
3. If the firewall has more than one virtual system (vsys), select a
firewall or Panorama evaluates the
Location (a vsys or Shared) where the sequence is available.
profiles in top-to-bottom order until one
profile successfully authenticates the To expedite the authentication process, the best
user. practice is to Use domain to determine authentication
profile: the firewall or Panorama will match the domain
name that a user enters during login with the User
Domain or Kerberos Realm of an authentication
profile in the sequence, and then use that profile to
authenticate the user. If the firewall or Panorama
doesn’t find a match, or if you clear the check box, it
tries the profiles in the top-to-bottom sequence.
4. Add each authentication profile. To change the evaluation
order of the profiles, select a profile and Move Up or Move
Down.
5. Click OK to save the authentication sequence.
Step 5 Assign the authentication profile or Assign the authentication profile or sequence to an administrator
sequence. account or to a firewall service for end users.
Test Authentication Server Connectivity to verify that an
authentication profile can communicate with the back-end
authentication server and that the authentication request
succeeded.
Palo Alto Networks firewalls and Panorama support Kerberos V5 single sign-on (SSO) to authenticate
administrators to the web interface and end users to Captive Portal. A network that supports Kerberos SSO
prompts a user to log in only for initial access to the network (for example, logging in to Microsoft Windows).
After this initial login, the user can access any browser-based service in the network (for example, the firewall
web interface) without having to log in again until the SSO session expires. (Your Kerberos administrator sets
the duration of SSO sessions.) If you enable both Kerberos SSO and external authentication services (for
example, a RADIUS server), the firewall or Panorama first tries SSO and, only if that fails, falls back to the
external service for authentication.
To support Kerberos SSO, your network requires:
A Kerberos infrastructure, including a key distribution center (KDC) with an authentication server (AS)
and ticket-granting service (TGS).
A Kerberos account for the firewall or Panorama that will authenticate 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.
Configure Kerberos Single Sign‐On
Step 1 Create a Kerberos keytab. 1. Log in to the KDC and open a command prompt.
2. Enter the following command, where <principal_name>,
<password>, and <algorithm> are variables. The Kerberos
principal name and password are of the firewall or Panorama,
not the user.
ktpass /princ <principal_name> /pass
<password> /crypto <algorithm> /ptype
KRB5_NT_PRINCIPAL /out <file_name>.keytab
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 Encryption Standard (AES) algorithm, the
functional level of the KDC must be Windows Server
2008 or later and you must enable AES encryption for
the firewall or Panorama account.
The algorithm in the keytab must match the algorithm
in the service ticket that the TGS issues to clients. Your
Kerberos administrator determines which algorithms
the service tickets use.
Step 2 Import the keytab into an authentication Configure an Authentication Profile and Sequence:
profile. 1. Enter the Kerberos Realm (usually the DNS domain of the
users, except that the realm is uppercase).
2. Import the Kerberos Keytab that you created for the firewall
or Panorama.
You can use a local firewall database instead of an external service to manage user account credentials and
authentication. For example, you might create a local database of users and user groups for specialized
purposes if you don’t have permission to add them to the directory servers that your organization uses to
manage regular accounts and groups. Local database authentication is available for firewall administrators
and for Captive Portal and GlobalProtect end users.
If your network supports Kerberos single sign-on (SSO), you can configure local authentication as
a fall-back in case SSO fails. For details, see Configure Kerberos SSO and External or Local
Authentication for Administrators.
You can also Configure an Administrative Account to use local account management and
authentication without a local database, but only for firewall administrators.
Configure Local Database Authentication
Step 1 Configure the user account. 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 Configure a user group. 1. Select Device > Local User Database > User Groups and click
Required if your users require group Add.
membership. 2. Enter a Name to identify the group.
3. Add each user who is a member of the group and click OK.
Step 3 Configure an authentication profile. Set the authentication Type to Local Database.
Step 5 Verify that the firewall can communicate Test a Local Database Authentication Profile.
with the authentication server.
Palo Alto Networks firewalls and Panorama can use external servers for many services that require
authentication, including administrator access to the web interface and end user access to Captive Portal,
GlobalProtect portals and GlobalProtect gateways. The server protocols that firewalls and Panorama
support include Lightweight Directory Access Protocol (LDAP), Kerberos, Terminal Access Controller
Access-Control System Plus (TACACS+), and Remote Authentication Dial-In User Service (RADIUS). If you
enable both external authentication and Kerberos single sign-on (SSO), the firewall or Panorama first tries
SSO and, only if that fails, falls back to the external server for authentication. To configure external
authentication, you create an authentication server profile, assign it to an authentication profile, and then
enable authentication for an administrator account or firewall/Panorama service by assigning the
authentication profile to it.
Configure Authentication Server Profiles
Enable External Authentication for Users and Services
You can configure the firewall or Panorama to use a RADIUS server for managing administrator accounts.
You can also configure the firewall to use a RADIUS server for authenticating end users and collecting
RADIUS Vendor-Specific Attributes (VSAs) from GlobalProtect clients. To use a RADIUS server for managing
administrator accounts or collecting GlobalProtect clients VSAs, you must define VSAs on the RADIUS
server. For details, see the list of supported RADIUS Vendor-Specific Attributes Support.
By default, when authenticating to the RADIUS server, the firewall or Panorama first tries
Challenge-Handshake Authentication Protocol (CHAP) and falls back to Password Authentication
Protocol (PAP) under certain conditions. Optionally, you can override this automatic protocol
selection and configure the firewall or Panorama to always use a specific protocol. For details, see
Set CHAP or PAP Authentication for RADIUS Servers.
When sending authentication requests to a RADIUS server, the firewall and Panorama use the
authentication profile name as the network access server (NAS) identifier, even if the profile is
assigned to an authentication sequence for the service that initiates the authentication process.
Configure a RADIUS Server Profile
Step 1 Add a RADIUS server profile. 1. Select Device > Server Profiles > RADIUS and click Add.
2. Enter a Profile Name to identify the server profile.
3. For a firewall with more than one virtual system (vsys), select
the Location (vsys or Shared) where the profile is available.
4. For the Timeout, enter an interval in seconds after which an
authentication request times out (range is 1-30, default is 3).
5. Enter the number of automatic Retries following a Timeout
before the request fails (range is 1-5, default is 3).
6. For each RADIUS server, click Add and enter a Name (to
identify the server), server IP address or FQDN (RADIUS
Server field), Secret/Confirm Secret (a key to encrypt
passwords), and server Port for authentication requests
(default is 1812).
If you use an FQDN address object to identify the
server and you subsequently change the address, you
must commit the change for the new server address to
take effect.
7. Click OK.
Step 2 Implement the RADIUS server profile. 1. Assign the RADIUS server profile to an authentication profile
or sequence.
2. Test a RADIUS Authentication Profile to verify that the
firewall or Panorama can connect to the RADIUS server.
3. Assign the authentication profile or sequence to an
administrator account or to a firewall service for end users.
4. Commit your changes.
When you configure the firewall to use RADIUS server authentication for a particular service (such as
Captive Portal), it first tries Challenge-Handshake Authentication Protocol (CHAP) and falls back to
Password Authentication Protocol (PAP) if the server rejects the CHAP request. This will happen if, for
example, the server doesn’t support CHAP or isn’t configured for CHAP. CHAP is the preferred protocol
because it is more secure than PAP. After falling back to PAP for a particular RADIUS server, the firewall uses
only PAP in subsequent attempts to authenticate to that server. The firewall records a fall back to PAP as a
medium severity event in the System logs. If you modify any fields in the RADIUS server profile and then
commit the changes, the firewall reverts to first trying CHAP for that server.
If you want the firewall to always use a specific protocol for authenticating to the RADIUS server, enter the
following operational CLI command (the auto option reverts to the default automatic selection):
set authentication radius-auth-type [ auto | chap | pap ]
When configuring a RADIUS server for CHAP, you must define user accounts with reversibly
encrypted passwords. Otherwise, CHAP authentication will fail.
Palo Alto Networks firewalls and Panorama support the following RADIUS Vendor-Specific Attributes
(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.
PaloAlto-Panorama-Admin-Access-Domain 4 The name of an access domain for Device Group and Template
administrators (configured in the Panorama > Access Domains
page).
PaloAlto-Client-Source-IP 7
PaloAlto-Client-OS 8
PaloAlto-Client-Hostname 9
PaloAlto-GlobalProtect-Client-Version 10
Terminal Access Controller Access-Control System Plus (TACACS+) protocol provides better Authentication
security than RADIUS because it encrypts usernames and passwords (instead of just passwords), and is also
more reliable (it uses TCP instead of UDP).
When authenticating to the TACACS+ server, the firewall first tries Challenge-Handshake Authentication
Protocol (CHAP) and falls back to Password Authentication Protocol (PAP) if the server rejects the CHAP
request. This will happen if, for example, the server doesn’t support CHAP or isn’t configured for CHAP.
CHAP is the preferred protocol because it is more secure than PAP. After falling back to PAP for a particular
TACACS+ server, the firewall uses only PAP in subsequent attempts to authenticate to that server. The
firewall records a fall back to PAP as a medium severity event in the System logs. If you modify any fields in
the TACACS+ server profile and then commit the changes, the firewall reverts to first trying CHAP for that
server.
Configure a TACACS+ Server Profile
Step 1 Add a TACACS+ server profile. 1. Select Device > Server Profiles > TACACS+ and click Add.
2. Enter a Profile Name to identify the server profile.
3. For a firewall with more than one virtual system (vsys), select
the Location (vsys or Shared) where the profile is available.
4. For the Timeout, enter an interval in seconds after which an
authentication request times out (range is 1-20, default is 3).
5. Select the Use single connection for all authentication check
box to use the same TCP session for all authentications that
use this profile. This option improves performance by avoiding
the need to start and end a separate TCP session for each
authentication. The check box is cleared by default.
6. For each TACACS+ server, click Add and enter a Name (to
identify the server), server IP address or FQDN (TACACS+
Server field), Secret/Confirm Secret (a key to encrypt
usernames and passwords), and server Port for authentication
requests (default is 49).
If you use an FQDN address object to identify the
server and you subsequently change the address, you
must commit the change for the new server address to
take effect.
7. Click OK.
Step 2 Implement the TACACS+ server profile. 1. Assign the TACACS+ server profile to an authentication
profile or sequence.
2. Test a TACACS+ Authentication Profile to verify that the
firewall or Panorama can connect to the TACACS+ server.
3. Assign the authentication profile or sequence to an
administrator account or to a firewall service for end users.
4. Commit your changes.
Configure an LDAP Server Profile
Step 1 Add an LDAP server profile. 1. Select Device > Server Profiles > LDAP and click Add.
2. Enter a Profile Name to identify the server profile.
3. For a firewall with more than one virtual system (vsys), select
the Location (vsys or Shared) where the profile is available.
4. For each LDAP server (up to four), click Add and enter a Name
(to identify the server), server IP address (LDAP Server field),
and server Port (default 389).
5. Select the server Type from the drop-down: active-directory,
e-directory, sun, or other.
6. If you want the firewall or Panorama to use SSL or TLS for a
more secure connection with the directory server, select the
Require SSL/TLS secured connection check box (it is selected
by default). The protocol that the firewall or Panorama uses
depends on the server Port:
• 389 (default)—TLS (Specifically, the firewall or Panorama
uses the Start TLS operation, which upgrades the initial
plaintext connection to TLS.)
• 636—SSL
• Any other port—The firewall or Panorama first tries to use
TLS. If the directory server doesn’t support TLS, the firewall
or Panorama falls back to SSL.
7. To improve security, you can select the Verify Server
Certificate for SSL sessions check box (it is cleared by
default) so that the firewall or Panorama verifies the certificate
that the directory server presents for SSL/TLS connections. If
the verification fails, the connection fails. To enable
verification, you must also select the Require SSL/TLS
secured connection check box. The firewall or Panorama
verifies the certificate in two respects:
• The certificate is trusted and valid. For the firewall or
Panorama to trust the certificate, its root certificate
authority (CA) and any intermediate certificates must be in
the certificate store under Device > Certificate
Management > Certificates > Device Certificates. Import
the certificate if necessary: see Import a Certificate and
Private Key.
• The certificate name must match the host Name of the
LDAP server. The firewall or Panorama first checks the
certificate attribute Subject AltName for matching, then
tries the attribute Subject DN. If the certificate uses the
FQDN of the directory server, you must enter that FQDN
in the LDAP Server field for the name matching to succeed.
8. Click OK.
Configure an LDAP Server Profile (Continued)
Step 2 Implement the LDAP server profile. 1. Assign the LDAP server profile to an authentication profile or
sequence.
2. Test an LDAP Authentication Profile to verify that the firewall
or Panorama can connect to the LDAP server.
3. Assign the authentication profile or sequence to an
administrator account or to a firewall service for end users.
4. Commit your changes.
A Kerberos server profile enables users to natively authenticate to an Active Directory domain controller or
a Kerberos V5-compliant authentication server. This authentication method is interactive, requiring users to
enter usernames and passwords, in contrast with Kerberos single sign-on (SSO), which involves transparent
authentication.
To use a Kerberos server for authentication, the server must be accessible over an IPv4 address.
IPv6 addresses are not supported.
Configure a Kerberos Server Profile
Step 1 Add a Kerberos server profile. 1. Select Device > Server Profiles > Kerberos and click Add.
2. Enter a Profile Name to identify the server profile.
3. For a firewall with more than one virtual system (vsys), select
the Location (vsys or Shared) where the profile is available.
4. For each Kerberos server, click Add and enter a Name (to
identify the server), server IPv4 address or FQDN (Kerberos
Server field), and an optional Port number for communication
with the server (default 88).
If you use an FQDN address object to identify the
server and you subsequently change the address, you
must commit the change for the new server address to
take effect.
5. Click OK.
Step 2 Implement the Kerberos server profile. 1. Assign the Kerberos server profile to an authentication profile
or sequence.
2. Test a Kerberos Authentication Profile to verify that the
firewall or Panorama can connect to the Kerberos server.
3. Assign the authentication profile or sequence to an
administrator account or to a firewall service for end users.
4. Commit your changes.
Palo Alto Networks firewalls and Panorama can use external services to authenticate administrators and end
users.
Enable External Authentication
Step 2 Assign the server profile to an 1. Configure an Authentication Profile and Sequence.
authentication profile. 2. Test Authentication Server Connectivity.
Optionally, you can assign multiple
authentication profiles to an
authentication sequence.
After you configure an authentication profile on a Palo Alto Networks firewall or Panorama, you can use the
test authentication feature to determine if it can communicate with the back-end authentication server and
if the authentication request succeeded. You can additionally test authentication profiles used for
GlobalProtect and Captive Portal authentication. You can perform authentication tests on the candidate
configuration, so that you know the configuration is correct before committing.
Authentication server connectivity testing is supported for local database, RADIUS, TACACS+, LDAP, and
Kerberos authentication.
The following topics describe how to use the test authentication command and provides examples:
Run the Test Authentication Command
Test a Local Database Authentication Profile
Test a RADIUS Authentication Profile
Test a TACACS+ Authentication Profile
Test an LDAP Authentication Profile
Test a Kerberos Authentication Profile
Run the Test Authentication Command
Step 1 On the PAN-OS firewall or Panorama server, Configure an authentication profile. You do not need to commit
the authentication or server profile configuration prior to testing.
Step 2 Using a terminal emulation application, such as PuTTY, launch an SSH session to the firewall.
Step 3 (Firewalls with virtual systems configured) Define the target virtual system that the test command will access.
This is required on firewalls with multiple virtual systems (vsys) configured, so the test authentication
command can locate the user (Global Protect or Captive Portal, for example) in the correct vsys.
To define the target vsys:
admin@PA-3060> set system setting target‐vsys <vsys‐name>
For example, if the user is defined in vsys2, run the following command:
admin@PA-3060> set system setting target‐vsys vsys2
The target-vsys command is per-login session, so the system clears the option when you log off.
Run the Test Authentication Command
The following example shows how to test a Local Database authentication profile named LocalDB for a user
named User1-LocalDB and how to troubleshoot error conditions that arise. For details on using the test
authentication command, see Run the Test Authentication Command.
Local Database Authentication Profile Test Example
Step 1 On the PAN-OS firewall, ensure that you have an administrator configured with the type Local Database. For
information on administrator accounts, refer to Manage Firewall Administrators.
Step 2 Using a terminal emulation application, such as PuTTY, launch an SSH session to the firewall.
Local Database Authentication Profile Test Example
Step 3 (Firewalls with virtual systems configured) Define the target virtual system that the test command will access.
This is required on firewalls with multiple virtual systems (vsys) configured, so the test authentication
command can locate the user (Global Protect or Captive Portal, for example) in the correct vsys.
To define the target vsys:
admin@PA-3060> set system setting target‐vsys <vsys‐name>
For example, if the user is defined in vsys2, run the following command:
admin@PA-3060> set system setting target‐vsys vsys2
The target-vsys command is per-login session, so the system clears the option when you log off.
Step 5 When prompted, enter the password for the User1-LocalDB account. The following output shows that the
test failed:
Allow list check error:
Do allow list check before sending out authentication request...
User User1-LocalDB is not allowed with authentication profile LocalDB-Profile
In this case, the last line of the output shows that the user is not allowed, which indicates a configuration
problem in the authentication profile.
Step 6 To resolve this issue, modify the authentication profile and add the user to the Allow List.
1. On the firewall, select Device > Authentication Profile and modify the profile named LocalDB-Profile.
2. Click the Advanced tab and add User1-LocalDB to the Allow List.
3. Click OK to save the change.
Step 7 Run the test command again. The following output shows that the test is successful:
Do allow list check before sending out authentication request...
name "User1-LocalDB" has an exact match in allow list
Authentication by Local User Database for user "User1-LocalDB"
Authentication succeeded for Local User Database user "User1-LocalDB"
The following example shows how to test a RADIUS profile named RADIUS-Profile for a user named
User2-RADIUS and how to troubleshoot error conditions that arise. For details on using the test
authentication command, see Run the Test Authentication Command.
RADIUS Authentication Profile Test Example
Step 1 On the PAN-OS firewall, Configure a RADIUS Server Profile and Configure an authentication profile. In the
authentication profile, you select the new RADIUS server profile in the Server Profile drop-down.
Step 2 Using a terminal emulation application, such as PuTTY, launch an SSH session to the firewall.
RADIUS Authentication Profile Test Example
Step 3 (Firewalls with virtual systems configured) Define the target virtual system that the test command will access.
This is required on firewalls with multiple virtual systems (vsys) configured, so the test authentication
command can locate the user (Global Protect or Captive Portal, for example) in the correct vsys.
To define the target vsys:
admin@PA-3060> set system setting target-vsys <vsys‐name>
For example, if the user is defined in vsys2, run the following command:
admin@PA-3060> set system setting target-vsys vsys2
The target-vsys command is per-login session, so the system clears the option when you log off.
Step 5 When prompted, enter the password for the User2-RADIUS account. The following output shows that the
test failed:
Do allow list check before sending out authentication request...
name "User2-RADIUS" is in group "all"
Authentication to RADIUS server at 10.5.104.99:1812 for user "User2-RADIUS"
Egress: 10.5.104.98
Authentication type: CHAP
Now send request to remote server ...
RADIUS error: Invalid RADIUS response received - Bad MD5
Authentication failed against RADIUS server at 10.5.104.99:1812 for user "User2-RADIUS"
In this case, the output shows Bad MD5,which indicates that there may be an issue with the secret defined in
the RADIUS server profile.
Step 6 To resolve this issue, modify the RADIUS server profile and ensure that the secret defined on the RADIUS
server matches the secret in the server profile.
1. On the firewall, select Device > Server Profiles > RADIUS and modify the profile named RADIUS-Profile.
2. In the Servers section, locate the RADIUS server and modify the Secret field.
3. Type in the correct secret and then retype to confirm.
4. Click OK to save the change.
Step 7 Run the test command again. The following output shows that the test is successful:
Do allow list check before sending out authentication request...
name "User2-RADIUS" is in group "all"
Authentication to RADIUS server at 10.5.104.99:1812 for user "User2-RADIUS"
Egress: 10.5.104.98
Authentication type: CHAP
Now send request to remote server ...
RADIUS CHAP auth request is NOT accepted, try PAP next
Authentication type: PAP
Now send request to remote server ...
Authentication succeeded against RADIUS server at 10.5.104.99:1812 for user "User2-RADIUS"
Authentication succeeded for user "User2-RADIUS"
The following example shows how to test a TACACS+ profile named TACACS-Profile for a user named
User3-TACACS and how to troubleshoot error conditions that arise. For details on using the test
authentication command, see Run the Test Authentication Command.
TACACS+ Authentication Profile Test Example
Step 1 On the PAN-OS firewall, Configure a TACACS+ Server Profile and Configure an authentication profile. In the
authentication profile, you select the new TACACS+ server profile in the Server Profile drop-down.
Step 2 Using a terminal emulation application, such as PuTTY, launch an SSH session to the firewall.
Step 3 (Firewalls with virtual systems configured) Define the target virtual system that the test command will access.
This is required on firewalls with multiple virtual systems (vsys) configured, so the test authentication
command can locate the user (Global Protect or Captive Portal, for example) in the correct vsys.
To define the target vsys:
admin@PA-3060> set system setting target‐vsys <vsys‐name>
For example, if the user is defined in vsys2, run the following command:
admin@PA-3060> set system setting target‐vsys vsys2
The target-vsys command is per-login session, so the system clears the option when you log off.
Step 5 When prompted, enter the password for the User3-TACASC account. The following output shows that the
test failed:
Do allow list check before sending out authentication request...
name "User2-TACACS" is in group "all"
Authentication to TACACS+ server at '10.5.196.62' for user 'User2-TACACS'
Server port: 49, timeout: 30, flag: 0
Egress: 10.5.104.98
Attempting CHAP authentication ...
CHAP authentication request is created
Sending credential: xxxxxx
Failed to send CHAP authentication request: Network read timed out
Attempting PAP authentication ...
PAP authentication request is created
Failed to send PAP authentication request: Network read timed out
Returned status: -1
Authentication failed against TACACS+ server at 10.5.196.62:49 for user User2-TACACS
Authentication failed for user "User2-TACACS"
The output shows error Network read timed out, which indicates that the TACACS+ server could not
decrypt the authentication request. In this case, there may be an issue with the secret defined in the TACACS+
server profile.
Step 6 To resolve this issue, modify the TACACS+ server profile and ensure that the secret defined on the TACACS+
server matches the secret in the server profile.
1. On the firewall, select Device > Server Profiles > TACACS+ and modify the profile named TACACS-Profile.
2. In the Servers section, locate the TACACS+ server and modify the Secret field.
3. Type in the correct secret and then retype to confirm.
4. Click OK to save the change.
TACACS+ Authentication Profile Test Example
Step 7 Run the test command again. The following output shows that the test is successful:
Do allow list check before sending out authentication request...
name "User2-TACACS" is in group "all"
Authentication to TACACS+ server at '10.5.196.62' for user 'User2-TACACS'
Server port: 49, timeout: 30, flag: 0
Egress: 10.5.104.98
Attempting CHAP authentication ...
CHAP authentication request is created
Sending credential: xxxxxx
CHAP authentication request is sent
Authentication succeeded!
Authentication succeeded for user "User2-TACACS"
The following example shows how to test a LDAP authentication profile named LDAP-Profile for a user
named User4-LDAP and how to troubleshoot error conditions that arise. For details on using the test
authentication command, see Run the Test Authentication Command.
LDAP Authentication Profile Test Example
Step 1 On the PAN-OS firewall, Configure an LDAP Server Profile and Configure an authentication profile. In the
authentication profile, you select the new LDAP server profile in the Server Profile drop-down.
Step 2 Using a terminal emulation application, such as PuTTY, launch an SSH session to the firewall.
Step 3 (Firewalls with virtual systems configured) Define the target virtual system that the test command will access.
This is required on firewalls with multiple virtual systems (vsys) configured, so the test authentication
command can locate the user (Global Protect or Captive Portal, for example) in the correct vsys.
To define the target vsys:
admin@PA-3060> set system setting target‐vsys <vsys‐name>
For example, if the user is defined in vsys2, run the following command:
admin@PA-3060> set system setting target‐vsys vsys2
The target-vsys command is per-login session, so the system clears the option when you log off.
LDAP Authentication Profile Test Example
Step 5 When prompted, enter the password for the User4-LDAP account. The following output shows that the test
failed:
Do allow list check before sending out authentication request...
name "User4-LDAP" is in group "all"
Authentication to LDAP server at 10.5.104.99 for user "User4-LDAP"
Egress: 10.5.104.98
Type of authentication: plaintext
Starting LDAP connection...
Succeeded to create a session with LDAP server
parse error of dn and attributes for user "User4-LDAP"
Authentication failed against LDAP server at 10.5.104.99:389 for user "User4-LDAP"
Authentication failed for user "User4-LDAP"
The output shows parse error of dn and attributes for user User4-LDAP, which indicates a BIND
DN value issues in the LDAP server profile. In this case, a Domain Component (DC) value is incorrect.
Step 6 To resolve this issue, modify the LDAP server profile and ensure that the Bind DN DC value is correct by
comparing the DC value with the DC value of the LDAP server.
1. On the firewall, select Device > Server Profiles > LDAP and modify the profile named LDAP-Profile.
2. In the Server settings section, enter the correct value for the DC in the Bind DN field. In this case, the
correct value for the DC is MGMT-GROUP
3. Click OK to save the change.
Step 7 Run the test command again. The following output shows that the test is successful:
Do allow list check before sending out authentication request...
name "User4-LDAP" is in group "all"
Authentication to LDAP server at 10.5.104.99 for user "User4-LDAP"
Egress: 10.5.104.98
Type of authentication: plaintext
Starting LDAP connection...
Succeeded to create a session with LDAP server
DN sent to LDAP server: CN=User4-LDAP,CN=Users,DC=MGMT-GROUP,DC=local
User expires in days: never
Authentication succeeded for user "User4-LDAP"
The following example shows how to test a Kerberos profile named Kerberos-Profile for a user named
User5-Kerberos and how to troubleshoot error conditions that arise. For details on using the test
authentication command, see Run the Test Authentication Command.
Kerberos Authentication Profile Test Example
Step 1 On the PAN-OS firewall, Configure a Kerberos Server Profile and Configure an authentication profile. In the
authentication profile, you select the new Kerberos server profile in the Server Profile drop-down.
Step 2 Using a terminal emulation application, such as PuTTY, launch an SSH session to the firewall.
Kerberos Authentication Profile Test Example
Step 3 (Firewalls with virtual systems configured) Define the target virtual system that the test command will access.
This is required on firewalls with multiple virtual systems (vsys) configured, so the test authentication
command can locate the user (Global Protect or Captive Portal, for example) in the correct vsys.
To define the target vsys:
admin@PA-3060> set system setting target‐vsys <vsys‐name>
For example, if the user is defined in vsys2, run the following command:
admin@PA-3060> set system setting target‐vsys vsys2
The target-vsys command is per-login session, so the system clears the option when you log off.
Step 5 When prompted, enter the password for the User5-Kerberos account. The following output shows that the
test failed:
Do allow list check before sending out authentication request...
name "User5-Kerberos" is in group "all"
Authentication to KERBEROS server at '10.5.104.99' for user 'User5-Kerberos'
Realm: 'Bad-MGMT-GROUP.LOCAL'
Egress: 10.5.104.98
KERBEROS configuration file is created
KERBEROS authcontext is created. Now authenticating ...
Kerberos principal is created
Sending authentication request to KDC...
Authentication failure: Wrong realm: 'Bad-MGMT-GROUP.LOCAL' (code: -1765328316)
Authentication failed against KERBEROS server at 10.5.104.99:88 for user "User5-Kerberos"
Authentication failed for user "User5-Kerberos"
In this case, the output shows Wrong realm, which indicates that the Kerberos realm has an incorrect value.
Step 6 To resolve this issue, modify the Kerberos server profile and ensure that the Realm value is correct by
comparing the realm name on the Kerberos server.
1. On the firewall, select Device > Authentication Profiles and modify the profile named Kerberos-Profile.
2. In the Kerberos Realm field, enter the correct value. In this case, the correct realm is mgmt-group.local.
3. Click OK to save the change.
Step 7 Run the test command again. The following output shows that the test is successful:
Do allow list check before sending out authentication request...
name "User5-Kerberos" is in group "all"
Authentication to KERBEROS server at '10.5.104.99' for user 'User5-Kerberos'
Realm: 'MGMT-GROUP.LOCAL'
Egress: 10.5.104.98
KERBEROS configuration file is created
KERBEROS authcontext is created. Now authenticating ...
Kerberos principal is created
Sending authentication request to KDC...
Authentication succeeded!
Authentication succeeded for user "User5-Kerberos"
When users fail to authenticate to a Palo Alto Networks firewall or Panorama, or the Authentication process
takes longer than expected, analyzing authentication-related information can help you determine whether
the failure or delay resulted from:
User behavior—For example, users are locked out after entering the wrong credentials or a high volume
of users are simultaneously attempting access.
System or network issues—For example, an authentication server is inaccessible.
Configuration issues—For example, the Allow List of an authentication profile doesn’t have all the users
it should have.
The following CLI commands display information that can help you troubleshoot these issues:
Task Command
Display the number of locked user accounts associated show authentication locked-users
with the authentication profile (auth-profile), {
vsys <value> |
authentication sequence (is-seq), or virtual system (vsys). auth-profile <value> |
To unlock users, use the following operational is-seq
{yes | no}
command: {auth-profile | vsys} <value>
request authentication [unlock-admin | }
unlock-user]
To ensure trust between parties in a secure communication session, Palo Alto Networks firewalls and
Panorama use digital certificates. Each certificate contains a cryptographic key to encrypt plaintext or
decrypt cyphertext. Each certificate also includes a digital signature to authenticate the identity of the issuer.
The issuer must be in the list of trusted certificate authorities (CAs) of the authenticating party. Optionally,
the authenticating party verifies the issuer did not revoke the certificate (see Certificate Revocation).
Palo Alto Networks firewalls and Panorama use certificates in the following applications:
User authentication for Captive Portal, GlobalProtect™, Mobile Security Manager, and web interface
access to a firewall or Panorama.
Device authentication for GlobalProtect VPN (remote user-to-site or large scale).
Device authentication for IPSec site-to-site VPN with Internet Key Exchange (IKE).
Decrypting 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 destination. For outbound traffic, the firewall acts as a forward proxy server, establishing an SSL/TLS
connection to the destination server. To secure a connection between itself and the client, the firewall
uses a signing certificate to automatically generate a copy of the destination server certificate.
The following table describes the keys and certificates that Palo Alto Networks firewalls and Panorama use.
As a best practice, use different keys and certificates for each usage.
Table: Palo Alto Networks Device Keys/Certificates
Key/Certificate Usage Description
Administrative Access Secure access to firewall or Panorama administration interfaces (HTTPS access to the web
interface) requires a server certificate for the MGT interface (or a designated interface on
the dataplane if the firewall or Panorama does not use MGT) and, optionally, a certificate
to authenticate the administrator.
Captive Portal In deployments where Captive Portal identifies users who access HTTPS resources,
designate a server certificate for the Captive Portal interface. If you configure Captive
Portal to use certificates (instead of, or in addition to, username/password credentials) for
user identification, designate a user certificate also. For more information on Captive
Portal, see Map IP Addresses to Usernames Using Captive Portal.
Forward Trust For outbound SSL/TLS traffic, if a firewall acting as a forward proxy trusts the CA that
signed the certificate of the destination server, the firewall uses the forward trust CA
certificate to generate a copy of the destination server certificate to present to the client.
To set the private key size, see Configure the Key Size for SSL Forward Proxy Server
Certificates. 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 acting as a forward proxy does not trust the CA
that signed the certificate of the destination server, the firewall uses the forward untrust
CA certificate to generate a copy of the destination server certificate to present to the
client.
SSL Inbound Inspection The keys that decrypt inbound SSL/TLS traffic for inspection and policy enforcement. For
this application, import onto the firewall a private key for each server that is subject to
SSL/TLS inbound inspection. See Configure SSL Inbound Inspection.
Key/Certificate Usage Description
SSL Exclude Certificate Certificates for servers to exclude from SSL/TLS decryption. For example, if you enable
SSL decryption but your network includes servers for which the firewall should not
decrypt traffic (for example, web services for your HR systems), import the corresponding
certificates onto the firewall and configure them as SSL Exclude Certificates. See
Configure Decryption Exceptions.
GlobalProtect All interaction among GlobalProtect components occurs over SSL/TLS connections.
Therefore, as part of the GlobalProtect deployment, deploy server certificates for all
GlobalProtect portals, gateways, and Mobile Security Managers. Optionally, deploy
certificates for authenticating users also.
Note that the GlobalProtect Large Scale VPN (LSVPN) feature requires a CA signing
certificate.
Site-to-Site VPNs (IKE) In a site-to-site IPSec VPN deployment, peer devices use Internet Key Exchange (IKE)
gateways to establish a secure channel. IKE gateways use certificates or preshared keys to
authenticate the peers to each other. You configure and assign the certificates 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 location for storing private keys, you can use an encryption (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 certificate to enable secure connections between the firewall and a syslog server. See
Syslog Field Descriptions.
Trusted Root CA The designation for a root certificate issued by a CA that the firewall trusts. The firewall
can use a self-signed root CA certificate to automatically issue certificates for other
applications (for example, SSL Forward Proxy).
Also, if a firewall must establish secure connections with other firewalls, the root CA that
issues their certificates must be in the list of trusted root CAs on the firewall.
Certificate Revocation
Palo Alto Networks firewalls and Panorama use digital certificates to ensure trust between parties in a secure
communication session. Configuring a firewall or Panorama to check the revocation status of certificates
provides additional security. A party that presents a revoked certificate is not trustworthy. When a
certificate is part of a chain, the firewall or Panorama checks the status of every certificate in the chain
except the root CA certificate, for which it cannot verify revocation status.
Various circumstances can invalidate a certificate before the expiration date. Some examples are a change
of name, change of association between subject and certificate authority (for example, an employee
terminates employment), and compromise (known or suspected) of the private key. Under such
circumstances, the certificate authority that issued the certificate must revoke it.
The firewall and Panorama support the following methods for verifying certificate revocation 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.
Certificate Revocation List (CRL)
Online Certificate Status Protocol (OCSP)
Each certificate authority (CA) periodically issues a certificate revocation list (CRL) to a public repository. The
CRL identifies revoked certificates by serial number. After the CA revokes a certificate, the next CRL update
will include the serial number of that certificate.
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 certificates; if a firewall never validated a certificate,
the firewall cache does not store the CRL for the issuing CA. Also, the cache only stores a CRL until it expires.
The firewall supports CRLs only in Distinguished Encoding Rules (DER) format. If the firewall downloads a
CRL in any other format—for example, Privacy Enhanced Mail (PEM) format—any revocation verification
process that uses that CRL will fail when a user performs an activity that triggers the process (for example,
sending outbound SSL data). The firewall will generate a system log for the verification failure. If the
verification was for an SSL certificate, the firewall will also display the SSL Certificate Errors Notify response
page to the user.
To use CRLs for verifying the revocation status of certificates used for the decryption of inbound and
outbound SSL/TLS traffic, see Configure Revocation Status Verification of Certificates Used for SSL/TLS
Decryption.
To use CRLs for verifying the revocation status of certificates that authenticate users and devices, configure
a certificate profile and assign it to the interfaces that are specific to the application: Captive 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 Revocation Status Verification of
Certificates.
When establishing an SSL/TLS session, clients can use Online Certificate Status Protocol (OCSP) to check
the revocation status of the authentication certificate. The authenticating client sends a request containing
the serial number of the certificate to the OCSP responder (server). The responder searches the database of
the certificate authority (CA) that issued the certificate 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-time,
instead of depending on the issue frequency (hourly, daily, or weekly) of CRLs.
The Palo Alto Networks firewall downloads and caches OCSP status information for every CA listed in the
trusted CA list of the firewall. Caching only applies to validated certificates; if a firewall never validated a
certificate, the firewall cache does not store the OCSP information 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 revocation status of certificates when the firewall functions as an SSL forward
proxy, perform the steps under Configure Revocation Status Verification of Certificates Used for SSL/TLS
Decryption.
The following applications use certificates to authenticate users and/or devices: Captive 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 revocation status of the certificates:
Configure an OCSP responder.
Enable the HTTP OCSP service on the firewall.
Create or obtain a certificate for each application.
Configure a certificate profile for each application.
Assign the certificate profile to the relevant application.
To cover situations where the OCSP responder is unavailable, configure CRL as a fall-back method. For
details, see Configure Revocation Status Verification of Certificates.
Certificate Deployment
The basic approaches to deploy certificates for Palo Alto Networks firewalls or Panorama are:
Obtain certificates from a trusted third‐party CA—The benefit of obtaining a certificate from a trusted
third-party certificate authority (CA) such as VeriSign or GoDaddy is that end clients will already trust the
certificate because common browsers include root CA certificates from well-known CAs in their trusted
root certificate stores. Therefore, for applications that require end clients to establish secure connections
with the firewall or Panorama, purchase a certificate from a CA that the end clients trust to avoid having
to pre-deploy root CA certificates to the end clients. (Some such applications are a GlobalProtect portal
or GlobalProtect Mobile Security Manager.) However, note that most third-party CAs cannot issue
signing certificates. Therefore, this type of certificate is not appropriate for applications (for example,
SSL/TLS decryption and large-scale VPN) that require the firewall to issue certificates. See Obtain a
Certificate from an External CA.
Obtain certificates from an enterprise CA—Enterprises that have their own internal CA can use it to issue
certificates for firewall applications and import them onto the firewall. The benefit is that end clients
probably already trust the enterprise CA. You can either generate the needed certificates and import
them onto the firewall, or generate a certificate 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 certificate, which the firewall uses to automatically generate
certificates (for example, for GlobalProtect large-scale VPN or sites requiring SSL/TLS decryption). See
Import a Certificate and Private Key.
Generate self‐signed certificates—You can Create a Self-Signed Root CA Certificate on the firewall and
use it to automatically issue certificates for other firewall applications. Note that if you use this method
to generate certificates for an application that requires an end client to trust the certificate, end users will
see a certificate error because the root CA certificate is not in their trusted root certificate store. To
prevent this, deploy the self-signed root CA certificate to all end user systems. You can deploy the
certificates manually or use a centralized deployment method such as an Active Directory Group Policy
Object (GPO).
To verify the revocation status of certificates, the firewall uses Online Certificate Status Protocol (OCSP)
and/or certificate revocation lists (CRLs). For details on these methods, see Certificate Revocation 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 function as the OCSP responder.
The following topics describe how to configure the firewall to verify certificate revocation status:
Configure an OCSP Responder
Configure Revocation Status Verification of Certificates
Configure Revocation Status Verification of Certificates Used for SSL/TLS Decryption
To use Online Certificate Status Protocol (OCSP) for verifying the revocation status of certificates, you must
configure the firewall to access an OCSP responder (server). The entity that manages the OCSP responder
can be a third-party certificate authority (CA) or, if your enterprise has its own public key infrastructure (PKI),
the firewall itself. For details on OCSP, see Certificate Revocation
Configure an OCSP Responder
Step 1 Define an OCSP responder. 1. Select Device > Certificate Management > OCSP Responder
and click Add.
2. Enter a Name to identify the responder (up to 31 characters).
The name is case-sensitive. It must be unique and use only
letters, numbers, spaces, hyphens, and underscores.
3. If the firewall has more than one virtual system (vsys), select a
Location (vsys or Shared) for the certificate.
4. In the Host Name field, enter the host name (recommended)
or IP address of the OCSP responder. From this value,
PAN-OS automatically derives a URL and adds it to the
certificate 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 Enable OCSP communication on the 1. Select Device > Setup > Management.
firewall. 2. In the Management Interface Settings section, edit to select
the HTTP OCSP check box, then click OK.
Configure an OCSP Responder
Step 3 (Optional) To configure the firewall itself 1. Select Network > Network Profiles > Interface Mgmt.
as an OCSP responder, add an Interface 2. Click Add to create a new profile or click the name of an
Management Profile to the interface existing profile.
used for OCSP services.
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.
The firewall and Panorama use certificates to authenticate users and devices for such applications as Captive
Portal, GlobalProtect, site-to-site IPSec VPN, and web interface access to the firewall/Panorama. To
improve security, it is a best practice to configure the firewall or Panorama to verify the revocation status of
certificates that it uses for device/user authentication.
Configure Revocation Status Verification of Certificates
Step 1 Configure a Certificate Profile for each Assign one or more root CA certificates to the profile and select
application. how the firewall verifies certificate revocation status. The common
name (FQDN or IP address) of a certificate must match an interface
to which you apply the profile in Step 2.
For details on the certificates that various applications use, see
Keys and Certificates
Step 2 Assign the certificate profiles to the The steps to assign a certificate profile depend on the application
relevant applications. that requires it.
The firewall decrypts inbound and outbound SSL/TLS traffic to apply security rules and rules, then
re-encrypts the traffic before forwarding it. (For details, see SSL Inbound Inspection and SSL Forward Proxy.)
You can configure the firewall to verify the revocation status of certificates used for decryption as follows.
Enabling revocation status verification for SSL/TLS decryption certificates will add time to the
process of establishing the session. The first attempt to access a site might fail if the verification
does not finish before the session times out. For these reasons, verification is disabled by default.
Configure Revocation Status Verification of Certificates Used for SSL/TLS Decryption
Step 1 Define the service-specific timeout 1. Select Device > Setup > Session and, in the Session Features
intervals for revocation status requests. section, select Decryption Certificate Revocation Settings.
2. Perform one or both of the following steps, depending on
whether the firewall will use Online Certificate Status
Protocol (OCSP) or the Certificate Revocation List (CRL)
method to verify the revocation status of certificates. 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 section, select the Enable check box and enter
the Receive Timeout. This is the interval (1-60 seconds)
after which the firewall stops waiting for a response from
the CRL service.
• In the OCSP section, select the Enable check box and enter
the Receive Timeout. This is the interval (1-60 seconds)
after which the firewall stops waiting for a response from
the OCSP responder.
Depending on the Certificate Status Timeout value you
specify in Step 2, the firewall might register a timeout before
either or both of the Receive Timeout intervals pass.
Step 2 Define the total timeout interval for Enter the Certificate Status Timeout. This is the interval (1-60
revocation status requests. seconds) after which the firewall stops waiting for a response from
any certificate status service and applies the session-blocking logic
you optionally define in Step 3. The Certificate Status Timeout
relates to the OCSP/CRL Receive Timeout as follows:
• If you enable both OCSP and CRL—The firewall registers a
request timeout after the lesser of two intervals passes: the
Certificate Status Timeout value or the aggregate of the two
Receive Timeout values.
• If you enable only OCSP—The firewall registers a request
timeout after the lesser of two intervals passes: the Certificate
Status Timeout value or the OCSP Receive Timeout value.
• If you enable only CRL—The firewall registers a request timeout
after the lesser of two intervals passes: the Certificate Status
Timeout value or the CRL Receive Timeout value.
Step 3 Define the blocking behavior for If you want the firewall to block SSL/TLS sessions when the OCSP
unknown certificate status or a or CRL service returns a certificate revocation status of unknown,
revocation status request timeout. select the Block Session With Unknown Certificate Status check
box. Otherwise, the firewall proceeds with the session.
If you want the firewall to block SSL/TLS sessions after it registers
a request timeout, select the Block Session On Certificate Status
Check Timeout check box. Otherwise, the firewall proceeds with
the session.
Every firewall and Panorama management server has a default master key that encrypts all the private keys
and passwords in the configuration to secure them (such as the private key used for SSL Forward Proxy
Decryption).
In a high availability (HA) configuration, ensure both firewalls or Panorama management servers in the pair
use the same master key. If the master keys differ, HA configuration synchronization will not work properly.
Additionally, if you are using Panorama to manage your firewalls, you must use the same master key on
Panorama and all managed firewalls so that Panorama can push configurations to the firewalls.
Be sure to store the master key in a safe location. You cannot recover the master key and the only way to
restore the default master key is to Reset the Firewall to Factory Default Settings.
Configure a Master Key
Step 1 Select Device > Master Key and Diagnostics and edit the Master Key section.
Step 3 Define a new New Master Key and then Confirm New Master Key. The key must contain exactly 16
characters.
Step 4 To specify the master key Life Time, enter the number of Days and/or Hours after 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 automatically reboots in Maintenance mode. You must then Reset the Firewall
to Factory Default Settings.
Step 5 Enter a Time for Reminder that specifies the number of Days and Hours before the master key expires when
the firewall generates an expiration alarm. The firewall automatically opens the System Alarms dialog to
display the alarm.
To ensure the expiration alarm displays, select Device > Log Settings, edit the Alarm Settings, and
Enable Alarms.
Step 6 (Optional) Select whether to use an HSM to encrypt the master key. For details, see Encrypt a Master Key
Using an HSM.
Obtain Certificates
A self-signed root certificate authority (CA) certificate is the top-most certificate in a certificate chain. A
firewall can use this certificate to automatically issue certificates for other uses. For example, the firewall
issues certificates for SSL/TLS decryption and for satellites in a GlobalProtect large-scale VPN.
When establishing a secure connection with the firewall, the remote client must trust the root CA that issued
the certificate. Otherwise, the client browser will display a warning that the certificate is invalid and might
(depending on security settings) block the connection. To prevent this, after generating the self-signed root
CA certificate, import it into the client systems.
On a Palo Alto Networks firewall or Panorama, you can generate self-signed certificates only if
they are CA certificates.
Generate a Self‐signed Root CA Certificate
Step 1 Select Device > Certificate Management > Certificates > Device Certificates.
Step 2 If the firewall has more than one virtual system (vsys), select a Location (vsys or Shared) for the certificate.
Step 4 Enter a Certificate Name, such as GlobalProtect_CA. The name is case-sensitive and can have up to 31
characters. It must be unique and use only letters, 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 certificate.
Step 6 If the firewall has more than one vsys and you want the certificate to be available to every vsys, select the
Shared check box.
Step 7 Leave the Signed By field blank to designate the certificate as self-signed.
Step 9 Leave the OCSP Responder field blank; revocation status verification doesn’t apply to root CA certificates.
Generate a Certificate
Palo Alto Networks firewalls and Panorama use certificates to authenticate clients, servers, users, and
devices in several applications, including SSL/TLS decryption, Captive Portal, GlobalProtect, site-to-site
IPSec VPN, and web interface access to the firewall/Panorama. Generate certificates for each usage: for
details, see Keys and Certificates.
To generate a certificate, you must first Create a Self-Signed Root CA Certificate or import one (Import a
Certificate and Private Key) to sign it. To use Online Certificate Status Protocol (OCSP) for verifying
certificate revocation status, Configure an OCSP Responder before generating the certificate.
Generate a Certificate
Step 1 Select Device > Certificate Management > Certificates > Device Certificates.
Step 2 If the firewall has more than one virtual system (vsys), select a Location (vsys or Shared) for the certificate.
Step 4 Select Local (default) as the Certificate Type unless you want to deploy SCEP certificates to GlobalProtect
clients.
Step 5 Enter a Certificate Name. The name is case-sensitive and can have up to 31 characters. It must be unique and
use only letters, 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 certificate.
Step 7 If the firewall has more than one vsys and you want the certificate to be available to every vsys, select the
Shared check box.
Step 8 In the Signed By field, select the root CA certificate that will issue the certificate.
Step 10 For the key generation Algorithm, select RSA (default) or Elliptical Curve DSA (ECDSA). ECDSA is
recommended for client browsers and operating systems that support it.
Firewalls that run PAN-OS 6.1 and earlier releases will delete any ECDSA certificates that you push
from Panorama™, and any RSA certificates signed by an ECDSA certificate authority (CA) will be
invalid on those firewalls.
Step 11 Select the Number of Bits to define the certificate key length. Higher numbers are more secure but require
more processing time.
Step 12 Select the Digest algorithm. From most to least secure, the options are: sha512, sha384, sha256 (default),
sha1, and md5.
Client certificates that are used when requesting firewall services that rely on TLSv1.2 (such as
administrator access to the web interface) cannot have sha384 (in releases before PAN-OS 7.1.8) or
sha512 as a digest algorithm. The client certificates must use a lower digest algorithm 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 Expiration, enter the number of days (default is 365) for which the certificate is valid.
Step 14 (Optional) Add the Certificate Attributes to uniquely identify the firewall and the service that will use the
certificate.
If you add a Host Name (DNS name) attribute, it is a best practice for it to match the Common Name.
The host name populates the Subject Alternative Name field of the certificate.
Generate a Certificate (Continued)
Step 15 Click Generate and, in the Device Certificates page, click the certificate Name.
Regardless of the time zone on the firewall, it always displays the corresponding Greenwich Mean
Time (GMT) for certificate validity and expiration dates/times.
Step 16 Select the check boxes that correspond to the intended use of the certificate on the firewall.
For example, if the firewall will use this certificate to secure forwarding of syslogs to an external syslog server,
select the Certificate for Secure Syslog check box.
If your enterprise has its own public key infrastructure (PKI), you can import a certificate and private key into
the firewall from your enterprise certificate authority (CA). Enterprise CA certificates (unlike most
certificates purchased from a trusted, third-party CA) can automatically issue CA certificates for applications
such as SSL/TLS decryption or large-scale VPN.
On a Palo Alto Networks firewall or Panorama, you can import self-signed certificates only if they
are CA certificates.
Instead of importing a self-signed root CA certificate into all the client systems, it is a best practice
to import a certificate from the enterprise CA because the clients will already have a trust
relationship with the enterprise CA, which simplifies the deployment.
If the certificate you will import is part of a certificate chain, it is a best practice to import the
entire chain.
Import a Certificate and Private Key
Step 1 From the enterprise CA, export the certificate and private key that the firewall will use for authentication.
When exporting a private key, you must enter a passphrase to encrypt the key for transport. Ensure the
management system can access the certificate and key files. When importing the key onto the firewall, you
must enter the same passphrase to decrypt it.
Step 2 Select Device > Certificate Management > Certificates > Device Certificates.
Step 3 If the firewall has more than one virtual system (vsys), select a Location (vsys or Shared) for the certificate.
Step 4 Click Import and enter a Certificate Name. The name is case-sensitive and can have up to 31 characters. It
must be unique and use only letters, numbers, hyphens, and underscores.
Step 5 To make the certificate available to all virtual systems, select the Shared check box. This check box appears
only if the firewall supports multiple virtual systems.
Step 6 Enter the path and name of the Certificate File received from the CA, or Browse to find the file.
Import a Certificate and Private Key
Step 8 Enter and re-enter (confirm) the Passphrase used to encrypt the private key.
Step 9 Click OK. The Device Certificates page displays the imported certificate.
The advantage of obtaining a certificate from an external certificate authority (CA) is that the private key
does not leave the firewall. To obtain a certificate from an external CA, generate a certificate signing request
(CSR) and submit it to the CA. After the CA issues a certificate with the specified attributes, import it onto
the firewall. The CA can be a well-known, public CA or an enterprise CA.
To use Online Certificate Status Protocol (OCSP) for verifying the revocation status of the certificate,
Configure an OCSP Responder before generating the CSR.
Obtain a Certificate from an External CA
Step 1 Request the certificate from an external 1. Select Device > Certificate Management > Certificates >
CA. Device Certificates.
2. If the firewall has more than one virtual system (vsys), select a
Location (vsys or Shared) for the certificate.
3. Click Generate.
4. Enter a Certificate Name. The name is case-sensitive and can
have up to 31 characters. It must be unique and use only
letters, 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 certificate.
6. If the firewall has more than one vsys and you want the
certificate 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. (Optional) Add the Certificate Attributes to uniquely identify
the firewall and the service that will use the certificate.
If you add a Host Name attribute, it is a best practice
for it to match the Common Name (this is mandatory
for GlobalProtect). The host name populates the
Subject Alternative Name field of the certificate.
10. Click Generate. The Device Certificates 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 certificate. 1. After the CA sends a signed certificate in response to the CSR,
return to the Device Certificates tab and click Import.
2. Enter the Certificate Name used to generate the CSR.
3. Enter the path and name of the PEM Certificate File that the
CA sent, or Browse to it.
4. Click OK. The Device Certificates tab displays the certificate
with a Status of valid.
Palo Alto Networks recommends that you use your enterprise public key infrastructure (PKI) to distribute a
certificate and private key in your organization. However, if necessary, you can also export a certificate and
private key from the firewall or Panorama. You can use an exported certificate and private key in the
following cases:
Configure Certificate-Based Administrator Authentication to the Web Interface
GlobalProtect agent/app authentication to portals and gateways
SSL Forward Proxy decryption
Obtain a Certificate from an External CA
Export a Certificate and Private Key
Step 1 Select Device > Certificate Management > Certificates > Device Certificates.
Step 2 If the firewall has more than one virtual system (vsys), select a Location (a specific vsys or Shared) for the
certificate.
Step 3 Select the certificate, click Export, and select a File Format:
• Base64 Encoded Certificate (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 Certificate (PKCS12)—This format is more secure than PEM but is not as
common or as broadly supported. The exported file will automatically include the private key.
• Binary Encoded Certificate (DER)—More operating system types support this format than the others. You
can export only the certificate, 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 importing the
certificate and key into client systems.
Certificate profiles define user and device authentication for Captive Portal, GlobalProtect, site-to-site IPSec
VPN, Mobile Security Manager, and web interface access to Palo Alto Networks firewalls or Panorama. The
profiles specify which certificates to use, how to verify certificate revocation status, and how that status
constrains access. Configure a certificate profile for each application.
It is a best practice to enable Online Certificate Status Protocol (OCSP) and/or Certificate
Revocation List (CRL) status verification for certificate profiles. For details on these methods, see
Certificate Revocation.
Configure a Certificate Profile
Step 1 Obtain the certificate authority (CA) Perform one of the following steps to obtain the CA certificates
certificates you will assign. you will assign to the profile. You must assign at least one.
• Generate a Certificate.
• Export a certificate from your enterprise CA and then import it
onto the firewall (see Step 3).
Step 2 Identify the certificate profile. 1. Select Device > Certificate Management > Certificates
Profile and click Add.
2. Enter a Name to identify the profile. The name is
case-sensitive, must be unique and can use up to 31
characters that include only letters, numbers, spaces, hyphens,
and underscores.
3. If the firewall has more than one virtual system (vsys), select a
Location (vsys or Shared) for the certificate.
Step 3 Assign one or more certificates. Perform the following steps for each CA certificate:
1. In the CA Certificates table, click Add.
2. Select a CA Certificate. Alternatively, to import a certificate,
click Import, enter a Certificate Name, Browse to the
Certificate File you exported from your enterprise CA, and
click OK.
3. (Optional) If the firewall uses OCSP to verify certificate
revocation status, configure the following fields to override
the default behavior. For most deployments, these fields do
not apply.
• By default, the firewall uses the OCSP responder URL that
you set in the procedure Configure an OCSP Responder. To
override that setting, enter a Default OCSP URL (starting
with http:// or https://).
• By default, the firewall uses the certificate selected in the
CA Certificate field to validate OCSP responses. To use a
different certificate for validation, select it in the OCSP
Verify CA Certificate field.
4. Click OK. The CA Certificates table displays the assigned
certificate.
Configure a Certificate Profile
Step 4 Define the methods for verifying 1. Select Use CRL and/or Use OCSP. If you select both, the
certificate revocation status and the firewall first tries OCSP and falls back to the CRL method only
associated blocking behavior. if the OCSP responder is unavailable.
2. Depending on the verification method, enter the CRL Receive
Timeout and/or OCSP Receive Timeout. These are the
intervals (1-60 seconds) after which the firewall stops waiting
for a response from the CRL/OCSP service.
3. Enter the Certificate Status Timeout. This is the interval (1-60
seconds) after which the firewall stops waiting for a response
from any certificate status service and applies any
session-blocking logic you define. The Certificate Status
Timeout relates to the OCSP/CRL Receive Timeout as
follows:
• If you enable both OCSP and CRL—The firewall registers a
request timeout after the lesser of two intervals passes: the
Certificate Status Timeout value or the aggregate of the
two Receive Timeout values.
• If you enable only OCSP—The firewall registers a request
timeout after the lesser of two intervals passes: the
Certificate Status Timeout value or the OCSP Receive
Timeout value.
• If you enable only CRL—The firewall registers a request
timeout after the lesser of two intervals passes: the
Certificate 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 certificate revocation status of unknown,
select the Block session if certificate status is unknown
check box. Otherwise, the firewall proceeds with the session.
5. If you want the firewall to block sessions after it registers an
OCSP or CRL request timeout, select the Block session if
certificate status cannot be retrieved within timeout check
box. Otherwise, the firewall proceeds with the session.
6. (GlobalProtect only) If you want the firewall to block sessions
when the serial number attribute in the subject of the client
certificate does not match the host ID that the GlobalProtect
agent reports for the client endpoint, select Block sessions if
the certificate was not issued to the authenticating device.
Palo Alto Networks firewalls and Panorama use SSL/TLS service profiles to specify a certificate and the
allowed protocol versions for SSL/TLS services. The firewall and Panorama use SSL/TLS for Captive 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 communication with the clients requesting
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 connection to a supported version.
In the client systems that request firewall services, the certificate trust list (CTL) must include the certificate
authority (CA) certificate that issued the certificate specified in the SSL/TLS service profile. Otherwise, users will
see a certificate error when requesting firewall services. Most third-party CA certificates are present by default
in client browsers. If an enterprise or firewall-generated CA certificate is the issuer, you must deploy that CA
certificate to the CTL in client browsers.
Configure an SSL/TLS Service Profile
Step 1 For each desired service, generate or import a certificate on the firewall (see Obtain Certificates).
Use only signed certificates, not CA certificates, in SSL/TLS service profiles.
Step 2 Select Device > Certificate Management > SSL/TLS Service Profile.
Step 3 If the firewall has more than one virtual system (vsys), select the Location (vsys or Shared) where the profile
is available.
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.
Client certificates that are used when requesting firewall services that rely on TLSv1.2 cannot have
SHA384 (in releases before PAN-OS 7.1.8) or SHA512 as a digest algorithm. The client certificates
must use a lower digest algorithm or you must limit the Max Version to TLSv1.1 for the firewall
service.
When you first boot up the firewall or Panorama, it automatically generates a default certificate 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 certificate with a new certificate issued specifically for your organization.
Replace the Certificate for Inbound Management Traffic
Step 1 Obtain the certificate that will You can simplify your Certificate Deployment by using a certificate
authenticate the firewall or Panorama to that the client systems already trust. Therefore, we recommend
the client systems of administrators. that you Import a Certificate and Private Key from your enterprise
certificate authority (CA) or Obtain a Certificate from an External
CA; the trusted root certificate store of the client systems is likely
to already have the associated root CA certificate that ensures
trust.
If you Generate a Certificate on the firewall or Panorama,
administrators will see a certificate error because the root
CA certificate is not in the trusted root certificate store of
client systems. To prevent this, deploy the self-signed root
CA certificate to all client systems.
Regardless of how you obtain the certificate, we
recommend a Digest algorithm of sha256 or higher for
enhanced security.
Step 2 Configure an SSL/TLS Service Profile. Select the Certificate you just obtained.
For enhanced security, we recommend that you set the Min
Version (earliest allowed TLS version) to TLSv1.1 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 1. Select Device > Setup > Management and edit the General
inbound management traffic. Settings.
2. Select the SSL/TLS Service Profile you just configured.
3. Click OK and Commit.
When responding to a client in an SSL Forward Proxy session, the firewall creates a copy of the certificate
that the destination server presents and uses the copy to establish a connection with the client. By default,
the firewall generates certificates with the same key size as the certificate that the destination server
presented. However, you can change the key size for the firewall-generated certificate as follows:
Configure the Key Size for SSL Forward Proxy Server Certificates
Step 1 Select Device > Setup > Session and, in the Decryption Settings section, click SSL Forward Proxy Settings.
Revoke a Certificate
Renew a Certificate
Revoke a Certificate
Various circumstances can invalidate a certificate before the expiration date. Some examples are a change
of name, change of association between subject and certificate authority (for example, an employee
terminates employment), and compromise (known or suspected) of the private key. Under such
circumstances, the certificate authority (CA) that issued the certificate must revoke it. The following task
describes how to revoke a certificate for which the firewall is the CA.
Revoke a Certificate
Step 1 Select Device > Certificate Management > Certificates > Device Certificates.
Step 2 If the firewall supports multiple virtual systems, the tab displays a Location drop-down. Select the virtual
system to which the certificate belongs.
Step 4 Click Revoke. PAN-OS immediately sets the status of the certificate to revoked and adds the serial number to
the Online Certificate Status Protocol (OCSP) responder cache or certificate revocation list (CRL). You need
not perform a commit.
Renew a Certificate
If a certificate expires, or soon will, you can reset the validity period. If an external certificate authority (CA)
signed the certificate and the firewall uses the Online Certificate Status Protocol (OCSP) to verify certificate
revocation status, the firewall uses the OCSP responder information to update the certificate status (see
Configure an OCSP Responder). If the firewall is the CA that issued the certificate, the firewall replaces it
with a new certificate that has a different serial number but the same attributes as the old certificate.
Renew a Certificate
Step 1 Select Device > Certificate Management > Certificates > Device Certificates.
Step 2 If the firewall has more than one virtual system (vsys), select a Location (vsys or Shared) for the certificate.
A hardware security module (HSM) is a physical device that manages digital keys. An HSM provides secure
storage and generation of digital keys. It provides both logical and physical protection of these materials from
non-authorized use and potential adversaries.
HSM clients integrated with Palo Alto Networks firewalls or Panorama enable enhanced security for the
private keys used in SSL/TLS decryption (both SSL forward proxy and SSL inbound inspection). In addition,
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 Connectivity with an HSM
Encrypt a Master Key Using an HSM
Store Private Keys on an HSM
Manage the HSM Deployment
HSM clients are integrated with PA-3000 Series, PA-4000 Series, PA-5000 Series, PA-7000 Series, and
VM-Series firewalls and with the Panorama management server (virtual appliance and M-Series appliances)
for use with the following HSM vendors.
SafeNet Network—The supported client versions depend on the PAN-OS release:
– PAN-OS 7.1 releases and earlier releases (also PAN-OS 8.0 releases)—SafeNet Network client
version 5.2.1.
– PAN-OS 7.1.10 and later PAN-OS 7.1 releases (also PAN-OS 8.0.2 and later PAN-OS 8.0 releases)—
SafeNet Network client version 5.2.1, 5.4.2, and 6.2.2. On the firewall or Panorama, use the request
hsm client-version CLI command to select the version that is compatible with your SafeNet HSM
server.
Thales nShield Connect—All PAN-OS releases support client version 11.62.
The HSM server version must be compatible with these client versions. Refer to the HSM vendor
documentation for the client-server version compatibility matrix.
Set Up Connectivity with a SafeNet Network HSM
Set Up Connectivity with a Thales nShield Connect HSM
To set up connectivity 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 authenticating the firewall to the
server, and register the firewall with the server. Before starting the configuration, make sure you created a
partition for the firewall on the HSM server. To ensure the SafeNet Network client version on the firewall is
compatible with your SafeNet Network server, see Set up Connectivity with an HSM.
Before the HSM and firewall connect, the HSM authenticates the firewall based on the firewall IP address.
Therefore, you must configure the firewall to use a static IP address, not a dynamic address assigned through
DHCP. Operations on the HSM would stop working if the firewall IP address changed during runtime.
HSM configurations are not synchronized between high availability (HA) firewall peers.
Consequently, you must configure the HSM separately on each peer. In active/passive HA
deployments, you must manually perform one failover to individually configure and authenticate
each HA peer to the HSM. After this initial manual failover, user interaction is not required for the
failover function.
Set up Connectivity with a SafeNet Network HSM
Step 1 Define connection settings for 1. Log in to the firewall web interface and select Device > Setup > HSM.
each SafeNet Network HSM. 2. Edit the Hardware Security Module Provider section and set the
Provider Configured to SafeNet Network HSM.
3. Add each HSM server as follows. A high availability (HA) HSM
configuration requires two servers.
a. Enter a Module Name for the HSM server. This can be any ASCII
string of up to 31 characters.
b. Enter an IPv4 address for the HSM Server Address.
4. (HA only) Select High Availability, specify the Auto Recovery Retry
value, and enter a High Availability Group Name.
If two HSM servers are configured, the best practice is to
enable High Availability. Otherwise the second HSM server is
not used.
5. Click OK and Commit.
Step 2 (Optional) Configure a service 1. Select Device > Setup > Services and click Service Route
route to connect to the HSM if Configuration.
you don’t want the firewall to 2. Customize a service route. The IPv4 tab is active by default.
connect through the
Management interface (default). 3. Click HSM in the Service column.
If you configure a service 4. Select a Source Interface for the HSM.
route for the HSM, 5. Click OK and Commit.
running the clear
session all CLI
command clears all
existing HSM sessions,
bringing all HSM states
down and then up again.
During the several
seconds required for the
HSM to recover, all
SSL/TLS operations will
fail.
Set up Connectivity with a SafeNet Network HSM (Continued)
Step 3 Configure the firewall to 1. Select Device > Setup > HSM and Setup Hardware Security Module.
authenticate to the HSM. 2. Select the HSM Server Name.
3. Enter the Administrator Password to authenticate the firewall to the
HSM.
4. Click OK.
The firewall tries to authenticate to the HSM and displays a status
message.
5. Click OK.
Step 4 Register the firewall as an HSM 1. Log in to the HSM from a remote system.
client with the HSM server and 2. Register the firewall using the client register -c <cl-name> -ip
assign the firewall to a partition <fw-ip-addr> command, where <cl-name> is a name that you assign
on the HSM server. to the firewall for use on the HSM and <fw-ip-addr> is the firewall IP
If the HSM already has a address. The IP address must be static, not assigned through DHCP.
firewall with the same
3. Assign a partition to the firewall using the client assignpartition
<cl-name> registered,
-c <cl-name> -p <partition-name> command, where <cl-name>
you must first remove
is the name assigned to the firewall in the client register
the duplicate registration
command and <partition-name> is the name of a previously
by running the client
configured partition that you want to assign to the firewall.
delete -client
<cl-name> command,
where <cl-name> is the
name of the client
(firewall) registration you
want to delete.
Step 5 Configure the firewall to connect 1. Select Device > Setup > HSM and click the Refresh icon.
to the HSM partition. 2. Setup HSM Partition in the Hardware Security Operations section.
3. Enter the Partition Password to authenticate the firewall to the
partition on the HSM.
4. Click OK.
Step 6 (HA only) Configure an Repeat the previous authentication, registration, and partition connection
additional HSM for HA. steps to add an additional HSM to the existing HA group.
If you remove an HSM from your configuration, repeat the previous
partition connection step to remove the deleted HSM from the HA
group.
Set up Connectivity with a SafeNet Network HSM (Continued)
Step 7 Verify firewall connectivity and 1. Select Device > Setup > HSM and check the authentication and
authentication with the HSM. connection Status:
• Green—The firewall is successfully authenticated and connected to
the HSM.
• Red—The firewall failed to authenticate to the HSM or network
connectivity to the HSM is down.
2. View the following columns in the Hardware Security Module Status
section to determine the authentication status:
• Serial Number—The serial number of the HSM partition if the
firewall successfully authenticated to the HSM.
• Partition—The partition name on the HSM that is assigned on the
firewall.
• Module State—The current state of the HSM connection. The value
is always Authenticated if the Hardware Security Module Status
section displays the HSM.
You must set up a remote filesystem (RFS) as a hub to synchronize key data for all the firewalls (HSM clients)
in your organization that use the Thales nShield Connect HSM. To ensure the Thales nShield Connect client
version on your firewalls is compatible with your Thales nShield Connect server, see Set up Connectivity
with an HSM.
Before the HSM and firewalls connect, the HSM authenticates the firewalls based on their IP addresses.
Therefore, you must configure the firewalls to use static IP addresses, not dynamic addresses assigned
through DHCP. Operations on the HSM would stop working if the firewall IP addresses changed during
runtime.
HSM configurations are not synchronized between high availability (HA) firewall peers.
Consequently, you must configure the HSM separately on each peer. In active/passive HA
deployments, you must manually perform one failover to individually configure and authenticate
each HA peer to the HSM. After this initial manual failover, user interaction is not required for the
failover function.
Set up Connectivity with a Thales nShield Connect HSM
Step 1 Define connection settings for 1. Log in to the firewall web interface and select Device > Setup > HSM.
each Thales nShield Connect 2. Edit the Hardware Security Module Provider section and set the
HSM. Provider Configured to Thales nShield Connect.
3. Add each HSM server as follows. A high availability (HA) HSM
configuration requires two servers.
a. Enter a Module Name for the server. This can be any ASCII string of
up to 31 characters.
b. Enter an IPv4 address for the HSM Server Address.
4. Enter an IPv4 address for the Remote Filesystem Address.
5. Click OK and Commit.
Set up Connectivity with a Thales nShield Connect HSM (Continued)
Step 2 (Optional) Configure a service 1. Select Device > Setup > Services and click Service Route
route to connect to the HSM if Configuration.
you don’t want the firewall to 2. Customize the service route. The IPv4 tab is active by default.
connect through the
Management interface (default). 3. Click HSM in the Service column.
If you configure a service 4. Select a Source Interface for HSM.
route for the HSM, 5. Click OK and Commit.
running the clear
session all CLI
command clears all
existing HSM sessions,
bringing all HSM states
down and then up again.
During the several
seconds required for the
HSM to recover, all
SSL/TLS operations will
fail.
Step 3 Register the firewall as an HSM 1. Log in to the front panel display of the Thales nShield Connect HSM
client with the HSM server. unit.
This step briefly describes the 2. Use the right-hand navigation button to select System > System
procedure for using the front configuration > Client config > New client.
panel interface of the Thales
3. Enter the firewall IP address.
nShield Connect HSM. For more
details, refer to the Thales 4. Select System > System configuration > Client config > Remote file
documentation. system and enter the IP address of the client computer where you set
up the RFS.
Step 4 Configure the RFS to accept 1. Log in to the RFS from a Linux client.
connections from the firewall. 2. Obtain the electronic serial number (ESN) and the hash of the KNETI
key, which authenticates the HSM to clients, by running the
anonkneti <ip-address> command, where <ip-address> is the IP
address of the HSM.
The following is an 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 HSM IP address, <ESN> is the electronic
serial number, and <hash-Kneti-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.
Set up Connectivity with a Thales nShield Connect HSM (Continued)
Step 5 Authenticate the firewall to the 1. In the firewall web interface, select Device > Setup > HSM and Setup
HSM. Hardware Security Module.
2. Click OK.
The firewall tries to authenticate to the HSM and displays a status
message.
3. Click OK.
Step 6 Synchronize the firewall with the Select Device > Setup > HSM and Synchronize with Remote Filesystem.
RFS.
Step 7 Verify firewall connectivity and 1. Select Device > Setup > HSM and check the authentication and
authentication with the HSM. connection Status:
• Green—The firewall is successfully authenticated and connected to
the HSM.
• Red—The firewall failed to authenticate to the HSM or network
connectivity to the HSM is down.
2. Check the Hardware Security Module Status section to determine the
authentication status.
• Name—The name of the HSM.
• IP address—The IP address of the HSM.
• Module State—The current state of the HSM connection:
Authenticated or Not Authenticated.
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 location, you can encrypt the master key using an
encryption 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 location 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 encryption using an HSM.
The following topics describe how to encrypt the master key initially and how to refresh the master key
encryption:
Encrypt the Master Key
Refresh the Master Key Encryption
If you have not previously encrypted the master key on a firewall, use the following procedure to encrypt it.
Use this procedure for first time encryption of a key, or if you define a new master key and you want to
encrypt it. If you want to refresh the encryption on a previously encrypted key, see Refresh the Master Key
Encryption.
Encrypt a Master Key Using an HSM
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.
As a best practice, periodically refresh the master key encryption by rotating the wrapping key that encrypts
it. The frequency of the rotation depends on your application. The wrapping key resides on your HSM. The
following command is the same for SafeNet Network and Thales nShield Connect HSMs.
Refresh the Master Key Encryption
Step 1 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.
For added security, you can use an HSM to secure the private keys used in SSL/TLS decryption for:
SSL Forward Proxy—The HSM can store the private key of the Forward Trust certificate that signs
certificates in SSL/TLS forward proxy operations. The firewall will then send the certificates that it
generates during such operations to the HSM for signing before forwarding the certificates to the client.
SSL Inbound Inspection—The HSM can store the private keys for the internal servers for which you are
performing SSL/TLS inbound inspection.
Store Private Keys on an HSM
Step 1 On the HSM, import or generate For instructions on importing or generating a certificate and private key on
the certificate and private key the HSM, refer to your HSM documentation.
used in your decryption
deployment.
Step 2 (Thales nShield Connect only) 1. Access the firewall web interface and select Device > Setup > HSM.
Synchronize the key data from 2. Select Synchronize with Remote Filesystem in the Hardware Security
the Thales nShield remote file Operations section.
system to the firewall.
Synchronization with the
SafeNet Network HSM is
automatic.
Step 3 Import the certificate that 1. Select Device > Certificate Management > Certificates > Device
corresponds to the HSM-stored Certificates and click Import.
key onto the firewall. 2. Enter the Certificate Name.
3. Browse to the Certificate File on the HSM.
4. Select a File Format.
5. Select Private Key resides on Hardware Security Module.
6. Click OK and Commit.
Store Private Keys on an HSM (Continued)
Step 4 (Forward Trust certificates only) 1. Open the certificate you imported in Step 3 for editing.
Enable the certificate for use in 2. Select Forward Trust Certificate.
SSL/TLS Forward Proxy.
3. Click OK and Commit.
Step 5 Verify that you successfully Locate the certificate you imported in Step 3 and check the icon in the Key
imported the certificate onto the column:
firewall. • Lock icon—The private key for the certificate is on the HSM.
• Error icon—The private key is not on the HSM or the HSM is not
properly authenticated or connected.
Manage HSM
• View the HSM configuration Select Device > Setup > HSM.
settings.
• Display detailed HSM Select Show Detailed Information from the Hardware Security Operations
information. section.
Information regarding the HSM servers, HSM HA status, and HSM hardware is
displayed.
• Export Support file. Select Export Support File from the Hardware Security Operations section.
A test file is created to help customer support when addressing a problem with an
HSM configuration on the firewall.
• Reset HSM configuration. Select Reset HSM Configuration from the Hardware Security Operations section.
Selecting this option removes all HSM connections. All authentication procedures
must be repeated after using this option.
HA Overview
You can set up two Palo Alto Networks firewalls as an HA pair. HA allows you to minimize downtime by
making sure that an alternate firewall is available in the event that the peer firewall fails. The firewalls in an
HA pair use dedicated or in-band HA ports on the firewall to synchronize data—network, object, and policy
configurations—and to maintain state information. Firewall-specific configuration such as management
interface IP address or administrator profiles, HA specific configuration, log data, and the Application
Command Center (ACC) information is not shared between peers. For a consolidated application and log
view across the HA pair, you must use Panorama, the Palo Alto Networks centralized management system.
When a failure occurs on a firewall in an HA pair and the peer firewall takes over the task of securing traffic,
the event is called a Failover. The conditions that trigger a failover are:
One or more of the monitored interfaces fail. (Link Monitoring)
One or more of the destinations specified on the firewall cannot be reached. (Path Monitoring)
The firewall does not respond to heartbeat polls. (Heartbeat Polling and Hello messages)
A critical chip or software component fails, known as packet path health monitoring.
You can use Panorama to manage HA firewalls. See Context Switch—Firewall or Panorama in the Panorama
Administrator’s Guide.
After you understand the HA Concepts, proceed to Set Up Active/Passive HA or Set Up Active/Active HA.
HA Concepts
The following topics provide conceptual information about how HA works on a Palo Alto Networks firewall:
HA Modes
HA Links and Backup Links
Device Priority and Preemption
Failover
LACP and LLDP Pre-Negotiation for Active/Passive HA
Floating IP Address and Virtual MAC Address
ARP Load-Sharing
Route-Based Redundancy
HA Timers
Session Owner
Session Setup
NAT in Active/Active HA Mode
ECMP in Active/Active HA Mode
HA Modes
Active/Active— Both firewalls in the pair are active and processing traffic and work synchronously to
handle session setup and session ownership. Both firewalls individually maintain session tables and
routing tables and synchronize to each other. Active/active HA is supported in virtual wire and Layer 3
deployments.
In active/active HA mode, the firewall does not support DHCP client. Furthermore, only the
active-primary firewall can function as a DHCP Relay. If the active-secondary firewall receives DHCP
broadcast packets, it drops them.
An active/active configuration 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, multiple
ISPs, and load balancers.
When deciding whether to use active/passive or active/active mode, consider the following differences:
Active/passive mode has simplicity of design; it is significantly easier to troubleshoot routing and traffic
flow issues in active/passive mode. Active/passive mode supports a Layer 2 deployment; active/active
mode does not.
Active/active mode requires advanced design concepts that can result in more complex networks.
Depending on how you implement active/active HA, it might require additional configuration such as
activating networking protocols on both firewalls, replicating NAT pools, and deploying floating IP
addresses to provide proper failover. Because both firewalls are actively processing traffic, the firewalls
use additional concepts of session owner and session setup to perform Layer 7 content inspection.
Active/active mode is recommended if each firewall needs its own routing instances and you require full,
real-time redundancy out of both firewalls all the time. Active/active mode has faster failover and can
handle peak traffic flows better than active/passive mode because both firewalls are actively processing
traffic.
In active/active 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
inspection enabled. If the design oversubscribes the capacity of the remaining firewall, high latency and/or
application failure can occur.
For information on setting up your firewalls in active/passive mode, see Set Up Active/Passive HA. For
information on setting up your firewalls in active/active mode, see Set Up Active/Active HA.
The firewalls in an HA pair use HA links to synchronize data and maintain state information. 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.
On firewalls with dedicated HA ports such as the PA-3000 Series, PA-4000 Series, PA-5000 Series, and
PA-7000 Series firewalls (see HA Ports on the PA-7000 Series Firewall), use the dedicated HA ports to
manage communication and synchronization between the firewalls. For firewalls without dedicated HA
ports such as the PA-200, PA-500, and PA-2000 Series firewalls, as a best practice use the management port
for the HA1 link to allow for a direct connection between the management planes on the firewalls, and an
in-band port for the HA2 link.
The HA1 and HA2 links provide synchronization for functions 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 synchronization packets over the
dataplane.
HA Links and Description
Backup Links
Control Link The HA1 link is used to exchange hellos, heartbeats, and HA state information, and
management plane sync for routing, and User-ID information. The firewalls also use
this link to synchronize configuration 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 communication; port
28 for encrypted communication (SSH over TCP).
Data Link The HA2 link is used to synchronize sessions, forwarding tables, IPSec security
associations and ARP tables between firewalls in an HA pair. Data flow on the HA2
link is always unidirectional (except for the HA2 keep-alive); it flows from the active
or active-primary firewall to the passive or active-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.
Backup Links Provide redundancy for the HA1 and the HA2 links. In-band ports are used as backup
links for both HA1 and HA2. 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.
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 Link In addition to HA1 and HA2 links, an active/active deployment also requires a
dedicated HA3 link. The firewalls use this link for forwarding packets to the peer
during session setup and asymmetric traffic flow. The HA3 link is a Layer 2 link that
uses MAC-in-MAC encapsulation. It does not support Layer 3 addressing or
encryption. PA-7000 Series firewalls synchronize sessions across the NPCs
one-for-one. On PA-3000 Series, PA-4000 Series, and PA-5000 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-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.
HA connectivity on the PA-7000 Series mandates the use of specific ports on the Switch Management Card
(SMC) for certain functions; for other functions, you can use the ports on the Network Processing Card
(NPC). PA-7000 Series firewalls synchronize sessions across the NPCs one-for-one.
The following table describes the SMC ports that are designed for HA connectivity:
Control Link HA1-A Used for HA control and synchronization in both HA Modes. Connect
Speed: Ethernet this port directly from the HA1-A port on the first firewall to the
10/100/1000 HA1-A port on the second firewall in the pair, or connect them
through a switch or router.
HA1 cannot be configured on NPC data ports or the MGT port.
Control Link HA1-B Used for HA control and synchronization as a backup for HA1-A in
Backup Speed: Ethernet both HA Modes. Connect this port directly from the HA1-B port on
10/100/1000 port the first firewall to the HA1-B port on the second firewall in the pair,
or connect them through a switch or router.
HA1 Backup cannot be configured on NPC data ports or the MGT
port.
Data Link HSCI-A The High Speed Chassis Interconnect (HSCI) ports are Layer 1 Quad
Port SFP+ (QSFP+) interfaces used to connect two PA-7000 Series
firewalls in an HA configuration. Each port is comprised of four 10
gigabit channels multiplexed for a combined speed of 40 gigabits.
The traffic carried on the HSCI ports is raw layer-1, which is not
Data Link HSCI-B
routable or switchable; therefore the HSCI ports must be connected
Backup
directly to each other. The HSCI-A on the first chassis connects
directly to HSCI-A on the second chassis and HSCI-B on the first
chassis connects to HSCI-B on the second chassis. This provides full
80 gigabit transfer rates. In software, both ports (HSCI-A and HSCI-B)
are treated as one HA interface.
Palo Alto Networks recommends using the dedicated HSCI ports for
the HA2 link. The HA3 link, required for packet forwarding in an
active/active deployment, must use the HSCI port; the HA3 traffic
cannot be configured on data ports.
If the firewalls are deployed in:
• an active/active configuration, the HA3 link must use the HSCI
ports. The HA2 link and HA2 backup links can use the HSCI ports
or data ports on the NPC.
• an active/passive configuration, you can configure a data port on
the NPC for the HA2 link or the HA2 backup link, if needed.
The firewalls in an HA pair can be assigned a device priority value to indicate a preference for which firewall
should assume the active or active-primary role. If you need to use a specific firewall in the HA pair for
actively securing traffic, you must enable the preemptive 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 active or active-primary. The other firewall is the active-secondary or passive firewall.
By default, preemption is disabled on the firewalls and must be enabled on both firewalls. When enabled,
the preemptive behavior allows the firewall with the higher priority (lower numerical value) to resume as
active or active-primary after it recovers from a failure. When preemption occurs, the event is logged in the
system logs.
Failover
When a failure occurs on one firewall and the peer 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 are monitored for detecting 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
operational. 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. A ping is sent every
1000 milliseconds and if there are three consecutive heartbeat losses, a failovers occurs. For details on
the HA timers that trigger a failover, see HA Timers.
Link Monitoring
The physical interfaces to be monitored are grouped into a link group and their state (link up or link down)
is monitored. A link group can contain one or more physical interfaces. A firewall failure is triggered when
any or all of the interfaces in the group fail. The default behavior is failure of any one link in the link group
will cause the firewall to change the HA state to non-functional (or to tentative state in active/active
mode) to indicate a failure of a monitored object.
Path Monitoring
Monitors the full path through the network to mission-critical IP addresses. ICMP pings are used to verify
reachability of the IP address. The default interval for pings is 200ms. An IP address is considered
unreachable when 10 consecutive pings (the default value) fail, and a firewall failure is triggered when
any or all of the IP addresses monitored become unreachable. The default behavior is any one of the IP
addresses becoming unreachable will cause the firewall to change the HA state to non-functional (or to
tentative state in active/active mode) to indicate a failure of a monitored object.
In addition to the failover triggers listed above, a failover also occurs when the administrator suspends the
firewall or when preemption occurs.
On the PA-3000 Series, PA-5000 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 critical components,
such as the FPGA and CPUs. Additionally, general health checks occur on any platform causing failover.
If a firewall uses LACP or LLDP, negotiation of those protocols upon failover prevents sub-second failover.
However, you can enable an interface on a passive firewall to negotiate LACP and LLDP prior to failover.
Thus, a firewall in Passive or Non-functional HA state can communicate with neighboring devices using
LACP or LLDP. Such pre-negotiation speeds up failover.
The PA-3000 Series, PA-5000 Series, and PA-7000 Series firewalls support a pre-negotiation configuration
depending 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:
Active—The firewall has LACP or LLDP configured on the interface and actively participates in LACP or
LLDP pre-negotiation, respectively.
Passive—LACP or LLDP is not configured on the interface and the firewall does not participate in the
protocol, but allows the peers on either side of the firewall to pre-negotiate LACP or LLDP, respectively.
Pre-negotiation is not supported on subinterfaces or tunnel interfaces.
To configure LACP or LLDP pre-negotiation, see Step 14 of Configure Active/Passive HA.
In a Layer 3 deployment of HA active/active mode, you can assign floating 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 floating IP
address responds to ARP requests with a virtual MAC address.
Floating IP addresses are recommended when you need functionality such as Virtual Router Redundancy
Protocol (VRRP). Floating IP addresses can also be used to implement VPNs and source NAT, allowing for
persistent connections when a firewall offering those services fails.
As shown in the figure below, each HA firewall interface has its own IP address and floating IP address. The
interface IP address remains local to the firewall, but the floating IP address moves between the firewalls
upon firewall failure. You configure the end hosts to use a floating 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 floating IP address and virtual MAC
address move over to the functional firewall. (In the figure below, each firewall has two floating IP addresses
and virtual MAC addresses; they all move over if the firewall fails.) The functioning firewall sends a gratuitous
ARP to update the MAC tables of the connected switches to inform them of the change in floating IP address
and MAC address ownership to redirect traffic to itself.
After the failed firewall recovers, by default the floating IP address and virtual MAC address move back to
firewall with the Device ID [0 or 1] to which the floating IP address is bound. More specifically, after the
failed firewall recovers, it comes on line. The currently active firewall determines that the firewall is back
online and checks whether the floating IP address it is handling belongs natively to itself or the other firewall.
If the floating IP address was originally bound to the other Device ID, the firewall automatically gives it back.
(For an alternative to this default behavior, see Use Case: Configure Active/Active HA with Floating IP
Address Bound to Active-Primary Firewall.)
Each firewall in the HA pair creates a virtual MAC address for each of its interfaces that has a floating IP
address or ARP Load-Sharing IP address.
The format of the virtual MAC address (on firewalls other than PA-7000 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:
The format of the virtual MAC address on PA-7000 Series firewalls is 00-1B-17-xx-xx-xx, where 00-1B-17
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:
When a new active firewall takes over, it sends gratuitous ARPs from each of its connected interfaces to
inform the connected Layer 2 switches of the new location of the virtual MAC address. To configure floating
IP addresses, see Use Case: Configure Active/Active HA with Floating IP Addresses.
ARP Load-Sharing
In a Layer 3 interface deployment and active/active HA configuration, 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.
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 computing the hash or modulo of the
source IP address of the ARP request.
After 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 lifetime of the
ARP cache. The lifetime of the ARP cache depends on the end host operating system.
If a link or firewall fails, the floating IP address and virtual MAC address move over to the functional firewall.
The functional 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 Active/Active HA with ARP Load-Sharing.
You can configure interfaces on the WAN side of the HA firewalls with floating 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 floating IP addresses for the upstream WAN edge routers and an ARP
load-sharing address for the hosts on the LAN segment.
Route-Based Redundancy
In a Layer 3 interface deployment and active/active HA configuration, the firewalls are connected to routers,
not switches. The firewalls use dynamic routing protocols to determine the best path (asymmetric route) and
to load share between the HA pair. In such a scenario, no floating IP addresses are necessary. If a link,
monitored path, or firewall fails, or if Bidirectional Forwarding Detection (BFD) detects a link failure, the
routing protocol (RIP, OSPF, or BGP) handles the rerouting of traffic to the functioning 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
Active/Active HA with Route-Based Redundancy.
HA Timers
High availability (HA) timers facilitate a firewall to detect a firewall failure and trigger a failover. To reduce
the complexity in configuring HA timers, you can select from three profiles: Recommended, Aggressive and
Advanced. These profiles auto-populate the optimum HA timer values for the specific firewall platform to
enable a speedier HA deployment.
Use the Recommended profile for typical failover timer settings and the Aggressive profile for faster failover
timer settings. The Advanced profile allows you to customize the timer values to suit your network
requirements.
The following table describes each timer included in the profiles and the current preset values across the
different hardware models; these values are for current reference only and can change in a subsequent
release.
PA‐3000 Series
VM‐Series
Monitor fail hold up Interval during which the 0/0 0/0 0/0
time firewall will remain active
following a path monitor or
link monitor failure. This
setting is recommended to
avoid an HA failover due to
the occasional flapping of
neighboring devices.
Promotion hold time Time that the passive firewall 2000/500 2000/500 2000/500
(in active/passive mode) or
the active-secondary firewall
(in active/active mode) will
wait before taking over as the
active or active-primary
firewall after communications
with the HA peer have been
lost. This hold time will begin
only after the peer failure
declaration has been made.
PA‐3000 Series
VM‐Series
Maximum no. of A flap is counted when the 3/3 3/3 Not Applicable
flaps firewall leaves the active state
within 15 minutes after it last
left the active state. This value
indicates the maximum
number of flaps that are
permitted before the firewall
is determined to be
suspended and the passive
firewall takes over (range
0-16; default 3).
Session Owner
In an HA active/active configuration, both firewalls are active simultaneously, which means packets can be
distributed between them. Such distribution requires the firewalls to fulfill two functions: session ownership
and session setup. Typically, each firewall of the pair performs one of these functions, thereby avoiding race
conditions 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 active-primary state (the Primary device). If Primary device
is configured, but the firewall that receives the first packet is not in active-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 existing sessions fail over to the
functioning 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 setting the Session Owner to First Packet and the Session Setup to IP Modulo
unless otherwise indicated in a specific use case.
Setting Session Owner and Session Setup to Primary Device causes the active-primary firewall to perform all
traffic processing. You might want to configure this for one of these reasons:
• You are troubleshooting and capturing logs and pcaps, so that packet processing is not split between the
firewalls.
• You want to force the active/active HA pair to function like an active/passive HA pair. See Use Case:
Configure Active/Active HA with Floating IP Address Bound to Active-Primary Firewall.
Session Setup
The session setup firewall performs the Layer2 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 active/active configuration by selecting one of the following
session setup load sharing options.
Session Setup Option Description
IP Modulo The firewall distributes the session setup load based on parity of the source IP
address. This is a deterministic method of sharing the session setup.
IP Hash The firewall uses a hash of the source and destination IP addresses to distribute
session setup responsibilities.
Primary Device The active-primary firewall always sets up the session; only one firewall performs all
session setup responsibilities.
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 responsibilities, set session owner to First
Packet and session setup to IP modulo. These are the recommended settings.
• If you want to do troubleshooting or capture logs or pcaps, or if you want an active/active HA pair to function
like an active/passive HA pair, set both the session owner and session setup to Primary device so that the
active-primary device performs all traffic processing. See Use Case: Configure Active/Active HA with Floating
IP Address Bound to Active-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 dotted lines
indicate FW1 forwarding the packet to FW2 and FW2 forwarding the packet back to FW1 over the HA3 link.
The following figure and text describe the path of a packet that matches an existing session:
In an active/active HA configuration:
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 static NAT rule to either Device ID 0, Device ID 1, both Device IDs, or the firewall in
active-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.
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 translation 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
translation.
If one of the peer firewalls fails, the active firewall continues to process traffic for synchronized sessions
from the failed firewall, including NAT traffic. In a source NAT configuration, when one firewall fails:
The floating IP address that is used as the Translated IP address of the NAT rule transfers to the surviving
firewall. Hence, the existing sessions that fail over will still 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 active/active HA with NAT, see:
Use Case: Configure Active/Active HA with Source DIPP NAT Using Floating IP Addresses
Use Case: Configure Separate Source NAT IP Address Pools for Active/Active HA Firewalls
Use Case: Configure Active/Active HA for ARP Load-Sharing with Destination NAT
Use Case: Configure Active/Active HA for ARP Load-Sharing with Destination NAT in Layer 3
When an active/active HA peer fails, its sessions transfer to the new active-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 active-primary firewall select a new
ECMP path.
If you did not configure the same interfaces on the active/active peers, upon failover the active-primary
firewall selects the next best path from the FIB table. Consequently, the existing sessions might not be
distributed according to the ECMP algorithm.
Set Up Active/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 application, URL, and threat databases.
The same multi virtual system capability—Both firewalls must have Multi Virtual System Capability either
enabled or not enabled. When enabled, each firewall requires its own multiple virtual systems licenses.
The same type of interfaces—Dedicated HA links, or a combination of the management port and in-band
ports that are set to interface type HA.
– Determine the IP address for the HA1 (control) connection 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
connection. Using the management port provides a direct communication 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) connection, determine the IP address
for the HA2 link. Use Layer 3 only if the HA2 connection 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 identically. If both firewalls do not have an identical set of
licenses, they cannot synchronize configuration information and maintain parity for a seamless failover.
As a best practice, if you have an existing firewall and you want to add a new firewall for HA
purposes and the new firewall has an existing configuration, Reset the Firewall to Factory Default
Settings on the new firewall. This ensures that the new firewall has a clean configuration. After
HA is configured, you will then sync the configuration on the primary firewall to the newly
introduced firewall with the clean configuration.
To set up an active (PeerA) passive (PeerB) pair in HA, you must configure some options identically on both
firewalls and some independently (non-matching) on each firewall. These HA settings are not synchronized
between the firewalls. For details on what is/is not synchronized, see Reference: HA Synchronization.
The following checklist details the settings that you must configure identically 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 Floating IP Address and Virtual MAC
Address for information about virtual MAC addresses. When a new active 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 location.
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 Active Passive on both firewalls.
If required, enable preemption on both firewalls. The device priority value, however, must not be
identical.
If required, configure encryption on the HA1 link (for communication between the HA peers) on both
firewalls.
Based on the combination of HA1 and HA1 Backup ports you are using, use the following
recommendations to decide whether you should enable heartbeat backup:
HA functionality (HA1 and HA1 backup) is not supported on the management interface if it's configured for
DHCP addressing (IP Type set to DHCP Client), except for AWS.
The following table lists the HA settings that you must configure independently on each firewall. See
Reference: HA Synchronization for more information about other configuration settings are not
automatically synchronized between peers.
Control Link IP address of the HA1 link configured on this IP address of the HA1 link configured on
firewall (PeerA). 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 Ethernet/Layer 2. By default, the HA2 link uses
The data link If using a Layer 3 connection, configure the IP Ethernet/Layer 2.
information is address for the data link on this firewall (PeerA). If using a Layer 3 connection, configure
synchronized between the IP address for the data link on this
the firewalls after HA firewall (PeerB).
is enabled and the
control link is
established between
the firewalls.
Device Priority The firewall you plan to make active must have a If PeerB is passive, set the device priority
(required, if lower numerical value than its peer. So, if Peer A value to a number larger than the setting
preemption is enabled) is to function as the active firewall, keep the on PeerA. For example, set the value to
default value of 100 and increment the value on 110.
PeerB.
If the firewalls have the same device priority
value, they use the MAC address of their HA1 as
the tie-breaker.
Link Monitoring— Select the physical interfaces on the firewall that Pick a similar set of physical interfaces that
Monitor one or more you would like to monitor and define the failure you would like to monitor on this firewall
physical interfaces condition (all or any) to trigger a failover. and define the failure condition (all or any)
that handle vital traffic to trigger a failover.
on this firewall and
define the failure
condition.
Path Monitoring— Define the failure condition (all or any), ping Pick a similar set of devices or destination
Monitor one or more interval and the ping count. This is particularly IP addresses that can be monitored for
destination IP useful for monitoring the availability of other determining the failover trigger for PeerB.
addresses that the interconnected networking devices. For example, Define the failure condition (all or any),
firewall can use ICMP monitor the availability of a router that connects ping interval and the ping count.
pings to ascertain to a server, connectivity to the server itself, or
responsiveness. 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.
Configure Active/Passive HA
The following procedure shows how to configure a pair of firewalls in an active/passive deployment as
depicted in the following example topology.
To configure an active/passive HA pair, first complete the following workflow on the first firewall and then
repeat the steps on the second firewall.
Connect and Configure the Firewalls
Step 1 Connect the HA ports to set up a • For firewalls with dedicated HA ports, use an Ethernet cable to
physical connection between the connect the dedicated HA1 ports and the HA2 ports on peers.
firewalls. 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. 1. Select Device > Setup > Management and edit the
Enabling ping allows the management Management Interface Settings.
port to exchange heartbeat backup 2. Select Ping as a service that is permitted on the interface.
information.
Step 3 If the firewall does not have dedicated 1. Select Network > Interfaces.
HA ports, set up the data ports to 2. Confirm that the link is up on the ports that you want to use.
function as HA ports.
3. Select the interface and set Interface Type to HA.
For firewalls with dedicated HA ports
continue to the next step. 4. Set the Link Speed and Link Duplex settings, as appropriate.
Connect and Configure the Firewalls (Continued)
Step 4 Set the HA mode and group ID. 1. Select Device > High Availability > General and edit the Setup
section.
2. Set a Group ID and optionally a Description for the pair. The
Group ID uniquely identifies each HA pair on your network. If
you have multiple HA pairs that share the same broadcast
domain you must set a unique Group ID for each pair.
3. Set the mode to Active Passive.
Step 5 Set up the control link connection. 1. In Device > High Availability > General, edit the Control Link
This example shows an in-band port that (HA1) section.
is set to interface type HA. 2. Select the Port that you have cabled for use as the HA1 link.
For firewalls that use the management 3. Set the IPv4/IPv6 Address and Netmask.
port as the control link, the IP address
If the HA1 interfaces are on separate subnets, enter the IP
information is automatically
address of the Gateway. Do not add a gateway address if the
pre-populated.
firewalls are directly connected
Step 6 (Optional) Enable encryption for the 1. Export the HA key from one firewall and import it into the peer
control link connection. firewall.
This is typically used to secure the link if a. Select Device > Certificate Management > Certificates.
the two firewalls are not directly b. Select Export HA key. Save the HA key to a network
connected, that is if the ports are location that the peer can access.
connected to a switch or a router. c. On the peer firewall, select Device > Certificate
Management > Certificates, and select Import HA key to
browse to the location that you saved the key and import it
in to the peer.
2. Select Device > High Availability > General, edit the Control
Link (HA1) section.
3. Select Encryption Enabled.
Step 7 Set up the backup control link 1. In Device > High Availability > General, edit the Control Link
connection. (HA1 Backup) section.
2. Select the HA1 backup interface and set the IPv4/IPv6
Address and Netmask.
Connect and Configure the Firewalls (Continued)
Step 8 Set up the data link connection (HA2) 1. In Device > High Availability > General, edit the Data Link
and the backup HA2 connection (HA2) section.
between the firewalls. 2. Select the Port to use for the data link connection.
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 Synchronization 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 action
will occur. For active/passive configuration, a critical system
log message is generated when an HA2 keep-alive failure
occurs.
You can configure the HA2 keep-alive option on both
firewalls, or just one firewall in the HA pair. If the
option is only enabled on one firewall, only that firewall
will send the keep-alive messages. The other firewall
will be notified if a failure occurs.
7. Edit the Data Link (HA2 Backup) section, select the interface,
and add the IPv4/IPv6 Address and Netmask.
Step 9 Enable heartbeat backup if your control 1. In Device > High Availability > General, edit the Election
link uses a dedicated HA port or an Settings.
in-band port. 2. Select Heartbeat Backup.
You do not need to enable heartbeat To allow the heartbeats to be transmitted between the
backup if you are using the management firewalls, you must verify that the management port across
port for the control link. both peers can route to each other.
Enabling heartbeat backup also allows you to prevent a
split-brain situation. Split brain occurs when the HA1
link goes down causing the firewall to miss heartbeats,
although the firewall is still functioning. In such a
situation, each peer believes that the other is down and
attempts 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 transmitted over
the management port.
Connect and Configure the Firewalls (Continued)
Step 10 Set the device priority and enable 1. In Device > High Availability > General, edit the Election
preemption. Settings.
This setting is only required if you wish to 2. Set the numerical value in Device Priority. Make sure to set a
make sure that a specific firewall is the lower numerical value on the firewall that you want to assign a
preferred active firewall. For higher priority to.
information, see Device Priority and If both firewalls have the same device priority value,
Preemption. the firewall with the lowest MAC address on the HA1
control link will become the active firewall.
3. Select Preemptive.
You must enable preemptive on both the active firewall and
the passive firewall.
Step 11 (Optional) Modify the HA Timers. 1. In Device > High Availability > General, edit the Election
By default, the HA timer profile is set to Settings.
the Recommended profile and is suited 2. Select the Aggressive profile for triggering failover faster;
for most HA deployments. select Advanced to define custom values for triggering failover
in your set up.
To view the preset value for an individual timer
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 (Optional, only configured on the passive Setting the link state to Auto allows for reducing the amount of time
firewall) Modify the link status of the HA it takes for the passive firewall to take over when a failover occurs
ports on the passive firewall. and it allows you to monitor the link state.
The passive link state is To enable the link status on the passive firewall to stay up and
shutdown, by default. After you reflect the cabling status on the physical interface:
enable HA, the link state for the 1. In Device > High Availability > General, edit the Active Passive
HA ports on the active firewall Settings.
will be green and those on the
passive firewall will be down and 2. Set the Passive Link State to Auto.
display as red. The auto option decreases the amount of time it takes for the
passive firewall to take over when a failover occurs.
Although the interface displays green (as cabled and
up) it continues to discard all traffic until 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.
Connect and Configure the Firewalls (Continued)
Step 13 Enable HA. 1. Select Device > High Availability > General and edit the Setup
section.
2. Select Enable HA.
3. Select Enable Config Sync. This setting enables the
synchronization of the configuration settings between the
active 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 (Optional) Enable LACP and LLDP 1. Ensure that in Step 12 you set the link state to Auto.
Pre-Negotiation for Active/Passive HA 2. Select Network > Interfaces > Ethernet.
for faster failover if your network uses
LACP or LLDP. 3. To enable LACP active pre-negotiation:
Enable LACP and LLDP before a. Select an AE interface in a Layer 2 or Layer 3 deployment.
configuring HA pre-negotiation b. Select the LACP tab.
for the protocol if you want c. Select Enable in HA Passive State.
pre-negotiation to function in d. Click OK.
active mode.
You cannot also select Same System MAC Address for
Active-Passive HA because pre-negotiation requires
unique interface MAC addresses on the active and
passive firewalls.
4. To enable LACP passive pre-negotiation:
a. Select an Ethernet interface in a virtual wire deployment.
b. Select the Advanced tab.
c. Select the LACP tab.
d. Select Enable in HA Passive State.
e. Click OK.
5. To enable LLDP active pre-negotiation:
a. Select an Ethernet interface in a Layer 2, Layer 3, or virtual
wire deployment.
b. Select the Advanced tab.
c. Select the LLDP tab.
d. Select Enable in HA Passive State.
e. Click OK.
If you want to allow LLDP passive pre-negotiation for
a virtual wire deployment, perform Step 5 but do not
enable LLDP itself.
Connect and Configure the Firewalls (Continued)
Step 16 After you finish configuring both 1. Access the Dashboard on both firewalls, and view the High
firewalls, verify that the firewalls are Availability widget.
paired in active/passive HA. 2. On the active 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 active firewall: The state of the local firewall should
display active and the Running Config should show as
synchronized.
Configure the Failover Triggers
Step 1 To configure link monitoring, define the 1. Select Device > High Availability > Link and Path Monitoring
interfaces you want to monitor. A and Add a Link Group.
change in the link state of these 2. Name the Link Group, Add the interfaces to monitor, and
interfaces will trigger a failover. select the Failure Condition for the group. The Link group you
define is added to the Link Group section.
Step 2 (Optional) Modify the failure condition 1. Select the Link Monitoring section.
for the Link Groups that you configured 2. Set the Failure Condition to All.
(in the preceding step) on the firewall.
The default setting is Any.
By default, the firewall will trigger a
failover when any monitored link fails.
Step 3 To configure path monitoring, define the 1. In the Path Group section of the Device > High Availability >
destination IP addresses that the firewall Link and Path Monitoring tab, pick the Add option for your set
should ping to verify network up: Virtual Wire, VLAN, or Virtual Router.
connectivity. 2. Select the appropriate item from the drop-down for the Name
and Add the IP addresses (source and/or destination, as
prompted) that you wish to monitor. Then select the Failure
Condition for the group. The path group you define is added to
the Path Group section.
Step 4 (Optional) Modify the failure condition Set the Failure Condition to All.
for all Path Groups configured on the The default setting is Any.
firewall.
By default, the firewall will trigger a
failover when any monitored path fails.
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 information on setting 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.
Verify Failover
To test that your HA configuration works properly, trigger a manual failover and verify that the firewalls
transition states successfully.
Verify Failover
Step 1 Suspend the active firewall. Select Device > High Availability > Operational Commands and
click the Suspend local device link.
Step 2 Verify that the passive firewall has taken On the Dashboard, verify that the state of the passive firewall
over as active. changes to active in the High Availability widget.
Step 3 Restore the suspended firewall to a 1. On the firewall you previously suspended, select Device > High
functional state. Wait for a couple of Availability > Operational Commands and click the Make local
minutes, and then verify that preemption device functional link.
has occurred, if Preemptive is enabled. 2. In the High Availability widget on the Dashboard, confirm that
the firewall has taken over as the active firewall and that the
peer is now in a passive state.
Set Up Active/Active HA
To set up active/active 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 application, URL, and threat databases.
The same multi virtual system capability—Both firewalls must have Multi Virtual System Capability either
enabled or not enabled. When enabled, each firewall requires its own multiple virtual systems licenses.
The same type of interfaces—Dedicated HA links, or a combination of the management port and in-band
ports that are set to interface type HA.
– The HA interfaces must be configured with static IP addresses only, not IP addresses obtained from
DHCP (except AWS can use DHCP addresses). Determine the IP address for the HA1 (control)
connection 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
connection. Using the management port provides a direct communication 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) connection, determine the IP address
for the HA2 link. Use Layer 3 only if the HA2 connection 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. PA-7000 Series firewalls use the HSCI
port. On the remaining platforms, you can configure aggregate interfaces 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 identically. If both firewalls do not have an identical set of
licenses, they cannot synchronize configuration information and maintain parity for a seamless failover.
If you have an existing firewall and you want to add a new firewall for HA purposes and the new
firewall has an existing configuration, it is recommended that you Reset the Firewall to Factory
Default Settings on the new firewall. This will ensure that the new firewall has a clean
configuration. After HA is configured, you will then sync the configuration on the primary firewall
to the newly introduced firewall with the clean config. You will also have to configure local IP
addresses.
Configure Active/Active HA
The following procedure describes the basic workflow for configuring your firewalls in an active/active
configuration. However, before you begin, Determine Your Active/Active Use Case for configuration
examples more tailored to your specific network environment.
To configure active/active, 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.
Configure Active/Active HA
Step 1 Connect the HA ports to set up a • For firewalls with dedicated HA ports, use an Ethernet cable to
physical connection between the connect the dedicated HA1 ports and the HA2 ports on peers.
firewalls. Use a crossover cable if the peers are directly connected to each
For each use case, the firewalls other.
could be any hardware platform; • For firewalls without dedicated HA ports, select two data
choose the HA3 step that interfaces for the HA2 link and the backup HA1 link. Then, use an
corresponds with your platform. 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 any other hardware platform, use dataplane interfaces
for HA3.
Step 2 Enable ping on the management port. 1. In Device > Setup > Management, edit Management Interface
Enabling ping allows the management Settings.
port to exchange heartbeat backup 2. Select Ping as a service that is permitted on the interface.
information.
Step 3 If the firewall does not have dedicated 1. Select Network > Interfaces.
HA ports, set up the data ports to 2. Confirm that the link is up on the ports that you want to use.
function as HA ports.
3. Select the interface and set Interface Type to HA.
For firewalls with dedicated HA ports
continue to the next step. 4. Set the Link Speed and Link Duplex settings, as appropriate.
Step 4 Enable active/active HA and set the 1. In Device > High Availability > General, edit Setup.
group ID. 2. Select Enable HA.
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. (Optional) Enter a Description.
5. For Mode, select Active Active.
Configure Active/Active HA (Continued)
Step 5 Set the Device ID, enable 1. In Device > High Availability > General, edit Setup.
synchronization, and identify the control 2. Select Device ID as follows:
link on the peer firewall
• 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 setting is required to
synchronize the two firewall configurations (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. (Optional) Enter a Backup Peer HA1 IP Address, which is the
IP address of the backup control link on the peer firewall.
6. Click OK.
Step 6 Determine whether or not the firewall 1. In Device > High Availability > General, edit Election Settings.
with the lower Device ID preempts the 2. Select Preemptive to cause the firewall with the lower Device
active-primary firewall upon recovery ID to automatically resume active-primary operation after
from a failure. either firewall recovers from a failure. Both firewalls must
have Preemptive selected for preemption to occur.
Leave Preemptive unselected if you want the active-primary
role to remain with the current firewall until you manually
make the recovered firewall the active-primary firewall.
Step 7 Enable heartbeat backup if your control 1. In Device > High Availability > General, edit Election Settings.
link uses a dedicated HA port or an 2. Select Heartbeat Backup.
in-band port.
To allow the heartbeats to be transmitted between the
You need not enable heartbeat backup if firewalls, you must verify that the management port across
you are using the management port for both peers can route to each other.
the control link.
Enabling heartbeat backup allows you to prevent a
split-brain situation. Split brain occurs when the HA1
link goes down, causing the firewall to miss heartbeats,
although the firewall is still functioning. In such a
situation, each peer believes the other is down and
attempts to start services that are running, thereby
causing a split brain. Enabling heartbeat backup
prevents split brain because redundant heartbeats and
hello messages are transmitted over the management
port.
Step 8 (Optional) Modify the HA Timers. 1. In Device > High Availability > General, edit Election Settings.
By default, the HA timer profile is set to 2. Select Aggressive to trigger faster failover. Select Advanced
the Recommended profile and is suited to define custom values for triggering failover in your setup.
for most HA deployments. To view the preset value for an individual timer
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.
Configure Active/Active HA (Continued)
Step 9 Set up the control link connection. 1. In Device > High Availability > General, edit Control Link
This example uses an in-band port that is (HA1).
set to interface type HA. 2. Select the Port that you have cabled for use as the HA1 link.
For firewalls that use the management 3. Set the IPv4/IPv6 Address and Netmask.
port as the control link, the IP address
If the HA1 interfaces are on separate subnets, enter the IP
information is automatically
address of the Gateway. Do not add a gateway address if the
pre-populated.
firewalls are directly connected.
Step 10 (Optional) Enable encryption for the 1. Export the HA key from one firewall and import it into the peer
control link connection. firewall.
This is typically used to secure the link if a. Select Device > Certificate Management > Certificates.
the two firewalls are not directly b. Select Export HA key. Save the HA key to a network
connected, that is if the ports are location that the peer can access.
connected to a switch or a router. c. On the peer firewall, select Device > Certificate
Management > Certificates, and select Import HA key to
browse to the location 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 Encryption Enabled.
Step 11 Set up the backup control link 1. In Device > High Availability > General, edit Control Link (HA1
connection. Backup).
2. Select the HA1 backup interface and set the IPv4/IPv6
Address and Netmask.
Step 12 Set up the data link connection (HA2) 1. In Device > High Availability > General, edit Data Link (HA2).
and the backup HA2 connection 2. Select the Port to use for the data link connection.
between the firewalls.
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 Synchronization 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 action
will occur. For active/passive configuration, a critical system
log message is generated when an HA2 keep-alive failure
occurs.
You can configure the HA2 keep-alive option on both
firewalls, or just one firewall in the HA pair. If the
option is only enabled on one firewall, only that
firewall will send the keep-alive messages. The other
firewall will be notified if a failure occurs.
7. Edit the Data Link (HA2 Backup) section, select the interface,
and add the IPv4/IPv6 Address and Netmask.
8. Click OK.
Configure Active/Active HA (Continued)
Step 13 Configure the HA3 link for packet 1. In Device > High Availability > Active/Active Config, edit
forwarding. Packet Forwarding.
2. For HA3 Interface, select the interface you want to use to
forward packets between active/active 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 synchronization of all virtual routers
configured on the HA peers. Select when the virtual router is
not configured for dynamic routing protocols. Both peers must
be connected to the same next-hop router through a switched
network and must use static routing only.
4. Select QoS Sync to synchronize the QoS profile selection on all
physical interfaces. Select when both peers have similar link
speeds and require the same QoS profiles on all physical
interfaces. This setting affects the synchronization of QoS
settings on the Network tab. QoS policy is synchronized
regardless of this setting.
Step 14 (Optional) Modify the Tentative Hold 1. In Device > High Availability > Active/Active Config, edit
time. Packet Forwarding.
2. For Tentative Hold Time (sec), enter the number of seconds
that a firewall stays in Tentative state after it fails (range is
10-600, default is 60).
Step 15 Configure Session Owner and Session 1. In Device > High Availability > Active/Active Config, edit
Setup. Packet Forwarding.
2. For Session Owner Selection, select one of the following:
• First Packet—The firewall that receives the first packet of
a new session is the session owner (recommended setting).
This setting minimizes traffic across HA3 and load shares
traffic across peers.
• Primary Device—The firewall that is in active-primary state
is the session owner.
3. For Session Setup, select one of the following:
• IP Modulo— Distributes session setup load based on parity
of the source IP address (recommended setting).
• Primary Device—The active-primary firewall sets up all
sessions.
• First Packet—The firewall that receives the first packet of
a new session performs session setup.
• IP Hash—The firewall uses a hash of either the source IP
address or a combination of the source and destination IP
addresses to distribute session setup responsibilities.
4. Click OK.
Configure Active/Active HA (Continued)
Step 16 Configure an HA virtual address. 1. In Device > High Availability > Active/Active Config, Add a
You need a virtual address to use a Virtual Address.
Floating IP Address and Virtual MAC 2. Enter or select an Interface.
Address or ARP Load-Sharing.
3. Select the IPv4 or IPv6 tab and click Add.
4. Enter an IPv4 Address or IPv6 Address.
5. For Type:
• Select Floating to configure the virtual IP address to be a
floating 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 floating IP address. 1. Do not select Floating IP bound to the Active-Primary device
unless you want the active/active HA pair to behave like an
active/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,
respectively. The relative priorities determine which peer
owns the floating IP address you just configured (range is
0-255). The firewall with the lowest priority value (highest
priority) owns the floating 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. 1. For Device Selection Algorithm, select one of the following:
The device selection algorithm • IP Modulo—The firewall that will respond to ARP requests
determines which HA firewall responds is based on the parity of the ARP requester's IP address.
to the ARP requests to provide load • IP Hash—The firewall that will respond to ARP requests is
sharing. based on a hash of the ARP requester's IP address.
2. Click OK.
Step 19 Enable jumbo frames on firewalls other 1. Select Device > Setup > Session.
than PA-7000 Series firewalls. 2. In the Session Settings section, select Enable Jumbo Frames.
Switch ports that connect the HA3 link
3. Click OK.
must support jumbo frames to handle
the overhead associated with the 4. Repeat on any intermediary networking devices.
MAC-in-MAC encapsulation on the HA3
link.
The jumbo frame packet size on
the firewall must match the
setting on the switch.
Step 22 Reboot the firewall after changing the 1. Select Device > Setup > Operations.
jumbo frame configuration. 2. Click Reboot Device.
Determine which type of use case you have and then select the corresponding procedure to configure
active/active HA.
If you are using Route-Based Redundancy, Floating IP Address and Virtual MAC Address, or ARP
Load-Sharing, select the corresponding procedure:
Use Case: Configure Active/Active HA with Route-Based Redundancy
Use Case: Configure Active/Active HA with Floating IP Addresses
Use Case: Configure Active/Active HA with ARP Load-Sharing
If you want a Layer 3 active/active HA deployment that behaves like an active/passive deployment, select
the following procedure:
Use Case: Configure Active/Active HA with Floating IP Address Bound to Active-Primary Firewall
If you are configuring NAT in Active/Active HA Mode, see the following procedures:
Use Case: Configure Active/Active HA with Source DIPP NAT Using Floating IP Addresses
Use Case: Configure Separate Source NAT IP Address Pools for Active/Active HA Firewalls
Use Case: Configure Active/Active HA for ARP Load-Sharing with Destination NAT
Use Case: Configure Active/Active HA for ARP Load-Sharing with Destination NAT in Layer 3
The following Layer 3 topology illustrates two PA-7050 firewalls in an active/active 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 redirecting traffic to the functioning firewall.
Configure Active/Active HA with Route‐Based Redundancy
In this Layer 3 interface example, the HA firewalls connect to switches and use floating IP addresses to
handle link or firewall failures. The end hosts are each configured with a gateway, which is the floating IP
address of one of the HA firewalls. See Floating IP Address and Virtual MAC Address.
Configure Active/Active HA with Floating IP Addresses
Step 2 Configure an HA virtual address. 1. In Device > High Availability > Active/Active Config, Add a
You need a virtual address to use a Virtual Address.
Floating IP Address and Virtual MAC 2. Enter or select an Interface.
Address.
3. Select the IPv4 or IPv6 tab and click Add.
4. Enter an IPv4 Address or IPv6 Address.
5. For Type, select Floating to configure the virtual IP address to
be a floating IP address.
Step 3 Configure the floating IP address. 1. Do not select Floating IP bound to the Active-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,
respectively. The relative priorities determine which peer
owns the floating IP address you just configured (range is
0-255). The firewall with the lowest priority value (highest
priority) owns the floating 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.
Configure Active/Active HA with Floating IP Addresses (Continued)
Step 4 Enable jumbo frames on firewalls other Perform Step 19 of Configure Active/Active HA.
than PA-7000 Series firewalls.
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.
Configure Active/Active HA with ARP Load‐Sharing
Configure Active/Active HA with ARP Load‐Sharing (Continued)
Step 2 Configure an HA virtual address. 1. Select Device > High Availability > Active/Active Config >
The virtual address is the shared IP Virtual Address and click Add.
address that allows ARP Load-Sharing. 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 ARP Load Sharing, which allows both peers
to use the virtual IP address for ARP Load-Sharing.
Step 3 Configure ARP Load-Sharing. 1. For Device Selection Algorithm, select one of the following:
The device selection algorithm • IP Modulo—The firewall that will respond to ARP requests
determines which HA firewall responds is based on the parity of the ARP requester's IP address.
to the ARP requests to provide load • IP Hash—The firewall that will respond to ARP requests is
sharing. based on a hash of the ARP requester's IP address.
2. Click OK.
Step 4 Enable jumbo frames on firewalls other Enable jumbo frames on firewalls other than PA-7000 Series
than PA-7000 Series firewalls. firewalls.
In mission-critical data centers, you may want both Layer 3 HA firewalls to participate in path monitoring so
that they can detect path failures upstream from both firewalls. Additionally, you prefer to control if and
when the floating IP address returns to the recovered firewall after it comes back up, rather than the floating
IP address returning to the device ID to which it is bound. (That default behavior is described in Floating IP
Address and Virtual MAC Address.)
In this use case, you control when the floating IP address and therefore the active-primary role move back
to a recovered HA peer. The active/active HA firewalls share a single floating IP address that you bind to
whichever firewall is in the active-primary state. With only one floating IP address, network traffic flows
predominantly to a single firewall, so this active/active deployment functions like an active/passive
deployment.
In this use case, Cisco Nexus 7010 switches with virtual PortChannels (vPCs) operating 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 floating IP address. That is, you must design your network so the route tables of
the router peers have the best path to the floating IP address. This example uses static routes with the proper
metrics so that the route to the floating IP address uses a lower metric (the route to the floating IP address
is preferred) and receives the traffic. An alternative to using static routes would be to design the network to
redistribute the floating IP address into the OSPF routing protocol (if you are using OSPF).
The following topology illustrates the floating IP address bound to the active-primary firewall, which is
initially Peer A, the firewall on the left.
Upon a failover, when the active-primary firewall (Peer A) goes down and the active-secondary firewall (Peer
B) takes over as the active-primary peer, the floating IP address moves to Peer B (shown in the following
figure). Peer B remains the active-primary firewall and traffic continues to go to Peer B, even when Peer A
recovers and becomes the active-secondary firewall. You decide if and when to make Peer A the
active-primary firewall again.
Binding the floating IP address to the active-primary firewall provides you with more control over how the
firewalls determine floating IP address ownership as they move between various HA Firewall States. The
following advantages result:
You can have an active/active HA configuration for path monitoring out of both firewalls, but have the
firewalls function like an active/passive HA configuration because traffic directed to the floating IP
address always goes to the active-primary firewall.
When you disable preemption on both firewalls, you have the following additional benefits:
The floating IP address does not move back and forth between HA firewalls if the active-secondary
firewall flaps up and down.
You can review the functionality of the recovered firewall and the adjacent components before manually
directing traffic to it again, which you can do at a convenient down time.
You have control over which firewall owns the floating IP address so that you keep all flows of new and
existing sessions on the active-primary firewall, thereby minimizing traffic on the HA3 link.
• We strongly recommended you configure HA link monitoring on the interface(s) that support the floating 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 function.
• We strongly recommend you configure HA path monitoring to notify each HA peer when a path has failed so
a firewall can fail over to its peer. Because the floating IP address is always bound to the active-primary
firewall, the firewall cannot automatically fail over to the peer when a path goes down and path monitoring is
not enabled.
You cannot configure NAT for a floating IP address that is bound to an active-primary firewall.
Configure Active/Active HA with Floating IP Address Bound to Active‐Primary Firewall
Step 2 (Optional) Disable preemption. 1. In Device > High Availability > General, edit the Election
Disabling preemption allows you Settings.
full control over when the 2. Clear Preemptive if it is enabled.
recovered firewall becomes the
3. Click OK.
active-primary firewall.
Configure Active/Active HA with Floating IP Address Bound to Active‐Primary Firewall (Continued)
Step 4 Configure Session Owner and Session 1. In Device > High Availability > Active/Active Config, edit
Setup. Packet Forwarding.
2. For Session Owner Selection, we recommend you select
Primary Device. The firewall that is in active-primary state is
the session owner.
Alternatively, for Session Owner Selection you can select
First Packet and then for Session Setup, select Primary
Device or First Packet.
3. For Session Setup, select Primary Device—The
active-primary firewall sets up all sessions. This is the
recommended setting if you want your active/active
configuration to behave like an active/passive configuration
because it keeps all activity on the active-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
active-secondary firewall, setting Session Owner
Selection and Session Setup to Primary Device
causes the traffic to traverse HA3 to get to the
active-primary firewall for session ownership and
session setup.
4. Click OK.
Step 5 Configure an HA virtual address. 1. Select Device > High Availability > Active/Active Config >
Virtual Address and click Add.
2. Enter or select an Interface.
3. Select the IPv4 or IPv6 tab and Add an IPv4 Address or IPv6
Address.
4. For Type, select Floating, which configures the virtual IP
address to be a floating IP address.
5. Click OK.
Step 6 Bind the floating IP address to the 1. Select Floating IP bound to the Active-Primary device.
active-primary firewall. 2. 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.
3. Click OK.
Step 7 Enable jumbo frames on firewalls other Enable jumbo frames on firewalls other than PA-7000 Series
than PA-7000 Series firewalls. firewalls.
Use Case: Configure Active/Active HA with Source DIPP NAT Using Floating
IP Addresses
This Layer 3 interface example uses source NAT in Active/Active 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 floating IP address configured on the egress interface. Each
host is configured with a default gateway address, which is the floating IP address on Ethernet1/1 of each
firewall. The configuration 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.
Configure Active/Active HA with Source DIPP NAT Using Floating IP Address
Configure Active/Active HA with Source DIPP NAT Using Floating IP Address (Continued)
Step 2 Enable active/active HA. 1. In Device > High Availability > General, edit Setup.
2. Select Enable HA.
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. For Mode, select Active Active.
5. Set the Device ID to 1.
6. Select Enable Config Sync. This setting is required to
synchronize the two firewall configurations (enabled by
default).
7. Enter the Peer HA1 IP Address, which is the IP address of the
HA1 control link on the peer firewall.
8. (Optional) Enter a Backup Peer HA1 IP Address, which is the
IP address of the backup control link on the peer firewall.
9. Click OK.
Step 4 Configure Session Owner and Session 1. In Device > High Availability > Active/Active Config, edit
Setup. Packet Forwarding.
2. For Session Owner Selection, 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.
Step 5 Configure an HA virtual address. 1. Select Device > High Availability > Active/Active Config >
Virtual Address and click Add.
2. Select Interface eth1/1.
3. Select IPv4 and Add an IPv4 Address of 10.1.1.101.
4. For Type, select Floating, which configures the virtual IP
address to be a floating IP address.
Step 6 Configure the floating IP address. 1. Do not select Floating IP bound to the Active-Primary device.
2. 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.
3. Click OK.
Configure Active/Active HA with Source DIPP NAT Using Floating IP Address (Continued)
Step 9 Still on PA-3050-1, create the source 1. Select Policies > NAT and click Add.
NAT rule for Device ID 0. 2. Enter a Name for the rule that in this example identifies 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 Destination Zone, select the zone you created for the
external network.
6. Allow Destination Interface, Service, Source Address, and
Destination Address to remain set to Any.
7. For the Translated Packet, select Dynamic IP And Port for
Translation 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 floating IP address 10.1.1.100.
9. On the Active/Active HA Binding tab, for Active/Active HA
Binding, select 0 to bind the NAT rule to Device ID 0.
10. Click OK.
Configure Active/Active HA with Source DIPP NAT Using Floating IP Address (Continued)
Step 10 Create the source NAT rule for 1. Select Policies > NAT and click Add.
Device ID 1. 2. Enter a Name for the policy rule that in this example helps
identify it as a source NAT rule for Device ID 1.
3. For NAT Type, select ipv4 (default).
4. On the Original Packet, for Source Zone, select Any. For
Destination Zone, select the zone you created for the external
network.
5. Allow Destination Interface, Service, Source Address, and
Destination Address to remain set to Any.
6. For the Translated Packet, select Dynamic IP And Port for
Translation 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 floating IP address 10.1.1.101.
8. On Active/Active HA Binding tab, for the Active/Active HA
Binding, select 1 to bind the NAT rule to Device ID 1.
9. Click OK.
If you want to use IP address pools for source NAT in Active/Active 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 active/passive and active/active 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.
Create Address Objects for IP Address Pools for Source NAT in an Active/Active HA Configuration
Step 1 On one HA firewall, create address 1. Select Objects > Addresses and Add an address object Name,
objects. 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.
Create Address Objects for IP Address Pools for Source NAT in an Active/Active HA Configuration (Continued)
Step 2 Create the source NAT rule for 1. Select Policies > NAT and Add a NAT policy rule with a Name,
Device ID 0. for example, Src-NAT-dev0.
2. For Original Packet, for Source Zone, select Any.
3. For Destination Zone, select the destination zone for which
you want to translate the source address, such as Untrust.
4. For Translated Packet, for Translation 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 Active/Active HA Binding, select 0 to bind the NAT rule to
Device ID 0.
7. Click OK.
Step 3 Create the source NAT rule for 1. Select Policies > NAT and Add a NAT policy rule with a Name,
Device ID 1. for example, Src-NAT-dev1.
2. For Original Packet, for Source Zone, select Any.
3. For Destination Zone, select the destination zone for which
you want to translate the source address, such as Untrust.
4. For Translated Packet, for Translation 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 Active/Active HA Binding, select 1 to bind the NAT rule to
Device ID 1.
7. Click OK.
This Layer 3 interface example uses NAT in Active/Active HA Mode and ARP Load-Sharing with destination
NAT. Both HA firewalls respond to an ARP request for the destination NAT address with the ingress
interface MAC address. Destination 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 destination 10.1.1.200, both firewalls could possibly respond
to the ARP request, which could cause network instability. To avoid the potential issue, configure the firewall
that is in active-primary state to respond to the ARP request by binding the destination NAT rule to the
active-primary firewall.
Configure Active/Active HA for ARP Load‐Sharing with Destination NAT
Step 2 Enable active/active HA. 1. In Device > High Availability > General, edit Setup.
2. Select Enable HA.
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. (Optional) Enter a Description.
5. For Mode, select Active Active.
6. Select Device ID to be 1.
7. Select Enable Config Sync. This setting is required to
synchronize the two firewall configurations (enabled by
default).
8. Enter the Peer HA1 IP Address, which is the IP address of the
HA1 control link on the peer firewall.
9. (Optional) Enter a Backup Peer HA1 IP Address, which is the
IP address of the backup control link on the peer firewall.
10. Click OK.
Configure Active/Active HA for ARP Load‐Sharing with Destination NAT (Continued)
Step 4 Configure an HA virtual address. 1. Select Device > High Availability > Active/Active Config >
Virtual Address and click Add.
2. Select Interface eth1/1.
3. Select IPv4 and Add an IPv4 Address of 10.1.1.200.
4. For Type, select ARP Load Sharing, which configures the
virtual IP address to be for both peers to use for ARP
Load-Sharing.
Step 5 Configure ARP Load-Sharing. 1. For Device Selection Algorithm, select IP Modulo. The firewall
The device selection algorithm that will respond to ARP requests is based on the parity of the
determines which HA firewall responds ARP requester's IP address.
to the ARP requests to provide load 2. Click OK.
sharing.
Step 6 Enable jumbo frames on firewalls other than PA-7000 Series firewalls.
Step 10 Still on PA-3050-1 (Device ID 0), create 1. Select Policies > NAT and click Add.
the destination NAT rule so that the 2. Enter a Name for the rule that, in this example, identifies it as
active-primary firewall responds to ARP a destination NAT rule for Layer 2 ARP.
requests.
3. For NAT Type, select ipv4 (default).
4. On the Original Packet, for Source Zone, select Any.
5. For Destination Zone, select the Untrust zone you created for
the external network.
6. Allow Destination Interface, Service, and Source Address to
remain set to Any.
7. For Destination Address, specify 10.1.1.200.
8. For the Translated Packet, Source Address Translation
remains None.
9. For Destination Address Translation, enter the private IP
address of the destination server, in this example,
192.168.1.200.
10. On the Active/Active HA Binding tab, for Active/Active HA
Binding, select primary to bind the NAT rule to the firewall in
active-primary state.
11. Click OK.
This Layer 3 interface example uses NAT in Active/Active 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 destination NAT address.
Traffic can arrive at either firewall from either WAN router in the untrust zone. Destination NAT translates
the public-facing, shared IP address to the private IP address of the server. The configuration requires one
destination NAT rule bound to both Device IDs so that both firewalls can respond to ARP requests.
Configure Active/Active HA for ARP Load‐Sharing with Destination NAT in Layer 3
Configure Active/Active HA for ARP Load‐Sharing with Destination NAT in Layer 3 (Continued)
Step 2 Enable active/active HA. 1. Select Device > High Availability > General > Setup and edit.
2. Select Enable HA.
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. (Optional) Enter a Description.
5. For Mode, select Active Active.
6. Select Device ID to be 1.
7. Select Enable Config Sync. This setting is required to
synchronize the two firewall configurations (enabled by
default).
8. Enter the Peer HA1 IP Address, which is the IP address of the
HA1 control link on the peer firewall.
9. (Optional) Enter a Backup Peer HA1 IP Address, which is the
IP address of the backup control link on the peer firewall.
10. Click OK.
Step 4 Configure an HA virtual address. 1. Select Device > High Availability > Active/Active Config >
Virtual Address and click Add.
2. Select Interface eth1/2.
3. Select IPv4 and Add an IPv4 Address of 10.1.1.200.
4. For Type, select ARP Load Sharing, which configures the
virtual IP address to be for both peers to use for ARP
Load-Sharing.
Step 5 Configure ARP Load-Sharing. 1. For Device Selection Algorithm, select one of the following
The device selection algorithm • IP Modulo—The firewall that will respond to ARP requests
determines which HA firewall responds is based on the parity of the ARP requester's IP address.
to the ARP requests to provide load • IP Hash—The firewall that will respond to ARP requests is
sharing. based on a hash of the ARP requester's source IP address
and destination IP address.
2. Click OK.
Step 6 Enable jumbo frames on firewalls other than PA-7000 Series firewalls.
Configure Active/Active HA for ARP Load‐Sharing with Destination NAT in Layer 3 (Continued)
Step 10 Still on PA-3050-1 (Device ID 0), create 1. Select Policies > NAT and click Add.
the destination NAT rule for both Device 2. Enter a Name for the rule that in this example identifies it as a
ID 0 and Device ID 1. destination NAT rule for Layer 3 ARP.
3. For NAT Type, select ipv4 (default).
4. On the Original Packet, for Source Zone, select Any.
5. For Destination Zone, select the Untrust zone you created for
the external network.
6. Allow Destination Interface, Service, and Source Address to
remain set to Any.
7. For Destination Address, specify 10.1.1.200.
8. For the Translated Packet, Source Address Translation
remains None.
9. For Destination Address Translation, enter the private IP
address of the destination server, in this example
192.168.1.200.
10. On the Active/Active HA Binding tab, for Active/Active HA
Binding, select both to bind the NAT rule to both Device ID 0
and Device ID 1.
11. Click OK.
HA Firewall States
Initial A/P or A/A Transient state of a firewall when it joins the HA pair. The firewall remains in this
state after boot-up until it discovers a peer and negotiations begins. After a
timeout, the firewall becomes active if HA negotiation has not started.
Passive A/P State of the passive firewall in an active/passive configuration. The passive
firewall is ready to become the active firewall with no disruption to the network.
Although the passive firewall is not processing other traffic:
• If passive link state auto is configured, the passive firewall is running routing
protocols, monitoring link and path state, and the passive firewall will
pre-negotiate LACP and LLDP if LACP and LLDP pre-negotiation are
configured, respectively.
• The passive firewall is synchronizing flow state, runtime objects, and
configuration.
• The passive firewall is monitoring the status of the active firewall using the
hello protocol.
Active-Primary A/A In an active/active configuration, 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 active-primary firewall. A firewall in this state can own
sessions and set up sessions.
Active-Secondary A/A In an active/active configuration, state of the firewall that connects to User-ID
agents, runs DHCP server, and matches NAT and PBF rules with the Device ID
of the active-secondary firewall. A firewall in active-secondary state does not
support DHCP relay. A firewall in this state can own sessions and set up sessions.
Tentative A/A State of a firewall (in an active/active configuration) 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-functional state.
A firewall in tentative state synchronizes sessions and configurations from the
peer.
• In a virtual wire deployment, when a firewall enters tentative 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 tentative 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 destination or sends it back to the peer in tentative state for
forwarding.
After the failed path or link clears or as a failed firewall transitions from tentative
state to active-secondary state, the Tentative Hold Time is triggered and routing
convergence occurs. The firewall attempts to build routing adjacencies and
populate its route table before processing any packets. Without this timer, the
recovering firewall would enter active-secondary state immediately and would
blackhole packets because it would not have the necessary routes.
When a firewall leaves suspended state, it goes into tentative state for the
Tentative Hold Time after links are up and able to process incoming packets.
Tentative Hold Time range (sec) can be disabled (which is 0 seconds) or in the
range 10-600; default is 60.
Non-functional A/P or A/A Error state due to a dataplane failure or a configuration mismatch, such as only
one firewall configured for packet forwarding, VR sync or QoS sync.
In active/passive mode, all of the causes listed for Tentative state cause
non-functional state.
Suspended A/P or A/A Administratively disabled state. In this state, an HA firewall cannot participate in
the HA election process.
Reference: HA Synchronization
If you have enabled configuration synchronization on both peers in an HA pair, most of the configuration
settings you configure on one peer will automatically sync to the other peer upon commit. To avoid
configuration conflicts, always make configuration changes on the active (active/passive) or active-primary
(active/active) peer and wait for the changes to sync to the peer before making any additional configuration
changes.
Only committed configurations synchronize between HA peers. Any configuration in the commit queue at the
time of an HA sync will not be synchronized.
The following topics identify which configuration settings you must configure on each firewall independently
(these settings are not synchronized from the HA peer).
What Settings Don’t Sync in Active/Passive HA?
What Settings Don’t Sync in Active/Active HA?
Synchronization of System Runtime Information
You must configure the following settings on each firewall in an HA pair in an active/passive deployment.
These settings do not sync from one peer to another.
Configuration Item What Doesn’t Sync in Active/Passive?
Management Interface All management configuration settings must be configured individually on each
Settings firewall, including:
• Device > Setup > Management > General Settings—Hostname, Domain, Login
Banner, SSL/TLS Service Profile, Time Zone, Locale, Date, Time, Latitude,
Longitude.
The configuration for the associated SSL/TLS Service profile (Device >
Certificate Management > SSL/TLS Service Profile and the associated
certificates (Device > Certificate Management > Certificates) is
synchronized. It is just the setting of which SSL/TLS Service Profile to use
on the Management interface that does not sync.
• Device > Setup > Management > Management Interface Settings—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)
Multi-vsys Capability You must activate 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-3000 Series, PA-4000 Series, PA-5000 Series, and PA-7000 Series firewalls.
You must also enable Multi Virtual System Capability on each firewall (Device >
Setup > Management > General Settings).
Configuration Item What Doesn’t Sync in Active/Passive?
Administrator You must define the authentication profile and certificate profile for administrative
Authentication Settings access to the firewall locally on each firewall (Device > Setup > Management >
Authentication).
Panorama Settings Set the following Panorama settings on each firewall (Device > Setup >
Management > Panorama Settings).
• Panorama Servers
• Disable Panorama Policy and Objects and Disable Device and Network Template
Statistics Collection • Device > Setup > Operations > Statistics Service Setup
Global Service Routes • Device > Setup > Services > Service Route Configuration
Data Protection • Device > Setup > Content-ID > Manage Data Protection
Jumbo Frames • Device > Setup > Session > Session Settings > Enable Jumbo Frame
Forward Proxy Server • Device > Setup > Session > Decryption Settings > SSL Forward Proxy Settings
Certificate Settings
Master Key Secured by • Device > Setup > HSM > Hardware Security Module Provider > Master Key
HSM Secured by HSM
Software Updates With software 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 > Software
GlobalProtect Agent With GlobalProtect client updates, you can either download and install them
Package separately on each firewall, or download them to one peer and sync the update to the
other peer. You must activate separately on each peer.
• Device > GlobalProtect Client
Content Updates With content 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 > Dynamic Updates
Master Key The master key must be identical on each firewall in the HA pair, but you must
manually enter it on each firewall (Device > Master Key and Diagnostics).
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 after you change the keys.
Reports, logs, and Log data, reports, and Dashboard data and settings (column display, widgets) are not
Dashboard Settings synced between peers. Report configuration settings, however, are synced.
You must configure the following settings on each firewall in an HA pair in an active/active deployment.
These settings do not sync from one peer to another.
Configuration Item What Doesn’t Sync in Active/Active?
Management Interface You must configure all management settings individually on each firewall, including:
Settings • Device > Setup > Management > General Settings—Hostname, Domain, Login
Banner, SSL/TLS Service Profile, Time Zone, Locale, Date, Time, Latitude,
Longitude.
The configuration for the associated SSL/TLS Service profile (Device >
Certificate Management > SSL/TLS Service Profile and the associated
certificates (Device > Certificate Management > Certificates) is
synchronized. It is just the setting of which SSL/TLS Service Profile to use
on the Management interface that does not sync.
• Device > Setup > Management > Management Interface Settings—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)
Multi-vsys Capability You must activate 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-3000 Series, PA-4000 Series, PA-5000 Series, and PA-7000 Series firewalls.
You must also enable Multi Virtual System Capability on each firewall (Device >
Setup > Management > General Settings).
Administrator You must define the authentication profile and certificate profile for administrative
Authentication Settings access to the firewall locally on each firewall (Device > Setup > Management >
Authentication).
Panorama Settings Set the following Panorama settings on each firewall (Device > Setup >
Management > Panorama Settings).
• Panorama Servers
• Disable Panorama Policy and Objects and Disable Device and Network Template
Statistics Collection • Device > Setup > Operations > Statistics Service Setup
Global Service Routes • Device > Setup > Services > Service Route Configuration
Data Protection • Device > Setup > Content-ID > Manage Data Protection
Jumbo Frames • Device > Setup > Session > Session Settings > Enable Jumbo Frame
Forward Proxy Server • Device > Setup > Session > Decryption Settings > SSL Forward Proxy Settings
Certificate Settings
Configuration Item What Doesn’t Sync in Active/Active?
Software Updates With software 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 > Software
GlobalProtect Agent With GlobalProtect client updates, you can either download and install them
Package separately on each firewall, or download them to one peer and sync the update to the
other peer. You must activate separately on each peer.
• Device > GlobalProtect Client
Content Updates With content 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 > Dynamic Updates
Ethernet Interface IP All Ethernet interface configuration settings sync except for the IP address (Network
Addresses > Interface > Ethernet).
Loopback Interface IP All Loopback interface configuration settings sync except for the IP address
Addresses (Network > Interface > Loopback).
Tunnel Interface IP All Tunnel interface configuration settings sync except for the IP address (Network >
Addresses Interface > Tunnel).
LACP System Priority Each peer must have a unique LACP System ID in an active/active deployment
(Network > Interface > Ethernet > Add Aggregate Group > System Priority).
VLAN Interface IP Address All VLAN interface configuration settings sync except for the IP address (Network >
Interface > VLAN).
Virtual Routers Virtual router configuration synchronizes only if you have enabled VR Sync (Device >
High Availability > Active/Active Config > Packet Forwarding). Whether or not to do
this depends on your network design, including whether you have asymmetric
routing.
IPSec Tunnels IPSec tunnel configuration synchronization is dependent on whether you have
configured the Virtual Addresses to use Floating IP addresses (Device > High
Availability > Active/Active Config > Virtual Address). If you have configured a
floating IP address, these settings sync automatically. Otherwise, you must configure
these settings independently on each peer.
Configuration Item What Doesn’t Sync in Active/Active?
QoS QoS configuration synchronizes only if you have enabled QoS Sync (Device > High
Availability > Active/Active Config > Packet Forwarding). You might choose not to
sync QoS setting if, for example, you have different bandwidth on each link or
different latency through your service providers.
IKE Gateways IKE gateway configuration synchronization is dependent on whether you have
configured the Virtual Addresses to use floating IP addresses (Network > IKE
Gateways). If you have configured a floating IP address, the IKE gateway
configuration settings sync automatically. Otherwise, you must configure the IKE
gateway settings independently on each peer.
Master Key The master key must be identical on each firewall in the HA pair, but you must
manually enter it on each firewall (Device > Master Key and Diagnostics).
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 after you change the keys.
Reports, logs, and Log data, reports, and dashboard data and settings (column display, widgets) are not
Dashboard Settings synced between peers. Report configuration settings, however, are synced.
The following table summarizes what system runtime information is synchronized between HA peers.
A/P A/A
Management Plane
A/P A/A
Dataplane
Session Table Yes Yes HA2 • Active/passive peers do not sync ICMP
or host session information.
• Active/active peers do not sync host
session, multicast session, or BFD
session information.
ARP Table Yes No HA2 Upon upgrade to PAN-OS 7.1, the ARP
table capacity automatically increases. To
avoid a mismatch, upgrade both peers
within a short period of time.
As a best practice, clear the ARP
cache (clear arp) on both peers
prior to upgrading to PAN-OS 7.1.
The Dashboard tab widgets show general firewall information, such as the software version, the operational
status of each interface, resource utilization, and up to 10 of the most recent entries in the threat,
configuration, 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 automatic 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 title bar. The following table describes the
dashboard widgets.
Dashboard Charts Descriptions
Top Applications Displays the applications with the most sessions. The block size indicates the relative
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 application to view its
application profile.
Top High Risk Applications Similar to Top Applications, except that it displays the highest-risk applications with the
most sessions.
General Information Displays the firewall name, model, PAN-OS software version, the application, threat, and
URL filtering definition versions, the current date and time, and the length of time 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, application, and date and time for the last 10 entries in the Threat
log. The threat ID is a malware description or URL that violates the URL filtering profile.
Config Logs Displays the administrator username, client (Web or CLI), and date and time for the last 10
entries in the Configuration log.
Data Filtering Logs Displays the description and date and time for the last 60 minutes in the Data Filtering log.
URL Filtering Logs Displays the description and date and time for the last 60 minutes in the URL Filtering log.
System Logs Displays the description and date and time for the last 10 entries in the System log.
A Config installed entry indicates configuration changes were committed
successfully.
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 time 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 (active), yellow (passive), or black (other). For more information about HA, see High