mDNS traffic from WAN to 224.0.0.251:5353, but why? Please help.

JeGr

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...

Derelict

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.)

JeGr

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!

johnpoz

@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.

JeGr

@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?

johnpoz

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.

johnpoz

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.

laser22

@MG85 IGMP snooping in Networks enabled?

johnpoz

@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.

JeGr

@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 :)

johnpoz

^ 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.

JeGr

@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).