Opened 3 years ago

Last modified 3 months ago

#79 new Feature Wish

Optimizations for multicast over TAP w/ OpenVPN

Reported by: samuli Owned by:
Priority: minor Milestone:
Component: Networking Version: git master branch
Severity: Not set (if unsure, select this one) Keywords:
Cc:

Description

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

Change History (5)

comment:1 Changed 3 years ago by samuli

This issue has been discussed earlier:

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."

comment:2 Changed 22 months ago by 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>.

comment:3 Changed 10 months ago by 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'

comment:4 Changed 9 months ago by samuli

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

comment:5 Changed 3 months ago by cron2

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.

Note: See TracTickets for help on using tickets.