Address Group and Tag limitations

[HeinzP]

The necessary firewall rules for each application are defined by labels.
If a workstation needs access to it, the label is requested and assigned (XML-API), so each Workstation has its own set of firewall rules. I tried implementing this requirement using different approaches, but unfortunately, everything failed due to several limitations.

• First, custom external dynamic lists (EDLs) are limited to a maximum of 30 lists.
• Assigning tags to address objects for dynamic address groups is limited to 64.
• The maximum number of members per Address Group is 2,500.

These limitations are documented, and some of them have already been discussed on this portal:

• https://www.paloaltonetworks.com/products/product-selection
• Show system state | Match cfg.general.max-address.

Why do data center firewalls (not the small boxes) have limitations like this? Have others also reached these limitations?
Does anyone have another approach to implementing the requirements?

[Brandon_Wertz]

---

@HeinzP wrote:

The necessary firewall rules for each application are defined by labels.
If a workstation needs access to it, the label is requested and assigned (XML-API), so each Workstation has its own set of firewall rules. I tried implementing this requirement using different approaches, but unfortunately, everything failed due to several limitations.

• First, custom external dynamic lists (EDLs) are limited to a maximum of 30 lists.
• Assigning tags to address objects for dynamic address groups is limited to 64.
• The maximum number of members per Address Group is 2,500.

These limitations are documented, and some of them have already been discussed on this portal:

• https://www.paloaltonetworks.com/products/product-selection
• Show system state | Match cfg.general.max-address.

Why do data center firewalls (not the small boxes) have limitations like this? Have others also reached these limitations?
Does anyone have another approach to implementing the requirements?

---

@HeinzP  -- What are you trying to do?  What are you trying to control?  

Are you trying to control a specific device from accessing a specific resource (server?)  Or are you trying to control a specific person/account from accessing a specific resource (server?)

[HeinzP]

Exactly! We are trying to enable a specific device to access particular servers. Company policy states that this should NOT be done using user accounts. In other words, one user account can be used on different devices with different firewall rules (for example, developer devices and business user devices.).

For example:
Device1 -> Application_Server_1
Device2 -> Application_Server_1 and Application_Server_2
Device3 -> Application_Server_2

We have around 3,000 devices and approximately 250 application servers, so any combination should be possible.

[kiwi]

Hi @HeinzP ,

I haven't exactly tested this, but I'm thinking something along these lines should be possible:

Since company policy forbids using human user accounts for this, could you use the User-ID XML-API to perform 'Machine-to-Group' mapping?

Instead of tagging an Address Object, use the API to register the workstation's IP as a 'user' where the username is actually the Hostname (e.g., workstation-01). You can then map that hostname to 'Groups' (representing your application labels) using the 'type=user-id' XML-API payload.

I believe, because these memberships are stored in the User-ID table (Data Plane) rather than the Configuration table, you bypass the 64-tag limit and the 2,500-member Address Group limit. An additional benefit is that these API updates happen in real-time—no 'Commit' is required to update access for a device (which is required every time a label should change for example).

This fulfills the requirement of 'per-device' rules without touching actual user accounts, and I believe it scales better for thousands of devices and combinations.

Hope this approach can be useful.

[Brandon_Wertz]

@HeinzP  -- I've done exactly this.  One way was ~12+ years ago via an "unsupported" option and now recently via a Palo supported option (which I've been doing successfully for the past ~2ish years.)

The first way was using an EDL, like you mentioned though, the box has a limit of 30 total EDLs.  So if you have more than 30 device types then an EDL won't ultimately work.

Palo Alto acquired a company about 6 years ago called "Zing Box."  This products' whole purpose was device control.  Prior to the Zing Box acquisition palo couldn't natively use the "what" in security policy, but with this acquisition they could.  This product turned into IoT Security or Device Security, which is a licensed feature of their firewall product.  If you purchase this product you can add "device type" as a field in your security policy and you'll be able to achieve exactly what you're trying to do.

[HeinzP]

The User-ID XML API is a great idea. I have run a few tests with it.
Unfortunately, I am struggling with the user-to-group mapping. In my opinion, this is only possible with an LDAP server profile.

Does the limit of 2,500 entries per group still exist when using Tag-Based Dynamic Group?

eg.
<dynamic>
<filter>'user contains "label1\\"'</filter>
</dynamic>

I will run some additional tests.

[HeinzP]

I'll try to get an evaluation license for it and give it a try.
Thanks for the tip!

[Brandon_Wertz]

---

@HeinzP wrote:

The User-ID XML API is a great idea. I have run a few tests with it.
Unfortunately, I am struggling with the user-to-group mapping. In my opinion, this is only possible with an LDAP server profile.

Does the limit of 2,500 entries per group still exist when using Tag-Based Dynamic Group?

eg.
<dynamic>
<filter>'user contains "label1\\"'</filter>
</dynamic>

I will run some additional tests.

---

IMO, if you're going to use this XML/EDL process you're going to set yourself up for support issues long term. The only real "enterprise" solution would be the DeviceID route, especially if you have a security policy driving your security architecture.