# ZIA architecture — every hop from device to internet Source: https://ai.techclick.in/blog_zscaler_b11_02_zia_architecture Markdown: https://ai.techclick.in/blog_zscaler_b11_02_zia_architecture.md Publisher: Techclick Infosec Pvt Ltd Walk every ZIA hop: user → forwarding → Public Service Edge → SSL and SSMA engines → internet. Name Central Authority, Nanolog, Log Routers, Feed Central, and subclouds — then prove Location + Activate. Quick answer (say this out loud) The Central Authority (CA) is the control plane: policy, config, software, threat feeds. It is not on the live data path. The Public Service Edge (PSE) is the data plane: it identifies the Location or user, decrypts if SSL Inspection says so, runs Single-Scan, Multi-Action (SSMA) , then opens its own connection to the destination. A compressed log copy leaves over TLS to a Log Router , then a Nanolog cluster. A subcloud is a named subset of PSEs — use it when residency says “only these edges.” Saved Admin changes stay PENDING until Activation → Activate . ## 1. Why the hop map matters Lesson 1 placed Zscaler on the map. This page opens the box. Every “YouTube should be blocked” ticket is the same sentence: is the right activated policy on the Service Edge that actually received this user? If you put the CA on the wire, you will reboot laptops while a staged URL rule sits unactivated. If you treat Nanolog as enforcement, you will chase a logging gap while the user is already on the internet. If you ignore Location, an ISP swap turns the branch into an unknown / Road Warrior source with the default bundle. Hero · who talks to whom Notice: the user never opens a socket to github.com. The Service Edge does. The CA is off this picture on purpose. Interview line ZIA is a full proxy, not a router with an ACL. The client’s next hop is a Service Edge selected by forwarding + geo-IP (and any subcloud). The destination sees a Zscaler egress IP, not the laptop. ## 2. Mental model — three planes Official Help names three cloud components: Central Authority , Public Service Edges for Internet & SaaS , and Nanolog clusters . Everything else either feeds those planes or constrains which edge you may land on. Feel · three planes Caption in words, not in the art: write-plane (CA), run-plane (PSE), log-plane (Log Router → Nanolog). Traffic stays on the middle layer. #### Central Authority — write plane Brain and nervous system of the cloud. Holds policy, config, software updates, and threat intel. One active node plus two passive standbys in separate sites. Accepts Admin / API writes. Never inspects the user session. #### Public Service Edge — run plane Full-featured secure internet gateway in a Zscaler data center. Identifies Location or user, runs SSL Inspection + SSMA, egresses to the destination. Customer traffic stays on the edge — it is not forwarded to the CA or Nanolog. Nothing written to disk on the edge. #### Nanolog — log plane Stores compressed, tokenized transaction logs and serves Insights / reports. Topology mirrors the ZIA CA: one active + two standbys. NSS / Cloud NSS streams from here to your SIEM. A Nanolog outage does not stop enforcement. #### Log Router + Feed Central Log Routers take the TLS log export from the edge and land it on the Nanolog for that tenant’s geography. Feed Central is a separate Zscaler cloud: intel and URL classification → each cloud’s CA → every Service Edge. Classroom decks that say “SMC” for the reporting cluster map here — official Help name is Nanolog (store) and Log Router (hop). Flow 1 · mental model — write / run / log ZIA three planes: Central Authority writes, Public Service Edge runs, Nanolog records - The CA pushes policy. The PSE inspects. Nanolog is a copy, not a hop. Central Authority policy · config · feeds · Activate User / device browser · app · ZCC Forwarding ZCC · PAC · GRE · IPSec Public Service Edge SSL + SSMA in one pass Location / user match Internet / SaaS PSE opens the socket push (not inline) Log Router → Nanolog cluster async TLS copy · Insights / NSS · not in the allow path Solid arrows = user session. Dashed arrows = control or log. If you draw the CA or Nanolog on the solid line, the interview is already lost. Say this out loud The CA writes. The Public Service Edge runs. Nanolog records. A subcloud only changes which edges are legal — it does not inspect a packet. ### Hard words before the hop list Term Meaning on a ticket Zscaler cloud Your org is provisioned on one production cloud: zscaler.net , zscalerone.net , zscalertwo.net , zscalerthree.net , or zscloud.net . Admin is admin. . There is no tenant-level failover to a different numbered cloud. SSMA Single-Scan, Multi-Action. Packets sit in shared memory on the PSE. Dedicated CPUs for URL, malware, DLP, firewall, IPS, CASB, sandbox run at once — not a chain of appliances. Subcloud A named subset of Public Service Edges. Constrains where ZCC / PAC / geo-IP may land (residency, a bad DC, a beta ring). PAC form: gateway. . . Location Named source the PSE can match — typically a public IP, GRE/IPSec tunnel, or ZCC-enrolled roaming user. Wrong IP → unknown / Road Warrior policy. Sub-Location Internal IP (or XFF) range inside a Location, usually inside a GRE/IPSec tunnel. Guest Wi-Fi vs LAN behind one public IP. Ranges inside one Location must not overlap. Activate ZIA writes are staged ( PENDING ) until Activation → Activate ( ACTIVE / INPROGRESS ). ZPA has no equivalent step. Log Router Official hop from the Service Edge log export to the regional Nanolog. If a classroom slide says SMC for “the reporting cluster,” map it here + Nanolog — do not invent a fourth enforcement plane. Feed Central Separate Zscaler cloud. Threat intel and URL classes go Feed Central → CA → Service Edges. Stale feeds ≠ dropped sessions. MCLS Multi-Cluster Load Sharing. Several clusters can sit behind one VIP so Zscaler adds capacity without you rebuilding GRE. Published at config.zscaler.com/ /cenr . ## 3. Every hop — flowchart first Do not start the whiteboard in the Admin sidebar. Start with the click. The CA already pushed an activated policy bundle to the edges. The click only meets the edge that forwarding selected. Path · device → inspect → egress → log Feel the order: Device, Forward, Inspect, Egress, Log. Policy was already on the edge. The log copy is last and optional for the user’s success. Flow 2 · hop diagram (flowchart first) ZIA hop path from user request through forwarding, PSE SSL and SSMA, internet egress, and async Nanolog Mumbai laptop opens github.com — CA is already off-path 1 · Device browser / app 2 · Forward ZCC / PAC / GRE 3 · Select PSE geo-IP + subcloud 4 · Identify Location / user 5 · SSL inspect? Decrypt? SSL policy Tunnel only still SSMA on metadata NO 6 · SSMA engines URL · malware · DLP · FW · IPS · CASB YES Allow? activated policy Block / isolate user sees Zscaler page 7 · PSE egresses to destination own outbound TCP · re-encrypts response to client 8 · Async: compressed log → Log Router → Nanolog → Web Insights / NSS. Not on the allow path. Diamond = decision. Wrong Location is decided at hop 4. Forgot-Activate dies at hop 6 with the old bundle. Nanolog never sits between 6 and 7. On a managed laptop the usual hop list is: Device — Chrome (or any app) requests github.com . - Forwarding — Zscaler Client Connector (Z-Tunnel 1.0 or 2.0), a PAC file, GRE, or IPSec sends the session toward ZIA. Lesson 3 is the method choice; this page only needs “traffic left the laptop toward a Service Edge.” - Edge selection — advanced geo-IP aims at the nearest healthy Public Service Edge. A subcloud (if attached) shrinks that set. Private / Virtual Service Edges are the same software, different host. - Identify — the PSE matches source IP / tunnel / ZCC enrollment to a Location or Sub-Location, then the user if authentication is required. - SSL/TLS Inspection — if policy says inspect, the edge presents the Zscaler (or custom) intermediate CA and a short-lived server cert. Bypass still leaves metadata for later engines. - SSMA — one parse, many engines, the activated policy bundle. - Egress — on allow, the PSE opens its connection to the destination. The laptop never owns that socket. - Log — a compressed, tokenized copy goes TLS to a Log Router, then Nanolog. Web Insights and NSS read Nanolog. This hop can lag or fail while the user is already reading the page. Unsafe path Drawing Chrome → CA → GitHub or Chrome → Nanolog → PSE . The CA pushed earlier. Nanolog is a copy. Putting either inline is how juniors “reboot the CA” on a policy ticket. ## 4. How to choose the edge Most tenants only ever use Public Service Edges. Reach for the other rows when residency, an air-gap, or a region with no nearby public DC is the actual constraint — not because “private sounds safer.” If this is true Choose Do not choose Default internet / SaaS inspection. Users should follow geo-IP to the nearest Zscaler DC. Public Service Edge — Zscaler-hosted, multi-tenant, same software everywhere. A Private box “just in case.” Extra subscription, extra ops, no extra engines. German (or other) traffic must be inspected only in a listed set of public DCs. Rest of the company can land anywhere. Subcloud attached to that Location (or Department, if the tenant still offers it). Ask Zscaler to provision the subset if it is not already there. A second tenant, or a Private Service Edge, unless the auditor forbids any public DC. User traffic must not leave the building, but you still want ZIA engines and the same CA policy. Private Service Edge — hardware form factor Zscaler uses in its own DCs, customer-hosted, single-tenant. Policy still comes from the CA. Public PSE (leaves the premises). App Connector (that is ZPA). Same local-inspection idea, but you want a VM in VMware / AWS / Azure / GCP. Virtual Service Edge . Forward with GRE or ZCC. Official constraint: VSE does not terminate IPSec . IPSec into that VSE. Build GRE or send users through Client Connector instead. You need more GRE capacity on an existing VIP, not a new destination. Stay on the VIP. MCLS lets Zscaler add clusters behind it. Check config.zscaler.com/<cloud>/cenr . Rebuilding every GRE peer because “the DC is full.” The whole numbered cloud is unreachable and you bought Business Continuity. Business Continuity Cloud (Private Policy Cache + Private PAC). Supports Z-Tunnel 1.0, PAC, GRE. Z-Tunnel 2.0 is not supported in BC mode — clients fall back to 1.0. Treating BC Cloud as “Z-Tunnel 2.0 continues.” That is a different outage story. Primary source Form factors and “traffic never leaves the Service Edge”: Understanding the Zscaler Cloud Architecture and Understanding Public Service Edges for Internet & SaaS . Subcloud: Understanding Subclouds . VSE / IPSec: Traffic Forwarding in ZIA reference architecture. ## 5. Runbook Side A → B → C Architecture is useless if you cannot make the PSE name the branch. Side A is evidence. Side B is the object. Side C is Activate + proof. Primary source for the clicks: Configuring Locations and Configuring Sublocations . ### Side A — identify the source (before you click Add) - #### Get the public IP the PSE will see From a machine on the branch, open https://ip.zscaler.com . Record Cloud, Service Edge, current Location, and the public IP. If Location already says the right name, stop — this is not a Location ticket. - #### Decide how traffic arrives GRE or IPSec: the Location binds to that tunnel (and you can carve Sub-Locations from inner IPs). PAC or explicit proxy: the public IP of the egress. ZCC roaming: there is no stable public IP — do not invent one; identity is the enrolled user, not a /32. - #### List the inner ranges that need different policy Example: employees 192.168.0.0/16 , guest Wi-Fi 10.20.30.0/24 , both behind 203.0.113.10 . That is one Location and two Sub-Locations — not two Locations with the same public IP. ### Side B — ZIA objects (Location, then Sub-Location) Official path (current Help): Infrastructure → Locations → Location Management → Legacy Locations → Add Location . Some tenants still show an older Administration tree. Trust the breadcrumb that ends in Add Location . https://admin.zscaler.net · Infrastructure → Locations → Location Management → Legacy Locations Training mock · not live Infrastructure / Locations / Location Management / Legacy Locations / Add Location ### Add Location Name Mumbai-HQ Country India Time Zone Asia/Kolkata IP Addresses 203.0.113.10 Authentication Required Enabled X-Forwarded-For (XFF) Forwarding Enabled Subcloud None — use any Public Service Edge in this cloud Cancel Save Next: Save, then do not close the laptop. The red badge on Activation is the real commit. Source: Configuring Locations . IP is RFC 5737 documentation space. - #### Add the Location Name, country, time zone, IP addresses (or the GRE/IPSec binding). Turn Authentication Required on if this site must identify users. Turn X-Forwarded-For (XFF) Forwarding on if downstream apps or an on-prem proxy must still see the client IP. Attach a subcloud only if this site is not allowed to use the full public edge set. - #### Add Sub-Locations for inner ranges Open the parent Location → Add Sub-Location . Give the guest SSID 10.20.30.0/24 its own URL / bandwidth rules. Do not overlap ranges inside the same parent — Help forbids it. - #### If this is an ISP swap, edit the existing Location Do not create a second Location with the new /32. Edit IP Addresses on Pune-HQ (or Mumbai-HQ) to the new public IP. Two Locations with one public IP collide on PSE lookup. ### Side C — Activate and prove https://admin.zscaler.net · Activation Training mock · not live Activation / Activate pending configuration ### Activate pending changes Status PENDING — 1 staged change (Location Mumbai-HQ) After Activate INPROGRESS → ACTIVE. Edges pull the new Location IP. Traffic is not queued behind other tenants. Review changes Activate Next: wait for status ACTIVE , then re-hit ip.zscaler.com from the branch. Source: Help Activation + partner guides “Go to Activation and click Activate.” Session-end can also auto-activate — do not rely on that in a change window. - #### Activation → Activate API surface if you automate: GET /status then POST /status/activate . Enum you will see: ACTIVE / PENDING / INPROGRESS . Saving a Location is not the same as edges enforcing it. - #### Prove on the user path https://ip.zscaler.com must show the Location name you just saved, the expected cloud, and a Service Edge that is inside any attached subcloud. Then Analytics → Web Insights (some tenants still say Insights): filter user + last 15 minutes. You want Location, policy action, and a username if auth is on. Pilot proof — what “green” looks like 1. ip.zscaler.com Cloud: zscalerthree.net (example — use YOUR cloud) Location: Mumbai-HQ (not Road Warrior / Unknown) Service Edge: a name inside the subcloud, if one is attached 2. Analytics → Web Insights User: ada@example.com Location: Mumbai-HQ URL: github.com Action: Allowed (or the rule you expected) SSL: Inspected | Not Inspected — matches Policy → SSL/TLS Inspection 3. Internal app / SIEM (if XFF is on) X-Forwarded-For includes the client (e.g. 10.20.30.45), not only the PSE egress ## 6. Runtime after Activate Once the Location is live, a weekday request does not walk the Admin tree. It walks the hop diagram. Keep this order in your head when the ticket says “it worked yesterday.” - Forwarding still delivers the session to a Service Edge (ZCC connected, GRE up, PAC not bypassed). - That edge is in the subcloud, if one is attached. A US user pinned to an EU-only subcloud will look “broken” even though ZIA is healthy. - Source IP still matches the Location. Sunday ISP swaps fail here first. - Activated policy is what SSMA evaluates — not the draft in your browser tab. - SSL Inspection still trusts the intermediate CA on the device. A new laptop without the cert is an SSL ticket, not an architecture ticket. - Nanolog / NSS can be minutes behind. Do not declare “ZIA dropped the session” because Insights is empty at T+30s. Policy follows the user: if Ada leaves Mumbai-HQ and ZCC lands her on another Public Service Edge, that edge downloads the right bundle from the CA. You do not “steer her back to the Mumbai node” to make policy work. ## 7. Traps + proof Ops · prove it before you close Close the ticket with ip.zscaler.com + a Web Insights row. A green VPN icon on the laptop is not evidence of the right Location. Symptom Likely miss First proof You saved a URL rule at 09:05. At 09:30 the old action still fires. Change is still PENDING . You never clicked Activation → Activate . Activation badge / GET /status . Then Insights after ACTIVE . ip.zscaler.com shows Location: Road Warrior after a circuit swap. Location IP Addresses still has yesterday’s /32. PSE cannot match the source. Compare the page’s public IP to the Location object. Edit, Activate, re-test. Guest Wi-Fi and LAN get the same URL policy behind one public IP. No Sub-Location (or overlapping inner ranges). You cannot create two Locations with that same public IP. Sub-Location list on the parent. Test from each VLAN; Insights Location field must split. German users land on a US Service Edge and the auditor is unhappy. No subcloud, or the subcloud is attached to the wrong Location. Edge name on ip.zscaler.com vs the subcloud’s allowed DC list (Help: Editing a Subcloud ). Internal Splunk shows one source IP — the PSE egress — for every employee. XFF Forwarding off on the Location. NSS will not fix app logs that never received the header. Enable XFF on the Location, Activate, confirm X-Forwarded-For on a test app. Insights empty, users say “internet works.” Log plane (Log Router / Nanolog / NSS), not the data plane. ip.zscaler.com still shows an edge + Location. Fix logging separately. Do not reboot ZCC. IPSec to a Virtual Service Edge never comes up. Documented constraint: VSE does not terminate IPSec . Rebuild as GRE or move those users to Client Connector. BC event: Z-Tunnel 2.0 users fail open or look different. Business Continuity Cloud supports Z-Tunnel 1.0, PAC, GRE — not 2.0. Confirm BC design assumed a 1.0 fallback before the outage. Pilot checklist - One branch user: ip.zscaler.com Location name matches the object you edited. - One guest-VLAN user: Insights shows the Sub-Location, not the parent only. - Activation status is ACTIVE , not PENDING . - If a subcloud is attached, the printed Service Edge is in that subset. - Web Insights row exists for the test URL with the expected action and (if auth is on) a username. - You did not put the CA or Nanolog on the live hop diagram when you explained it to the NOC. ## Knowledge check Six judgment items. Same tickets as the hop map. Check answers, read the reason, retry the weak ones. Q1 You edited a URL Filtering rule at 09:05. At 09:30 users still hit the old action. What do you check first? Whether the CA queued you behind other tenants on the cloud Whether Nanolog is ingesting, because policy cannot run without logs Whether Activation status is still PENDING — saved is not live Whether the user’s laptop needs a reboot so ZCC rereads the CA Correct: c . ZIA stages writes until Activation → Activate . Re-read the runbook Side C. Nanolog does not enforce. The CA push is per tenant after Activate — it is not a multi-tenant queue in the data path. Q2 A Pune user opens https://ip.zscaler.com and sees Location: Road Warrior instead of Pune-HQ. What is the most likely cause? The branch public IP changed and the Location IP field was not updated, so the PSE cannot match the source The subcloud is misconfigured, so Location lookup is skipped The SSL intermediate CA on that PSE does not match the Trust Store Nanolog has not indexed the session, so the diagnostic page cannot name the Location Correct: a . Location match is a PSE data-plane lookup on source / tunnel. Subclouds pick which edges are legal. SSL certs do not name Locations. Nanolog is not in the diagnostic path. Re-read traps. Q3 Mumbai-HQ has employees on 192.168.0.0/16 and guest Wi-Fi on 10.20.30.0/24 , both behind one public IP. You need different URL rules. What do you build? Two Locations that share the same public IP One Location on the public IP, then two Sub-Locations split by inner IP range A subcloud so guests land on a different Public Service Edge Two ZPA App Connectors, one per VLAN Correct: b . Sub-Locations exist to refine inside a GRE/IPSec (or XFF) Location. Two Locations cannot share one public IP. Subclouds constrain edges, not VLANs. App Connectors are ZPA. Re-read Side B. Q4 A Mumbai user opens github.com over Z-Tunnel 2.0. Which hop list is correct? Chrome → Central Authority (policy check) → Public Service Edge → GitHub Chrome → ZCC → nearest allowed PSE (identify + SSL + SSMA) → PSE opens GitHub → async log to Log Router / Nanolog Chrome → Nanolog (auth) → Public Service Edge → GitHub Chrome → ZCC → CA → Nanolog → GitHub Correct: b . CA pushed earlier; it is not inline. Nanolog is an async copy via the Log Router. Re-read the hop flowchart. Q5 A German subsidiary must be inspected only on EU Public Service Edges. The rest of the company can use any edge. What do you configure? A custom SSL Intermediate CA attached to the German Location A Virtual Service Edge in AWS eu-central-1 for those users only A subcloud limited to EU Public Service Edges, attached to the German Location (or Department) A second ZIA tenant so policy cannot leak Correct: c . That is what a subcloud is for. SSL CAs do not pick DCs. VSE / a second tenant is heavier than the requirement. Re-read How to choose. Q6 SOC cannot see Web Insights for the last ten minutes, but users are browsing. What is the strong read? The Public Service Edge is down — browsing is coming from a local cache The Central Authority failed, so the edge cannot allow anything; the reports are stale You must fail the tenant over to another numbered cloud (zscalerone → zscalertwo) Log plane (Log Router / Nanolog / NSS) can gap while the data plane keeps enforcing cached policy Correct: d . Official architecture: traffic stays on the Service Edge; logs are an export. There is no tenant-level failover to another numbered cloud. Re-read mental model + traps. Check answers Reset ## Sources - Understanding the Zscaler Cloud Architecture — CA, Public Service Edges, Nanolog, Feed Central, Log Routers, “traffic stays on the Service Edge.” - Understanding Public Service Edges for Internet & SaaS — data-plane role, geo-IP, policy follows the user. - Understanding Subclouds / About Subclouds — subset of PSEs, PAC gateway. . . - Configuring Locations — path Infrastructure → Locations → Location Management → Legacy Locations → Add Location ; XFF. - Configuring Sublocations / Understanding Sublocations — inner IPs in a tunnel; no overlap. - ZIA Policy Leading Practices — SSMA, shared memory, parallel engines. - Understanding Private Service Edge for Internet & SaaS and Private vs Virtual — hardware vs VM; VSE does not terminate IPSec. - Understanding Zscaler Cloud Names — ZIA production clouds. - Understanding Nanolog Streaming Service (NSS) — SIEM export from Nanolog. - Understanding Multi-Cluster Load Sharing — VIP capacity, config.zscaler.com/ /cenr . - Understanding Business Continuity Cloud Components — no Z-Tunnel 2.0 in BC mode. - Choosing the CA Certificate for SSL/TLS Inspection — intermediate CA on the PSE. - Activation: Help Activation API ( GET /status , POST /status/activate ) and partner guides “Go to Activation and click Activate.” Related: Batch 11 · Lesson 1 — foundation · Lesson 3 — traffic forwarding · Zscaler authentication · ZIA traffic flow · GRE & IPSec tunnels · ZPA architecture --- 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