Casting Stops on a VPN: Discovery, Control or Stream?
A missing receiver, a refused session and a stalling stream fail in different places. Name the stage before changing the phone's VPN policy or the network.
Casting breaks in three places that look identical from the couch. The phone may never see the receiver, the receiver may appear and then refuse the session, or the session may start and stall a minute later. A tunnel on the phone changes each of those paths differently, and for one of them it changes nothing at all. Name the failing stage first, then decide whether a policy change is even the right lever to pull.
Name the failing stage before you change policy
Watch what the phone does immediately after you tap the cast icon. An empty list is a discovery result, a tap that reports failure is a control result, and a session that starts before stalling is a playback result. Those three have different owners, and only the first two normally involve the phone's tunnel settings.
| Stage | What the phone shows | Evidence that separates it |
|---|---|---|
| Discovery | No receiver in the list | Another device on the same segment sees the receiver |
| Control | Receiver listed, session refused | Port answer versus permission prompt |
| Playback | Session starts, then stalls | The receiver's own link, not the phone's |
Write the stage down before changing anything. A fix applied to the wrong stage makes the next test unreadable, and most casting folklore comes from exactly that confusion.
Discovery is local traffic, and a tunnel hides it
Receivers advertise themselves through local announcements and the phone finds them with queries on the same link, so anything that removes the phone from that link removes the receiver from the list. A tunnel that routes all traffic away from the LAN can hide those exchanges, and an app-level local-network permission can block them even when the route exists. Guest Wi-Fi with client isolation produces the same empty list with no VPN involved at all. Prove the two devices share a segment before blaming the tunnel.
avahi-browse -at | grep -i -E 'chromecast|googlecast'
dig +short @224.0.0.251 -p 5353 _googlecast._tcp.local PTRThe first command lists what is announcing itself on the helper machine's segment, and the second asks the multicast DNS group directly. A receiver absent from both will not appear in a phone app either, whatever the phone's tunnel state. If the receiver is visible from a device whose tunnel is off and invisible from one whose tunnel is on, you have found the stage and the cause together.
A LAN exception keeps the tunnel up
Many clients offer a local-network exception that leaves the tunnel active while permitting local addresses. Use that documented setting rather than disabling the kill switch or the whole firewall, because those change far more than casting needs. If the network separates smart devices on purpose, ask the owner for the specific discovery, control and return traffic instead of asking for flat access.
nc -vz 192.168.1.50 8009A control test against the receiver separates permission from reachability: a port that answers means the path exists, while a refusal means the phone was allowed to discover the device and still cannot talk to it. Ports 8008 and 8009 are the usual cast ports, and an app may use others, so treat a single refused port as a hint rather than a verdict. The exception and the app permission stay independent, since granting local access does not create a route and adding a route does not grant permission. A kill switch can also drop local traffic after a reconnect, which is why discovery has to be retested once the tunnel is back.
Playback may not use the phone's connection
In an app-directed session the phone hands the receiver a media address and the receiver fetches it over its own connection, so changing the phone's public address does nothing for the stream. An account-gated title can still fail for its own reasons, and Google's casting requirements cover app and device compatibility rather than the network path. Routing the television itself through a tunnel is a separate configuration with its own policy questions.
Two clues tell the modes apart. A cast that survives locking the phone's screen is app-directed, because the receiver is fetching on its own; a mirror that stops when the sender's screen locks is a continuous stream from the phone. When discovery and control succeed but playback stalls, look at the receiver's Wi-Fi link and its internet path instead, since a speed test on the phone describes the phone and not the television.
Undo the exception and retest
Every temporary change needs a way back, and the order matters. Remove the LAN exception, reconnect the tunnel so the client reapplies its policy, then repeat the discovery step and note whether the receiver disappears again. That sequence tells you whether the exception was doing the work or whether something else changed in between.
# after removing the LAN exception, reconnect and confirm the tunnel is up
resolvectl status | grep -E 'DNS Servers|Default Route|Protocols'
avahi-browse -at | grep -i -E 'chromecast|googlecast'Verify the three stages separately afterwards, because a pass on one says nothing about the others. Then check that unrelated phone applications still follow the intended route, since a local exception that quietly became a full bypass is a worse outcome than a cast that needs one extra tap.