How Can I: Classify Netflix Traffic from Unclassified Traffic?

Netflix is listed as one of the protocols that the Application Control filter can detect -- are you saying you have throttling / blocking rules in place with Application Control enabled and they are ineffective?  It sounds like you do not have Application Control enabled!

My guess is if you do have such rules enabled, you probably have others that overrule them (higher priority)... check on that.

If you have rules in place, and are sure there are no other rules enabled that are overriding your throttling and/or blocking rules, then no, there's nothing further you can do yourself to cause the application control feature to detect the traffic correctly.  You need to start an official Support Case with Sophos Support (you cannot start a case on this forum, it's not regularly monitored by Sophos Support staff).  You can do this via your Reseller, or directly with Sophos Support.

I first started out by making some Traffic Selectors and Bandwidth Pools for these services and they did not work out so well.  

I do have Application Control enabled, as I was able to straight up allow or black traffic to Netflix, however, due to academic freedom, I am not allowed to block it out entirely.  This is where I wish there was a more direct way to throttle it.

I have the exact same problem with schools.  One student Netflix session in HD totally nukes all the bandwidth for a school with a 100Meg link.   QOS is a chocolate teapot where Netflix is concerned.  

This issue is critical to resolve for the education sector globally.   

William is totally on this issue and has escalated it.  See
https://community.sophos.com/products/unified-threat-management/astaroorg/f/55/t/46555 

Top man.

There's one huge issue with QoSing Netflix, as opposed to blocking it.  Download QoS cannot regulate the speed upstream from the external server to the UTM, only from the UTM downstream to the user.  The streaming data will still be able to saturate your WAN connection, but the performance for the end user will be terrible, hopefully causing them to stop using it.  

That being said, you could talk with the schools ISP and see if they can QoS the downloads further upstream, which would save your WAN connection from the brunt of the traffic and/or talk with the "powers that be" at the school for permission to block Netflix, which would kill requests for the data.

Netflix isn't reliably able to be blocked right now due to a long running dns bug inside of the http proxy that causes mis calssification of the traffic.

https://community.sophos.com/products/unified-threat-management/astaroorg/f/55/t/46555

Scott, 

I can get FTP to control nicely in download using Download throttling.   

Is the difference with Netflix that the web proxy is acting as a buffering client for Netflix before QOS (download or upload) can kick in?  

Thanks in advance,

If all else fails, create an regular (upload) qos rule for Netflix, throttling it, BUT use the internal interface(s) of the UTM, as the source parameter, and the client network(s) you wish to throttle it for as the destination -- and place the rule on the internal interface(s) of the utm.  It's sort of an upload QoS rule in reverse... it will work, I've done it before (assuming application control is detecting Netflix traffic correctly -- I'm not aware that it isn't, but one poster here has said it isn't working right).  This is what I used to do all the time before we had download throttling.  Squeeze the pipe on the other side, the flow will slow on the internet side [:)]

Tried that Bruce.  Does not work I think because the proxy is acting as a client buffering full speed from the Tinterweb then trying to serve to the LAN throttled.  

My next throw of the dice is to disable IDS, Web and App proxies so it is basically just a router, and try what you suggested to see if that works.   

I don't know enough about this stuff, but presumably we cannot control a TCP stream by the window/ack mechanism can we?  That would mean having the QOS mechanism embedded in the TCP driver, wouldn't it?  Be awesome if we could because then we could throttle any TCP stream in the download direction on the external interface without losing a single packet or forcing a re-transmit.  

I was going to use the 1k subnet that Netflix's content servers are on in Europe to do my "application recognition".   Think that may work but trying to find a 1 hour slot to do the watching of another couple of episodes of Breaking Bad (while working this issue of course).

If all else fails, create an regular (upload) qos rule for Netflix, throttling it, BUT use the internal interface(s) of the UTM, as the source parameter, and the client network(s) you wish to throttle it for as the destination -- and place the rule on the internal interface(s) of the utm.  It's sort of an upload QoS rule in reverse... it will work, I've done it before (assuming application control is detecting Netflix traffic correctly -- I'm not aware that it isn't, but one poster here has said it isn't working right).  This is what I used to do all the time before we had download throttling.  Squeeze the pipe on the other side, the flow will slow on the internet side [:)]

if you depend on the classification(which this apparently does) as long as the proxy has this rdns/classification problem it isn't going to be reliably controllable.

Tried that Bruce.  Does not work I think because the proxy is acting as a client buffering full speed from the Tinterweb then trying to serve to the LAN throttled.  

My next throw of the dice is to disable IDS, Web and App proxies so it is basically just a router, and try what you suggested to see if that works.   

I don't know enough about this stuff, but presumably we cannot control a TCP stream by the window/ack mechanism can we?  That would mean having the QOS mechanism embedded in the TCP driver, wouldn't it?  Be awesome if we could because then we could throttle any TCP stream in the download direction on the external interface without losing a single packet or forcing a re-transmit.  

I was going to use the 1k subnet that Netflix's content servers are on in Europe to do my "application recognition".   Think that may work but trying to find a 1 hour slot to do the watching of another couple of episodes of Breaking Bad (while working this issue of course).

Then I suggest starting an official support case with Sophos.  You may be having the issue William speaks of.