Thaigo, In fact, that's what I tried at first. My very first attempt I had four rules, in the following order: Allow: Source: (My PC); Destination: (Any); App-ID: (facebook, twitter); URL-category: (Any) Deny: Source: (Any); Destination: (Any); App-ID: (facebook, twitter); URL-category: (Any) All Web-browsing: Source: (Any); Destination: (Any); App-ID: (web-browsing, SSL); URL-category: (Any) Profile: (URL Filter profile blocking "Social networking" category) Deny all: Source: (Any); Destination: (Any); App-ID (Any); URL-category: (Any) The problem is that before Facebook or Twitter (or many other applications) can be identified, they start out as basic "SSL" (for Facebook, "web-browsing" for Twitter) and as additional traffic is received, the Palo Alto gets enough traffic to identify the application traffic as Facebook or Twitter or whatever. So, the inital traffic (i.e. the first packet of the TCP connection) is classified with a "SSL" App-ID and hits rule #3, which has the URL filtering blocking social networking. Rule #3 will then block the inital Facebook/Twitter traffic, killing the connection before any further traffic is identified as Facebook/Twitter--Rules #2 and Rule #3 are never used. My original issue was that the Facebook and Twitter App-IDs needed "web-browsing" and "ssl" App-IDs to work, but adding those two dependent App-IDs would have allowed too much access for the selected Facebook and Twitter users. But adding the basic URL filter profile to restrict access would have stopped the Facebook and Twitter App-IDs from working. A little bit of a Catch-22 right there. The custom URL category allows me to have a second "web-browsing" and "ssl" rule that only applies to the specific users I am allowing access to Facebook and Twitter. Everyone else would hit the main "web-browsing" rule near the bottom of the policy list.
... View more