Sonos speakers and applications on different subnets (VLAN's)
-
This thread is amazing and helped me get Sonos working with my VLAN's and in the process I learned a bunch of stuff.
For anyone still struggling with this I will give a warning of something that I am not sure anyone has referenced in the hundreds of replies.
Make sure that the interface where the VLAN'S is also added to the "enabled" interfaces. So lets say your VLAN is igb1.70, then you must also include igb1 otherwise it won't work.
Hope that helps.
-
@dennypage I had to use pimd to get HEOS app working on Android. Without PIMD, the app used to hang when I used Music>AV Inputs. The input used to change, but the app used to give an error. This webpage says that multicast traffic is used for HEOS.
-
@trumee That webpage describes UPnP support, which is not required for local network HEOS use. UPnP is generally required for opening ports to allow use/control from outside the local network (WAN).
Avahi provides mDNS device discovery across local segments, which is all that is necessary for HEOS discovery. It's all point to point after discovery. Unfortunately, I can't speak to why you had an issue in your specific case.
-
This post is deleted! -
@pajinha I don't understand your statement. all my interfaces and vlans are enabled. is that what you mean?
-
He is saying you must also enable the VLAN parent interface in PIMD. I have no way of testing that though.
Steve
-
@stephenw10 ok, now that makes sense.
-
I've read almost the whole thread and now I'm unsure, if the effort is worth it.
Of course I like the idea of separating the clients from iot devices.But from a security POV, is it necessary to do that?
Is enabling broadcasting and multicasting over VLANS safer, than just putting Sonos and Clients in the same network with the right rules? -
It is safer. Is it necessary? Only you can decide that really.
It's not designed to work across subnets. I would guess the vast majority of Sonos users have one subnet with servers and clients on it and don't see issues.
The question is if some firmware update suddenly added all your smart speakers to a bot net what other things on your network would that expose? And what sort of risk is that?
Steve
-
@stephenw10
Thanks Stephe for the reply.I'm a little bit overwhelmed by the thread itself. I don't know which solution works. Whether it's PIMPD, Avahi or the UDP relay.
I think the relay looks promising, but isn't in the package manager yet: https://redmine.pfsense.org/issues/10818 Will this be a thing?@stephenw10 said in Sonos speakers and applications on different subnets (VLAN's):
Only you can decide that really
For myself, I'd be thrilled to work this out somehow. But sadly my company network has way bigger security holes to close :( I'll comeback to this thread, when I've time!
EDIT: I tried it with IGMP-Proxy, doesn't work
-
I can only speak for myself and I don't like IoT's that are closed source, be it cam's, Sonos, smart power plugs etc. I have no idea what so ever what they (can) do and how well there operating system is maintained. As an example I have video door cam that has a telnet service running, no idea why this should be and why telnet is chosen and not SSH.
It's like your home, some use a burglar alarm system others only have lock, so each to his own ;)
-
I totaly agree. To be honest, I wish I could trust some companies to do their homework. I can't and don't want to control everything by myself.
-
That's why I like and use pfSense, I want to control the rulez, so what do you (dis)allow to go where. That's why by default every subnet (apart from the LAN) created can go nowhere.
Although a cheap router/fw (albeit from you supermarket) has good ingress block, you have almost no control over the traffic. In pfSense I decide what goes where.
-
@wellcomefit
For what it's worth, I've given up. I've solved the problem three times. Each time it worked for a few months, then stopped working with that solution. I didn't want to devote more time and effort.
I have a Sonos subnet. I've moved my smartphones to that and created rules for their access to other nets where needed. Not much is needed. Access to a NAS from smartphones for storage of pictures and access from the Sonos speakers to the NAS (limited to TCP port 445) for the music library. I use a firewall on the NAS and ACL on the NAS to control what the smartphones can get to.
It's also easy to switch the smartphones to my main data network when I want to get to other things. But I haven't had that need. This is a home environment, not a business environment, so your situation may be more complicated. -
Thank you Stan for the feedback.
I decided for myself that, it's not worth the effort right now. UDP_Relay sounds really promising and if this ever comes officially to Pfsense. I'm willing to give it a try :) Until then, I'll go with your solution and just create a separate VLAN for it and not connect the client and sonos network. -
just chiming in to thank @Qinn here for pushing this all forward, across a few different threads qinn was involved in, I was able to get this up and running in a few hours. I needed pimd, avahi, (both just from the package manager) and four firewall rules (in attached pics), setting an RP address in pimd was also required.
LAN interface Rules
NOTRUST interface rules (where sonos lives)
I might end up moving my sonos system to a sort of intermediary network, originally I put it on the same net as the rest of my iot stuff, but having to grant more trust to the sonos system than the rest of my iot systems.
maybe this helps someone, but really just meaning to say thanks for the forums here! pfsense is pretty cool
-
@packetperson99 Thanks ;) maybe also share your GUI PIMD settings?
-
192.168.40.109 is a sonos speaker -
@packetperson99; @qinn; @wellcomefit
Oh heck, I couldn't help myself. I've tried the solution above and it works. When I first open the Sonos app, it takes about 9 seconds to find the Sonos system. I'm not sure of whether I can stand the repeated anxiety of wondering whether it's going to connect during those nine seconds, so not sure whether I'm going to stick with this solution or go back to having things on the same network.
I do have a question, though. Of the four firewall rules, two are repeats of the other two, just in the different interface. I'm not sure what is accomplished by having a version of the LAN to NOTRUST rule on the NOTRUST interface, and by having a copy of the NOTRUST to LAN rule on the LAN interface. I set it up with all four rules. Then I disabled those two rules and it still works.
I'm not an expert. I'd be interested to understand what the rules do on a different interface. -
This post is deleted!
