Hi  @KJK ,

Thanks for confirming the behavior.

I'll start a new thread to get the attention of tp-link's staff...

  @KJK 

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.

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.

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. 

  @EricPerl 

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.

@KJK  and  @EricPerl 

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!

  @Death_Metal ,

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:

1. 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)

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