One cannot effectively block anything anymore with a basic soho router. You need enterprise grade equipment or business class with IDS/IPS etc…
Typically that kind of inspection kills throughput.
There is no definitive solution because RouterOS just has too many options. Not knowing what you are trying to achieve, this is one way I tested to block websites using L7.
The idea is to block outbound requests to the site via DNS (traffic you usually control on any router connected to the Web).
So assuming you already made the proper L7 regex named youtube:
You then add a drop rule for those packets in the firewall for both the input and forward chain. I tested this last night, and it worked on my home router for Youtube, Pornhub, etc. It even blocked web proxies from reaching those sites. I had to use Tor to bypass the block. It might cause unforeseen issues, but I couldn’t see any when I tried this method. I didn’t test it with Apple/Android connected devices though.
Furthermore, since you don’t require a global block, you will need to use DHCP to assign a static address to the clients/schedule you want to block and add that information to one of the mangle rules.
Please note that if you try to filter all inbound traffic by making L7 rules directly in the forward chain, or worse, in the firewall, as suggested in many online tutorials, it will be CPU intensive with many clients and any encrypted packets (port 443) will bypass the filter easily i.e. Chrome will not be blocked. Trying to control that traffic for QOS purposes is also quite futile in my limited experience (only works with Firefox).
I then block those packets in the firewall. This method seems effective to control bandwidth in queues as well (worked for Chrome and my smart TV). YMMV.
Sorry for stealing this thread, but what is the simplest way if you just wanna block a certain website adress for all users on the router att all times?
Firewall Raw if it’s a limited range - you can use the firewall connections tab to get the addresses. Alternatively, L7 and TLS Host methods can work to build an address list, but are easily bypassed. MT doesn’t offer simple URL or keyword filtering like those found on consumer routers.
With a DNS server, you can block ads and any site you wish. If it’s only a few Windows computers, you can also block sites with the HOST file.
There are no easy block for that.
As long as you do not have 100% control of the client on your network, you are out of luck.
On a corporate network, you can use Forecpoint or Palo Alto that intercepts the certificate and examine all https packets.
Even there Quic passes trough, so you need to block the Quic protocol (HTTP/3) so that communication goes to HTTP/2. https://en.wikipedia.org/wiki/QUIC
Make a rule for what IP each user can reach and then block the rest…
The problem is that there isn’t a single simple “address” in many cases.
Creating a global-scale video hosting system is non-trivial in the extreme. You can’t do that with a single machine, nor even safely so with a single domain name. Thus round robin DNS, the distinctions between youtube.com, yimg.com, gstatic.com, 1e100.net and whatever else Google’s got set up these days.
Simple address blocking works for simple services where such measures aren’t in place. (e.g. This web forum.) Blocking a whole cloud service without breaking everything else using the same cloud (e.g. GMail) is nontrivial for the same reason the service itself is nontrivial.
How do you upload your videos if that works? Don’t worry Chrome let me watch.
And the Filter docs do pretty well at clarifying most of the discussion here – basically it says there are some case this method doesn’t work…
The MT docs even have a yellow warning box specifically about YouTube filter using the “tls-host” method:
A tls-host matcher is a powerful tool to block HTTPS-based websites, > but for example, Youtube is using QUIC > (UDP-based protocol) instead of normal HTTP/2 (TCP-based protocol). TLS-host does not work with QUIC as it depends on TCP connection.
On tls-host in a Firewall>Filter filter rules, there are some subtleties here:
Allows matching HTTPS traffic based on TLS SNI hostname. Accepts > GLOB > syntax for wildcard matching. Note that the matcher > will not be able to match hostname > if the TLS handshake frame is > fragmented into multiple TCP segments > (packets).
So if “tls-host=domainname” isn’t working more generally with other website, check/fix the MTU and/or MSS cramping setting/config are right. If you do have fragmentation, you’d likely get a performance increase by fixing it – that might allow you not worry about some YouTube escaping. . On the other hand, using any Layer7/L7 RegEx on your router is certainly a good way to decrease your performance. While this is in fact largely what enterprise/other content filtering solution do – but it takes a large CPU because they use a complex set of match rules that have way more context (e.g. L7 rules can’t use the whole packet), typically with some automatic updating as blocking rules need to change with websites methods to avoid.
Which is why folks here suggest this + firewall + DNS redirection as the “best you can” approach for Mikrotik. But even if you do all that, still have to consider IPv6 path something like Google/Apple try to steer folks to, and now enabled by default in V7. The Mikrotik IPv6 firewall will protect inbound, but it allow LAN IPv6 without issue by default.
But in the case of YouTube with a Chrome browser… you really are trying to fight a US$1T company whose revenue depends on people seeing content like YouTube with all the tools – they control the client AND server, thus can employ a variety of technique so it “just works” for the customer – including bypassing most common things a home router could to block traffic. This isn’t necessary an attack – people do misconfigure routers and some find it a feature that Chrome “fixes it”. Or in case of QUIC, try to do something about design problems with TLS+TCP that limit performance.
Not taking sides on approach here, but if your technical need is “stopping YouTube from working” it’s just hard and/or lot of work/money.
There’s one simple and reliable solution, but it may not be very convenient. If it’s some company network, then don’t give users direct internet access at all. Only allow it via proxy with ACL, where you allow only hostnames (not numeric addresses). Then if you block connections to www.youtube.com, no simple trick will allow to get around that, QUIC, DoH, ESNI, nothing will help, everything will be reliably blocked. There’s still VPN, that’s another level, but if you find what people use, you can block its servers the same way. Downside is that it’s not commonly used, so not everything may be ready for that.
I don’t have any ready-to-use and fine-tuned solution, but generally for example SOCKS proxy.
As user you’d have PC in LAN, without any connection to internet. To access internet, e.g. to browse web, you’d configure web browser to use SOCKS proxy provided by admin. Proxy would be configured to only accept hostnames, not numeric addresses, so even if you’d write down blocked server’s IP address, you wouldn’t be able to connect to it and get around blocking this way.
From admin perspective, it would be easy to block anything by hostname (any port, any protocol), including subdomains, because proxy gets that in readable form (it’s the hostname client wants to connect to), no matter if the connection is encrypted or anything. A purposedly built solution could easily make statistics for each user (proxy could require unique login for each to make sure that it’s able to tell them apart), show most accessed domains, amount of transferred data, etc. So if someone would e.g. tunnel traffic through own VPN server at home, it would show up immediatelly.
Two main problems is that not all software supports proxy (so some wouldn’t work at all with this), and that there’s no simple system-wide config for this (in Windows, some software takes proxy from IE settings, but probably not many), so it would be annoying for users travelling between different networks.
@SoB is right – more pointing out Normis false hope it’s just one config line. Useful feature, incomplete as comprehensive web blocking tool.
I really do think trying to effectively block YouTube without effecting things too much is difficult on Mikrotik.
Since I don’t mind playing devil advocate… SOCKS5 is designed for this kinda of thing – all traffic goes through a single port, if the OS/browser respect it. I wouldn’t recommend trying SOCKS on v7.1 yet…
But I’d imagine home device support auto-proxy configuration via a “PAC file”: https://en.wikipedia.org/wiki/Proxy_auto-config. Zscaller had a picture/description of how PAC work. Recall also being some DHCP things to do to enable SOCKS5 too. If stuff didn’t allow PAC file/app didn’t work, or needed more access, etc – then you can could allow direct access of those services in the firewall per device. For really tricky things, allow direct HTTPS direct for “trusted device” in firewall config. Or perhaps device-class via script in DHCP server that put in a firewall list for IoT devices based on starting MAC or reservations, etc…).
Certainly re-architecting you config/network to enable blocking using this method. I think it’s a game of whack-a-mole to try with only a Mikrotik in the tool bag. But if that’s the case, SOCKS may be worth looking at – something to try – since the DNS approach’s days are numbered, and not much to do about QUIC. Again stick to v6 if you do.
Problem with this solution is that evolution simply went in different direction. It’s easier to give devices direct access to internet, and not bother with any proxy server, because that’s extra.
In the past, with plaintext everywhere, it wasn’t even too difficult to block something. But that’s action and reaction, more blocking means more incentive to invent something that will get around it. So now we have encryption everywhere, and when there’s direct access, filtering becomes more and more problematic. I don’t think that proxies are magical solution, but if all traffic has to go through proxy, as admin you definitely have tighter grip on it.
I don’t know if someone will reinvent this, and if it has any chance to become popular. I wouldn’t bet on it, but who knows…
I wouldn’t recommend SOCKS either. Or even trying to solve this “problem” on a Mikrotik – focus on managing the bandwidth. If you need to restrict user in fine grain manner, look beyond the Mikrotik. But if you looking for novel Mikrotik approach that do something to block website (how much YMMV), MT offer something LOTS to do and try, but never be “definitive solution”.
So more fodder for trying. At least SOCKS knows the always knows domain names, and if device/browser did support it, they probably respect any policy. DNS tricks are easy, but eventually avoided by clients. SOCKS5 at least be stable (eventually in V7), has a UI, and either clearly work, or not. Basically turn an SOCKS from yet-another-method avoid the very same MT content filters discussed here (e.g. the force DNS firewall rules discussed here would do nothing if some DID configure their device to use SOCKS) – into SOCKS more historical form as the defensive gatekeeper. Start with a deny on all IPv4, then white list what doesn’t work with SOCKS. Since blocking a one website is likely not the only thing someone might want to block.
What to do about IPv6 and block – this I’m more clueless – that seems even harder (but maybe easier). Sure there are some [likely partial] solutions out there. If you wanted to foist IPv6 usage, another idea along these lines is offering only SOCKS5 access for IPv4 is certainly an approach – allow you to focus your blocking effects on what to secure IPv6. More idea – since whatever you do in IPv4 firewall would have to be replicated in IPv6 firewall to enable it – making any block on a MT literally TWICE as much work. Since if you have IPv6 on the WAN, in most cases, you’d want to use it – outside being able to block websites, it generally offers speed benefits.
Also the other thing to consider is if you only have mobile device (Apple/Android), there may be easy/cheap ways to restrict websites. There is lots of Apple’s MDM approach for iPhone and iPad, including using using Profile Manager on a Mac - that lets you block website (and more). Android has similar stuff, again an expert. Also there are a lot of DHCP options that might be able to control some policy (can’t think if web site blocking, but sometimes there are esoteric DHCP things to implement a network policy. Also believe there are Made for Mikrotik SaaS solutions out there that attack this same problem by applying these MT blocking techniques more automatically.
Basically a Mikrotik asking the network device to respect some protocol and block if they don’t is different way of skinning this cat. You’d be looking for why something didn’t respect. Or accept you may need to apply large org technique at the home to more realistically solve to do any website blocking effectively.