unfortunately I have no possibilities to block files (exe, iso, dmg etc.) download. I was told here viewtopic.php?f=21&t=150767&start=50#p744362 that I shouldn't use L7 Protocol for this. Do you have a solution that works?

Yes, I am aware of that, but how do the others do it, at train stations, airports ... ? a few weeks ago I set up a WLAN connection at the airport and I couldn't download any files. So there has to be a solution.

Strangely enough, URL Block also works for HTTPS pages.

This works here, for example:

Strangely enough, URL Block also works for HTTPS pages.

This works here, for example:

Code: Select all

^.+(youtube.com|facebook.com).*$

Domain block (not URL block) works because the domain is visible (unencrypted) during the TLS session setup between the browser and the server.
After that, you cannot see anything due to TLS (so you cannot block specific URLs or specific extensions to a URL).
This will also stop working after TLS 1.3 becomes the standard, as it will no longer contain the unencrypted domain in the request.

Yes, I am aware of that, but how do the others do it, at train stations, airports ... ? a few weeks ago I set up a WLAN connection at the airport and I couldn't download any files. So there has to be a solution.

I doubt they were able to block files download over an HTTPS connection. Only whole domains and/or IPs.
With unencrypted HTTP is very easy to block anything you want using a transparent proxy.

Yes, I am aware of that, but how do the others do it, at train stations, airports ... ? a few weeks ago I set up a WLAN connection at the airport and I couldn't download any files. So there has to be a solution.

I doubt they were able to block files download over an HTTPS connection. Only whole domains and/or IPs.
With unencrypted HTTP is very easy to block anything you want using a transparent proxy.

@Link100, You can block HTTPS with devices like Sonicwall, Proxy's, etc, maybe that is what they used at the airport

Sonicwall has a feature that can inspect HTTPS packets, but it is an "extra" feature that does not come with the standard license of the product

@pe1chl, also true

Which I don't understand. HTTPS pages can be blocked with the above regexp, but HTTPS downloads cannot.

squid/proxy filtering with the L7 Protocol principle?

If you have https://www.someserver.tld/some/file.exe, the part visible to L7 is only www.someserver.tld.

Okay, thank you guys for the answer.
Too bad there's no possibility for MikroTik.

This is not a problem of MikroTik!
What you want is simply not possible anymore.
You can blame Google and others for migrating everything to https to prevent that people like you look in the traffic.

You misunderstood me.
As I have already mentioned above, I have set up on airport WLAN connection and I could do everything. Only *.exe, *.mp4 ...files, could not be downloaded. This means that there is the possibility with other router network technology, but it is a pity that the same is not possible with MikroTik.

I'm gonna test this out:
https://wiki.mikrotik.com/wiki/Block_Do ... load_Sizes

EDIT
Works!
Download will be slowed down and then stopped!
Also a possibility. Better than nothing!

You can believe that. I couldn't download any files. Because it seems to be the same. It starts Download, but it is stopped when downloading.

And please understand that it will have false positives. Someone not downloading a file but working in a google docs document will be affected just as well.

Exactly, therefore the next question

On the page there is a hint, without an example of how to do it:
...
"Also You can start this strategy base on File Extensions , Such as ( mp3 , avi , flv , zip , ... )"

Now the question is, how do you do it?

And another question:
...
add action=add-src-to-address-list address-list=Src address-list-timeout=1h \
chain=forward connection-bytes=1970000-0 disabled=no protocol=tcp \
src-address=192.168.0.0/24
... The input in the web interface is incorrect. What is wrong?

"Also You can start this strategy base on File Extensions , Such as ( mp3 , avi , flv , zip , ... )"

It had much better change to work in 2011, when it was written. There was more of plaintext http and less encrypted https back then.

Edit: And about connection-bytes option, congratulations, it looks like you found a bug in WebFig. It works correctly in WinBox and CLI.

With blocking of connection once a volume is reached one can block that connection, but the user can just resume the download with a new connection.
So the net effect is slight delay.

A more effective approach would be to slow down the connection once a volume has been reached: based on volume, assign connection / packet marks to assign connection to a different queue with lower priority / lower bandwidth.

@Sob, my brain is tired, been fighting with L2 fiber provider all day for poor service, but just so I can follow, I can't see what is wrong in the webfig, it shows 1970k instead of 1970000, which seems to be correct according to my current tired brain?

Problem is when you click OK or Apply, it responds with "Invalid value in Connection Bytes" and it's not possible to save the rule.

@Sob, my brain is tired, been fighting with L2 fiber provider all day for poor service, but just so I can follow, I can't see what is wrong in the webfig, it shows 1970k instead of 1970000, which seems to be correct according to my current tired brain?

not 1970k, but "1970k-0" does not work.

Isn't that a limit for the two directions? The 0 is supposed to mean "unlimited" but apparently it is rejected by incorrect validation. You can put a very large number there.

Without..."-0" it doesn't work for me.

Hello to all

Connection Bytes doesn't work properly.
I want to Drop packets people who download more than 150 MB,it used to be Connection Bytes: 157286400 Bytes (in binary) -0 and i had no problem. but now i have to set it to Connection Bytes: 23 M-0, it work somewhat.
Connection Bytes: 157286400-0 ==> Not working
Connection Bytes: 23 M-0 ==> working

Does anyone have any suggestions?