Skip to main content

I’m looking for some of those brave souls that have run the gauntlet and moved their Sonos devices to a dedicated subnet ...

In preparing to move’ my Sonos devices to a dedicated subnet, I’ve read everything (!) I can find on the topic. I’m happy to report I understand nearly all the networking vernacular, AND I’m happy to report my firewall seems up to the task.

The trickiest bit I’ve read about is handling the discovery process, well described here: https://felix-kling.de/blog/2019/sonos-dedicated-vlan.html

As noted, my firewall can handle the 239.255.255.250 multicast forwarding. Yay!

Before pulling the trigger on the ‘move’ and the subsequent beating my head against a wall, I did a bit of packet capture on my existing/normal/everything-on-the-same-subnet setup. The results of packet capture surprised me, inasmuch as there seems to be ZERO 239.255.255.250 multicast traffic … all I see is 255.255.255.255 broadcast traffic. And while the former requires careful planning, the latter is a non-starter.

I am as much a glutton for punishment as the next fellow, tho’ I would sincerely appreciate hearing from anyone who succeeded in the “dedicated subnet” setup. Is your setup still working? 

Putting a finer point on the above … I am wondering if 10.6 broke the “dedicated subnet” setup. Perhaps prior to 10.6 the controllers used a mix of multicast and broadcast … and with 10.6 the controllers ONLY use broadcast making my quest untenable?

I can’t help but just so you don’t feel like nobody is listening.

I looked at the dedicated subnet option a long time ago and decided it was more hassle than I cared for. Tried adding an AP on the Sonos subnet and connecting to it when I wanted to control things and it worked well. After playing with it a bit and looking at the Sonos network usage I just moved the Sonos all over to my private WiFi subnet and unplugged the dedicated AP.

Why are you considering using a dedicated subnet?

The results of packet capture surprised me, inasmuch as there seems to be ZERO 239.255.255.250 multicast traffic … all I see is 255.255.255.255 broadcast traffic.

I would check out your capture process then, or try a different controller device.

When I sniff traffic while a controller starts I see SSDP UDP to 239.255.255.250:1900 (as well as to 255.255.255.255:1900).

 

I am wondering if 10.6 broke the “dedicated subnet” setup. 

Some have found issues after 10.6. And here. Working between subnets is of course not officially supported.

Thanks much for the replies!

I’m a recovering Infosec professional. All of my ‘thing’ devices are on their own subnet, as contemporary history is replete with vulnerabilities in these devices. Those devices are controlled via a server on the Internet proper, so isolating them from my ‘people’ devices does not cause any issues.

I’ve been happily using Sonos for a decade, suppressing the trepidation that a vulnerability allowing rogue wireless connection to Sonosnet would put said ne’er do well squarely on my ‘people’ network.

Having recently upgraded my firewall, I find myself with an unused physical port just sitting there waiting for my to bite the bullet and give Sonosnet its own dedicated subnet.

If I can get the (unsupported) dedicated subnet setup to work, it will be a huge win for the security of my network.

Are you sure it will be a security win if you open up the things LAN to your other LANs?

I see Sonos pulling IPv6 addresses, don’t even want to think about that here as we are on a PD (Cox Cable) system. The v4 stuff was more than enough stress for me.

Give the dedicated AP on the Sonos LAN another look, it may well be the best from a security standpoint.

Good luck and keep us posted as it is an interesting project.

Thanks for the reply, Stanley.

I can lock-down the cross-subnet traffic to exactly the required ports--and the firewall will performIDS/IPS on the traffic--so it would be secure to my liking.

My greatest concern is one that cannot be addressed: having the non-supported setup break down the road, due to an update (cough, 10.6, cough). Getting the setup working now is a one-time investment in time and meditative breathing. Waking up to find that Sonos isn’t working would be another matter.

I agree that your “dedicated AP” approach is equally-or-more secure … and has the benefit of being dramatically more future-proof. Under consideration!

 

With update 10.6 SONOS on a separated VLAN does not work well:

https://en.community.sonos.com/setting-up-sonos-228990/vlan-issue-on-unifi-network-after-10-6-update-on-ios-6833871

 

---EDIT: Sorry for double post, haven’t seen @ratty s “hidden” links. ;)

Good news: minimum of punishment, few bruises
Bad news: “dedicated subnet” does not work … at all

  1. Setup a single Sonos device on the ‘new’ Sonos subnet … WIRED to reduce variables
  2. Setup necessary firewall rules to route traffic (across the board: ANY protocol for starters)
  3. Setup multicast for discovery (controllers to device) and mDNS (device to controllers)
  4. Power cycled the whole shebang
  5. Device snagged a DHCP address, YAY!
  6. Device performed a boatload of (apparently unsuccessful) mDNS activity
  7. Controller (iOS and Windows) performed a boatload of (apparently unsuccessful) multicast and broadcast activity
  8. Attempted combinations of resetting, setting up a new Sonos system, and yelling at stuff

While I did not perform full-strength packet sniffing, I strongly suspect the multicast(s) are at fault. I’ve setup the multicast rules per the firewall instructions (read them TWICE), but we all know multicast forwarding is a fickle proposition.

Open to suggestions!

Terms & ConditionsCookie settings