Best Practices - How To Isolate Sonos System? VLANs or Other?

[securedspace]

I'm just getting into PFsense for the first time and am very excited for the possibilities. I'm still learning about networking principles and am having fun so far. What I'd like to do next is learn how to best isolate Sonos from phoning home, stop it from being a attack surface, or doing anything else dangerous.

My setup is: [Cable Modem in Bridge Mode] --> [Protectli PFSense Box running DCHP server] -->[DD WRT Wireless Router in AP mode, DCHP server off]

I can either plug the Sonos "base station" into the Protectli box directly, or into the DD WRT Wireless Router, and I think directly into the Protectli box is safer, but please correct me if I'm wrong. I also think giving the Sonos base station a static IP on my internal network is better than DHCP since I can likely make rules easier for a static IP device. But I'm not sure.

My concern is that Sonos might be phoning home, possibly with microphone data, since I think the pre-Echo Sonos units have some form of microphone in them to help calibrate sound in rooms. Sonos recently updated their TOS to make it less private, and I've avoided installing the new software because of it. The new TOS lets them send even more information back to their mothership.

I'm not using Sonos to connect to any 3rd party audio servers (such as Spotify), so as far as I'm concerned, Sonos does not need to talk to the outside world at all, unless I manually decide to allow a software update. However, I am concerned I can't segregate it from everything else, because I still want my iOS and OS X devices to be able to control the Sonos unit, which requires it be on the same WiFi network. So I think the best course here, using my non-technical understanding, is to keep Sonos on my primary network, but tell PFSense to disallow any outgoing connections through the Gateway (my cable modem).

Any thoughts on where to start?

[hbauer]

I am thinking into the same direction. My current idea is to give all sonos devices a specific adress and to deny access to the internet via rules.

In case of updates you could disable this rule for a short time.

This is not perfect but probably pragmatic

[virgiliomi]

I think with what has been posted, blocking your Sonos IP address(es) at pfSense would be the best way to go.

However, just so you know, you'll also want to turn off automatic app updating on your mobile devices too, because otherwise when Sonos releases an update, your mobile devices will get the new app, then constantly prompt to update your Sonos devices until the versions match.

Pro tip for the firewall rule: If you have multiple Sonos devices, group them together within the address range of a smaller subnet size. For example, I have my Sonos devices between x.x.x.177 and x.x.x.190. By doing this, I can create one firewall rule for network x.x.x.176/28 on my LAN to block all of my Sonos devices easily.

[securedspace]

Pro tip for the firewall rule: If you have multiple Sonos devices, group them together within the address range of a smaller subnet size. For example, I have my Sonos devices between x.x.x.177 and x.x.x.190. By doing this, I can create one firewall rule for network x.x.x.176/28 on my LAN to block all of my Sonos devices easily.

Interesting, I do have multiple Sonos devices, but haven't dug into the config for it yet. I assumed the one Sonos device that is acting as a bridge is receiving an IP via DCHP from my PFSense box currently. And then that Sonos Bridge (a playbar) is running it's own form of DHCP across it's proprietary wireless network it creates with the other devices.  I haven't gotten around to checking to see if each Sonos device is getting an IP from the PFsense box, nor have I assigned Sonos a static IP yet, which I think is prudent to help with rules.

Do you think it's worthwhile to keep a spreadsheet handy with every static IP assigned on my device and perhaps the MAC addresses of all of my devices, so that if things get wonky, I at least know the MAC address of each Sonos device and can try to backtrace issues based on that? If so, is there any format that works? I'm just thinking simply:

Name of Device (Sonos Playbar, Xbox One, Apple TV, etc)
Physical Location of Device (bathroom, bedroom, etc)
MAC Address of Device
Static IP of Device
Connection Type (Wireless to AP, Hardwired to PFSense Box, Hardwired to Sonos Playbar, etc)

If something breaks once I have it set up, it would be nice to have a tool like this built in advance.

[virgiliomi]

Nope, the Sonos devices will all still receive addresses from your DHCP server. The Sonos mesh wireless network is just an extension of your existing network.

Do I find a spreadsheet useful? I used to long ago, when I would give static IP addresses to devices that needed to be manually configured... but now I just use DHCP reservations instead (so if I take a device somewhere else, it can still use DHCP without me needing to change anything), and I can see what's being used through the Status > DHCP Leases page. A spreadsheet could be helpful if you decide to set up a new router and either want to start with a clean configuration or can't import (if you go to a completely different platform) so you can set everything back up... but you could just copy/paste the data from the DHCP Leases page into your favorite spreadsheet application or print the page.

[Programie]

I've done something similar with all my IoT devices. But I've gone a bit further: All of them are in a VLAN having any outgoing traffic to any other network (WAN, LAN, etc.) rejected by default. Only my defined list of rules are allowed.

I've even redirected all DNS queries to pfSense (NAT TCP/UDP port 53 to 127.0.0.1), so they can't even use any freely chosen DNS server like Google Public DNS. All DNS traffic is sent to pfSense so I can log DNS queries and find out which hosts they are trying to reach (and maybe open them in the firewall if required).

In my case I'm using Ubiquiti UniFi Access Points which allow to create multiple WiFi networks with different VLANs, so even wireless devices can be restricted to a specific VLAN. I'm not sure whether that is going to work with DD WRT.