Casting to and controlling Google devices on different VLANs

[Banister5024]

I'm pretty sure this has been asked several times. I found a bunch of posts with suggestions but so far I haven't managed to make it work so figured I'd ask here again.

I think it's a pretty standard arrangement. I have a bunch of Google Assistant devices (speakers and hubs) that I want to put into a dedicated IoT VLAN but I would like to still be able to cast to them and control them using the Google Home application.

I've seen posts and guides saying "Just install the MDNS repeater and enable it" and I've done that following the documentation here. It does something because scanning for devices from my phone shows the one in the other VLANS and if I disable it they disappear but I can't connect nor cast anything to them. I tried putting a blanket "allow all from anywhere" rule in the firewall for that interface and no luck.

Am I missing something?. Any idea on how I can troubleshoot this?.

Another thing I tried was the UDP Broadcast Relay plugin that seemed to have more options and a more involved configuration but still no luck.

[WaffleIron]

Hi Banister,
First, I recommend you do some reading on multicast, IGMP, and PIM to understand how google devices (and others) magically work when everything is on one VLAN.

At a very high level, these DLNA/mDNS devices use multicast instead of unicast to communicate.  If all your vlans are on the same device, IGMP is needed to support multicast communication between them as it can track the IGMP snooping groups.  If there are other devices/routers/switches between the vlans, PIM or some other mechanism is needed on all the devices to route multicast subnets at layer 3 between them and using an established rendezvous point.

pfsense added a PIMD package a couple years back and it worked perfectly.  opnsense is still without a PIM package, however, the post below shows how you can install/configure it manually.
https://forum.opnsense.org/index.php?topic=15385.0

For firewall rules, if you want to leave multicast communication wide open but lock down everything you can do it with three permit rules:
any any PIM
any any IGMP
UDP any to 224.0.0.0/4

[Banister5024]

Hey! Thanks for the reply!.

So, I added the rules you mentioned as floating rules selecting the interfaces that I think need to be affected (the IoT vlan, the one where my NAS is for windows samba discovery, things like that). Would you mind checking if this looks right? imgur screenshot of how the 3 rules look like.

Now, onto the actual casting part.

I was having absolutely no luck. I could see the devices on the other side (my phone could see the nest hub) but connection would fail regardless of what I did. The logs/debugging I could see in the terminal didn't really tell me anything.

What you said about things depending on other switches/routers/whatever made me realize that I never actually looked into the rest of the networking gear to see if there was anything there.
I'm using TP-Link's Omada gear for AP and switches and poking around the configuration where I set the VLAN tags for each network there's a checkbox labeled "IGMP Snooping" that's disabled by default (imgur screenshot link). I checked that option and everything started working right away.


Thanks!.


//Edit: Or maybe not. It worked last night before bed but now that I'm trying it again I'm getting the same behavior than before >.>. Still troubleshooting it seems haha.

[Banister5024]

After a bit more troubleshooting.

I'm using the 3 firewall rules I posted above. With these settings for the UDP Broadcast Relay plugin -> imgur link. I enabled IGMP Snooping on the switches/AP like I mentioned on my post above.

What I found out is that if I try to cast from my phone or any other wireless device the connection will work for the first device that tries it. Any other device will see the speaker and will try to connect to it but will never actually start casting. The original device can stop casting, start again, do anything but the other ones will get stuck in that even if the original one already stopped.
This even persists through the speaker itself being rebooted and only seems to clear itself when I restart the wireless network itself.

I can replicate this every time.

For whatever weird reason though. Wired devices do not face this issue. I can start casting on my laptop connected to the LAN VLAN by ethernet -> Works -> Grab one wireless device connected to the LAN VLAN through wifi -> Works -> Grab another ethernet computer -> works -> grab any other number of wireless devices -> Nope! -> Back to the first wireless device -> Still works.

I have absolutely no clue what's going on XD.

[Patrick M. Hausen]

Check your AP documentation for any multicast related settings. Ask in the Omada forum/community for unicast related issues across VLANs ...

[FullyBorked]

You've gotten farther than I have, in three years with OPNsense I've attempted this several times and never made it even as far as you have.  I use Ubiquity gear, so very similar to the Omada kit.  If you figure this out please post up.  I'd love to move my Chromecasts etc off my LAN. 

[EdwinKM]

You've gotten farther than I have, in three years with OPNsense I've attempted this several times and never made it even as far as you have.  I use Ubiquity gear, so very similar to the Omada kit.  If you figure this out please post up.  I'd love to move my Chromecasts etc off my LAN.

Not an option to just create a "media" vlan? Add all your tablets/phone's/receivers to this network. Maybe you have to create some "normal" firewall rules to allow to access some lan services.

[Patrick M. Hausen]

As a rule of thumb put devices that need to communicate with each other in one zone/LAN/burb/whatever.

[nferocious76]

has there been anyone who manage to have a workaround for this?

[yourfriendarmando]

I had a gig where I had to constantly silence one of my teammates promising the world to leadership.

I would counter these promises,  saying, If it's a smart TV, it's going in the Guest network. If you want to cast to this device, get your laptop on the same guest network. Once you're done with your presentation, switch back to the production network to access the server, printers, and faster internet

[HackerWolf]

Hi! First message here for me but I'm an OPNsense user since more than one year.

Last week I changed my home's WIFI APs to finally be able to separate my devices. Among them, a couple of Google Nest Mini and a Bravia Google TV, so with Chromecast built-in. And I've managed to get them working! First, I installed the mdns-repeater plugin (os-mdns-repeater) and enabled in it my main LAN and the VLAN where Chromcasts devices are. Second, since my firewall rules deny any traffic from that VLAN to my main LAN and others VLANs, (so all in this VLAN is "blind" and going straight to the WAN GW, while my main LAN talks to them), I had to disable WCI (Wireless Client Isolation) and Network Isolation in the APs settings (on my APs I can set these option differently for any VLAN).
Moreover, I'm using AdGuard Home from mimugmail repo as DNS service in OPNsense and I had to do nothing more on its side, clients on Chromecast's VLAN and others are correctly shown in DNS logs.
Casting works perfectly and flawlessy, even the remote controller function of the Google Home app for the Bravia TV, and no signs of lag so far.

Since it happened that I installed my new WiFi AP's the next day OPNsense 24.7 was released, I cannot say if my setup works on 24.1 or any previous release, but I'd think yes.
I hope that my experience can be useful for others.

My hardware setup:

• Virtualized OPNsense 24.7 running on Proxmox VE 8.2, on a "mini PC" with 6 Intel 2.5 Gbit NICs, 32 GB  of LPDDR4 SODIMM RAM, 1 TB NVME SSD: OPNsense VM currently has 4 VCPUs and 4 GB of dedicated RAM and it runs very smoothly - be sure to set your bridge/trunk port on Proxmox as VLAN-aware;
• 8-ports Gbit Managed Switch NETGEAR GS108Ev3;
• WiFi Mesh Kit NETGEAR SXK30 AX1800 WiFi 6, 1 Router SXR30 + 1 Satellite SXS30, it supports up to 4 separate WiFi networks, the fourth is by design "dedicated" to the guest network.