3.2 Forwarding Profiles, App Profiles & PAC Integration

3.2 Forwarding Profiles, App Profiles & PAC Integration

Zscaler Client Connector separates where an endpoint is physically connected from who is logged in and what services they can access. This separation is implemented through two fundamental policy objects in the Zscaler Client Connector Portal:

1. Forwarding Profiles: Define network environmental context (Trusted vs. Untrusted vs. VPN) and dictate how traffic is forwarded (Z-Tunnel 1.0, Z-Tunnel 2.0, Local Proxy, or None).
2. App Profiles: Define user and group entitlements, client feature controls (e.g., ZIA, ZPA, ZDX enablement), UI behavior, logging verbosity, and the browser-level PAC file.

---

1. Forwarding Profiles vs. App Profiles

Understanding the distinct roles of Forwarding Profiles and App Profiles is essential for both designing zero-trust deployments and passing the ZDTA exam.

+-----------------------------------------------------------------------------+
|                             APP PROFILE                                     |
|  "Who are you and what features/entitlements do you receive?"                |
|  - Target Criteria: SAML User, Group, Department, OS Platform (Win/Mac/iOS) |
|  - Service Enablement: ZIA (On/Off), ZPA (On/Off), ZDX (On/Off)             |
|  - App Profile PAC File: Injected into OS / Browser (127.0.0.1:9000)        |
|  - Client Controls: Log Level, Notification Settings, Password Policies      |
|  - Association: References exactly ONE Forwarding Profile                   |
+-------------------------------------+---------------------------------------+
                                      |
                                      v
+-----------------------------------------------------------------------------+
|                         FORWARDING PROFILE                                  |
|  "Where are you and how should your network packets be forwarded?"          |
|  - Trusted Network Detection (TND): DNS, Default Gateway, HTTP Probe        |
|  - Network Locations & Tunnel Actions:                                      |
|      * On-Trusted Network:     Action (Tunnel 2.0, Tunnel 1.0, Proxy, None) |
|      * Off-Trusted Network:    Action (Tunnel 2.0 / DTLS with TLS Fallback) |
|      * VPN-Trusted Network:    Action (None / Tunnel with Route Exclusions) |
|  - Forwarding Profile PAC: Evaluated at the driver level for tunnel entry   |
+-----------------------------------------------------------------------------+

---

2. Trusted Network Detection (TND)

Trusted Network Detection (TND) is the intelligence engine inside ZCC that determines whether an endpoint is connected directly inside a trusted corporate network (such as a corporate headquarters or branch office) or situated on an untrusted public network (such as a home Wi-Fi or coffee shop).

Whenever a network change occurs—such as a DHCP renewal, Wi-Fi SSID transition, or virtual adapter connection—ZCC initiates a TND evaluation.

+-----------------------------------------------------------------------+
|                   TND EVALUATION CRITERIA WORKFLOW                    |
+-----------------------------------------------------------------------+
                                    |
                       [ Network Change Detected ]
                                    |
                                    v
         +-----------------------------------------------------+
         | 1. DNS Server & Search Domain Matching Check        |
         |    - Are local DNS servers in enterprise list?      |
         |    - Does DNS search domain match corp.internal?    |
         +--------------------------+--------------------------+
                                    |
                                    v
         +-----------------------------------------------------+
         | 2. Default Gateway IP / MAC Address Lookup          |
         |    - Does default gateway IP match branch subnet?   |
         |    - Does gateway MAC match core router BSSID/MAC?  |
         +--------------------------+--------------------------+
                                    |
                                    v
         +-----------------------------------------------------+
         | 3. Internal Network Validation Server (HTTP Probe)  |
         |    - HTTP/HTTPS GET to internal canary URL          |
         |    - Validates expected payload + Internal Root CA  |
         +--------------------------+--------------------------+
                                    |
            +-----------------------+-----------------------+
            |                                               |
       [ All Pass ]                                   [ Any Fail ]
            |                                               |
            v                                               v
  =====================                           =====================
   ON-TRUSTED NETWORK                              OFF-TRUSTED NETWORK
  =====================                           =====================

TND Verification Mechanisms

1. DNS Search Domains & DNS Servers:

   • ZCC checks the endpoint's active network adapter to verify if assigned DNS servers match specified corporate internal IPs and whether the connection-specific DNS suffix matches authorized domains (e.g., corp.example.local).

2. Default Gateway IP & MAC Address:

   • ZCC checks the default gateway IP address and reads the ARP table to match the default gateway's MAC address against predefined gateway fingerprints.

3. Network Validation Server / HTTP(S) Probe:

   • The Gold Standard for TND: Simple DNS and gateway checks can be spoofed by malicious Wi-Fi hotspots or captive portals. To eliminate false positives, Zscaler strongly recommends configuring a Network Validation Server.
   • ZCC issues an HTTP or HTTPS probe to an internal web server URL reachable only from within the corporate LAN. If configured with HTTPS, ZCC validates that the certificate was issued by the internal enterprise Private Root CA. If the probe succeeds and returns the expected cryptographic response code, the network is positively verified as Trusted.

---

3. The Dual PAC File Architecture

A frequent area of confusion—and a primary focus of advanced ZDTA questions—is the Dual PAC File Architecture utilized by ZCC. ZCC uses two separate PAC files that execute at different layers of the operating system.

[ Web Browser / Application ]
              |
              | 1. App Profile PAC (AP-PAC)
              |    Evaluated by browser/OS proxy subsystem
              v
+-------------------------------------------------------------+
| Local Proxy Listener: 127.0.0.1:9000 (ZSATunnel.exe)        |
+-------------------------------------------------------------+
              |
              | 2. Forwarding Profile PAC (FP-PAC)
              |    Evaluated by ZCC Driver (Packet/Route Engine)
              v
+-------------------------------------------------------------+
| ZCC Kernel Driver Interception Layer                        |
+------------------------------+------------------------------+
                               |
          +--------------------+--------------------+
          |                                         |
     [ MATCH ]                                 [ BYPASS ]
          |                                         |
          v                                         v
+---------------------------+             +-------------------+
| Z-Tunnel 2.0 (DTLS/TLS)   |             | Direct to Local   |
| Encapsulation to ZIA/ZPA  |             | Physical NIC / ISP|
+---------------------------+             +-------------------+

Comparing the Dual PAC Files

1. App Profile PAC (AP-PAC)

• Execution Point: Operating system proxy layer and web browser network stack.
• Primary Role: Instructs browsers and system applications to send web traffic (HTTP/HTTPS) to the local ZCC proxy listening port: PROXY 127.0.0.1:9000.
• Example Statement:

  function FindProxyForURL(url, host) {
      // Bypass local intranet addresses at the browser layer
      if (isPlainHostName(host) || shExpMatch(host, "*.corp.local"))
          return "DIRECT";
      
      // Forward all other web traffic to local ZCC listening port
      return "PROXY 127.0.0.1:9000; DIRECT";
  }
  

2. Forwarding Profile PAC (FP-PAC)

• Execution Point: ZCC kernel driver / tunneling engine.
• Primary Role: Determines which destinations enter the Z-Tunnel (Z-Tunnel 1.0 or 2.0) destined for the Zscaler Public Service Edge versus what traffic is completely bypassed from the ZCC driver.
• Example Statement:

  function FindProxyForURL(url, host) {
      // Bypass corporate data center subnets from ZIA tunnel
      if (isInNet(dnsResolve(host), "10.0.0.0", "255.0.0.0"))
          return "DIRECT";
      
      // Tunnel traffic to ZIA node via Gateway
      return "PROXY ${GATEWAY}:80; PROXY ${SECONDARY_GATEWAY}:80; DIRECT";
  }
  

[!WARNING] Critical Architecture Rule: Returning DIRECT in an App Profile PAC bypasses the local 127.0.0.1:9000 proxy listener, but if the Forwarding Profile is set to Z-Tunnel 2.0, the kernel driver will still intercept the underlying IP packet and route it into the tunnel unless the destination is also bypassed in the Forwarding Profile PAC or Forwarding Profile destination exclusion list!

---

4. Tunnel Action Selection Based on Network Context

Within the Forwarding Profile, administrators configure distinct Tunnel Actions tailored to each network state discovered by TND:

1. On-Trusted Network Action:

   • Option A (None): If the corporate headquarters or branch office is already protected by an IPsec or GRE tunnel forwarding traffic to ZIA with location-based policies, ZCC sets its tunnel action to None. This prevents "tunnel-inside-a-tunnel" encapsulation overhead and lets the perimeter firewall/router handle cloud forwarding.
   • Option B (Tunnel 2.0): If the corporate network does not have site-to-site GRE/IPsec tunnels, ZCC maintains an active Z-Tunnel 2.0 tunnel even while on-premises to enforce user-level identity and security.

2. Off-Trusted Network Action:

   • Standard policy is Tunnel 2.0 (DTLS with TLS fallback). Enforces full cloud security inspection across all TCP, UDP, and ICMP traffic whenever the user is remote.

3. VPN-Trusted Network Action:

   • Evaluated when a full-tunnel or split-tunnel third-party VPN adapter becomes active.
   • If a full-tunnel corporate VPN is active, setting this action to None avoids double-encryption and routing conflicts.