I agree that this needs to be fixed. If I allow clearspace then I have nothing against if the PAN will do some magic behind the scenes to make this work but at the same time it should never allow other applications as you described. In the particular case I can agree to that http-proxy needs to be allowed at first (in order to detect clearspace) but once clearspace is detected (or not detected) then http-proxy should no longer be allowed through the PAN for this particular flow. The question here is perhaps how many packets is needed for the detection to work? Doing tests for how the appid works (deny unknown, allow any appid (with full idp, antivirus and antispyware inspection incl ssl-termination) showed that the request will be allowed through the PAN (because at this point it doesnt know what app this might be and because I simply allow all applications in this test) but the response from the server is blocked (because now PAN figured out that the application in use was web-browsing BUT the request itself wasnt web-browsing so the endresult was unknown which was denied). In this particular test I sent a "a b c" as request to a webserver (located behind the PAN) and could verify that the packet with just "a b c" (instead of "GET / HTTP/1.0" or whatever) passed through - but the (I think it was) "HTTP 400 Bad Request" sent as response from the webserver was not allowed and the session was destroyed (as it should). So is there some manual workaround one can use to fix this problem unless PAN cannot fix this? At first I thought that something like this could work (before my brain started to function ) 1) Allow appid: clearspace, http-proxy 2) Deny appid: http-proxy but once my brain booted up (a few microseconds later ) I realized that this will never work becuase PAN uses top-down first-match so rule no1 will always be used before rule no2 (a flow identified as http-proxy will never hit rule no2).
... View more