Hi, friends
I need to restrict external game traffic. I tried to block traffic by port, but it’s very unreliable, because many game servers on untypical ports.
I tried block all external UDP, but VoIP and voice-messengers died… Can I make delay of this traffic? Suppose, delay in 1sec is very imperceptible for VoIP, but very annoying for gamers and it’s ping…
Sounds like you need to put them on their own subnet, vlan and then priority queue their traffic low or turn off their internet at a certain time.
What is the problem with them gaming???
Them gaming is administrative prohibited.
And I can’t limit all traffic from this subnet, need allow to use VoIP and some other UDP. I can’t distinct VoIP UDP and gaming UDP 
Well if they are on static IP addresses then you can certainly make some rules up for their PCs…
You could limit throughput etc…
… and? As I wrote above, I can’t distinct traffic, so the only idea is to delay all UDP traffic. Is any other idea or you can advice to realize the delay?
VOIP UDP sits on port 7000-7100 (STUN) and instead of blocking choose to allow traffic and block the rest of the UDP traffic.
Unfortunately, some voice services, like discord, using ports above 20000, and some game servers using below 10000, i tried it…
I had a glance at Discord and it seems to be above 50000. Address list won’t work because the connections are a sort of P2P.
I can’t represent complete list of voice messengers with ports, but need to block game traffic and don’t touch voice…
If the location is a business and the request comes straight from the top, imho the only viable solution is per computer screen monitoring after all employees have been notified.
You get caught gaming, you are out.
Trying to cover all bases on the router is a cat and mouse game. And we all know Jerry is a sneaky one.
Ok 
Can we discuss delay sending of UDP packets? Some ideas is to use simple queue, but in this case I define some speed of UDP for voice and delay all packets above this limit, but can I delay all packets and not decrease speed?
No.
The queuing in RouterOS will only delay packets when there are too many of them (the rate is above the configured rate for a while), you cannot just delay packets at random.
And in general it can be said that when you “need to control network traffic” your life will become more miserable every day.
I would advise you to try to get out of that position. Move the responsibility for such things somewhere else, like in a (employment) contract, and handle it on a human-to-human level. “when we catch you gaming you are out”.
All the developments in internet networking are towards moving the network operator out of the control loop to allow/deny what the network users are doing.
(and even notice what they are doing)
Everything becomes encrypted, VPN is used, etc etc. You will have to accept it because there will be less and less you can do every day.
I agree with pe1chl. Blocking every UDP may not help. You will end up with an unstable net, where stuff that should work does not work, and thing you try to block, just change from UDP to an TCP port. So if this an work place, make every one sign a contract, where misuse has consequences. Also do inform that all network traffic are logged.
And you can actually do that. You can setup IP->Traffic Flow to log the fields you are interested in (IPFIX format) to an external netflow log server, which can be as simple as a Raspberry Pi connected to your router.
(I have shown a simple netflow server we use for that in another topic)
Then, when someone is caught you can search the log and present them with the evidence (how long it is going on, how much per day, etc).
With that in place (and your users warned), you can take away the focus from trying to block things, which will be fruitless anyway and will require constant attention.
That’s a wrong assumption. Already with 400 ms round-trip delay, the conversation becomes uncomfortable, because the other party’s reaction to what you say is so delayed that you think they are silent and start clarifying or continue speaking, and then the reaction arrives so you stop talking etc. One second delay would completely ruin any bi-directional conversation, unless you’d use the protocol used in half-duplex wireless communication, where you have to explicitly indicate to the other party you’ve finished talking and switched yourself to listening-only mode.
Technically, there are no tools in RouterOS which would allow to delay traffic - you can restrict the output rate of a queue so if many packets arrive to the queue at a faster rate, the first one of them will be output from the queue immediately, i.e. almost at the same time it has arrived, whereas the last one of them will be output from the queue much later than it has arrived, but that’s not the same thing as delaying every packet for the same amount of time.
Regarding blocking the gaming traffic, as you’ve found out yourself, the actual issue is the classification. Like in other cases, you can try to identify the traffic you want to block (and fail doing so), or you can try to identify the traffic you want to permit, and block/limit the rest. This is typically an easier task, because the VoIP or conference services use less IP addresses and/or domain names, and usually document which IP address ranges, port ranges etc. they use, so you can set up the classification rules using this information. Plus you get a more useful feedback when using this approach - the VoIP users will let you know that you’ve restricted them, whereas the gamers will never let you know you haven’t restricted them.
But still you can have false negatives if some gaming service uses the same port range like some conference service and the conference service uses too many IP address ranges so you can’t use them as classification criteria, so the administrative measures have to be taken anyway.