An HTTP proxy intercepts HTTP/S traffic on a network, and then makes the HTTP/S connection to the remote server on behalf of the original client, relaying the responses back to that client. Most HTTP proxies have the ability to block connections to specific sites based on categorization or security content, or to block responses from remote servers that make contain undesirable content (e.g. malware).
There are two primary methods for redirecting HTTP traffic to a proxy: explicit redirection and transparent redirection. These different methods require different steps to be taken in order to function properly in combination with Umbrella.
When intercepting HTTP/S traffic, an HTTP proxy will read the "Host" header in the HTTP/S request, and generate its own DNS query for that host. Thus, it is important to take the proxy's behaviour into consideration when deploying Umbrella solutions. At an abstract level, this involves ensuring that HTTP/S connections to Umbrella IP addresses are not redirected to the proxy, but are instead sent directly to their intended destination.
When using only Umbrella Network protection, it is recommended that the HTTP proxy itself is configured to either use Umbrella directly for DNS resolution, or it should use an internal DNS server which in turn forwards DNS queries to Umbrella. The appropriate external IP address should be registered as a Network identity in the Umbrella Dashboard. In this scenario, no additional action should be required in order to use Umbrella.
If this is not possible for some reason, and clients themselves are using Umbrella, then the actions detailed in this article should be taken in order to ensure that enforcement is not bypassed by the HTTP proxy.
When using the Umbrella roaming client, DNS queries from the client machine are sent directly to Umbrella. However, since an HTTP proxy will perform its own DNS queries, this renders enforcement by the Umbrella roaming client ineffective. Thus, when using the Umbrella roaming client in a proxied environment.
The Virtual Appliance (VA) is intended to act as the DNS server for client machines on the protected network. As such, the use of an HTTP proxy will render its enforcement ineffective in the same manner as the Roaming Client. As such, the actions detailed in this article should be followed in order to ensure that enforcement is effective and reporting is accurate.
In addition to the actions below, it is recommended that the HTTP proxy be configured to use the VA as its DNS server. This allows you to define a policy specific to the proxy so that queries from the proxy can be identified. Such a policy also allows you to disable logging for queries originating from the proxy, which will avoid have duplicate queries in your reports.
Deploying an explicit proxy entails modifying the browser proxy settings in order to explicitly redirect traffic to a proxy. This is done either by using Group Policy in Windows, or more commonly, by using a Proxy Auto-Configuration (PAC) file . In either case, this causes the browser to send all HTTP traffic directly to the proxy, instead of sending it to the remote site. Because the browser knows that the proxy will generate its own DNS request, it does not bother to resolve the hostname of the remote site itself. Additionally, as mentioned above, when the HTTP connection reaches the proxy, the proxy will generate its own DNS query, which may be given a different result than the client would get.
Thus, in order to function properly with Umbrella, two changes are needed:
- The client must be forced to make a DNS query.
- HTTP connections destined to Umbrella IP addresses must not go to the proxy, but rather go directly to Umbrella.
For a transparent proxy, HTTP traffic is rerouted to the proxy at the network level. Because the client is unaware of the proxy, the browser will generate its own DNS request. This means that, if the proxy is also using Umbrella,then each request will be duplicated. Additionally, policy may not be properly applied as the proxy will use the DNS response that it received, not the result the client received.
Unlike the explicit case above, resolving this issue does not require us to force a DNS request on the client, as that is already occurring. However, bypassing the proxy for HTTP connections to Umbrella IP addresses is still required. The method for doing this varies widely depending on what mechanism you are using to redirect traffic to the proxy. In general, however, it involves exempting the Umbrella IP address ranges from being redirected.
Source: https://support.umbrella.com/hc/en-us/articles/230563527-Using-Umbrella-DNS-with-an-HTTP-proxy
