Network requirements for cast moderator

Applies to managed ChromeOS devices or Windows and macOS users who use managed Chrome browser on M108 or later.

This page is for administrators. If you are a user and want to learn more, see Cast using cast moderator.

Cast moderator has network requirements that differ from networks that consist primarily of Chromebooks and other enterprise devices. These requirements might conflict with your existing network topology, and you might need to make changes to your routing tables, firewall or NAT port openings, packet filtering, and even Wi-Fi access points.

To use cast moderator, you’ll need:

• Cast sender—The device with content you want to share. For example, a managed ChromeOS device or managed Chrome browser on M108 or later. For more details, see About ChromeOS device management.
• Cast receiver—The device to which you are casting. For example, a Chromecast with Google TV device plugged into a TV or projector.
  • Supported cast receiver devices include:
    • Chromecast with Google TV (HD)
    • Chromecast with Google TV (4K)
  • If you need to allowlist Mac addresses to connect devices to your school network, we recommend the Chromecast with Google TV (4K) that uses a stable device Mac address. For more details on how to use device MAC, see Receiver best practices.

Cast receiver requirements

Receivers support one of the following types of network connections:

• WPA2-PSK Wi-Fi connections—Receivers are designed to work on WPA2-PSK Wi-Fi connections. Receivers do not support any WPA2-Enterprise/802.1X username or password authentication. If you are using a network with WPA2-Enterprise authentication for your organization, you might need to add a separate Wi-Fi access point for receiver devices with their own SSID. One common method is to deploy the VLAN configuration IoT VLAN.
• Wired ethernet—Receivers support wired ethernet with an appropriate adapter, such as the Ethernet Adapter for Chromecast with Google TV. The wired connection does not work with WPA2-Enterprise/802.1X authentication. This mode also does not support any sort of enterprise certificates. To connect successfully the receiver must be able to contact a DHCP server to obtain an IP address or have its IP address configured manually, and have an unfiltered routable path for traffic to the router, the internet, and any sender devices.

The receivers’ network must meet the following requirements:

• AP isolation and client isolation are turned off. Learn more about AP Isolation.
• Receivers can contact a DNS server.
• Receivers can make https connections to castedumessaging-pa.googleapis.com.
• If you need receivers to stream content from services such as YouTube, make sure the receiver can contact those services, and stream content from them. The receiver should not be required to go through a proxy in order to connect to these services.
  • This typically requires 443 and RTM 19305 (UDP and TCP) to be opened.
• Configure the receivers, and the network segment on which they live, to allow the following inbound traffic:
  • TCP connections on port 8008-8009.
  • Incoming UDP packets on ports 1 to 65535.
• Configure the receivers, and the network segments on which they live, to allow the following outbound traffic:
  • Outgoing UDP packets on ports 1 to 65535.
  • Make sure they can respond to incoming client requests on whatever port was established in the inbound connection.
• Make sure there is no packet filtering of traffic between the sender and the receiver on any of these ports; TCP 8008-8009 and UDP 1 to 65535.
• Unlike normal Chromecasts or GoogleTV with Chromecasts, receivers do not rely on mDNS. No provisions need to be made to transmit mDNS or Bonjour packets between network segments.
• We do not recommend giving cast receivers publicly routable IP addresses. To cast to receivers with publicly routable IP addresses, admins can set the MediaRouterCastAllowAllIPs policy option for senders. Casting will fail by default if this policy is not enabled and an attempt is made to cast to a publicly routable IP address.

Receiver best practices

• If you set the Remember cast devices policy, we recommend that the receiver IP addresses are kept stable so senders can reconnect to the receiver. This means that either the receiver IP addresses are hard-coded in the receiver network setup, or the DHCP server is configured to use reserved addresses for the receivers that do not change from lease-to-lease.
• If you would prefer not to open up ports on your existing network, you can put the cast receivers on their own VLAN and only open up the TCP and UDP ports between the sender network and the receiver VLAN
• If you put the receiver devices on a separate IoT network secured with WPA2-PSK but are worried about unauthorized connections to that SSID, you can use MAC address allowlists to ensure that only permitted devices connect. Make sure your Wi-Fi access point allows this.
• If you are using a MAC address allowlist and purchasing your cast receivers through an approved EDU reseller, contact them for a list of MAC addresses and serial numbers. We recommend you purchase the Chromecast with Google TV (4K), which uses a persistent device MAC address.
  If you do not receive a list of MAC addresses at purchase the best way to obtain the MAC address of Chromecast with Google TV (4K) is to set it up on a open network or use a wired Ethernet, then check for the device MAC address in the receiver’s Settings  Network & Internet, allowlist that MAC address on your network, and then move the device onto the new network.
  The Chromecast with Google TV (HD) has MAC address randomization on by default. This means it generates a new MAC address for each SSID connection. To use device MAC for Chromecast with Google TV (HD), do the following:
  1. Connect to an open network to complete setup.
  2. Navigate to SettingsNetwork.
  3. Click the MAC-allowlisted PSK network you want to connect to and enter the password. The connection will fail but you can change the setting to use Device MAC instead of randomized MAC.
  4. Re-connect to the MAC-allowlisted network to complete setup.
• Receivers support 802.11ac Wi-Fi 2.4GHz/5GHz. If your receivers connect to 5GHz, you get greater speed and less contention over radio channels.
• If a separate IoT network is not suitable for your network, or if your Wi-Fi access points do not allow for reliable streaming speeds, and you have wired ethernet ports available, you can connect your receivers via the Ethernet Adapter for Chromecast with Google TV.

Cast sender requirements

Senders are managed Chromebooks or other laptop or desktop devices running a managed version of Chrome. There are no special requirements as to how they connect to the network.

Senders must have the following requirements for content and to communicate with receivers:

• They can make https connections to castedumessaging-pa.googleapis.com.
• If you want to stream content from services like YouTube to the receiver, configure the sender's connected network to allow http and https connections to those services from the sender.
• To contact a receiver to initiate a casting session, make sure senders have a routable path to the receiver’s IP address on TCP ports 8008-8009.
• To send tab and desktop mirroring video and audio streams to the receiver, make sure the sender has a routable path to the receiver's IP address on UDP ports 1 to 65535.
• Make sure there is no packet filtering of traffic between the sender and the receiver on any of these ports; TCP 8008-8009, UDP ports 1 to 65535.
• Sender video streaming to a receiver does not use WebRTC. It is unicast stream between the sender and the receiver. Ensure the following:
  • There is a routable path between the two devices.
  • The packets, protocols, and ports listed above are not blocked.
  • Traffic to and from the receiver on those packets, protocols, and ports are not filtered.

Configuration for different networks

Single network segment

In the simplest case, the sender and the receiver are on the same network segment or VLAN. They communicate with each other directly and each communicates with the router for any external requests, such as sending https web requests to castedumessaging-pa.googleapis.com.

The following are the requirements for successful casting:

• Both devices either have an assigned IP, or can reach a DHCP server to obtain an IP address, and can contact a DNS server.
• Both devices have the same subnet mask.
• Both devices are able to reach castedumessaging-pa.googleapis.com.
• There is no packet filtering between the sender and receiver for TCP ports 8008-8009 or UDP 1 - 65535.

Multiple network segments

In this case, the sender and the receiver exist on different network segments or VLANs. This represents a, possibly simplified, model of the case where any receivers exist on an IoT network with its own WPA2-PSK Wi-Fi access point. There may or may not be a NAT or firewall at the router level.

The following are the requirements for successful casting:

• Both devices either have an assigned IP, or can reach a DHCP server to obtain an IP address, and can contact a DNS server.
• Both devices have different subnet masks, but can contact a router that knows how to route packets between the two network segments. This means that the routing table on the router must be updated to forward packets back and forth between the two segments.
• Both devices are able to reach castedumessaging-pa.googleapis.com.
• There is no packet filtering between the sender and receiver for TCP ports 8008-8009 or UDP 1 - 65535.
• If a firewall exists between the sender and the receiver, make sure it is configured so the receiver can accept connections from the sender on ports 8008-8009, established connections can send TCP traffic on those ports, and both ways can send UDP packets on ports 1 - 65535.
• If more than one receiver exists on the same segment, it is not recommended to have a NAT between the two network segments. This is because it will be difficult to configure it to forward traffic on ports 8008-8009+8443 to different internal addresses.

Troubleshooting

You might see the following issues:

• The receiver reports limited connectivity
• The receiver does not display an access code
• When you enter the access code on the sender, a casting session is not initiated and the error message Something went wrong or You’ve entered an incorrect access code is displayed.

If you encounter any of these issues, try the following:

• Make sure that the account that was used to set up the receiver, and the account attempting to cast belong to the same domain. Or, that the account being used to attempt to cast belongs to a domain trusted by the account used to set up the receiver.
• Make sure that the sender can ping the IP address of the receiver.
• Make sure that there is no packet filtering between the sender and the receiver.
• If possible, put the receiver on a network segment or VLAN that has all filtering, proxying, and so on turned off, and see if that corrects the issues. If so, add back the necessary security measures one-by-one until you find the one that needs adjusting.
• To validate whether the issue is with your network or the hardware, consider setting up a Wi-Fi hotspot and connecting a receiver and a sender to that Wi-Fi. If you are able to cast in that scenario, but not on your full network, then there is almost certainly some form of filtering, proxying, NAT, or incorrect routing tables that are preventing communication.
  • Note: Using a Wi-Fi hotspot sometimes results in publicly routable IP addresses being assigned to receivers and causing casting to fail by default. For more details, see here.

Google and related marks and logos are trademarks of Google LLC. All other company and product names are trademarks of the companies with which they are associated.