What is the difference between Transparent and Explicit proxies
Article ID: 175723
Updated On:
Products
Issue/Introduction
You are planning to deploy a proxy in your network and read about different ways to achieve certain configurations. You frequently see references to Explicit or Transparent proxies. You begin to wonder about the benefits / behavior of each deployment.
Resolution
At its core, the difference between Transparent and Explicit proxies is how traffic gets to them.
In an Explicit proxy (and hence an Explicit deployment) the application in question (Internet Explorer, Firefox, custom in-house application, etc.) must have a configuration field to enter a proxy’s IP and port. The end result of this action is whenever this application wants to send traffic, the destination IP of the packet will be that of the proxy, and destination port will be that of the proxy.
In a Transparent proxy (and hence a Transparent deployment) the application in question is either not configured with proxy settings or has no option to configure proxy settings. It sends traffic as it would regularly to the destination IP addresses and port numbers of the servers it wants to connect to. The network must find a way (different techniques available such as setting the proxy as the default gateway or WCCP for example) to get traffic to the proxy, and once it does, the proxy will intercept it and effectively spoof the IP address of the server when communicating with the client. From the client’s perspective there are no visible differences in Layer 4 and below.
This is the fundamental difference between the two. Understanding this will allow to better design how you want to deploy your proxies. Some things to help you in your considerations of each deployment:
Transparent
Pros
- No additional client side configuration needed
- Client unaware of proxy’s existence and evasion is highly unlikely
- Ability to intercept the 3 way handshake of any application routed to it
Cons
- May require network redesign
- Traffic that has to be bypassed from SSL interception to work cannot be authenticated (SSL interception must takes place before authentication in classic authentication deployments. Certificate realm authentication is an exception)
Other
- Client responsible for completing DNS requests
Explicit
Pros
- Easier to troubleshoot
- All traffic it receives can be authenticated before interception as long as the application supports HTTP 407 response codes
Cons
- Client side settings needed (typically done via .pac file pushed through GPO, though other methods available)
- Client is aware of proxy’s existence and can attempt to bypass it or tunnel traffic through it
- Only applications that allow for proxy to be configured can be proxied via this method.
Other
- Proxy responsible for completing DNS requests on behalf of all clients
While this is not a definitive list, it describes the fundamental concepts and differences between these 2 proxy deployment modes and should be a good guide to get you started when planning on how to deploy a proxy on your network.
Feedback
