Knowledge Base Isolated VLAN Configuration for Omada
Updated 04/11/22 - updated x.1 with x.0 for Networks: There was a time where .0 is not accepted, but now it is fixed.
Hello All.
I have created a new version of the previous design I shared I shared. In this version, a new VLAN has been added (Isolated).
Use Case:
This Isolated VLAN is to complement the limitation of the "Guest" feature for Wireless, specifically, the end-device isolation (i.e. all wireless clients connected to Guest WiFi can't see each other). The Guest feature only works for Wireless Clients only so this Isolated VLAN do a similar thing: prevent other Wired Clients in the same VLAN to see each other (and also not see other Clients in other VLANs). The Isolated VLAN end devices must still be able to access the Internet.
I have listed all the ACLs needed below, along with the layout. If you want to see the ACL in Action, I have a video uploaded and you'll find the testing and demo at Part 4 of the video.
VLAN Info:
- VLAN 1-Admin (192.168.1.x)- this is the Native/Default VLAN 1. Access to all VLAN, can get granular Access to IoT VLAN with VNC and SSH
- VLAN 10-Home (192.168.10.x) - Access to all except Admin VLAN, granular access to IoT VLAN with VNC and SSH
- VLAN 20-Guest (192.168.20.x)- Access to Internet only, no access to same-VLAN devices. Wireless ONLY
- VLAN 30-Cameras (192.168.30.x)- Access to same-VLAN devices only, no Internet
- VLAN 40-Isolated (192.168.40.x)- Access to Internet only, no access to same-VLAN devices. Wired ONLY
- VLAN 90-IoT (192.168.90.x)- Access to same-VLAN devices with Internet, granular access to Home VLAN with DNS
Device List:
-
ER-7206 v1 / v1.2.3
-
OC-300 v5.7.6 / v1.14.7
-
SG-2210MP v1 / v1.0.7
-
EAP-235 v1 / v3.1.0
Note: DNS Server @ Home VLAN: 192.168.10.75
ACLs:
For Guests, make sure the Guest Network check box for Wifi is checked
Gateway ACLs:
- Deny Home to Admin
Direction: LAN > LAN
Policy: Deny
Protocols: All
Source > Network > Home
Destination > Network > Admin
- Deny Camera to Internet
Direction: LAN > WAN
Policy: Deny
Protocols: All
Source > Network > Camera
Destination > IP Group > IPGroup_Any
- Deny Camera to All
Direction: LAN > LAN
Policy: Deny
Protocols: All
Source > Network > Camera
Destination > Network > Admin
Destination > Network > Home
Destination > Network > Guest
Destination > Network > IoT
Destination > Network > Isolated
Switch ACLs:
- Permit VNC to IoT
Policy: Permit
Protocols: All
Source > IP Port Group > (Subnet 192.168.90.0/24, Ports: 5800, 5900)
Destination > Network > Home
- Permit SSH to IoT
Policy: Permit
Protocols: All
Source > IP Port Group > (Subnet 192.168.90.0/24, Port: 22)
Destination > Network > Home
- Permit DNS Port to Home
Policy: Permit
Protocols: All
Source > Network > IoT
Destination > IP Port Group > (Subnet 192.168.10.75/32, Port: 53)
- Deny IoT to All
Policy: Deny
Protocols: All
Source > Network > IoT
Destination > Network > Admin
Destination > Network > Home
Destination > Network > Guest
Destination > Network > Camera
Destination > Network > Isolated
- Permit Isolated To Net
Policy: Permit
Protocols: All
Source > Network > Isolated
Destination > IP Group > (Subnet 192.168.40.1/32)
- Permit Isolated To Net Reverse
Policy: Permit
Protocols: All
Source > IP Group > (Subnet 192.168.40.1/32)
Destination > Network > Isolated
- Deny Isolated To All and Itself
Policy: Deny
Protocols: All
Source > Network > Isolated
Destination > Network > Admin
Destination > Network > Home
Destination > Network > Guest
Destination > Network > Camera
Destination > Network > Isolated
- Copy Link
- Subscribe
- Bookmark
- Report Inappropriate Content
Hi @KJK ,
Thanks for confirming the behavior.
I'll start a new thread to get the attention of tp-link's staff...
- Copy Link
- Report Inappropriate Content
Before I started a new thread, I did a quick search in the Wi-Fi section of the forum.
It's actually known: [BUG/Issue] EAP ACL not functioning between wireless connections on the same EAP. (653, 650, 225) - Business Community (tp-link.com)
There's also a more recent thread pointing back to that one. I didn't look past that.
Believe it or not, the engineering team declared this behavior as by design...
I expressed my opinion. Feel free to pile on.
I also dared tp-link to advertise this by design behavior in their documentation. There's at least 4 customers that found out the hard way.
- Copy Link
- Report Inappropriate Content
That's a serous issue and my Internet research indicates that it can be addressed. Saying that it works that way by design does not make any sense to me. I also own an AP by another maker that supports peer-to-peer blocking for clients connected to the same WLAN. Besides, TP-Link incorporated this feature into its Guest Network.
- Copy Link
- Report Inappropriate Content
This is what I found about guest WiFi:
https://www.tp-link.com/de/support/faq/3042/
I think these are AP ACLs. Don't know in which order they will be active or if they could be overwritten. But its worth a try. But on AP level....
You could even try to put them in manually.
- Copy Link
- Report Inappropriate Content
Hi @SebastianH ,
These rules block access to the reserved IP ranges. This said nothing prevents you from setting your private network outside these ranges...
We've already established that Guest is catching traffic "earlier" than normal AP ACLs since it clearly handles the same AP/antenna case.
And yes, Guest can be overridden by Permit rules as long as the source and destinations are NOT on the same AP/antenna.
- Copy Link
- Report Inappropriate Content
Hey there Eric, apologies again for the really late reply as I am not a frequent forum visitor. Good to know ACL is making a bit of sense now. As for updating this post about rule 2, as you mentioned, it is about SSH and the rule name does state that "Permit SSH to IoT" so I am not sure how to make it even better. It is not supposed to be a reverse, but I can see where you are coming from, because of Switch ACL 4. But my focus on Switch ACL 2 is to allow only SSH, and I'd like to emphasize that. Sure, it can be viewed as a reverse, if that helps to convey the message. I realize that it is probably lost in the whole post, so I made another attempt to explain these type of ACLs in this post.
I must admit, I did not read all your ACL posts with Guest WiFi and Wireless, I just quickly scan it and I might have an idea about what you guys are talking about. I have a post that makes use of Guest WiFi and allows access to Internal LAN. I called it "Secluded WiFi",
The use case is that, all Wireless Clients will NOT see EACH other (including Printers and such) but I am "poking" a path to the built-in Guest protection and allow traffic to target network or host (can be printer or servers or other network device).I do not recommend this as there may be other things that may break when doing this.
Good hunting!
- Copy Link
- Report Inappropriate Content
Hey, I've been down with a cold so I've had time to play with my network.
I may just disappear for a while after I get this in order.
The name of the ACL is not always sufficient when it's not clear where the client and server are.
In that other, you use "Permit Home devices to SSH to IoT devices".
That's quite clearer than "Permit SSH to IoT" . Is IoT a destination or the entity you give permission to.
English is not my first language (either)...
Copying from that other post:
-
Permit Home devices to SSH to IoT devices Switch ACLs (Layer 3 Switching Version): Permit Home SSH to IoT Policy: Permit Protocols: TCP (or All) Source > IP Port Group > (Subnet 192.168.90.0/24, Port: 22) Destination > IP Group > (Subnet 192.168.10.0/24)
-
Permit IoT devices to VNC to Home devices Permit IoT VNC to Home Policy: Permit Protocols: TCP (or All) Source > IP Group > (Subnet 192.168.90.0/24) Destination > IP Port Group > (Subnet 192.168.10.0/24, Ports: 5800, 5900)
You'll note that the entity mentioned in the source is IoT in both ACLs, yet it's a "destination" in the name of ACL1 and a "source/grantee" in ACL2.
That's because for ACL1, your client is in Home while the SSH host/server is in IoT.
SSH traffic is initiated from the client and flows to the IoT host/server without issues (not ACLs denying that).
ACL1 is 100% about allowing SSH responses from the IoT host/server back to the home client.
I believe that's called reverse traffic in other posts...
ACL2 is more straightforward (server on the destination side).
FWIW, the latest posts with KJK are about the fact that AP ACLs are ineffective allowing or denying traffic that's internal to an AP (same AP/antenna/VLAN).
For example, denying access between peers or trying to override Guest by allowing traffic.
- Copy Link
- Report Inappropriate Content
Information
Helpful: 7
Views: 9498
Replies: 27