Implicit in your post is an acknowledgment that yours is an unsupported configuration. In recent times Sonos have taken various steps to improve the security of the system, including preventing access to port 1400 from off-subnet sources. It could be that the latest developments are a corollary of those increased security measures.
Hi Ratty!
I am not asking for support with this configuration =) So no problem there.
The configuration is fine and has worked for myself and other customers for some time now.
If we were asking for support, as you suggested, then I could see how you might have a very small point to make.
Sonos should be careful about messaging that crossing subnets is an abnormal practice. It’s a common practice, and when Sonos acts unsure about it, it makes them seem uninformed.
Sonos should simply acknowledge that they broke this setup for OSX users, get the message to their techs so they can immediately inform customers who ask, and fix their mistake.
If any kind employees from Sonos are reading, here are some other customers also having a bad time right now after the 10.6 update.
These customers have done nothing wrong, and are not asking for networking support. They just want what worked before to keep on working.
https://en.community.sonos.com/setting-up-sonos-228990/vlan-issue-on-unifi-network-after-10-6-update-on-ios-6833871/index2.html#post16384544
https://en.community.sonos.com/announcements-228985/sonos-10-6-now-available-6832438/index2.html#post16384545
https://en.community.sonos.com/ask-a-question-228987/sonos-control-across-a-vlan-has-stopped-working-6833843#post16384547
Similar to how the Apple update to iOS broke the ability to play from an iOS device, I would assume that if this change was indeed security related, and not just an intentional gimping, you’re unlikely to have it changed back. And in my years here, I have never seen Sonos make any explicit declaration of what security measures have been taken.
Here is why I don’t think this was intentional.
The IOT vendor, in this case Sonos, would be making an assumption that 2 subnets are not supposed to talk to one another.
That decision would only make sense if the IOT vendor had some information about the network to decide that this traffic was unsafe.
Since the IOT vendor here has no knowledge of the customer network, it is not reasonable to make an assumption that traffic between subnets should be considered unsafe.
The IOT vendor should only assume that the owner of the network did in fact intend for subnets to communicate, because it has no information to contradict that assumption.
Also, if it were the intent of Sonos to intentionally break the setups of customers, it seems like that would be a consistent decision across platforms.
And yet, non iOS controllers are still chugging along without this issue, suggesting that Sonos did not intend to make our systems fail under these circumstances.
Having the same problem here and I am really angry that Sonos not even commit they changed something.
Also, if it really is for security reasons, why not just support using the product on different subnets or even „allow“ it? This is the most secure solution in which all other proprietary security measures well fit. The more IoT devices this world gets the more possible security threads could appear...
In the tech world this is called a REGRESSION. A customer use model used to work, then Sonos changed something, and now it does not work. A customer oriented company would react to this as, “ Oh no, we broke something!”
Maybe the breakage was unintentional and there is an easy way to get it working again. Or an easy work around.
Or Sonos can say sorry, buy someone else’s products from now on.
Its not a regression if it is an unsupported configuration and only worked by accident in the past.
If a customer is technically savvy enough to figure out how to get it to work across VLANs, then that person should be able to figure out exactly which packet(s) are not making it across the LANs any more, and provide a solid description of the problem. The best theory I saw was the TTL value changing, but as I’ve never tried cross-LAN connectivity I cannot confirm.
SSDP is not a complicated protocol, but to work between LANs a bunch of configuration is required that is very specific to the network hardware in use. A quick web search hit this as an example: https://help.airtame.com/en/articles/1257772-step-4-set-up-auto-discovery-multicast-routing-between-vlans
Looks like it’s not the TTL that is the issue but the Sonos kit now responding on random high UDP port numbers. I’ve updated my original post at VLAN Issue on Unifi Network
The real problem here is that Sonos’s release notes are fisher-price tripe, and what that says about them as a company.
Contrast point. I just got an update for one (1) of the many network appliances I manage at work. It’s not even one of the big core network routers, it’s just an edge device costing the same as a Sonos 5.1 system. Nonetheless, the release notes are 132 pages long, and go into extraordinary detail about every technical change they made, irrespective of whether the configurations that they enable are supported or not.
The equivalent release notes from Sonos:
“Bug fixes”
“Improved menu”
Then it turns out they made significant changes to the network stack, DSP behaviour, voice assistant integration &c.
Do they want to ship high-end gear to sophisticated consumers, or do they want to sell tamagotchi to schoolchildren?
My takeaway: Sonos’s engineers think we are all idiots, and you just need to read this thread to see multiple apologists for that lousy attitude.
Given recent events, it appears their marketing/PR people have the same haha-screw-you-suckers attitude, so I guess it’s just their entire corporate culture that sucks.
