mdns-bridge one-way reflection

[marcg]

Can mdns-bridge be configured for "one-way" reflection?

I have a T(rusted) network and an U(ntrusted) network. I'd like

• T hosts to be able to see+query all services offered by U hosts, and
• U hosts to be unable to see any services offered by T hosts.

If I configure mdns-bridge on the U interface with an empty outbound Allow list and no other interface filters, will that have the desired effect? Thx.

[dennypage]

@marcg said in mdns-bridge one-way reflection:

Can mdns-bridge be configured for "one-way" reflection?

I have a T(rusted) network and an U(ntrusted) network. I'd like

• T hosts to be able to see+query all services offered by U hosts, and
• U hosts to be unable to see any services offered by T hosts.

If I configure mdns-bridge on the U interface with an empty outbound Allow list and no other interface filters, will that have the desired effect?

"Reflection" is particular to Avahi -- I've really never understood why they chose that term.

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.

[marcg]

@dennypage Perfect, thanks.

Using Avahi presently, but I'd prefer that hosts on the untrusted network know as little as possible about hosts/services on the trusted network. Hosts on the untrusted network are ... untrusted :)

EDIT: Just tested with the suggested mdns-bridge config. Seems to work well. Connected to the T network, the mDNS "Service Browser" Android app shows a long list of advertised services, including ones from the U network. Connected to the U network, a much shorter list is shown (seems to be services only from the U network, but I haven't gone through them one by one).

[Gertjan]

@marcg said in mdns-bridge one-way reflection:

untrusted

I have a pfSense captive portal, so my hotel clients can 'do their thing'.
As they always forgot to bring along their own printers, I expose my company printers to them (Avahi ).
Btw : people in a hotel always want to plain boarding passes and thinks like that.

I took my printers out of my company LAN, and places them on a separate 'Printer only' LAN.
Ok, true, now they don't show up in the network neifggbnour anymore, but I don't care. They have host name, my LAN firewall rules allow a connection to these printers, so all is well.
Same thing for the portal user : I had to open up the printer ports .... so these printers are exposed to these 'untrusted' users. Imagine that they manage to take control over a printer because a printer exposes telnet port that I forgot to block.... they can now only 'see' the other two printers in that network segment, they won't have access to my LAN, they can't even go 'out' (to the net).

[marcg]

@Gertjan My understanding is that, in pfsense-world, mdns-bridge and Avahi (with reflection) provide essentially the same functions. The difference is that mdns-bridge provides granularity/filtering on mDNS queries/responses that Avahi does not. Firewall rules have to be configured for the associated inter-VLAN traffic -- after service discovery -- in both cases.

My use case is different from yours. The untrusted devices are largely media players of various sorts. I want to be able to control/access them from the trusted network. In limited cases, I want the untrusted devices to be able access content on the trusted network. If the trusted network were mapped via mDNS advertisements or, worse, breached based on the mapping and the limited trusted-network access from untrusted>trusted, my risk would be more significant than losing a few printers.

[dennypage]

@marcg said in mdns-bridge one-way reflection:

My understanding is that, in pfsense-world, mdns-bridge and Avahi (with reflection) provide essentially the same functions. The difference is that mdns-bridge provides granularity/filtering on mDNS queries/responses that Avahi does not. Firewall rules have to be configured for the associated inter-VLAN traffic -- after service discovery -- in both cases.

Avahi reflection and mdns-bridge provide the same functionality. FWIW, there are some additional benefits to mdns-bridge such as correct handling of various mDNS types (NSEC, OPT, SVCB and HTTPS), a much smaller footprint, and security improvements (simpler code, stateless, no dynamic memory allocation post initialization).

[Gertjan]

@marcg said in mdns-bridge one-way reflection:

I want the untrusted devices to be able access content on the trusted network

The untrusted device on the untrusted network has to contact a device on the trusted network.

This means you have to make a firewall rule on the untrusted network that allows untrusted devices to access the IP of the trusted devices on the trusted network. You should allow on a port level.
This won't be optionally - you have to do this.

When I scan my untrusted network, a captive portal, I see :

which is the list of info that printers (in another LAN) that can be accessed. Because I places a firewall rule that accepts only the IP of these printers, and the allowed 'printer ports'.

From my LAN, I could, in theory, access all untrusted devices, and it was not uncommon in the good old days that I could browse the holiday photos (everything actually) on a device that a hotel client used to access my hotel wifi (untrusted) network, as they've set up their sharing to 'everybody' (ancient windows system would allow that).

The fact that a device knows the 'address' (and more) details of a device not accessible isn't, for me, a big deal.
I - and everybody else - knows that (example) "core4.dns.ext.facebook.com" exists. It's on the biggest untrusted network that exists : the internet. I can't access it, though.

[kesawi]

When using mdns-bridge do you need to set up firewall rules to allow the initial multicast discovery traffic to the firewall (e,g. LAN subnets to 224.0.0.251), or does that automatially occur when you enable mdns-bridge on an interface?

[marcg]

@kesawi said in mdns-bridge one-way reflection:

When using mdns-bridge do you need to set up firewall rules to allow the initial multicast discovery traffic to the firewall (e,g. LAN subnets to 224.0.0.251), or does that automatially occur when you enable mdns-bridge on an interface?

Good question.

I did not need to set up additional rules, but already I had rules like the following that permitted all but a few things to the firewall address. pfctl -sr doesn't reveal anything that looks like multicast-specific rules.

pfSense documentation for This Firewall implies that it covers all addresses on which the firewall is listening.

[dennypage]

@kesawi said in mdns-bridge one-way reflection:

When using mdns-bridge do you need to set up firewall rules to allow the initial multicast discovery traffic to the firewall (e,g. LAN subnets to 224.0.0.251), or does that automatially occur when you enable mdns-bridge on an interface?

mdns-bridge itself does not install any firewall rules -- you are responsible for any necessary rules to allow mDNS packets (UDP port 5353) to be received by the firewall.

Many people have some form of default allow for internal networks which usually suffices.

[kesawi]

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_ on GUEST - Outbound - Allow then 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_ on GUEST - Outbound - Allow stop the response getting back to GUEST and prevent it from being discovered?

[dennypage]

@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.

[keyser]

@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.

[dennypage]

@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.

[keyser]

@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.

[dennypage]

@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?

[keyser]

@dennypage

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.

[dennypage]

@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.

[keyser]

@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.

[keyser]

@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 :-)