Chromecast and DLNA discovery never crosses a routed VPN

The cast button lists nothing, VLC DLNA stays empty, and the machine at the other end answers ping without complaint. That combination is not a bandwidth problem or a firewall mystery. Discovery in these protocols is a group exchange on the local segment, and a routed tunnel does not carry group-addressed traffic. The session you are trying to start never gets offered.

Reachability is fine. Discovery is missing.

The myth: the tunnel needs a setting or more capacity

The usual suggestions are to enable peer-to-peer traffic, raise the MTU, or change the tunnel device type. None of them adds a broadcast domain. Multicast is delivered by switches and by the local network stack, and a point-to-point TUN interface has no group address to flood.

Changing settings can make the failure louder. It cannot make an announcement appear where the protocol never sent one.

What the discovery exchange actually is

Three patterns cover almost everything you will meet. mDNS sends to 224.0.0.251 on UDP 5353, SSDP sends to 239.255.255.250 on UDP 1900, and older SMB browse lists went to the subnet broadcast address. Each is addressed to a group rather than to a host, and each expects a listener on the same segment. A receiver across a routed tunnel is not on that segment, so nothing arrives.

Even a relayed announcement carries a payload: usually the sender LAN address and port, which the remote viewer must then be able to reach.

Read a capture before changing the tunnel

Capture on the tunnel interface while the app scans. An empty capture means the announcement never crossed the boundary, and no amount of tunnel tuning changes that. Packets that do appear while the app still shows nothing usually mean the advertised address is unreachable from the viewer, which is a routing problem wearing a discovery costume.

Two minutes of capture replaces an hour of guessing about ports: tcpdump -ni tun0 udp port 5353 or udp port 1900.

Three fixes, cheapest first

Point the client at the service address directly. For DLNA, SMB and plain media servers this skips discovery entirely and proves the payload path works, which makes it the best first test as well as a usable workaround. Chromecast is the exception, because the receiver expects to be found rather than addressed.

Relay the protocol at the gateway. An mDNS reflector repeats announcements between the tunnel and the LAN, and Avahi ships a reflector section that takes an explicit interface list. Keep the relay narrow, and confirm the advertised address is reachable from both sides, or the reply still points at a subnet the viewer cannot route to.

Bridge instead of routing. A TAP segment with the server bridging the tap device onto the LAN puts both ends in one broadcast domain, so announcements cross unchanged. It is also the most expensive option, because one subnet means one failure domain and every multicast service on the LAN now reaches every peer.

What does not help, however often it is suggested

Switching dev tun to dev tap without a bridge leaves a TAP device that is still routed, so behaviour does not change. client-to-client permits peer-to-peer unicast and does not flood broadcasts. Forwarding a discovery port to one host does not deliver group-addressed traffic. A media server bound to one address keeps answering on that address until its own configuration lists the VPN interface.

Test one direct unicast request, then one announced request. If the first works and the second does not, the tunnel is healthy and discovery is the whole problem.