mdns-bridge one-way reflection

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.