How to block multicast DNS traffic (mDNS) on an AP230 between wireless Clients via the user profile based traffic filters?

[andreas_brueck]

Hello everybody,

i have some trouble to block multicast DNS traffic (mDNS) between wireless clients via the user profile based traffic filters.

We are using at our university the on-premises Hivemanager NG (build version 12.8.1.2-NGVAMAY18 ) and about four hundred AP230 (HiveOS 8.3r4 Mayberry build-195604 ). The problem is, that we have a high amount of mDNS multicast traffic, which we want to block directly on the APs. I tried the following things, but with no success:

• IP-filter (inbound & outbound): any (Service) any (source-ip) 224.0.0.251 (destination-ip) deny (action) dropped packets (logging)
• IP-filter (inbound & outbound): MDNS (Service) any (source-ip) any (destination-ip) deny (action) dropped packets (logging)
• MAC-filter (inbound & outbound): any (source-mac) 01005e0000fb (destination-mac) deny (action) dropped packets (logging)

The mDNS traffic still reach all wireless clients. I also tried to disable the function "Enable inter-station traffic" with no success. If i defined a ip filter to block Netflix, it worked fine. There are also no log entries on the access points about dropped packets (with the exception of the Netflix traffic).

How i can block mDNS traffic on the access points? Are there any mistakes at my configuration? I hope you can help me with your knowledge 🙂

Regards,

Andreas

[andreas_brueck]

To block IPv6-mDNS multicast traffic i defined a service which drop packets directed to udp port 5353 and put this entry as the first acl entry. I think it is also possible to use the predefined MDNS service, but i didn't test it anymore.

[andreas_brueck]

I have good news. We have a firewall list with about 40 entries. I added the rule...

• IP-filter (inbound & outbound): any (Service) any (source-ip) 224.0.0.0 /24 (destination-ip) deny (action) dropped packets (logging)

now as the first entry and not as the last. Now it works! But i do not understand why? The other rules was just deny rules, which specifies services like Netflix and other streaming services (see figure 1) and the default policy is set to permit. Has anyone a idea?

[andreas_brueck]

Hello Keith,

thanks you very much for your help. I tried all your suggestions, but sadly with no success:

1. The APs are all configured with enabled DFS and 40 MHz channels, but i do not understand why it is important in reference to mDNS-traffic? In my opinion the problem is independent from the physical layer.
2. I uncheck the option "enable inter-station traffic" for the SSID and also added the user based ip firewall to drop traffic between stations, but with no success to block mDNS traffic (other traffic will be blocked successfully). What is the difference between this two options?
3. Additionally you wrote me to block also the multicast address 224.0.0.250, but this also does not block the mDNS traffic. I also tried to block the whole local multicast subnet 224.0.0.0 /24, with no success.

Do you have any other ideas? I do not understand why the blocking for multicast addresses is not working. Is there a special reason for this?

Regards,

Andreas

[weekdaysailor]

Actually, stumbled on this KB article which although centered on Chromebooks, has the following:

1. Enable DFS and 40. MHz channels on 5Ghz spectrum (802.11a/n and 802.11a/n/ac) (see Figure 1a & 1b)
2. We have two options to prevent mDNS requests from reaching other clients and thus preventing mDNS responses, one at the SSID level and one in the User Profile.
   1. SSID Level - disable inter-station traffic at SSID that chrome books are connecting to (see figure 2.1). This option allows us to prove more channel width, which allows devices to send at higher data rates and save airtime.
   2. User Profile - Define User Based IP Firewall to drop traffic between stations and assign to User Profile (see figure 2.2). This option will block mDNS requests from being received by other chrome books. This will prevent the sending of mDNS responses, which will in turn prevent the p2p updates, and will make sure the Chromebooks revert back to client-server updates instead. (source: https://groups.google.com/forum/#!topic/google-chrome-anz-education/8UBDPTJqpWk) 
   3.  

The article implies simple ACLs such as you are trying will block multicast as well.

Also lots of reports of recent bugs in Google/Android apps re MDNS which may be causing storming.