Weird VLAN/Sonos Issue

[RumorConsumer]

So I have several VLANs that I use to partition off various network services and devices. The users get to use one VLAN/SSID combo that has a Chromecast Audio on it as well which connects to my Sonos Play 5 via analog 35mm jack. The Sonos system has its own VLAN/SSID combo which it operates on. This keeps the ability to play music on one network and the ability to admin the Sonos on another. This has worked great forever. I just updated to Sonos' newest software  S2 and updated my whole system. Now, this peculiar thing happens which is that even when I am on the user network, my S2 app allows me to control the system. Previously, it was not able to see it unless I was on their special VLAN/hidden SSID. What is going on? Does the S2 app and firmware somehow penetrate VLANs? Makes no sense to me.

Hmm I wonder if this is why.... from the Sonos SSID config...

Realizing I had duplicated settings from my original SSID that all had Bonjour forwarding to VLAN 1. I bet thats why.

UPDATE - I tested. Thats not it.  

Found some other network jocks having the same issue: https://community.ui.com/questions/Sonos-S2-Still-using-STP/80919618-24d8-4d8a-9031-cd945d85edff?pag...

Does anybody here understand what is going on? @PhilipDAth ? @cmr ?

[PhilipDAth]

Note this.

https://documentation.meraki.com/MR/Client_Addressing_and_Bridging/Bonjour_Forwarding 

"Please note that the service VLAN cannot be the native untagged VLAN, which is usually 1. "

[RumorConsumer]

@PhilipDAth Yes, I just did that reading. That was a mistake. Its been fixed and the issue persists.

So here is the behavior I notice. 

The App has a sign in feature. It works without being signed in, but the behavior is interesting. 

So on a phone that has never been signed in to the app, having just downloaded the app, when the wrong VLAN/SSID combo is chosen, it does not see the Sonos instance. Great. As expected. Thats the main behavior I want to avoid. 

When I get on the right SSID for Sonos with the App not signed in, it sees it and can control it. Great. Expected behavior. 

When I sign into the app, and then leave the right network/VLAN/SSID, it can still control the Sonos instance. If I disconnect from wifi, it can't. What the hell? 

[GIdenJoe]

Hey @RumorConsumer ,

I would of course start by doing packet captures and analyse the boot up of the Sonos and then what your app does when signed in (that last part requires an OTA over the air capture).

However from your description I have a theory that could use some confirming please.

Assumption 1

The sonos has always used mDNS to announce it's services on the local network in previous software versions.  This confined usage to a single VLAN if not using mDNS bridging/gateway feature.  The actual usage is by unicast messaging.

Assumption 2

The new software still uses mDNS so you can still see the device while not signed in.
But when the device is "registered" it unicasts it's local IP reachability to the account.
When you also sign in using the app, you receive it's local IP and can start using it via unicast.

[RumorConsumer]

@GIdenJoe That sounds plausible. How would you suggest I test and control for the variables? 

[GIdenJoe]

Well a capture is catching all packets and you'd normally see the Sonos communicating with some external server.  If the info is encrypted you won't see that it is in fact communicating it's local IP.

You could also capture on the default gateway of the sonos for messages going to 224.0.0.251 on udp 5353 to capture the mDNS entries.  But that will only prove the Sonos is using mDNS outside of the logging in to the sonos account.

If a capture is too much you can of course create a firewall rule to match all traffic coming from the sonos and log the traffic to a syslog server.  Followed by another rule that matches traffic from your devices IP towards the sonos.