Google Chromecast on a separate VLAN with UniFi Security Gateway
By: Andrew Besford
Tags: Networks, Chromecast, Home Networking, Unifi, Home Network

I have a separate “Internet of Things” network to limit the potential impacts from untrusted devices around the house. I wanted to have the protection of putting Chromecast devices on this network, and still be able to cast to them from devices on the trusted and guest networks.

I figured this out after a lot of searching and finding inconsistent answers. Hopefully it might save someone else some time. My network is built around a UniFi Security Gateway (USG3), a UniFi US-8–60W Switch, UAP-AC-Pro Access Points, with the controller running on a first generation UniFi Cloud Key, all with latest stable release software as of February 2021. It might work for you if you have a similar setup, though it won’t work on a UniFi Dream Machine (UDM) for reasons described below.

The UniFi recommended approach

Ubiquiti have a support article on UniFi Best Practices for Managing Chromecast/Google Home which goes through how to configure a UniFi network so you can cast to Chromecast devices on a separate VLAN. Problem solved?

I followed these instructions including:

Creating a separate SSID/VLAN

Enable IGMP snooping — on ✅ (Networks section, works only if you have a UniFi Switch) — Networks need to manage broadcast and multicast traffic because otherwise it eventually degrades the network health. Internet Group Management Protocol (IGMP) snooping is designed to prevent hosts on a local network from receiving traffic for a multicast group they have not explicitly joined. A UniFi article on Managing Broadcast Traffic goes into this in more detail.

(Networks section, works only if you have a UniFi Switch) — Networks need to manage broadcast and multicast traffic because otherwise it eventually degrades the network health. Internet Group Management Protocol (IGMP) snooping is designed to prevent hosts on a local network from receiving traffic for a multicast group they have not explicitly joined. A UniFi article on Managing Broadcast Traffic goes into this in more detail. Enable multicast enhancement (IGMPv3) — on ✅ (Wireless Networks section under Advanced Options)— This limits the multicast traffic that is sent to client devices that aren’t participating in a particular multicast group. Confusingly, some posts online suggest this should be disabled for Chromecast to work. I left it on.

(Wireless Networks section under Advanced Options)— This limits the multicast traffic that is sent to client devices that aren’t participating in a particular multicast group. Confusingly, some posts online suggest this should be disabled for Chromecast to work. I left it on. Enable Multicast DNS service — on ✅ (Services section under MDNS) — more on this later.

(Services section under MDNS) — more on this later. Block LAN to WLAN Multicast and Broadcast Data — off ❎ (Wireless Networks section under Advanced Options) — not mentioned in the UniFi best practices article.

mDNS (Multicast DNS) setting in UniFi Controller

With this configuration, it was possible to cast from a trusted device to a Chromecast on the untrusted network. Great!

But it didn’t work completely — audio groups didn’t appear in the cast target list. I wondered why and wanted to fix this.

Casting to an audio group did work from a device on the untrusted network. So I knew it was something to do with the network configuration.

Going down the rabbithole

Chromecast gets an IP address using DHCP, and then uses a simple multicast protocol for discovery and launch.

This uses the DIAL protocol (DIscovery And Launch). DIAL Service Discovery enables a client to discover a DIAL Server (Chromecast) on its local network, and obtain access to those services. This is achieved by using a new search target within the Simple Service Discovery Protocol (SSDP), defined by Universal Plug and Play (UPnP).

Clients (known in UPnP as a ‘control point’) wishing to discover Chromecast servers send a request over UDP to the IPv4 multicast address 239.255.255.250 and UDP port number 1900.

So the main issues to getting Chromecast to work across networks are:

Multicast — Multicast traffic needs to be able to get between the casting device and the Chromecast. By default a switch will flood multicast traffic to all the ports in a broadcast domain (or the VLAN equivalent). However multicast can cause unnecessary load on host devices by requiring them to process packets they have not solicited, and when purposefully exploited, this can form the basis of a denial-of-service attack. So networks include controls on where multicast traffic is sent. mDNS — The Multicast DNS (mDNS) protocol defined in RFC 6762 is a zero-configuration service that resolves hostnames to IP addresses in small networks that do not include a local name server. It is also used by Apple Bonjour, Spotify Connect, and printers. An mDNS reflector is required to make devices discoverable and usable by other devices located on different VLANs. The reflector intercepts all mDNS traffic and rewrites layers 2 and 3 of the packets to send them out across the appropriate VLANs. There are mDNS reflectors in software packages called Avahi (included in most Linux distributions) and Gandem (which has more fine-grained control). Wireless network name— Hiding your network name/SSID causes Chromecast speaker groups not to work, which is a Google thing. I didn’t have my networks hidden anyway, because hiding SSIDs makes no difference to the security of your network, and can create more problems than it solves. Wireless network band — Chromecast devices have a single radio and work on the 2.4 GHz band. So you need to make sure the SSID that the Chromecast devices is connected to is broadcast on the 11b radio. I already had my IoT network limited to the 2.4 GHz band anyway because reasons. Firewall — Chromecast discovery sends requests to the SSDP multicast address 239.255.255.250 at UDP port 1900. So you need to make sure no firewall blocks this connectivity between the Chromecast device and wireless client, and the direct response.

Things that didn’t work (for me)

Several things suggested in posts online didn’t work for me, including:

Various firewall ‘allow’ rules for 239.255.255.250 and/or UDP 1900

Adding 239.255.255.250 to the Allow list in Guest Control (and I didn’t really want to do that anyway as it would allow unauthenticated guest devices to cast)

Adding the Chromecast MAC addresses as Excepted Devices under Multicast and Broadcast Filtering: Block LAN to WLAN Multicast and Broadcast Data

Fixing the speaker group problem

The fix is not to use the mDNS reflector, but instead to enable the mDNS repeater. The Enable Multicast DNS option in the UniFi web interface enables the reflector, not the repeater. The repeater is not exposed through the UniFi Controller GUI.

One difference between these is that the reflector enables mDNS on all network interfaces including WAN, so sends mDNS advertisements to your ISP, which sounds best avoided. I am not really clear on any other differences.

The repeater is enabled by manually applying settings to the USG which specify the interfaces to accept mDNS advertisements from, as well as repeat mDNS advertisements to. That means both the source and target interfaces must be added, in my case VLANs 2 and 3 as well as the trusted LAN.

To test this I connected to the USG via SSH and used the following commands:

admin@SecurityGateway:~$ configure admin@SecurityGateway# set service mdns repeater interface eth1 admin@SecurityGateway# set service mdns repeater interface eth1.2 admin@SecurityGateway# set service mdns repeater interface eth1.3 admin@SecurityGateway# show service mdns reflector +repeater { + interface eth1 + interface eth1.2 + interface eth1.3 +} admin@SecurityGateway# commit admin@SecurityGateway# save Saving configuration to '/config/config.boot'... Done

I tested this and it finally worked ok.

In the above example you can see the reflector service was still on in the Controller GUI, and it still works if you turn it off and go back around.

So I had this working — but the configuration is lost on the next reprovision from the Controller, and needs to be made permanent by including in a config file on the Controller.

Ubiquity have a support article on UniFi — USG Advanced Configuration Using config.gateway.json which is the file that sits in the UniFi Network Controller filesystem that allows custom changes to the USG that aren’t yet available in the web GUI. This doesn’t apply to UniFi Dream Machine (UDM) models, which do not support configuration done outside of the UniFi Controller.

Connecting SSH to the Controller the location of the file is:

/srv/unifi/data/sites/<site-id>/

I didn’t have any previous configuration that couldn’t be done through the GUI, so there was no existing config.gateway.json file.

I created a file config.gateway.json with the following contents:

{

"service": {

"mdns": {

"repeater": {

"interface": [

"eth1",

"eth1.2",

"eth1.3"

]

}

}

}

}

I then did a Force Provision on the USG from the Controller GUI and confirmed it still worked.

Done!

Conclusions

Maybe I should have just moved the Chromecasts back to the trusted network. Maybe Ubiquiti don’t include this in the ‘best practices’ guide because they are trying to move people away from doing config outside the GUI. Maybe they should include the mDNS repeater in the GUI. Maybe I should look at AirPlay too, but not now.

References