Palo Alto Networks Integration Guide

Overview

The Palo Alto Networks integration allows your NINA workflows to connect with PAN-OS firewalls and Panorama management systems for comprehensive network security automation. This integration enables you to manage firewall address objects, create custom URL categories for domain blocking, configure security policies, and control network traffic directly from your workflows.

Palo Alto Networks provides industry-leading next-generation firewalls with advanced threat prevention capabilities. The NINA integration provides a streamlined way to automate firewall configuration and security policy management in your security operations workflows.

Status

Currently, our integration supports core firewall management operations through the PAN-OS REST API (v11.0+):

Supported Resources

• Address Objects: Create and manage IP addresses, subnets, IP ranges, and FQDN (domain) objects for security policies
• URL Categories: Create and manage custom URL categories with domain lists for web filtering and blocking
• Security Policies: Create and manage security policy rules to deny, drop, or reset traffic based on source IP, User-ID, zones, applications, and services
• System Configuration: Commit pending configuration changes to activate them on the firewall

Key Capabilities

• Multi-Format Address Objects: Support for IP/Netmask (CIDR), IP Range, and FQDN object types
• Flexible Policy Management: Create deny, drop, reset-client, reset-server, or reset-both actions
• User-ID Integration: Block traffic based on Active Directory users and groups
• Zone-Based Security: Configure policies for traffic between security zones
• Application Control: Apply policies to specific applications regardless of port
• Tagging and Organization: Tag objects for categorization and policy management
• Virtual System Support: Manage objects and policies in shared context or specific virtual systems
• Configuration Commit: Atomic commit operations to activate pending changes

Important Notes

• PAN-OS Version: This integration requires PAN-OS 11.0 or later with REST API support
• API Access: The REST API must be enabled on your firewall or Panorama
• Commit Required: All configuration changes (address objects, URL categories, security policies) must be committed to take effect
• Virtual Systems: Firewalls can use virtual systems (vsys) for multi-tenancy; most objects can be created in "shared" or specific vsys contexts

Not Currently Supported

Our integration does not yet support several advanced PAN-OS features:

• NAT Policies: Network address translation rules
• Application Override Policies: Port-based application identification overrides
• Decryption Policies: SSL/TLS inspection and decryption rules
• DoS Protection Policies: Denial-of-service protection profiles
• QoS Policies: Quality of service and bandwidth management
• Zone Protection: Zone-level protection profiles
• Threat Prevention: Antivirus, anti-spyware, vulnerability protection, file blocking, and wildfire profiles
• Dynamic Address Groups: Address groups with dynamic membership based on tags
• GlobalProtect: VPN gateway and portal configuration
• Device Groups (Panorama): Management of device groups and templates in Panorama
• Logs and Reports: Log querying, traffic analysis, and threat reports
• High Availability: HA pair configuration and management

For comprehensive information about PAN-OS capabilities, refer to the official documentation at https://docs.paloaltonetworks.com/

Credential Configuration

Before using the Palo Alto Networks integration in your workflows, you need to configure API key authentication credentials.

Authentication Method

The Palo Alto Networks integration uses API Key authentication:

Field	Description	Example
API Key	PAN-OS API Key	LUFRPT14MW5xOEo1R09KVlBZNnpnem... (truncated)
Base URL	Firewall or Panorama URL	https://firewall.example.com or https://10.10.10.10

Generating an API Key

There are two methods to generate a PAN-OS API key:

Method 1: Using the Web UI (PAN-OS 9.0+)

1. Log in to your PAN-OS firewall or Panorama web interface
2. Navigate to the top-right corner and click your username
3. Select API Keys from the dropdown menu
4. Click Generate API Key
5. The API key will be displayed - copy and save it securely
6. Note: API keys inherit the permissions of the user account that generated them

Method 2: Using the XML API

If you prefer to generate the API key programmatically:

1. Make a GET request to the keygen endpoint:

curl -k 'https://firewall.example.com/api/?type=keygen&user=admin&password=yourpassword'

2. The response will contain your API key:

<response status="success">
  <result>
    <key>LUFRPT14MW5xOEo1R09KVlBZNnpnem...</key>
  </result>
</response>

3. Extract the key value between the <key> tags

Important Security Notes:

• API keys have the same permissions as the user account that generated them
• Use dedicated service accounts with minimum required permissions
• API keys do not expire but can be revoked by deleting and regenerating them
• Store API keys securely and never commit them to version control

Required Permissions

The user account used to generate the API key should have the following minimum permissions:

• For Address Objects and URL Categories: XML API Read/Write access to Objects
• For Security Policies: XML API Read/Write access to Policies
• For Commit Operations: Commit access on the firewall/Panorama

For production use, create a dedicated service account with role-based access control:

1. Navigate to Device > Administrators
2. Click Add to create a new administrator
3. Assign an appropriate admin role (Superuser, Superuser (read-only), Device administrator, etc.)
4. For custom roles: Go to Device > Admin Roles and configure specific permissions

Creating a Palo Alto Networks Credential in NINA

1. Navigate to the Credentials section in NINA
2. Click Add New Credential
3. Fill in the credential details:
   • Name: A descriptive name (e.g., "Palo Alto Production Firewall")
   • Description: Optional details about the credential's purpose
   • Integration Service: Select "Palo Alto Networks"
   • Auth Type: "API Key" (only option available)
   • API Key: Paste your PAN-OS API key
   • Base URL: Enter your firewall or Panorama URL (e.g., https://firewall.example.com or https://10.10.10.10)
4. Click Test Connection to verify credentials
5. Click Save to store the credential

Base URL Configuration

The Base URL should point to your PAN-OS device:

• Firewall: Direct URL or IP address of your firewall (e.g., https://fw1.company.com)
• Panorama: URL of your Panorama management server (e.g., https://panorama.company.com)
• Management Interface: Ensure the URL points to the management interface, not a data interface

Format Requirements:

• Must include https:// protocol (HTTP is automatically upgraded to HTTPS)
• Port can be specified if using non-standard ports (e.g., https://firewall.example.com:8443)
• No trailing slash

Supported Resources and Operations

The Palo Alto Networks integration supports the following resources and operations:

Address Objects

Manage IP addresses, subnets, ranges, and FQDN objects for use in security policies and rules.

Operation	Description
Create	Create a new address object (IP/netmask, IP range, or FQDN)
List	Retrieve all address objects
Get	Get details of a specific address object
Update	Update an existing address object (modify value, description, tags)
Delete	Delete an address object

Address Object Types:

• ip-netmask: Single IP address or subnet in CIDR notation (e.g., 192.168.1.1/32, 10.0.0.0/8)
• ip-range: Range of IP addresses (e.g., 192.168.1.1-192.168.1.100)
• fqdn: Fully qualified domain name (e.g., malicious-domain.com, *.example.com)

URL Categories

Manage custom URL categories for domain-based web filtering and blocking.

Operation	Description
Create	Create a custom URL category with a list of domains
List	Retrieve all custom URL categories
Get	Get details of a specific custom URL category
Update	Update the domains in a custom URL category (replaces entire list)
Delete	Delete a custom URL category

URL Category Features:

• Support for wildcard domains (e.g., *.example.com matches all subdomains)
• Domain lists can include URLs and URL patterns
• Custom categories can be used in security policies and URL filtering profiles

Security Policies

Manage security policy rules to control traffic flow based on multiple criteria.

Operation	Description
Create	Create a security policy rule to deny or control traffic
List	Retrieve all security policy rules
Get	Get details of a specific security policy rule
Update	Update an existing security policy rule
Delete	Delete a security policy rule

Policy Actions:

• deny: Silent drop of packets without sending TCP reset or ICMP unreachable
• drop: Drop packets and send ICMP unreachable (for IP) or TCP reset (for TCP)
• reset-client: Send TCP reset to client side
• reset-server: Send TCP reset to server side
• reset-both: Send TCP reset to both client and server

Policy Criteria:

• Source addresses and users (IP addresses, address objects, User-ID)
• Destination addresses (IP addresses, address objects)
• Source and destination zones
• Applications (any, or specific applications like web-browsing, ssh, etc.)
• Services (ports and protocols, or service objects)

System Configuration

System-level operations for managing firewall configuration state.

Operation	Description
Commit	Commit all pending configuration changes to activate them

Commit Operations:

• Validates all pending configuration changes
• Activates changes atomically (all or nothing)
• Optional commit description for audit trail
• Required after creating, updating, or deleting objects and policies

Parameter Merging

The Palo Alto Networks integration takes advantage of NINA's parameter merging capabilities:

Parameter Sources (in order of precedence)

1. Node Parameters: Parameters configured directly in the Palo Alto Integration Node
2. Extracted Parameters: Parameters automatically extracted from the input data
3. Input Data: The complete input data from upstream nodes

When a Palo Alto Integration Node executes:

• It combines parameters from all sources
• Node parameters take precedence over extracted parameters
• The combined parameters are used to execute the Palo Alto operation

Example: Managing Address Objects

Creating an IP Address Object

Block a malicious IP address by creating an address object:

Node Configuration:

{
  "resource": "addressObjects",
  "operation": "create",
  "parameters": {
    "name": "Malicious_IP_203.0.113.42",
    "type": "ip-netmask",
    "value": "203.0.113.42/32",
    "description": "Malicious IP identified in phishing campaign - 2024-01-15",
    "tags": ["Blocked", "Phishing", "Threat-Intel"],
    "location": "shared"
  }
}

This creates an address object that can be referenced in security policies to block this IP address.

Creating a Domain (FQDN) Object

Block a malicious domain:

Node Configuration:

{
  "resource": "addressObjects",
  "operation": "create",
  "parameters": {
    "name": "Malicious_Domain_Evil_Site",
    "type": "fqdn",
    "value": "malicious-domain.evil",
    "description": "C2 server domain for APT29 campaign",
    "tags": ["Blocked", "C2", "APT29"],
    "location": "shared"
  }
}

Creating an IP Range Object

Block an entire range of malicious IP addresses:

Node Configuration:

{
  "resource": "addressObjects",
  "operation": "create",
  "parameters": {
    "name": "Suspicious_IP_Range",
    "type": "ip-range",
    "value": "198.51.100.1-198.51.100.50",
    "description": "Hosting provider subnet associated with malicious activity",
    "tags": ["Blocked", "Hosting"],
    "location": "shared"
  }
}

Listing Address Objects

Retrieve all address objects from the shared context:

Node Configuration:

{
  "resource": "addressObjects",
  "operation": "list",
  "parameters": {
    "location": "shared"
  }
}

Updating an Address Object

Update an existing address object with new information:

Node Configuration:

{
  "resource": "addressObjects",
  "operation": "update",
  "parameters": {
    "name": "Malicious_IP_203.0.113.42",
    "type": "ip-netmask",
    "value": "203.0.113.42/32",
    "description": "Updated: Confirmed active C2 server - block immediately",
    "tags": ["Blocked", "Phishing", "Threat-Intel", "Active-C2"],
    "location": "shared"
  }
}

Deleting an Address Object

Remove an address object when no longer needed:

Node Configuration:

{
  "resource": "addressObjects",
  "operation": "delete",
  "parameters": {
    "name": "Malicious_IP_203.0.113.42",
    "location": "shared"
  }
}

Example: Managing URL Categories

Creating a Custom URL Category

Create a custom URL category for blocking malicious domains:

Node Configuration:

{
  "resource": "urlCategories",
  "operation": "create",
  "parameters": {
    "name": "Malware_Distribution_Sites",
    "domains": [
      "malicious-domain1.com",
      "evil-site.net",
      "*.phishing-domain.org",
      "c2-server.xyz"
    ],
    "description": "Domains identified as malware distribution sites from threat intel feeds",
    "location": "shared"
  }
}

Creating URL Category from Threat Feed

Dynamically create URL categories based on upstream threat intelligence:

Input Data from Previous Node:

{
  "threat_feed": {
    "category": "ransomware",
    "domains": [
      "ransom-payment-portal.onion.ly",
      "lockbit-leak-site.com",
      "blackcat-data-dump.net"
    ],
    "confidence": "high",
    "source": "FBI Flash Alert"
  }
}

Node Configuration:

{
  "resource": "urlCategories",
  "operation": "create",
  "parameters": {
    "name": "Ransomware_{{threat_feed.category}}_Domains",
    "domains": "{{threat_feed.domains}}",
    "description": "Ransomware domains from {{threat_feed.source}} - Confidence: {{threat_feed.confidence}}",
    "location": "shared"
  }
}

Updating a URL Category

Add more domains to an existing URL category:

Node Configuration:

{
  "resource": "urlCategories",
  "operation": "update",
  "parameters": {
    "name": "Malware_Distribution_Sites",
    "domains": [
      "malicious-domain1.com",
      "evil-site.net",
      "*.phishing-domain.org",
      "c2-server.xyz",
      "new-threat-domain1.com",
      "new-threat-domain2.net"
    ],
    "description": "Updated with new threat intelligence - 2024-01-15",
    "location": "shared"
  }
}

Note: The update operation replaces the entire domain list, so include all existing domains plus new ones.

Example: Managing Security Policies

Creating a Security Policy to Block an IP Address

Create a security policy rule to deny traffic from a specific IP:

Node Configuration:

{
  "resource": "securityPolicies",
  "operation": "create",
  "parameters": {
    "name": "Block_Malicious_IP_203_0_113_42",
    "action": "deny",
    "sourceAddresses": ["Malicious_IP_203.0.113.42"],
    "destinationAddresses": ["any"],
    "fromZones": ["any"],
    "toZones": ["any"],
    "applications": ["any"],
    "services": ["any"],
    "description": "Block all traffic from confirmed malicious IP",
    "logStart": true,
    "logEnd": true,
    "location": "vsys",
    "vsys": "vsys1"
  }
}

Creating a Security Policy to Block by User-ID

Block network access for a compromised user account:

Node Configuration:

{
  "resource": "securityPolicies",
  "operation": "create",
  "parameters": {
    "name": "Block_Compromised_User",
    "action": "drop",
    "sourceUsers": ["DOMAIN\\compromised.user"],
    "sourceAddresses": ["any"],
    "destinationAddresses": ["any"],
    "fromZones": ["trust"],
    "toZones": ["untrust"],
    "applications": ["any"],
    "services": ["any"],
    "description": "Emergency block for compromised user account - Incident #2024-001",
    "logStart": true,
    "logEnd": true,
    "location": "vsys",
    "vsys": "vsys1"
  }
}

Creating a Security Policy to Isolate a Device

Isolate a potentially compromised device by blocking all outbound traffic:

Node Configuration:

{
  "resource": "securityPolicies",
  "operation": "create",
  "parameters": {
    "name": "Isolate_Device_10_10_50_100",
    "action": "reset-both",
    "sourceAddresses": ["10.10.50.100/32"],
    "destinationAddresses": ["any"],
    "fromZones": ["trust"],
    "toZones": ["any"],
    "applications": ["any"],
    "services": ["any"],
    "description": "Device isolation - suspected ransomware infection",
    "logStart": true,
    "logEnd": true,
    "location": "vsys",
    "vsys": "vsys1"
  }
}

Creating a Zone-Based Security Policy

Block traffic between specific security zones:

Node Configuration:

{
  "resource": "securityPolicies",
  "operation": "create",
  "parameters": {
    "name": "Block_Guest_to_Internal",
    "action": "deny",
    "sourceAddresses": ["any"],
    "destinationAddresses": ["any"],
    "fromZones": ["guest"],
    "toZones": ["trust", "dmz"],
    "applications": ["any"],
    "services": ["any"],
    "description": "Prevent guest network access to internal zones",
    "logStart": true,
    "logEnd": true,
    "location": "vsys",
    "vsys": "vsys1"
  }
}

Updating a Security Policy

Modify an existing security policy to add more blocked addresses:

Node Configuration:

{
  "resource": "securityPolicies",
  "operation": "update",
  "parameters": {
    "name": "Block_Malicious_IP_203_0_113_42",
    "action": "deny",
    "sourceAddresses": [
      "Malicious_IP_203.0.113.42",
      "Malicious_IP_203.0.113.43",
      "Suspicious_IP_Range"
    ],
    "destinationAddresses": ["any"],
    "fromZones": ["any"],
    "toZones": ["any"],
    "applications": ["any"],
    "services": ["any"],
    "description": "Updated: Block expanded list of malicious IPs",
    "logStart": true,
    "logEnd": true,
    "location": "vsys",
    "vsys": "vsys1"
  }
}

Example: Configuration Commit

Committing Configuration Changes

After creating, updating, or deleting address objects, URL categories, or security policies, you must commit the changes:

Node Configuration:

{
  "resource": "system",
  "operation": "commit",
  "parameters": {
    "description": "Emergency block for IOCs from Incident #2024-001"
  }
}

Important Notes:

• All configuration changes are pending until committed
• Commit validates all changes before applying them
• If validation fails, no changes are applied (atomic operation)
• Include a descriptive commit message for audit trail
• Commits may take 30-60 seconds to complete on busy firewalls

Integration in Workflow Context

The Palo Alto Networks integration is particularly powerful when combined with other nodes in a workflow for automated threat response:

Common Workflow Patterns:

1. Automated IOC Blocking:

   • Threat Intel Feed → Script Node (extract IOCs) → Palo Alto Node (create address objects) → Palo Alto Node (create security policy) → Palo Alto Node (commit) → Slack Node (notify)

2. Incident Response - Device Isolation:

   • SIEM Alert → Script Node (extract device IP) → Palo Alto Node (create address object) → Palo Alto Node (create isolation policy) → Palo Alto Node (commit) → Ticket Creation Node

3. Phishing Response - Domain Blocking:

   • Email Analysis Node → Script Node (extract domains) → Palo Alto Node (create URL category) → Palo Alto Node (commit) → Email Node (notify security team)

4. Malware C2 Blocking:

   • Sandbox Analysis Node → Script Node (extract C2 IPs/domains) → Palo Alto Node (create address objects) → Palo Alto Node (create security policy) → Palo Alto Node (commit) → Dashboard Update Node

5. Compromised Account Response:

   • Identity Provider Alert → Script Node (format User-ID) → Palo Alto Node (create user block policy) → Palo Alto Node (commit) → Identity Provider Node (disable account) → Notification Node

6. Bulk IOC Import:

   • Schedule Node → File Node (read IOC CSV) → Script Node (parse and batch IOCs) → Loop Node → Palo Alto Node (create address objects) → End Loop → Palo Alto Node (commit)

Working with Virtual Systems

Palo Alto firewalls support virtual systems (vsys) for multi-tenancy and logical separation:

Shared vs. Virtual System Context

• Shared (location: "shared"): Objects are available to all virtual systems
• Virtual System (location: "vsys"): Objects are specific to a virtual system

Creating Objects in Specific Virtual Systems

Node Configuration:

{
  "resource": "addressObjects",
  "operation": "create",
  "parameters": {
    "name": "Department_Server",
    "type": "ip-netmask",
    "value": "10.20.30.40/32",
    "description": "Department-specific server",
    "location": "vsys",
    "vsys": "vsys2"
  }
}

Default Virtual System

If not specified, operations use the default virtual system:

• Address Objects and URL Categories: location: "shared" (available to all vsys)
• Security Policies: location: "vsys", vsys: "vsys1" (most common default)

Response Structure Examples

Address Object Creation Response

{
  "@status": "success",
  "@code": "20",
  "result": {
    "@count": "1",
    "@total-count": "1",
    "entry": {
      "@name": "Malicious_IP_203.0.113.42",
      "@location": "shared",
      "ip-netmask": "203.0.113.42/32",
      "description": "Malicious IP identified in phishing campaign",
      "tag": {
        "member": ["Blocked", "Phishing", "Threat-Intel"]
      }
    }
  }
}

Security Policy Creation Response

{
  "@status": "success",
  "@code": "20",
  "result": {
    "@count": "1",
    "@total-count": "1",
    "entry": {
      "@name": "Block_Malicious_IP_203_0_113_42",
      "@location": "vsys",
      "@vsys": "vsys1",
      "from": {
        "member": ["any"]
      },
      "to": {
        "member": ["any"]
      },
      "source": {
        "member": ["Malicious_IP_203.0.113.42"]
      },
      "destination": {
        "member": ["any"]
      },
      "action": "deny",
      "log-start": "yes",
      "log-end": "yes"
    }
  }
}

Commit Configuration Response

{
  "@status": "success",
  "@code": "19",
  "result": {
    "msg": {
      "line": "Configuration committed successfully"
    },
    "job": "1234"
  }
}

Note: Commit operations return a job ID. Large commits may take time to complete. Check firewall logs for commit status if needed.

Best Practices

1. Use Descriptive Names: Name address objects and policies clearly (e.g., Malicious_IP_203_0_113_42 instead of Block_Rule_1)

2. Tag Everything: Use consistent tags for categorization and easier management (e.g., Blocked, Threat-Intel, Phishing, APT29)

3. Document Sources: Include threat intelligence source and date in descriptions for audit trail

4. Test Before Production: Test policy changes in a lab environment before deploying to production firewalls

5. Use Shared Objects: Create address objects and URL categories in shared context when they need to be used across multiple virtual systems

6. Commit Strategically: Batch multiple changes and commit once to reduce configuration churn and improve performance

7. Include Commit Descriptions: Always include descriptive commit messages for audit trail and troubleshooting

8. Handle Errors Gracefully: Implement error handling for API failures, commit failures, and validation errors

9. Monitor Commit Jobs: For large commits, implement job status monitoring to ensure changes are applied

10. Maintain Object Lifecycle: Regularly review and clean up unused address objects, URL categories, and policies

11. Use Service Accounts: Create dedicated API service accounts with minimum required permissions

12. Secure API Keys: Store API keys securely in NINA credentials, never in workflow configuration or code

13. Plan Policy Order: Security policies are evaluated top-to-bottom; plan rule ordering carefully for performance

14. Leverage Templates (Panorama): If using Panorama, use templates and device groups for consistent configuration across firewalls

15. Log Everything: Enable logging on security policies for incident investigation and compliance

Troubleshooting

Issue	Resolution
Authentication failed	Verify API key is valid and hasn't been regenerated. Check that the base URL is correct and accessible.
Permission denied	Ensure the user account that generated the API key has necessary permissions (XML API access, Objects/Policies read/write, Commit).
Object already exists	Check if an object with the same name already exists. Use the update operation instead, or delete the existing object first.
Commit failed	Check the firewall logs for validation errors. Common issues: referenced objects don't exist, invalid configuration syntax, or conflicting rules.
Connection timeout	Verify network connectivity to the firewall. Check if the management interface is accessible and the REST API is enabled.
Invalid object name	Object names cannot contain spaces or special characters. Use underscores or hyphens instead.
Referenced object not found	Ensure address objects are created before referencing them in security policies.
Changes not taking effect	Configuration changes require a commit operation to activate. Always commit after making changes.
REST API not available	Ensure you're running PAN-OS 11.0 or later. Enable the REST API in Device > Setup > Management.
Virtual system not found	Verify the vsys name is correct (usually vsys1 by default). Check Device > Virtual Systems for available vsys.

Common Error Messages

Error Message	Meaning	Solution
"API returned non-success status"	The API request was processed but failed validation	Check the error details in the response for specific validation issues
"authentication failed: invalid API key"	The API key is incorrect or has been regenerated	Generate a new API key and update credentials
"failed to connect to PaloAlto API"	Network connectivity issue	Verify base URL, firewall accessibility, and network connectivity
"Object already exists"	An object with the same name already exists	Use a different name or update the existing object
"Invalid reference to object"	Security policy references a non-existent object	Create the referenced address object before creating the policy
"Configuration validation failed"	Commit failed due to invalid configuration	Review commit error details and fix validation issues

Checking Commit Status

If a commit operation times out or you need to verify it completed:

1. Log in to the PAN-OS web interface
2. Navigate to Monitor > Logs > System
3. Filter for "Configuration committed successfully" or look for commit job completion
4. Check Device > Setup > Operations > Show Jobs for commit job status

Advanced Configuration

IP Address Formats

The integration supports various IP address formats:

• Single IP: 192.168.1.100/32 (use /32 netmask for single IPs)
• Subnet: 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16
• IP Range: 192.168.1.1-192.168.1.100
• FQDN: example.com, *.example.com (wildcard subdomain)

Domain Patterns

URL categories support various domain patterns:

• Exact Domain: example.com (matches only example.com)
• Wildcard Subdomain: *.example.com (matches all subdomains)
• URL Patterns: example.com/malware/* (matches URL paths)

Security Policy Actions

Choose the appropriate action based on your security requirements:

• deny: Silent drop (no response to client) - good for known malicious traffic
• drop: Drop with ICMP/TCP notification - better for troubleshooting
• reset-client: Reset only client connection
• reset-server: Reset only server connection
• reset-both: Reset both sides (most aggressive)

Logging Configuration

Enable appropriate logging for security policies:

• logStart: Log when session starts (useful for denied traffic)
• logEnd: Log when session ends (useful for allowed traffic to track volume)
• For blocked traffic: Enable both for complete audit trail
• For performance: Enable only logStart for denied traffic

PAN-OS Version Compatibility

This integration uses the PAN-OS REST API v11.0 and requires:

• PAN-OS 11.0 or later on your firewall or Panorama
• REST API enabled in Device > Setup > Management > Management Interface Settings
• HTTPS management access configured on the management interface

To check your PAN-OS version:

1. Log in to the web interface
2. Look at the bottom-left corner for version information
3. Or navigate to Device > Software

Additional Resources

• PAN-OS REST API Documentation: https://docs.paloaltonetworks.com/pan-os/11-0/pan-os-panorama-api
• PAN-OS Administrator's Guide: https://docs.paloaltonetworks.com/pan-os
• Security Policy Best Practices: https://docs.paloaltonetworks.com/best-practices
• PAN-OS CLI Reference: https://docs.paloaltonetworks.com/pan-os/11-0/pan-os-cli-reference

Support

If you encounter issues with the Palo Alto Networks integration, please contact our support team with:

• The operation you were attempting
• Your PAN-OS version
• Any error messages received
• The parameters you were using
• Whether the REST API is enabled on your firewall
• The workflow context where the issue occurred

This information will help us provide faster and more accurate assistance.

Updated: 2026-01-28