About Sub-Locations

Sub-locations enable an organization to create new locations that reference IP addresses that are encapsulated within a GRE tunnel or IPSec tunnel, or that are passed to the Zscaler service through X-Forwarded-For headers.

For example, an organization can define a sub-location for its corporate network, and another sub-location for its guest network, even if their traffic goes through the same GRE or IPSec tunnel. Then, the organization can use the sub-locations to do the following:

  • Implement different policies based on IP addresses
  • Enforce authentication on the internal corporate network, while disabling it for the guest network
  • Enforce bandwidth control for sub-locations while ensuring that unused bandwidth remains available to the parent location
  • Provide reporting information for different internal networks/offices when they share the same egress IP address

A few things to keep in mind regarding sub-locations:

  • Sub-locations cannot have overlapping IP addresses within a location
  • Sub-locations can reference IP address ranges (e.g., 10.10.20.2-10.10.20.250)
  • When you add a sub-location, the service automatically creates an Other sub-location for all other IP addresses that are sent to the cloud from the location that are not already defined in the sub-location
  • While IP addresses within a location cannot overlap, the same IP address can exist in multiple locations

You can add individual sub-locations, as explained below, or import multiple locations and sub-locations using a CSV file.

To add a sub-location:

  1. Go to Administration > Locations.
  2. In the Locations page, locate the location you want to add a sub-location to, and click the Edit icon.

The Edit Location window appears.

  1. In the Edit Location window, select the Enable XFF Forwarding option if this location uses proxy chaining to forward traffic to the Zscaler service, and you want the 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.

Using the XFF headers, the service can apply the appropriate sub-location policy to the transaction, and if Enable IP Surrogate is turned on for the location or sub-location, the appropriate user policy is applied to the transaction. When the service forwards the traffic to its destination, it will remove the 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 externally.

  1. Go back to the Locations page and click the Add Sub-Location icon for the location.
    See image.

The Add Sub-Location window appears.

  1. In the Add Sub-Location window, in the Location section:
    • Name: Enter a name for the sub-location
    • Country: Choose your sub-location's country
    • State/Province: Enter the sub-location's state or province, if applicable
    • Time Zone: Choose the time zone for the sub-location
  2. In the Addressing section:
    1. Internal IP Addresses: Add the internal IP addresses for the sub-location.
    2. Click Add Items.
  3. In the Gateway Options section:
    • Enforce Authentication: Enable to require users from this location to authenticate to the service. To learn more, see Provisioning and Authenticating Users.
    • Enable AUP: If you disabled Enforce Authentication, you can enable this feature to display an Acceptable Use Policy (AUP) for unauthenticated traffic and require users to accept it. To learn more, see About Acceptable Use Policy and End User Notifications. If you enable this feature:
      • In Custom AUP Frequency (Days) specify, in days, how frequently the AUP is displayed to users
      • First Time AUP Behavior section appears, with the following settings:
        • If Block Internet Access is enabled, the Zscaler service will disable all access to the internet, including non-HTTP traffic, until the user accepts the AUP that is displayed to them
        • If Force SSL Interception is enabled, to make SSL Inspection enforce an AUP for HTTPS traffic
    • Enable IP Surrogate: If you enabled Enforce Authentication, select this option if you want to map users to device IP addresses for a sub-location. To learn more, see What is Surrogate IP?

If you enable this feature on a sub-location:

  • In Idle Time to Disassociation, specify how long after a completed transaction the service retains the IP address-to-user mapping.
  • If you want to use the existing IP address-to-user mapping (acquired from the surrogate IP) to authenticate users sending traffic from known browsers, enable Enforce Surrogate IP for Known Browsers.

With this feature enabled, the Zscaler 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 for users who connect over high-latency satellite links, for example. 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 Zscaler service can use IP address-to-user mapping for authenticating users sending traffic from known browsers. After the defined period of time elapses, 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.

The refresh time for the revalidation of IP surrogacy must be shorter than the DHCP lease time, otherwise the wrong user policies might be applied. Also, Zscaler recommends setting the Refresh Time for re-validation of Surrogacy to a time period shorter than what you specified for Idle Time to Disassociation.

  • Enable Kerberos Authentication: If you enabled Enforce Authentication, you can enable this feature to enforce Kerberos authentication on all web traffic explicitly forwarded from the location and its associated dedicated ports. To learn more, see How do I deploy Kerberos?
  • Enable SSL Scanning: Enable to apply your SSL Inspection policy to HTTPS traffic in the location and inspect HTTPS transactions for data leakage, malicious content, and viruses. To learn more, see How do I deploy SSL inspection?
  • Enforce Firewall Control: Select to enable the service's firewall controls.
  1. In the Bandwidth Control section, you can Enforce Bandwidth Control for the sub-location:
    • If you have bandwidth control disabled on the parent location, you can still select Enabled for the sub-location and then specify the maximum bandwidth limits for Download (Mbps) and Upload (Mbps).
    • If you have bandwidth control enabled on the parent location, you can:
      • Select Use Location Bandwidth to enable on the sub-location and use the download and upload maximum bandwidth limits as specified for the parent location.
      • Select Override to enable on the sub-location and then specify the maximum bandwidth limits for Download (Mbps) and Upload (Mbps). This bandwidth is dedicated to the sub-location and not shared with others.

Any unused bandwidth is returned to the parent location’s bandwidth.

  1. Click Save and activate the change.

In the Locations page, the sub-locations are listed when you expand a location.
See image. 

Locations page with sub-locations displayed within table

Locations page with Add Sub-location icon