PA and icap?

[migration]

Hello world,

is there a chance/way of talking icap between my squid and the PA?

Thanks a lot

Marcus

[dyang · Accepted solution]

amansour is correct - since we are not a proxy nor do we intend to be one, we will not support ICAP. 

[rapoint_person]

No, but can you solve whatever you want to do with PBF? Tell us more!

[amansour]

yeah I need to setup an ICAP server to SQUID as well,  did PBF do this for you? Could you send block pages from PA directly?

[amansour]

Any updates.  We have a number of customers that run 3rd party DLP and want to eliminate their proxy and ICAP, if we can do policy based forwarding or receive messages like ICAP we can send the pages from PA, which would truly make this a proxy replacement.

[jmahoney]

2 years later and this is still on my wishlist. Working with a solution like RSA DLP is impossible with a Palo Alto. It's a huge problem in helping customers build a comprehensive DLP strategy. The PA built in DLP doesn't do enough and the solution of "just block Dropbox and Gmail Send" isn't really an option for most customers.

[amansour]

@jmahoney I think this will never make the roadmap.  ICAP and WCCP are forwarding for proxies (HTTP/HTTPS/FTP) that's the problem.  PAN does all protocols all the time, they can't proxy, there not a proxy, the developers likely cannot make this happen.  I think network based DLP better get more protocols to stay relevant on the wire which is why ICAP is no good.

What I do is instead you should look at a re-generator TAP. Then tools which need to see all the traffic to do their job can have multiple copies (DLP is a great example, RSA Netwitness and other recorders like Niksun too).

Then everyone gets a copy and is happy.   With respect to blocking (the ICAP forward) the DLP integration would likely have to create a flexible response (Symantec DLP does this) where you could send something to the XML API, like you could with a proxy filter (Websense) or MTA and SPAM filter.  Each response is going to be specific to the type of block and in the PAN case I think that's an XML-API call.

Anyway my two cents.  Have the DLP bend the response because proxy is dead and they will be too if THEY don't adapt.

[amansour]

Oh yeah and for anyone wondering.  PBF doesn't do it.  It send routes out an egress, ICAP is different than routing in the DLP world because the DLP can mark up ICAP like it cal SPAM X-FORWARD messages.  PBF Doesn't allow this so unless your DLP tool (Websense has a few articles on this) can do that then you're out of luck.

[dyang · Accepted solution]

amansour is correct - since we are not a proxy nor do we intend to be one, we will not support ICAP. 

[mikand]

So how do you explain the SSL/SSH-proxy and DNS-proxy? :smileysilly:

[amansour]

@mikand, they should have probably labelled it forward instead of proxy.  SSL and SSH also misleading but proxy in our DLP case means re-write.  It terminates the session and re-establishes it which can work for protocols like http, https, ftp but not all applications. Those proxy features forward traffic they don't re-write it.  I think It's also why the GlobalProtect portal is only somewhere you can download the agent and not put links or content that is re-written to the internal segments like other SSL-VPNs.

Also Nice Pantopia score :smileywink: