Traffic leaking between RADIUS dynamic VLANs: IPv6 RAs
Traffic leaking between RADIUS dynamic VLANs: IPv6 RAs
9 months ago, I reported a software bug. That thread got closed. That thread was not updated. Were you able to reproduce the issue? That thread does not list all models/versions affected. I am not asking whether that bug gets fixed in my V3. I am ready to upgrade to V4 if the issue was solved there. Alternatively, I am ready to upgrade to other models. However, I need some support on the current state of that bug report. And, I am happy to provide more details if the bug is not reproducible.
- Copy Link
- Subscribe
- Bookmark
- Report Inappropriate Content
Hi @CISTORop,
EAPs support multicast to unicast, please keep your all devices' firmware are the latest.
- Copy Link
- Report Inappropriate Content
@Hank21 I am sorry, I do not understand. Is there newer firmware for my EAP245 V3 or EAP620 HD V1? I was and I am not able to find that. Both products show no change with ‘multicast to unicast’ set, they still exhibit that issue. Which models/versions support that feature? Furthermore, has reproducing my report revealed that this setting/feature works around the issue?
- Copy Link
- Report Inappropriate Content
If there is another support channel, I should go for, please, say so. Learning how to deal with feature requests but also bug reports from the ‘field’, reported by users, could be the unique selling point for Omada series. As of today, I am still not sure whether my other thread was transformed into a bug report internally at all. If it was, which status does that have now, and which Omada models are consider to be fixed. I went for the latest Omada SDN controller 5.13.30.8, reset my devices to factory and re-adopted them, did not help. Such re-tests take time, making Omada more expensive than it should be. Then, I re-visited the thread about early-access firmware. For the EAP650, EAP655, and EAP670, it states, ‘Fixed abnormal IPv6 address acquisition for clients when enables Dynamic VLAN’. Again, I am just guessing, but that might relate to my bug report. Therefore, I went for a (not mentioned) EAP653. Not sure, why that model was not mentioned. And I am not sure why this bug fix was not found in the official release notes. Again failures, failures. But indeed, without fiddling around with the Multicast/Broadcast settings in the controller, the behavior of the EAP653 was different; IPv6 RAs from my router do not leak across VLANs. But in my last thread, IPv6 was just one example!
mDNS still leaks. Furthermore, I tested more than one Wi-Fi client connected to the same access point: All multicast/broadcast messages from one Wi-Fi client, although in a different VLANs, are sent to all other Wi-Fi clients. Again, I monitored via Wireshark: The client sends broadcast messages via PMK, and the access point re-sends them via GTK. Consequently, Omada does not isolate the different VLANs. The latter could be worked around with Client Isolation or, as TP-Link called it, ‘SSID isolation,’ enabled on each access point. However, that is just a workaround because then members of the same VLAN cannot talk to each other either. Furthermore, TP-Link enhanced that feature into Guest Network, blocking Wi-Fi clients from private IP addresses, too. But I do not need/want that.
Long story short, RADIUS dynamic VLAN is still broken in the world of Omada. For example, a bad Wi-Fi client in a guest network is able to send IPv6 RAs himself, tearing down IPv6 connectivity for all Wi-Fi clients, even those in different VLANs. Consequently, the team who added Dynamic VLAN did neither implement nor test correctly. Consequently, the one who tackled my bug report just focused on the example and did not understand the broader picture. I am not sure, whether giving that team this bug report again would be a good idea. Again, the solution is quite easy as you just have to monitor Wi-Fi on the air layer with the help of the PMK, and then copy the behavior of Cisco, UniFi, or MikroTik.
- Copy Link
- Report Inappropriate Content
Hi @CISTORop
Thanks for posting in our business forum.
CISTORop wrote
If there is another support channel, I should go for, please, say so. Learning how to deal with feature requests but also bug reports from the ‘field’, reported by users, could be the unique selling point for Omada series. As of today, I am still not sure whether my other thread was transformed into a bug report internally at all. If it was, which status does that have now, and which Omada models are consider to be fixed. I went for the latest Omada SDN controller 5.13.30.8, reset my devices to factory and re-adopted them, did not help. Such re-tests take time, making Omada more expensive than it should be. Then, I re-visited the thread about early-access firmware. For the EAP650, EAP655, and EAP670, it states, ‘Fixed abnormal IPv6 address acquisition for clients when enables Dynamic VLAN’. Again, I am just guessing, but that might relate to my bug report. Therefore, I went for a (not mentioned) EAP653. Not sure, why that model was not mentioned. And I am not sure why this bug fix was not found in the official release notes. Again failures, failures. But indeed, without fiddling around with the Multicast/Broadcast settings in the controller, the behavior of the EAP653 was different; IPv6 RAs from my router do not leak across VLANs. But in my last thread, IPv6 was just one example!
mDNS still leaks. Furthermore, I tested more than one Wi-Fi client connected to the same access point: All multicast/broadcast messages from one Wi-Fi client, although in a different VLANs, are sent to all other Wi-Fi clients. Again, I monitored via Wireshark: The client sends broadcast messages via PMK, and the access point re-sends them via GTK. Consequently, Omada does not isolate the different VLANs. The latter could be worked around with Client Isolation or, as TP-Link called it, ‘SSID isolation,’ enabled on each access point. However, that is just a workaround because then members of the same VLAN cannot talk to each other either. Furthermore, TP-Link enhanced that feature into Guest Network, blocking Wi-Fi clients from private IP addresses, too. But I do not need/want that.
Long story short, RADIUS dynamic VLAN is still broken in the world of Omada. For example, a bad Wi-Fi client in a guest network is able to send IPv6 RAs himself, tearing down IPv6 connectivity for all Wi-Fi clients, even those in different VLANs. Consequently, the team who added Dynamic VLAN did neither implement nor test correctly. Consequently, the one who tackled my bug report just focused on the example and did not understand the broader picture. I am not sure, whether giving that team this bug report again would be a good idea. Again, the solution is quite easy as you just have to monitor Wi-Fi on the air layer with the help of the PMK, and then copy the behavior of Cisco, UniFi, or MikroTik.
Since my associate left, I have taken over this temporarily and I am new to this issue. There was an email forwarded to me about your issue.
As instructed, here's the download link I need to share with you and you can take a look.
EAP245_v3.0_5.1.90_build20240305_rel60554
Let me know if this resolves your issue or not.
- Copy Link
- Report Inappropriate Content
With the new firmware 5.1.90, behaves like EAP653 now: IPv6 does not leak. Multicast/Broadcast originating at the Wi-Fi client like mDNS and DHCP leak.
- Copy Link
- Report Inappropriate Content
Hi @CISTORop
Thanks for posting in our business forum.
CISTORop wrote
With the new firmware 5.1.90, behaves like EAP653 now: IPv6 does not leak. Multicast/Broadcast originating at the Wi-Fi client like mDNS and DHCP leak.
mDNS and DHCP are expected. The firmware has fixed the reported issue and the other aspects you proposed do not compose an issue.
mDNS packets will influence the Apple Bonjour Service, as a result, someone using Airprint ® or screen sharing would not be able to use them after we stop the mDNS transition in different VLANs.
- Copy Link
- Report Inappropriate Content
What is the device you are using that is experiencing the leaking? Model & version. Had a very similar issue on EAP610, EAP650, EAP653, and EAP655-Wall. It was resolved by a beta firmware that has not been released publicly.
If we can highlight another device with the same issue it adds more attention for TP-Link to fix the issue permanently.
B
- Copy Link
- Report Inappropriate Content
I don't know what I shall say. How do you come to that conclusion? Again, DHCP is just an example. The whole concept of how to deal with multicast/broadcast (from client devices and from the router) in case of dynamically assigned VLANs is broken. GTK is misused currently. Each VLAN must be isolated. The current situation creates the wildest issues, explained in the source cited in my previous thread, years ago. Therefore, I invite @MikeSchnagli @StevieDuk @Nitin-Lohchab @pokhui @TomasAAA @Christian2705 @bky @Oliv2831 @MatthiasL22 @Holl595 @Yttra @sonaric @MR.S @mtl_squirrel because they reported to use Dynamic VLAN Assignment. @4uba @Eguliker @Ofloo @mobb @NickyV @0llli @mtpi @maresu @bolhaskutya @Kamal9 intended to use Dynamic VLAN Assignment. Hopefully, you are still with Omada, using Dynamic VLAN, and noticed my reported issue. Perhaps you can explain/convince TP-Link, which I cannot.
- EAP653 V1 1.0.12 Build 20240131
- EAP620 V1 1.1.0 Build 20230303
- EAP245 V3 5.1.90 Build 20240305
Do you have a newer release on your EAP653?
- Copy Link
- Report Inappropriate Content
Hi @CISTORop
CISTORop wrote
I don't know what I shall say. How do you come to that conclusion? Again, DHCP is just an example. The whole concept of how to deal with multicast/broadcast (from client devices and from the router) in case of dynamically assigned VLANs is broken. GTK is misused currently. Each VLAN must be isolated. The current situation creates the wildest issues, explained in the source cited in my previous thread, years ago. Therefore, I invite @MikeSchnagli @StevieDuk @Nitin-Lohchab @pokhui @TomasAAA @Christian2705 @bky @Oliv2831 @MatthiasL22 @Holl595 @Yttra @sonaric @MR.S @mtl_squirrel because they reported to use Dynamic VLAN Assignment. @4uba @Eguliker @Ofloo @mobb @NickyV @0llli @mtpi @maresu @bolhaskutya @Kamal9 intended to use Dynamic VLAN Assignment. Hopefully, you are still with Omada, using Dynamic VLAN, and noticed my reported issue. Perhaps you can explain/convince TP-Link, which I cannot.
- EAP653 V1 1.0.12 Build 20240131
- EAP620 V1 1.1.0 Build 20230303
- EAP245 V3 5.1.90 Build 20240305
Do you have a newer release on your EAP653?
Your last reply about mDNS and DHCP was read by the dev and it is not something useful and fruitful.
If you want to continue this conversation with me, please show the test method, topology of your test environment and Wireshark result.
I will check if is expected or not and if it is logical and will get the dev to read through your test methodology as well.
So far, you just say mDNS does not make sense. DHCP is leaking, how do you test it out? DHCP's first query is broadcasting. Do you think the broadcast is leaking? I don't think this will be a dialectic and logical way to discuss.
I only take concrete evidence and a dialectic way to illustrate an issue. Please, please reply with some other concrete information as we go further into this conversation.
- Copy Link
- Report Inappropriate Content
- Copy Link
- Report Inappropriate Content
Information
Helpful: 0
Views: 1028
Replies: 12
Voters 0
No one has voted for it yet.