youtube

cancel
Showing results for 
Search instead for 
Did you mean: 

youtube

L5 Sessionator

hi!

digging through the logs of our PA-2020 showed that at some point after Nov 3rd it was not able to recognize youtube as an application any more. since we upgraded from 4.0.7 to 4.1.0 a few days later, I was wondering if you have any idea what might be the cause of this behavior since all other applications seem to be recognized correctly? broken application signatures?

BR, Andrej

9 REPLIES 9

L4 Transporter

Hi Andrej,

What version of apps & threats are you running?  I'm on 278-1187 (running on 4.1.0) and I still seem to be getting hits for youtube-base

Regards,

Dave

hi!

I'd say we are running the latest available signatures

Application version 278-1187

Threat version 278-1187

Antivirus version 618-840

URL Filtering version 3745

BR, Andrej

I would assume if the application does not show up as youtube it is either detected as web-browsing or ssl. Are you blocking your users from access to youtube and now it is allow access since the application is not detected?

hi!

since PA-2050 is deployed in TAP mode, we are actually only monitoring internet traffic. you are indeed correct about application identification: in the URL filtering log access to www.youtube.com/watch?.... is always identified as web-browsing.

BR, Andrej

This should be expected behavior. the application in the url logs will be web-browsing. if you go to the traffic logs do you see youtube-base?

I just check on another device and you are correct it can be vary on the application for url filtering logs. i was testing on a lab unit but only saw web-browsing.

if you can log a case online we can have our content team look into this.

hi!

it turned out that changing the action from "block" to "alert" in the URL filtering profile completely changed the device's ability to detect Youtube. if the option "alert" is used both our PA-2020 and PA-2050 deployed in TAP mode are able to correctly identify Youtube traffic.

br, Andrej

@santonic:

the behavior that you describe is expected. Here's a synopsis of the two scenarios you describe:

URL action == block

1. three way handshake

2. first packet after the three-way handshake allows the device to identify application web-browsing

3. packet passed to URL filtering for decision

4. block decision causes session termination. no further identification work required. we will never identify as a child application of web-browsing

URL action == alert|allow

1. three way handshake

2. first packet after the three-way handshake allows the device to identify application web-browsing

3. packet passed to URL filtering for decision

4. alert|allow decision is made

5. packets are inspected to determine if application is a child app of web-browsing (such as you-tube)

Makes sense, thanx for the explanation.

Like what you see?

Show your appreciation!

Click Like if a post is helpful to you or if you just want to show your support.

Click Accept as Solution to acknowledge that the answer to your question has been provided.

The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!

These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the LIVEcommunity as a whole!

The LIVEcommunity thanks you for your participation!