I can’t get directed broadcast to work with router OS 4.11, neither 5.0 beta 6.
When you send trafic to a lan directed broadcast address, say 192.168.18.255/24, and this trafic is flowing through 2 different interfaces of the router (not belonging to this subnet), there is no problem. It does flow through without issue.
Nevertheless, if the destination lan belong to a router local Ethernet interface, then the trafic is droped. The translation of a directed broadcast to a physical broadcast does not work.
It seems like the local routing does not allow broadcast exploding to another interface when it does come from another subnet directed broadcast address.
On Cisco routers, there is a command to enable directed broadcast on each interface.
According to cisco press 642-812:
“the no ip directed-broadcast command configures the router or switch to prevent the translation of a directed broadcast to a physical broadcast”.
Not providing the ability to do directed broadcast is not in the spirit of RFCs, like RFC2644.
I know that directed broadcast is dangerous, please do not reply with “why do you want to do this, it’s too dangerous ?”.
I know what i do and it is for use on private LANs and anyway broadcast can be easily firewalled by rules on Router OS boxes.
I don’t want to use multicast routing, directed broadcast is so much simpler to implement for simple tasks, and anyway the tool i’m using to send trafic is not designed for multicast.
Directed Broadcast is possible on Router OS but only on a helper address, not the normal subnetwork Broadcast Address.
So you wont be able to use for example 192.168.0.255/24 as the subnetwork broadcast address.
To enable directed broadcast, you’ll need to choose a free IP address on the destination Network, and map the Ethernet broadcast address on it (FF:FF:FF:FF:FF:FF).
You can do this using ARP static entries inside Router OS.
On Cisco routers since IOS version 10.0 (year 1993), you can do this simply by issuying the "ip directed-broadcast " command.
ip directed-broadcast [access-list-number] | [extended access-list-number]
Mikrotik say that this possibility is a security hole. I think that they are wrong. They simply don’t want to code it, because it’s not included inside Linux, and would need a Linux kernel modification they don’t have time to do.
Here is the reason why they are wrong :
Cisco do have this command on IOS since years, to my knowledge, Cisco routers are reliable.
the default state of directed braodcast is off on all router interfaces
it’s possible to use filter rules to restrict broadcast
I think that Mikrotik is not too much interested in making Router OS a very professional product. If a feature is not asked by a majority of clients, and if it needs some important efforts (for example something not included inside Linux).
We see the same attitude from Mikrotik for advanced MPLS and IPv6 features asked by professional users and providers.
Mikrotik say that this possibility is a security hole.
Yes it is a security hole and it is even stated in your provided cisco manual. They suggest to turn this feature off.
On RouterOS we will not add similar command as cisco has, but, as you already mentioned, it is possible by adding static ARP entry to broadcast MAC address so no need for special coding.
It is not a security hole since years : since version Cisco IOS 12.0 (year 2003) “ip directed broadcast” is off by default.
Yes we can use ARP mapping to the broadcast address, but this does not work on the subnetwork broadcast address. Try it, you will see you’ll need to use another address.
On Linux systems, the subnetwork address is always wasted. Could have been used as a normal address… isn’t it ?
I like Routerboard hardware and Router OS a lot, but i hate when you say you can’t do something because it’s a security hole.
There are tones of security holes inside all software systems, Linux or Router OS included, and traditionnaly even more on Microsoft systems because of there fat complexity. But that’s another story.
So please stop to say “it’s a security hole” when you don’t want to do something.
Router OS history shows that you were wrong with that : SSH tunnels is an example. You didn’t want to put it inside router OS, but after a lot of experienced user pressure, you did it a few monthes ago.
Mikrotik my goal is not to be agressive or negative against you, but i don’t understand (and i know a lot of users here do share my viewpoint) why you don’t listen a bit more from your clients, or ask them what they think, before to take decisions. Specialy those special decisions where functionnality are removed, like SSH forwarding or IPv6 over PPPoE.
Here is what you said about SSH Forwarding (Posted: Thu Aug 06, 2009 7:46 am by Normis) :
“This feature was disabled because it posed a security risk to those, who didn’t know about it. We are making a new SSH package right now, where this feature will be integrated, and will be configurable (ie. you will be able to turn it on if you want).”
Mikrotik, you should be a bit less paranoïd, and concentrate on coding. When something not needed by beginners could open a security hole, please eventually disable it by a console switch, but do allow advanced admins to enable it. And perhaps you could ask on the forum what users think before to commit some important and castrating changes.
Users will tell you soon if something is not secure enough because there are hundreds of advanced or expert users. You have only a small set of Mikrotik programmers. They can’t have the global consciousness and knowledge degree of your user community even if they are the best programmers in the world.
For SSH forwarding, admins were not able to use it since Router OS version 3.25 to version 5.0 beta. This is a long period…
This makes a lot of unhappy users during a long time just because you decided (alone) that SSH forwarding was not secure.
“Anybody has any idea if newer versions of RouterOS have the SSH port forwarding functionality back in place?
It is march 2010 and still no official --or unofficial, for that matter-- stance about this.
I guess Mikrotik engineering staff does not really do any real admin work on live networks.
On the other hand, taking more than a year to fix an issue that was stubbornly introduced
by lack of knowledge is unacceptable. Come on! It is just changing a #define in a .config file.
I hope there is no “ip packet forwarding failed: administratively prohibited: wee wee” message in a later version.
After all, moving packets between networks could lead to a security issue.”
Except perhaps if you have full control on the wan link (IP link i suppose) and if routers on it do allow to authorize directed broadcast, the probability that you can get this working is very low.
If you want to do this you’ll probably need to make a VPN, or level 2 tunnels through the wan link, then you’ll be able to get directed broadcast working, if there is no blocking on the path. I was using that before, through IP VPN using Mikrotik routers.
Because Mikrotik routers do not allow directed broadcast by default, you’ll need the trick i gave using the ARP static entry on the destination router that have access to the level2 network you want to send the directed broadcast on.
You just need to add a single static arp entry for the ip address you want to use as a directed broadcast address. Preferably this will be the broadcast subnetwork address, the last one of the subnetwork address range.
Be aware that if you do this you are introducing a denial of service door or a security risk on the network.Do this only if the network is out of risks and well protected.
Can be interesting to remote power on computers through wake on lan on distant networks using only a L3 VPN.
