mdns-bridge one-way reflection
-
Thanks all for clarifying.
I have the following three VLANs:
- LAN - Trusted network
- IOT - Where my chromecast devices plus some other appliances live
- GUEST - Untrusted devices from my friends
I want LAN and GUEST to both be able to discover and cast to devices in IOT, but I don't want GUEST or IOT to be able to discover or have visibility of devices in LAN. I also want GUEST to only discover chrome cast devices and not others in IOT, but LAN to be able to discover all devices and appliances in IOT.
My understanding is I would need to set the interface filter settings in mdns-bridge as follows:
- LAN - Inbound - None
- LAN - Outbound - None
- GUEST - Inbound - Allow - _googlecast._tcp.local, _androidtvremote2._tcp.local
- GUEST - Outbound - _googlecast._tcp.local, _androidtvremote2._tcp.local
- IOT - Inbound - _googlecast._tcp.local, _androidtvremote2._tcp.local,_homeconnect._tcp.local
- IOT - Outbond - None
I also understand this would still allow chromecast devices in IOT to announce their presence to GUESTs (including those on the LAN which I don't have), however, if I put
_nothing_onGUEST - Outbound - Allowthen this would stop those announcements.- Does it matter whether announcements of Chromecasts get to GUEST or does blocking it mean they are still discoverable on IOT, but the GUEST devices just take a little more time?
- Don't the Chromecast devices respond to an mDNS query via multicast so wouldn't putting
_nothing_onGUEST - Outbound - Allowstop the response getting back to GUEST and prevent it from being discovered?
-
@kesawi mDNS isn't like firewall rules, where you are controlling pathways between discrete interfaces.
The way to think about this is that mDNS represents a common pool of services (I.E. DNS entries). The filter rules allow you to control what service names from each segment are added to the pool (inbound filters), and what service names from the pool are advertised to each segment (outbound filters).
Do keep in mind that the ability to see that the service exists in mDNS does not mean that you can connect to it. Standard firewall rules for TCP/UCP still govern the ability to connect to a service.
One other note: as indicated in the documentation, it is not necessary (or useful) to include _tcp or local labels in filters as these are redundant.
-
@dennypage said in mdns-bridge one-way reflection:
With regard to mdns-bridge, while you cannot have an empty filter list, you can have a filter list that will not match anything real, like
_nothing_Using that as the Allow Outbound Filter on your untrusted network would effectively prevent any services from the trusted network being advertised in the untrusted network.
Sorry to bring this up again, but I'm having problems getting the filters to work as intended,
I have 4 interfaces in play, and having done a packet capture, I can verify that even though I setup outbound filters with ALLOW nothing on an interface, I still get all kinds of PTR service requests and their answers (all from other VLANs) "reflected"
So far using DENY filter on one interface seems to work (on that interface), but applying another DENY on another interface does not seem to filter what's expected.
Something fishy is going on....
I have verifies all packets are sourced from the pfSense Gateway interface in the VLANs I'm testing on.
-
@keyser said in mdns-bridge one-way reflection:
I setup outbound filters with ALLOW nothing on an interface, I still get all kinds of PTR service requests and their answers (all from other VLANs)
Yes, that is correct. mdns-bridge filters based on services rather than addresses. Host name lookups are not services, and are always allowed.
The following DNS types are never filtered from queries:
- A (1)
- AAAA (28)
- PTR (12)
- OPT (41)
In resource records (responses to queries), PTRs are filtered based on the domain name, which is where the service name will be found. Additionally, AAAA records are filtered to remove link local addresses.
-
@dennypage Okay then... I must have some sort of issue then because as I block services there seems to be a massive amount of PTR queries for _rdlink, _companion-link and _hap going on. I have those flooded requests across all my VLANs - with the responses as well - every 10ish seconds.
-
@keyser said in mdns-bridge one-way reflection:
I must have some sort of issue then because as I block services there seems to be a massive amount of PTR queries for _rdlink, _companion-link and _hap going on.
Apple?
-
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.
