I think this topic has been discussed in the past, but I want to be clear about this deployment
since web proxy server design is still typical in many customer's live network. So please allow me to bring this again.
2 basic deployments are mentioned in the past. These deployments are:
(1) Place PAN between users and a proxy server. It would be like, for example:
[Clients] -- [PAN] -- [Proxy] -- [Internet]
(One of the recommended designs is placing a proxy server in a separate interface of PAN as a typical DMZ design.)
But, let's assume the above simple design. PA could be either L3 or vwire mode.
(2) Place PAN between a proxy server and internet. It would be like, for example:
[Client] -- [Proxy] -- [PAN] -- [Internet]
Now, my questions are:
<< In case of (1) scenario >>
With this design, source web traffic comes from actual client and goes through PAN, so PAN can identify source user-id.
What about destination IP and app-id? Clients' web browser are actually pointing to the proxy server and the session to an external web server in Internet is
initiated from this web proxy server. Does that mean all destination IPs will be the IP address of this proxy server?
What about app-id to be identified? Will it be "web-proxy" for all traffic from clients?
<< In case of (2) scenario >>
From the past posts, the nature of this design can cause a problem, because all web access are coming from the web proxy server.
That means PAN can't identify original source IP addresses of clients.
The solution is enable "X-Forwarded-For" option in both web proxy server and PAN.
With "X-Forwarded-For" solution, PAN can identify original source IP address from clients since the original source IP is included in HTTP header.
My question is what about user-id? Can PAN map user-id based on this "X-Forwarded-For" feature, so that you can identify both original source IP and user-id?
Any comment is appreciated.
Thanks in advance,
1) Depends on how you setup your webproxy - if its transparent or non-transparent.
When transparent your PAN will use dstip of the server on the Internet and just route its traffic to the proxy as nexthop.
Also the request in transparent mode will be "GET / HTTP/1.0" or such.
In this case the client does the DNS-resolution aswell to find out which dstip the packets should use.
When non-transparent the proxy waits for a CONNECT statement similar to "CONNECT http://www.example.com/ HTTP/1.0" and then its the proxy who will do the DNS-resolution.
2) I have a slight memory that the PA-device at least could handle those "X-Forwarded-For" in its logs - but I dunno if it will map those ip's with userid.
When you use this setup its a good thing to make sure your proxy will use "keepsource=yes", this way it doesnt matter if the webproxy is transparent or non-transparent towards the clients - it will be transparent towards the PA-device (since srcip will be kept when using keepsource=yes).
Personally I prefer the second design because the PA will then protect the proxy itself from the internet.
This way you can use this design:
*) Client use proxysetting to use non-transparent proxy. This also brings us that in your internal network you will only see RFC1918 addresses (if you use them). This gives that if a non RFC1918 ip is seen it probably means that the client sending the packets have got a trojan/malware onboard (a trojan/malware that didnt pickup the proxy settings and instead tries to spread or monitor on its own).
*) Proxy is setup to non-transparent mode (meaning incomming data has "CONNECT http://www.example.com/ HTTP/1.0" and its the proxy who does the DNS-resolution) along with keepsource=yes so next hop will see the clientip directly in the ip-header.
*) PA-device uses userid and can map which user uses which ip either by using PAN-agent or by other userid methods. The PA-device will do the SNAT aswell. This also gives that you can utilize stuff like geoip based rules in your PA if you wish.
*) On a DMZ to the PA-device you have your DNS resolvers which the proxy uses to query.
First of all, thanks for your comment.
Actually, in this particular situation in one of my customers, I am looking for the solution with (1).
Also, more detailed physical connection is below:
[Clients] --- [PAN(vwmode)] --- [Proxy] --- [FW(NonePAN)] --- (Internet)
As you can guess, PAN is not placed yet. That is why there is an existing FW (Not PA), and PAN will be placed between clients and the proxy server
using virtual-wire mode.
In addition, the proxy is none-transparent. The idea is not replacing the existing firewall. Instead placing PAN in the above deisgn
and control user web access using user-id and app-id as well as web filtering in PAN.
(The proxy is working as just cache server, and web filtering is not enabled on this server.)
In this scenario, can PAN recognize destination-ip from a client as (A) the destination server on internet, or just (B) the ip of proxy server?
My guess is (B), since web browser of client is explicitly configured the ip address of this proxy server...
Do you really need to use a proxy at all?
Just allow your clients direct access to the internet via the PA - simple. I assume everything will be PAT'd out via your firewall?
This allows you to use the full features of the PA web monitoring function..
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 Live Community as a whole!
The Live Community thanks you for your participation!