Multicast over “stupid” networks

IP multicast is an interesting technology. It’s main purpose is to
save network bandwidth as much as possible – traffic is sent to hosts
which asked for it only (as opposed to broadcast). On the other
side, you need smarter (manageable) switches and separate and
non-trivial configuration on both routers and switches. Even more
complicated it is when you try to make it work over VPN.

I have a server, which can join multicasts using IGMP on one
interface and has a public IP on another interface. I wanted it to make
those multicasts available via VPN.

It has a static route for multicast to know where to join them:

route add -net dev eth1

So my first try was to use OpenVPN with tun device (routed IP packets). I set it up to push route to clients:

push "route"

And to to preserve TOS value for QoS:


Next, I needed to make my server join on eth1 and route multicasts to
tun0 interface. Linux has a native support for multicast routing but it
needs to be managed by an userspace application which statically or
dynamically manages routes. For this I used igmpproxy. It listens for IGMP packets on tun0, joins/unjoins multicasts on eth1 and install multicast routes accordingly.

# ip mroute show
(,   Iif: eth1       Oifs: tun0

This was working ok, but it has one huge disadvantage: OpenVPN treats
multicasts as broadcast and sends them to all clients. If you have VPN
clients with poor network or CPU performance, you can effectively make
the VPN unusable for them.

igmpproxy can listen on multiple interfaces (even dynamically created)
so if each client had it’s own tun interface the above problem would
disappear, but unfortunately OVPN can’t do this. There are VPNs which do
this by default e.g. pptpd (I tested it and it works) but I wanted to
stay with OpenVPN.


So I came to an idea to use tap device. Even though OVPN does the
same as in TUN mode and brodacasts packets to all clients (there are
some efforts to change it), I got a new opportunity: to direct the packets using Ethernet header.

The idea is following: I’ll write a daemon, which will listen and
process IGMP joins on VPN tap interface. When it gets one, it will
record senders MAC address, join requested group on upstream interface a
listen for incoming multicast packets. It will then take the whole IP
packet, prepends recorded destination MAC, some source MAC and send it
to the tap interface. This should cause the packet to be sent only to
one client but keep the IP payload unchanged.

So I wrote a prototype and for my surprise it also WORKS! At least on Linux. You can find it here.
Feel free to test it. Now to explain the title, this daemon can be also
used for network with stupid switches to avoid network flooding. The
traffic effectively changes to unicast on link layer and is delivered
directly to subscribers.

I hope this helps someone with similar problem.
Looking forward for your comments and suggestions.


11 thoughts on “Multicast over “stupid” networks”

  1. Hi Danman

    Im struckling with openvpn and multicast my self, but and fairly new to linux and openvpn.

    I have my openvpn running on an virtual server, and devices can see each other by ping, but i need to allow multicast.

    The devices are on mobile 3g/4g networks with the vpn to the openvpn server and of what i can understand the android devices does not allow TAPs which in my case then leave me for routing vpn.

    Not sure if i understand your topology correct. but if you any hint/ guides everything would be grateful accepted

    best regards

      1. Hi again.

        I want the multicast send from the tunnel returned to other devices in the tunnel if this makes sense

        Best regards

  2. Awesome, thank you.

    On my router i have following interfaces :
    vlan1 : Ethernet LAN
    ath1 : Wifi LAN
    vlan2 : WAN
    tap0 : TAP for openvpn

    br0 : bridge vlan1 / ath1 (whole LAN) and tap0

    In vpnmcast.conf:
    sourceif = “tap0”
    destifs = [“br0”]

    From a remote OpenVPN client, i’m able to see DLNA server using :
    $ gssdp-discover -i tap0 –timeout=3

    But from VLC > UPnP Discover, the server is not listen… any idea why ?
    What UPNP client do you use ?

    Thanks !

  3. hmmmm……
    gssdp-discover show DLNA server even if vpnmcast is not running.
    There is something i clearly don’t understand :s

  4. thanks, you are right, adding this route client-side make the server appear in VLC :
    # route add -net netmask tap0

    I cannot browse files from VLC, i don’t understand because vpnmcast show:
    22: 2 -> XXX.XXX.168.192 -> INVERTED DLNA SERVER IP
    adding sender
    adding forward 5404a6cd2934

  5. Answering myself : it’s seems that VLC indexes all medias on the server (instead of indexing only opened folder), so it can be very, very long…

  6. Hi there,

    We’re running a similar setup using OPNsense.
    We have “bridge0” with two client interfaces:
    ovpns1 – the tap interface used by the OpenVPN server
    vtnet1 – the interface that plugs into the IPTV router

    Since both interfaces are in the same bridge, all VPN clients will be connected to the IPTV router transparently when they bridge their tap interfaces with their IPTV stb network-interfaces.

    However we have the same problem, when a single VPN client does a multicast join, all other VPN clients will receive the traffic as well.

    Will your python script also work in this scenario? e.g. when both interfaces are part of a network bridge?

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.