icon-zia.svg
Secure Internet and SaaS Access (ZIA)

Load Balancing for PAC Forwarded Traffic

Zscaler supports up to 8 Virtual IP (VIP) addresses in a cluster and up to 64 clusters in a data center to ensure load balancing for the incoming traffic. Load balancing is typically based on the source IP address and the destination IP address. Many deployments have traffic-forwarding either through Zscaler Client Connector or directly via a browser. If your organization uses NAT, the traffic originating from multiple users has the same public IP address.

Many organizations use only Zscaler Client Connector as the traffic forwarding method. In such cases, a large volume of users from one physical location are behind an edge gateway with a single egress IP address. This means that all the users have the same source IP address. So, the typical load balancing calculation leads all the users from the organization to connect to the same ZIA Public Service Edge in the data center. This results in the overloading of a single Service Edge instance in the data center, thereby causing performance issues.

To evenly distribute PAC forwarded traffic over multiple Service Edge instances in a data center, the PAC server returns multiple VIPs within the same data center as the destination IP address. When the clients with the same source IP address are assigned with different VIPs as the destination IP addresses, they are load-balanced to different Service Edge instances. This ensures even distribution of traffic from the same source IP address over multiple Service Edge instances.

The PAC server uses the ${GATEWAY_FX} and ${GATEWAY_Fn} variables, (where n can take up to 8 values from 0 to 7 ) in the Zscaler-hosted PAC file to assign the VIPs for the incoming traffic:

Load balancing for PAC forwarded traffic can be classified as:

  • For Zscaler Client Connector users, the PAC server allocates VIPs for devices through the ${GATEWAY_FX} variable in the Zscaler-hosted PAC file. When the Zscaler Client Connector connects to the PAC server to download a PAC file, it sends a unique device identifier with the request. The PAC server allocates one of the VIPs to the device based on the device identifier received from the HTTP request using the ${GATEWAY_FX} variable. When the same device connects again to download the PAC file, the PAC server allocates the same VIP that was allocated to the device earlier based on its unique identifier.

    Close
  • Each data center can have up to 8 unique VIPs assigned to it. For non-Zscaler Client Connector users, admins can leverage the ${GATEWAY_Fn} variable in the Zscaler-hosted PAC file to evenly distribute the clients across multiple VIPs.

    ${GATEWAY_Fn} represents 8 different variables starting from ${GATEWAY_F0} to ${GATEWAY_F7} that are used to pick an available VIP from the data center. The PAC server returns the VIP value based on the variable used in the PAC file. If the number of VIPs assigned to a data center is less than 8, then the PAC server allocates the available VIPs to all 8 variables in a round-robin fashion.

    The following image illustrates how the VIPs are mapped to the variables based on the number of available VIPs in a data center:

    Zscaler recommends the following PAC file format for non-Zscaler Client Connector users to leverage the multiple VIP features using a single PAC file.

    Close
Related Articles
Writing a PAC FileBest Practices for Writing PAC FilesFirewall Requirements for Using PAC FilesUsing Default PAC Files to Forward Traffic to ZIAUsing Custom PAC Files to Forward Traffic to ZIAForwarding Traffic Based on User's Location Using PAC FilesLoad Balancing for PAC Forwarded TrafficDistributing a PAC File URL to UsersConfiguring Internet Explorer to Use a PAC FileConfiguring Google Chrome to Use a PAC FileConfiguring Mozilla Firefox to Use a PAC FileConfiguring Safari to Use a PAC FileIdentifying the PAC File on a Device Using Browsers