Zscaler Client Connector and traffic forwarding
One agent, several forwarding decisions
The Zscaler Client Connector is the endpoint agent that authenticates the user, applies device posture, and forwards traffic. Its behaviour comes from an App Profile containing forwarding settings: whether to tunnel web traffic to ZIA, private-app traffic to ZPA, telemetry to ZDX, and which traffic to send natively. Profiles and their web policies are assigned to users and groups, and the agent selects the enforcement node closest to the user.
Tunnel mechanics
Z-Tunnel 2.0 carries traffic over DTLS (UDP 443) with fallback to TLS over TCP 443, so it survives restrictive networks. Traffic is encapsulated per application rather than as a full-device VPN, unless broad forwarding is deliberately configured. Trusted Networks let you bypass the tunnel on known-good networks (for example, an office already forwarding via GRE or IPSec); VPN Trusted Networks exist for coexistence with third-party VPN clients.
Location-based forwarding alternatives
PAC files, explicit proxy, GRE, and IPSec tunnels forward traffic from a location rather than an agent. On their own they carry no per-user identity; identity is reconstructed through SAML-based location authentication or surrogate IP, which must be refreshed before it expires.
Traps
- Assuming GRE or IPSec authenticates individual users - it does not.
- Forgetting that a user on a Trusted Network is bypassed and loses agent-based policy.
- Mixing up Z-Tunnel versions and their transports.
- Overlooking that ZPA traffic requires the agent (or Browser Access), while GRE serves site-based web forwarding.
Rule of thumb
Agent on the device → identity and posture available. Tunnel from a site → identity must be reconstructed. Choose a forwarding method by asking 'where does the user's identity come from?'