4.2 PAC Files, Explicit Proxy & Sub-locations

4.2 PAC Files, Explicit Proxy & Sub-locations

Architectural Premise: While GRE and IPsec tunnels capture and steer traffic transparently at the network routing layer, Explicit Proxy forwarding directs application-layer web traffic explicitly to the Zscaler Internet Access (ZIA) Public Service Edge using Proxy Auto-Configuration (PAC) files. Combining PAC files with Sub-locations and Surrogate IP enables granular identity mapping, bandwidth governance, and policy customization for distinct departments and user groups operating behind branch and campus networks.

---

1. PAC File Fundamentals and JavaScript Syntax

A PAC file is a lightweight JavaScript file containing a single mandatory entry-point function: FindProxyForURL(url, host). When an application or browser initiates an HTTP/HTTPS request, it executes the PAC script locally to determine whether the request should be forwarded to a ZIA proxy gateway, sent through a secondary backup proxy, or routed DIRECT to the destination without proxy intervention.

// Standard PAC File Execution Logic Flow
function FindProxyForURL(url, host) {
    
    // 1. Bypass internal intranet hostnames and local domains
    if (isPlainHostName(host) || 
        dnsDomainIs(host, ".corp.local") || 
        dnsDomainIs(host, ".internal.enterprise.com")) {
        return "DIRECT";
    }

    // 2. Bypass private RFC 1918 IPv4 address spaces
    if (isInNet(host, "10.0.0.0", "255.0.0.0") ||
        isInNet(host, "172.16.0.0", "255.240.0.0") ||
        isInNet(host, "192.168.0.0", "255.255.0.0")) {
        return "DIRECT";
    }

    // 3. Bypass latency-sensitive streaming or VoIP services if required
    if (shExpMatch(host, "*.zoom.us") || shExpMatch(host, "*.webex.com")) {
        return "DIRECT";
    }

    // 4. Default: Forward all public web traffic to ZIA Public Service Edge
    return "PROXY ${GATEWAY}:80; PROXY ${SECONDARY_GATEWAY}:80; DIRECT";
}

Common PAC Functions and Operational Guidelines

[!WARNING] Performance Hazard (The dnsResolve() Trap): Executing isInNet(dnsResolve(host), ...) inside a PAC file forces the client browser to perform a synchronous DNS lookup for every single URL request before evaluating the proxy statement. If the destination domain is slow, unreachable, or external, the browser hangs. Best practice dictates matching hostnames using string operations (dnsDomainIs or shExpMatch) rather than resolving DNS on the client.

---

2. Zscaler Dynamic PAC Variables

In standard PAC files, administrators must hardcode proxy IP addresses or hostnames (e.g., PROXY 104.129.192.1:80). This creates severe administrative overhead and fails for mobile users roaming globally. Zscaler resolves this limitation through Dynamic PAC Variables, which the Zscaler Central Authority compiles dynamically at request time based on the client's public egress IP address.

+-----------------------------------------------------------------------------+
|                   DYNAMIC PAC COMPILATION BY CENTRAL AUTHORITY              |
+-----------------------------------------------------------------------------+

  Client Request for PAC:
  Client (Egress IP: 198.51.100.25 - London, UK) ---> GET http://pac.zscaler.net/corp.com/custom.pac
                                                              |
                                                              v
  Zscaler Central Authority:
  * Performs Geo-IP lookup on 198.51.100.25
  * Identifies closest healthy DC: London (lon1.sme.zscaler.net)
  * Identifies secondary DC: Amsterdam (ams1.sme.zscaler.net)
  * Dynamically compiles PAC template:
      ${GATEWAY}           ===> lon1.sme.zscaler.net
      ${SECONDARY_GATEWAY} ===> ams1.sme.zscaler.net
      ${SRCIP}             ===> 198.51.100.25
                                                              |
                                                              v
  Client Receives Compiled JavaScript with Localized Gateway FQDNs

Primary Zscaler Dynamic Variables

• ${GATEWAY}: Evaluates to the FQDN/IP of the geographically closest healthy ZIA Public Service Edge based on the client's public source IP.
• ${SECONDARY_GATEWAY}: Evaluates to the second closest healthy ZIA Public Service Edge, providing automated geographic failover redundancy.
• ${GATEWAY_FX} / ${SECONDARY_GATEWAY_FX}: Evaluates to dedicated ZIA gateways configured for non-HTTP / Firewall-based explicit proxy capabilities.
• ${SRCIP}: Evaluates to the client's public source IP as detected by the Zscaler cloud, enabling source-IP-conditional logic within the script.
• ${GATEWAY_HOST} / ${GATEWAY_PORT}: Separates gateway hostname and listening port (default port 80 or 443 or dedicated ports like 9443).

---

3. Automated PAC Distribution: WPAD, DHCP Option 252, and DNS

Deploying PAC URLs manually across thousands of unmanaged or legacy systems is unscalable. Web Proxy Auto-Discovery (WPAD) automates PAC discovery at the network layer.

+-----------------------------------------------------------------------------+
|                        WPAD DISCOVERY MECHANISMS                            |
+-----------------------------------------------------------------------------+

  Method 1: DHCP Option 252 (Highest Priority in Windows/macOS)
  [ Client Boot ] ---> DHCP Request ---> [ DHCP Server ]
                                              |
                                              +--> DHCP ACK with Option 252:
                                                   "http://pac.zscaler.net/corp/custom.pac"

  Method 2: DNS Lookups (Fallback if DHCP 252 is absent)
  [ Client Query ] ---> DNS Query: "wpad.sub.corp.enterprise.com"
                   ---> DNS Query: "wpad.corp.enterprise.com"
                   ---> DNS Query: "wpad.enterprise.com"
                   ---> Downloads "http://wpad.enterprise.com/wpad.dat"

WPAD Configuration Best Practices

1. DHCP Option 252: Configure DHCP scopes to return Option 252 as a string pointing directly to the Zscaler-hosted PAC URL (http://pac.zscaler.net/<organization_domain>/<pac_file_name>.pac).
2. DNS Fallback: Create internal DNS A or CNAME records for wpad.<domain> pointing to an internal web server hosting the wpad.dat file. Ensure wpad.dat is served with MIME type application/x-ns-proxy-autoconfig.
3. Active Directory GPO / MDM: For enterprise-managed Windows and macOS devices, configure explicit proxy PAC URLs via Intune configuration profiles or Group Policy Objects (Computer Configuration > Administrative Templates > Windows Components > Internet Explorer > Use automatic configuration script), bypassing WPAD network discovery latency.

---

4. Explicit Proxy vs. Transparent Forwarding: DNS Resolution Mechanics

A fundamental architectural difference tested on the ZDTA exam is where DNS resolution occurs between Explicit Proxy and Transparent Tunnel (GRE/IPsec/Z-Tunnel) forwarding.

+-----------------------------------------------------------------------------+
|              DNS RESOLUTION COMPARISON: EXPLICIT VS TRANSPARENT             |
+-----------------------------------------------------------------------------+

  EXPLICIT PROXY (PAC File): No Client-Side DNS Resolution for External Sites
  [ Client Browser ] ---( 1. HTTP CONNECT www.target.com:443 )---> [ ZIA Public Service Edge ]
                                                                          |
                                                                          +---( 2. DNS Query: www.target.com )---> [ Public DNS ]
                                                                          +---( 3. Outbound TCP SYN to IP )-----> [ Origin Web Server ]

  TRANSPARENT TUNNEL (GRE / IPsec): Mandatory Client-Side DNS Resolution
  [ Client Endpoint ] ---( 1. DNS Query: www.target.com )----------> [ Local Internal DNS Server ]
                      <---( 2. DNS Response: 93.184.216.34 )-------+
  [ Client Endpoint ] ---( 3. TCP SYN to 93.184.216.34:443 )------> [ Branch Router ]
                                                                          |
                                                                          +===( 4. Encapsulates in GRE )===> [ ZIA Public Service Edge ]

Architectural Implications of Explicit Proxy DNS:

• Mitigation of DNS-Based Data Exfiltration: Because the client never issues a DNS query to public or local resolvers for web traffic, malicious DNS tunneling techniques (e.g., Iodine, DNS covert channels) cannot be used for data theft via web browsing.
• Resolution of Internal Split-Brain DNS: When users access external sites that have overlapping internal names, explicit proxying forces ZIA to resolve the public DNS record at the cloud edge.
• Zero DNS Overhead on Local Branch Resolvers: Offloads hundreds of thousands of daily external DNS queries from branch domain controllers to Zscaler's global Anycast DNS infrastructure.

---

5. Sub-locations and Scoped Surrogate IP Architecture

In ZIA, a Location represents an entire physical site bound to a static IP address or GRE/IPsec tunnel. However, enterprise branches frequently host diverse network segments—such as Corporate Workstations, Guest Wi-Fi, Point of Sale (POS) Terminals, and Server VLANs—that require distinct security policies and authentication handling.

+-----------------------------------------------------------------------------+
|                  LOCATION & SUB-LOCATION HIERARCHICAL MODEL                 |
+-----------------------------------------------------------------------------+

  Parent Location: "Chicago-Regional-Office" (GRE Tunnel: 198.51.100.1)
  ├── Sub-location 1: "Corporate-Users" (Subnet: 10.10.10.0/24)
  │   ├── Enforce Authentication: ENABLED (SAML SSO)
  │   ├── Enable Surrogate IP: ENABLED (Idle Time: 480 mins)
  │   └── Policy: Full SSL Inspection, DLP, Strict Cloud App Control
  │
  ├── Sub-location 2: "Guest-Visitors" (Subnet: 10.10.20.0/24)
  │   ├── Enforce Authentication: DISABLED (Captive Portal / No SAML)
  │   ├── Enable Surrogate IP: DISABLED (Prevents IP collision across high churn)
  │   └── Policy: Bandwidth Capped (2 Mbps), Social Media & Streaming Blocked
  │
  └── Sub-location 3: "IoT-Printers-Badges" (Subnet: 10.10.30.0/24)
      ├── Enforce Authentication: DISABLED (Headless devices cannot authenticate)
      ├── Enable Surrogate IP: DISABLED
      └── Policy: Restricted to specific internal cloud update URLs only

Sub-location Configuration Parameters in ZIA

1. Internal IP Subnets: Defined by entering one or more RFC 1918 CIDR blocks (e.g., 10.10.10.0/24). ZIA matches incoming packets arriving across the parent tunnel to the sub-location whose subnet matches the packet's inner private source IP.
2. Authentication Enforcement: Can be toggled on or off per sub-location. Corporate subnets enforce SAML SSO, while IoT and guest subnets disable authentication to prevent captive challenge loops on headless devices.
3. Surrogate IP Mapping:
   • What it does: When an authenticated user logs into SAML via their browser, ZIA maps that user's identity to their endpoint's internal private IP address for a configurable idle timeout (e.g., 120 to 480 minutes).
   • Why it matters: Subsequent non-browser traffic (background operating system updates, command-line tools, background daemons) and applications that cannot perform SAML authentication inherit the authenticated user's identity and policies.
   • Sub-location Scoping: Surrogate IP must be disabled on Guest Wi-Fi sub-locations. In high-turnover guest environments where DHCP leases are short, enabling Surrogate IP risks assigning a previous user's credentials and policies to an unrelated subsequent guest device connecting with the same reused IP.