An old chestnut - mDNS/Bonjour across VLANs

[iMx]

Something else, whilst I remember, Fast Roaming on the wifi network settings, broke it as well when enabled.

... network Auto Optimise probably will as well, as I believe that restricts Multicast in some way.

[Greelan]

Yep, have always steered well clear of those

[iMx]

Started getting a weird, perhaps similar problem to you, on 4.3.20...

Out of the 3 APs, after a few days, one would randomly stop passing multicast traffic - devices wouldn't see the Airplay announcements - port mirroring I could see it leaving the switch, but devices connected to an impacted AP did not see it.  Restarting the AP recovered things, for a few days.... then another AP would be impacted.

So far, downgrading APs to 4.0.80 again it hasn't happened again... yet anyway :)

[devilkin]

I'm seeing this kind of behaviour too... odd. Still on the latest firmwares.

[iMx]

4.3.20 was supposed to fix....

[UAP] Fix intermittent multicast packet loss on static VLANs.

Seems likely that it didn't - airplay problems have not reoccurred since downgrading to 4.0.80 :)

4.0.80 still seems to be solid for me, even though the 'experience' scores for various devices are 'wonky' on this version, the actual wireless connection seems to be sound on all devices.  I was on this before going to the 4.3.x branch... which seems to have been a bit of a disaster generally.

4.3.20 still seems to be ok for me on switches, however, no outstanding issues/problems there for me.

[Greelan]

Well, blow me down - having changed nothing in my network over the last week, today I am seeing all mDNS traffic from my IoT VLAN in my main VLAN. What the?!

Let's see if it lasts.

[devilkin]

In case you still see issues, you might want to take a look at the latest official firmware for the APs:

https://community.ui.com/releases/UAP-Firmware-4-3-26-11358/e05cd041-ea54-460c-85f4-7f3fd97261e8

[UAP-G2] Fix intermittent broadcast and multicast packet drop on gen2 APs, introduced in 4.3.24. This impacted users with non-UniFi DHCP servers which use broadcast for DHCP, along with IoT devices that rely on multicast for discovery.

[Greelan]

I did see that, but read it as fixing an issue introduced in a version released recently. Anyway, fingers crossed but so far mDNS traffic is still being passed between VLANs on my existing firmware (4.3.20)

[devilkin]

For me it atleast worked for solving my ARP traffic issue ;)

Edit: nope. Spoke too soon

[AryasDad]

Just set this up myself, there are a few Unifi-isms, I'm running:

3 x Unifi AC AP Pros
1 x Unifi Pro 48 Port Gen2 switch
1 x Unifi Pro 24 Port POE Gen2 switch
A number of Flex and Flex Mini switches

- Firstly, firmware 4.3.20 is key for me.  On APs and switches.  .21 and .22 caused all sorts of havoc.  I shall be staying on this firmware version

- Firewalls rules as you have above, destination 224.0.0.251, UDP, port 5353, inbound all VLANs you want to repeat

- Enable 'Multicast Enhancement' on each wifi network that you have mDNS repeater setup for on the Unifi controller (Settings -> Wifi - > Edit -> Advanced

- Enable IGMP Snooping on the Unifi for each VLAN/profile setup with mDNS (Settings -> Advanced Features ->Network Isolation -> Edit)

- I had to allow all traffic BACK from my AppleTVs, to the streaming devices (iphones, computers).  I think the port range is huge, so I decided to create 2 groups and allow all traffic between them. Airport express seemed to work ok without this, but I believe AppleTV needs to be able to initiate connections back to the iPhone, computer, etc.

.. think that's it

Sorry to revive an old thread but am trying to get this working for myself.  I have recently made the switch from pfSense to OPNSense and am trying to get my AirPrint to work across VLANS.  I also am running UniFi AP's and switches, so have turned on the features you mentioned on those items.

My printers are on a IOT VLAN (103) with IPs 10.103.0.0/24
I have a LAN network with IPS 10.1.0.0/23
I have a Guest VLAN (102) with IPs 10.102.0.0/24

I have activated os-mdns-repeater and have it listening on the LAN, IOT and Guest interfaces.  I can see and print to the printers from my LAN, which has access to all the other VLANs.  The IOT and Guest VLAN has rules blocking anything originating on those nets to the LAN net.

I am trying to get my Guest net to also see and print to the IOT printers, but AirPrint fails to discover them. I am sure it is a Firewall rule, but am having a hard time understanding the discussions I come across that discuss the rules.  In particular from your post:

Firewalls rules as you have above, destination 224.0.0.251, UDP, port 5353, inbound all VLANs you want to repeat

I am not following what this means.  Can you please show me a shot from your rules table with these rules so I can decipher what I need to set.  Where does this rule get placed? 

Thank you!

[crissi]

Hello,

found this thread as i have also the issue with Multicast. Also related to the Rules im not sure if i have configured them correctly?

I hope someone could have a short look, and let me know, if they are correct or not :)

Thx!

[persons]

A few beefs with mDNS I'd like to add. Why are there implicit deny rules (that cannot be seen from GUI) for other services but not mDNS? Is this the right place to request basic features? If not, please direct me to the best (free) place. Every service that requires interfaces to be selected should include an option to auto add firewall rules. Also why is logging disabled for newly created rules, and why is there no 'select all / batch' way to enable logging? Debugging issues is a fundamental process to learning.

[OPNenthu]

Why are there implicit deny rules (that cannot be seen from GUI) for other services but not mDNS?

Are you asking why there is no need for an mDNS-specific block rule?  The 'default deny' rule blocks all protocols already, including mDNS.  It's a catch all rule for anything which isn't explicitly allowed, so OPNsense doesn't have or need any deny rules just for specific protocols or services.  Everything is blocked- until and unless you allow it.

The catch: it only blocks what the firewall can see in the first place such as routed multicast or that which is reflected by mdns-repeater across interfaces.  In other words inter-VLAN mDNS is blocked by default.

In most cases (if you have clients behind a switch) the mDNS multicast stays link-local and is forwarded at the switching layer.   The firewall doesn't see it for clients that are on the same broadcast domain, so we can say intra-VLAN mDNS is not blocked.  That's why mDNS "just works" within a subnet.  Control over this would likely be on your managed switch or your wireless APs.  You might have some coarse options there.  For example, in UniFi settings I can block multicast (not just mDNS) for wireless SSIDs and enable it only for certain MACs.

Things might be different in case of bridged interfaces in OPNsense like when clients are directly connected to its ports.  Maybe then the firewall has a chance to filter mDNS because it is the switch.  (I can't really speak to it as I haven't tried)

Not sure if that's what you were asking but I hope this helps clarify when rules are / are not needed. 

I don't know what other implicit deny rules for services you're talking about (?) but the automatic rules can be seen in the GUI.  They're just in a separate category that you can expand in the Rules UI, or if you're using the "Rules [new]" UI then you can see them with the "Inspect" button.

Is this the right place to request basic features? If not, please direct me to the best (free) place. Every service that requires interfaces to be selected should include an option to auto add firewall rules

I think that would be a task for the plug-in's maintainer as most of the plugins are not maintained by the OPNsense devs.  You can try raising a request: https://github.com/opnsense/plugins

I'm not sure that it's an established norm that anything with selectable interfaces gets rules added.   It might seem that way because it's done for Dnsmasq/Kea and ICMPv6 requirements because those are tough to configure manually and the network connectivity breaks without them.  Also the default "LAN" interface gets permissive rules that allow everything, so it gives a false impression maybe, but any additional interfaces you add would require you to supply rules for DNS, NTP, etc.

Note: if you have a managed switch with a built-in mDNS proxy then you can use that and avoid mdns-repeater and rules altogether.  That might also work for IPv6 whereas mdns-repeater doesn't.

Also why is logging disabled for newly created rules, and why is there no 'select all / batch' way to enable logging? Debugging issues is a fundamental process to learning.

Getting very off topic now, but I suspect admins keep logging disabled to reduce noise and processing.  They selectively enable what they need.

You can raise a request for the batch logging toggle on the opnsense/core repo.

--

Welcome to the forums.  Have fun learning.