What is a sub-location?

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.
  • 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.
  • 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.

To add a sub-location:

  1. Go to Administration > Resources > Locations.
  2. Select the location and 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.
  3. Go to the location to which you want to add the sub-location and click the Add Sub-Location icon.
    See image.
  4. Enter a Name for the sub-location and modify any settings that do not apply to the sub-location.
  5. Add the internal IP addresses and enable features for the sub-location:
    • Internal IP Addresses: Add the Internal IP Addresses of the sub-location.
    • Enable IP Surrogate: Select to map users to device IP addresses.
      If the IP Surrogate feature is enabled, in Idle time to Disassociation, specify how long after a completed transaction the service retains the IP address to user mapping.
    • Enable SSL Scanning: Select to enable the service to decrypt HTTPS transactions and inspect them for data leakage, malicious content and viruses, and to enforce policy.
    • Enforce Firewall Control: Select to enable the firewall.
  6. In the Bandwidth Control section, you can enforce bandwidth control for the location. Specify the bandwidth limits of the following:
    • Download (Mbps)
    • Upload (Mbps)
  7. Click Save and activate the change.

The service lists sub-locations when you expand a location. See image. 

Screenshot of Zscaler sub-locations list used when traffic forwarding

Screenshot of sub-location icon used to add Zscaler sub-location when traffic forwarding