@SebastianH 

Switch ACL is not stateful, try enabling bidirectional ACL rules

  @MR.S I did. Like described...

  @SebastianH 

SebastianH wrote

Hi everyone,

 

I'm experiencing an issue with ACLs on Omada-managed switches. I have three rules configured: 

 

Allow all traffic from GatewayIP to IoT

Allow all traffic from IoT to GatewayIP

Allow all traffic from 192.168.30.9 to 192.168.30.4

Allow all traffic from 192.168.30.4 to 192.168.30.9

Deny all traffic within the IoT VLAN (source: IoT → destination: IoT)

 

As soon as I enable the deny rule, communication between .9 and .4 becomes unstable. Pings from .9 to .4 occasionally show very high latency (hundreds of ms), followed by a series of "Destination Host Unreachable" messages. This happens even though the specific allow rules for those two IPs are placed above the deny rule.

 

After some testing, I found that ARP is the problem:

 

When I clear the ARP cache on .9, it sends a broadcast ARP request for .4, but doesn't receive a response.

 

During that time, ping fails.

 

Eventually, it gets a response and communication resumes.

 

Static ARP entries temporarily resolve the issue.

 

So it appears that the switch-based ACL is blocking ARP replies from .4 to .9, even though I have IP-based allow rules in place. Since ARP is a Layer 2 protocol, it seems to be affected by the broad "deny IoT → IoT" rule.

 

Unfortunately, I cannot use Gateway ACLs – only Switch ACLs are available in my setup.

 

My questions:

Is there a way to allow ARP replies between two specific hosts while still denying all other intra-VLAN communication?

 

Does Omada offer protocol-level control in Switch ACLs (e.g. allow ARP or filter by EtherType)?

 

Are there plans to support stateful ACLs or more granular protocol control?

 

Any suggestions or workarounds would be appreciated!

 

Thanks.

The description is basically correct. Yes, when you block the ARP or create the ACL like this, it would cause the local connection to fail. 

If you are doing an IoT setup, why not consider the Guest WIFI instead, which simply enables the Guest Network on the SSID profile. It would save the trouble of setting this up.

If you don't have an Omada router, you don't have the option to use the stateful ACL. Switch ACL is never stateful as it is a layer 2 device. 

To the questions:

1. In standalone, you might have the option to use granular protocols or granular ACLs. 

2. No. 

3. No.

Blocking the ARP is the incorrect way to use it. I don't think any switch would be that "granular" to allow you to block ARP. ARP is quite important. 

Guest Network should be what you need. For the wired devices, you can create separate ACL rules to stop them from accessing other devices. 

  @Clive_A 

Hi.

I'm using an Omada Router and I am talking about LAN and WiFi.

I want to block any client to client communication exept gateway traffic (internet) and dedicated traffic which I want to allow.

With stateful gateway ACL I was not able to achieve this.

Als also in WiFi when enabling Guest Network, I will not be able to allow dedicated traffic between clients.

I don't want to block ARP. It just do it when creating a Switch deny any ACL and there is no way to overrule it.

For the wired devices, you can create separate ACL rules to stop them from accessing other devices. 

--> this is what I'm trying ;-)

  @SebastianH 

SebastianH wrote

  @Clive_A 

Hi.

I'm using an Omada Router and I am talking about LAN and WiFi.

I want to block any client to client communication exept gateway traffic (internet) and dedicated traffic which I want to allow.

 

With stateful gateway ACL I was not able to achieve this.

Als also in WiFi when enabling Guest Network, I will not be able to allow dedicated traffic between clients.

 

I don't want to block ARP. It just do it when creating a Switch deny any ACL and there is no way to overrule it.

 

 

For the wired devices, you can create separate ACL rules to stop them from accessing other devices. 

--> this is what I'm trying ;-)

Then for the wired devices, you use SW ACL and use IP Group instead to block the wired IoT stuff. 

The standalone mode ACL would offer more granular ACLs. The controller mode only got what you see now.

  @Clive_A 

I found out that the issue is related to the ALLOW rules.
When only allowing dedicated PORTS and protocols (IP-PORT-GROUP), then ARP is not matching and beeing blocked.

When allowing any protocol and using IP-GROUPs, then its working.

But this defeats the purpose of fine-grained control.  Only way to solve this is to allow ARP, but this does not seem to be possible with Omada Controller.


Not really satisfying.

Any suggestion how to solve this?
My goal was to allow very specific communication (TCP port 2010) between two IoT devices, while blocking everything else between devices in the same VLAN or IP group.