Configuring Proxy Chaining
Proxy chaining involves forwarding traffic from one proxy server to another. This method leverages your existing proxy servers, with no additional changes to the network. It's a quick and easy way to forward your traffic to the Zscaler service from an existing on-premise proxy. Though Zscaler supports proxy chaining, it is not recommended as a long-term solution in production environments. Multiple proxies add latency and proxy servers that support failover support only manual failover.
- Ensure that your organization has been provisioned and send the IP address of your endpoint to Customer Support (or to your Zscaler representative if you are evaluating the service).
- Log in to the service portal and add your gateway location.
- Some proxy servers can insert an X-Forwarded-For (XFF) header in outbound HTTP requests. An XFF header identifies the IP address of the original client that sent the HTTP request through the proxy server, which can then be leveraged by the service to identify the client’s sub-location. Thus, using the XFF headers, the service can apply the appropriate sub-location policy to the transaction, and if Surrogate IP is enabled on the location or sub-location, appropriate user policy to the transaction. Note that when the service forwards the traffic to its destination, it will remove this original XFF header and replace it with an XFF header that contains the IP address of the client gateway (the organization’s public IP address), ensuring that an organization's internal IP addresses are never exposed to the external world.
Furthermore, when the Zscaler service logs a transaction, it includes the source IP address, which is always the public IP address of the firewall or edge router that sent the traffic to the service. But if you want the Zscaler service to log the source IP address that is in the XFF header, you can go to the Advanced Settings page of the admin portal and enable Internal IP Logging.
- Configure your proxy server traffic to the Zscaler service.
Refer to your server’s documentation for instructions on configuring your proxy server to forward traffic to the Zscaler service. You can also refer to the following configuration examples:
Adding a Gateway Location
You will need to provide Zscaler with the public IP addresses of your Internet egress points. This “registration” process enforces the uniqueness of IP addresses, so that an organization does not inadvertently use another organization’s IP addresses. You can send the IP addresses to Customer Support (or to your Zscaler representative if you are evaluating the service). After your IP addresses have been provisioned on the service, log in to the service portal and define your organization’s gateway location as follows:
- Go to Administration > Resources > Locations.
- Click Add.
- Enter general information about the location:
- Type in its Name.
- Choose the Country.
- Enter a State/Province, if applicable.
- Choose the Time Zone of the location.
When you specify the location in a policy, the service applies the policy according to the location's time zone. For example, if a Cloud App Control policy blocks posting to Facebook between 8 a.m. and 5 p.m., and the rule is applied to locations in Spain and California, users at each location will be blocked during their respective daytime hours.
- Choose the IP addresses for the location:
- The Public IP Addresses list displays the IP addresses that you sent to Zscaler when it provisioned your organization. Choose IP addresses for the location.
- Optionally, enable the other features on this page.
- Click Save and activate the change.
This example illustrates how to configure a Microsoft ISA server to redirect web traffic upstream to a ZEN. It is based on the deployment of a simple single network adapter. Client workstations on the internal network have their browsers configured to proxy to the ISA server.
It assumes you have configured the rule to permit web access from the internal network to the Internet. This rule (number 1) allows both the HTTP and HTTPS traffic from the internal network to the external network for all users.
To configure web chaining on the Microsoft ISA Server:
- Go to the Configuration - Networks menu.
- Edit Default Rule or create a new rule higher up in the Web chaining policy.
- On the rule’s Action tab, select to Process requests by: Redirecting them to a specified upstream server.
- Click Settings, and specify the Server as gateway.<cloud_name>.net and enter 80 in the Port and SSL Port fields.
- On the same tab, select to use a Backup route: Upstream proxy server.
- Click Settings, and specify the Server as secondary.gateway.<cloud_name>.net and enter 80 in the Port and SSL Port fields.
All proxy connections to the Microsoft ISA Server will now be forwarded to a resilient pair of nodes within the Zscaler service. Note that both gateway.zscaler.net and secondary.gateway.zscaler.net must be specified as the primary and secondary proxy servers to ensure fault tolerance. Zscaler does not support configurations with only one proxy server.
Following is a sample configuration for proxy chaining using a SQUID proxy server. The example specifies gateway.zscaler.net and secondary.gateway.zscaler.net so the Zscaler service uses its Geo-location technology to forward the traffic to the nearest ZEN.
# ACL that defines the source IPs to match and redirect on acl zscaler src 18.104.22.168/32 acl zscaler src 22.214.171.124/30 acl zscaler src 126.96.36.199/32 # define the caches, user GeoIP cache_peer gateway.zscaler.net parent 80 0 no-query weight=2 cache_peer secondary.gateway.zscaler.net parent 80 0 no-query weight=1 # chain traffic matching the zscaler ACL, all other goes direct cache_peer_access gateway.zscaler.net allow zscaler cache_peer_access gateway.zscaler.net deny all cache_peer_access secondary.gateway.zscaler.net allow zscaler cache_peer_access secondary.gateway.zscaler.net deny all
Following is an example that explicitly forwards traffic to one of three different gateways in a failover scenario. The ACL is defined by the incoming port on the SQUID server.
# listen on normal HTTP/HTTPS ports http_port 80 http_port 443 # ACL that defines the source IPs to match and redirect on # For this example, match on all inbound traffic acl zscaler 0.0.0.0/0.0.0.0 # define the caches cache_peer fmt1.sme.zscaler.net parent 80 0 no-query weight=3 cache_peer ord1.sme.zscaler.net parent 80 0 no-query weight=2 cache_peer atl1.sme.zscaler.net parent 80 0 no-query weight=1 # chain traffic matching the zscaler ACL, all other goes direct cache_peer_access fmt1.sme.zscaler.net allow zscaler cache_peer_access fmt1.sme.zscaler.net deny all cache_peer_access ord1.sme.zscaler.net allow zscaler cache_peer_access ord1.sme.zscaler.net deny all cache_peer_access atl1.sme.zscaler.net allow zscaler cache_peer_access atl1.sme.zscaler.net deny all