Inter-VLAN Segmentation with Strict Isolation and Limited Exceptions (ER605 + SG2008P + Omada APs)
Hello,
I would like to validate whether the following network design and security model is technically feasible using TP-Link Omada, specifically with inter-VLAN ACLs and granular exceptions (IP + port based).
I am particularly interested in whether this can be implemented reliably and predictably, preferably using Switch ACLs, since all wired and wireless traffic is aggregated on the switch or EAP
Hardware Used
-
Gateway: TP-Link ER605
-
Switch: TP-Link SG2008P (managed, Omada-adopted)
-
Access Points: TP-Link Omada EAP-615 Wall series (VLAN tagging + PPSK supported)
-
Controller: Omada Software Controller (Docker on NAS)
All APs are connected directly to the SG2008P.
All wired devices (NAS, cameras, etc.) are also connected either to the SG2008P or EAP's
VLANs and Intended Purpose
1. Home (Trusted / Management VLAN)
Devices:
-
personal laptops
-
smartphones
-
NAS
-
Omada Controller
-
management access to router, switch, and APs
Rules:
-
no client isolation
-
full Internet access
-
full access to all other VLANs (administrative network)
This is the only fully trusted network.
2. Media (Semi-trusted)
Devices:
-
Smart TVs
-
amplifiers
-
Chromecast / Google Cast devices
-
trusted guests
Rules:
-
Internet access allowed
-
no client isolation (multimedia discovery required)
-
no access to Home VLAN by default
-
limited access to NAS only via explicit exceptions
Typical use cases:
-
Chromecast
-
Spotify Connect
-
media streaming from NAS (e.g. Immich)
3. IoT (Untrusted, Isolated)
Devices:
-
IoT devices
-
network printer
Rules:
-
client isolation enabled
-
no Internet access
-
no access to any other VLANs by default
-
limited access to NAS only via explicit exceptions
4. Surveillance (Untrusted, High Risk)
Devices:
-
IP cameras
Rules:
-
client isolation enabled
-
no Internet access
-
no access to any VLANs by default
-
limited access to NAS (NVR) only via explicit exceptions
5. Work (Restricted)
Devices:
-
corporate or less trusted laptops
Rules:
-
client isolation enabled
-
no Internet access
-
no access to Home, Media, or Surveillance
-
access only to printer (located in IoT VLAN) via explicit exception
Inter-VLAN Policy Model (Conceptual)
Default rule:
All inter-VLAN traffic is denied unless explicitly permitted.
Explicit Exceptions Required
-
Media → NAS (Home VLAN)
-
destination: NAS IP only
-
ports: specific application ports (e.g. Immich, DLNA, SMB)
-
-
IoT → NAS (Home VLAN)
-
destination: NAS IP only
-
ports: Home Assistant, printer-related services
-
-
Surveillance → NAS (Home VLAN)
-
destination: NAS IP only
-
ports: RTSP / ONVIF / NVR services
-
-
Work → Printer (IoT VLAN)
-
destination: printer IP only
-
ports: printing protocols only
-
No other cross-VLAN communication should be possible.
ACL Implementation Expectations
Ideally:
-
ACLs are enforced at Switch ACL level on the SG2008P
-
because:
-
all APs are connected to the switch
-
all Wi-Fi traffic traverses the switch
-
enforcement at the switch avoids unintended routing behavior at the gateway
-
The desired ACL capabilities are:
-
source VLAN → destination IP group
-
protocol filtering (TCP / UDP)
-
port-based filtering
-
bi-directional rule control
Key Questions
-
Is this design fully supported and achievable with:
-
ER605
-
SG2008P
-
Omada EAP APs
-
-
Can Switch ACLs in Omada:
-
reliably filter inter-VLAN traffic originating from Wi-Fi clients?
-
enforce IP + port-based exceptions?
-
-
Are Gateway ACLs strictly required for any part of this design, or can all enforcement be done at the switch level?
-
Are there any known limitations or caveats that would make this design unreliable or impossible on this hardware?
Summary
This is not a request for workarounds, but a validation of whether Omada supports a principled, least-privilege VLAN security model with strict isolation and carefully scoped exceptions. Any confirmation, limitation notes, or recommended adjustments are highly appreciated.
Thank you.
