· None of the above quite fits
· None of these quite match
· My JBL Boombox 3 WiFi is no longer appearing as a Roon device
· I am 100% Ubiquiti. Roon server is on a 10 gb ethernet. Boombox is wifi, obviously.
Hi @JS_Gladstone,
Thanks for writing in and for sharing your report!
The first thing I would review is your local subnets within your local network. From your account admin, it looks like you may be running multiple subnets, and it could be the case that your BoomBox 3 is running on a different subnet than your Roon devices.
Note that all Roon devices need to be on the same subnet for proper functionality. Here’s more info on this:
Let me know if you’re able to access your devices list within your router settings to confirm or deny this. Thank you! 
I have mDNS repeating across vlans, and both chromecast and airplay2 work across the vlans. Is ROON’s use of mDNS different in some way from these two mDNS based protocols?
Not sure if you saw my previous post.
Hi @JS_Gladstone,
It’s unclear if you’ve run through the troubleshooting steps I’ve listed above. Were you able to give that a try?
Roon needs more than just mDNS to do its job, and from a fresh server diagnostic report, the JBL Boombox 3 has never appeared in the servers discovery at all, there’s no record of it being seen, attempted, or rejected. All other working devices look to be on the 10.7.67.x subnet alongside the server.
Can you please confirm:
Hi @JS_Gladstone,
Can you share the actual network topology involved between your server and this endpoint? How many APs or managed switches are in between?
Roon’s use of mDNS has similar device announcement mechanics to Chromecast and AirPlay 2, but there are a few differences that can cause issues even when those two work fine.
The next thing to check is whether your inter-VLAN firewall rules allow the full unicast traffic Roon needs after discovery, not just the Cast handshake ports. Roon requires broader TCP/UDP access between the Core and the endpoint than a standard Cast client does. For RAAT, Roon needs to maintain a sustained TCP connection to the endpoint. Keep in mind that RAAT is uncompressed and vulnerable to WiFi interference, and too many dropped samples due to packet loss.
Could you confirm: when you browse to Settings → Audio in Roon, does the Boombox 3 appear at all (even greyed out or intermittently when you turn it on), or is it completely absent? Also, are there any firewall rules between the VLANs limiting traffic beyond mDNS?
Connor -
Thanks for following-up. What ports do I need to make sure are open between VLANs?
Regarding the wifi side of things, the endpoint works flawlessly both via Airplay2 (on either vlan) and via RAAT (only on the same subnet as the server), so that does not appear to be an issue. It also used to work (i.e., both show up and play) as a RAAT endpoint on the IoT vlan, and nothing I can identify has changed on my end since.
Thanks again for continuing to explore this with me.
Hey @JS_Gladstone,
A few additional thoughts on this.- your mDNS repeater handles discovery, but the actual audio streaming traffic may be hitting firewall rules between VLANs. Make sure inter-VLAN traffic is permitted between the Roon server’s subnet and the Boombox’s subnet.
_roon._tcp and _raat._tcp service types specifically — not just the types needed for AirPlay (_airplay._tcp, _raop._tcp) and Chromecast (_googlecast._tcp).