If I remember correctly the PA will do a precheck on the packet before it start to crunch it through the "singlepass" engine. This precheck (described in a pdf/picture on this site) will check for the ip-header stuff like srcip, dstip, srcport, dstport. Which gives if you for example only have one rule setup and thats something like "appid:web-browsing, service:TCP80" then if the packet arriving has a dstport of something other than TCP80 then this packet will be dropped (and logged if you have a rule in the end which will log dropped packets, the builtin hidden last rule is just a drop without logging). Thats why you should avoid to use "service:any" and always use at least "application-default" or even better define exactly which ports you allow. The next step (when this "singlepass" kicks in) is to try to detect what kind of application this packet actually is, send it through a protocol-decoder and if thats successful it will do other tests aswell on the packet before finally (hopefully) give a final verdict of letting this packet pass through (or drop the session completely). This gives that if your rule instead was "service:any" the precheck would always fail (given the combo of srcip + dstip is valid aswell) and the PA must let through enough of packets before the particular application can be identified. Some applications can be identified on the first packet (after the tcp handshake if we talk about tcp applications) while others need a few more packets before the verdict can definately say "this packet is not the allowed appid". You can see this yourself in action if you setup a rule like "appid:web-browsing, service:any" and put a webserver to listen at lets say TCP81. Your tcp-handshake will complete (since its obviously part of web-browsing) and you will also be able to send a packet through towards the webserver - lets say a packet such as: a b c that is three letters with whitespace in between. As you can see "a" is not a valid http method - but PA obviously doesnt know this (yet)... not until the server responds with "HTTP ERROR 400/Bad Request" it seems that PA is 100% sure that this flow has nothing to do with web-browsing and will now drop the flow (and log it if you have such rule in the end). I have no idea why PA will let through such requests (or if this particular case has been taken care of by an appid update) but a workaround is to create a custom appid which is based on web-browsing but with the addition of "http-method" (or whatever its called when you create custom appids) needs to be GET, HEAD or POST (or whatever http methods you like to let through). Now, with the custom appid, even the request would be dropped. There are also other corner cases such as if you wish to block skype. In order to block skype you must first allow skype-probe. Which gives that the more you go into "applications" the more leakage will occur. Personally I recommend to first configure your PA device as you would with an older SPI based device - look at srczone, dstzone, srcip, dstip and service. THEN add which application is supposed to get detected by this flow. And in some cases also add a url-filter (if dealing with browsing). And of course the rest of a proper IPS profile, AV, SSL-termination (to inspect https sessions) etc. Edit: Here is the document I had in mind: There is also an "executive summary" edition of the flows described on page 4 (anyone else remembers what that document is called? its like light green boxes describing the same flow but with less technical details). Edit2: Here is that "executive summary" (well sort of) I had in mind: http://media.paloaltonetworks.com/documents/techbrief-app-id.pdf
... View more