Business Community > Controllers > Need Expert Help: VLAN ACLs for Omada ER605, TL-SG2016P, TL-SG2008P – Specific IP/Port Access
< Controllers

Need Expert Help: VLAN ACLs for Omada ER605, TL-SG2016P, TL-SG2008P – Specific IP/Port Access

Need Expert Help: VLAN ACLs for Omada ER605, TL-SG2016P, TL-SG2008P – Specific IP/Port Access

Need Expert Help: VLAN ACLs for Omada ER605, TL-SG2016P, TL-SG2008P – Specific IP/Port Access
Need Expert Help: VLAN ACLs for Omada ER605, TL-SG2016P, TL-SG2008P – Specific IP/Port Access
Yesterday
Tags: #ACL
Model: OC200   ER605 (TL-R605)   SG2016P  
Hardware Version: V2
Firmware Version: Latest

Any TP-Link Omada Experts

 

 

 

Any Omada Experts,

 

I’m struggling to configure secure VLAN ACLs on my TP-Link Omada setup (ER605 router, TL-SG2016P loft switch, TL-SG2218P office switch, OC200 controller) to achieve strict VLAN segregation with specific IP/port access. I’ve hit multiple issues, including Gateway ACL limitations (no IP/port granularity), Switch ACL sync failures (“not responding / disconnected etc”), and unclear advice from TP-Link support. I’m losing confidence in the solutions I’ve tried, and even TP-Link seemed unsure. I need expert guidance to create a concise, secure, and reliable ACL rule set that meets my requirements without risking lockouts or opening entire VLANs. Below, I’ve detailed my setup, goals, issues, and questions. Any help from experienced Omada users would be greatly appreciated!

 

My Network Setup

  • Hardware:
    • Router: TP-Link ER605 (firmware up to date).
    • Switches:
      • TL-SG2016P (v1.20.5, loft, hosts CCTV cameras devices on VLAN 20).
      • TL-SG2218P (v2.03, office, hosts PC, NAS, 3CX, EAP).
    • Controller: OC200 (On VLAN 1, IP 192.168.100.2).
    • Access Point: Omada EAP (office, IP 192.168.100.4 on VLAN 1, broadcasts SSIDs for VLAN 1, 10, 30).
  • Topology:
    • ER605 (Port 1: WAN, Port 2 to SG2016P Port 1, Port 3 to SG2218P Port 1).
    • SG2218P (loft, CCTV devices on VLAN 20 via PoE ports).
    • SG2008P (office, PC on VLAN 1 (Default), NAS on VLAN 40, 3CX VOIP server on VLAN 50, EAP).
    • Uplink ports (SG2016P Port 1, SG2218P Port 1) trunk VLANs 1, 10, 20, 30, 40, 50 (VLAN 1 untagged, others tagged).
  • VLANs:
    • VLAN 1 (Default, 192.168.100.0/24): PC, OC200 (management).
    • VLAN 10 (Guest, 192.168.10.0/24): Guest Wi-Fi devices.
    • VLAN 20 (CCTV, 192.168.20.0/24): Blue Iris server (192.168.20.2), cameras.
    • VLAN 30 (IoT, 192.168.30.0/24): IoT devices (e.g., iPhone on IoT SSID, Firesticks etc).
    • VLAN 40 (NAS, 192.168.40.0/24): NAS (192.168.40.2).
    • VLAN 50 (VoIP, 192.168.50.0/24): 3CX (192.168.50.100), VoIP phone (192.168.50.10).

My Goals

I want a secure network with strict VLAN segregation, allowing only specific IP/port access and WAN where needed, while avoiding lockouts (e.g., OC200, PC management). Here’s what I need:

  1. VLAN 1 (Default):
    • Access to:
      • Blue Iris (192.168.20.2:81, VLAN 20) for UI3 web portal from PC.
      • NAS (192.168.40.2:445,139, VLAN 40) for SMB shares from PC.
      • 3CX (192.168.50.100:5015, VLAN 50) for management from PC.
      • OC200 (192.168.100.x, VLAN 1) for controller access.
  2. VLAN 10 (Guest):
    • WAN access only (internet).
    • No inter-VLAN access (e.g., can’t reach default or VLAN 20, 30, 40, 50).
  3. VLAN 20 (CCTV):
    • WAN access (e.g., remote viewing for cameras).
    • Accessible only from VLAN 1 to Blue Iris (192.168.20.2:81), not other VLAN 20 devices (e.g., cameras).
    • Cameras tagged as VLAN 20 on the loft switch and Blue Iris server tagged as VLAN 20 in office.
    • No other inter-VLAN access.
  4. VLAN 30 (IoT):
    • WAN access only.
    • No inter-VLAN access.
  5. VLAN 40 (NAS):
    • Accessible from VLAN 1 (SMB, 192.168.40.2:445,139) and VLAN 50 (SFTP, 192.168.40.2:22 for 3CX backups).
    • No WAN access.
    • No other inter-VLAN access.
  6. VLAN 50 (VoIP):
    • Internal access (e.g., 3CX at 192.168.50.100 to phone at 192.168.50.10, SIP 5060, RTP 9000-10999).
    • Access to NAS (192.168.40.2:22) for backups.
    • Accessible from VLAN 1 (3CX management, 192.168.50.100:5015).
    • WAN access (e.g., VoIP SIP traffic).
    • No other inter-VLAN access.

Security Priorities:

  • Specific IP/Port Access: Only allow exact IPs/ports (e.g., 192.168.20.2:81, not all of VLAN 20) to minimize attack surface.
  • Strict Segregation: VLANs must be isolated except for specified access (e.g., no Guest to CCTV).
  • No Lockouts: Must maintain OC200 and PC access for management.
  • Minimal Rules: Concise rule set to avoid sync issues and complexity.

Issues Encountered

I’ve tried configuring ACLs but hit several roadblocks:

  1. Gateway ACL Limitations:
    • LAN -> LAN rules only allow Network (VLAN) selections (e.g., Omada(Default), CCTV-VLAN), not specific IPs (e.g., 192.168.20.2) or ports (e.g., 81). This forces broad rules (e.g., VLAN 1 to all of VLAN 20), which I don’t want for security.
    • Can’t set same VLAN as Source and Dest (e.g., VLAN 50 to VLAN 50) for intra-VLAN traffic—assumed allowed by default, but unclear if secure.
    • IPGROUP_ANY not available for LAN -> LAN, only LAN -> WAN.
  2. Switch ACL Sync Issues:
    • My 17 Switch ACLs (e.g., allowing 192.168.20.2:81, 192.168.40.2:445,139) worked intermittently but often failed with “switches not responding” errors, requiring force provisioning or reboots.
    • TL-SG2008P (office) may hit ACE limit (~128, I had ~50+ ACEs), causing sync failures.
    • Reverse rules needed (no bidirectional option), doubling rule count.
  3. TP-Link Support Advice:
    • Suggested moving all rules to Gateway ACLs, added 3 rules (Deny All to WAN first, Allow VLAN 1 to VLAN 20, Allow VLAN 20 to WAN). This worked for Blue Iris UI3 but opened all of VLAN 20, reducing security.
    • Their Deny-first order seemed odd (shouldn’t Allows be first?), and they seemed unsure about specifics.
  4. Fishy Behavior:
    • Disabling the Gateway permit rule (VLAN 1 to VLAN 20) still allowed UI3 access (http://192.168.20.2:81), suggesting default inter-VLAN allowance by ER605, which is insecure.
    • Force provisioning switches temporarily fixed sync but issues recurred.
  5. Previous Lockout: Misconfigured rules once locked me out of OC200, requiring a reset—must avoid this.

What I’ve Tried

  • Switch ACLs (17 Rules):
    • Allowed specific IPs/ports (e.g., 192.168.20.2:81, 192.168.40.2:445,139, 192.168.50.100:5015) with forward/reverse rules.
    • Denied inter-VLAN traffic (e.g., Guest, IoT, CCTV, NAS).
    • Worked for IoT isolation (VLAN 30 couldn’t ping others) after reboot, but Blue Iris rules failed until Deny rules disabled.
    • Sync issues persisted, requiring force provisioning.

 

Also TP link support came on as a cloud user and changed some rules to gateway which worked but upon further investigation it seemed they were not correct or doing anything at all so effectively they had just allowed all the traffic to flow from A to B causing security risks. Its so frustrating.

Questions for Experts

  1. How can I restrict VLAN 1 access to only 192.168.20.2:81 (Blue Iris) without opening all of VLAN 20?
    • Gateway ACLs seem to require VLAN-level rules (e.g., VLAN 1 to VLAN 20). Can Switch ACLs override this to limit to specific IPs/ports?
  2. Is intra-VLAN traffic (e.g., VLAN 50 internal, VLAN 1 to OC200) secure by default, or do I need Switch ACLs to restrict ports (e.g., SIP 5060, RTP 9000-10999)?
    • Gateway ACLs don’t allow same-VLAN rules (e.g., VLAN 50 to VLAN 50).
  3. How do I prevent default inter-VLAN allowance?
    • Disabling permits allowed UI3 access, suggesting ER605 permits inter-VLAN traffic without rules.
  4. Can I avoid Switch ACL sync issues?
    • TL-SG2008P (~128 ACEs) struggled with 17 rules. How many rules/ACEs are safe?
    • Force provisioning helped but wasn’t reliable.
  5. What’s the best Gateway ACL order to avoid blocking access during setup?
    • TP-Link’s Deny-first (WAN) worked but seemed risky for LAN-to-LAN. Should Allows always be first?
  6. How do I ensure no lockouts?
    • Need OC200 and PC access (VLAN 1) at all times. How to configure safely?
  7. Minimal Rule Set:
    • What’s the smallest, secure rule set to achieve my goals (specific IPs/ports, strict segregation, WAN control)?

Additional Notes

  • Firmware: ER605, TL-SG2016P (v1.20), TL-SG2008P (v3.20), OC200—all up to date.
  • Topology: ER605 to SG2016P (Port 1) and SG2218P (Port 1), trunking VLANs 1, 10, 20, 30, 40, 50 (VLAN 1 untagged, others tagged).
  • Previous Lockout: Misconfigured Switch ACLs blocked OC200 access, required reset—terrified of repeating this.
  • Fishy Behavior: UI3 access persisted without permits, indicating insecure defaults. Hence why i had no faith in TP link staff members setting.
  • TP-Link Support: Suggested Gateway ACLs but didn’t address IP/port specificity or sync issues, seemed unsure.

Request for Experts

 

  • Clear steps to apply rules safely (e.g., order, testing).

Include:

Please help and im happy to provide more 

I’m happy to provide more details (e.g., current ACLs, OC200 IP) if needed. Thanks in advance for your expertise—this has been a nightmare, and I need a solution that works!

Best regards,
[Your Forum Username]

  0      
 
  0      
 
#1
Options
4 Reply
Re:Need Expert Help: VLAN ACLs for Omada ER605, TL-SG2016P, TL-SG2008P – Specific IP/Port Access
Yesterday - last edited Yesterday

  @AIT90 

 

This will limit inter-commuication to exaclt wht you specify.  If you want to limit the individual ports per IP pair thats a LOT more rules.  This set will limit IP pairing to exact IPs only

 

IP Groups to Make

 

Grp1 - 

192.168.100.0 /24

192.168.20.2 /32

 

Grp2-

192.168.100.0 /24

192.168.40.2 /32

 

Grp3-

192.168.100.0/24

192.168.50.100 /32

 

Grp4

192.168.40.2 /32

192.168.50.100 /32

 

SWITCH RULES (In this order!)

Type(Ip groups both sides or Networks both sides) - Deny/Permit - Sources - Destination
(and yes, the top 4 are the same IP group each side, this allows 2-way without having to make a reverse rule)

IP Group - Allow - Grp1 > Grp1

IP Group - Allow - Grp2 > Grp2

IP Group - Allow - Grp3 > Grp3

IP Group - Allow - Grp4 > Grp4

Network - Deny - VLAN 20 > All but VLAN 20

Network - Deny - VLAN 30 > All but  VLAN 30

Network - Deny - VLAN 40 > All but VLAN 40

Network - Deny - VLAN 50 > All but VLAN 50

 

GATEWAY RULES

Type Deny/Permit Sources Destination

Network - Deny - LAN>WAN - VLAN 40  > IP_Any

Main: ER8411 x1, SG3428X x1, SG3452 x1, SG2428LP x1, SG3210 x1, SG2218P x1, SG2008P x1, ES205G x2, EAP650 x6 Remotes: ER605 v2 x3, SG2008P x2, EAP650 x2 VPN Server: ER7206 v2 Controller: OC300
  0  
  0  
#2
Options
Re:Need Expert Help: VLAN ACLs for Omada ER605, TL-SG2016P, TL-SG2008P – Specific IP/Port Access
Yesterday
Thanks for this reply. Can i adapt it too add: Port Specificity: specific ports (e.g., 81 for BI, 445/139 for NAS, 5015 for 3CX, 22 for backups), to enhance security. WAN Control: Can i deny WAN for the nas VoIP Internal: Would we Need a port-specific rule (SIP, RTP) for extra security. Do I need a Default Inter-VLAN: Needs a Gateway ACL to block default allowance (e.g., VLAN 1 to VLAN 20). Just trying to add as robust security as we can, thanks for reading
  0  
  0  
#3
Options
Re:Need Expert Help: VLAN ACLs for Omada ER605, TL-SG2016P, TL-SG2008P – Specific IP/Port Access
Yesterday - last edited Yesterday

  @AIT90 

 

If you want to specify the ports, you will need to adjust what i posted as follows

 

IYou need ONE ip-port group per device with its specific IP as a /32 and port added

Make an IP group with each IP as a /32

 

You will then have to make 2 rules per pairing, one allowing to, one allowing from

 

Then you would need an extra Network deny from VLAN 1 to all but vlan 1

 

eg

 

allow > vlan 1 group > NAS ip-port group

allow > NAS ip-port group > vlan 1 group

 

For the SIP <> NAS, you will have to have have both, its own IP as an IP group as a /32 AND its specific ip as a /32 and its port as an IP group.

 

EG, the NAS <> Phone rule would be

 

allow > phone IP group > nas IP-ports group

allow nas IP-ports group > phone IP group

 

However, there is very little benefit from restricting to individual ports really, if an IP isnt in the allow ruleset i posted, it simply cannot see it at all.  It wont get any response.  You are also potentially limiting your own access from vlan 1 should you need to do maintenance or access a web service on the target that is on a port not in the list.

 

Main: ER8411 x1, SG3428X x1, SG3452 x1, SG2428LP x1, SG3210 x1, SG2218P x1, SG2008P x1, ES205G x2, EAP650 x6 Remotes: ER605 v2 x3, SG2008P x2, EAP650 x2 VPN Server: ER7206 v2 Controller: OC300
  0  
  0  
#4
Options
Re:Need Expert Help: VLAN ACLs for Omada ER605, TL-SG2016P, TL-SG2008P – Specific IP/Port Access
Yesterday - last edited Yesterday

  @AIT90 

 

I forgot to say, the switch rules will prevent any cross vlan that isnt specifically in the allow list.  It doesnt matter if the gateway doesnt have matching lan>lan rules, the switch will intercept and block it. You could, if you want, add gateway rules, but you cannot add any that would prevent anything in the switch rules from working

 

eg, you cant add a gateway vlan 1 to everything but vlan 1 rule because this will kill dead your access to anything not in vlan 1 and totally over-ride the switch rule.  (this situation is reversed if you use switch based routing, which i ssume you are not)

 

for the phone > internet rule, you would need an Ip-Port group for its traffic, and then put an allow > phone vlan > lan>wan > phone traffic_ip_port_group, and below that, a deny > phone vlan > lan>wan > ip_any (as gateway rules)_

 

Main: ER8411 x1, SG3428X x1, SG3452 x1, SG2428LP x1, SG3210 x1, SG2218P x1, SG2008P x1, ES205G x2, EAP650 x6 Remotes: ER605 v2 x3, SG2008P x2, EAP650 x2 VPN Server: ER7206 v2 Controller: OC300
  0  
  0  
#5
Options

Information

Helpful: 0

Views: 76

Replies: 4

Tags

ACL
About Us
Press
Copyright © TP-Link Systems Inc. All rights reserved.