We have run into an issue in our deployment where SOME (really only a few) Youtube videos don't play, the user gets an error 'An error occurred, please try again later'. In the traffic logs, I see traffic that is recognized as application 'http-audio'. We have configured an application whitelist of the applications we allow from our network, and have chosen to exclude 'http-audio' due to its risky nature. When I add this application to the whitelist, the video plays without fail.
Here's where it gets weird, since I'm averse to allowing http-audio and being done with it, I decided to go deeper. Turns out that if I refresh the link via the browsers refresh button (or F5) enough times (sometimes only once, sometimes it takes 5-6 times), the video will eventually play, without allowing the http-audio application.
The link I'm currently working with is http://www.youtube.com/watch?v=t7wmPWTnDbE but I've heard that there are other youtube links that behave similarly.
I wonder if anyone has experienced this or may have suggestions for an elegant solution that doesn't include allowing http-audio, or mashing the refresh button until it works.
Took a look at that, not the case. The link above fails on all workstations, they all use flash, and refreshing a couple times always gets it to work. Majority of other links always work, in fact I have yet to definitively identify another link that behaves/fails similarly - but I do recall over the past few weeks getting this error on occasion, and believe it may be related.
When it does fail, traffic logs on the PA show sessions denied due to application http-audio not being allowed. So I wonder if the application ID engine may somehow be misinterpreting what it's seeing and misidentifying the application somehow? Thanks for giving it some thought, much appreciated
Sounds like a case where you should contact the appid team and submit this as a request: http://researchcenter.paloaltonetworks.com/tools/
They will most likely want some pcaps of these failing sessions aswell.
Or if you have a supportcontract you wish to try out take it that path instead :-)
By the way, have you tried taking some pcaps of these clients when this problem surfaces? I mean if there is something obvious going on in there by just looking at the traffic (that is that it actually is http-audio which youtube sometimes tries to send to these clients)?
Click Accept as Solution to acknowledge that the answer to your question has been provided.
The Live Community thanks you for your participation!