Fail Closed, Private Addresses, and the Captive Portal
A healthcare group has 800 managed Windows laptops running Client Connector with a single forwarding profile: all traffic tunnelled to ZIA. Three problems surfaced in one week. At the main hospital, clinicians can no longer reach the on-premises EHR at 10.20.0.0/16, which worked before ZCC was enforced. At home, users on hotel and guest Wi-Fi cannot reach the captive portal sign-in page, so they have no internet at all - and the helpdesk has started telling them to disable ZCC to get online. Separately, executives report that Teams calls stutter, and the security team insists all traffic must keep going through ZIA. Imaging studies on the EHR routinely run to hundreds of megabytes.
1. Explain why the EHR broke and compare the two designs for fixing it, including which one you recommend for on-network versus off-network access.
Read the worked answer
Why it broke: ZIA is an internet proxy. A request to 10.20.0.0/16 is tunnelled to a Zscaler enforcement node, which has no route into the hospital LAN, so it fails. Nothing is misconfigured - the traffic is simply in the wrong place.
Option A - publish the EHR through ZPA. An application segment behind App Connectors in the hospital data centre. Identity-based, logged, no inbound exposure, works on and off network. Cost: hundreds-of-megabyte imaging flows go device → PoP → connector, which is slower than a direct LAN path and adds a dependency on the Zscaler cloud for a same-building app.
Option B - bypass at ZCC. Exclude the EHR FQDN (narrowly) or RFC1918 from tunnelling, ideally only when the device is on a trusted network identified by SSID, gateway or on-VPN detection. Direct LAN performance, but the traffic never touches ZIA - no inspection, no logging - and a broad RFC1918 bypass is easy to abuse.
Recommendation - combined: on the hospital trusted network, bypass ZPA/ZIA for the EHR so imaging goes direct over the LAN; off-network, use ZPA for identity-based access without exposing the app. Scope the bypass to the EHR FQDN and port rather than all of RFC1918, and document that these flows are outside inspection.
2. The captive portal problem is driving users to disable the agent. Fix it, and set out the fail-open versus fail-closed decision per user group.
Read the worked answer
Captive portal: ZCC brings the tunnel up before the device has network access, so the portal redirect is tunnelled and unreachable. Enable captive-portal detection in the Client Connector app profile so ZCC recognises the interception, notifies the user and pauses tunnelling until sign-in completes. This is a supported behaviour and is far better than a helpdesk script that trains 800 users to disable security software - that workaround will outlive the problem.
Fail-open vs fail-closed is a risk decision, not a default:
- Fail-closed (block traffic when the tunnel is down) protects data but produces a total outage on bad hotel Wi-Fi, which is precisely what pushes users and helpdesk to defeat the agent. The security outcome is worse than a controlled fail-open.
- Recommend fail-closed for high-risk groups (clinical users with regulated data, finance, admin roles) and fail-open with alerting plus a tunnel-down exception report for the rest.
- Remember ZIA and ZPA tunnels are independent: a ZIA outage need not break private application access, so blanket fail-closed across all tunnels is usually unnecessary.
Pair either choice with telemetry on tunnel-down events so the exceptions are visible and reviewed, not silent.
3. How do you handle the Teams media complaint given the security team's 'everything through ZIA' mandate?
Read the worked answer
Real-time media is UDP, already encrypted end-to-end, and latency-sensitive. Forcing it through the proxy adds a hop and a tunnel the call does not need, and inspecting SRTP buys almost nothing. The stutter is a predictable consequence of the current profile, not a Teams fault.
Proposal: follow the Microsoft 365 network-optimisation guidance - keep signalling and non-media traffic in ZIA, and bypass the media flows (UDP 3478–3483 and the published M365 endpoints) via the forwarding profile so calls go direct.
Make the trade explicit rather than arguing policy:
- Present the measured latency and jitter delta from ZDX before and after a pilot on one floor.
- State plainly that bypassed media is outside inspection and web logging, and record the risk acceptance with an owner.
- Offer the middle ground: bypass for media only, all other M365 traffic still inspected.
If security still refuses, the decision is a business one - call quality against inspection of already-encrypted traffic - but it should be made with the numbers and documented, not settled by asserting 'all traffic goes through ZIA' while the executives quietly use their phones instead.