Inter-VLAN Segmentation with Strict Isolation and Limited Exceptions (ER605 + SG2008P + Omada APs)

Inter-VLAN Segmentation with Strict Isolation and Limited Exceptions (ER605 + SG2008P + Omada APs)

Inter-VLAN Segmentation with Strict Isolation and Limited Exceptions (ER605 + SG2008P + Omada APs)
Inter-VLAN Segmentation with Strict Isolation and Limited Exceptions (ER605 + SG2008P + Omada APs)
Friday
Model: SG2008P  
Hardware Version: V3
Firmware Version: 3.20.0 Build 20230818 Rel.72032

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

  1. Media → NAS (Home VLAN)

    • destination: NAS IP only

    • ports: specific application ports (e.g. Immich, DLNA, SMB)

  2. IoT → NAS (Home VLAN)

    • destination: NAS IP only

    • ports: Home Assistant, printer-related services

  3. Surveillance → NAS (Home VLAN)

    • destination: NAS IP only

    • ports: RTSP / ONVIF / NVR services

  4. 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

  1. Is this design fully supported and achievable with:

    • ER605

    • SG2008P

    • Omada EAP APs

  2. Can Switch ACLs in Omada:

    • reliably filter inter-VLAN traffic originating from Wi-Fi clients?

    • enforce IP + port-based exceptions?

  3. Are Gateway ACLs strictly required for any part of this design, or can all enforcement be done at the switch level?

  4. 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.

  0      
  0      
#1
Options
1 Reply
Re:Inter-VLAN Segmentation with Strict Isolation and Limited Exceptions (ER605 + SG2008P + Omada APs)
8 hours ago

  @brute4c 

 

In reviewing what you want to achieve, I would say that Omada can support your requirements. If I am wrong, perhaps one of the more-seasoned experts can weigh in on this.

 

My answers to your key questions are:
1. Yes.
2. Yes.  The latest controller release also allows IP-Port groups in gateway ACLs which may be easier to set up than switch ACLs.
3. Gateway ACLs can be configured to restrict internet access but I don’t see that option under Switch ACLs in my OC300 controller. For those VLANs where you want to restrict internet access, gateway ACLs might be required.
4. I don’t see any limitations.

 

1x ER7406 1x OC300 4x SG2008 1x EAP610 3x EAP650-Desktop
  0  
  0  
#2
Options