Multicast VLAN over a EOIP/IPSec tunnel

Hello,

I am trying to forward an IPTV VLAN over the encrypted tunnel. The main local Internet facing router is an Ubiquiti ER-X because of the hardware NAT. On the local LAN I have a MIkrotik RB850Gx2 acting as a VPN / IPSec endpoint to all my connections. So basically to have the remote HAP LIte to be able to transfer VLAN over an encrypted tunnel I have to setup the tunnel in 3 stages:

  1. Setup a GRE tunnel between remote HAP Lite and RB850. At this stage ER-X forwards pure GRE to RB850. I cannot do an EOIP tunnel because ER-X won’t forward GRE packets if I setup EOIP interfaces on MIkrotiks on both sides somehow (anyone knows how to adjust ER-X for this?).

  2. Setup an IPSec over the GRE tunnel between the GRE tunnel interfaces;

  3. Setup an EOIP tunnel between the GRE tunnel interfaces.

At this stage the traffic flows fine, I can ping the endpoint in and out and vice versa. Now the question is (I am not sure if this is even possible, that’s why this new thread here):

If I create a bridge with the IPTV VLAN alongside with a new VLAN created on top of the EOIP endpoint as the bridge ports within RB850 and afterwards I create a VLAN interface on the remote HAP Lite, everything works as expected: DHCP works, traffic flows, IPTV STB works fine. But because I encrypt the whole VLAN this means that if a local STB is turned on the multicast traffic is transmitted over the IPSEc tunnel as well. I have measured the IPSec performance with the Bandwidth tool over to HAP Lite. Considering the overhead of the GRE / EOIP tunnels the max throughput I could get was 20Mbit/s. The problem is if more STBs gets tuned in the remote HAP Lite will not be able to encrypt / decrypt it’s own traffic because all the other multicast traffic would still be there. Is there a way to avoid this situation? I would like the remote STB to only see the traffic destined for it only. Maybe some bridge filtering or multicast routing would do this? I consider myself lucky to go this far, knowing I am not a networking guy at all, but this is where I stop because of the lack of ideas. I am grateful for any hints.

Thanks,
Darius.

Anyone please?

You need IGMP snooping to limit the traffic passing through the bridge. Currently, Mikrotik does not support IGMP snooping.
To implement multicast routing you should at the sources ( the routing interface facing the multicast must be in the same logical segment as the source).

Thanks for the response tsvgos.

Is there any way to apply some filter to the bridges or something similar? I don’t have the access to the multicast source servers unfortunately.

Thanks.

Yes, you can filter traffic in bridges. You could have studied that in the manual.

What exactly should I target at the filter? MAC addresses / IPs, something else? There is a plethora of options in the bridge filter, I got totally lost in those.

Thanks!
Darius.

Hi!

Start by saying that I have not the answer for you but I’m in the same situation as you. I’m sending multicast IPTV over an EOIP-tunnel but I use an SSTP tunnel as a ‘carrier’ for the EOIP. The problem you mention that the multicast streams for several STB are sent over the ‘bridge’ ie EOIP-tunnel and caps the mikrotiks is exactly what I see here. I was searching for IGMP-snooping when I found your thread and maybe we could work this filtering question out. I’m not in any way a RouterOS guru so bare with me.

I have done several tests and have found that the maximum bandwidth I can get between my routers are ~ 27 Mbit over the EOIP-tunnel when I use the bw-test that’s found in the RouterOS. This is more than enough for both SD and HD channels as they in my environment consumes 5.4 resp 13 Mbits. I can watch SD without problem but when I switch to an HD channel the video starts to stutter and sound is cracking. This is very strange but I have found out that when I switch channel, it take some time before the ‘old’ stream stops and I think that this has to do with the underlaying multicast behaviour ie the source has not stopped the stream because it is unaware that there are no listeners. ( IGMP snooping anyone? ) :slight_smile:

IGMP and PIM.
Normis said that this will not improve.
IGMP and PIM will not be improved and supported in the coming years