School Guardian and Quicktime

One of our schools is having a strange issue with a the Quicktime movie embedded on the following URL:

A Day At The Great Exhibition - Victoria and Albert Museum

The plugin loads, does a countdown for buffering and then says '401 Not authorised'. I've added the vam.ac.uk domain to the list of domains not requiring authentication, and there's no longer any signs of denied requests in the filter log, yet it still won't play.

If I bypass School Guardian completely, and go straight through the upstream proxy everything works.

Any suggestions...?

Sounds like a squid problem. I would contact Smoothwall, I would image they would have a "patch"

First question.. is AV enabled?
Second.. what do the filter logs say?

Quote:

---

Originally Posted by tom_newton

First question.. is AV enabled?

---

AV is not currently enabled for the filter (it is for SmoothZap, though that shouldn't affect things).

Quote:

---

Originally Posted by tom_newton

Second.. what do the filter logs say?

---

This is for the page itself:

Code:

---

8:49:34 172.16.4.66 - http://www.vam.ac.uk/collections/british_galls/video... 0 200 
*EXCEPTION* Exception site match
Custom domains 2 - Custom allowed content

---

And this for the Quicktime movie:

Code:

---

8:49:44 172.16.4.66 - http://www.vam.ac.uk/files/video/10845_broadband.mov... 0 200 
*EXCEPTION* Exception site match
Custom domains 2 - Custom allowed content

---

It looks like it's picking up on the vam.ac.uk domain being in the custom allow list, and the not-requiring-authentication settings, but something else still appears to block it. :|

There are no 'denied' entries in the filter log for either the machine IP or the logged-on user - for any addresses at all around the time this was tested.

Stephen

Stephen,

looks like i missed your reply here - much apologies :getmecoat: :)

The issue is that this is really an rtsp stream:
rtsp://rn.groovygecko.net/groovy/vam/britgalls_video/great_exhibition_high.mov

You're not actually going through the filter at all here - as we don't proxy RTSP (yet). So you may need to open up some ports on the firewall.
https://support.smoothwall.net/index...id=221&nav=0,4

HTH,

Tom

After further investigation, it appears that something odd is happening with either Quicktime or the stream at the other end.

Doing a netstat on a machine when trying to play the Quicktime stream showed a connection open to 77.67.2.202 on port 554. The stream still failed to play, so I added the IP to the list of sites that don't need authentication, and it's now playing.

It's almost as if it tries RTSP, but the other end doesn't like it, and reverts back to HTTP (but on port 554) and therefore runs foul of not being authenticated.

So long as the IP stays the same I should be fine. If not, then I might have to abandon the effort.

Cheers for the help though :)

Stephen

Steve,

That's really quite odd! I imagine it might be a block of IPs as it looks like they are using an external CDN. Is realplayer set up to use the proxy? I don't seem to remember having to do that myself though. Are you using transparent proxying?

Tom

Quote:

---

Originally Posted by tom_newton

Steve,

That's really quite odd! I imagine it might be a block of IPs as it looks like they are using an external CDN. Is realplayer set up to use the proxy?

---

It's Quicktime actually, and it's not set to use a proxy - I'm not sure if it picks up the Internet Explorer settings automatically though, in which case it might be.

The odd thing is that if I don't use the School Guardian (aside from it being the gateway) and go through the RM SEGfL proxy instead it all works without any issues!

Quote:

---

Originally Posted by tom_newton

I don't seem to remember having to do that myself though. Are you using transparent proxying?

---

Nope, just pointing the machines at the SG box via group policy. Still, I think it's kept the same IP address for the past few days, and the video is only needed for one lesson - I may just leave it at that :p

Stephen

I wonder if port 544 is being blocked upstream. That might explain it.
Hard to workout to do with applications that don't support NTLM but connect to many external services. Exclude by user-agent seems like opening a big loophole :(

Anyone any ideas?

Quote:

---

Originally Posted by tom_newton

I wonder if port 544 is being blocked upstream. That might explain it.
Hard to workout to do with applications that don't support NTLM but connect to many external services. Exclude by user-agent seems like opening a big loophole :(

Anyone any ideas?

---

Will ident do? I was hoping it doesn't matter what app it is as it's just checking to see who's logged in.

Quote:

---

Originally Posted by DMcCoy

Will ident do? I was hoping it doesn't matter what app it is as it's just checking to see who's logged in.

---

Well we support ident.. but:
a) its easier to spoof than it should be
b) it doesnt check passwords
c) requires installation
d) means you need 1:1 user:IP mapping (ie no terminal server etc.)