Sven and the Art of Computer Maintenance

Sven and the Art of Computer Maintenance

27 Feb 2023

Chromecast casting support across IP networks

There can be situations in which you want to support ‘casting’ across different network segments (VLANs) to a Google Chromecast, an Android TV television or media player, or any other device with Chromecast built-in. One example is guests in a guest wireless network, who want to cast something to media devices in a separate media network.

Documentation about this is available here and there, but rarely is everything needed available in a single location. In this short reference, I note it all. Of course, protocols can be updated and Google can change how casting works since they indirectly control all endpoints. Please notify me if something is inaccurate or missing.

To cast from one network to another, the following is necessary:

  • A multicast DNS forwarder. Device discovery uses the multicast DNS protocol (mDNS). This protocol is broadcast-based, and is therefore limited to a single network segment. A multicast DNS forwarder listens on two or more network segments for mDNS broadcasts, and is typically installed on a router between both networks. These broadcasts are destined for (IPv4) 224.0.0.251 or (IPv6) ff02::fb, UDP port 5353. Once a broadcast is received by the mDNS forwarder on one network interfaces, it is rebroadcasted on the other configured network interfaces.
  • Allowed network connections between both networks. Once the media offering device chooses a media receiving device, it must be able to open a direct connection. If a firewall exists between both networks, its rules must explicitly allow this.

Installing and configuring an mDNS forwarder

This step depends on the type of router you use. OpenWRT uses umdns, OPNsense uses its own mdns-repeater plugin, and pfSense uses Avahi. DD-WRT might include Avahi in recent builds. Other routers might use something else. It might be named differently (‘mDNS proxy’, ‘Bonjour’, ‘Zeroconf’, …), so look around. At least, an mDNS forwarder should allow you to enable it, and to select the interfaces it should forward mDNS broadcasts between (at least two). I tested OPNsense. To have OPNsense receive mDNS broadcasts, it is not necessary to create firewall rules to allow incoming traffic.

Configuring a firewall

From the network containing the media offering devices (e.g. smartphones on a guest network), allow the following traffic to the media receiving devices (e.g. one or more Chromecasts on a media network):

  • TCP 8008-8009, used to let devices offer media sources for the receiving device to play, and to remotely control the receiving device (playback features only). Unauthenticated.

  • UDP 32768-61000, used to stream media directly from the offering device to the receiving device (as opposed to playing a stream from a streaming service on the internet) using the Real-time Transport Protocol and the RTP Control Protocol. Unauthenticated.

In addition, the following traffic in the same direction can be allowed for optional services:

  • TCP 8443, required for Google Home (an Android/iOS smartphone application) support. Google Home allows remote media control and screen mirroring. I haven’t found any other use for this port. Without access to this port, Google Home won’t list discovered devices. All other casting sources I have tested seem to work fine without it (including other screen mirroring applications, such as Google Chrome). Unauthenticated.

  • TCP 6466-6467, Android TV Remote support, used by Google TV (an Android/iOS smartphone application) to fully control Android TV devices, not just for casting. Only used by Android TV (‘Google TV’) devices, and is not required for casting. Requires pairing for authentication as a security feature (show number on display, enter number on smartphone).

In addition, the following traffic in the reverse direction (from the media playing network to the media offering network) can be allowed for additional services:

  • TCP 8010, required by VLC for streaming local videos to a Chromecast-compatible device. VLC’s approach to offering media without an online source is different compared to screen mirroring. Instead of pushing data, it points the Chromecast-compatible device to its own host to retrieve media from.

Unauthenticated services solely rely on network security to offer any form of protection against abuse.

Play some media

From the network configured for media offering, cast using a well-known streaming service (Disney+, Netflix, YouTube, …). Alternatively, cast something from one of your own devices. On Android, Google Home can be used to mirror the display and to control media playback. On desktop, Google Chrome can be used for screen mirroring, casting media sites that support it and media playback control. Avoiding Google, it is possible to use VLC to stream your own media files.

Removing Android TV Remote pairings

While testing, I did not find a way to manage paired smartphones on my Android TV media player (a Shield TV with the latest firmware). A rather obscure option I found allows for removal of all pairings.

In Android TV, go to Settings -> General Settings -> Apps -> Recently opened apps -> See all apps -> Show system apps -> Android TV Remote Service. There, choose ‘Clear data’. The service can also be disabled here using Disable and Force stop, which stops the Android TV device from listening on TCP ports 6466 and 6467.

One final note

If you offer a VPN-based internet connection on your guest network using a commercial VPN provider, chances are that online streaming services will refuse casting due to applied IP restrictions. This can be true even if the Chromecast-compatible device is not using a VPN when the external IP addresses of both devices are taken into consideration. Ensure both devices use one or more external IP addresses that are not blocked.