Zscaler Client Connector Not Tunnelling: The Diagnostic Order That Finds It Fast

The user says the internet works but nothing is being filtered. Zscaler Client Connector shows a green tick and the user's name. Yet an ip check website reports the corporate ISP address, not a Zscaler egress. Traffic is bypassing the service entirely.

Why is Zscaler Client Connector authenticated but not tunnelling traffic?

Authentication and forwarding are two separate functions. The connector can authenticate the user successfully and still forward nothing, because forwarding is controlled by the PAC file and the forwarding profile - not by login state. A green tick only proves the user is known to Zscaler. Check the PAC file the connector actually loaded, then the forwarding profile that applies to the network the device is on.

Layer 1 - Confirm what the connector thinks it is doing

Open Client Connector, go to More then Advanced Diagnostics, and export the logs. Before reading them, check the three fields on the front page.

FIELD                 HEALTHY VALUE            WHAT IT PROVES
Authentication        Authenticated            user is known
Service Status        ON                       driver is loaded
Tunnel Version        Z-Tunnel 2.0             full transparent tunnel
Forwarding Profile    <your off-trusted name>  which rules apply NOW

Common Mistake: Treating "Authenticated" as proof the tunnel works. It is not. It only means the user signed in. Read the Tunnel Version and Forwarding Profile fields - those are the ones that decide whether packets move.

Layer 2 - The forwarding profile is matching the wrong network

This is the most common real cause. A forwarding profile decides behaviour based on whether the device is On Trusted Network or Off Trusted Network. Trusted network detection usually keys on a DNS server, a resolvable hostname, or a specific DNS suffix.

If someone builds a new office subnet reusing the same internal DNS, every remote laptop on that VPN now believes it is inside the office - and On Trusted Network is very often configured as Direct, meaning no tunnel at all. The user is authenticated, the tick is green, and nothing is inspected.

# What the device actually resolves - run this on the endpoint
nslookup trusted-check.corp.local
ipconfig /all        | findstr "DNS"       # Windows
scutil --dns         | grep nameserver     # macOS

# Compare against the trusted network condition in
# Administration > Forwarding Profile > Trusted Network

Key Concept: Trusted network detection is a guess based on DNS. It is not a security boundary. If the guess can be satisfied from outside the office, your off-network policy silently stops applying.

Layer 3 - Read the PAC file the connector actually loaded

Not the PAC file you think is applied - the one on the device. A bypass added months ago for one broken application is often the reason a whole category of traffic goes direct.

# Typical PAC bypass that quietly grows out of control
if (shExpMatch(host, "*.vendor-portal.com")) return "DIRECT";
if (isInNet(dnsResolve(host), "10.0.0.0", "255.0.0.0")) return "DIRECT";

# ^ the second line sends ALL RFC1918 traffic direct.
#   If an app resolves to a 10.x address, it is never inspected.

Common Mistake: Adding a broad isInNet DIRECT rule to fix one internal application. It works, the ticket closes, and months later a cloud service that resolves into private address space is invisible to the proxy.

Layer 4 - Prove it end to end

Verify: Zscaler publishes a diagnostic endpoint that tells you, from the service side, whether your request arrived through the tunnel and which node handled it.

curl -s https://ip.zscaler.com

# Tunnelling correctly:
#   "Your request is arriving from ... You are accessing the
#    Internet via Zscaler Cloud <cloud name>"
#
# NOT tunnelling:
#   "...you are not going through the Zscaler service"

# Then confirm the session appears service-side:
#   Analytics > Web Insights > filter by the user, last 15 minutes

If ip.zscaler.com confirms the tunnel but Web Insights shows nothing for that user, you have a logging or attribution problem, not a forwarding problem - which is a different investigation entirely.

The order, in short

1  Client Connector front page   tunnel version + forwarding profile
2  Trusted network detection      is the device wrongly "on network"
3  The loaded PAC file            which bypasses actually exist
4  ip.zscaler.com                 does the SERVICE see the tunnel
5  Web Insights                   does the LOG see the user

Exam Trap: ZDTA asks what a green "Authenticated" status guarantees. It guarantees identity only - never forwarding. Forwarding is decided by the forwarding profile and PAC file.

Zscaler ZIA and ZPA are part of our Network Security Package - 90 hours across Palo Alto, Zscaler and F5 BIG-IP, preparing you for ZDTA. Full syllabus: https://ai.techclick.in/courses

- Team Techclick techclick.in | +91 92772 29456 @techclick_in | exam.techclick.com