Use this checklist to investigate casting on a managed school or business network. Sender means the laptop, phone or
tablet; receiver means the Chromecast or Cast-enabled display. Check the receiver model and software: built-in display
implementations may have additional requirements.
Visible does not mean connected. Discovery, local control and media use different traffic. A receiver can appear in the Cast menu while the actual connection is blocked.
1. Required network checks
Addressing & isolation. Verify both devices have a valid IP address, subnet mask, gateway and DNS configuration (DHCP or supported static settings). AP/client isolation and guest policies must allow communication between the intended sender and receiver. [1]
mDNS / Bonjour discovery. Allow queries and responses for _googlecast._tcp.local. Across VLANs, configure a supported mDNS gateway, repeater or reflector for the relevant networks and service. Opening UDP 5353 alone does not carry link-local discovery across subnets. [2, 3]
Routing & return traffic. Across VLANs, verify routes in both directions. Permit local control and media through network and endpoint firewalls, including stateful return traffic. Prefer a routed path without NAT between the casting networks. [4]
Sender permissions - required where prompted. On iOS/iPadOS 14+ and macOS 15+, enable Privacy & Security > Local Network for the casting app or Chrome, then reopen it. [5]
2. Traffic to verify
Required = needed for the stated function. Diagnostic = a temporary test, scoped to the test devices. Local rules apply inside the network; outbound rules apply to Internet or infrastructure services.
| Traffic / ports | Path | Requirement / purpose |
|---|---|---|
| mDNS UDP 5353 | Local discovery | Required for standard discovery. IPv4 multicast 224.0.0.251; IPv6 ff02::fb where used. Check wireless and wired forwarding. [2, 3] |
| Local control TCP 8008-8009 | Sender to receiver | Required for standard Cast control. Allow replies on established connections. Confirm model-specific ports. [4] |
| Media / mirroring UDP, dynamic ports | Sender and receiver, both directions | Required: media traffic must pass. Diagnostic: temporarily allow UDP 1-65535 between test devices; see scope below. [4] |
| HTTP / HTTPS TCP 80 / 443 | Sender / receiver to required services | Required as used for setup, updates and online content. Check service domains and any additional application ports. |
| DNS UDP and TCP 53 | Devices to working DNS resolvers | Required: successful name resolution. Inspect blocked queries; verify any device-specific use of external resolvers. |
| NTP UDP 123 | Receiver to its time service | Required when using NTP. Correct time is needed for certificate validation; check time and synchronisation. |
Port scope: Google explicitly specifies UDP 1-65535 for Cast Moderator. For other receivers, confirm the permanent media rules with the
manufacturer. Do not assume TCP/UDP 32768-61000 is universal. Cast Moderator also uses a different discovery method from standard
mDNS-based Cast. [4]
Find the failing step
Symptoms and practical checks
| Symptom | Checks to perform |
|---|---|
| Receiver is not visible | Confirm the receiver is online and Cast is enabled. Check AP/client isolation, mDNS service advertisements, VLAN gateway policies and sender Local Network permission. Try another sender or Cast-enabled app. [1-3, 5] |
| Visible, but cannot connect | Check the route to the advertised receiver IP, TCP 8008-8009, firewall/ACL logs and return traffic. Review NAT and sender VPN or endpoint firewall rules. Discovery alone does not verify these paths. [4] |
| Connects, but mirroring fails | Check UDP media filtering in both directions. Apply the scoped UDP diagnostic test on page 1. On the sender, check screen-recording permission where required. Compare another sender/app. |
| Online content fails | Check Internet access from the receiver itself, DNS responses, TCP 80/443 and correct time/NTP. Review domain filtering, proxy authentication and SSL/TLS inspection; test a targeted bypass. |
| Disappears or drops out | Check Wi-Fi signal, congestion, roaming, address changes and firewall session timeouts. If discovery expires, inspect multicast handling and IGMP snooping as described below |
| Cannot join the network | Check DHCP and supported Wi-Fi security. Google streaming devices do not support captive-portal login; enterprise/802.1X support depends on the receiver. Use a supported network or Ethernet option. [6] |
3. Recommended settings & diagnostic checks
IGMP snooping - recommended where supported by the network design. It can reduce unnecessary multicast
flooding. Follow the switch/AP vendor guidance and check querier operation where required. If discovery disappears, briefly disable snooping on the affected test VLAN, retest, then restore it and correct the multicast configuration. [7]
Proxy / SSL inspection - diagnostic. Avoid requiring an unsupported authenticated proxy. If HTTPS fails, test a
receiver-specific bypass of proxying and SSL/TLS inspection; use the result to define a suitable exception. [4]
UPnP - not a blanket enterprise requirement. Do not enable automatic router port mapping as a general fix. Configure the required discovery and traffic paths explicitly.
4. Isolate the network in a simple test
1. Put both devices on the same test VLAN/subnet or a simple unrestricted test network, with Internet access and client isolation off.
2. Remove inter-VLAN filtering, proxy/inspection and VPN effects from the test path. Retry discovery, connection and mirroring with the same devices and app.
3. If it works, compare the managed network's discovery, routing and filtering policies. If it still fails, check
device/app setup and try another sender. Restore test changes. [4]
Still unresolved? Share with support: receiver model/software, sender OS/app, both IPs/VLANs, exact symptom and time, relevant firewall logs, and the isolation-test result.
Technical references (click to open) | Reviewed 15 September 2026
[1] Google: AP/client isolation [2] Google: discovery troubleshooting [3] Cisco: mDNS gateway [4] Google: Cast Moderator network requirements [5] Google: Local Network permission [6] Google: Wi-Fi connection troubleshooting [7] Cisco: mDNS design and troubleshooting