@Clive_A Thank you for your answer. Yes, my switches are all Omada switches and I'm using the OC300 hardware controller.

So, if I understand correctly,

1. to prevent my IOT VLAN to access other VLANs, I should have a Switch ACL rule (source and destination "network") that denies access to other VLANs

2. ... and then I add another rule also as a Switch ACL rule like this:

  Policy: permit

  Source: type network, IOT VLAN

  Destination: type IP group, and I set here my Home Assistant server IP with a /32 mask

Is it correct?

Also:

- How does precedence work here? What should be the first rule? 1. or 2. ?

- For these 2 rules, should the binding type be "Ports" or "VLAN"?

Thank you.

  @Clive_A OK, this is not possible. Switch ACL are not working for one direction only, and Gateway ACL works, but I cannot add a rule for a specific IP.

So I guess I have to wait for the 5.16.X you mention.

Is there a roadmap pubically available?

Also, where can we find changelog and versions for OMADA routers, EAP, ...?

  @StephaneDupont ,

While it would seem more natural to control inter-VLAN traffic at the gateway, GW ACLs are very coarse and don't handle your scenario.

But switch ACLs might. They are less straightforward though.

If you look around on this forum, you'll see some mentions about switch ACLs being stateless.

It essentially means that they look at packets without any context.

Client-server communication requires a packet from the client to the server (request) and one in the other direction (reply).

If you have a broad rule DENY-VLAN1->VLAN2, when the server is in VLAN2 (client in VLAN1), you need a finer ALLOW-VLAN1->SERVER to allow the requests through.

When the server is in VLAN1 (client in VLAN2), the finer rule is ALLOW-SERVER->VLAN2. This allows the replies through.

If you also broadly DENY-VLAN2->VLAN1, you need both finer exceptions.

The exceptions need to exist above the broad rule.

I'm not familiar enough with HA (future project for me) to know which of the devices or HA takes the role of client and server but it doesn't really matter here, at least as long as you don't tighten stuff up at the port level. ALLOW IOT -> HA, DENY IOT->DEFAULT_LAN

This said, a quick search on HA with VLANs indicates that device discovery is not easy to setup.

Some people seem to resort to a 2nd NIC on HA (for the IOT network), physical or virtual.

Others seemed to have some luck with discovery reflection by their router. I haven't played with this but it seems there's some support for this (for mDNS) in Settings->Services->mDNS.

In any case, I'd deal with the ACLs AFTER you've successfully made discovery work.

And since ACLs produce no logs, you won't even know what it blocked until the experience the aftermath...

  @EricPerl I do not care about discovery, it's easy to add devices manually, but in any case, the problem is that Switch ACL rules are not working for one direction only. If I create a single Rule (no other rules are present, it's the only rule I have) to prevent access from VLAN1 to VLAN2, then VLAN2 cannot access VLAN1 anymore.

  @StephaneDupont ,

That single rule prevents traffic from VLAN1 to VLAN2.

It blocks traffic initiated from VLAN1 to any "server" in VLAN2 (the more intuitive behavior).

But it also blocks traffic flowing back from VLAN1 to VLAN2 corresponding to communication initiated from VLAN2 (the more confusing behavior).

Let's take an example with a SSH server SRV1 in VLAN1, and you're trying to initiate the connection from CLT2 in VLAN2.

Packets from CLT2 to SRV1 flow just fine. The replies from SRV1 to CLT2 are dropped on the floor.

If you enable the rule after the connection is established, you end up with a command executed on SRV1 but the output never reaches CLT1 (you can't be sure it executed or not from that client).

If you add a rule to Allow traffic from SRV1:22 to CLT2 (or the entire VLAN2) network above the deny rule, things fall back into place.

I don't know enough about HA to recommend anything at the port level, but a rule for the entire HA host should be enough.

[Edit:] That more targeted rule need to precede the broad VLAN to VLAN deny.

Wouldn't it all be easier if ACLs firing triggered some form of logging? 

  @EricPerl So, if we forget about HA, there is no way that all my IOT devices cannot access the VLAN where the computers are, but that I can still access the IOT devices from a computer on the computer VLAN ?

EDIT: ... or would it be possible via Gateway ACLs?

  @StephaneDupont ,

The gateway ACL would be DENY IOT -> DEFAULT.

All communication initiated from IOT towards DEFAULT is dropped at the gateway (pure inter-VLAN control).

All communication initiated from DEFAULT towards IOT is not affected. Replies make it back because there's enough state at the gateway to handle it.

There's a caveat to that last part. Idle connections are forgotten at some point (not sure how configurable that it) to avoid excessive memory consumption. The DEFAULT client will have to re-initiate communication, which is often transparent to the user.

The switches only look at packets with source and destination. Client and server for requests, server and client for replies...

Note that if the kind of access you need from computer to IOT is control/status that also works when you're not home, it means that your IOT devices have shadow state in the cloud. IOT devices only communicate with their cloud (after setup like Wi-Fi). Your PC or phone also access the cloud related to the devices.

You don't need to open up anything on your network regarding inter-VLAN.

For IOT devices that require local communication, you need ALLOW IOT -> Computer before DENY IOT -> DEFAULT (both switch ACLs).

You can NOT override a gateway ACL...

You should be able to be more granular (at the port level) from documentation or network captures...

Again, that's the part where the absence of logging really hurts.

Personally, I'm so tired of these ACLs and their shortcomings (mainly logging) that I'm switching to OPNsense (for now as a transparent filtering bridge between my router and main switch).