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
Like @Yttra replying since I was tagged (I only check these forums occasionally). My two Omada sites are using EAP670s and EAP650-Outdoor units, Omada switches, and SuperMicro systems running OPNsense BE for routing/firewall/network services. Both use PPSKs for dynamic VLAN assignment. I use the mDNS Repeater plugin for multicast proxy between VLANs, along with appropriate firewall rules. I do not use switch L3 features at either site right now. All internal addressing is IPv4.
I don't have the time budget right now to dig into this, so I can't provide direct useful testing. That said this response by @Clive_A was a little confusing:
Clive_A wrote
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.
That definitely does not sound like expected behavior, including in Omada. I expect everything between VLANs, including all Bonjour services, to be fully isolated by default as if they were on a physically different LAN unless I explicitly bridge them. That's the entire point, it's a "virtual LAN". I may want a given printer, speaker or whatever on one VLAN only available to select others (or indeed select clients on others), or not at all. The point of mDNS Repeaters is to bridge multicast across L3, and firewall rules. And indeed Omada itself includes this capability, that's the point of Services > mDNS right? Under no circumstances should WAPs decide to just go around that. If Omada WAPs were deciding on their own to just share multicast traffic between VLANs even without any explicit mDNS rule I'd consider that a pretty significant security bug and violation of expectations.
I'd certainly want verify that's exactly what's happening with a clean minimal setup, fresh controller, etc. But yeah, mDNS absolutely should not cross subnets by all by itself.
- Copy Link
- Report Inappropriate Content
Hi @sonaric
Thanks for posting in our business forum.
sonaric wrote
Like @Yttra replying since I was tagged (I only check these forums occasionally). My two Omada sites are using EAP670s and EAP650-Outdoor units, Omada switches, and SuperMicro systems running OPNsense BE for routing/firewall/network services. Both use PPSKs for dynamic VLAN assignment. I use the mDNS Repeater plugin for multicast proxy between VLANs, along with appropriate firewall rules. I do not use switch L3 features at either site right now. All internal addressing is IPv4.
I don't have the time budget right now to dig into this, so I can't provide direct useful testing. That said this response by @Clive_A was a little confusing:
Clive_A wrote
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.
That definitely does not sound like expected behavior, including in Omada. I expect everything between VLANs, including all Bonjour services, to be fully isolated by default as if they were on a physically different LAN unless I explicitly bridge them. That's the entire point, it's a "virtual LAN". I may want a given printer, speaker or whatever on one VLAN only available to select others (or indeed select clients on others), or not at all. The point of mDNS Repeaters is to bridge multicast across L3, and firewall rules. And indeed Omada itself includes this capability, that's the point of Services > mDNS right? Under no circumstances should WAPs decide to just go around that. If Omada WAPs were deciding on their own to just share multicast traffic between VLANs even without any explicit mDNS rule I'd consider that a pretty significant security bug and violation of expectations.
I'd certainly want verify that's exactly what's happening with a clean minimal setup, fresh controller, etc. But yeah, mDNS absolutely should not cross subnets by all by itself.
Correct about the highlight part.
I am waiting to see any test results from him or you if you can provide them. Without configuring the mDNS on the router/AP, it leaks. I hope to see further details on this if there are any.
mDNS is supposed to be broadcast if configured between the designated VLANs.
This is the basis of the comment which I did not bring up. I did not consider the PMK and GTK as I haven't handled cases in Controller and AP in recent days.
I did not read his comment meticulously. But the dev read that and informed me that these are expected in his scenario which might be under the context of PMK and GTK situation.
I will get @Hank21 to follow up this next week if there are any test results with a diagram.
- Copy Link
- Report Inappropriate Content
Information
Helpful: 0
Views: 1066
Replies: 12
Voters 0
No one has voted for it yet.