Palo Alto Panorama
A Group is a named list of IP addresses and CIDRs, kept up to date automatically as matching resources change. Group Export pushes a Group to your Palo Alto firewalls (managed by Panorama) as a Dynamic Address Group (DAG) and keeps its membership in sync for you.
Connect creates and maintains the DAG and stops there. Your security rules stay exactly as they are, so the DAG starts affecting traffic once you reference it in your own policy.
Before you start
Connect creates none of the following. Have all of it in place before you provision the account:
| Prerequisite | Why it's needed | Where to check in Panorama |
|---|---|---|
| An existing device group that directly contains the firewalls that should receive the Group | The DAG is written into that device group, which you create in Panorama. A firewall belongs to exactly one device group. Name the group the firewalls sit in, not a parent of it: a push made through the API reaches only the firewalls directly in the named device group, never those in its child device groups | Panorama > Device Groups |
| At least one firewall in that device group showing Connected | The export delivers to the connected firewalls in that device group. With none connected, the job retries for a while, then fails with an error that starts No connected firewalls in the device group, and runs again when the Group next changes or the Connector restarts | Panorama > Managed Devices > Summary |
| A Panorama administrator account with XML API access to that device group | Every call the Connector makes is XML API | Panorama > Administrators, and its role under Panorama > Admin Roles |
| Outbound HTTPS from the Connector to Panorama | The Connector opens every connection to Panorama | Network Requirements |
A device group groups firewalls, not addresses. The Connect Group provides the address list; the Connector delivers it to that device group's firewalls.
If you scope the administrator account to least privilege, it must cover everything the Connector does: API key generation, operational commands (listing devices and reading registered IPs from firewalls), configuration reads and changes in the device group (listing device groups, and creating, renaming, and deleting the Dynamic Address Groups it manages), User-ID (the IP-to-tag registrations), a partial commit scoped to its own administrator account, and push to devices. A partially restricted role fails at whichever operation it reaches first.
The Connector asks Panorama for a new API key at the start of every run, so an API Key Lifetime set under Panorama > Setup > Management > Authentication Settings, which Palo Alto recommends, does not interrupt it. A key that expires during a run is renewed once.
Set up a Palo Alto account
- In Connect, go to Integrations and click New Integration Account.
- Provider: Palo Alto Networks. Give it a name and a project. The name is the label shown throughout Connect, so use something you and your team will recognize, such as the Panorama hostname.
- Click Continue to Provisioning, then on the Provision page fill in:
- Connector: the Connector you paired earlier. (Required for Palo Alto.)
- Panorama Hostname: your Panorama's IP or hostname, with a port if it isn't 443. A pasted URL works too: the scheme and any path are dropped.
- Username / Password: Panorama admin credentials. Once saved, the password opens blank; leave it blank to keep it. See Passwords and tokens are write-only.
- Device Group: an existing Panorama device group whose firewalls should receive the DAG, entered exactly as it appears under Panorama > Device Groups (case-sensitive). Connect writes the DAG into the device group you name here, and Test in the next step reports a name Panorama doesn't have.
- Under Advanced, Allow Self-Signed Certificate is on by default, because most Panorama deployments present a self-signed certificate. Turn it off if yours uses a certificate from a publicly trusted CA.
- Click Provision Account, then press Test to confirm the Connector can reach Panorama and sign in. The test also checks that the administrator role can read device groups and devices and that the Device Group exists, and reports how many of its firewalls are connected, so a mistyped name or a missing privilege fails here rather than on the first export.
Export a Group
- In Connect, go to Groups > New Group.
- Set Update to Automatic so membership stays current on its own.
- Pick the Project the Group belongs to.
- Set Export To to your Palo Alto account.
- Build your membership filters (tags, type, vendor, CIDR, account, region, and so on) and confirm the preview table shows the members you expect.
- Save. Because the Group updates automatically, the form shows a warning that saving exports all current matches to the targets above. That's expected.
Steps 2 and 3 are permanent. A Group created as Manual, or under the wrong project, has to be replaced. See Creating a Group.
The Connector picks up the export job on its next poll. Watch it under Settings > Connectors > Jobs. Group membership caps at 10,000 items; see Group size limits.
Verify it landed
An exported Group shows up in three places, each holding something different:
| What to check | Where to look | What you should see |
|---|---|---|
| The DAG definition | Panorama: Objects > Address Groups, with the Device Group selector set to your device group rather than Shared | An entry named after your Connect Group with a short unique suffix. Open it: Type Dynamic, Match the Group's firemon- tag in single quotes ('firemon-01ARZ3NDEKTSV4RRFFQ69G5FAV'), Description FireMon Connect: <your Group name> |
| The DAG delivered to the firewall | The firewall: Objects > Address Groups | The same entry. Present on Panorama but missing here means Panorama hasn't pushed it yet (see Details and edge cases) |
| The resolved members | The firewall: Objects > Address Groups, then the More... link in the group's Address column | The IP addresses registered to the group, which are the members of your Connect Group |
Check membership on the firewall. Panorama holds the DAG's definition; each firewall holds the IP-to-tag mappings that the DAG's filter matches against. Panorama's Addresses column is therefore empty even on a healthy export, which is the most common false alarm with this integration.
Use the DAG in your policy
Reference the DAG as a source or destination address in a rule under Policies > Security, then commit and push as you normally would.
How changes are handled
| Action | Result |
|---|---|
| Edit the Group's filters | Membership recalculates on save, and the tag registrations on the firewall follow immediately. |
| A resource gains/loses a matching tag | Automatic groups pick up the change on the next refresh. |
| Rename the Group | The DAG is renamed in place; existing policy references are preserved. |
| Add/remove a target under Export To | Members sync to the new target. A dropped target's DAG and its tagged IPs are left in place, the same as when the Group is deleted; remove them in Panorama if no longer needed. |
| Delete the Group | The DAG and its tagged IPs are left in place on Panorama and the firewall. Remove them manually if they're unwanted. |
| Restart the Connector | It runs a full sync on startup: a missing DAG is recreated, and tag registrations are brought back in line with each Group's current members. DAGs left behind by deleted Groups stay as they are. |
Details and edge cases
How the sync works. Each Connect Group maps to a tag (registered on each member IP) and a DAG whose match filter is that tag. Adding or removing IPs changes tag registrations on the firewall alone, which takes effect immediately. Creating, renaming, or deleting the DAG itself changes Panorama configuration and does require a commit and push, which the Connector handles for you.
A push delivers everything committed for the device group. When the Connector pushes, Panorama sends the device group's whole committed configuration to its firewalls, including a change another administrator committed on Panorama but had not yet pushed. Changes still uncommitted in another administrator's candidate configuration are not included: the Connector commits only its own.
The DAG's name is your Group's name with unsupported characters removed, spaces replaced by hyphens, truncated if long, and a short unique suffix appended, so Blocked Ranges becomes something like Blocked-Ranges-01ARZ3NDEKTS. The Connector matches the DAG by its match filter rather than its name, which is why renaming the Group renames the DAG in place and leaves policy references intact.
Each firewall caps its registered IP addresses. The cap depends on the model, from 1,000 on the smallest firewalls to 500,000 on the largest, and a range or subnet counts as one registered address. Palo Alto documents ranges and subnets for IPv4 only; single IPv6 addresses register as any other. Those caps, not Connect's own 10,000 item limit, are what limit a large Group on the firewall side. See Use Dynamic Address Groups in Policy for the table.
Two DAGs sharing one firemon- tag are reconciled on the next sync: one is kept and the extras are removed. This is the only case where Connect deletes a DAG, and only ever a DAG whose match filter is a firemon- tag. It normally means an earlier rename was interrupted part-way.
Audit trail vs. current state. The firewall's Monitor > Logs > IP-Tag log records registration and unregistration events, so a tag that was added and later removed still appears there. For the mappings in force right now, use the firewall CLI (documented commands):
show object registered-ip all
show object dynamic-address-group all
The second lists each DAG with its filter and members, marking each member's origin. Everything Connect adds is a registered IP, marked (R).
If the DAG is empty on the firewall, check whether show object registered-ip all returns anything for that tag, whether the Group's filters currently match anything (use the candidate preview under Group Candidates), and whether the push has completed.
If the DAG is on Panorama but missing from the firewall, Panorama has yet to push it. That needs one of two things: Share Unused Address and Service Objects with Devices enabled (under Panorama > Setup > Management, edit Panorama Settings; it's on by default), or an enabled policy rule referencing the DAG, followed by a commit and push to devices. The rule has to be enabled to count as a reference.
For common issues, see Troubleshooting.
Palo Alto documentation
- Policy Object: Address Groups: what a Dynamic Address Group is and how its match filter works
- Use Dynamic Address Groups in Policy: including how to verify a DAG's resolved members
- Register IP Addresses and Tags Dynamically: the User-ID mechanism the Connector uses to keep membership current
- CLI Commands for Dynamic IP Addresses and Tags
- Manage Unused Shared Objects: the setting that decides whether an unreferenced DAG is pushed to firewalls