@Ethan-TP Hi, thank you for getting back to me.

The current envisaged scenario is 4 VLAN's (Prod/Dev/QA/UAT) with the current limit spread equally across that would equate to 4 cross border IP-Port Group rules per VLAN, I appreciate there are caveats to this with netmasks, port ranges etc, however at most basic level if we want to allow restrictive API/Web/DB Access across VLANS without reorganising the entire network we hit that limit incredibly quickly, so as to make Omada SDN not really practical.

Small network, currently consists of gateway, core switch, five access switches & three WAP's

I would hope for a limit of at least 128, however I appreciate resource are finite! I limit of 64 would be acceptable, 32 would be workable.

Where/why is this limit enforced, I assume it's at the controller level?

The only solution I see at this time is ditch the Omada Gateway (ER7412-M2) and replace it with pfsense or similar which is something we don't really want/should not have to do.

  @Ethan-TP could you expand on this response please, I am not using a single ACL in fact I cannot use any more ACL's as I have exhausted the inadequate quota of IP-Port Groups, I don't follow how your response fits the question, would be interested to know if there is a better way and I am missing something. Thank you!

  @Ethan-TP  Ah ok, I see the the confusion.
 

I believe your statement to be incorrect.
 

The maximum number of IP-Port Groups that can be created is 16. Not 16 per ACL (that would be fine!) but 16 in total across the entire environment.

You can now see why this is a serious limitation?

I would love to be wrong here, but am reasonably confident I am not.

  @Ethan-TP I think the point is still being overlooked, it's not the number of entries per group that is the concern, it's the number of groups.

My original question remains unanswered, why is this marked as resolved, surely the customer would be in a position to state that rather than the support teams.

I appreciate you have no real investment in this and probably just want to close the conversation as it's a bit hard not a not a one line answer, but is your role not to assist rather than state facts and offer no resolution or plan to resolve. 

This point has been raised numerous times over the years, and no one seems willing or able to answer or even admit it's a serious limitation for anyone who wants to build a remotely complex network.

Please could you see if you can answer the original question, for me and the next poor admin who hits this seeming artificially low limit.

'If there is a not a workaround are there any plans to increase this limit? why does it exist at such a low number?'

16 Groups is far too low - Users have to get very creative to work around this by supernetting for ACL rules, which can lead to the loss of granularity that some users need.

The other thing that needs improvement is Switch ACL rule count limit - complex rules - or multi-element rules all produce individual background rules that quickly add up and hit the limit.  But, in standalone mode, its possible to make far far more rules on switches.