SoundTouch on different subnet

[netfreak]

Hi,

I cannot connect to my speakers from a different VLAN/Subnet. 

I have been reading in another post about this being due to security reasons. I really cannot see where this provides any security. Due to me it just creates hassle.

A quick fix is to run a mDNS proxy and simply masquerade the client subnet towards the SoundTouch subnet. So there is no security enhancement at all for private subnets.

In a corporate context this is a reason to ban Bose SoundTouch. To decide if another subnet should not be allowed to connect is a task for a firewall!

Please change it and allow incoming connections from all private address spaces:

10.0.0.0/8
172.16.0.0/12

192.168.0.0/16

fd80::/8

If this is not changed, we cannot install these speakers in our enterprise.

[akhileshb]

I'm having a similar issue. I called the bose support helpline today for multiple issues (this being one of them) and the answer I received is that "Bose will look into it when multiple people have this issue". It is uncalled for in a way to get that answer when you pay a premium for these systems. Disappointed.

[Hector_B]

Hey Netfreak and Akhileshb, 

Thank you both for posting and providing us with feedback on this topic. 

The majority of our customers that use the SoundTouch speakers are customers that use the speakers in home environments rather than enterprise environments which is why the speakers are designed the way that they are. I would love to forward this feedback that you have provided us with above to the appropriate teams for future consideration. 

If you do have any other suggestions for the speakers please do let us know below. 

Kind regards, 

Hector B - Community Support 

[netfreak]

Hey Hector B,

thanks for following up on this.

Just some more things to consider. It is not just enterprise environments. I'm lacking the ability to connect from a different subnet in my home environment. It might not be the avarage environment, but...

If you google a bit, you will see a lot of people talking about seperating out there media network on a different SSID or VLAN. If you want to keep your performance up, that's the way to go.

Also it really does not provide any bit of security. Simply do a NAT and you passed around it.

I could see a security point, if you block public IPs and just allow private address spaces as I suggested above.

By the way, the Bose SoundTouch App is continously crashing on my Android Samsung S7. I unable to configure the Speaker via the App. Always when I select WiFi after the software update check it crashes. I already send in a bunch of error reports with stack trace.

All the best!

[guelcki]

Hello Hector_B!

I am using the Soundtouch at home in a consumer environment. I just bought all the network equipment to separat the network for the parents, the children, guests and IoT. All of them should have access to the Soundtouch devices within the IoT VLAN.

I think, this a setup that will be used more and more also for consumer! It is really annoying, that this is just another SW issue of the Bose equipment (or maybe only poor systems engineering during design phase).

Is there a plan to just use network standards established long time ago also for Bose Soundtouch? 

Otherwise I have to sell all my Bose equipment again and buy Sonos devices. With Sonos such a network segmentation is working.

But, to be honest, as I am already not really satisfied with the software quality of the Bose equipment in the past, I am pretty sure, that I will never buy Bose equipment anymore in such a case.

Kind regards

Timo

[Ns526]

@netfreak @akhileshb 

I have the same problem. IP masquerading sounds good in theory, but what about discovery and mDNS?  mDNS broadcasts encode the source IP; I currently have an mDNS responder in my AP broadcasting services across VLANs as needed. I suppose that would need to be altered somehow...

@Hector_B In 2020, virtual segmentation is not unusual, even for home networks, and it comes in many forms. I'm guessing that you guys (Bose) likely did this after the Soundtouch was demonstrably hacked (link here). Instead of actually addressing vulnerabilities in the servers running on the device, you needlessly crippled the device. Frankly, the solution sounds like a one-off quick-fix. This is a pattern of longstanding software issues with Bose (this and the Airplay 2 debacle come to mind) it seems that your management has been completely disrupted in the transition to IoT. 

As your core competency is power electronics and acoustics, take a note from forum users who take network security seriously and know what they are doing (some are, I dare say, even IT professionals)

If you don't want to do that, at least take a note from Apple, a company much larger than yours and with far more market penetration / devices in every home: the Apple TV is not restricted to connections from a particular subnet.

At the very least, you could have an option in the Soundtouch app to undo the damage for those of us who need it, but as you have been unable to manage the relatively simple task of including bass and treble controls in the app I am doubtful that you will be to address this issue.

[DMal]

Agree, this is a much needed feature.  I'm a home user, and want to segregate my network for performance and security reasons.  I also give advice to others as to how to set that up.  I cannot recommend Bose for this reason, and dissuade people from buying your product until you support VLAN/Subset isolation properly.

Dan

[mp2020]

I am just now running into this issue with my new home network.  I am coming to an end with Bose since it seems every turn runs me up against some non-industry standard and seemingly arbitrary configuration limitation.  This one appears deliberate.  I long ago stopped running video through the LifeStyle 600 due to crazy stuff happening with the image and signal.  It only manages the sound now.  And now there's this mess.  Please update the software across the board so that the soundtouch app can connect in this totally reasonable way. 

[ShadesJeff]

I wasted this afternoon trying to debug why AirPlay 2 is working correctly across my subnets to everything except my three SoundTouch speakers (two SoundTouch 20 Gen IIIs and one SoundTouch Wireless Adapter).  This was immensely frustrating and I am glad I came across this forum post and realized there's no way  I can make it work or I likely would have wasted most of my weekend on a futile attempt.

I echo the comments from others in the thread that the on-device firewall restrictions need to be opened up to accept connections from (minimally) all non-publicly addressable IP address space.

I am hoping Hector will be able to provide some insight as to if/when we can expect a software update with this change...

Thanks,

Jeff

[zhennTil]

---

@Ns526 wrote:

@netfreak @akhileshb 

I have the same problem. IP masquerading sounds good in theory, but what about discovery and mDNS?  mDNS broadcasts encode the source IP; I currently have an mDNS responder in my AP broadcasting services across VLANs as needed. I suppose that would need to be altered somehow...

This may not apply to SoundTouch, but it works for me on a similar setup with an isolated IoT network, a Soundbar 500, and the Bose Music app on a different local network.

I'm running a Ubiquiti EdgeMAX router, with an mDNS repeater and a SNAT rule masquerading traffic bound for the Soundbar's IP.

It could be that the mDNS repeater is aware of the masquerade, or perhaps the Soundbar does not have this restriction in place for the discovery protocol. It would be interesting to inspect the traffic on the IoT network, but I haven't gotten around to that yet.