Palo Alto Networks Panorama Integration - Policy Group Derived Dynamic Address Groups (DAG)

Dynamic Address Groups (DAGs) are essential for Palo Alto Networks policy management, allowing firewall rules to dynamically adapt to changes in network conditions. Elisity's integration now supports Panorama, providing centralized management of DAGs across multiple Palo Alto Networks firewalls.

Key Benefits of Panorama Integration

• Centralized Security Management: Instead of configuring individual firewalls, Panorama acts as a single control plane, ensuring consistency.
• Automated Security Updates: DAGs dynamically update based on Policy Groups (PGs) defined in the Elisity platform.
• Scalability & Efficiency: Synchronization to all firewalls from Panorama eliminates manual configuration effort.
• High Availability Support: Support for Panorama HA mode with automatic switchover for DAG syncronization.

Integration Workflow

1. Policy Groups in Elisity: Devices, users, and endpoints are assigned to PGs based on identity and behavior.
2. Mapping to DAGs: PGs are converted into DAGs and published to Panorama.
3. Panorama Polling for Device Groups: Instead of pushing DAGs directly to a predefined Device Group, Elisity queries Panorama for all Device Groups under 'Shared'.
4. DAG Synchronization: Retrieved Device Groups are updated with DAG entries to ensure all managed firewalls receive the correct data.
5. Commit Behavior Control: Administrators can now choose whether to commit DAGs directly to Panorama or to both Panorama and managed firewalls. This setting gives customers control over DAG propagation timing, supporting workflows such as change control windows.
6. Tag Distribution: DAGs require IP-TAG redistribution for their values to be recognized and applied on managed firewalls.
7. Firewall Policy Enforcement: DAGs in Panorama are referenced in security policies for automated enforcement.

Prerequisites

Before proceeding, ensure the following prerequisites are handled:

• Panorama Configuration
  • Enable DAGs within Panorama.
  • Ensure Panorama is configured to manage the intended firewalls.
  • Configure User-ID Redistribution to allow tag propagation to firewalls.
  • For security rule visibility Elisity requires creating a common username in Panorama (matching the username used to onboard the Panorama VEN) to be pushed to the different firewalls.
  • Firewalls with separate API keys / usernames than the one used to manage Panorama are not supported.
• Firewall Configuration
  

  • DAGs will not show any entries under Objects -> Address Groups until they are referenced in a Security Policy.

  • Verify IP-Tag Redistribution settings to enable DAG updates.

• API Access & Credentials
  • Dedicated Panorama admin user with API permissions.
  • Generate an API key for Elisity integration.
  • For security rule visibility Elisity requires creating a common username/password in Panorama's device groups (matching the username used to onboard the Panorama VEN) to be pushed to the firewalls.

https://<FIREWALL_IP>/api/?type=keygen&user=<USERNAME>&password=<PASSWORD>

example:
https://192.168.1.1/api/?type=keygen&user=veusername&password=vepassword

 <response status="success">
     <result>
       <key>
         LUFRPT1LSXduVStJanRobnU5eVl2K3c1TFNhZEFZSUE9aFVmWTRZRXBiMUxlMmpiRGxrb1BxT2VGcTY5aGxYOS8rWnZDMlVLMVArRFpMTERuRnlKYlI4eU4zUElheDRLVw==
       </key>
     </result>
 </response>

Connectivity Requirements

Onboarding Panorama in Cloud Control Center (CCC)

Step 1: Create a Firewall Integration VE Group

Navigate to Virtual Edges and create a VE group dedicated for Panorama integration.

See our Virtual Edge Groups and Virtual Edge Deployment articles for steps on how create VE Groups and Virtual Edges. 

Step 2: Deploy Panorama as a Virtual Edge Node

Navigate to Virtual Edges and create a VE Group dedicated for Panorama integration.

Refer to the Virtual Edge Groups and Virtual Edge Deployment articles for help creating VE Groups and Virtual Edges.

1. Launch the Virtual Edge Node Wizard

Add a Virtual Edge Node to a previously created Virtual Edge Group using the wizard. Launch the wizard by clicking on + Add Virtual Edge Node in Virtual Edges > Virtual Edge Nodes.

Select a dedicated Virtual Edge Group for Palo Alto Networks.

2. Choose the Virtual Edge Node Type

In the Virtual Edge Node Type selection, choose Security Platform. 

Select Palo Alto Networks as the Security Platform Type, and select Panorama as the Deployment Type.

3. Enter Integration Details

Fill out the required fields to configure communication between the Virtual Edge Node and Panorama:

• Firewall IP Address: Management IP of Panorama or both primary/secondary IPs if using HA.

• Username: Admin account with superuser permissions and API access.

• API Key: Paste the API key generated with the credentials above.

• Description (optional): Add a description to help identify the Virtual Edge Node.

Tip: Generate an API key using the following URL (replacing placeholders as needed):

https://<FIREWALL_IP>/api/?type=keygen&user=<USERNAME>&password=<PASSWORD>

Replace <FIREWALL_IP>, <USERNAME>, and <PASSWORD> with the appropriate values.

You will be redirected to a web page with the API Key, where you can copy and paste as seen here:

Note: The Prerequisites section covers account permissions and User-ID redistribution required for DAG synchronization and rule visibility.

4. (Optional) Enable High Availability Mode

If deploying in Panorama HA mode, toggle High Availability and provide both primary and secondary Panorama IP addresses.

5. Configure Advanced Options

Before continuing, review the advanced options available in this step:

• Palo Alto Commit Behavior: Choose to commit DAG changes to Panorama only, or commit and push directly to firewalls. This setting gives customers additional control over DAG propagation timing, supporting workflows such as change control windows.

• Palo Alto DAG Rule Visibility: Optionally enable visibility into local (non-Panorama-managed) firewall rules.

These settings can also be modified later by editing the Virtual Edge Node.

6. Finalize Configuration

Review your settings in the summary view and click Finish to deploy the Virtual Edge Node.

7. Deployment Confirmation

You’ll receive a confirmation once the Virtual Edge Node has been successfully added.

8. Post-Onboarding View

After deployment, verify the Virtual Edge Node status in the Virtual Edge Node Details panel. If HA is enabled, the currently active Panorama instance will be marked with a green indicator.

Assigning Policy Groups as DAGs in Cloud Control Center

Elisity's integration with Panorama polls Panorama for Device Groups and allows Administrators in Cloud Control Center to selectively distribute Policy Groups to Device Groups in Panorama. Each Device Group in Panorama can have indepedent collections of Policy Group mappings, enabling flexible and precise control of how DAGs are populated. The process is as follows:

Elisity Polls Panorama for Device Groups

• CCC retrieves all Device Groups under All from Panorama.
• These device groups are populated in Cloud Control Center in the details view of the Panorama VEN.

Nested (Hierarchical) Device Groups

Panorama supports hierarchical Device Group structures, with Device Groups nested beneath the top-level Shared Device Group. Panorama allows up to five levels of nesting (counting Shared as the first level), and in production environments it is common to see four or five levels in use, with the physical firewalls assigned to the lowest-level (leaf) Device Groups.

When Elisity polls Panorama, it retrieves every Device Group across all hierarchy levels and lists them in Cloud Control Center. The example below, taken from a production Panorama, shows a Device Group tree nested up to five levels deep.

How nested Device Groups appear in Cloud Control Center

Cloud Control Center retrieves and supports the complete set of Device Groups from Panorama, including those nested at every level of the hierarchy. Note, however, that CCC lists Device Groups in alphabetical order rather than in Panorama's parent-child tree order, so the nesting relationships are not represented visually in the Device Group list. When deciding where to assign Policy Groups, refer to your Panorama configuration to confirm which Device Groups are parents and which are children.

How DAG inheritance affects distribution

Panorama automatically propagates a Dynamic Address Group (DAG) applied to a parent Device Group down to every child Device Group beneath it. This is native Panorama behavior and is not controlled by Elisity. An inherited DAG reports the parent Device Group in its Location column, indicating it was not configured directly on the child.

Recommended distribution methods for nested Device Groups

To distribute Policy Groups cleanly in a nested hierarchy, choose one of the following approaches so that CCC's per-Device-Group assignments match what Panorama enforces:

• Assign to the leaf Device Groups only (recommended). Assign the Policy Group only to the lowest-level Device Groups that actually contain the firewalls (for example, the two Test Device Groups in the first screenshot). Because nothing is applied to a parent, there is no inheritance for the consistency check to misinterpret, and the DAG stays scoped to the Device Groups that own the firewalls.
• Assign to every Device Group in the branch. Assign the Policy Group to the parent and all of its child Device Groups in CCC. The consistency check then expects the DAG everywhere it appears and leaves the inherited copies in place.
• Assign at the Shared Device Group. Applying the Policy Group at Shared makes the DAG global, so every Device Group already has it and there is nothing for the consistency check to remove. Use this only when the broadest scope is acceptable.

When reviewing Device Groups in CCC, refer to your Panorama configuration to understand the parent-child relationships before deciding where to assign Policy Groups. As noted above, CCC lists Device Groups alphabetically rather than in Panorama's hierarchy order, so the parent-child structure is not shown in the selector itself.

Add Policy Groups to be mapped to DAGs

• By default, no Policy Groups are sent. You must select which PGs you want to publish as DAGs within each Device Group by selecting the group on the left hand side and clicking Add or Edit Policy Groups in the additonal options menu.

The Device Group Mapping menu allows you to specify which Policy Groups will be mapped as Dynamic Address Groups for each Device Group in Panorama.

The interface will display the total number of IP addresses being pushed for each Policy Group mapping. After assigning Policy Groups to Device Groups in Panorama, the total number of mapped PGs will appear next to each Device Group (1).

Click Save Changes to confirm. You can then check the Dynamic Address Groups in Panorama for each Device Group and see the Elisity-programmed DAG has been populated. 

The naming for each DAG pushed from Cloud Control Center is standardized as:
Elisity_<PG_ID>_policy_group_name

Commit Configuration to Panorama

1. Choose Commit to Panorama and Devices (Recommended Default).
2. Monitor commit status logs in CCC to confirm success.
3. Verify that DAGs appear under Objects > Address Groups in Panorama.

Final Configurations and Validation in Panorama

Configure User-ID Redistribution for DAG Tag Distribution

1. Log in to Panorama and navigate to User-ID Redistribution Settings. Enable Redistribute User Mappings to managed firewalls by going to the Management Interface Settings and checking the User-ID box in the Network Services section. Panorama acts as a User-ID Redistribution Point, forwarding DAG tags to managed firewalls.
   
   
   
   
2. Ensure that firewalls are configured to receive IP TAG mappings from Panorama by navigating to the Data Redistribution settings and ensuring that the IP Tags check box is selected for each relevant Firewall.
   
   
   
3. Verify DAG tags appear on managed firewalls.

Managing Changes to Policy Group Derived Dynamic Address Groups

Adding New PGs

• Automatically pushed to Panorama when added in Elisity.
• Commit required in Panorama to apply.

Removing PGs

• If PG is still referenced in policies, it will not be deleted from Panorama.
• Administrators will receive a warning before deletion.

Renaming Policy Groups

When a Policy Group that is mapped to a Dynamic Address Group is renamed in Cloud Control Center, the corresponding DAG on Panorama or the firewall is renamed in place. This preserves any existing security rules that reference the DAG, eliminating the need for manual reconfiguration in Panorama after a rename.

• The rename operation propagates automatically to all associated Device Groups.
• Security rules referencing the DAG continue to function without modification.
• The updated DAG name follows the standard naming convention: Elisity_<PG_ID>_policy_group_name.
• No additional commit or administrator action is required beyond the standard commit workflow.

Best Practices

• Use dedicated Virtual Edges (VEs) for Panorama to avoid exceeding API session limits.
• Ensure IP-Tag Redistribution is Enabled. Without it, DAG tags will not propagate.
• Review Resource Limits: Panorama/firewall DAG capacities should be monitored.
• Track Commit Logs: Regularly verify commit success/failure in Panorama.

Policy Group Usage Visibility in Palo Alto Security Rules

When Policy Groups are published to Palo Alto Networks firewalls as Dynamic Address Groups (DAGs), their usage within firewall security rules can be viewed directly from the associated Virtual Edge Node (VEN) in Cloud Control Center.

For direct firewall integrations, the left panel displays the Policy Groups assigned to the VEN. The security rules table lists all rules on the associated firewall that reference those DAGs. Each row includes a timestamp indicating when the rules were last retrieved. Rules no longer present on the firewall are automatically removed during the next update cycle.

In Panorama-managed environments, Policy Groups are shown grouped under their assigned Device Groups. The corresponding firewalls and their security rules are displayed per device group. Rules that reference multiple DAGs (e.g., in both source and destination fields) are displayed under each relevant Policy Group for clarity. The left panel supports expandable views per device group, and all columns in the rules table support standard filtering, global search, and list-style expansion for multi-value fields.

Firewall rules are refreshed at a configurable interval, and the most recent update time is shown in the "Last Update" column. This ensures administrators have a current view of how identity-driven segmentation policies are enforced within the firewall infrastructure.

Note: Visibility from the VEN view is currently supported. Viewing policy group usage across all firewalls from the Policy Group details page is not yet available.