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

Source: https://ai.techclick.in/blog_zscaler_exchange_factory
Markdown: https://ai.techclick.in/blog_zscaler_exchange_factory.md
Publisher: Techclick Infosec Pvt Ltd

Walk the Zscaler factory: user/device → Zero Trust Exchange → ZIA inspect or ZPA broker. Decision flow, Side A/B/C, and a scored quiz.

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

   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.

- Arrival — Client Connector (Z-Tunnel), GRE/IPSec, PAC, or Branch Connector hands the flow to a Service Edge.

- Factory — the Service Edge identifies the user or location, loads the activated policy the Central Authority already pushed, and classifies the destination.

- 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

   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

       User or device arrives at the Zero Trust Exchange, then ZIA inspects internet or ZPA brokers a private app

- 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 Term Meaning 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.0 DTLS or TLS tunnel from Client Connector to the Service Edge. Carries all ports and protocols. Tunnel down = factory never saw the flow. App Connector VM next to the private app. Outbound-only to the ZPA Service Edge. No inbound VIP on the app. Closest healthy connector wins. Application Segment ZPA object: FQDN + port + server group. Enabled is the object. It is not the allow. Access Policy ZPA allow/deny for user, group, posture, Connector group. Default is block until a rule allows. Location ZIA named source (public IP, GRE/IPSec, dedicated port). Known location can run place-only policy. Unknown / Road Warrior must authenticate or is refused. Nanolog ZIA 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 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 with forwarding, then destination class, then ZIA inspect or ZPA broker 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.” Situation Prefer Do not Internet / SaaS — URL, SSL inspect, DLP, cloud-app ZIA Public Service Edge + named user or known Location Hide a private app behind a ZIA allow Internal FQDN, no inbound VIP, least privilege ZPA Application Segment + Access Policy + App Connector group Treat Enabled as an allow Roaming laptop, all ports/protocols Client Connector Tunnel (Z-Tunnel 2.0) to the nearest Service Edge Assume PAC-only still covers non-web Known office, many users, internet breakout GRE or IPSec to a ZIA Public Service Edge, bound to a Location Quote the tunnel without a Location match Branch / IoT / no Client Connector Branch Connector forwards the flow to the ZTE , then ZIA or ZPA by destination Stop at the classify rule — you still need the ZIA or ZPA transaction Need residency or a dedicated inspect edge ZIA subcloud, or Private / Virtual Service Edge for Internet & SaaS Assume “Private Service Edge” means ZPA One user slow, peers fine Prove the factory line first, then ZDX score / Cloud Path Open 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 #### 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.

- #### 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.

- #### 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

          Name  Lab-Tunnel-2

          Off-Trusted Network  Tunnel (Z-Tunnel 2.0)

          On-Trusted Network  Tunnel (Z-Tunnel 2.0)

          VPN-Trusted Network  None

        Action  Forward all ports and protocols to the nearest Service Edge

        Cancel  Save

    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

- #### 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.

- #### 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.

- #### 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

          Rule name  Finance-CRM-Allow

          Action  Allow Access

        Application Segment / Segment Group  CRM-Prod · Finance-Private

          Users / groups  Finance

          Client Connector posture  Managed

        App Connector Group  DC1-Connectors

        Cancel  Save

    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

- #### 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.

- #### 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.

- #### 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

- Rebuilding SAML because Z-Tunnel is down.

- Adding a ZIA URL allow for crm.internal.example .

- ZPA Application Segment Enabled, Access Policy never written.

- Treating the ZIA and ZPA Service Edges as the same inspect engine.

- Quoting Client Connector “protected” as proof the app answered.

## 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

   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

       Runtime path: Client Connector to Service Edge, then ZIA inspect or ZPA App Connector

- 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 Symptom Likely cause First check Unauthenticated / empty user Tunnel down, PAC miss, or location-only policy ip.zscaler.com + Client Connector status — not a new IdP Allow screenshot, browser still fails Inspect/pin, path, or you quoted policy not the transaction Name the line, then the exact ZIA or ZPA row CRM unavailable, segment green No Access Policy, bad posture, dead connector Policy decision + connector + server:443 URL filter “does not see” CRM You are on the ZIA line for a private FQDN Destination class → ZPA, not another URL allow Office works, home fails On-Trusted vs Off-Trusted forwarding, or unknown location refused Forwarding Profile states + Location auth setting Policy you saved does nothing ZIA still PENDING, or you edited the wrong cloud Activation → Activate; confirm admin.  Protected on ZCC, no log row You stopped at arrival Protected ≠ transaction. Find the web log or ZPA access event Proof the change worked https://ip.zscaler.com names your cloud and the Location (or Road Warrior) you designed.

- Client Connector shows Internet & SaaS and Private Access connected — then you still quote a transaction.

- SaaS: ZIA web log with user or Location, action, SSL decision, rule name, bytes.

- CRM: ZPA Access Policy allow + healthy App Connector + server reachable.

- ZIA policy you care about is ACTIVE , not PENDING.

- A hotspot test (unknown location) still reaches the exchange if that is the design.

   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?

           Add a second allow for the same URL
           Name the factory line, then forwarding, then who is on the ticket, then the exact transaction
           Force re-auth for the whole org
           Disable SSL inspection tenant-wide

       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?

           ZIA Public Service Edge — it inspects every FQDN
           Nanolog — logs grant access
           ZPA — private FQDN, no inbound VIP; segment + Access Policy + App Connector
           Central Authority — put the CA on the data path

       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?

           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 share one inspect engine on the same multi-tenant fabric
           The Central Authority decrypts TLS on both lines
           App Connectors accept inbound VIPs from the internet

       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?

           Create a second SAML IdP
           Treat it as an arrival incident — the factory never saw a flow until Z-Tunnel / GRE / PAC is up
           Enable the CRM Application Segment
           Activate a pending URL rule

       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?

           A ZIA URL category allow
           Nanolog cluster health
           A GRE tunnel to the ZIA Public Service Edge
           Access Policy + posture + connector/server proof — Enabled is the object, not the allow

       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?

           The CA writes policy, config, and feeds to the edges — it does not inspect the session
           The CA is the ZIA Public Service Edge
           The CA is the App Connector
           The CA must be inline or SSL Inspection cannot run

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

       Check answers
       Reset

## Sources

- Zscaler Help — What is Zscaler Internet & SaaS? (part of the Zero Trust Exchange; traffic routed to the nearest Public Service Edge)

- Zscaler Help — Understanding the Zscaler Cloud Architecture for Internet & SaaS (Central Authority, Public Service Edges, Nanolog)

- Zscaler Help — Understanding Public Service Edges for Internet & SaaS (full-featured secure internet gateway; bidirectional inspect)

- Zscaler Help — Understanding Policy Enforcement (SSMA on the ZIA Public Service Edge)

- Zscaler Help — Choosing Traffic Forwarding Methods

- Zscaler Help — Configuring Forwarding Profiles for Zscaler Client Connector (Infrastructure → Connectors → Client → Forwarding Profile for Platforms)

- Zscaler Help — About Z-Tunnel 1.0 & Z-Tunnel 2.0 (DTLS/TLS; all ports and protocols)

- Zscaler Help — What Is Zscaler Private Access?

- Zscaler Help — Understanding the Private Access Architecture (CA as brain of ZTE; Z-Tunnel; separate multi-tenant fabric from ZIA)

- Zscaler Help — Understanding Service Edges (ZIA inspects; ZPA does not inspect as traffic flows through)

- Zscaler Help — About App Connectors

- Zscaler Help — Configuring Access Policies

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

---
Cite this Techclick lesson with the source URL. Do not invent fees, batch dates, or job guarantees.
Browse all lessons: https://ai.techclick.in/blogs
AI index: https://ai.techclick.in/llms.txt