- Access exclusive content
- Connect with peers
- Share your expertise
- Find support resources
08-29-2011 02:23 AM
Hi all,
I tested this strange (imho) behaviour with PAN 2020 4.0.3:
1. create a first security policy with ssl, http-proxy, dns but without web-browsing application (as you can see in 1.jpg) with action ALLOW
2. create a following security policy with facebook application and action DENY
3. create a final security policy for all other outbound traffic, with action ALLOW ALL for all applications but with a Custom URL Profile that blocks facebook (as you can see in 2.jpg) - all other Sec. Profiles are in alert mode.
(and obviously commit the configuration )
when I try to go to www.facebook.com from my client (the source address of the rules) I get blocked by URL Profile (4th rule) and not by application signature present in the 2nd rule - first match is not respected
If I add web-browsing application in the 1st rule (point 1) and retry to go to www.facebook.com, this time I get blocked by application signature present in 2nd rule - this time first match is respected
If I delete the URL Profile from rule 4 and I delete web-browsing application from 1st rule, I get blocked correctly by the 2nd rule
Why this behaviour?
Thanks in advance
08-29-2011 08:29 PM
Hi Iceman,
It is expected.
In order to understand your observation, you need to understand our app-id design and app dependency.
Although we have app-id for facebook, but during the life of a facebook session, the initial packet of facebook is actually first recognized as web-browsing before we identify it as facebook. If you are running the facebook app through an explicit proxy, the traffic will be first identified as web-browsing, then http proxy followed by facebook.
So in order to allow facebook, you need to allow web-browsing, http proxy and facebook- and this is called app dependency.
For case1, web-browsing is blocked by your URL filtering so facebook cannot work.
For case2, web-browsing and http proxy are allowed but facebook itself is not and that's why facebook cannot work.
For case3, if you deleted the URL filtering, web-browsing will be allowed by the last policy, http proxy will be allowed by 1st policy, but finally facebook will be blocked by 2nd policy.
08-29-2011 08:29 PM
Hi Iceman,
It is expected.
In order to understand your observation, you need to understand our app-id design and app dependency.
Although we have app-id for facebook, but during the life of a facebook session, the initial packet of facebook is actually first recognized as web-browsing before we identify it as facebook. If you are running the facebook app through an explicit proxy, the traffic will be first identified as web-browsing, then http proxy followed by facebook.
So in order to allow facebook, you need to allow web-browsing, http proxy and facebook- and this is called app dependency.
For case1, web-browsing is blocked by your URL filtering so facebook cannot work.
For case2, web-browsing and http proxy are allowed but facebook itself is not and that's why facebook cannot work.
For case3, if you deleted the URL filtering, web-browsing will be allowed by the last policy, http proxy will be allowed by 1st policy, but finally facebook will be blocked by 2nd policy.
08-30-2011 01:33 AM
Thank you.
App dependency is always challanging!
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!