OpenVPN fans multicast out to every client, not subscribers

"Supports multicast" answers a protocol question and leaves the capacity question untouched. What matters operationally is how many copies the server emits for one group packet and which tunnels carry them. One subscribed application receiving the stream proves only that delivery works somewhere. It does not prove that uninterested clients were spared the bandwidth.

Three questions inside one feature claim

Group membership asks whether the receiver joined the group. Tunnel delivery asks whether the packet crossed the tunnel at all. Replication policy asks how many copies the server made and to whom. A vendor statement can be true for the first and silent on the third, which is where the cost lives.

Keep them separate when you size a link. Only the third question sets the outbound budget on the server side.

What the userspace server does with a group packet

In the OpenVPN 2.6 traditional userspace server, an arriving broadcast or multicast packet is classified in the TUN/TAP input path and handed to the broadcast fan-out routine rather than to a per-group lookup. That routine walks the client instances, skips the sender and any halted instance, applies its VLAN check where one is configured, and queues a copy for each remaining client. No step in that loop consults a membership table. That is broadcast-style replication, and it is the whole mechanism.

Treat this as a property of that code path, not a universal law. Accelerated data paths, other implementations and different versions may behave differently, and none of this makes TAP a requirement or a repair.

Budget the copies before you measure anything

Take the payload rate and multiply by the number of eligible clients. A stream sending one megabit per second to twenty clients produces twenty megabits per second of payload leaving the server, before encapsulation, retransmission and any per-client overhead. That arithmetic is a budget, not a measurement of your deployment.

ip -s link show tun0

Read the transmit byte counter before and after a fixed interval with one known sender active. Divide by the interval and compare with the payload rate multiplied by the client count. A number near the single-stream rate means replication is scoped; a number near the multiplied rate means every client is receiving a copy.

The counter also includes your own tunnel traffic, so keep the test window short and the host otherwise quiet. Precision matters less than the order of magnitude, which is all you need to tell one copy from twenty.

A two-client test that settles the scope question

Connect one client that should receive the stream and a second that should not. Start the sender, then watch the second client's tunnel counters for the same interval. Growth on the second client is direct evidence of wide replication, whatever the feature list said.

Filter the capture to the group address so you are not reading unrelated traffic, and keep it to the tunnel interface. Capturing the physical interface on a busy host produces a file nobody can interpret and may retain user data you did not intend to collect.

Then reverse the roles. If the result follows the receiver rather than the group, you are looking at something membership-aware, and the earlier assumption was wrong in your favour.

Choosing a scoped design instead of removing limits

When the fan-out is too wide, the fix is a supported scoped distribution arrangement, not deleting every control you have. Options include moving the distribution point closer to the receivers, using a source-specific subscription model that carries the source identity as well as the group, or splitting the stream so uninterested sites never sit on the same distribution boundary.

Keep the source and group identity distinct from the bare fact that a destination is multicast. A receiver that recognises the group but not the source is a different subscriber than one that asked for a specific channel. Mixing the two makes later capacity planning guesswork.

The source-specific multicast channel model is the reference for that distinction. Whichever design you pick, write down the eligible peer set, the replication owner and the counter you will read next time; that record is what turns a bandwidth surprise into a known cost.