MDNS flooding by Bonjour
-
I noticed that the continuous and repeated blocks of my network with 4 AP behind PFSense are due to Apple
Bonjour discovery service. When an Iphone or iPad are connecting to the network the blocks are starting, caused by the flooding of mDNS packets.
I tried to block UDP port 5353 and install Avahi, but this not solve.
Does anyone know how to solve or suggest me?
thanks -
What blocks are you talking about - can you post a pic of your log showing what your wanting to block - sounds like blocked already if your seeing it in the log ;)
I have 2 iphones and Ipad that connect to my network - I don't see any blocks?
Could you also post your interface rules where where these devices are connected.
-
That's a screenshot of a capture on PfSense LAN interface.
You can see the flooding of mDNS packets coming from Apple devices, this cause the block of my whole network.
-
That's the rules on LAN interface
-
ok your rules are redundant, the top rule says only tcp/udp - but its pointless since the last rule is any. Same for the icmp rule - you have a any rule.. Those other allow rules are pointless
That is ipv6 - are you using ipv6? What rule is blocking them - the default rule? If so you could turn logging that off - system logs, settings tab. You could allow ipv6 in advanced, network. You could put in a rule to block it but not log based up that multicast dest IP. You could figure out why its asking or what its asking and get it to stop. Seems to be doing it quite a bit. From the sniff it looks to be all coming from the same device - disable ipv6 on the thing if your not using it as another option to remove that noise.
I would look to what it looking for and figure out why its looking so often as the better approach.
But lets be clear unless allowed its block - these are the default rules. So asking to block that is pointless, its in the logs because its block.. So you want to NOT LOG it is your actual question? Or make it stop sending the traffic.. Or do you want a rule to allow/blocked it so its not logged?
-
Thanks,
I've deleted the pointless rules and I've disallowed IPv6 because it was turned on.
I want that this service,Apple Bonjour, doesn't flood my network with his mDNS packets.
I've noticed that not only one Apple device cause this but more than one, but not all.Some example link of the problem as follow:
http://www.cepro.com/article/how_apples_bonjour_networking_standard_affects_installs/
http://www.networkworld.com/article/2161302/lan-wan/apple-seeks-standard-to-appease-angry-university-net-managers.html
-
Where did you disallow ipv6?
So multicast is not going to go across segments. Do you have a switch that supports igmp snooping? You could use that to block such traffic at layer 2 from being seen by other devices on that segment. But ffx2::/16 can not be routed. So your not going to flood other segments.. Isolate the bad boxes to their own segment would be another option ;)
But again best to fix such traffic at the source.. Are these computers running OS X, or like ipad or iphones or some other type appliance? You can tweak bonjour if os x - but if some other devices nothing you can do - I have some dvrs that send out a few packets looking for something they will never find.. I just told the switch not to pass it on via igmp snooping. And they are on a isolated segment anyway.
-
I disallow IPv6 in PfSense Advanced-Networking.
Being essentially a wireless network with 4 SSID the problem is caused by iPhone and or iPad.
I have a Cisco switch available with IGMP snooping support, I'll try to use this feature.Don't routing setting of ffx2::/16 is correct in the image attached?
-
why would you create that route?? ffx2::/16 is not routable, why would you route it to null? If you have a cisco switch you should also be able to block ipv6 with an acl on the interfaces you want to block it.. For example the port your AP are connected too.
When you disallow ipv6 - then yes all ipv6 traffic would be blocked, and show up in the logs. I don't believe ios devices have a way of to disable ipv6 - I don't agree with it, no matter how much everyone wants ipv6 to be used - there are many networks where its not ready yet. Every OS should have the ability to disable it.
Still a bit confused - are you worried about the flooding, or that its cluttering up your pfsense logs? Nothing you can do at pfsense is going to stop the traffic from flooding the network, that would have to be done at the source or at the port on the switch where the traffic enters - it is ipv6 multicast, so on your switch you can block multicast or ipv6 at the enter point of the switch.
If your just worried about the logging, then you can set it up not be logged, or just allow it so it wont be logged - pfsense is not going to do anything with that traffic - so if you allow it - it wouldn't show up in the default block log.
What AP do you have - you could maybe block it there as well.
-
What do you mean with Logging?
I'm not worried in cluttering pfsense logs, I'm worried because my network is flooded by this traffic.
Next thing to do it's try to study the cisco switch. -
Ok - so you need to stop it at the source, or where that source enters the network if you don't want it flooding that L2 network. So at your switch where the wireless AP connect to the network, or the AP itself - or setting on the device themselves.
-
Hi John, your approach is correct: the problem must be stopped at the origin, denying the use of Apple products into the company, or controlling packets at AP level, or controlling at switch level with right rules. I think that this storm into medium size networking should be known at Cupertino and the solution should come from their. Obviously this means stopping the resource discovery into the net by Bonjour and the Apple's men never they'll do!
I think that many people have this problem worldwide and many strategies have been applied for solving.
After many days of research and tests I solved observing the mDNS destinations into the captured packets and then filtering they at level of incoming port.
Many thanks for showed me the right way! :)