mdns-bridge one-way reflection
-
Yes, it’s almost a pure Apple environment. I’m guessing this happens because I have a misunderstanding about how mDNS/Bonjour operates.
As I understand mDNS Services:
Clients queries for services, and devices replies with capabilities.
There is also devices that intermittently announce their capabilities and clients can cache this.When I look at packet captures, service discovery attempts by clients seems to be done using PTR queries on the servicename. Are you saying those PTRs is never filtered, but responses from devices that offer the service is?
Any intermittent service announcements by a device is obviously filtered, and I guess that’s why I am seeing some blocking that works.I guess I’m confusing services with the whole Name lookup part of mDNS since all the PTRs I’m talking about queries for PTR on a servicename rather than an IP address?
I have 4 VLANS:
1: MGMT (Only has one Homekit Bridge - needs to be seen discovered by my homehubs)
2: HOME - Main Homekit VLAN with two AppleTV Hubs, several Airplay/Chromecast speakers and some Homekit cameras and sensors
3: IOT - IOT VLAN for Printers and SmartTVs
4: CLIENT - Trusted device VLAN for phones, PC’s and tablets.How would a good “initial” filter in/out on those 4 VLANs look like? For services like:
_hap (homekit)
_airplay and _roap
_chromecast
_IPP (and other printer services)NB: I seem to have filtered something that causes some of my apple clients to PTR for the services called _rdlink and _companion-link every 10 seconds. Those PTRs and the 5 or 6 individual replies are flooded on all VLANs continiously - and I’m unable to filter that at all.
-
@keyser said in mdns-bridge one-way reflection:
Yes, it’s almost a pure Apple environment.
This tripped me up at first as well. Since the Apple devices all talk to the iCloud service, they already know about each other outside the mDNS context. They use mDNS to try and find each other so they can establish connections. No way to stop it other than completely disconnecting the systems from iCloud.
@keyser said in mdns-bridge one-way reflection:
When I look at packet captures, service discovery attempts by clients seems to be done using PTR queries on the servicename. Are you saying those PTRs is never filtered, but responses from devices that offer the service is?
Queries of type PTR are never filtered, whereas resource records (responses) of type PTR are filtered based on the rdata domain name.
-
@dennypage said in mdns-bridge one-way reflection:
Queries of type PTR are never filtered, whereas resource records (responses) of type PTR are filtered based on the rdata domain name.
Hmm, then It really becomes whack-a-mole to filter down mDNS chit-chatter with more than two interfaces…
Thank you for the explanation and pointing out that attemting to block something they know exist through iCloud is a moot point - that’s likely whats causing them to query continiously for it.
I’ll try some new filters with this in mind.
-
@dennypage I have been testing with a few different filtering setups now (considering what I Expect they know from iCloud anyways), and things are better in terms of filters working as "expected".
It would be nice though if one could filter PTR requests of specific kinds, but I know that would require state in the mDNS-bridge to also filter the responses in their entirety.I must admit that even though I'm a network engineer and have always LOATHED Apple for not providing a centralized option as an alternative to mDNS (could be flicked on by a DHCP option fx. or the availability of a special DNS TXT record in the current search domain), I never quite realized how bad it has become......
It's BAD!!
For all my enterprise customers it's not an issue because we simply filter mDNS completely, and any services needed must be based on DNS.
But in home networks where mDNS is needed because of HomeKit, Airplay/print and so on... OMG they are chatty now. This must REALLY be costing on Wireless network performance in home networks where there is no Multicast to Unicast conversion in the AP.
With 10 apple clients and two appleTV's, I have about 150 frames/min on average just with _rdlink and _companion-link updates.
In a single L2 that's no too costly, but spread out over VLANs and duplicated..... cheesus! It almost becomes an argument not to segment your IOT :-) -
@keyser At the risk of turning this into an Apple Support Thread...
A lot of the chattiness you are seeing likely comes from them being unable to discover and/or connect to each other. Even if you just allow them to discover each other via mDNS, I expect that the level will drop significantly.
FWIW, while I segregate my IoT stuff (I have a lot of it), I do not classify my AppleTVs as IoT. Given that all the Apple devices are all bound to the same iCloud account, it's rather a compromise one, compromise all situation. As such, my AppleTVs sit in the trusted network alongside the laptops, phones, etc. Honestly, given the complexity of use, and mobile nature of the laptops and phones, I view the AppleTVs as being low on the list of likely sources for compromise. Phones scare me the most...
-
@dennypage Thank you for the continued sparring on this. I completely agree on the AppleTV's. I might also end up doing the same thing, but It's a good learning excercise to get this working in the most optimal way :-)
You are quite right - it's about the ability to contact each other, and I have solved a good deal of the "chattiness" now with a port opening on TCP7000 and UDP3722 from "home" to "clients" + lifting some off my L2 client isolation setup.
But there are some undocumented port needs in between clients on L2 that's causing a bit of grief.
I'm running with some level of client isolation in L2 (role ACLs), but there is something blocked that's causing the clients to be VERY chatty even though all ports Apple has documented are open. Lifting the ACL completely makes them comparatively quiet, but more or less everything is allowed as it is now.I have a sneaky feeling it's an unmentioned IPv6 requirement. I block everything IPv6 at the user-role/connectionpoint (wired or wireless) so nothing IPv6 Is moving on my network (My ISP does not support it anyways).
The question is if Apple has made it a requirement even though its not documented (that I can find...) -
Somewhat off-topic ... with an Airplay player (e.g., AppleTV) on an untrusted VLAN different from the trusted VLAN of an Airplay source (e.g., phone), is it necessary to allow the player to initiate traffic from the untrusted VLAN to the trusted VLAN to establish a source<>player connection for video?
From what I've read and from testing, this seems to be the case.
Just replaced our 15 year old TV with an LG one that supports Chromecast and Airplay. I put it on an untrusted VLAN that blocks flows initiated from untrusted>trusted with some narrow exceptions.
For Chromecast, enabling mdns-bridge was all that was required for Chromecast to be discovered and work from a source on the trusted VLAN. For Airplay, mdns-bridge enabled discovery from the trusted VLAN. However, to play video from the source, I had to enable untrusted>trusted flow initiation on UDP:7000 and UDP:49152-65535 to make it work. Is this really necessary?
No iCloud involved here and only a single Apple device (phone) in the house. I did this mostly out of curiousity. But I've left the Airplay rules for untrusted>trusted initiation disabled; I'm not keen on punching a massive untrusted>trusted hole in the firewall. I could shrink the hole somewhat by limiting the traffic to certain hosts on the trusted network, but still ...
I do want the TV on the untrusted network. It runs all sorts of connected apps from LG and others. I don't have a warm fuzzy feeling about its security.
-
@marcg AirPlay sessions are initiated by the client. The information necessary for the client to initiate the session is advertised by the server via mDNS. Hopefully this addresses your question.
-
@marcg Yes, those ports are needed - in what we consider the wrong direction - when you are Airplaying Video/screen mirroring.
For sound only Airplay they are not needed/used.The UN should really gather a mandate from all of the world to impeach Apple for creating the most obfuscated and security and network performance UNFRIENDLY solutions possible. You would be hard pressed to dream up a worse and more unmanageable solution for these things that what Apple has done (And this I coming from a ALL apple user - that happens to be a network engineer).
-
@keyser said in mdns-bridge one-way reflection:
@marcg Yes, those ports are needed - in what we consider the wrong direction - when you are Airplaying Video/screen mirroring.
For sound only Airplay they are not needed/used.@keyser @dennypage , thanks for the info and confirmation.
Somewhat reminiscent of the well-known firewall issues with active FTP ... with the difference that Airplay was introduced 20+ years later.
