MDNS struggles
-
Hello
I have an iOS device on my IOT VLAN that I want to communicate with an Airplay enabled AVR on the MAIN VLAN. Looking at packet captures it seems the issue is the mdns query from the iOS device is not returning the details of the AVR. (However, if I join the iOS device to the MAIN VLAN then it does return correctly in the mdns answer and I am able to connect to the AVR. I have installed and enabled the Avahi package and configured it to repeat mdns packets across subnets (Selected the MAIN and IOT networks).
What I'm slightly confused about is whether the issue is with pfSense or if I need to consider my Netgear managed switch or Ubiquiti AP as well - could they be interfering with mdns getting to and from the AVR in the other VLAN?
Thanks in advance for any thoughts or pointers to help me get this working or rule out an issue with pfSense
-
@nazuro well when you sniff.. Does pfsense see the mdns query - and does it send it onto the other vlan?
if doesn't see it, can never forward it. If it forwards it - is there a response.
A sim recent thread user was doing this - and wasn't working because they were policy routing, so even if the client found the device via a mdns query, when they actually wanted to talk to that device the traffic was routed out some vpn gateway.
-
@johnpoz Hey, thanks for your help. Sorry for the delayed response In the pcap I can only see one packet which contains the mdns query AND the answers. So, pfsense can definitely see the query but I can't work out how to see if it sends it to the other VLAN or not. Any ideas how I can do so please?
Thanks
-
@nazuro said in MDNS struggles:
AND the answers.
Well if it contains an answer - then clearly is sent it on, or there would of been no answer.
-
@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..
