mDNS traffic from WAN to 224.0.0.251:5353, but why? Please help.
-
My initial thought would be you installed avahi and told it to use WAN.
-
Yeah I thought that as well - but why would that trigger what clearly is an ingress only rule - is it not?
Those antispoof rules are clearly listed as drop "in" Could the modem be reflecting it back?
-
@Derelict said in mDNS traffic from WAN to 224.0.0.251:5353, but why? Please help.:
My initial thought would be you installed avahi and told it to use WAN.
Hi @Derelict, I can tell you that is not the case. I have selected 2 LAN interfaces. I also believe you can only make it listen to WAN by manually editing code, which of course I would not consider, given the security risk you introduce.
@johnpoz I will have to test with Avahi off indeed to see if the traffic is still seen in the logs.
I am also doing some new pcaps that I can provide.Meanwhile, I found another topic on the Netgate forum, exactly the same, with no response: https://forum.netgate.com/topic/142877/avahi-listening-on-wan-interface, as well as on Reddit: https://www.reddit.com/r/PFSENSE/comments/7t78bq/avahi_plugin_generating_firewall_block_log/. So I am not the only one :-). Responses in those topics did not yield any solution however, so I have to keep on troubleshooting.
-
So I downloaded avahi, and will duplicate sending mdns from 1 vlan to another vlan..
Please post up your settings..
-
Ok I installed avahi.. I then had it setup doing my lan and wlan
I then started a mdns-scan on linux box on the wlan network..
It floods the network with mdns
root@NewUC:/home/user# mdns-scan + NAS._http._tcp.local + NAS._sftp._tcp.local + NAS._ftp._tcp.local + NAS._afpovertcp._tcp.local + NAS._smb._tcp.local + NAS._device-info._tcp.local + NAS._adisk._tcp.local + Brother HL-3170CDW series._pdl-datastream._tcp.local + Brother HL-3170CDW series._printer._tcp.local + Brother HL-3170CDW series._ipp._tcp.local + Brother HL-3170CDW series._ipps._tcp.local + Brother HL-3170CDW series._ipp-tls._tcp.local + Brother HL-3170CDW series._http._tcp.local + John's Air2._companion-link._tcp.localAs you can see it finds my nas that is on my lan network, and printer that is on my wlan network... And I can see the packets being forwarded via avahi.. And it also finds my ipad it seems on the wlan network.
Which I have setup like this
with only lan and wlan selected..
I see no blocks about antispoof.. If I sniff on my wan I see zero mdns traffic...
I then turn off avahi and now mdns-scan does not find my nas.. It only finds stuff on that same network printer and my ipad, which is the 192.168.2/24, and my lan above is the 192.168.9/24
So I can not duplicate what your seeing.. So your going to have to provide more info.. Lets see if I select my wan, in avahi if I see blocks... I don't think I would because its not ingress it would be egress..
BRB..
Well that is impossible - it doesn't list my wan to pick... So again I can not duplicate your problem.. Using avahi to allow mdns across 2 networks.. Works just fine... No traffic is sent out wan interface, via sniff.. No logs are being seen about antispoof... mdns traffic is being forwarded via avahi..
So there is either something else going on with your install.. Or you have a loop in your network?? Or what you think is your wan is not really your wan? Do you have PPPoe? Do you have multiple wans? etc etc.. Are you using other packages as well for multicast, igmp proxy, pimd? Do you not have a gateway on your wan interface, and manually set a gateway? Are you not doing nat on your wan... What is different with your setup other than default out of the box turn it on pfsense..
I can not duplicate your issue, and from my testing avahi does exactly what its suppose to do.
-
Just as a thought, @MG85 tcpdump showed
19:09:14.933859 00:0d:b9:52:xx:xx > 01:00:5e:00:xx:xx, ethertype IPv4 (0x0800), length 88: (tos 0x0, ttl 1, id 64688, offset 0, flags [none], proto UDP (17), length 74) WANIP.20743 > 224.0.0.251.5353: [bad udp cksum 0x996d -> 0x4a51!] 2400 PTR (QU)? _services._dns-sd._udp.local. (46) 19:09:14.934402 00:0d:b9:52:xx:xx > 01:00:5e:00:xx:xx, ethertype IPv4 (0x0800), length 119: (tos 0x0, ttl 1, id 20152, offset 0, flags [none], proto UDP (17), length 105) WANIP.20743 > 224.0.0.251.5353: [bad udp cksum 0x998c -> 0x75b7!] 2401 [2q] PTR (QU)? _sonos._tcp.local. PTR (QU)? Sonos-949F3E8F1EBA._sonos._tcp.local. (77) 19:09:14.934685 00:0d:b9:52:xx:xx > 01:00:5e:00:xx:xx, ethertype IPv4 (0x0800), length 88: (tos 0x0, ttl 1, id 46782, offset 0, flags [none], proto UDP (17), length 74) WANIP.20743 > 224.0.0.251.5353: [bad udp cksum 0x996d -> 0x4a4f!] 2402 PTR (QU)? _services._dns-sd._udp.local. (46) 19:09:14.935472 00:0d:b9:52:xx:xx > 01:00:5e:00:xx:xx, ethertype IPv4 (0x0800), length 203: (tos 0x0, ttl 1, id 53220, offset 0, flags [none], proto UDP (17), length 189) WANIP.20743 > 224.0.0.251.5353: [bad udp cksum 0x99e0 -> 0x5fba!] 2403 [4q] PTR (QU)? _sonos._tcp.local. PTR (QU)? _spotify-connect._tcp.local. PTR (QU)? sonos7828CA338235._spotify-connect._tcp.local. PTR (QU)? Sonos-7828CA338235._sonos._tcp.local. (161) 19:09:14.936255 00:0d:b9:52:xx:xx > 01:00:5e:00:xx:xx, ethertype IPv4 (0x0800), length 119: (tos 0x0, ttl 1, id 3105, offset 0, flags [none], proto UDP (17), length 105)Would this be what you are looking for? '00:0d:b9:52:xx:xx' is the MAC address of the WAN interface of pfSense.
And in the PCAPs the PTR that is called is _sonos._tcp.local and/or/for spotify-connect etc. etc.
So that doesn't strike me as something coming from his inside from an LG TV?
@MG85 are you running Sonos devices?
If not I'd guess perhaps someone has a faulty setup connected to some Router/Modem that is on the same upstream switch from the ISP and is spweing that out to all devices on the same uplink card/box from the ISP?
I'm running german cable internet on my box and boy do I see weird shit in that segment from some other modems/routers connectedd to the same distribution box as my line...
-
But the source MAC is claimed to be the pfSense WAN MAC.
(Please don't redact things like private addresses and MAC addresses. It only makes it harder to help you.)
-
Ah because of the redaction I didn't see that... damn ;)
Nevertheless Sonos-949F3E8F1EBA seems like a "normal" Sonos device for me (including its MAC in the name, like they commonly do). So I'd check things on my IOT net if there are Sonos speakers in action or drop&block that on WAN if I don't have Sonos running :)
-
@johnpoz @Derelict @JeGr after the great tips you guys have been sharing, I have managed to find the ultimate root cause.
I filtered again the states of the WAN interface, filtering on port 5353. You can see that there is traffic initiated.
I redacted the WAN IP address, but left the port visible. This is of course not what I expected, as mDNS normally only establishes traffic over UDP/5353. In this case it's 43075.Secondly, I went into the states again, filtering on the IOT interface this time. This is the result:
Here you can see that the TV (192.168.20.2) initiated traffic to 224.0.0.251 with the local port 43075. Same port that I saw on WAN.The firewall log shows the same traffic being dropped:
Right.. I am getting somewhere :-).
I went ahead and edited the mDNS allow rule to only allow mDNS traffic with the source port being 5353.
I never set the source port before, as I implemented things according to some nice tutorials on Youtube.
After the filters were reloaded, I deleted the single connection I mentioned earlier that was still open on the WAN interface.
I also noticed that the reject rule I put in place was no longer logging traffic. Great!Summarized, it was indeed the TV that was using a random high port to establish mDNS traffic, and even though the destination was set to :5353, it seems to have taken a different route, towards WAN. Something I still can't explain why.
I have now corrected it, and it works like a charm.
@johnpoz @Derelict there is one thing however I would like to have your advice on, which is the fact that Avahi seems to be having 2 sockets open, one on :5353 and one on a random high port.
Do you see that as well in your setup? (Diagnostics > Sockets):
.Again, MANY thanks for your help!
-
@MG85 said in mDNS traffic from WAN to 224.0.0.251:5353, but why? Please help.:
it seems to have taken a different route, towards WAN
This is the whole point!!! Doesn't matter what source port it was using... There should be no way it can get to wan.. You have a cross over in your L2 networks!!
You have Sonos - that create a bridge.. There is your problem with your L2 networks being connected!!!
But you said your wan is a wire to your modem, and your modem is not running wireless.. Clearly that is NOT the case and you have sonos connecting these two L2 networks together..
-
@johnpoz said in mDNS traffic from WAN to 224.0.0.251:5353, but why? Please help.:
@MG85 said in mDNS traffic from WAN to 224.0.0.251:5353, but why? Please help.:
it seems to have taken a different route, towards WAN
This is the whole point!!! Doesn't matter what source port it was using... There should be no way it can get to wan.. You have a cross over in your L2 networks!!
You have Sonos - that create a bridge.. There is your problem with your L2 networks being connected!!!
But you said your wan is a wire to your modem, and your modem is not running wireless.. Clearly that is NOT the case and you have sonos connecting these two L2 networks together..
Lol. What does SONOS have to do with it, while I have found out the TV to be the culprit? If I tell you the modem is in bridge mode with all routing and wireless features off, it is like that (it is already like that since we moved in here). I manually moved the speakers over to the IOT VLAN, so I know what I did.
For my SONOS speakers I have implemented PIMD which is running just fine for over a year (it even is released as an official package now
), and all of this with strict firewall rules. No strange stuff in the logs, no network loops whatsoever, clearly ruled out.
Yes, Sonos speakers do use multicast (but just for IGMP packets from the speakers and controllers to destination 224.0.0.22). Besides, SSDP is leveraged for discovery (239.255.255.250.1900 UDP) through the app, and broadcast to find other players within the network (which of course is non-routable anyway).This stuff started to happen just after I connected the smart TV. And that was again confirmed as it flooded the logs.
Also, you did not answer my question about the sockets. I would be happy to see if you have just one socket open for Avahi on port 5353, or also have multiple, just like my last screenshot.Thanks.
-
@MG85 said in mDNS traffic from WAN to 224.0.0.251:5353, but why? Please help.:
Lol. What does SONOS have to do with it, while I have found out the TV to be the culprit? If I tell you the modem is in bridge mode with all routing and wireless features off, it is like that (it is already like that since we moved in here). I manually moved the speakers over to the IOT VLAN, so I know what I did.
Because your tcpdump shows nothing from the TV - that's why I was asking you above if you run SONOS speakers in your network. Your dump clearly shows SONOS Speakers making mDNS requests for spotify etc.
Just because you have one time found the same port inside as outside nothing in your screens shows me that actually your TV is causing that - and it shouldn't be able to as mDNS don't travel across network boundaries. That's not how multicast works. Look into my post above:
https://forum.netgate.com/post/913796
-
@JeGr said in mDNS traffic from WAN to 224.0.0.251:5353, but why? Please help.:
@MG85 said in mDNS traffic from WAN to 224.0.0.251:5353, but why? Please help.:
Lol. What does SONOS have to do with it, while I have found out the TV to be the culprit? If I tell you the modem is in bridge mode with all routing and wireless features off, it is like that (it is already like that since we moved in here). I manually moved the speakers over to the IOT VLAN, so I know what I did.
Because your tcpdump shows nothing from the TV - that's why I was asking you above if you run SONOS speakers in your network. Your dump clearly shows SONOS Speakers making mDNS requests for spotify etc.
Just because you have one time found the same port inside as outside nothing in your screens shows me that actually your TV is causing that - and it shouldn't be able to as mDNS don't travel across network boundaries. That's not how multicast works. Look into my post above:
https://forum.netgate.com/post/913796
Apologies for that misleading element. Should have been more clear there.
I made a snippet from just the top few lines, at it would flood the post otherwise.
Now that I made the configuration on the mDNS rule on both interfaces, I at least do not see the traffic hit the WAN interface anymore. I am fairly confident it is the TV, but given the fact that SONOS does not use mDNS, would you still believe it is worthwhile digging into further and doing pcaps? -
Sono's creates bridges that can cause all sorts of issues with this sort of thing..
Nobody gives 2 shits what is creating the multicast traffic - the problem is you have 2 different L2 networks connected.. As have already gone over... Its not possible for your wan to see ingress traffic for a block rule.. Unless something is putting that traffic on the L2 network your wan is connected to..
What creates the multicast traffic is not the real problem.. The problem is your have your wan and lan side networks with something bridging the 2 networks together..
Sonos is known to do this! Google Sonos network loop..
Do you have sonos? Your TV could be doing this too... Something is putting traffic on your wan that shouldn't be there.. Its the only way that antispoof rule would kick off on ingress blocks!
-
@johnpoz said in mDNS traffic from WAN to 224.0.0.251:5353, but why? Please help.:
Sono's creates bridges that can cause all sorts of issues with this sort of thing..
Nobody gives 2 shits what is creating the multicast traffic - the problem is you have 2 different L2 networks connected.. As have already gone over... Its not possible for your wan to see ingress traffic for a block rule.. Unless something is putting that traffic on the L2 network your wan is connected to..
What creates the multicast traffic is not the real problem.. The problem is your have your wan and lan side networks with something bridging the 2 networks together..
Sonos is known to do this! Google Sonos network loop..
Do you have sonos? Your TV could be doing this too... Something is putting traffic on your wan that shouldn't be there.. Its the only way that antispoof rule would kick off on ingress blocks!
Yes I have SONOS speakers, and yes you are correct on network loops and SONOS, but this only happens if one (or more) speakers are connected via cable to a switch that has spanning tree protocol not configured correctly. Only then you will have high chances of loops.
All of our SONOS speakers are on wireless LAN (UniFi AP, even with dedicated SSID for IOT stuff), no single speaker is connected to the LAN wired. See here. I don't see the relation, but this could very well be me. -
Well clearly you have something putting the traffic on the network your wan is on - because your seeing it!!!
Find out what that is for the correct solution!!!
-
Yep, thanks.
I love your tone of voice by the way. From your posts you can see you are excited definetely, but unfortunately also sometimes read half of the posts, and repeating yourself with information you have already shared.
Have a look at my post from yesterday where I found two other individuals posting the same. Posts are dating one year back. Even one here on the Netgate forum. I would be astonished if they had an identical setup just like me at home
.Anyway. Let me finish then by thanking you, @JeGr and @Derelict again for sharing some good insights. Thanks guys.
-
@MG85 IGMP snooping in Networks enabled?
-
@MG85 said in mDNS traffic from WAN to 224.0.0.251:5353, but why? Please help.:
be astonished if they had an identical setup just like me at home
And why is that - I have seen many a user with sonos speakers and bridged L2 networks.. It a very common issue with sonos.
-
@johnpoz said in mDNS traffic from WAN to 224.0.0.251:5353, but why? Please help.:
And why is that - I have seen many a user with sonos speakers and bridged L2 networks.. It a very common issue with sonos.
Indeed. Had to hassle with them, too, as sadly they don't speak RSTP and shook the whole network apart. After that switched to old STP and configure the weights correctly before they understood that LAN was the better alternative to meddle with flaky WiFi from one speaker to another. Really a shame, that they run a good nice WiFi mesh but have no switch whatsoever (like an expert mode) to really switch WiFi off and just use the cable I plugin. But now they all use LAN over WiFi even when they need a bit of time (thanks to no RSTP). But that aside - complex or strange setups like putting Sonos in their own network etc etc are not that far out :)
