Why Multicast Does Not Cross a VPN Without a Plan

Two sites can reach each other perfectly by unicast and still behave as if one of them cannot see the printer's discovery announcement, the IPTV stream or the cluster's heartbeat. That is not a broken tunnel; it is the difference between a destination and a group. Multicast delivery needs a membership model, forwarding state along the path, and an interface willing to carry the traffic, and none of those come from a unicast route. Walking from the application's group to one working receiver is the shortest route to an answer.

Start With the Group and the Application

Ask which group address the application uses and what the traffic is for. A discovery protocol that announces services, a streaming feed, and a routing protocol's hello packets are three different problems with three different acceptable answers. The group address itself tells you the scope: addresses in the local network control block are not meant to be forwarded off-link by ordinary routing, and applications that use them usually assume a single broadcast domain. A streaming feed on a globally scoped group is a different design from a discovery protocol that expects every device to hear every query, and only the second one cares about the size of the broadcast domain.

Decide whether the requirement is the service or the discovery mechanism, because those answers differ in cost by an order of magnitude. One asks for an address that does not change; the other asks for a broadcast domain extended across a wide-area link, with everything that follows from it.

Link-Local Discovery Is Supposed to Stop

Multicast DNS as described in RFC 6762 is designed around a single link: queries go to a fixed group, responses are sent to the same group, and the protocol relies on every participant hearing everyone. Routers do not forward that traffic by default, and that is a design decision rather than an oversight. The boundary exists so that a device in one building cannot casually announce itself into another. A tunnel that appears to fix discovery by carrying the group everywhere has removed that boundary for every application, not just the one that needed help.

Repeaters and reflectors exist, and they are real services with real consequences: every name announced at one site becomes visible at the other, including device names that identify people or equipment. If the actual requirement is that a specific service be findable, a service record published in DNS is usually the smaller change, and it discloses one name instead of a stream of them.

Three Things Routed Multicast Needs

Routed multicast needs three things working together: receivers that join the group, routers that maintain forwarding state for it, and a tunnel that treats the group addresses as traffic to carry. A tunnel with a policy that only lists unicast subnets will drop the group traffic at the encryption boundary, which is why the first symptom is often silence rather than an error. A route-based interface such as a GRE or VTI tunnel carries whatever the routing table sends into it, which makes the group reachable once the multicast state exists.

Source reachability is the second half. Multicast routing protocols such as PIM build distribution trees by checking that the path back to the source is the expected one, so a unicast route that points somewhere else breaks the tree even when the group membership is correct. Installing a route for the receiver does nothing for that check, and this is the mistake that produces a working ping and a failing stream. Verify the source's return path first, then add membership, and only then look at the application.

ip maddr show dev tun0
ip mroute show
ss -gnu | grep 239.255.0.10
ip route get 10.20.5.20

The first two lines show what the host joined and what the kernel forwards, the third shows the application's own membership, and the last shows the unicast path the reverse-path check will use. Reading them together distinguishes an application that never joined from a network that never forwarded.

Prove It With One Source and One Receiver

Before touching a configuration, confirm the application works on a single segment. If it fails locally, multicast routing is not the problem and no tunnel change will help. Then repeat with one receiver across the tunnel and watch the packets on both sides of the encryption boundary.

tcpdump -ni tun0 -c 10 'ip multicast'
tcpdump -ni eth0 -c 10 'ip multicast and host 239.255.0.10'

Packets visible inside the tunnel but absent outside it point at encapsulation or policy; packets visible on both sides with no application progress point at the receiver's membership or the application's binding. Keep captures short and filtered, since a broad multicast capture on a busy segment is mostly noise.

Prefer a Service Address When You Only Need the Service

Discovery exists to find something that moves. A server with a stable name does not need discovery, and a documented address in private DNS answers the user's real question without extending a broadcast domain across a wide-area link. The same reasoning applies to printers, appliances and internal web services. A name in DNS can be reached from every site that needs it while announcing nothing to the sites that do not, and it keeps working when the device is replaced by one with a different address.

When a protocol genuinely requires multicast, scope it to the group and the sites that need it, document why, and revisit the decision when the application changes. Extending discovery everywhere is easy to do once, and hard to unwind after a year of devices that quietly depend on it.