ZIA scenarios symptom then Web Insights

Lessons · Zscaler series · ZIA scenarios

Hero · the user talks to a browser; you talk to Insights

Why a symptom is not a policy

The day-one ticket is always the same: “The site is blocked, so URL filtering is wrong.” Wrong. A timeout, a certificate warning, a Zscaler block page, a SAML loop and “it works at home” are five different desks. Editing URL Filtering because Priya saw a padlock error wastes the change window and still leaves the CA undeployed.

Three silent-zero states look identical from the chair (site will not load):

• PAC returned DIRECT — no Service Edge, no Web Insights row, no policy to edit.
• GRE/IPSec down — office source IP is not the location object; traffic is Road Warrior or raw ISP.
• User field is the location name (NoAuth) — group-based URL rules never evaluated.

Five desks, one request

Treat ZIA as five objects that fire in order. Skip a desk and you “fix” the wrong one.

Path · symptom, forwarding, identity, policy reason

Symptom → Web Insights

Existing session first only in your head: write the six-tuple before you open Admin. Then filter Insights to that tuple. Empty result is a forwarding ticket, not a missing allow.

Which ticket is this

Keep these five. They are the unique ZIA interviews. DLP, QUIC, DNS and sandbox are the same method on a different Insights family — do not start there.

Runbook Side A / B / C

Side A is the symptom tuple. Side B is Insights. Side C is one scoped change. Do not start at C.

Side A — write the tuple before Admin

1. Six fields, one screenshot

   User, device OS, office vs home, URL (full), timestamp, exact error (block page vs cert vs timeout vs SAML). Lab: priya@apexfreight.example, Win11, APEX-BLR, https://portal.vendorsaas.example/invoices, 10:14 IST, Zscaler block page. Source: ZIA Traffic Forwarding Troubleshooting Runbook — collect before you filter.

2. Name the forwarding guess

   Office desk with GRE: expect Traffic Forwarding = GRE and Location = APEX-BLR-WAN. WFH ZCC: Zscaler Client Connector, Road Warrior. Browser PAC only: PAC File. If you cannot name it, you are not ready for a policy edit.

user:     priya@apexfreight.example
url:      https://portal.vendorsaas.example/invoices
when:     2026-09-05 10:14 IST
error:    Zscaler block page (not a cert warning)
fwd:      office GRE 203.0.113.10 → APEX-BLR-WAN
expect:   URL allow for Professional Services, this host only
proof:    Web Insights row + Policy Reason before/after

Side B — one Insights row

1. Empty table = stop

   Widen time ±10 min. Drop User filter (auth miss). Still empty: PAC/ZCC/GRE. Open Tunnel Insights for GRE/IPSec. Do not create a URL allow for a request ZIA never saw.

2. Read SSL before URL

   Cert warning + SSL Inspected = Yes → CA/trust ticket. SSL Policy Reason = Not inspected because of SSL policy → a Do Not Inspect rule already won; URL path is hostname-only. O365 / UCaaS / Zscaler best practices are designed bypasses — do not “fix” them with decrypt.

3. Read Policy Reason as a string

   Not allowed to browse this category is URL Filtering. Access denied due to bad server certificate is SSL. Cloud App Control block means URL Filtering was not evaluated. Source: Policy Reasons.

Side C — five scoped fixes

Change the desk the row named. Activate. Retest Priya, same URL, same path. Save the new Insights row.

SSL — inspect CA, not decrypt-off

Deploy the Zscaler intermediate/root used for inspection to Windows/macOS/mobile via GPO/MDM. Firefox: its own cert store. Pinned SaaS: Policy › SSL Inspection → Do Not Inspect for that application/URL category, not a global off. Show Notifications on a block rule forces decrypt to paint the EUN — that is why a “Do Not Inspect” still shows Inspected. Source: About SSL Inspection; SSL Policy Reason runbook; Inspected despite Do Not Inspect.

URL — custom host, not allow-all

Policy › URL & Cloud App Control. If Professional Services is blocked on purpose, add portal.vendorsaas.example to a custom URL category and allow that category for Priya’s group above the block. Do not open the super-category for the org. Confirm Cloud App Control did not already block. Source: URL Filtering; Block policy configured but access gets allowed.

PAC — DIRECT for IdP and RFC1918

function FindProxyForURL(url, host) {
  if (isPlainHostName(host) ||
      shExpMatch(host, "*.apexfreight.example") ||
      isInNet(dnsResolve(host), "10.0.0.0", "255.0.0.0") ||
      shExpMatch(host, "login.microsoftonline.com") ||
      shExpMatch(host, "*.login.microsoftonline.com"))
    return "DIRECT";
  return "PROXY ${GATEWAY}:80; PROXY ${SECONDARY_GATEWAY}:80; DIRECT";
}

Use ${GATEWAY} / ${SECONDARY_GATEWAY}, not a static Public Service Edge VIP (System Audit flags static PAC IPs). Port 80 is the usual explicit proxy; 9400 if something intercepts 80/443 on the path; 9443 for remote HTTPS inspect; 9480 from unknown locations still forces auth. Keep the file small (audit warns > 25 KB). Source: Writing a PAC File.

GRE / IPSec — location IP, then tunnel health

Administration › Locations: APEX-BLR-WAN static IP 203.0.113.10, failover 203.0.113.11. Logs › Insights › Tunnel Insights: Tunnel Type GRE or IPSec IKEv1/IKEv2, Location, Tunnel Source IP, status. If Web Location = Road Warrior from that public IP, the location object does not own the source — not a URL bug. Source: Tunnel Insights Logs columns; Traffic Forwarding runbook (Client External IP vs GRE).

Auth — exempt the IdP, do not disable Enforce Authentication

One request after go-live

Priya on LAN. GRE 203.0.113.10 up. Browser PAC not in play (or PAC over GRE). GET https://portal.vendorsaas.example/invoices. Service Edge sees location APEX-BLR-WAN, SAML cookie maps User to priya@apexfreight.example, group Finance. SSL Inspection rule Inspect → SSL Inspected Yes, SSL Policy Reason Inspected. URL Filtering rule URL_Block_Productivity matches Professional Services → Policy Action Blocked, Policy Reason Not allowed to browse this category. Web Insights row exists within minutes. You add a custom category allow for that host, activate, she retries. New row: Allowed, same User/Location/Forwarding. Ticket closed.

Home laptop, ZCC Z-Tunnel 2.0: Location Road Warrior, Traffic Forwarding = Zscaler Client Connector. Same URL rule still applies if it is user/group based. If the office GRE is down, the same laptop in Bengaluru also shows Road Warrior — that is the GRE ticket, not a new URL exception.

Proof · the close is a second Insights row, not a Slack thumbs-up

before: Blocked | Not allowed to browse this category | URL_Block_Productivity
        SSL Inspected=Yes | SSL Policy Reason=Inspected
        Location=APEX-BLR-WAN | Forwarding=GRE | User=priya@…
after:  Allowed | URL_Allow_VendorPortal (custom category, host only)
        same User / Location / Forwarding / SSL Inspected
rollback: disable URL_Allow_VendorPortal, activate

Traps + proof

Sources

• Zscaler Help — About Insights Logs (Logs › Insights Logs; Web / Firewall / DNS / Tunnel)
• Zscaler Help — Web Insights Logs: Columns (User, URL Category, Policy Action, SSL Inspected, SSL Policy Reason)
• Zscaler Help — Policy Reasons (e.g. Not allowed to browse this category; Access denied due to bad server certificate)
• Zscaler Help — SSL Policy Reason Runbook (Inspected; Not inspected because of SSL policy / O365 / UCaaS / Zscaler best practices)
• Zscaler Help — About SSL Inspection
• Zscaler Help — Writing a PAC File (${GATEWAY}, ports 80/9400/9443/9480, INTERNAL DIRECT)
• Zscaler Help — ZIA Traffic Forwarding Troubleshooting Runbook (Web Insights Traffic Forwarding; GRE Client External IP; IdP 307 loop)
• Zscaler Help — Tunnel Insights Logs: Columns (Tunnel Type GRE / IPSec IKEv1 / IKEv2; Location; source IP)
• Zscaler Help — Block Policy Configured but Access Gets Allowed (Cloud App Control ends evaluation; NoAuth / location in User field)

Related: Authentication · SSL inspection · GRE & IPSec · URL + Cloud App Control · ZIA command center · ZCC troubleshooting