A history lesson...

2016

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

2017

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

2020

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

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

And now, we have EAP ACL with a big issue, not really a bug. Bringing back that Client Isolation would resolve the issue, right?

Hi @ikheetjeff 

ikheetjeff wrote

Hey,

 

@runner89 @Nlem @EricPerl Thank you for your input, I'm glad to read that I'm not the only one experiencing this.

 

@Clive_A  Thank you for your message, although I don't entirely agree with what you've said.

 

Indeed, I had lengthy contact with Myers via email, but the communication wasn't smooth. I had to explain the problem anew each time, and after a lot of times, you start to get tired of it. And after explaining it, I received responses like:

 

"Could you please try using the ping test command on your PC to test different SSID VLANs under the same EAP?"

 

When the problem clearly revolves around the same SSID with the same VLAN. Then I was asked to create two SSIDs with the same VLAN tag, and indeed the ACL works in that case. However, it's about only one SSID and the ACL on it.

 

As a final response, I received this:

"Sorry for the late reply. I am on a business trip now. As discussed, the design is such that for different devices under the same SSID, the data exchange between them will be forwarded directly by the AP, so it will not be affected by functions such as portal and ACL at this time. Our R&D colleagues are evaluating the performance of competing products, or can you tell us which product can meet this requirement?

In addition, your requirement is not complicated to implement. Why do you need to prevent devices on the same network segment from accessing each other? You can set a separate VLAN SSID for the printer on the controller (only effective on one EAP)."

 

So, this part in your reply:

"OP's reply did not mention what's been explained by the SE. That's very very very helpful information in explaining things on the forum here. He did not mention it and made it look like we sit back and do nothing. Yet, that's not the case. The SE has explained very clearly. Just simply ignored the fact that layer 2 and 3 matters in this whole thread."

 

Is not accurate. After weeks of difficult communication, during which I had to explain again every week and wrong suggestions were made each time, I gave up on it myself. You surely tried to solve this with good intentions, but it was certainly subpar.

 

But.. I found a solution by myself!
This problem bothered me so much that I put it on hold. Eventually, I revisited it recently, and what solves the problem: If you check "Guest Network" under WLAN, you can add "ACL Permit rules" under EAP ACL, which "override" that Guest Network setting. In my email communication, I repeatedly indicated that I thought Guest Network couldn't be overridden with ACL I was NEVER corrected on that.  (Even not in your reply!) You really missed an opportunity there and it shows that the support was unfortunately subpar.

 

For me, the problem seems to be solved now.

 

So, to summarize: an isolated WLAN can indeed be on one SSID, but you need to check Guest Network for that. Then, you can add permits under "EAP ACL". Isolating without Guest Network checked and with "Deny" EAP ACLs will not work. That's the whole point.

 

Point of attention
I also want to express that the tone of your message doesn't come across as entirely polite to me. (Maybe that's on me) I buy your products for 600+ euros, which is not insignificant. I ask for support politely, I give you time, I really don't expect miracles. But in the end, the support in the ticket was (in my opinion) poor, and since then I find TP-Link's support to be really lacking. I hope you can take this feedback into account.

"Since this is clear and has been explained, I will not further reply to anyone's comments on this part. ACL did not have a specific guide because it has tons of variations and you cannot list all of them."

It has never been explained properly by you/TP-Link. Unfortunately.

 

I'm trying to learn things, not to bother you. By helping each other, you also reach new customers, and I think that's what you want. By offering poor support, you don't invite (new) customers.

 

When I hadn't found the solution yet, I was really disappointed that I had bought your products. Now that I know the power of your products again, I'm enthusiastic once more. You can make a difference in this, because you should know your own products 100%.

 

Nevertheless, I still want to thank everyone!

I don't take replies from the EAP and I was replying to your thread out of curiosity to learn about the system and verify my knowledge on the layer 2 and layer 3. It seems to be the case from what I learned about the system and OSI.

So, I am not gonna reply to this anymore as it fits the design and the SE consulted your case with the dev and the reply was somehow the attitude of the dev. It fits the expectation of the EAP ACL.

This situation might be an issue where it fails to meet your expectations but it still fit the purpose of the product and design from the dev's eyes.

And I have my points on this layer thing and I am not persuaded by your statement yet because I see this issue from the layer thing instead of the result. Theoretically. This will only become an argument in persuading one of us to believe it is not a design issue and get it understood in OSI which I was told by many users on the forum that they are not interested in OSI discussion and learning about the system. It's not gonna be productive anyhow from our discussion. I already foresee the result of this conversation.

If it is a "design flaw" in your opinion, you give some examples of other vendors and @ the forum admin and get this passed to the dev and PM for evaluation.

(BTW, traditionally, all the products we have are targeting the vendors products. And we have studied what they do with their products. What they can do with this price tag. So, PM comes up with a product with the similar price tag but somehow better performance in some aspects.) 

If you want take this further, @ Hank and he'll follow this up. Let Hank take this further into discussion with the dev. Mostly, I play around and am familiar with the Switch and GW ACL which I have explained in the previous replies. You may try something else from that level and stop this instead of holding too many expectations on the EAP ACL which is half-crippled because most ACLs are done on the GW or SW. Not EAP.

Hi @runner89 

Thanks for posting in our business forum.

runner89 wrote

  @Clive_A I suspect the gap is that the SE is explaining stuff from an OSI perspective and OP (or at least me) have concerns from a security perspective.

 

I want to be able to isolate clients from each other. Whether clients connect through layer 2 or layer 3 doesn't really matter to me. That's just a way to think about networking. I want to address security.

 

I don't get to see the thread but when you say OP ignored the SE's explanation of OSI, I'm very sympathetic to OP. The SE is explaining how they implemented the network. The implementation doesn't have the desired security characteristics (isolation) because of that implementation. The SE's description isn't wrong but it's off topic and rightly ignored.

 

If OSI can't provide suitable security characteristics then you need to use a different implementation model. 

 

Said another way... I bought a device that I expected has suitable security characteristics. It doesn't. When a device changes EAPs its isolation changes which, from a security perspective, is bad. Talking about layer 2 and layer 3 won't convince me that it has good security characteristics -- it just doesn't matter to the security question.

 

But everything is based on a foundation of RFC and OSI.

You cannot ignore the layers 2 and 3. And when you plan and scheme the ACL, you should also think of it from layers 2 and 3 to make it proper. That's something you cannot ignore during the whole time.

I cannot recall what was the issue discussed here.

If necessary, you can start a new thread to iterate the expectations of your ACL. Just a brief review of the whole post, this just looks like a stateful ACL request. AP is not playing an serious and important role in routing and ACL. Consider the GW and SW ACL.

Update: I reviewed it and I think I have explained and pointed out the solution in the previous replies. This is not a problem with the EAP ACL which is limited. ACL is not something as simple as you think it is. IMPv4 ACL and GW ACL should be what you are looking for.