@Death_Metal 

I've finally made sense of the situation with regards to Q2.

The Switch ACL 3 (access to DNS) made sense to me from the get go.

It's literally about allowing the DNS requests to flow from IOT to HOME. Other traffic in that direction is blocked by rule 4

The previous 2 rules (especially 2) made less sense.

Now I believe they are actually about allowing SSH responses to flow from IOT back into HOME.

You don't need a "direct" rule to allow SSH requests the other way (HOME to IOT) because they are not blocked by anything.

But rule 2 at least appears to be a "reverse" rule.

In my opinion, it would help to specify where the SSH servers are (apparently on the IOT side) and you may also want to update the rule name...

I'm now pretty sure my previous ACL experiments ended up very poorly because I had missed the stateless nature of these Switch ACLs.

I have no clue how other vendors deal with this but this is not intuitive and maybe not emphasized enough in the docs (because I don't appear to be the only one that didn't get it based on other posts).

  @Death_Metal should this setup work for my use-case? 

I would like to set up an IoT VLAN that is

- isolated (can't peer with others inside its vlan)

- can't talk to any other VLAN

- Home/Admin VLAN should be able to talk to IoT clients 

I guess due to the last one, I need to use stateful Gateway ACLs? I can't make it to work together with the Switch ACLs that would deny to peer inside the VLAN

  @florian_22 ,

If all your IoT clients are wireless, you only need to setup the IoT wireless network as a Guest network.

If some of them are wired, then you need to resort to switch ACLs (rules 5 & 6 , IMO with a .1 not a .0, for gateway access, and the first destination of rule 7).

Your 2nd use case is more easily achieved with a getaway ACL (LAN->LAN deny with IoT source and all other networks as destination).

Then you don't need to do anything for the 3rd use case (allowed by default and not blocked by the above rules).

It's closer to the config in this post: Secured Admin, Home, IoT, Cameras and Guest VLAN using Gateway ACL - Business Community (tp-link.com)

You could implement your use cases 2 and 3 with switch ACLs (along the lines of this current post) but you'll need to be more specific about which traffic is allowed to flow BACK from IoT to Home/Admin. Here, the OP allowed VNC and SSH.

HTH

  @florian_22 ,

Hmm, I had not experimented enough with the "Guest Network" functionality apparently. I just remedied that situation.

It indeed blocks way more than just traffic within the wireless network...

So you can achieve use cases 2 & 3 with the gateway ACL mentioned in your last reply.

That leaves the traffic within IoT network.

My experimentations this morning have been completely fruitless.

* Enabling "Guest Network" blocks everything but DHCP/Internet, and I also failed to override that setting with Permit ACLs at any level.

* I've also failed to reproduce "Guest Network" functionality with AP and/or Switch ACLs...

The switch ACLs work properly when at least one of my test peers is wired.

If both test peers are wireless (same SSID, same antenna), I failed to block any traffic using my EAP245! It's as if AP ACLs plain do nothing (which could also explain my failure to override above).

I'm going to sleep it over and retry tomorrow (or sooner if I get a new idea).

Otherwise, I'll likely start a new thread because something seems amiss.

  @florian_22 ,

My testing procedure was flawed yesterday. I'm now getting more consistent results...

Summary:

• "Guest Network" seems to be the only way to block traffic between peers on the same AP/Antenna (maybe just same AP).
  No amount of ACLing allowed me to replicate that part. If the traffic stays within the confines of the AP, that seems to be the only way that I found...
• As you (then me) found out, "Guest Network" blocks more than just traffic within the wireless network. By default, it only allows DHCP and Internet outbound traffic.
• The "Guest Network" blocking behavior can be overridden by AP ACLs but ONLY for traffic coming in and out of the AP.
  For example, I was able to allow ping and ssh from clients in other VLANs and also wired clients within my test VLAN.
• The "Guest Network" blocking behavior is stateless!
  In other words, when you enable some granular traffic to a host in the guest WLAN, you also need to allow the replies to flow back to their sources...
• My AP only supports 16 ACLs and you consume 2 per granular function enabled so choose carefully...

During my tests, I kept the Gateway ACL blocking all LAN->LAN traffic out of the isolated VLAN.

Test AP ACLs used:

For ping, allow ICMP from my entire private network (IP group) to the "guest" Network. Second rule with reverse source and destination.

For SSH, allow TCP from my entire private network (IP group) to SSH hosts in the "guest" Network (IP-Port group). Second rule with reverse source and destination.

I made at least couple mistakes yesterday. I got bit by the stateless nature of the "guest network" (didn't do enough to override).

I also had one test peer not behaving like the others because of a firewall rule not enabled...

If you have wired clients within your isolated network, you're likely to need switch ACLs (one to block traffic within the VLAN, pairs similar to the AP ACLs above to allow what you need).

HTH

  @EricPerl wow great, thanks a lot for your efforts. This seems to do the trick for me. Let's see when the AP ACL limit will block me. 

Hi Kris/ @KJK ,

I already had such rules because they were the fairly obvious way to replicate Guest Network functionality with AP ACLs.

But I was not 100% sure I retested them after I made my testing setup more reliable. So I just retested again.

Setup:

* TEST VLAN

* TEST SSID for the above VLAN

* 1 AP ACL for all protocols, source is SSID:Test, destination is IP Group:TEST VLAN subnet (also tried 10.0.0.0/8 for my entire internal network).

* 1 Windows machine over Wi-Fi

* 1 Linux machine, wired or Wi-Fi

I only have 1 TP-Link AP (EAP245) but if anything, it may expose something unexpected... Both machines on the same antenna/channel.

With the rule disabled, and both machines on Wi-Fi, ping works in both directions. All clear.

I enable the ACL. NOTHING happens. Ping still work. SSH too.

I switch the Linux box to wired only. Ping fails. SSH too. Both ways due to the stateless nature of AP ACLs. 

I disable the ACL. Ping & SSH work again.

My conclusion is that AP ACLs plain don't work as long as the traffic does not leave the confines of the AP...

They seem to apply when traffic comes in or goes out of the AP.

[Edit: Fortunately, this doesn't apply to inter-VLAN traffic, which clearly get pushed through switch (and likely GW) because a switch ACL can take care of that. Interestingly, the AP ACL extended to my full internal network also catches that, which aligns with my previous conclusion].

Is your experience different?