Not without rooting it.

Sadly this is not possible, Mikrotik currently doesn't even have simple port mapper tools.
There have been requests to support port mapping and have tools like UDPXY for a long time... so far without any official reply.
Too bad, because most of the cases could be handled by including socat in ROS, even if it would be say accessible from commandline only.

So if you need these features, don't buy Mikrotik

I'm surprised that there isn't a [x] checkbox for this.

There's a [N/A] check box for this ... white ink on white background

Could you use dstnat for this?


The idea is that we're taking undirected broadcasts on UDP port 9999 and reflecting them from an arbitrary Ethernet interface to the gateway IP on the target VLAN. If the protocol uses directed broadcast (e.g. 192.168.99.255/24) then so much the better.

I'm relying on UDP broadcast flooding here, so that we pick a copy of the stream off as it flies by. We're not asking the router to do anything it wasn't already doing: copying packets among ports.

Open questions:

1. Can you do this with arbitrary switch ports, so long as they allow broadcast flooding? The dstnat chain is pretty early in the flow diagram, so do we prevent the traffic from staying on the source VLAN by doing this?

2. Assuming the redirect action takes traffic away from the named port rather than copy it, can we get away with doing this anyway so long as we point it at a port that's either not got anything connected, or at least doesn't have any hosts that need to see the redirected stream?

Really what I want is action=copy, but I don't see anything like that.

If this were for TCP, then sure, we'd need an ALG or proxy on the device, but for a broadcast UDP stream? It seems so tantalizingly close to existing functionality. If my formulation doesn't work, it seems like something like it should.

Would a `dstnat` work even if I don't know the IP address of the recipient?

It isn't in the nature of this type of protocol for the destination to be secret or random. If it isn't a configurable item somewhere, the destination IP will be as well-known as the UDP port number, presumably 10001 or 1900, rather than my example's picked-out-of-the-air 9999. If it were otherwise, the intended receivers would have no way to "catch" the stream. The protocol might be using universal broadcast, 255.255.255.255 in my example, or it could be directed broadcast, as I say. Don't ask me to tell you which. You've got the device; you tell us!

I have no idea what that underlying protocol is; I don't even have one of these devices. A MikroTik forum isn't the best place to pursue the matter. Find the details, then bring them back for us to chew on.

Given the presumed-relevant port numbers above, some playing around with a packet sniffer should tell you what the destination IP is.

Flood Unknown Multicast

In the thread title, you said "broadcast," but now you're saying "multicast." Which is it? It matters.

I'm not sure if that wouldn't reduce security provided by VLANs?

Do I understand correctly that you want VLANs to isolate things, but then you ask for some configuration magic that un-isolates them, but with no reduction in this vague notion of "security?"

By asking this question, you've decided this protocol is to be allowed through. I can only presume you did that advisedly. I can't make the decision for you. I don't have a "Ubiquity Cloud Key Gen2+," nor do I know what it's good for, nor do I care. All I'm talking about here is UDP. Anything above that layer of the network protocol stack is up to you.

I did some minimal amount of web searching in preparing this response, but couldn't find much of use. You'll be better motivated than me to find protocol manuals, IP addresses, port numbers, security implications, and such.

Until you gather that info and make your motivated evaluation, all I can tell you is that my dstnat solution might forward a single UDP port through. Note the tone of the offering: I'm fully prepared for someone here to tell me that it won't work and can't be replaced with something that will.

I'm using a switch with SwOS

If the SwOS device isn't one of those that can be made to reboot into RouterOS, and if you cannot move the UniFi device to a port on the RouterOS device ahead of it, I think you're pretty well stuffed. My solution is based on the notion that the UniFi device is plugged into a RouterOS device, allowing you to write rules that make intelligent decisions about the traffic based on destination IP, port, etc. With SwOS, I believe your only option is to flood broadcast traffic, which sucks, and it might not even work, if there is no option to flood across VLANs.

By the way, I assume your drawing is wrong in its implication that the UniFi stream source on VLAN 20 is on the same switch port as the untagged traffic's recipients, these mobile devices of yours. I hope the truth is that the traffic must cross the switch in some way, emerging on another port.

I point this out not to nit-pick, but in case you decide to post another drawing. A misleading drawing is nearly as bad as no drawing at all.

Scratch that dstnat hackery above. I think you might be able to accomplish this under RouterOS more simply with a switch chip rule. Something like this:


This copies UDP port 1900 traffic from VLAN 20 on ether1 to ether2, down at the switch chip level. Think of it as per-L3-protocol mirroring. You're allowed to set multiple target ports if necessary.

The analog under SwOS is ACL rules, which are less powerful, but perhaps sufficient for this simple use case. Translating the RouterOS rule above to the pointy-clicky actions necessary to replicate its effects should be straightforward.

Either way, I'm counting on the port VLAN filtering to strip the VLAN 20 tag on its way out the target port according to the diagram above. There's a "new-vlan-id" action under RouterOS, but it applies to only one switch chip — Atheros8316 — which doesn't seem to be used in any current products.

@tangent, clever indeed!

Btw, the forum link to the "switch chip rule" is broken. Also, this might be interesting as well: "Switch Chip Features - Rule Table"

Yes, Larsa, that's the link I meant to add; thanks.

I should note that if my solution does solve the OP's actual question, it doesn't solve the total problem. There's doubtless more configuration needed. This UniFi protocol presumably carries an IP address from the VLAN20 side to the untagged side, which uses a different subnet, so now you need inter-VLAN routing and possibly firewall adjustments that let those mobile clients connect back to the UniFi thingy. This is where we get into "is this secure" questions.

If this feature of the switch chip works as I think it should, I believe you can use this same technique to solve the perennial mDNS/Bonjour-across-VLANs problem. I'd try it out and report on it, but I've managed to avoid use of VLANs here so far.

Yes, Larsa, that's the link I meant to add; thanks.

I should note that if my solution does solve the OP's actual question, it doesn't solve the total problem. There's doubtless more configuration needed. This UniFi protocol presumably carries an IP address from the VLAN20 side to the untagged side, which uses a different subnet, so now you need inter-VLAN routing and possibly firewall adjustments that let those mobile clients connect back to the UniFi thingy. This is where we get into "is this secure" questions.

If this feature of the switch chip works as I think it should, I believe you can use this same technique to solve the perennial mDNS/Bonjour-across-VLANs problem. I'd try it out and report on it, but I've managed to avoid use of VLANs here so far.

So, any luck with this?

Since you're quoting me, I suppose you're hoping that I've developed this into a cookie-cutter solution in the meantime?

Sorry, I have no interest in doing so. I don't own any UniFi gear. I was approaching it as a practical puzzle, not as a problem I had to solve for personal reasons.

How about this: you pick the idea up and tell us what's wrong with it. Then we can advise.