Optimizations for multicast over TAP w/ OpenVPN

[Samuli Seppänen]

Multicast forwarding in OpenVPN is not as effective as it could be, as OpenVPN does not have multicast routing capabilities

[Samuli Seppänen]

This issue has been discussed earlier:

• ​https://forums.openvpn.net/post9180.html#p9180
• ​http://openvpn.net/archive/openvpn-devel/2004-04/msg00032.html

It came up again in IRC meeting on 13th Jan 2011, where jamesyonan explained the issue in detail:

"I think the crux of the email is still true. If you want OpenVPN to be an multicast router you need to intercept IGMP messages and use them to alter the internal routing table. So, right now, openvpn will treat a multicast as a broadcast but it could be potentially smarter and limit the number of receivers on a multicast message if it kept track of IGMP messages that tell it which client wants to be a member of which multicast groups. The point being that this is just an optimization: right now multicast packets are forwarded, just not efficiently."

[dbertolo]

This issue is of importance to us. Our users started to stream HD multicast video via our bridged OpenVPN setup. Unfortunately, OpenVPN does not support IGMP snooping. This leads to the behaviour that if one user starts a 14 MBit/s multicast video stream, this stream will be sent to all connected VPN users. This means that almost all VPN users experience a denial of service. Instead, the behaviour of OpenVPN should be the same as the one of a standard Linux bridge.

There has been a patch for OpenVPN back in 2006 that introduced IGMP snooping: <​http://openvpn.net/archive/openvpn-devel/2006-11/msg00018.html>.

[cutty201]

I am about to embark on a project myself that would bridge multiple sites and allow a multicast feed to originate from one site and traverse all without pegging the source router.

I was about to begin prototyping with OpenVPN but this bug makes me feel that it will fail.

I'm not a total newbie, I understand many networking protocols and basic routing and subnetting, but new to configuring and implementing.

I read the following ​http://openvpn.net/archive/openvpn-devel/2004-04/msg00032.html and it says:

These are the solutions:

(1) Let the kernel do the routing.  That means falling back to one OpenVPN
daemon on each end of the tunnel, as in 1.x.

(2) Use a tun interface in OpenVPN 2.0 in multiclient mode.  This will treat
multicast like broadcast.

(3) Use multicast tunnels -- this will tunnel the multicast packets through
OpenVPN encapuslated in an IP-in-IP container which should work fine.

Option 2 I am 98% sure will not work for me, but 1 or 3 might. Since the bug/feature doesn't seem to be closed, I wanted to comment to understand whether these options resolve this feature or not from someone who is an "authority"

I'm planning on using OpenVPN on a DD-WRT device, which I do believe is/can be a IP Multicast router, if that's the case, I believe option 1 or 3 should 'just work'

[Samuli Seppänen]

I wonder if this fixed in the new 3.0 C++ core...

[Gert Döring]

As the 3.0 core does not have a server component, and the server component is the one that would need to understand multicast -> no, it isn't.

Multicast is tricky, and indeed, to make it work in point-to-multipoint mode would need an IGMP implementation in the server, both in tun and tap mode (plus, in tun mode, you'd need a multicast routing instance on the linux side). Can be done, but will not go into 2.3 as that would be a change that has the potential to introduce new and exciting bugs - you'd need to sniff and intercept IGMP packets coming in, maintain multicast routing state, and replicate multicast packets according to a newly introduced multicast forwarding table.

(As the change would only affect server side, it would mean "you need to run a modified server, but 2.2 or 2.3 clients could nicely connect to it", so it's not as bad as it sounds).

If someone forward-ports the 2006 patch to git master, I promise I'll look at it and give it good consiration. I won't do it, though - no time, and no need myself.

[dbertolo]

Forward port of multicast patch. Works with version 2.1.3 (as a patch to the Debian package).

[Samuli Seppänen]

cron2: can you have a look at the patch?

[jaylik]

cron2/samuli: Any progress with this?
dbertolo: Do you have forward ported version of this patch?

[dbertolo]

No, I passed the operations of our VPN service to someone else. Not sure if the patch has ever been updated to a current version. Probably not.

[Samuli Seppänen]

The patch for 2.1.3 is huge, almost 20000 lines. At a quick glance the changes are real, not just accidental whitespace changes. There's no way we could review and merge a patch that big. I would not be surprised if some of the patch was generated by some automated cleanup script.

The patch will not apply to post-2.4 codebase which has been reformatted heavily. I doubt the patch even applies to 2.3.

This feature, or lack of it, seems to be important for a few people, while most don't care about it at all. If the patch gets a new maintainer, I would recommend the following:

• Port the patch to Git "master"
• Remove all unrelated cleanups from the patch
• Split the remainder into a set of patches, so that each does something useful in itself, and can be reviewed independently.
• Publish the results on GitHub

Even if the changes never get into the main OpenVPN codebase, people who do need this can easily get and build OpenVPN with this feature.

[dbertolo]

The feature is important indeed. The main reason is that OpenVPN treats multicast as broadcast which is a very bad thing (if a user subscribes to a multicast TV stream, it will be pushed to all VPN users connected to the same server).

The patch I attached to this ticket actually applies to the Debian package for 2.1.3 and consists mainly of the Makefile. The OpenVPN code itself is based on a multicast patch from Ulrik Mikaelsson from back in 2006. The only thing I did was to adjust that patch in order to work with 2.1.3. As there were only three minor changes due to renamed methods, I'll attach the original patch as well. Might be an easier start point.

As I mentioned, I don't actually operate our OpenVPN setup anymore. So, I probably won't find the time to migrate the patch to Git master.

[Samuli Seppänen]

dbertolo: openvpn-mcast-r2.patch​ is definitely a more reasonable starting point. Now we just need a maintainer for this feature.

[danman]

until this will be solved, you can use this daemon as workaround: ​https://github.com/danielkucera/vpnmcast