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 184.108.40.206/4 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 220.127.116.11 240.0.0.0"
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 (10.2.3.1, 18.104.22.168) 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”
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
Ok and what do you want to achieve?
I want the multicast send from the tunnel returned to other devices in the tunnel if this makes sense
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
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 ?
Did you try to add route for multicast over tap0 ?
gssdp-discover show DLNA server even if vpnmcast is not running.
There is something i clearly don’t understand :s
thanks, you are right, adding this route client-side make the server appear in VLC :
# route add -net 22.214.171.124 netmask 240.0.0.0 tap0
I cannot browse files from VLC, i don’t understand because vpnmcast show:
22: 2 -> XXX.XXX.168.192 250.255.255.239 -> INVERTED DLNA SERVER IP
adding sender 126.96.36.199
adding forward 188.8.131.52 5404a6cd2934
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…
so does it work?
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?
Hi, no, it won’t work. You have to separate the networks, they cannot be bridged.