In certain deployments from known locations, you can enable the Zscaler service to map a user to a private IP address so it applies the user’s policies, instead of the location’s policies, to traffic that it cannot authenticate, which includes:

  • Applications that do not support cookies, such as Google Earth and Skydrive
  • HTTPS transactions that are not decrypted
  • Transactions that use unknown user agents

If a user browses the Internet from multiple private IP addresses, the service maps all the private IP addresses to the user. The service also associates the transactions with the user in the logs.

The service maps a private IP address to only one user at a time. It retains the mapping until the configured idle time ends, until the user logs out of a session or logs out of the Zscaler service gateway, or until another user sends authenticated transactions from the same private IP address. The service will map the private IP address to a new user if a different user logs in to a session or to the service gateway from the same private IP address. Note that if the mapping changes more than three times in a minute, that is, three different users log in and surf the Internet from the same private IP address within a minute, the service will stop mapping users to the private IP address for five minutes and will apply the location policies to the transactions that do not support authentication during these five minutes.

Additionally, an organization can subscribe to one or more dedicated proxy ports and associate them with a location. If you enable this feature on a location with at least one subscribed port, the service maps the public IP address and not the internal or private IP address to the user, so it can apply user-level policies to road warrior traffic that it cannot authenticate.

Requirements

  • To use this feature, your organization must use one of the following methods to forward traffic to the service:
    • A GRE or IPsec tunnel without NAT
    • Forward proxy chaining with the XFF Forwarding option enabled on the location
    • Your organization subscribes to a dedicated proxy port
  • The location must have authentication enabled.

Enabling Surrogate IP

  1. Go to Administration > Resources > Location.
  2. Point to the location and click the Edit icon.
  3. In the Edit Location window, do the following:
    • Turn on Enable XFF Forwarding if this location uses proxy chaining to forward traffic to the service, and you want the Zscaler service to use the X-Forwarded-For (XFF) headers that your on-premise proxy server inserts in outbound HTTP requests. The XFF header identifies the client IP address, which can 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.
    • Turn on Enforce Authentication.
    • Turn on Enable IP Surrogate.
    • In Idle time to Disassociation, specify how long after a completed transaction the service retains the private IP address to user mapping.
    • Turn on Enforce Surrogate IP for Known Browsers if you want to use existing IP-to-user mapping (acquired from Surrogate IP) to authenticate users sending traffic from known browsers. With this feature enabled, the service uses existing IP-to-user mapping for authentication even if users go to sites that support cookies. This allows the service to authenticate without requiring the browser to complete HTTP redirects for every transaction, ensuring performance even for users who connect, for example, over high-latency satellite links. If the feature is disabled, the service authenticates users on browsers with cookies or other configured authentication mechanisms.  
    • If you enabled Enforce Surrogate IP for Known Browsers, in Refresh Time for Re-Validation of Surrogacy, specify the length of time that the service can use IP-to-user mapping for authenticating users sending traffic from known browsers. After the defined period of time, the service will refresh and revalidate the existing IP-to-user mapping so that it can continue to use the mapping for authenticating users on browsers. You can enter any value from 1 minute to 8 hours.
  4. Click Save and activate the change.