Zscaler Client Connector Portal — App Profiles, Forwarding Profiles & Trusted Network Detection

💡 Why this matters — the HR dress-code memo

Picture a company with branches in Lucknow, Pune and Bengaluru. HR writes ONE dress-code memo and pushes it to every branch. The branch manager does not invent his own rule — he reads the memo and follows it. If HR sends the wrong memo, every branch dresses wrong on the same Monday.

The App Profile is exactly that memo. The Client Connector Portal is HR. Each laptop is a branch that just obeys what HR pushed. So when a ticket says "policy not applying on 200 laptops", you do not log into 200 laptops — you fix the one memo in the portal. This is the single biggest mindset shift for a new ZCC engineer.

Three objects do the work. App Profile = WHO + which OS gets which bundle. Trusted Network = WHERE the device thinks it is. Forwarding Profile = HOW traffic leaves, given where it is. Mix these up and you will chase ghosts.

🔑 Six words you will see on every portal screen

Tap each card. These six terms repeat across App Profiles, Forwarding Profiles and Trusted Networks — learn them once, read every screen faster.

① What the Client Connector Portal is + where it sits

The Client Connector Portal is a separate management console from the ZIA admin console and the ZPA admin console. You sign in, build profiles, and Zscaler's cloud pushes them down to every enrolled ZIA / ZPA agent.

The navigation root moved from the old "Administration" tree to the current Infrastructure tree. As of June 2026, use the Infrastructure paths. App Profiles live at Infrastructure > Connectors > Client, Forwarding Profiles at Infrastructure > Connectors > Client > Forwarding Profile for Platforms, and Trusted Networks at Infrastructure > Locations > Trusted Networks.

② App Profiles — the per-OS, per-group policy bundle

An App Profile is the rule object that maps users, groups and device-groups (plus the OS, via which tab you build it under) to one chosen Forwarding Profile, a PAC, posture, and captive-portal behaviour. There is one App Profiles tab per OS — Windows, macOS, Linux, iOS, Android — so the "by OS" criterion is enforced by where you build the rule.

You reach it at Infrastructure > Connectors > Client > Windows, then on the App Profiles tab click Add Windows Policy (or Add macOS Policy, Add Linux Policy, etc.). The Rule Order field decides which rule a user gets — precedence is ascending, so the lowest number wins. The Forwarding Profile drop-down is the literal binding link: if you use Z-Tunnel 2.0, you must pick a Forwarding Profile that has Z-Tunnel 2.0 selected.

Three fields make or break the rule. ① Name is just a unique label, but a good convention (region-OS-tunnel-tier) saves you in audits. ② Rule Order is the trap field — a perfect rule placed below a default rule never matches. ③ Forwarding Profile is the binding link; if it lacks Z-Tunnel 2.0, non-web traffic silently won't tunnel even though the rule "looks right".

You can verify the live state from the device using ZSACLI, but only if Command Line Interface access is enabled in the App Profile (under the Add Windows Policy window). The Windows binary lives at C:\Program Files\Zscaler\ZSACli\ZSACli.exe; run it as administrator.

C:\> cd "C:\Program Files\Zscaler\ZSACli"
C:\Program Files\Zscaler\ZSACli> ZSACli.exe status -s all

{
  "zia":  { "state": "ENABLED",  "tunnel": "ZTUNNEL_2_0", "serviceMode": "TUNNEL" },
  "zpa":  { "state": "ENABLED",  "broker": "10.20.4.11",   "assigned": true },
  "zdx":  { "state": "ENABLED" },
  "networkType": "OFF_TRUSTED",
  "appProfile":  "IN-Win-ZT2-Standard",
  "fwdProfile":  "FWD-ZTunnel2-Remote"
}

Read the last three lines first. They tell you exactly which App Profile matched, which Forwarding Profile it bound, and what network state ZCC currently thinks it is in. If appProfile is not the rule you expected, your Rule Order or group binding is wrong — not the laptop.

③ Forwarding Profiles — tunnel mode per network state

Think of the Forwarding Profile as the auto-rickshaw meter. When the driver is in your own colony (On-Trusted), he switches the meter off because the society already covers the ride — your office has a GRE/IPSec tunnel to Zscaler. Out on the highway (Off-Trusted = home / café), the meter is on (Tunnel) so every km is tracked and tolled — inspected by Zscaler. The Forwarding Profile sets one of four modes per network state.

You build it at Infrastructure > Connectors > Client > Forwarding Profile for Platforms → Add Forwarding Profile. Under Forwarding Profile Action for Internet & SaaS you pick the mode for each network type: On-Trusted Network, VPN-Trusted Network, Off-Trusted Network and Split VPN-Trusted Network.

The four exact modes: Tunnel (routes traffic to Zscaler — choose Z-Tunnel 2.0 for all ports), Tunnel with Local Proxy (installs a PAC that forces traffic to localhost; proxy Enforce is locked on), Enforce Proxy (uses system proxy, tunnels nothing), and None (forwards no traffic at all). Zscaler recommends Tunnel (Packet Filter-Based) for Windows and Tunnel with Local Proxy for macOS.

④ Trusted Network Detection — and how all three bind

Trusted Network Detection (TND) is the auto driver recognising your own mohalla. He spots the colony gate — a landmark — and knows he is home. ZCC does the same with Trusted Network Criteria: it checks signals like DNS Server, DNS Search Domains, Hostname and IP, or Network Range, and decides "this is corporate" or "this is not".

You define a Trusted Network at Infrastructure > Locations > Trusted Networks → Add Trusted Network. Add one or more conditions, then set Condition Match to Any (one condition is enough) or All (every condition must match). Zscaler recommends the static criteria — DNS Server and DNS Search Domains — over the dynamic Hostname and IP, because hostname resolution can fail during network transitions and wrongly flip the device to untrusted.

The anchor that matters: ① DNS Server set to your internal-only resolvers, ② DNS Search Domains that exist only on the corporate LAN, and ③ Condition Match = All so one coincidental match (like a home router handing out a .local suffix) can never trip it. Never anchor TND on a public resolver like 8.8.8.8 or a too-broad range like 192.168.0.0/16 — almost every home LAN matches those.

Common mistakes & pro tips