Also, Enterprise IT is often averse to anything that's not centrally managed, and Bonjour is the anthesis of centralization (it's all peer-to-peer). Some networks turn on client isolation so that peers can't talk to each other at all, often in the name of security.
That said, there are ways to get this stuff to work right in an enterprise setting. It requires careful network design to keep broadcast domains small, ideally with an mDNS Reflector running somewhere. All the major WLAN vendors have custom options for supporting it, with varying levels of customizability:
- Cisco: https://www.cisco.com/c/en/us/support/docs/wireless/aironet-...
- Aruba: https://www.arubanetworks.com/techdocs/Instant_41_Mobile/Adv...
- Ubiquiti: https://help.ubnt.com/hc/en-us/articles/360001004034-UniFi-B...
Admittedly, it's hard to get right, the apps that need it are not usually business critical, and there's not many apps to test with... so most IT shops just turn it off and avoid the additional headache. Which is unfortunate, because it effectively kills off any peer-to-peer functionality on the LAN.
Disclaimer: I work at Google, but not on any of the teams mentioned in the article. I am a big fan of mDNS, but that's my personal opinion.
Fortinet nails this, took me a day to figure out.
It used to be rare for IT to have any real practical UDP/multicast/broadcast experience, mostly because general support was so bad.
If I know the IP of a friend on the LAN, I can connect to him directly, as normal - the connection will not be blocked by the router. But other than that, the router shows my device a view of the world in which it is the only thing connected to the LAN.
Enumerating the private IP space and trying to connect to all of the possible addresses might reveal the actual stuff though? But the multicast protocols I assume use a smarter and more efficient approach which gets blocked by client isolation.
Ruckus calls it bonjour fencing, and has pretty good support for creating useful policy.
http://docs.ruckuswireless.com/smartzone/3.6.2/sz300-vszh-sc...
This is usually solved through some sort of mDNS proxy, but you don't really want to proxy everything. If your phone discovered all of the apple tvs and chromecasts across campus, then it wouldn't make for a good user experience for anybody.
Mdns proxy would have been the solution, but I was never able to get it to work. It seemed to me that no one actually managed to get it to work, based on my Google searches at the time.
Of course, getting it to work on the corporate network was even less likely.
Any standard firewall contains tools for PIM (protocol independent multicast) routing. PIM router as the GW for both subnets / VLANs does the trick fine, and is easy-ish to setup. Using this for mDNS printer discovery on a guest network to an internal printer network.
This article is right in that multicast is stupid to use for this, but wrong in that the purpose of a net admin is to NET ADMIN. Make it work and quit whining, multicast is not a new or difficult problem.
Wireless and wired networks commonly are in different network segments, vs Bonjour etc. generally assuming devices are in the same and using only local multicast - so the network explicitly has to provide a proxy bridging that traffic between segments, not having rules forbidding traffic between them (which also would be normal to have) isn't even enough.
Or a weak one from the perspective that security must address usability since otherwise users will route around the “secured” system for functions which should be performed within that system.
Also protocols like Bonjour by default only work on the local network which at home might well be all there is while at work might be one of many.