Blocking Streaming Media

Are you employing deep inspection in the webfilter profile (in 5.0) and/or in the SSL/SSH inspection profile (5.0 and 5.2), or are you scanning unencrypted traffic only?

Unless users were somehow able to establish an SSL connection to YouTube before the FortiGate was configured to scan for them...

In that case, we can't perform inspection on a truncated SSL exchange, only when it is a new session.

Could you test with a new client with an empty browser cache, just to provide a baseline example?

Assigning youtube or any google related site in the urlfilter to be blocked won't work correctly under HTTPS because they use a wildcard SSL cert. So if you're using SSL certificate inspection all we do is look at the name on the cert returned and block based off that, in this case it would read *.google.com or something along those lines and never match youtube.com.

In this case, it's based on FortiGuard categories, not a urlfilter, from the screenshot attached earlier, and it looks like deep-inspection is being performed.

I just blocked the Bandwidth Consuming category on my default WF profile on a FG60C running 5.2.2, added the deep-inspection SSL/SSH Inspection Profile to the policy along with the WF profile, and had YouTube summarily blocked in IE, Firefox, and Chrome, despite being signed into Google's ecosystem in Chrome already. That being said, in Chrome, I navigated directly to www.youtube.com. If you use the app launcher (desktop or browser-based), the request may be handled differently.

I'm not saying you're wrong: very specifically, I'm saying I can't duplicate your results. I tested in 5.2, which is one difference.

Short of opening a ticket with TAC (which you can always do), I would be interested to see the flow trace and debug output from the urlfilter daemon: diag debug reset diag debug enable diag debug flow show console enable diag debug flow show function-name enable diag debug flow filter addr w.x.y.z //--input the private IP of your testing host here diag debug flow filter port 80

diag debug flow filter port 443 diag debug flow trace start 5000 <attempt to access YouTube, then...> diag debug flow trace stop

diag debug flow filter clear

diag debug reset

diag debug disable The general order should be: 1. Receive a packet 2. Allocate a new session

3. Find a route via a gateway interface and next-hop IP

4. Allow the session by a certain policy

At step #4, the output should show you whether the policy is using proxy- or flow-based UTM profiles, and if it performs SNAT or DNAT. For instance, 'allowed by policy x:SNAT' would indicate NATting, but no UTM. By comparison, 'allowed by policy x:AV SNAT' would indicate proxy-based scanning AND source NAT; if you say '...IPS SNAT', the policy most likely uses flow-based profiles. AV and IPS are short hand for proxy and flow-based, under most circumstances.

Once we verify it's hitting the policy and should be subject to the right kind of scanning, we can move on to the urlfilter daemon, to see if it's even invoked to try and determine the category of the URL being requested: diag debug reset diag debug enable

diag debug urlfilter src-addr4 w.x.y.z //--your private testing host's IP

diag debug app urlfilter -1 <attempt access to YouTube, then...>

diag debug reset

diag debug disable

That would be a good, methodical start towards resolution, or will at least generate the kind of diagnostics TAC will need to examine the issue in more detail.