Skip to main content
CID222 Docs

Zscaler Internet Access

Connect a cloud-delivered Zscaler tenant to CID222 over a public endpoint, a service connector or a tunnel, and admit its egress ranges.

  • Version: 0.4
  • Feature: icap
  • Role: admin_user
  • Type: task

Zscaler is cloud-delivered, which inverts the usual network model: the inspection service does not sit beside the gateway on a network you control — Zscaler's cloud dials out to your appliance. That decides everything about how you expose CID222 and how you authenticate the caller.

What do I need?

Licence
Any
Role
admin_user

Prerequisites

  • A Zscaler Internet Access tenant with the web-security tier and administrative access to its console.
  • A decision on how the cloud reaches the appliance: a public name, a Zscaler service connector inside your network, or a site-to-site tunnel.
  • For the public option, a gateway API key issued on the appliance, and a certificate on the appliance's HTTPS front.
  • Zscaler's published egress ranges for your data centres.
  • Saving the appliance-wide inspection policy requires the superadmin account.

Warning

Written from Zscaler's own documentation and the CID222 inspection contract. Not verified against a live Zscaler tenant. Console paths are a guide to the right screen, not a transcript.

Choose how the cloud reaches the appliance

The appliance has a stable public name and Zscaler dials its HTTP inspection endpoint at POST /inspect/v1/<hostname> over HTTPS.

A keyless call through the public edge is refused. Zscaler must present a gateway API key as a bearer token; the appliance's edge stamps every request that arrives through it, so network position cannot substitute for the key.

For an additional constraint, have the appliance's HTTPS front verify a client certificate and forward its subject name, then set mTLS client subject DN on the inspection policy. Set up the front first: once a subject name is configured, every caller of the inspection endpoint must present a matching one, the browser extension included.

Configure the tenant

Add CID222 as an inspection server

In the console's data-loss-prevention resources, add a server pointing at the address you chose above — the HTTPS endpoint for the public option, icap://<address>:1344/inspect for the connector or tunnel — and raise the connection limit, because a cloud tenant can ramp connection counts quickly.

Bind it to the AI category

In the web data-loss-prevention policy, add a rule matching Zscaler's centrally maintained AI category with the action of sending the request to that server.

Verify the category holds the hostnames you care about, and extend it with a custom category where it does not.

Admit Zscaler's egress ranges

Select Detection & Filtering → Browser Inspection and add the egress ranges for your data centres to Allowed ICAP peer IPs / CIDRs. Select Save policy.

The panel reports Inspection policy updated. Adding a public range this way removes the private-range default, so list every on-premises peer and test host in the same edit or they stop being admitted.

Size the timeout for a round trip to the cloud

Lower Inspection timeout (ms) so a verdict returns inside the budget a cloud round trip leaves you, and match the tenant's failure action to Fail closed (BLOCK) on timeout.

Inspection is synchronous and runs no background work, so the timeout is a hard ceiling on the whole check rather than a target.

Verify

  1. From a workstation whose traffic the tenant forwards, send a prompt containing a test identifier. The model receives it masked, or the browser shows a block page.
  2. Select Detection & Filtering → All Detections and filter to browser traffic. The attempt appears as MESSAGE_MASKED or MESSAGE_BLOCKED, carrying the identity Zscaler forwarded from your identity provider.
  3. On Browser Inspection, the tenant appears in the connected-sources table.

If it fails

  • The tenant reports the server unreachable and the appliance logs nothing → the call is not arriving. Check name resolution and the certificate on the appliance's HTTPS front before anything else.
  • The appliance answers with an authorisation failure → the call carries no gateway API key, or a subject name is configured on the policy and the front is not forwarding one.
  • Refusals appear in the log naming a public address → that range is not on the peer list.
  • Requests time out under load → the connection limit or the inspection timeout is too tight for the round trip.

Next steps

Last updated on

On this page