PAN as proxy destination?

Showing results for 
Show  only  | Search instead for 
Did you mean: 

PAN as proxy destination?

L0 Member

Does anyone know if I can configure a web browser to use the PAN device as the proxy?  We used to have an ISA as that proxy but after installing the PAN's (two 500's in HA) the ISA waqs moved to a DMZ and only helps with incoming connections to things like webmail and sharepoint.


L0 Member

PAN devices ARE NOT Web Proxies and can't be used for that (is something belonging to "What PAN firewall is NOT": is not a Proxy, is not a WAF, is not an UTM) 🙂


Any roadmap to add this feature? It is good selling point if End user want to replace their Proxy server originally use as URL filtering device.

Check Point FW can act as Web proxy server in R75.40. check_point_web_proxy.png

L3 Networker

Hi using proxies with PAN only masquerades information flows assing through the PAN. We've replaced our websence system (proxy) and are routing directy to the internet through the PAN. This allows us to see and more importantly control all data flows.


I agree...

If you still need a forward-proxy (can be handy for cases where you dont want to have public ip's flowing around in your core and by that be able to setup IDS to sound an alarm if such packet submerges anyway) you should use a device dedicated for this work.

Examples (depending on your needs, demands (assurance and stuff) and walletsize etc):

Most of the forward-proxies can be setup with keep-source meaning that you can still use user/panagent in your PA device (along with url-categories, av, ssl termination etc) if you setup like:

client <-> forward-proxy <-> PA <-> Internet

Any hint on how keep-source would have to be implemented in squid ?

Other possibilities:

  • client -- PA -- proxy -- internet
    But that would require tight security on the proxy...
  • PBF to redirect http to proxy (still have to try that sometime)

Im trying to dig into which setting will provide this in squid (if any).

I know for sure that Farist proxyfw can do this but I dunno about squid.

On the other hand the squid can add X-Forwarded-For header which PA can pickup in its logs. However the userid doesnt seem to be compatible with this according to:

Yes, use external of proxy server with PAN is not a good design (at least user-id not working).

However in this discussion, let focus on another feature - PAN work as proxy server.

Check Point is quite smart to add HTTP/HTTPS proxy into the FW. As the FW can log/control by the Client IP/User and URL itself but not only by the X-Forward-For header provided by external proxy.

Any timeline PAN will add this feature in the future?

I’m seeing this style of network layout all over the show. Customers of course have various reasons for using proxies. LAN PC’s/Laptop’s all talk to a proxy for internet access (in most cases it’s ISA). Most of them don’t need the proxy for caching and can do without the caching benefit. It’s the proxy function they’re after.

This becomes a bit of a mission to implement Palo in these cases. There are interesting workarounds like using X-FORWARD-FOR in the HTTP header. But as far as I can tell it doesn’t work with HTTPS. So this means a lot of the great features of Palo become an issue to get working 100% like User-ID.

I agree with linusso, a very basic proxy function implemented on the Palo’s would instantly solve all the issues in environments where a proxy and firewalling/user-id is needed.

Does anybody know if this is on the cards?

Most of them don’t need the proxy for caching and can do without the caching benefit.

I don't agree. I think the main advantage of a http proxy IS caching. It helps conserve (expensive) bandwidth, makes websites "faster" to users ...

In our highly developed contry in the center of Europe (Belgium) bandwidth is extremely pricey (in comparison to our neighbors). For now it's still doable without caching, but with every new bandwidth consuming web application it gets more difficult (or more expensive or slower, whatever you prefer). Cloud computing is in our situation out of the question, just because the cost of required bandwidth would overshadow.

That said: basic caching in PA would be a plus, but we knew it was missing when we bought it...

It really depends on the deployments in my opinion. Caching isn't always the main reason. For example if you want to push web traffic to a different "gateway" for breakout than the computer's actual default route.

Dont confuse a webcache with a webproxy 😉

Im not that sure that PA can act too much of a proxy due to how the hardware is layouted.

Im guessing that its possible but it would involve mgmtplane and that would be bad for other reasons (specially would bring a performance impact).

The reason for why Checkpoint can do this is because Checkpoint is a software solution and the performance goes downhill for every feature you enable (thats why Checkpoints datasheets shows performance figures with EVERYTHING DISABLED - compared to PA who have everything enabled).

To get an idea of what a simple HTTP proxy must be able to handle here is an example on how to do this with iRules (TCL) on a F5 loadbalancer:

# web proxy example
# This is a simple, incomplete example web proxy iRule.
# It only supports limited proxy functionality of converting the requested host 
#    (from an absolute URI or the Host header) to an IP address and sending the request on.  
# It doesn't support CONNECT/HTTPS or most other RFC2616 requirements for a web proxy.
    log local0. "[IP::client_addr]:[TCP::client_port]: New HTTP [HTTP::method] request to [HTTP::host], [HTTP::uri]"
    # Check if the URI is absolute and http://
    if {[string tolower [HTTP::uri]] starts_with "http://"}{
       # Parse the host value from the URI
       set host [URI::host [HTTP::uri]]
       log local0. "[IP::client_addr]:[TCP::client_port]: Parsed $host from URI [HTTP::uri]"
    } else {
       set host [HTTP::host]
    # Check if host header has a port
    if {$host contains ":"}{
       # Scan the host header to parse the host and port
       if {[scan $host {%[^:]:%s} host port] == 2}{
          log local0. "[IP::client_addr]:[TCP::client_port]: Parsed \$host:\$port: $host:$port"
       } else {
          # Host value was host: without a port. Use the requested port.
          set port [TCP::local_port]
    } else {
       # Host header didn't have a port. Use the requested port.
       set port [TCP::local_port]
    # Check if the host header isn't an IP address (ie, it contains an alpha character)
    if {[string match {*[a-zA-Z]*} $host]}{
       log local0. "[IP::client_addr]:[TCP::client_port]: Host value not an IP: $host"
       # Perform a DNS lookup of the hostname
       NAME::lookup $host
       # Hold the request until name resolution completes
    } elseif {[catch {IP::addr $host mask}]==0}{
       log local0. "[IP::client_addr]:[TCP::client_port]: Host is an IP: [HTTP::host]"
       # Request was to a valid IP address, so use that as the destination
       node $host $port
    } else {
       # Couldn't parse host header.  Could use the destination IP address as the destination?
       HTTP::respond 400 content "Invalid Host header"
       log local0. "[IP::client_addr]:[TCP::client_port]: Invalid host header: [HTTP::host]"
    set response [NAME::response]
    log local0. "[IP::client_addr]:[TCP::client_port]: Resolution response: $response (elements: [llength $response])"
    # Check if there is a resolution answer and it's an IP address
    switch [llength $response] {
       0 {
          # No response, or response wasn't an IP address
          log local0. "[IP::client_addr]:[TCP::client_port]: Non-existent/invalid response: $response"
      HTTP::respond 500 content "Couldn't process request"
       default {
          # Response was one or more list entries.  Use the first list element.  Check if it's an IP address.
          if {[catch "IP::addr [lindex $response 0] mask"]==0}{
             # Request was to a valid IP address, so use that as the destination
             if {$port != "" and [string is integer $port]}{
                log local0. "[IP::client_addr]:[TCP::client_port]: Using destination with parsed port [lindex $response 0]:$port"
                node [lindex $response 0] $port
             } else {
                log local0. "[IP::client_addr]:[TCP::client_port]: Using destination with default port $response:[TCP::local_port]"
                node [lindex $response 0] $::default_port
          } else {
             # No response, or response wasn't an IP address
             log local0. "[IP::client_addr]:[TCP::client_port]: Non-existent/invalid response: $response"
         HTTP::respond 500 content "Couldn't process request"
    # Release the request

It has been 5 years since this discussion and I was wondering if there had been any changes that may effect what was available then: i.e. can the Palo Alto be a proxy target now.  

To prevent the flood of responses telling me that I need a proxy that caches let me paint the picture. I would like to use the Palo Alto as a backup Internet Access point for the WAN. I do not want  to reconfigure all the routers on the WAN to point o the Palo Alto if the primary Internet Access point goes down but I could easily change a proxy.pac script to point them to an alternate access point being the firewall. I would rather not use a cacheing proxy server (eg Squid) as it seems to interfere with SSL decrypt and I still want this protection. (unless someone can tell me how to overcome the squid proxy preventing SSL decrypt on the Palo Alto).

  • 12 replies
  • 101 Subscriptions
Like what you see?

Show your appreciation!

Click Like if a post is helpful to you or if you just want to show your support.

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!