Why Casting Stops Working After You Enable the Router VPN
Discovery rides link-local multicast while the TV fetches media itself. A policy default can capture the LAN request and send it into the tunnel.
Casting worked before the router VPN was enabled and fails immediately after, while ordinary browsing on the phone still works. The two facts are consistent, because casting is not one connection. The phone discovers and controls the receiver over the local network, and the receiver then fetches media over its own connection.
Two paths that fail differently
The control path is local. A phone finds a receiver by asking the local network, then opens a control connection to the address it learned. If the receiver never appears in the list, the discovery step failed before any media was requested.
The media path is not necessarily local. Many receivers fetch the stream themselves, over their own connection and with their own credentials, so the phone's route does not describe the receiver's route. A phone that appears to use one exit says nothing about where the TV's traffic goes.
That split is why the failure looks strange. The tunnel changed the phone's routing table and did not change the TV's, so a symptom that appears on one side of the pair has to be traced on that side. Tracing the wrong device is the usual reason a fix appears to do nothing.
Why discovery breaks first
Discovery usually rides link-local multicast. mDNS sends to 224.0.0.251 on UDP port 5353, and SSDP sends to 239.255.255.250 on UDP port 1900. Both are scoped to a link by design, which is why a router does not forward them between segments without help from a repeater or a proxy. A routed VPN does not extend a multicast group, and a policy route cannot make a group that never left the link appear on another one.
So the first failure has nothing to do with encryption. The phone's multicast leaves the interface it was sent on, the receiver is on a segment that never sees it, and the device list comes back empty. An empty list is not evidence that the TV lost internet access.
Isolation produces an identical symptom without any VPN involved. Guest networks and access-point client isolation deliberately stop devices from talking to each other, and enabling a router VPN on top of an isolated segment changes nothing about that. Check the isolation setting before you check the tunnel. It is the cheaper answer and the more common one.
Segment layout is the other half. A second router, a mesh node in a different mode, or a wired segment behind another NAT all put the receiver somewhere the phone's discovery traffic does not reach.
Why a policy default can swallow a local request
A router that routes all traffic into a tunnel installs a default route on the tunnel interface. If the LAN prefix is not excluded from that policy, a packet addressed to a device two metres away now matches the default, and the router sends the control request into the tunnel instead of onto the switch.
| Stage | What carries it | How a router VPN interferes |
|---|---|---|
| Discovery | Link-local multicast on a single segment | Not extended across segments, and not repaired by a route |
| Control connection | Unicast to the receiver address on the LAN | A policy default can capture the LAN destination and tunnel it |
| Media fetch | The receiver's own connection | Unaffected by the phone's route, but affected by the TV's own policy |
| Account authorization | Tokens held by the application | Can fail for reasons unrelated to any route |
Rule order decides the outcome. Policy routing evaluates rules in priority order, so an exception for the local prefix has to appear before the rule that selects the tunnel table. Adding the exception after the tunnel rule has no effect, which is why a correct-looking configuration can still send LAN traffic to a remote exit.
The repair is narrow: permit the specific local destinations the casting flow needs, and leave the rest of the isolation alone. Removing client isolation as a first step fixes the symptom while discarding a control the network was designed to have.
A quick lookup on the phone settles which of the two failures you have. If the route to the receiver points at the tunnel, the policy is the problem. If it points at the LAN and discovery still fails, multicast or isolation is the problem, and no route change will help.
ip route get 192.168.1.50
ip rule show
avahi-browse -rt _googlecast._tcpTest the stage that changed, not the country
Recorded observations beat repeated experiments. Note whether the receiver appears in the device list, whether a control request reaches it, and whether playback starts once a stream is selected. Each answer removes one stage from suspicion.
Then test each stage directly rather than switching exit locations. Changing a VPN country tests the media path and leaves the discovery and control stages untouched, so it can appear to help by accident while teaching you nothing.
On the receiver side, check its own route and its own account state. A TV that fetches media through a different exit than the phone is a normal design, and a failure there is a question about the receiver's network policy rather than about the phone's tunnel.
Write the result down as a single sentence about which stage broke and what changed it. That sentence is worth more than a week of country switching, and it survives the next firmware update.
Casting is a good test case for a general rule about tunnels. When one is added to a network, the first question is which destinations should never have entered it. The second is which of those the policy silently accepted anyway.