I am using Mikrotik products and currently working on the RB750GL upgraded to 6.27.

My scenario is: I have a local network (Subnet 10.1.101.0/24) on Ether2 happily connected and sending multicast and broadcast packets to each other.
Ether1 is connected to the internet (The Internet network is 192.168.88.0/24) where a PC wants to join this local subnet network through PPP connection (Setting the Mikrotik as PPTP or L2TP Server, all works).
I have created "Bridge-Local" for the local subnet (Ether2) and added it to the PPP Profile that is being used by the PPP connection.
The connection to the VPN works, the IPs are configured correctly and the proxy-ARP enabled on the "bridge-local" interface works like a charm.

However, this is not enough. Many applications and services (Netbios, SIP, gaming, etc.) uses broadcast/multicast packets (Dest=255.255.255.255, etc.) in the initial query or during normal time to discover and connect to other PCs on the same network, and the VPN connection does not forward/route the multicast/broadcast packets from the Ethernet subnet on Ether2 to the VPN Client (and vice-versa), although they have IPs configured correctly, and are bridged to the same bridge "Bridge-Local".

I have tried:
- Setting BCP but it did not work, maybe because it is intended for VPN connection between two MikroTik routers, and not between a PC from one side and a Mikrotik Router from another,
- Installing the Multicast package, but I believe that PIM and IGMP are not what I should be looking for or at.
All I need is the Mikrotik Router to forward/send the multicast packets originated from the subnet on Ether2 to the VPN Client, and vice-versa.

In the Firewall -> Connections tab, for example, the broadcast packets from 10.1.101.100 are U - Unreplied by 10.1.101.2,3,4 and vice-versa.
A topic discusses the issue ("UDP broadcast over VPN") but only gives the router-to-router solution.
All help is welcome - Additional information in the attachment.

Did you ever get this working? I have the same issue.

Thanks.

Same problem here. How can this be solved?

In my case it's StarCraft that cannot be played over VPN as broadcast is used for clients to connect to player hosting a game.

But if we find a solution to this, other applications that are designed in the same way would also work.

In my case it's StarCraft that cannot be played over VPN as broadcast is used for clients to connect to player hosting a game.

But if we find a solution to this, other applications that are designed in the same way would also work.

I'll necro this thread in case the people with questions are still around. The reason for this is your typical remote access VPN only supports unicast traffic. In theory IKEv2 can support multicast which could semi-resolve this. That said if you're desperate to play SC with your friend you could setup an EoIP tunnel between 2 MikroTik routers. This with a little bit of bridging will get you and your bud on the same LAN with the ability to send and encapsulate broadcasts.

MikroTik1 <-> Internet <-> MikroTik2

MikroTik1 WAN IP: 10.1.1.2/30
MikroTik2 WAN IP: 10.1.1.6/30

MikroTik1 LAN IP: 192.168.1.0/24
MikroTik2 LAN IP: 192.168.1.0/24

The mystical shared LAN for StarCraft: 172.16.1.0/24

For MikroTik1:
For MikroTik2
On both MikroTik's create a bridge (to keep it separate from your normal LANs to minimize saturation that could induce latency)
This is all you need to do to have a simple software bridge setup between two remote MikroTik's that will support all types of IPv4 (or IPv6) traffic. You may want to create an SSID just for this bridge, you also could add a single Ethernet port to the bridge on each side and plug your gaming rigs into that port to play SC on. Alternatively you could VLAN this bridge off and present that VLAN on the existing Ethernet connection to your gaming rig.

Some additional to-do's:

You may want it to be routable. In order to do this the bridge interface needs an IP on each side.

MikroTik1:
MikroTik2:
You may want an IP shared between the two bridges for a single default gateway, this has the knock-on effect of sending all traffic out the current master.

MikroTik1:
MikroTik2:
On both:
You may want DHCP to assign addresses and settings so you don't have to:

MikroTik1:
MikroTik2:
On both:
It's up to you to specify the default gateway, you may want one or none at all. You may also have implemented VRRP and want that distributed. You may want DHCP on each side to respond with a default gateway of that side. In most cases local DHCP will respond faster than EoIP based DHCP (over the tunnel) so in almost all cases you'll get an address locally with the right sides default gateway.

The command would look like this on either device, this one assumes using the VRRP IP above shared across:
Closing Words

It should be noted, GRE and NAT aren't friends. So likely you'll want to do this on the WAN interface. You can do a 1:1 NAT to a device behind a firewall but that gets a little more complicated. Alternative, global unicast via IPv6 can save the day.

Also, don't forget about MTU, you don't want the router fragmenting packets and slowing down your stretched gaming experience anymore than it has to. It's best to simply set each PC or the interface used to connect to your special SC network to an MTU size that will accommodate the tunneling right out of the gate. For simplicity, set it to 1400.

The second to last thing, you can have multiple EoIP tunnels between friends to support larger multiplayer scenarios. You can even build in redundancy. Say you have 5 friends (6 people in total) and you are all hyper-nerds that "need" to play this without leaving your houses. You can create a hub-and-spoke layout, all 5 friends connect back to your MikroTik. Fine and dandy. You can also make one of the friends a hub as well, each spoke will have a minimum of 2 tunnels (1 to each hub) while each hub will have 5 tunnels (1 to 4 spokes and 1 between each other). All the tunnels get added to bridges and a loop prevention mechanism, spanning-tree, on the bridges all talks and prevents loops. If one of the hub routers goes down or is unavailable because you played to many games and couldn't afford your Internet the other 5 can play through the backup hub.

The very last thing, if you are interested. The EoIP tunnel can be wrapped in IPSec to secure the traffic if that's a concern. It's possible you'll see a knock-on effect of latency with this though.

EoIP is amazing and I highly recommend it. Works a treat. Thanks.

EoIP is amazing and I highly recommend it. Works a treat. Thanks.

Excellent, did you use my example above or did you find EoIP before I posted?

EoIP is amazing and I highly recommend it. Works a treat. Thanks.

Excellent, did you use my example above or did you find EoIP before I posted?

I just checked back on this and in the meantime my friend suggested EoIP. Just thought I would chime in and say how great it was.

Hi there!
I have resolved similar problem with Starcaraft version 1.16.1 and before:

1. 1. Create pptp server at Mikrotik at network with SC server .

• 2. Go to IP-Firewall-Mangle tab

• 3. Create new Prerouting mangle rule, with next parameters: dst-addr=255.255.255.255; proto=udp dst-port=6111 in-interface=pptp-in1 action=route dst-address=192.168.88.3 (it's my PC comp with SC server)
  Code: Select all

  [admin@MikroTik] /ip firewall mangle
  add action=route chain=prerouting dst-address=255.255.255.255 dst-port=6111 in-interface=pptp-server passthrough=yes  protocol=udp route-dst=192.168.88.3

• 4. At other side PC create pptp connection, setup checkbox "use default gateway from other side" at properties IPv4 protocol

• 5. Try to play game.

Description:
I see packets to 255.255.255.255:6111 from my friend, whithin he connected over pptp to my mikrotik. SC uses broadcasting udp port 6111 for search LAN servers.
I mangle this packets and hard routing it to my PC(192.168.88.3). Game server becomes visible for my friend.

Hi,

I have tested with RB951 ROS version 6.40. I have do EOIP VPN and bridge the EOIP tunnel to Ethernet interface. Then I do multicast stream from 1 side to another but it didn't work. As I search it forumn it need IGMP Snooping enable on bridge interface. It seem RB951 not support that feature.

Thanks,
Sovandara

Hi,

I have tested with RB951 ROS version 6.40. I have do EOIP VPN and bridge the EOIP tunnel to Ethernet interface. Then I do multicast stream from 1 side to another but it didn't work. As I search it forumn it need IGMP Snooping enable on bridge interface. It seem RB951 not support that feature.

Thanks,
Sovandara

Multicast does not require IGMP snooping. The bridge should flood (broadcast) multicast packets out all bridge ports without that feature. At layer 2 the MAC of an IPv4 multicast packet will lead off with 01005e and that tells the bridge to flood it out all ports (or with IGMP snooping enabled, flood to only joined ports). If it's truly not doing that, start with a report to MikroTik. You may be hitting a bug.

Separately, in 6.41rc IGMP snooping is implemented and can be toggled on. This will force the bridge to operate in software on your hardware, with EoIP being the likely limiter of performance anyways it might not be the worst if you absolutely require that feature.