avahi seemingly not working
-
@maverickws forgot about that:
Allow packets with IP options to pass. -
thanks a lot. So currently I have these
(the multicast alias is ff00::/12 can't add that directly to the rules)
I'm not logging just looking for hits and states created. I'll leave it running until tomorrow and see how it goes and maybe test it on each interface! thanks a lot for the hints. -
@maverickws what's so odd to me is that it works... or that is required. That's only true at one site of mine. The others work fine with just Avahi and normal firewall rules.
-
@SpaceBass howdy mate hope you had a nice weekend.
So as mentioned I had added those rules, initially I had them as Floating rules, but nothing was happening on the network so I made normal rules on the IoT interface, as nothing happened after a few hours I added a likewise rule to the LAN interface.
By today I was still not seeing changes in discovery.
I also noticed another thing:Despite the rules being there, active, and showing hits, all those hits had no traffic with State
NO_TRAFFIC:SINGLEall of them on this state, which means then that the rule is doing nothing. -
@maverickws said in avahi seemingly not working:
Despite the rules being there, active, and showing hits, ....
which means then that the rule is doing nothing.If it show hits, the rules is doing what it should do : passing traffic.
@SpaceBass said in avahi seemingly not working:
For testing the LAN network has a top rule for any/any and it's logged
Like this :
See the last two rules : these two are perfect.
Ok to be more restrictive, but in that case you have to deal will all the exceptions. Even the ones you don't know about
I have a captive portal - accessible for 'hostile devices' : the equipment hotel visitors bring along with them.
When they want to 'print' something, they can discover all printers I have available on my LAN network. [ that is, it works for Apple devices - others : I don't know ]A firewall rule on the captive portal allows them to access my printers :
First rule : 'Printers' is an alias for the 4 IP addresses of my network printers. 'MostBasicPorts' is a list with common ports like 21,22,23,53,80,443, etc.
Second rule : they can access any of my 4 printers.This works on a 'if they can make it work, the copy is for free' basis. That is : I'm not going to discover on their device how it implemented printing ...
I use Avahi :
Btw : Is this somewhat comparable :
?
-
This post is deleted! -
ok so I did another test, and plugged my computer directly to the switch in front of LAN, and captured traffic there.
I'm getting ALL multicast traffic there, including from the IOT subnet.
I then disabled all the rules on pfSense, and I'm still getting all the multicast traffic on the switch. -
@maverickws what happens if you use an mDNS browser app?
-
I've connected a machine to both LAN and IOT and capturing traffic.
Yesterday without rules and today with the rules enabled will analyse to see the differences. One thing I found yesterday a lot was malformed packets specially on the responses, idk still trying to figure out why Avahi does not work out of the box and why so hard to have mDNS working properly with pfSense. -
This post is deleted! -
@maverickws Avahi is working great here.
I have reflection working across three different VLAN's.
I have one floating rule:
A floating rule is the right place to put this, so you can select all the interfaces Avahi will need to run on in one rule, you also need direction "any" which can only be done in a floating rule. Allow IP options must be ticked as well otherwise the rule won't apply to multicast traffic.
My rule is a bit broader than technically necessary for just Avahi, it allows anything in the multicast range to pass as I have multicast routing set up as well, but this is a known working starting point which you could work backwards from if you want to lock it down a little more.
It probably goes without saying, but allowing Avahi/Bonjour discovery to work between networks/VLAN's is not enough by itself, there needs to be some level of unicast traffic routing enabled between different networks/VLAN's as well so that Bonjour discovered devices can actually exchange traffic once discovered.
We have additional unicast firewall rules that allow Apple Classroom and Airplay traffic between specific VLAN's for example.
-
@DBMandrake I actually moved the floating rule to regular rules precisely in order to more granularly control traffic.
Also:
I have aliases for both IPv4 and IPv6 (expressed as networks, /32 for v4 and /64 for v6) addresses of HomeKit Hubs: All capable Apple TV's (they act as redundant), and the iPhone I use to add devices to HomeKit. Also have an alias IPv4+IPv6 with the IP's of the HASS instance (v6 meaning local fe80).
The Source in my case isn't obviously any.Anywould mean traffic from the Guest VLAN or the WFM vlan (work from home, where companies computers connect when working from home, me and the mrs) would be able to multicast, and I obviously don't want that.
I control the devices allowed to mcast with - again - alias, and only the select devices are allowed from one subnet to another.Also and imperative for HomeKit to work flawlessly with Home Assistant, is to have a rule to allow communication between HASS and the Hubs.
So basically after figuring out exactly what traffic was going where, I was able to add tight rules to the firewall while keeping everything operational, which is one of the goals in networking anyways.
-
I added this rule on a VLAN to allow mDNS to work across subnets. I've had this rule in place well before recent updates though:
️
