Has anyone found a reliable and low maintenance technique for limiting or blocking video streaming?
This burner of bandwidth is particularly costly when using satellite links. I realize that video streaming providers have gone to great lengths to thwart techniques to block streaming, but I thought I would ask anyhow.
Since many sites switch to use https instead of http, (f.. google was initiator of this bad trend, to make filtering of their ads much more difficult) it is not possible to filter video (streaming) reliably. However, what you can do is to throttle download speed to your clients. Which will make watching videos very unpleasant 
but still keeps reasonable surfing speed, using 128kBit/s, for example. Another solution would be to block certain sites completely. But this is a problem with youtube, for example,as they use same IPs as other google services, so the blockage is more complicated to implement, using a proxy, for example. When your emphasis is on "low maintenance", with the meaning of "simple implementation", then use speed throttle. In case of more detailed efforts of blockage, levae me a note. I do special hotspot systems for a living
1 Like
Not to blow my own trumpet, but Gargoyle has https url filtering in the latest development versions.
@westislander may look at Gargoyle as an alternative if vanilla Openwrt is not suitable. However, Gargoyle's simplicity is not to everyones tastes, and may inhibit some other goals you are trying to achieve.
As many video are https, there is no real content-based blocking/throttling possibility. You are left with speed throttling or blocking certain sites either by IP in firewall or by DNS.
One low maintenance solution is to use adblock to define DNS based blocks for the most popular video site domains. youtube.com etc. That prevents users from finding the address of the sites. (Adblock package also allow you to hijack DNS packets rerouting them to the Openwrt server, preventing clients from using self-defined DNS server addresses (like 8.8.8.8).)
1 Like
I bet, using a proxy (SNI inspection), in case of good iplementation. Which is not very new, as I did it directly on openwrt years ago already. In case of bad implementation, it might be done using iptables.
However, this method is not really reliable, which means, it will work for certain sites, depending upon their https implementation. Traffic throttle works for all sites. And not only on https.
Using an iptables webfilter module (with SNI support).
Given the vast proliferation of SNI support since the year 2000, it is reasonably reliable.
As long as the net anonymity people don’t make their voices too loud and request that to be made secure as wel.
Although, from my understand of TLS (and hence the necessity of SNI), this would be troublesome anyways.
Don’t knock it till you try it of course
A big thanks to the many responders to my question.
@reinerotto: I was thinking of speed throttling. I recall seeing that a well know streaming provider would attempt to reserve a minumum 500kilobit/second bandwidth in order to stream. If there was additional bandwidth, they would reserve quite a bit more. So while this may be an effective technique, I have not yet found how do do this within Openwrt , selectively or otherwise.
@lantis1008: Interesting suggestion to use Gargoyle firmware. I haven't much experience with it. Is selective bandwidth throttling possible? How frequently does Gargoyle get security updates?
@hnyman : I think your technique will have difficulty with smartphone apps. which may not bypass DNS, via a multiplicity of direct IP addresses. Most of the streaming traffic I expect to be blocking will be via kids who are glued to their smartphones. There is a mind boggling universe of video content directed at kids - and apps directed at keeping kids using their smartphones as much as possible. Excessively so in my opinion. I'd be interested to hear if anyone has found a way of classifying video streaming by observing traffic patterns "on the fly".
Official releases, not very often (1 per year).
Beta releases are very frequent and try to keep up with the latest.
Version 1.10.x is still based on Openwrt 15.05.1
The newest version 1.11.x (due out not long after Openwrt 18.06) will be in line with all of the security updates done in 18.06.
Like I said, it may not suit all of your needs, but if you have the time it might be worth a try.
For a start:
https://wiki.openwrt.org/doc/howto/packet.scheduler/packet.scheduler
However, in case you are running a public hotspot: Bandwidth shaping is usually done in the "Captive Portal", in case it is based on "CoovaChilli". Such systems I do for a living. Be warned, though, learning curve for CoovaChilli is steep. You know now, whom to ask, just in case
New url: https://openwrt.org/docs/guide-user/network/traffic-shaping/packet.scheduler
(wiki.openwrt.org is for archival purposes only and doesn't receive any updates any more)
@reinerotto: Thanks for the link. There seem to be a lot of possible queueing disciplines, so a bit of a learning curve.
@lantis1008 I may try this, It looks like a great product. However I really think security updates are important, its my top reason for using openwrt.
@hnyman: I made a type in my previous response , I meant to say "which may bypass DNS".
While the content may be encrypted, the protocols and behaviour are still observable, at least at the IP protocol level. This does offer the possibility of some classification and control. It might be challenging to avoid "retries" which waste bandwidth.
@tmomas: Thanks!
Block all port 80 and 443 traffic, then install a squid proxy and make your devices use this. Use the squid proxy the throttle sites based on their URL using delay pools and to set DSCP marks like CS1 so that you de prioritize the packets in wmm queues.
Does this also work for https-videos, embedded in otherwise "innocent" https-sites ?
You can only filter the https-domain, AFAIK.
I.e. on https://innocent.com , there is a link to innocent.mp4.
Will the delay pools work for innocent-mp4 only ?
No not for only specific sub urls on https sites. At least not without a bunch of certificate based hacks where you install a signing cert on all the clients and then they trust your proxy when it lies to them about who they are connecting to... It's not a good solution, except maybe at some corporate installs with security experts involved.
Thats what I know, too. So I do not think, such a sophisticated approach is a good solution for the thread opener, as not easy to configure/maintain.
I agree, don't go towards the certificate based thing... But a simple proxy can be very useful even in the case of HTTPS. For example, how much bandwidth is really being used by video streaming individual videos served off of myriad sites that mostly don't do video? For example if you go to a site that has a video, it often is really just an embedded link to some youtube or vimeo or whatever goofy thing is the latest hotness.
You can combine the first approach: proxy based filtering on domains such as googlevideo.com (youtube) and nflxvideo.net (Netflix), and movetv.com (Sling) and espncdn.com (ESPN) and etc etc, where you know mostly video is coming through...
Then you can also use your proxy to up-prioritize important sites you really want to have access to, maybe some work related sites etc, office365 or google docs or whatever equivalent. You can DSCP mark them say AF31 or something so they are prioritized on your lan and in WMM queues. Finally, you can keep logs on what is being used and tune your prioritization as you realize certain sites are becoming a problem or need better priority. The whole approach is very flexible and operates at the correct level of abstraction (ie the URL or at least domain name level).
I've still found caching useful as well, as for example when upgrading desktop Debian machines and packages need to be downloaded. They're downloaded over http rather than https and they get cached. After upgrading one machine, upgrading the second machine comes almost entirely out of the cache at gigabit speeds. Caching is also useful for common javascript libraries delivered over CDNs and things.
For example suppose you by default tag everything that isn't a known set of "work related" or "important" sites with say CS1, then you limit all CS1 traffic to say 1Mbps. then with known video streaming sites you further limit to at most 500kbps, then with important sites you tag AF31 and allow full bandwidth. Sure this means on lots of everyday sites you'll use only 1Mbps instead of your full say 10Mbps but for the most important stuff you'll get the full 10Mbps, and any streaming you haven't specifically tagged will at most do the 1Mbps compared to currently 3 or 5 that is typical of many HD streaming sites, and the known sites will be cut down to say 0.5Mbps. Cutting your bandwidth bill by more than a factor of say 5 while keeping all your most important sites at full speed is not a bad result 
Lots of interesting ideas. I'd like to try something really simple. Just limit the incoming bandwidth to an arbitrary amount, say 400 kilobits. Is there some simple command or configuration option for OPENWRT to do this?
Thanks for the many suggestions. I think maybe starting with something simple would be useful. Is there some simple way to set up a speed limited wifi SSID with max throughput limited to , say 500 kbps no matter the connection quality?