T Techclick ← Zscaler hub
Zscaler · Whole Tech 1 of 2 · Session factory

The Zero Trust Exchange is a session factory — user → ZTE → ZIA or ZPA

A 09:12 ticket says “internet is broken” and a screenshot of a green Allow. Half the time the laptop never reached the exchange, ZIA never inspected the SaaS, or ZPA never brokered the private app. This lesson is the product starter: how the factory takes a user or device and manufactures a session down one of two lines.

~18 min read · L2 primary · Quiz at end · Blog 2 · Evidence desk

After this page you can

Quick answer

A user or device hands a flow to the Zero Trust Exchange (ZTE). The exchange is a proxy factory, not a network you join. Internet and SaaS go down the ZIA line: a Public Service Edge inspects (SSL + SSMA) and opens its own connection to the destination. Private apps go down the ZPA line: a Service Edge brokers an inside-out tunnel to an App Connector. Official Help is explicit: in Internet & SaaS the Service Edge inspects the data; in Private Access it does not inspect the data as it flows through. ZIA and ZPA run on separate multi-tenant clouds. The Central Authority writes policy; it is not on the live path. Allow is a policy decision. It is never the last sentence.

Say this out loud

User or device arrives at the Zero Trust Exchange. Destination class picks the line: ZIA inspects internet and SaaS; ZPA brokers the private app. I name the line first, then forwarding, then who is on the ticket, then the exact transaction.

1. Why the factory matters

Students memorise ZIA versus ZPA like two products you pick at random. In production they are two lines inside one exchange. The ticket is almost never “the proxy is down.” It is “this person, on this path, to this destination, at this minute.” If you skip the first stamps, you rebuild SAML for a down Z-Tunnel, or you add a ZIA URL allow for a private FQDN that should have been a ZPA Application Segment.

The lie that burns L2 is: “Zscaler allowed it, so the user should be happy.” Allow is a policy decision. The browser can still die on inspect, pin, posture, a dead App Connector, or traffic that never reached the factory. Unauthenticated is often a forwarding miss, not a broken IdP.

Hero · the factory
User and device connecting through a Zero Trust Exchange factory to internet and a private app
Notice: the user never opens a socket to the destination. The exchange does. Two exits, one arrival.
Interview line

Zscaler connects the user to the application, not to your network. Apps stay invisible to the internet. That is the factory contract — official Zero Trust Exchange architecture, not a slogan.

2. Mental model — one exchange, two lines

Memorise three parts. Skip one and you debug the wrong console.

  1. Arrival — Client Connector (Z-Tunnel), GRE/IPSec, PAC, or Branch Connector hands the flow to a Service Edge.
  2. Factory — the Service Edge identifies the user or location, loads the activated policy the Central Authority already pushed, and classifies the destination.
  3. Line — public internet/SaaS runs ZIA (inspect + egress). Private FQDN runs ZPA (broker + App Connector). Default on ZPA is deny until an Access Policy allows.
Feel · arrive → identify → decide → access
Four-step session journey: arrive, identify, decide, access
Feel the order: Arrive at the exchange, Identify who and what, Decide the line, then Access. Policy was already on the edge.
Flow 1 · the factory — user/device → ZTE → ZIA or ZPA
One arrival. Two production lines. CA is off the solid path. User / device browser · ZCC · site Forwarding Z-Tunnel · GRE · PAC Zero Trust Exchange Service Edge · identity destination class Central Authority writes policy · not inline ZIA line · inspect Public Service Edge for Internet & SaaS SSL + SSMA · URL · DLP · firewall PSE opens the socket to the destination Nanolog is a copy, not a hop ZPA line · broker Public / Private Service Edge for Private Access does not inspect payload like ZIA inside-out App Connector · Microtunnel separate multi-tenant cloud from ZIA User-to-app, not user-to-network. Apps stay invisible. If forwarding is down, neither line prints a transaction. Fix arrival first.

Solid arrows = user session. Dashed = control. If you draw the Central Authority on the solid line, the interview is already lost.

Hard words before the runbook

TermMeaning on a ticket
Zero Trust Exchange (ZTE)The cloud-native platform that brokers user-to-app, app-to-app, and machine-to-machine sessions from identity and context. Not a LAN you join.
Public Service Edge (ZIA)Full-featured secure internet gateway. Inspects web traffic bidirectionally. SSL + SSMA (Single-Scan Multi-Action). Opens its own connection to the destination.
Public / Private Service Edge (ZPA)Brokers Client Connector to App Connector. Official Help: does not inspect the data as it flows through, unlike the ZIA edge.
Central Authority (CA)Brain of the cloud: policy, config, software, feeds. Pushes to edges. Never inspects the live session. ZIA and ZPA each have their own CA fabric.
Z-Tunnel 2.0DTLS or TLS tunnel from Client Connector to the Service Edge. Carries all ports and protocols. Tunnel down = factory never saw the flow.
App ConnectorVM next to the private app. Outbound-only to the ZPA Service Edge. No inbound VIP on the app. Closest healthy connector wins.
Application SegmentZPA object: FQDN + port + server group. Enabled is the object. It is not the allow.
Access PolicyZPA allow/deny for user, group, posture, Connector group. Default is block until a rule allows.
LocationZIA named source (public IP, GRE/IPSec, dedicated port). Known location can run place-only policy. Unknown / Road Warrior must authenticate or is refused.
NanologZIA log store. A compressed TLS copy leaves the edge. A Nanolog outage does not stop enforcement.
Two clouds, one badge

ZPA Help: Private Access runs on a unique multi-tenant infrastructure, separate from Internet & SaaS. The user still has one identity. The session is still one factory ticket. The inspect engine is not shared. Do not expect a ZIA URL rule to grant crm.internal.example.

3. Decision flow — ZIA or ZPA

Draw this on the whiteboard before you open Admin. The diamond is not “is Zscaler up?” The diamond is “did a flow arrive, and what class of destination is it?”

Path · two exits
Decision node splitting traffic into Path A internet and Path B private app
Notice: one decision, two factory lines. Path A is ZIA inspect. Path B is ZPA broker. If arrival failed, stop — there is no line yet.
Flow 2 · ticket decision tree
Start every ticket here — not in a random policy list Forwarding up? NO Z-Tunnel / GRE / PAC / Branch down Looks unauthenticated. Fix arrival. YES Who is on the ticket? location name or username Destination class? Public SaaS / web → ZIA line web log + SSL + rule name Private FQDN → ZPA line segment + Access Policy + connector Then prove the transaction. Do not add a second IdP or a ZIA allow for a private app.

Diamond = decision. Always start with forwarding, then identity, then destination class. ZDX and Branch are later lessons — they watch or steer; they do not print the session.

4. How to choose the line

Use this table in design reviews and in the first five minutes of a Sev-2. The wrong line wastes an hour of “why is URL filtering not seeing CRM.”

SituationPreferDo not
Internet / SaaS — URL, SSL inspect, DLP, cloud-appZIA Public Service Edge + named user or known LocationHide a private app behind a ZIA allow
Internal FQDN, no inbound VIP, least privilegeZPA Application Segment + Access Policy + App Connector groupTreat Enabled as an allow
Roaming laptop, all ports/protocolsClient Connector Tunnel (Z-Tunnel 2.0) to the nearest Service EdgeAssume PAC-only still covers non-web
Known office, many users, internet breakoutGRE or IPSec to a ZIA Public Service Edge, bound to a LocationQuote the tunnel without a Location match
Branch / IoT / no Client ConnectorBranch Connector forwards the flow to the ZTE, then ZIA or ZPA by destinationStop at the classify rule — you still need the ZIA or ZPA transaction
Need residency or a dedicated inspect edgeZIA subcloud, or Private / Virtual Service Edge for Internet & SaaSAssume “Private Service Edge” means ZPA
One user slow, peers fineProve the factory line first, then ZDX score / Cloud PathOpen a tenant Sev-1 from a single score

5. Runbook Side A → B → C

Goal for a new Finance SaaS plus a private CRM on the same laptop: the flow reaches the exchange, internet goes to ZIA, CRM goes to ZPA, and you can quote both transactions.

Primary source for arrival: Zscaler Help — Choosing Traffic Forwarding Methods and Configuring Forwarding Profiles for Zscaler Client Connector. Primary source for the two lines: Understanding the Zscaler Cloud Architecture for Internet & SaaS and Understanding the Private Access Architecture.

Side A — Get the flow to the factory

  1. Name the arrival method

    Laptops: Client Connector Forwarding Profile Tunnel (Z-Tunnel 2.0) for internet, Private Access enabled for internal FQDNs. Known office: GRE or IPSec from the firewall to a ZIA Public Service Edge, bound to a Location. PAC-only is web-only. Branch without ZCC: Branch Connector forwards to the ZTE, then ZIA or ZPA by destination.

  2. Prove the laptop actually arrived

    From the pilot machine open https://ip.zscaler.com. You want a Zscaler cloud and a Location (or Road Warrior if that is the design). Client Connector status should show Internet & SaaS and Private Access connected to a Service Edge. If the page says you are not going through Zscaler, stop — there is no factory ticket to debug.

  3. Stamp who is on the ticket

    Known Location can run place-only policy. Unknown location must authenticate or is refused. Groups come from SCIM (directory write), not from the SAML password success. Full Entra SAML+SCIM walk is the authentication lesson. Do not rebuild an IdP until arrival is proven.

admin.zscalerthree.net · Infrastructure → Connectors → Client → Forwarding Profile for Platforms
Training mock · not live

Infrastructure / Connectors / Client / Forwarding Profile for Platforms / Add

Add Forwarding Profile

Lab-Tunnel-2
Tunnel (Z-Tunnel 2.0)
Tunnel (Z-Tunnel 2.0)
None
Forward all ports and protocols to the nearest Service Edge

Source: Zscaler Help — Configuring Forwarding Profiles for Zscaler Client Connector. Path on Experience Center: Infrastructure → Connectors → Client → Forwarding Profile for Platforms. Older Client Connector Portal label: Administration → Forwarding Profile. Lab values only.

Side B — Pick the line and the objects

  1. ZIA for the SaaS

    Policy → URL & Cloud App Control (and SSL Inspection if you inspect). Rule for group Finance, action Allow + inspect unless a pin exception is owned. ZIA writes stay PENDING until Activation → Activate. Proof is a web log row with the username or the Location you designed — not an empty user on a rule you thought was group-based.

  2. ZPA for the private CRM

    Resource Management → Application Management → Application Segments → Add. Application crm.internal.example, port 443, server 10.50.8.20, App Connector group next to that server. Then Policy → Access Policy → Add Rule: users in Finance, posture managed, action Allow. ZPA blocks until this rule exists. ZPA has no Activate step — the object is live when saved.

  3. Do not cross the lines

    A ZIA URL allow does not grant a private FQDN. An Enabled Application Segment does not grant the user. Branch Direct / Drop is a steer, not a ZIA or ZPA close. Write the owner on any Direct exception.

admin.private.zscaler.com · Policy → Access Policy → Add Rule
Training mock · not live

Policy / Access Policy / Add Rule

Add Access Policy

Finance-CRM-Allow
Allow Access
CRM-Prod · Finance-Private
Finance
Managed
DC1-Connectors

Source: Zscaler Help — Understanding the Private Access Architecture / Configuring Access Policies. Enabled is the object. Access Policy is the allow. Default deny until this rule exists.

Side C — Prove which line ran

  1. ZIA web log shows the SaaS transaction

    Analytics → Web Insights (or Insights → Logs). Filter user user@lab.example, URL of the SaaS. You want action=allowed, an SSL decision, and the rule name. https://ip.zscaler.com should name the same cloud and Location you designed.

  2. ZPA access decision + connector health

    Diagnostics / user activity for user@lab.example to CRM-Prod. Quote policy name, posture, Connector group, and server 10.50.8.20:443. Enabled segment without this quote is not a close.

  3. Do not stop at “protected”

    Client Connector “protected” is intended path, not proof that this URL was inspected or this CRM was brokered. The transaction is the last sentence.

Dummy lab · same shape as /interview/zscaler#simulator 
ZSC-LAB > show zte session user@lab.example
arrival: Z-Tunnel 2.0
service_edge: DEL2
zia: saas.example.test action=allowed ssl=inspected rule=Finance-SaaS
zpa: crm.internal.example policy=Finance-CRM-Allow connector=DC1-Connectors
location: user=user@lab.example  (not empty)

ZSC-LAB > show zia forwarding
user: user@lab.example
forwarding: Z-Tunnel 2.0
service edge: DEL2
status: protected
note: protected ≠ transaction
Do not ship with these mistakes

6. Runtime path after go-live

After Activate (ZIA) or Save (ZPA), the Central Authority is off the wire. Client Connector or the branch tunnel carries the session to the nearest legal Service Edge. Destination class splits the factory. The destination never sees the laptop’s private IP on the ZIA line — it sees a Zscaler egress. On the ZPA line the App Connector, not the user, reaches the server.

Proof cockpit · quote the transaction
Operations desk verifying ZIA and ZPA session proof
Green on the wall is not the close. Quote the ZIA web-log row or the ZPA access decision + connector.
Flow 3 · runtime after go-live
Two destinations, one arrival, CA already off-path Browser / ZCC Z-Tunnel 2.0 ZTE Service Edge ZIA PSE · inspect SaaS / web ZPA · broker App Connector 1 ZCC or GRE/PAC/Branch hands the flow to the nearest legal Service Edge 2 Edge matches Location or user. CA already pushed the activated policy — it is not inline 3 Internet FQDN → ZIA inspects (SSL + SSMA) and egresses. Private FQDN → ZPA brokers to an App Connector 4 ZIA Nanolog and ZPA user activity are copies. They do not grant the session Loop trap: IdP or ACS forced through ZIA before the user is authorized Fix on the authentication lesson: exemptions + PAC DIRECT for login hosts — then re-test the pilot

Same identity, two exits. The ZPA edge brokers; it does not inspect like the ZIA edge. Official Help, Understanding Service Edges.

7. Traps + proof

SymptomLikely causeFirst check
Unauthenticated / empty userTunnel down, PAC miss, or location-only policyip.zscaler.com + Client Connector status — not a new IdP
Allow screenshot, browser still failsInspect/pin, path, or you quoted policy not the transactionName the line, then the exact ZIA or ZPA row
CRM unavailable, segment greenNo Access Policy, bad posture, dead connectorPolicy decision + connector + server:443
URL filter “does not see” CRMYou are on the ZIA line for a private FQDNDestination class → ZPA, not another URL allow
Office works, home failsOn-Trusted vs Off-Trusted forwarding, or unknown location refusedForwarding Profile states + Location auth setting
Policy you saved does nothingZIA still PENDING, or you edited the wrong cloudActivation → Activate; confirm admin.<your-cloud>
Protected on ZCC, no log rowYou stopped at arrivalProtected ≠ transaction. Find the web log or ZPA access event
Proof the change worked
Interview close

I name the factory line first — ZIA inspect or ZPA broker — then forwarding, then who is on the ticket, then the exact transaction. Allow is never the last sentence. Night-shift commands live on the evidence desk.

Knowledge check

Six judgment questions. Map each to the factory path, a line choice, or a trap. Check + Reset.

Q1

A ticket says “Zscaler allowed it” but the browser still fails. What is the first sentence you owe?

Correct: b. Allow is a policy decision, not browser success. Re-read Quick Answer and Why the factory matters.
Q2

Users open crm.internal.example. L1 adds a ZIA URL allow. The app stays unavailable. Which factory line should own this?

Correct: c. Destination class picks the line. A ZIA URL allow does not grant a private app. Re-read Decision flow and How to choose.
Q3

Official Help contrasts the two Service Edges. Which statement is true?

Correct: a. Understanding Service Edges. ZPA brokers; ZIA inspects. They run on separate clouds. Re-read Mental model.
Q4

Home user, ticket says unauthenticated. Client Connector shows the tunnel down. First move?

Correct: b. If forwarding is down, neither line prints a transaction. Re-read Side A and Traps.
Q5

L1 screenshots Application Segment = Enabled. Users still get application unavailable. What is missing from that screenshot?

Correct: d. ZPA default deny until Access Policy allows. Re-read Side B and Traps.
Q6

A colleague draws the Central Authority on the live user path between the laptop and SaaS. What do you correct?

Correct: a. CA is the write plane. The Public Service Edge is the run plane. Re-read Mental model and Runtime.

Sources

Related: Blog 2 · Zscaler evidence desk · ZIA authentication (SAML + SCIM) · ZIA architecture — every hop · Traffic forwarding · ZPA architecture · ZIA traffic flow · Zscaler practice dashboard