@Death_Metal thanks for sharing this - it will be helpful in my learning about what is possible and helpful on my own network (although as an ER7212-PC + EAP user, I can't use Switch ACLs). Especially it's helpful that you seem to understand the current limitations of the Omada SDN, which some other tutorials online do not appear to.

2 questions:

1/ The "Isolated" VLAN that you defined for wired clients on subnet 192.168.40.x - I think that it applies all of the exact same restrictions as the guest network for WiFi clients on 192.168.20.x. Why not use a single subnet and set of ACLs for both the wired and wireless clients?

2/ Is there any special setting needed for IPv6 - for example, must it be turned off, or does it just work with this set of rules?

RockPaper wrote

  @Death_Metal thanks for sharing this - it will be helpful in my learning about what is possible and helpful on my own network (although as an ER7212-PC + EAP user, I can't use Switch ACLs). Especially it's helpful that you seem to understand the current limitations of the Omada SDN, which some other tutorials online do not appear to.

 

2 questions:

1/ The "Isolated" VLAN that you defined for wired clients on subnet 192.168.40.x - I think that it applies all of the exact same restrictions as the guest network for WiFi clients on 192.168.20.x. Why not use a single subnet and set of ACLs for both the wired and wireless clients?

 

2/ Is there any special setting needed for IPv6 - for example, must it be turned off, or does it just work with this set of rules?

 

 

Hello  @RockPaper glad to know my post is helping.

1. It can be done, but I also have several reasons to create a new VLAN:
   • Easier for me to demonstrate the similarity and difference
   • Clarity of VLAN and ACL, easier to troubleshoot by making these pieces separate and Description simpler
   • Biggest reason, the "isolation" ACL will impact some of the built-n Guest functionality such as Captive Portal Access which will be blocked by the ACL. I can and have done it in the past, but the video gets even longer :( and I doubt people really watch very long video. EAP ACL will be needed and it's just so much simpler to use the built-in Guest checkbox for Wireless clients
2. I have not personally tested this in IPv6 settings, in the past, IPv6 was limited but I can't be sure now. If there is no technical limitation (i.e. a setting that can't be done in Omada), I don't see any issue. However, I can't really say at this time with 100% certainty.

To expand on item 1, what I did (and I have a video recorded already), was create an Isolated Wireless Network. When I get the chance, I'll upload it.

  @Death_Metal 

Thank you for all of your posts you've made regarding VLAN setups and ACLs. I'm coming across a very ambiguous issue regarding a dedicated gaming server I am hosting on my network.
To put this bluntly, when the game comes to an end, the connection to the server will hang. However, if I disable the ACL rule I created to deny all access to my VLAN I am on, the game will run as intended.

I'm not looking for you to specify an answer to my issue, but I am looking for some guidance on what I can be checking:
-Are there specific logs I can look at regarding the time of the connection issue?

-Is it not necessary to deny all traffic for dedicate gaming servers?

-Is there a way I can define rules to create a DMZ network to host dedicated gaming servers on?

Thank you for taking the time to read.

Hey ss1gohan13 , sorry for late reply as I don't usually frequent the forums. I saw a notification from my email and saw your message. For your main post, it is possible that you made a Switch ACL and that server is expecting a "terminate" message/packet/signal (however it's called) and your server is not getting it. Try to check any documentation related to the network port it is using (i.e. Minecraft is using 25565) and allow bidrectional ACL traffic specific to that server's IP i.e. /32. As for other inquiries: - I am not aware of that. Maybe there is a settings under Logs but I have never seen that option. When I get the chance, I'll take a look and edit this post. - Only you can decide for that. I know you mentioned it's "dedicated" so assumption is it's not doing something else, but it will be your call. But whether you dedicate your server or not, if the hardware is not capable, then you'll have issue. Make sure your hardware meets the requirements. - For Port Forwarding, not ACL, yes you can define a DMZ.

  @Death_Metal 

first: thank you for all your videos. I really learned from them how OMADA works and how the concept behind is done.

Second: I have two questions ;)

1. You use " Subnet 192.168.90.1/24" in several rules. What kind of addressing is this. Its an IP address and not a network address. In my point of view it should be "192.168.90.1/32" if you mean the host. Or "192.168.90.0/24" if you mean the subnet.

2. About this post and isolation. For me it didn't work.

I created a post what I was trying. Maybe you can help:

https://community.tp-link.com/en/business/forum/topic/640422

  @Death_Metal , thanks for the post. The official docs and KB articles are quite lacking when it comes to real examples IMO.

This said, I have questions:

Q1: Why are Gateway ACLs 1 & 3 not Switch ACLs?

I have looked for a clear distinction between Gateway LAN->LAN ACLs and Switch ACLs with no success...

I hope it doesn't have anything to do with the fact that there's a switch in the router when more than 1 port is used on the LAN side.

I'm also baffled by the fact that such Gateway ACLs don't seem as capable as Switch ACLs (they only support NETWORK source et destination).

Q2: Why are Switch ACLs 1 & 2 specifying a port on the source side?

Aren't these ports primarily used on the server side, which also happens to be the more trustworthy side (as opposed to the untrusted IoT clients)?

Maybe I'm missing something about the use of the this Pi boxes...

You might want to add some context in the use case section if that's the case.

And per previous reply, 192.168.90.1/24 is weird.

Q3: Don't Switch ACLs 5 & 6 allow more than Internet access. For example DHCP?

I can't say I found concrete evidence that the creation of VLAN implies the existence of a virtual DHCP server at the gateway but I don't know how else it would work with the following ACL. 

Note that I would not have bothered with these questions if the post had not be promoted by staff, but as it is, I believe it should be held to a higher standard.

Sincerely,

Eric

  @SebastianH 

Hey Sebastian, thanks for the info. Looks like I didn't see this question before so I will skip question 2.

For question 1, there was a time that Omada ACLs won't accept x.0 in ACL so I am forced to use a .1. However, if you look at the diagram and the write-up, I used an IP followed by .x to designate network. Nowadays, ACLs correctly accept a .0.

Good hunting!

EricPerl

Q1 - Gateway ACLs are Stateful and Switch ACLs are not. The use case for Stateful ACL is that, if you will always have the same Source and Destination network (and always in that direction, i.e. Home to IoT and never IoT to Home), then Gateway ACL is much simpler and straightforward to implement. There was a time that this was not available, and this has been highly requested by users. If you need more granularity and control, you need to go for Switch ACL.

Q2 - Because of the way Switch ACL works when doing Source and Destination ACL. If you ask me why this is done this way, you can ask the TP Link engineers as I have no idea why it is this way. However, this is how I am able to allow more granular way of ACLs i.e. allow Home to VNC and SSH to IoT, and later on, allow IoT to access DNS server in the home VLAN. This use case will never work using Gateway ACL. Using Switch ACL and Port Granularity, I can allow what goes on from one VLAN to another VLAN, no matter the Source and Destination. As for use of .1 instead of .0, there was a time when ACL (click) will not accept a .0 in the source/destination network.but if you look at the diagram and write up, i use a .x

Q3 - There was a time when ACL 7 DHCP will block DHCP, because I had an earlier version of this which specifically permitted x.1/32 to provide DHCP and Internet access. But at the time I was doing it, and testing it, ACL 7 didn't break DHCP. Best way is to test and add an additional permit if DHCP is being blocked or if you don't want DHCP, just turn off DHCP server. Either way works.

All my posts are usually accompanied by videos. I am not saying they are perfect, but they were tested at the time of writing and at the time of each firmware versions.

I normally don't bother with snide remarks, but if you can do better, then I encourage you to contribute and help fix whatever you think is incorrect.

  @Death_Metal, thanks for the quick reply.

I guess I need to experiment more hands on again because I can't process your answers.

I've experimented before and managed to lock myself out (had to reset all devices and start over). I can deal with that but my partner was not thrilled...

I'll play in test VLANs next time!

It doesn't help that there's no feedback about which rules fired...

No snide remarks were intended.

If anything, I meant it as a compliment that your post was elevated to almost official documentation.

I clearly don't have anything worth sharing now.

It looks like you updated your post to address the xxx.1/24 remarks. Thanks.

This said, switch ACLs 5 & 6 now have xxx.0/32 (I think it was 1/32 before which was correct to allow access to the GW only).

As it is now, I suspect there's no Internet access within the Isolated network.