SSM Over OpenVPN: Following One Source and Group End to End

Pick one stream and one receiver, then follow that pair through every hop instead of testing multicast as a category. A source-specific design fails at exactly one of four places: the receiver never joined, the router rejected the packet on its reverse path, the kernel has no state, or the tunnel never delivered a copy. Working in that order costs minutes per hop and tells you which of the four you actually have.

Pin the source, group and receiver first

Write down three values before touching any device: the source address that will send, the group address the receiver will join, and the subnet the receiver lives on. For an illustrative IPv4 stream, a source of 10.50.0.10 and a group of 232.20.30.40 is the kind of pair that fits a source-specific design. Anything vaguer than those three values cannot be tested.

The 232/8 range is reserved for source-specific multicast, and the model is described in RFC 4607. If your group sits outside that range while you believe you are running SSM, stop and confirm what the deployment actually intends, because the receiver's join and the router's forwarding decision both depend on the model being consistent.

Check that the receiver joined the source

A membership report for the group alone is not a source-specific join. Ask the receiver which source it requested, and on the first-hop router look at the group state to see whether a source list appears. If the report carries no source, the router will treat it as an any-source join and the whole design silently degrades into something you did not plan.

On a Linux receiver, check what the socket actually subscribed to and what the kernel recorded. The application's configuration file is not evidence; the membership table is. Read it while the receiver is actually running, because an entry can linger briefly after the process that created it exits. A stale entry from an earlier test is a reliable source of false confidence.

ip maddr show dev eth0
cat /proc/net/igmp | sed -n '1,40p'

If the join is present with the expected source, move to the routers. If it is missing, no amount of tunnel configuration will help, because there is nothing to forward.

Verify the reverse path before you look at the tunnel

Multicast routing performs a reverse path check, and a packet that arrives on an interface other than the one the unicast route points to is dropped. This is the most common reason a stream that is clearly being sent never reaches the next hop, and it produces no useful application-level error at all.

On the router facing the source, compare the route toward the source with the interface the packets actually arrive on. On the router facing the receiver, do the same for the receiver's own subnet and confirm the outgoing interface list includes the link toward it. A mismatch in either direction is an RPF failure, not a membership failure.

Then confirm the source's TTL is large enough to survive the routed hops you designed. A stream that works on the first router and dies at the second is often a TTL question rather than a policy one.

Read kernel multicast state rather than configuration

Configuration tells you what you asked for; the kernel tells you what is happening. On each Linux hop, read the multicast routing entries and confirm an incoming and outgoing interface list exists for the exact source and group pair. An entry for the group with a wildcard source is a different object, and it will not explain a source-specific flow.

ip mroute show from 10.50.0.10 iif eth1
ip route get 10.50.0.10

Routing daemons keep their own view on top of that state, and the command that prints it depends on which implementation is installed. The principle is constant: ask the daemon for its upstream entry for the pair, then ask the kernel whether a forwarding entry exists. A daemon that thinks it is forwarding while the kernel has no entry is a configuration-scope problem on that host.

When the two disagree, fix the host rather than the VPN. Nothing downstream can compensate for a hop that is not forwarding the flow you asked about. Record the pair, the incoming interface and the outgoing list for every hop while the stream works. That record turns the next failure into a comparison instead of a fresh investigation.

Decide how the tunnel actually replicates

This is where multicast over a VPN stops being routine. A point-to-point tunnel delivers a packet to the single peer at the other end, so a copy reaches exactly one client. A bridged segment behaves more like a shared link, because the tunnel carries the frame and the bridge decides what to flood. Those are different delivery models, and a design that assumes the second while running the first will appear to work for one receiver and fail for the next.

For more than one receiver over a multipoint server, replication has to be designed explicitly. Installing a multicast route on the gateway does not teach the VPN server which peers should receive a copy, and no client-side route makes that decision for it. Where the requirement is many receivers, use supported replication or a deliberately chosen alternative, and write down which one you picked.

Finally, verify at the receiver under a narrow observation: the exact source, group and port, on the interface you expect, while one authorized receiver is joined. SSM selects a sender, and selection is not authentication of that sender, nor permission for other multicast traffic to cross the same policy.