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
-
@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 :)
-
^ exactly.. You know what else is really common... Users using wifi on their isp device, while pfsense is behind it.. So you got something like a sonos that thinks is a good idea to bridge shit <rolleyes> Plugged into a wire on the lan, and using the wifi that is on the wan - and you run into shit like this..
Here is the thing, pfsense is not going to block shit with its rule on egress, even if was the wan putting it on the wire.. Since the rules are inbound rules, ingress..
So somehow that traffic is becoming inbound to the wan interface.
-
@laser22 said in mDNS traffic from WAN to 224.0.0.251:5353, but why? Please help.:
@MG85 IGMP snooping in Networks enabled?
Yep!
-
@JeGr said in mDNS traffic from WAN to 224.0.0.251:5353, but why? Please help.:
@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 :)
This means, like I indicated before, that this loop behavior only occurs when using SONOS over a wired connection. The change of RSTP > classic STP and root bridge size of 4096 is only required then. Setting these values while you have connected the speakers joined to your wireless network (like I have, with my 2 UniFi AP AC Lites, who are the only devices at home broadcasting wifi signal) is of no added value. At least given the dozen articles I have read about it on Reddit, SONOS forum, and relevant other Google searches that came up.
-
@MG85 said in mDNS traffic from WAN to 224.0.0.251:5353, but why? Please help.:
Setting these values while you have connected the speakers joined to your wireless network (like I have, with my 2 UniFi AP AC Lites, who are the only devices at home broadcasting wifi signal) is of no added value.
For me it is. I don't want them on my Unifi WiFi and I don't want them to use WiFi at all, as there are so much freakin' 2.4GHz WiFis on my premise it's insane. Thus my Unifi WiFi AP only does HT20 on 2.4 and HT80 on 5GHz and has band steering towards 5GHz. Most devices I have can use 5GHz and those who doesn't aren't that speed dependend.
So the last I wanted was another 2.4GHz WiFi that's why every speaker has its LAN cabled and proofed. And if Sonos would get their shit together and actually DO what you select in their app - namely disable WiFi for Room X - I wouldn't have to deal with (R)STP or their bridging of interfaces etc. Just down that freakin' WiFi Interface if I disable it.As for "no added value": Without LAN cabling: 3 of 5 speakers have yellow/red status in their WiFi-Mesh-Matrix. With LAN and STP all speakers fall back to LAN, have better latency and ping and no bandwith problems at all (all green matrix). Shame they think they're smarter then their customers (and disabled the options to manually disable the wifi if in their speakers).
