log shows blocking but still able to access website

Robert,

That's very strange! If you see in the logs that request is blocked, then it should be blocked... Looking at your logs, you placed restrictions in the Default content filter. Maybe it is worth to try to create separate profile for your kids PC and place restrictions there? Also I would block Anonymizers category in the profile and if you wish to be more restrictive also forbid Uncategorized and Categorization failed.

You may also try to enable Application Control and block YouTube there.

Or if you are really mean, enable QoS and limit download speed for the YouTube traffic selector to a kind of unusable value like 8kbit or so :)

Personally I enabled quota for YouTube in the profile and this works fine for me. But the Block also works fire for me, just decided to give kids some time for doing stupid things :)

Hope this helps!

I thought about enabling quota but then have to do authentication.  I used to have UTM integrated into my AD and did automatic authentication but then it became a pain in the butt with non-windows devices.

To yours and Michael's suggestions that he's using an anonymizer, that's not impossible, but I've gotten onto his computer and looked at the URL and checked proxy settings and there's nothing to indicate that kind of behavior.  Plus, he's 9 years old...  I know I was a lot smarter when I was young, but I don't think I was THAT smart when I was THAT young!  :)

I have blocked streaming media already (as JDS mentioned) as well and that didn't seem to have an effect.  The PBR on my firewall which pushes the traffic over to the UTM does have a LOT of excluded IP addresses in it because I couldn't find a way to exclude all of Netflix using every technique I could find on the internet... it would always cut out or show some error when launching movies.  So, it's possible that the exclusions I put in at the network level could be playing a part in all this.

Interestingly, what I did find is this (not really a solution, but a Band-Aid and maybe a clue to a solution):

1) my policy does permit YouTube on the weekends via a schedule

2) Using Chrome on my sons computer, if I opened YouTube during that permit window I could keep accessing YouTube even after that window passed.  Even if I closed Chrome and re-opened it.  I don't think IE displayed this same behavior (though I don't remember if I specifically or thoroughly tested that).

3) Clearing the session table on the firewall had no effect.

4) Clearing the browser history/cache in Chrome outside the scheduled permission window caused YouTube to be blocked.

So, it seems like somehow Chrome could still access YouTube through it's cached files even though Sophos said that the traffic was blocked.  For now, I've uninstalled Chrome... nothing's preventing him from reinstalling it (or having my 16 YO re-install it for him since it's really his computer).

I've been doing networking for nearly 20 years, most of that time doing firewalls and many of those years doing filtering at the corporate level and I've never run across this type of behavior before.  I can't think of anything at a TCP level which would account for the traffic passing through the UTM, showing being blocked, but the session completing anyway except that UTM is just "monitoring" and not actually proxying the traffic for whatever reason.

I'd be curios if anyone else can recreate this behavior

When you said Chrome, it actually reminded me about fact that Google experiments with a kind of new protocol, in which communication to ports 80/443 is established with using UDP instead of TCP. This requires both Chrome browser and Google server to works. The protocol itself is called QUIC. So in case they started to experiment with this protocol on YouTube servers, and if you have all outgoing communication allowed in your firewall rules, this can explain this behavior as UDP 80/443 is not proxied.

If this is the case then please try to deny traffic to UDP 80/443 in your firewall rules and check if this helps.

regards,

Adam

When you said Chrome, it actually reminded me about fact that Google experiments with a kind of new protocol, in which communication to ports 80/443 is established with using UDP instead of TCP. This requires both Chrome browser and Google server to works. The protocol itself is called QUIC. So in case they started to experiment with this protocol on YouTube servers, and if you have all outgoing communication allowed in your firewall rules, this can explain this behavior as UDP 80/443 is not proxied.

If this is the case then please try to deny traffic to UDP 80/443 in your firewall rules and check if this helps.

regards,

Adam