64 object limit for IP group

mMontana

Hello to everyone,

today I discovered that there's this limit of 64 entries for Address group, and it hit me in two ways.

1: the limit is present on ZLD 4.x device like USG40.
2: the limit is also present on a ZLD 5.x device, like USG Flex 50 (or as it was born… USG 20 VPN.
3: the limit is not present on a ZLD 5.x device like USG Flex 100.

64 objects is not exacly a small limitation, but it's neither that big. It's a binary number, so makes sense to a computer in some way or another.

So, the questions.

1: on ZLD 5.x this limit can be moved to a bigger number, like 128? (I'm aware that ZLD 4.x devices are no more a thing)
2: is this limit device based or software based?
3: is there any object number limit for any category? Is reported in any manual?
4: I worked around this limit using a second group and a second firewall rule and this works… however I'm questioning myself if it's more efficient, as computational power, process more rules or use more memory allocation for a bigger group…

For who's interested why I need "more than 64" IP objects into a group: I use a "cloud" tool for verify the internet availability of the devices and this "look for" https port (non standard) to understand if the security device is actually on and available.
For allowing the USG to be found and answer the request, I have to allow the IPs of the service. IP address list already has been narrowed down to subnets if possible to reduce the object number entries.

PeterUK

One way around it is to group more then one in one group

On FLEX100 to FLEX500 its Maximum Address Object In One Group is 128 and FLEX700 is 256

Zyxel_Melen

Hi @mMontana,

Thanks for

1: on ZLD 5.x this limit can be moved to a bigger number, like 128? (I'm aware that ZLD 4.x devices are no more a thing)

> Due to the segmentation of device specifications, we cannot enlarge it.

2: is this limit device based or software based?

>This is because of the segmentation of device specifications.

3: is there any object number limit for any category? Is reported in any manual?

>Which category are you looking for?

mMontana

Sorry for the late reply (please, reinstate the capability quote of messages!)

> Due to the segmentation of device specifications, we cannot enlarge it.

So this is a designed limitation?

I can understand older devices could have memory issues, but I'm referring to the Zywall 5 era, or the first generation of USG (ZLD 3.xx)… but keeping the market segment limitation designed by Zyxel in 2020-era is baffling.

IPv4 have 4 billion addresses available, but the number skyrocket on IPv6 and as 64 ip address object as a limit for a group is… really small: GeoIP database is "raw data", but I guess that any asian country can have far more than 64 ip addresses stored for the specific nation… and any country seems to me an IPv4 and IPv6 group with more thant 64 entries. But as a customer, I cannot access to the same size of group of GeoIP db.

A less capable firewall linux distro than Zyxel devices like IPfire (cannot have more than 1 WAN interface) is able to do that.
A so-old BSD firewall distro like OPNSense (roots on m0n0wall project) can to that.
And with current low-powered x64 devices they are gaining so much more attention now to deliver a more capable devices than zyxel's for customers, due to increasing "subscription pressure" that company is make feel to customers, that can rely on to soon-EoS devices because current generation is not on-par as features.

64, 128, 256 and 512 singular entries limit for ip group, due to device class… today is small.
Unless the goal is to bind to a ip blacklist subscription…

Zyxel_Melen

Hi @mMontana,

So this is a designed limitation?

This is more likely the spec.

Thanks for your input. Would you like to share the model of "current low-powered x64 devices"? I will let our product team know and evaluate for future products.

PeterUK

One way to look at this is whats the difference between two rules each with Address group of 64 vs one rule with Address group of 128 ?

mMontana

Obsolete spec.

@PeterUK two groups to update instead of one if you're using a zyshell script to update a service check; if things goes south, two security policies instead of one.
And different scripts for any "obsolete spec" device.