MDNS struggles
-
@johnpoz Sorry if my OP was not clear. I have other devices on the network that return answers but I am specifically looking at the answer coming from the MAIN VLAN from the Denon AVR.
if my phone is on the IOT VLAN, then I do not see an answer from the Denon AVR (I see other answers from other things in the network).
If my phone is on the MAIN VLAN, then I do see an answer from the Denon AVR.
I am trying to investigate why I do not see an answer from the Denon AVR despite having Avahi enabled
-
@nazuro said in MDNS struggles:
despite having Avahi enabled
Do you have firewall rule to allow for it? Just because client sends some traffic to 5353 doesn't mean that avahi will actually see it. If pfsense rules on that interface do not allow access.
So again sniff on pfsense, on interface where it suppose to send the query on to - do you see being sent?
-
@johnpoz Yes on my MAIN interface I have a rule to allow MAIN -> IOT on UDP/5353. However, On all interfaces I have explicit deny rules and everything is logged. I can't see any deny events with dest port 5353.
Sniffing directly on the IOT interface I cannot see any MDNS packets from the MAIN network
-
@nazuro said in MDNS struggles:
I have a rule to allow MAIN -> IOT on UDP/5353.
What kind of rule is that?? You need a rule on the interface where the mdns query is going to come from to allow mdns to hit pfsense avahi.. So it can forward it..
The destination of the 5353 query is never going to be to IOT network, its going to be a broadcast or multicast packet. Which is only ever going to be local - the avahi is what sees the traffic and passes it onto the network where the device your tying to query is.
But it can not see it if you don't have a firewall rule on the main to allow avahi to see it.
-
@johnpoz Right yes of course, silly me. I've created a floating rule for MAIN and IOT for UDP source: any, dest: 224.0.0.0/8 port 5353 with Advanced "Allow packets with IP options to pass" Selected. Thought this would cover me but seems still no dice :(
-
did you set it as quick? Again just sniff to validate traffic is being sent how you think it is being sent, and if passed on..
Is your client sending ipv4 or is it using ipv6?
You really should post up your avahi setup and your firewall rules.
-
Here: Just did a validation of this.. Not a user or a fan of avahi, it is circumvention of L2 boundaries in my opinion.. But it is simple enough to get working.
mdns is going to be to 224.0.0.251, so create a firewall rule that allows that on the interfaces you want - or use floating. Here I created floating inbound rules on the 2 interfaces I want it to work on - set quick. My phone is on wpsk 192.168.4/24, and my printer is on wlan 192.168.2/24
You can see from the sniff on did on the psk interface - my phone on 4.205 sends a mdns query. And then pfsense sends that back - you can see in the info where my printer IP is listed 192.168.2.50.
You would then need a rule on your interface to allow to talk to that IP on the ports your service is going to be using if you want to actually be able to use the service.. In my test case "airprint" is how printer is found via mdns.
So if I sniff on the other interface, the wlan where my printer sits.. you can see the pfsense sending on the query "from its ip" and getting a response from the printer.
Pfsense IPs on the 2 different vlans are 192.168.4.253, and 192.168.2.253
Hope that helps understand how avahi works - and how to trouble shoot it via sniffing to validate pfsense sees and sends on the traffic and you get a response from what your trying to find via mdns.
-
@johnpoz said in MDNS struggles:
92.168.2
Thanks Johnpoz. Strangely I can't actually see any mdns messages on my MAIN VLAN pcap taken with the pfsense GUI (this VLAN has my AVR which I am trying to discover). This is despite me connecting on my iPhone to MAIN VLAN (and then seeing the AVR appear).
PCAP on the IOT interface sees only the query but not the response.However, if I pcap on the parent interface using
tcpdump -i igb1 -nn -e vlanThen I do in fact see query/responses (just not the response from the AVR like expected)
I'm likely doing something wrong with the pcaps. Assuming the tcpdump command I used is correct, then what I see is that I do not get a response from the AVR (MAIN) when my iPhone is connected to IOT. Incidentally, when things do work when I connect iPhone to MAIN, I do not see separate query & response packets like you. They are in the same packet (in screenshot, 192.168.11.128 is my iPhone on MAIN).
Is it possible this could be an issue with my GS116Ev2 or unifi AP?
-
@johnpoz Ok, problem with my pcap was not using promiscuous mode.
I still do not see the same results you see, even when I test with both phone and AVR on the same VLAN (which means I can successfully discover it by Airplay).
This is the pcap from the MAIN VLAN: tcpdump -i igb1.11 -nn
I only see one record which contains both the query and the answer. I do not see a separate packet going from AVR -> 224.0.0.251 or even from pfSense -> 224.0.0.251.
iPhone is 192.168.11.128
pfSense is 192.168.x.1
Denon AVR is 192.168.11.20Do you know why I might be seeing pcap results to you?
-
@nazuro said in MDNS struggles:
I only see one record which contains both the query and the answer.
And how would that even be a thing? That would be the same device asking for something that is not him, and then sending the answer with it? Again that is not him?
There is no IP there.. That wouldn't help you talk to anything anyway..
That 11.20 is your denon box? Where is his traffic answer??
What is .119 there - that is a response.
How about you post up the actual pcap so can look at it..
-
@johnpoz Yes it sounds impossible which is why I was thinking maybe it's an issue with my pcap or Wireshark settings. Pcap attached for the MAIN network where my phone (192.168.11.128) successfully discovers the Denon (192.168.11.50).
192.168.11.119 is a MacBook 300sep.pcap
-
@nazuro Dude your sniffing on pfsense - so query would go to broadcast and pfsense would see that, but the device answering a mdns query via a response could be direct to the query IP? So no pfsense wouldn't ever see the answer..
But I do see the 11.20 broadcasting via SSDP what he is and what his location is 11.20
So yeah your iphone would easy discover that..
So again setup avahi - sniff on both interfaces -- what do you see.. Maybe mdns isnt working because that is not what is being used?? Do see pfsense send on the broadcast mdns aksing for stuff.. If so then it did what suppose, to - if nothing answer that is not anything to do with pfsense or avahi.
-
@johnpoz Right, yes. I have now captured pcap on main and not interfaces while iPhone is on IOT (192.168.12.7). I can see the query like before but this time no answer contained in the packet. So if the Denon is trying to talk directly to the iPhone then that shouldn't work because it's in a different VLAN, right? It should be routed up to pfSense. I obviously have the wrong end of the stick here main.pcap iot.pcap
-
@nazuro you need to sniff on the devon side the 11 network while you phone sends on the mdns query - you should see pass that on from "its" 11.1 IP to 224.0.0.251 if you see that but no response then avahi is working.. Your device is just not answering via mdns..
And your discovery of the device is via the ssdp I showed you on your sniff and not some answer from a mdns query.
Avahi works by "repeating" the stuff it hears just from its own address in the other vlan.. If its doing that - but not response then no your device would not discover it via mdns.
a query
12.7 --> 224.0.0.251 pfsense 11.1 --> 224.0.0.251pfsense just repeating it in the other vlan - like "it" asked for it.. Lets see the sniff on the 11 interface while your phone is sending queries on the 12 network - does pfsense pass it on? If so avahi is working as designed.
For ssdp/upnp proxy you prob want igmp proxy of pfsense.. Or there is some other relay thing designed to break L2 barriers around here people talking about. I am not a fan of breaking the L2 boundary.. You can route multicast sure if what your doing with it meant to route.. But rebroadcast from 1 L2 into another L2 defeats the whole purpose of the L2 boundary in the first place if you ask me.
-
@johnpoz Hi John, thanks. I can see the SSDP from the Denon but from googling around I'm still pretty sure that Airplay uses mdns, and I can see that from the answer in the MDNS query when my phone is on the MAIN/11 network.
the sniff on the 11 interface while the phone sends queries on the 12 network is uploaded as main.pcap and I cannot see pfSense passing on the mdns query, which makes me think Avahi is not working correctly then.
-
@nazuro said in MDNS struggles:
and I can see that from the answer in the MDNS query when my phone is on the MAIN/11 network.
No your not - has NO IP in what your thinking is an answer - so how would you talk to it?
If your not seeing avahi pass on the traffic like I showed - then avahi is not running, or your firewall rules do not allow avahi to see the traffic to be able to pass it on.
you posted your avahi settings - where are the firewall rules that allow pfsense/avahi to see that broadcast so it can send it on? That floating rule looks to be outbound? See the little double green arrow icon. Oh that is for quick.. What direction is the rule set for?
If your not seeing pfsense pass on the traffic - then no it would not be possible to discover this via mdns..
What are you interface rules? As mentioned before - even if you discover it, if you do not have the firewall rules to allow the traffic (after discovered) then no your not going to be able to talk to it either. But what you posted, had no IP in it.. And that was coming from your phone.. As an announcement maybe.. For mdns to work - you should see a specific response from the device with its IP in it..
edit: Ah!! Always helps to go to the RFCS ;)
https://datatracker.ietf.org/doc/html/rfc6762#section-7.1
When a Multicast DNS querier sends a query to which it already knows
some answers, it populates the Answer Section of the DNS query
message with those answersThis explains what your seeing in that frame from your phone.
edit2:
If your phone already knows the IP, then possible your problem is firewall not letting it talk to that IP on whatever that is - but if that was the case you would see traffic to that IP in your sniff on the 12 network trying to go to the 11. address? Which I didn't see.. -
@johnpoz on my floating rule the direction is set to any.
By the way, same problem the other way round, I have an Apple HomePod (192.168.12.145) on IOT and I am not able to "discover" it with my phone on MAIN. Pcap does not show any SSDP from the HomePod just MDNS.
I've created a test floating rule to allow all from MAIN to IOT. However, I do already have explicit default deny rules on all interfaces with logging enabled and cannot see any blocked firewall traffic from the Denon (192.168.11.20). Still no luck.
-
If you do not see the query passed on, then no it would not discover. What version of pfsense are you running, what is the version of the package?
Did you try actually selecting the interface in avahi - vs not selecting any? And hoping it listening on all?
Your screenshot is so zoom in, maybe you have some other interface selected.. Select the 2 interfaces your wanting to use directly.
You do not have avahi set to filter service.. Any other settings?
-
@johnpoz pfSense 2.5.2 - selected MAIN and IOT interfaces only for Avahi.
Not changed anything else in the Avahi settings
-
@nazuro why are publishing pfsense - it has no services you would use via mdns.. those are not default..
This is how it should be set.. Set it like this - and set your firewall rule to 224.0.0.251
I show current package as 2.2 and its running
If you do not see it passing on the traffic via sniff - with a response - then no its not going to work, and something is wrong.
