- Access exclusive content
- Connect with peers
- Share your expertise
- Find support resources
05-02-2019 08:13 AM
Hi folks,
I am trying to understand what references mean when mentioning Palo Alto firewall as a web proxy or any reference to it that way.
I mean, from what I gather, the PA does not cache web requests like a web proxy product would, or rewrite URLs, or have other traditional web proxy type features. Unless I am wrong?
Could it be that the term Web Proxy is often misused in certain descriptions or reference when discussing PA devices?
I was looking at this comparison paper, but seems to highlight what Web Proxies don't do in regards to App-ID, which I understand.
https://www.paloaltonetworks.com/resources/techbriefs/palo-alto-networks-vs-proxy-based-products
Thanks,
OMatlock
05-02-2019 11:02 PM
Most of the documents compare pan to a proxy, yes it does proxy, ssl forward etc but it does not cache or rewrite like a proxy.
so PAN is a next gen firewall, a proxy is a proxy.
for me the proxy has been replace by the PAN for outgoing traffic for the reasons mentioned by @jeremy.larsen .
Not as much requiremenr for cache as mega gig pipes now replace our old isdn etc...
you cannot check your bus timetabel these days without https and this cannot be cached in proxy world,
plus the additional complication and demands of todays content seems to be ever forcing us closer to a proxy rule of......
if url=*.* then go direct (vial PAN)
having said that, our incoming web requests do not touch the PAN, it traverses a non NGFW and is then reverse proxied to our internal web servers. we are in control of code and content and with ssl terminated on the proxy we can cache to reduce overheads on our web servers.
so.... if you need to proxy, dont use a PAN, it is not a proxy.
05-02-2019 08:25 AM
What specific features are you looking for? PAN is a "transparent" web proxy. There is no need to point to a proxy in your environment. Personally, I prefer this method as it is much easier to implement without a bunch of special use case exceptions where a traditional proxy doesn't work/isn't supported/causes problems/etc.
05-02-2019 01:16 PM - edited 05-02-2019 01:25 PM
Thank you for responding!
I am not really looking for anything in particular, just trying to understand when I read and see reference to using PA device as a web proxy. When I think of a web proxy device, I think of web caching or web proxy device capturing the request and resending on user's behalf, and or other features that are specific to web proxy.
In other words, I've believed there is a clear separate distiction between these two types of products.
When you say the PA is a transparent proxy, that is just meant to say that web traffic flows through it as an intermediatary device (as a firewall for app-id scanning, etc, using NAT)? Therefore, when web proxy is used to in reference to PA device, I should understand within that context only (specifically)? Am I correct in this thinking?
Just trying to confirm as I get these kinds of questions when evaluating what are necessary in environments...
05-02-2019 01:43 PM
I guess that's kind of hard to answer because I don't know what features you are looking for. I couldn't tell you on the top of my head whether or not PA caches requests (I would assume so). Is there a specific feature or use case you are looking for. Perhaps I am just misunderstanding your question. Whether you explicitly forward traffic to a proxy on a predefined port or if it just runs transparently inline shouldn't make that big of a difference. I guess this boils down to your derfinition of "on your behalf".
05-02-2019 11:02 PM
Most of the documents compare pan to a proxy, yes it does proxy, ssl forward etc but it does not cache or rewrite like a proxy.
so PAN is a next gen firewall, a proxy is a proxy.
for me the proxy has been replace by the PAN for outgoing traffic for the reasons mentioned by @jeremy.larsen .
Not as much requiremenr for cache as mega gig pipes now replace our old isdn etc...
you cannot check your bus timetabel these days without https and this cannot be cached in proxy world,
plus the additional complication and demands of todays content seems to be ever forcing us closer to a proxy rule of......
if url=*.* then go direct (vial PAN)
having said that, our incoming web requests do not touch the PAN, it traverses a non NGFW and is then reverse proxied to our internal web servers. we are in control of code and content and with ssl terminated on the proxy we can cache to reduce overheads on our web servers.
so.... if you need to proxy, dont use a PAN, it is not a proxy.
05-03-2019 11:44 AM - edited 05-09-2019 12:01 PM
Ah! Incoming connections is your use case (I was only describing a client internet bound use case). Yes, in that case, PAN might be inline but then you should be using comething like F5/Netscaler/etc for reverse proxy traffic flow and load balancing. I don't usually refer to those services as a "web proxy".
05-09-2019 11:43 AM
Thank you guys for the feedback.
It's mainly my inexperience with both and learning that is driving these questions.
Very helpful.
05-10-2023 12:49 PM
@Mick_Ball solution "PAN is not a proxy" seems technically incorrect considering PAN-OS has very specific settings to configure itself as a proxy. He did not answer the question, rather he just offered an opinion to use a different product. Recommend this "solution" comment for removal.
05-12-2023 03:37 AM - edited 05-12-2023 03:38 AM
Hi @Jonathan_Runyan ,
The reply reflects the PAN-OS versions and the features that were available at the time of writing (early 2019).
It wasn't until PAN-OS 11.0 that web proxy capabilities were introduced.
For anyone interested to use the web proxy capabilities I recommend checking out the following: Configure a web proxy
Kind regards,
-Kim.
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!