[BUG/Issue] EAP ACL not functioning between wireless connections on the same EAP. (653, 650, 225)
[BUG/Issue] EAP ACL not functioning between wireless connections on the same EAP. (653, 650, 225)
Hello,
After 4 full days of trying and encountering issues every time, it seems there is a bug in the EAPs when combined with EAP ACL rules.
Hardware setup:
- ER605 v2.0 (Firmware Version: 2.1.4 Build 20230727 Rel.40308)
- OC200 1.0 (Controller Version: 5.12.9) (Firmware Version: 1.26.3 Build 20230906 Rel.36269)
- TL-SG2008P v3.0 (Firmware Version: 3.0.5 Build 20230602 Rel.73473)
- TL-SG2008P v3.0 (Firmware Version 3.0.5 Build 20230602 Rel.73473)
- EAP225(EU) v3.0 ( 5.1.0 Build 20220926 Rel. 62456)
- EAP653(EU) v1.0 (1.0.9 Build 20230814 Rel. 36852)
- EAP650(EU) v1.0 (1.0.10 Build 20230814 Rel. 36852)
- EAP653(EU) v1.0 (1.0.9 Build 20230814 Rel. 36852)
My problem:
I want to connect my printers via Wi-Fi to an isolated VLAN. The printer should not be discoverable/usable in the isolated VLAN but should be accessible from another (trusted) VLAN. Unfortunately, this is not working with the "Guest Network" function in the WLAN settings because it makes the printer inaccessible from any other VLAN as well. That's why I'm trying to achieve this with ACL rules.
After much experimentation with Gateway ACL & Switch ACL, I finally realized that traffic between wireless devices doesn't pass through the Switch/Gateway (ACL) but is instead routed through the EAP to the other wireless client. Therefore, I attempted to make the other devices unreachable using EAP ACL rules. I succeeded with these ACL rules:
Furthermore, the rules for both Gateway ACL and Switch ACL are currently empty. The outcome of these rules when I connect with my iPhone to the "Isolated" WiFi network is this scan:
I was thrilled when I saw this! Finally, but then a few hours later, it stopped working altogether. I was going crazy! After a lot of investigation and trial and error, I discovered that my printer and/or I occasionally connect to a different access point (AP). When I tested that, I noticed an issue.
Because when I connect with my iPhone to the same EAP, to which the Canon printer is also connected, all EAP rules no longer "work". Then, suddenly, my result is this:
It appears there is an issue with ACL rules not being processed correctly for users in the same EAP. Is this expected behavior? If so, how can I prevent this from happening?
I have tried the following:
- This issue was present in the latest firmware as well as the beta firmware.
- I have tested each EAP separately, and each EAP exhibits this issue.
- The problem persists even after a restart.
- Even when I block the network in the Gateway/Switch ACL, the issue remains.
- I have also tried resetting everything to factory defaults, but the problem persists.
Additional question:
Furthermore, I am still looking for a way to block the "Bonjour" service using ACL. I want to ensure that Bonjour does not work in my Isolated VLAN but does work in the trusted VLAN where the printer can be found using mDNS. Does anyone have any tips for this?
Currently, the iPhone can discover the printer, but due to the other restrictions in place, it cannot print anything.
I hope you can assist me further. Even if it turns out to be a configuration error rather than a bug, I would appreciate guidance on how to resolve it.
I have also tried to provide as much useful information as possible without including unnecessary details. If anything is missing, please let me know, and I'll be happy to provide any additional information you need.
Thank you very much for your help and support!
- Copy Link
- Subscribe
- Bookmark
- Report Inappropriate Content
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!
- Copy Link
- Report Inappropriate Content
@Clive_A the explanation about layer 2 vs layer 3 misses the point entirely. Filtering intra-vlan traffic (layer 2) using IP addresses (layer 3) is a thing that is commonly done. See this StackExchange question for a description of doing that using another manufacturer's equipment.
The most surprising part is that this kind of filtering works perfectly in TP-Link switches, it also works between TP-Link EAPs, and as another commenter pointed out it even works within the same EAP if different radios are being used. Why doesn't it work within the same radio? This clearly looks like a bug.
@ikheetjeff I am glad you found a solution, however judging by the support's responses it seems to only work by accident. I would be worried to rely on it as the subtle interactions between the guest network feature and ACLs don't appear clear to anyone and as such may go away silently in a firmware update.
- Copy Link
- Report Inappropriate Content
Nlem wrote
@ikheetjeff I am glad you found a solution, however judging by the support's responses it seems to only work by accident. I would be worried to rely on it as the subtle interactions between the guest network feature and ACLs don't appear clear to anyone and as such may go away silently in a firmware update.
@Nlem Thanks! I hadn't looked at it that way before. I'm definitely going to keep an eye on that. Thank you.
- Copy Link
- Report Inappropriate Content
I reached similar conclusions to yours in this thread:
https://community.tp-link.com/en/business/forum/topic/603136?replyId=1352944
Note that overriding Guest with allow rules only works if source and destination are NOT on the same AP/Antenna/SSID.
I suspect that's a corollary to deny rules not working under the same constraint.
If the AP can handle traffic, deny AP ACLs are ignored.
If the AP can handle traffic and Guest says to throw it away, allow AP ACLs are ignored too.
FWIW, while I was retesting some of this, one of my peers downgraded to 2.4GHz and all rules fired again. It was so confused for a few minutes.
I resorted to only enabling 5GHz on the TEST SSID...
- Copy Link
- Report Inappropriate Content
@Clive_A ,
I was mostly after documentation of that behavior in the controller docs about AP ACLs.
AP ACLs are ineffective when source and destination share AP/Antenna/SSID.
Deny rules don't apply if the AP can handle traffic on its own.
Allow rules to override Guest behavior don't apply either in the same case.
The fact that the antenna comes into play is probably what baffled me the most.
That looks like Layer 1 to me but I'm not a network engineer (and neither are many of your customers).
- Copy Link
- Report Inappropriate Content
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?
- Copy Link
- Report Inappropriate Content
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.
- Copy Link
- Report Inappropriate Content
Information
Helpful: 3
Views: 1521
Replies: 17
Voters 2
