Smart TV on the VPN: why casting and DNS break separately
Route the TV's traffic at the router, then treat the selector, the resolver, IPv6 and the casting path as four separate checks.
Your television shows the foreign catalogue, and the phone's cast button no longer lists it. Both complaints start with one phrase that names four settings on four router pages. Fix the exit and discovery breaks; fix discovery and the next lease hands the exit to a different device. The order below runs from the selector out to the casting path.
Where each of the four decisions lives
Write the four down before opening a menu, because each one lives on a different page and fails in a different place. The selector picks which client the tunnel applies to, the resolver decides where names get answered, the address family decides whether IPv6 is covered at all, and the local path decides whether the phone and the television can still see each other. A change to one looks complete from the page you are standing on. The damage from the other three turns up later, in a different menu, as a different complaint.
Firmware menus differ, but the four locations rarely do. The selector is a static mapping on the DHCP server plus a firewall rule that matches it. The resolver sits with the DNS service, where a forwarder entry or an upstream server list decides which names the router answers and where the queries leave from. The family setting belongs to the interface itself, where IPv4 and IPv6 are configured separately and a policy can cover only the first. The local path is an access-point switch, either client isolation or a guest network with its own firewall.
Make the selector outlive the lease
Both a per-device policy and a dedicated segment work, and the better choice is whichever the firmware can maintain without a second person remembering it. The trap is a rule pinned to an address the DHCP server handed out on its own schedule: it keeps working until the lease moves, then routes a laptop through another country for reasons its owner cannot see. Persistence, not tidiness, is the property worth optimising.
| Rule names the TV by | After the next lease | What it costs |
|---|---|---|
| whatever address it has now | may point at another client | silent misrouting weeks later |
| a reserved address | holds, if the reservation ships with it | one more entry to keep in step |
| a hardware address | holds, unless the device rotates it | privacy features can break it |
| a whole segment | holds for every device on it | neighbours inherit the exit |
Send the reservation and the rule out as one change, because a rule that outlives its reservation is a rule aimed at somebody else's hardware. A whole-segment rule is the most durable selector and the bluntest, since every device behind that interface inherits the exit whether or not it needed one. Whichever selector you pick, the coverage question comes next: an IPv4-only policy is half a decision, and the uncovered family is the one that leaves without being noticed.
Find out which resolver the television really uses
Open the television's own network settings before touching the router, because the device settles this argument. A DNS field set to manual keeps using that server whatever DHCP offers, and a set-top box configured once for another region can still be pointed at an address that no longer answers. If the field is automatic, the router's DHCP option decides, and the router's own resolver becomes the next question. Either way the answer is on the device's screen, not in the firmware manual.
On the router side the distinction that matters is between names the router answers itself and names it forwards, because those two paths can leave through different interfaces. A lookup that resolves correctly therefore says nothing about where a media request goes, and on a Linux gateway the policy table plus a single route lookup answer both questions without capturing anything on the television:
ip rule show
ip route get 203.0.113.10Read the first command for the rule that marks the television's traffic and the second for the interface a packet to the example address would actually use. When the two disagree, the resolver is not the fault; the policy is. Change one thing, then run the pair again, because a rule list is order-sensitive and a new entry can shadow the rule that was carrying the traffic. The destination is reserved for documentation, so a pasted output reads as a sample.
Casting breaks at discovery, not at the stream
Casting is at least three conversations and only one of them carries video. The phone discovers the television by multicast or broadcast on the local segment, opens a control channel to say what to play, and then the television either fetches the stream itself or receives it relayed from the phone. Discovery never crosses a router that is not forwarding that traffic, which is how a television can be routed exactly as intended and still never appear in the cast list.
Guest networks and client isolation are the usual cause, and both are doing exactly what they were configured to do. Switching isolation off across the whole wireless network so that one device reappears is the usual over-correction, and it reopens every phone-to-phone path the setting existed to close. Narrower answers exist: a pass rule for discovery and control traffic between two addresses, a separate SSID for the televisions, or one documented exception on the guest network.
Test the cast with the isolation rule still in place, then add only the discovery exception and test again. If the second attempt finds the television, the exception is the fix and the rest of the segment can stay as it was.
Stop the tunnel and watch which way it fails
The last check is the one most setups skip: take the tunnel down and watch whether the television stops or quietly leaves by the local connection. A policy that expresses a preference fails open, and the failure is easy to miss because playback continues while the exit moves back to the ISP. A kill-switch rule fails closed instead, and the television reports nothing until the tunnel returns. Neither behaviour is wrong; not knowing which one you configured is.
Re-check four things after any change, in this order. The selector still matches the device after the next lease or reboot. The resolver answers on the path the policy intends rather than from a server the device remembered. The address family in the policy covers every family the television and the access network actually use. Casting still finds the television from the phone that will really be used, not from a test phone sitting on the same SSID.
Keep those four lines beside the router configuration rather than in a chat thread: what the rule matches, which resolver the television asks, which family is covered, and which local path casting needs. The next person to open the firewall will read the config long before they read a ticket. By then, that person may be you.