omada inter-VLAN

[jorgemarmo]

Hi, I'm (slowly) setting up my home network,
I got full omada system:
-OC220 controller
- ER605 gateway/router
- 24p switch non PoE SG3428
- 24p switch PoE SG2428LP
- 3x WAP EAP650-desktop

ant I set up some VLANs
- Guest //w/ associated SSID
- IoT //w/ associated SSID
- Home //w/ associated SSID
- Cameras (cams and NVR)
- Management (default)

the thing is that for the moment my segmentation is worth nothing... since all inter VLAN communication is allowed,
I saw I could "fix" this with ACLs, but, been a newbie, I have some questions.

1) imagine that I block all inter-VLAN communication, still, all devices should be able to reach the router (for DHCP and WAN) cuz it exists on each VLAN, right?
2) should I use a Gateway ACL OR Switch ACL? I guess the latter, since is a LAN-LAN rule (not a WAN-LAN)
3) this might be very newbie question, but: reading some stuff I got the impression that I could block anything originating from Cameras VLAN, but still I could access that VLAN from Home VLAN... is this possible? I thought that either you block or you allowed, regardless of from where the communication "started"
4) depending on previous question, how can I add some security to Cameras VLAN, still being able to access them from Home VLAN / same as for IoT and Home (most of my IoT devices are local AND internet controllable / in the future they should all be local and controllable by HomeAssistant....)
5) on the Omada controller when in Gateway ACL, every network type appears 2 times, for instance "Network" and "! Network", what is this?
6) what are "IP Group" and "IP-port group"?

Thank you!

 

[PaddraighOS]

Good questions, and you're on the right track.

1) Yes, correct. Blocking inter-VLAN traffic means blocking VLAN-to-VLAN communication through the router. Each device still sends its default gateway traffic to the ER605 on its own VLAN (DHCP requests are broadcast-only within the local VLAN, and the ER605 handles DHCP for each VLAN independently). So DHCP and WAN access are unaffected by inter-VLAN ACL rules.

2) Use Gateway ACLs on the ER605, not Switch ACLs. Here's why: the ER605 is doing all the inter-VLAN routing in your setup. Switch ACLs are processed at the switch layer and are best suited for intra-VLAN or port-level control. For denying VLAN-to-VLAN traffic, you want the firewall rules applied where the routing decision happens, which is the gateway.

In Omada, the Gateway ACL approach for your setup would look something like this:
- IoT -> any private IP range: DENY (but allow IoT -> WAN)
- Guest -> any private IP range: DENY (allow Guest -> WAN only)
- Cameras -> any except Management: DENY (cameras shouldn't need internet usually)
- Home -> IoT: allow only specific ports you need (e.g., casting, homekit)

One thing to watch: in Omada, the ACL rules are processed top-down and stop at the first match, so put your "allow" exceptions above your "deny all" rules for that VLAN. Also make sure you're not accidentally blocking the devices from reaching the ER605's IP on their VLAN for DNS - by default the ER605 is the DNS resolver, so DNS queries from each VLAN go to the gateway IP on that subnet, which is local and won't be affected by inter-VLAN rules.

Best of luck with it.

 

[PaddraighOS]

To address the remaining questions:
3) Yes, you can absolutely allow one-directional access. Omada's Gateway ACL is stateful, meaning it tracks TCP connection state. So you can have a rule "Allow Home -> Cameras (any port)" followed by "Deny Cameras -> Home (any port)", and the stateful engine will still allow the return traffic for connections that Home initiated - you will be able to browse camera streams from a Home device without the cameras being able to initiate new connections back. The key order is: Allow rules for the direction you want above the Deny rules.
4) Practical setup for Cameras VLAN: Allow Home -> Cameras on the ports your NVR/cameras actually use (e.g., 8000, 8443, 554 for RTSP). Deny Cameras -> all other VLANs. Deny Cameras -> WAN (cameras generally should not need internet, this also stops any cloud phoning home). If you have Home Assistant, you allow HA's IP -> Cameras explicitly.
5) The "! Network" notation means NOT that network - it is a negation. So "! IoT" in the destination field means "any destination that is NOT the IoT VLAN". Very useful for rules like "Deny IoT -> any private range" where you want to allow IoT internet access but block IoT from reaching any of your other VLANs.
6) IP Group is a named collection of IP addresses or subnets that you can reuse across multiple rules. Example: create group "Private_Ranges" with 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, then use it in a rule "Deny IoT -> Private_Ranges" to block IoT from all RFC1918 space in one rule. IP-Port Group adds a port constraint on top - useful for service-level rules like "Allow Home -> NVR_Access (cameras subnet:8443)" without specifying the subnet and port separately each time.