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.
To configure proxy chaining:
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:
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:
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. See image.
To configure web chaining on the Microsoft ISA Server:
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 184.108.40.206/32 acl zscaler src 220.127.116.11/30 acl zscaler src 18.104.22.168/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