Sonos speakers and applications on different subnets (VLAN's)
-
It seems to be the pimd itself… :-)
Ranpimd -q
and then
pimd -c /var/etc/pimd.conf
again.
Now there was noe error.
But I can still not get multicast between sonos vlan and app vlan (iphone).
So I'll come back as soon as I have given up... -
Has anyone been able to discover new SONOS devices across VLANs?
I can now connect to my Sonos system from my wireless VLAN (sometimes the iOS app needs the wifi turned off and on to detect the Sonos speakers but the desktop app is very stable).
What I have been unable to do is add a Sonos component (even when my phone is on the same Sonos VLAN). I have been attempting to add a Sonos Bridge but the app cannot detect it. I have tried with Avahi, PIMD and IGMP. Next attempt is turning on UPnP
-
@edz said in Sonos speakers and applications on different subnets (VLAN's):
Next attempt is turning on UPnP
How do you think that would work??
(even when my phone is on the same Sonos VLAN).
if your on the same vlan as the device and it doesn't work - how do you think its going to work across vlans? Look to problem with your wireless..
-
Sorry for reviving an old thread but my question still felt related to this topic.
@Qinn Thank you making this guide. I was able to get multicast working across vlans because of your guide and some others here.
So my question is has anyone narrowed down the exact ports/rules to have Sonos & multicast work across vlans while denying other traffic from their IOT vlan to 'production' vlan?
I tried a rule set that @vacquah mentioned but as soon as I enabled my Deny All rule at the bottom of the rule stack, everything stops working. Only difference is that I have the allow rule working for the entire net vs a single IP/device.
-
this is what my iot lan rules look like .... I am sure it can be improved, but this works for me.
-
Thanks for your help. I liked how you set up your 'out to wan' rule so I attempted to duplicate that and a few other rules. I got this to work maybe once or twice this morning but after I came home from work it just decided to fail on me again. I left pimd running too so I'm not sure what's up.
The weird part is, if I hook my phone (android or iPhone) to the IoT net then immediately switch to the LAN net, the communication isn't broken and I can control Sonos as long as the app isn't terminated. But if I terminate the app, then switch the networks, it acts like it cannot find the Sonos.
My LAN side has the special packets allowed to any. The only other thing I can think of is that when installing pimd, it gives me this warning that there is a version mismatch between it and the kernel running on the router. Perhaps I'm missing something?
-
Just a few thoughts...
@WolfTech12 First, thanks for the feedback and good to hear this thread helped you!I have a subnet (VLAN) just for my Sonos devices. This way, the port access I grant these Sonos devices on my LAN is only for them. When you choose to have a IoT subnet filled with many devices, please note that when using the rule-setup (thanks @vacquah for sharing) it best it has an alias for the Sonos devices like "sonos_devices" and an alias for the applications like "home_devices", but you did not and thus you will grant all IoT devices access to the Sonos_ports on all your devices in your LAN.
Second, I would never use an inverted rule (so using the !) to combine things, so to allow access to the internet and rejecting/blocking private subnets in one rule. I always use a direct reject, block or pass.
Here on most subnets I use:
a pass rule from net to address to access port 53, then
a reject net to access the firewall, then
a reject to access RFC1918 and finally
a pass (IPv4) to access all -
If you're running 2.4.5 or 2.5 snapshots (or are able to) you might want to test the new pimd package to make sure it can be configured for this role.
Steve
-
I'll just say, since I just spent a while scratching my head, that you probably want to leave the Default Bind value at 'Bind to None' and then enable the interfaces you want set as 'Always Bind'.
That results in a conf file that looks like:
/var/etc/pimd/pimd.conf################################################################### # This file was created by an automatic configuration generator. # # The contents of this file will be overwritten without warning! # ################################################################### phyint igb2 enable phyint igb0 enable
Steve
-
-
@stephenw10 Sorry I can't test it, as I have no 2.4.5 or 2.5 operating at the moment. only 2.4.4 . Btw "Bind to none" is different from the default config file, as that one enables all the interfaces by default, so you had to disable the ones that should not be used. This approach (Bind to none by default) seems more logical
-
Yeah, it's not the pimd default but seems better to me. You have to explicitly define the interfaces you want it enabled on.
Steve
-
I enabled pimd for 2.4.4-p3 as well now, so anyone can install it.
As for the default behavior, I deliberately chose the more secure mode. Less room for error there, and I wanted to ensure that a user had to explicitly choose to activate it.
Makes it slightly more difficult to configure but it's also more difficult to create a broken or insecure config.
-
@jimp You made my day! Thank you!
Do you have tips on how to confiure it? The only thing I do manually is to do disable non sonos interfaces by doing this:
phyint mvneta0 disable phyint mvneta1 disable phyint mvneta2 disable phyint ovpnc2 disable phyint ovpnc4 disable phyint mvneta1.1002 disable phyint mvneta1.1004 disable phyint mvneta1.1005 disable phyint mvneta1.99 disable
How does this translate to the new plugin? I understand I have to go the other way - enable only the interfaces I need. How do i do that? And anything else? What about Avahi? Do we still need it?
-
Just install it, enable it, add the interfaces you want it on with binding set to always.
If you really want to blacklist interfaces instead of whitelist, then set the default binding on the general tab to bind to all, then add the interfaces you list there set to never bind.
-
@jimp Going to kick it around now! .... and avahi? . Is it still needed to make multicasting work? Or pimd is the one multicast plugin to rule them all ?
-
pimd does not replace Avahi
-
So I installed and enabled it. I set the default bind to "bind to none" and only enabled the interfaces I need with "always bind" I removed the previous pimd I installed manually. I then reboot my machine.
I see pimd service running. I also see only the two interfaces I enabled in the pimd.conf file at /var/etc/pimd/pimd.conf.
But my sonos app is not working anymore . Also I don't see pimd when I run a "top" command in diagnostics. I used to see it listed there in the output. Did I miss anything?
EDIT: Sonos app started working. Took awhile - maybe 5 minutes. But everything started working. I will monitor it for awhile and report if something comes up.
-
If you removed the pimd you installed manually after installing the package, it might have taken out something needed by the new pimd.
In case others are in the same situation, to be safe you should uninstall the third-party repo copy before installing the new one.
You may want to uninstall and then install the package again (don't use the reinstall link) to make sure that all of the components are there.
-
Sonos worked for me prior to installing pimd but the iOS app would always fail to find the system then I'd turn wifi off and back on that would allow the app to find my Sonos speakers. Thought I'd give pimd a try to see if it resolves the issue, wifi clients are on VLAN 192.168.20.1/24 and Sonos is on 192.168.50.1/24, no change in behaviour. I opened up IGMP on VLAN50:
Virtual Interface Table ====================================================== Vif Local Address Subnet Thresh Flags Neighbors --- --------------- ------------------ ------ --------- ----------------- 1 192.168.1.1 192.168.1 1 DISABLED 2 192.168.0.3 192.168 1 DISABLED 3 192.168.10.1 192.168.10 1 DISABLED 4 192.168.20.1 192.168.20 1 DR NO-NBR 5 192.168.30.1 192.168.30 1 DISABLED 6 192.168.50.1 192.168.50 1 DR NO-NBR 7 10.1.90.1 10.1.90/24 1 DISABLED 8 10.1.70.1 10.1.70/24 1 DISABLED 9 192.168.20.1 register_vif0 1 Vif SSM Group Sources Multicast Routing Table ====================================================== --------------------------------- (*,*,G) ------------------------------------ Number of Groups: 0 Number of Cache MIRRORs: 0 ------------------------------------------------------------------------------