NWA50AX filtering / blocking Multicast (mDNS) traffic?

Zyxel_Judy

Hi @TomAP ,

When we captured packets on wlan-2-1.1, the results were identical to those from eth0, as shown in the packet capture, we shared with you previously in the private message.

We also noticed that you captured packets on wlan-2-1 rather than wlan-2-1.1. Could you please try capturing packets on wlan-2-1.1 again to confirm the results?

By the way, please capture packets on the WiFi interface of your laptop when connected to the NWA50AX during periods of mDNS traffic on your network. This will help us confirm whether mDNS traffic is properly reaching the wireless device.

Additionally, are you experiencing any service impacts or functionality issues related to mDNS in your network?

forfrossen

Hi all,

i just ran into the same wall. Or better was able to identify that I ran into THIS wall. After months of problems with my phone in my wifi after aquiring a new Zyxel AP and constant Half-Dropouts I found out it's multicast-to-unicast (DMO) that causes IPv6 ICMPv6 Router Advertisements sent to the all-nodes multicast address ff02::1 to not be delivered to wireless clients. The reason why the captured packets still sees them, is that DMO runs AFTER the trace.

The following is written by Claude, I hope it helps someone or even gets Zyxel to FIX THIS!

Summary

With multicast-to-unicast (DMO) enabled, IPv6 ICMPv6 Router Advertisements sent to the all-nodes multicast address ff02::1 are not delivered to wireless clients. All-nodes (ff02::1) is never joined via MLD, so the DMO/multicast-to-unicast logic has no membership entry for it and drops/mishandles those frames. Affected clients therefore receive no periodic RA refresh; their IPv6 default route expires when its Router Lifetime elapses, and they fall back to IPv4-only until they reconnect.

Impact

Intermittent total loss of IPv6 internet for Wi-Fi clients — recurring roughly every ~30 minutes (= the RA Router Lifetime), while IPv4 is unaffected. Clients that do not periodically re-solicit are hit hardest: e.g. an Android phone that sends zero Router Solicitations once associated depends entirely on the unsolicited multicast RA refresh that DMO drops, so it loses IPv6 every ~30 min.

Root-cause proof (A/B test performed on this AP)

DMO ENABLED (default): a client went >2 hours with zero RAs received — verified on the client (Android APF: RA … Last seen 7061s ago; ip -6 route: IPv6 default route absent on Wi-Fi) — even though the LAN's IPv6 router was sending multicast RAs to ff02::1 every ~46 seconds the entire time (verified by packet capture on the router's LAN, on the AP's wired interface, and on the AP's BSS interface).

AP packet-trace on the client's 5 GHz BSS: the RA is present on wlan-2-1 as multicast (fe80::… > ff02::1: router advertisement, router lifetime 1800s) — i.e. the frame reaches the AP and is dropped/not-delivered in the DMO/TX path, not upstream.

DMO DISABLED via CLI:

configure
wlan-radio-profile RADIO_SETTING_TYPE_6
no multicast-to-unicast
exit

→ the client immediately began receiving the RAs every ~40 seconds; its IPv6 default-route Router Lifetime perpetually refreshed (::/0 … proto ra … expires reset near 1800s across a 95 s window, never decaying to expiry); the client then held **full IPv6 connectivity continuously for

1 hour** (previously it failed every ~30 min). Only multicast-to-unicast was changed.

The problem we need Zyxel to fix

multicast-to-unicast is not exposed anywhere in the Nebula Control Center cloud UI for access points (it appears only for switches, per port). CLI changes on a Nebula-managed AP are not persistent — they revert on the next cloud sync or on reboot. So there is currently no supported way to disable this setting or to persist the working configuration.

Requested resolution (any one is acceptable)

1. Expose a per-SSID or per-radio "Multicast-to-Unicast / DMO" toggle for APs in the Nebula Control Center; or
2. Firmware fix: exclude IPv6 ND control multicast — at minimum ff02::1 (all-nodes) and ff02::2 (all-routers), ideally all link-local ND — from the multicast-to-unicast / drop logic, so Router Advertisements are always delivered; or
3. Provide a supported method to persist no multicast-to-unicast on a Nebula-managed AP.

forfrossen

Summary

With multicast-to-unicast (DMO) enabled, IPv6 ICMPv6 Router Advertisements sent to the all-nodes multicast address ff02::1 are not delivered to wireless clients. All-nodes (ff02::1) is never joined via MLD, so the DMO/multicast-to-unicast logic has no membership entry for it and drops/mishandles those frames. Affected clients therefore receive no periodic RA refresh; their IPv6 default route expires when its Router Lifetime elapses, and they fall back to IPv4-only until they reconnect.

Impact

Intermittent total loss of IPv6 internet for Wi-Fi clients — recurring roughly every ~30 minutes (= the RA Router Lifetime), while IPv4 is unaffected. Clients that do not periodically re-solicit are hit hardest: e.g. an Android phone that sends zero Router Solicitations once associated depends entirely on the unsolicited multicast RA refresh that DMO drops, so it loses IPv6 every ~30 min.

Root-cause proof (A/B test performed on this AP)

DMO ENABLED (default): a client went >2 hours with zero RAs received — verified on the client (Android APF: RA … Last seen 7061s ago; ip -6 route: IPv6 default route absent on Wi-Fi) — even though the LAN's IPv6 router was sending multicast RAs to ff02::1 every ~46 seconds the entire time (verified by packet capture on the router's LAN, on the AP's wired interface, and on the AP's BSS interface).

AP packet-trace on the client's 5 GHz BSS: the RA is present on wlan-2-1 as multicast (fe80::… > ff02::1: router advertisement, router lifetime 1800s) — i.e. the frame reaches the AP and is dropped/not-delivered in the DMO/TX path, not upstream.

DMO DISABLED via CLI:

configure
wlan-radio-profile RADIO_SETTING_TYPE_6
no multicast-to-unicast
exit

→ the client immediately began receiving the RAs every ~40 seconds; its IPv6 default-route Router Lifetime perpetually refreshed (::/0 … proto ra … expires reset near 1800s across a 95 s window, never decaying to expiry); the client then held **full IPv6 connectivity continuously for

1 hour** (previously it failed every ~30 min). Only multicast-to-unicast was changed.

The problem we need Zyxel to fix

multicast-to-unicast is not exposed anywhere in the Nebula Control Center cloud UI for access points (it appears only for switches, per port). CLI changes on a Nebula-managed AP are not persistent — they revert on the next cloud sync or on reboot. So there is currently no supported way to disable this setting or to persist the working configuration.

Requested resolution (any one is acceptable)

1. Expose a per-SSID or per-radio "Multicast-to-Unicast / DMO" toggle for APs in the Nebula Control Center; or
2. Firmware fix: exclude IPv6 ND control multicast — at minimum ff02::1 (all-nodes) and ff02::2 (all-routers), ideally all link-local ND — from the multicast-to-unicast / drop logic, so Router Advertisements are always delivered; or
3. Provide a supported method to persist no multicast-to-unicast on a Nebula-managed AP.

Zyxel_Judy

Hi @forfrossen ,

Following your description, we conducted a local test using a Windows laptop. When the Multicast t0 Unicast is enable as default, over a 30-minute period, the laptop continued to receive RA packets.

Could you please help verify whether this issue is specific to phones only?

Zyxel_Judy

Hi there,

Some operating systems or Wi-Fi drivers, such as some Android phones, may handle converted multicast traffic differently, which could affect whether the Router Advertisement packets are accepted and processed correctly.

Regarding to Multicast-to-Unicast setting, we also understand that you have adjusted this setting through the CLI. Please note that this CLI configuration can remain in effect as long as no related configuration is pushed from Nebula CC. If the corresponding wireless settings are subsequently modified in Nebula and synchronized to the AP, the CLI setting may be overwritten by the cloud configuration. In case you would like to change Multicast-to-Unicast setting for any reason, you may consider using the AP in standalone mode as current solution.