[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)

[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)
2023-09-16 02:14:18
Model: EAP653   EAP650  
Hardware Version: V1
Firmware Version: 1.0.9 Build 20230814 Rel. 36852)

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!

  3      
  3      
#1
Options
20 Reply
Re:[BUG/Issue] EAP ACL not functioning between wireless connections on the same EAP. (653, 650, 225)
2023-09-19 00:55:16

Hello @ikheetjeff,

 

Thanks for reporting this issue to TP-Link Business Community!

 

This issue has been reported to the engineer for further investigation. I'll try to provide an update when there's progress.

Best Regards! >> Omada EAP Firmware Trial Available Here << >> Get the Latest Omada SDN Controller Releases Here << *Try filtering posts on each forum by Label of [Early Access]*
  1  
  1  
#2
Options
Re:[BUG/Issue] EAP ACL not functioning between wireless connections on the same EAP. (653, 650, 225)
2023-09-19 00:59:27

Hank21 wrote

Hello @ikheetjeff,

 

Thanks for reporting this issue to TP-Link Business Community!

 

This issue has been reported to the engineer for further investigation. I'll try to provide an update when there's progress.

  @Hank21 Great, thank you! If you need more information on my side, i'm happy to assist.

  1  
  1  
#3
Options
Re:[BUG/Issue] EAP ACL not functioning between wireless connections on the same EAP. (653, 650, 225)
2023-09-19 09:36:11

Hi @ikheetjeff,

 

To better assist you, I've created a support ticket via your registered email address, and escalated it to our support engineer to look into the issue. The ticket ID is TKID230931967, please check your email box and ensure the support email is well received. Thanks!

Once the issue is addressed or resolved, welcome to update this topic thread with your solution to help others who may encounter the same issue as you did.

 

Many thanks for your great cooperation and patience!

Best Regards! >> Omada EAP Firmware Trial Available Here << >> Get the Latest Omada SDN Controller Releases Here << *Try filtering posts on each forum by Label of [Early Access]*
  0  
  0  
#4
Options
Re:[BUG/Issue] EAP ACL not functioning between wireless connections on the same EAP. (653, 650, 225)
2023-09-19 12:51:02

Hank21 wrote

Hi @ikheetjeff,

 

To better assist you, I've created a support ticket via your registered email address, and escalated it to our support engineer to look into the issue. The ticket ID is TKID230931967, please check your email box and ensure the support email is well received. Thanks!

Once the issue is addressed or resolved, welcome to update this topic thread with your solution to help others who may encounter the same issue as you did.

 

Many thanks for your great cooperation and patience!

@Hank21 Thank you very much! I've received the email and have already responded to a request for more information. I'm patiently awaiting further updates.

 

I wanted to mention that I really appreciate how seriously this is being taken. Thank you so much for that! I'll provide an update here when it becomes available. smiley

  0  
  0  
#5
Options
Re:[BUG/Issue] EAP ACL not functioning between wireless connections on the same EAP. (653, 650, 225)
2023-09-20 01:12:30 - last edited 2023-09-20 01:13:56

Hi @ikheetjeff

 

That's great! Please feel free to reply to the support email for further follow-up.

Best Regards! >> Omada EAP Firmware Trial Available Here << >> Get the Latest Omada SDN Controller Releases Here << *Try filtering posts on each forum by Label of [Early Access]*
  0  
  0  
#6
Options
Re:[BUG/Issue] EAP ACL not functioning between wireless connections on the same EAP. (653, 650, 225)
2023-10-19 10:11:59

After a few weeks of communication, the conclusion now is that this is "correct" according to TP-Link. So, it is supposed to be that the traffic on the same EAP does not go through the ACL rules. I find this personally strange.

 

I was asked if other network equipment has this capability; I don't know. If anyone can share information on this, it would be greatly appreciated. I myself believe that it is quite logical for EAP ACL rules to apply to the same EAP.

 

If anyone else would like to comment on this, I would appreciate the input. I think it would only help us move forward.

  4  
  4  
#7
Options
Re:[BUG/Issue] EAP ACL not functioning between wireless connections on the same EAP. (653, 650, 225)
2023-12-30 18:22:18

  @ikheetjeff I strongly agree, this is strange. It would make more sense for EAP ACL rules to apply to traffic between two wireless clients on the same EAP.

 

For example, under the current system, if a wireless client changes to the same SSID on a different EAP then the ACL behavior will change.

 

Another problem: There is no way to apply any ACL rules between two wireless clients on the same EAP. Such traffic is always wide open.

 

In my experiments, I'm seeing the same issues that you're having.

 

  4  
  4  
#8
Options
Re:[BUG/Issue] EAP ACL not functioning between wireless connections on the same EAP. (653, 650, 225)
2024-04-06 12:59:33 - last edited 2024-04-06 13:09:39

This makes no sense, gear in the "business networking" category like the EAP650 should really have a way to enable client isolation.

 

As it stands the only way to prevent wireless devices on the same VLAN from communicating with each other is by enabling the "guest network" mode on the AP. This might work for a small home network, but anything bigger than that will have some services to reach in a private subnet (DNS server, printer...) which "guest network" mode breaks since it drops ALL local traffic.

 

The EAP650 specification literally says it has "Wireless Isolation Between Clients" which is stretching the truth if that's meant to be the "guest network" mode.

  2  
  2  
#9
Options
Re:[BUG/Issue] EAP ACL not functioning between wireless connections on the same EAP. (653, 650, 225)
2024-04-30 00:09:20

  @ikheetjeff , @Hank21 

 

[Retyping my entire reply because the site managed to sign me off as I posted!!! Grrr!]

 

I came to report same issue (with a tweak) but found this thread and another pointing back to it as well.

I was helping another customer on another thread and ended up encountering this issue.

 

My testing reveals that the AP ACLs don't fire when the source and destination are on the same AP AND the same antenna AND the same SSID/VLAN.

 

I tested:

  • Same AP, same SSID/VLAN, different antenna
  • Same AP, same antenna, different SSID/VLAN
  • One wireless, One wired in the same VLAN

All these cases work as expected.

 

tp-link can rationalize this all they want, but in my opinion this is the kind of quirk that makes AP ACLs unreliable (in not unusable).

 

In my case, I thought at first they plain didn't work. I was trying to emulate "Guest Network" functionality with AP ACLs but nothing worked because my test clients were in the same AP/antenna case. I only have one AP and most of my clients support 5GHz (or I only had one antenna enabled). 

 

In other cases, I can imagine a network admin (home or samll business) setting up and testing AP ACLs, being satisfied with his setup, only to be defeated when 2 clients end up on the same AP/antenna... Similarly, the same admin enabling "Guest Network" and trying to override the behavior with ACLs could have some use cases fail randomly when it involves source and destination on the same AP/antenna.

 

In any case, I see no mention of this behavior in the Omada controller documentation.

If this behavior is by design, it would seem wise to advertize it accordingly, accompagnied by a BIG BOLD warning sign.

 

Sincerely 

  0  
  0  
#10
Options
Re:[BUG/Issue] EAP ACL not functioning between wireless connections on the same EAP. (653, 650, 225)
2024-04-30 08:47:21 - last edited 2024-04-30 08:54:10

Hi @EricPerl  @ikheetjeff  @Nlem @runner89 

 

ikheetjeff wrote

After a few weeks of communication, the conclusion now is that this is "correct" according to TP-Link. So, it is supposed to be that the traffic on the same EAP does not go through the ACL rules. I find this personally strange.

 

I was asked if other network equipment has this capability; I don't know. If anyone can share information on this, it would be greatly appreciated. I myself believe that it is quite logical for EAP ACL rules to apply to the same EAP.

 

If anyone else would like to comment on this, I would appreciate the input. I think it would only help us move forward.

So start with this, it is expected to be normal but the senior engineer did not give further explanation. I happened to be interested in the OSI model. Let's break this down from the OSI model.

Layer 2 and Layer 3. Right? You have configured the VLAN, so you have the VLAN ID for different SSIDs and that's what you showed to the SE.

 

I read through the whole dialogue and I was thinking the same thing as the SE. It's about layers 2 and 3.

ACL is effective only on the layer 3. Layer 2 is about the MAC address isolation. Which usually links ARP but ARP cannot be blocked for certainty.

 

OP said that he assumed that devices tested under the same VLAN should be isolated. This description is clearly wrong.

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.

 

Isolated the printer in its own VLAN, that's guest network. Or you have to configure many entries to stop this device from being accessed. There will not gonna be a single rule like when you set SRC "network A" to DST "network A" isolated. 

Try the switch MAC group and start this from layer 2. But that'll be a ton of entries.

 

In case you don't know, they are different types. There is also a thing called MAC address table and it is used for switching locally in the VLAN(layer 2). AP and Switch can traffic on layer 2 when it is under the same subnet(VLAN or broadcast range you may call that.)

*VLAN interface(layer 3)* which is what you see as "Network" in the SRC/DST in ACL.

 

So, basically, the SE had a conversation with the OP explaining how OSI and ACL work. Basically meets what I learned about networking. Expected. And we don't think or conclude this is an issue/bug.

What you are looking for is the IMPv4 ACL which is available in the standalone switch. If interested, take a look at the User Guide of the standalone switch. It combines layer 1 2 and 3 together and forms a more versatile ACL.

 

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.

Our valuable forum member @death_metal(not gonna @ and rag him into this mire, you can look at the switch/router ACL config he posted) has several guides on this. What you should learn is the OSI model when you study the ACL configuration. These terms and knowledge matter in this conversation and ACL config down the road.

As I have directed you the way about this, you can search online for related information and keywords. Good luck on this journey.

Best Regards! If you are new to the forum, please read: Howto - A Guide to Use Forum Effectively. Read Before You Post. Look for a model? Search your model NOW Official and Beta firmware. NEW features! Subscribe for the latest update!Download Beta Here☚ ☛ ★ Configuration Guide ★ ☚ ☛ ★ Knowledge Base ★ ☚ ☛ ★ Troubleshooting Manual ★ ☚ (Disclaimer: Short links are used above solely for guidance to TP-Link subdomains and are safe and tracker-free. Exercise caution with short links from non-official members on forums. We are not liable for external content or damage from non-official members' link use.)
  1  
  1  
#11
Options

Information

Helpful: 3

Views: 1868

Replies: 20

Related Articles