Zscaler security controls only apply to traffic that actually reaches the Zscaler service, so traffic forwarding is an architectural decision rather than a setup detail. Mobile users, branch offices, campus networks, data centers, and unmanaged endpoints do not all need the same forwarding method. A good design chooses a method based on where the traffic originates, whether the device is managed, which protocols must be forwarded, how failure should work, and what identity or source context the policy engine needs.
The current Zscaler Digital Transformation Administrator (ZDTA) certification validates deploying the Zero Trust Exchange, securing user and device internet traffic, enabling basic policy, and connecting users to private applications. The more advanced ZDTE adds advanced connectivity. The broader Zscaler certifications connect administrator-level forwarding skills with more advanced engineering responsibilities. Zscaler’s current guidance recommends using an appropriate combination of Client Connector, tunnels, PAC files, and other forwarding options rather than forcing one mechanism everywhere.
For administrators, the key is to understand what each method changes in the traffic path. Client Connector follows a user device. GRE and IPsec tunnels usually represent fixed locations or branch edges. PAC files influence proxy behavior at the browser or operating-system proxy layer. Each choice affects resilience, protocol coverage, identity, DNS behavior, and troubleshooting.
Choose the forwarding method from the traffic source
Start by classifying the source. A managed laptop that leaves the office needs policy enforcement on hotel, home, and cellular networks. A branch office may have hundreds of devices behind a router or SD-WAN edge. A data-center server may not support endpoint software. A browser-only unmanaged device may need a different access pattern entirely.
This source classification narrows the design quickly. Client Connector is the natural fit for managed endpoints that move between networks because the forwarding logic travels with the device. Tunnels are efficient for fixed locations where a gateway can forward aggregate traffic. PAC files can steer web proxy traffic where an endpoint agent or transparent tunnel is unavailable, but they do not provide the same all-port, all-protocol coverage as a tunnel.
Do not choose a method only because it is easy to configure. The forwarding model should match the security and availability requirements of the traffic it carries.
Client Connector protects managed users wherever they work
Zscaler Client Connector is a lightweight endpoint agent that can forward internet traffic to Internet & SaaS (ZIA) and private-application traffic to Private Access (ZPA). That makes it especially useful for hybrid and mobile users, because the device can receive consistent policy even when it is outside a corporate location.
The agent can also contribute user and device context that location-only forwarding does not provide by itself. Administrators can build policy around identity, device posture, and other context instead of relying only on source IP. This is one reason Zero Trust architectures move away from the assumption that a user is trusted merely because traffic originates from an office network.
Client Connector still depends on correct enrollment, tunnel configuration, service reachability, and policy. Troubleshooting should verify the device’s forwarding state, selected service, authentication context, DNS behavior, and whether local exclusions are intentionally bypassing traffic.
GRE tunnels fit fixed locations with capable edge devices
GRE is commonly used to forward internet-bound traffic from a fixed corporate location to Zscaler. Zscaler’s current documentation recommends GRE for suitable fixed locations when the gateway supports it and the egress address is static. A typical resilient design uses primary and secondary tunnels to service edges in different data centers.
A major advantage is broad protocol coverage and transparent forwarding from the location. Endpoints do not need to be configured individually for every web application. The gateway sends selected traffic into the tunnel, and Zscaler can enforce the location’s policy while preserving useful source context depending on design.
The tradeoff is that GRE depends on the edge network. Routing, tunnel reachability, MTU, failover, and source-address design become part of the security path. If the branch router changes behavior, internet security can be affected even though the Zscaler policy itself is unchanged.
IPsec provides a tunnel option where GRE is not suitable
IPsec can also forward branch or site traffic to Zscaler. It is useful when the gateway does not support GRE, when encryption across the path is required by design, or when the available WAN equipment and services make IPsec the more practical tunnel type. Many SD-WAN platforms can establish and manage these tunnels as part of branch connectivity.
Because the tunnel adds cryptographic and stateful behavior, operators should monitor negotiation, rekeying, path changes, throughput, and failover. A tunnel can be technically up while performance is poor because of MTU, fragmentation, packet loss, or an inefficient path.
Use redundant tunnel endpoints where the design requires continued service during a service-edge or path failure. A security architecture that depends on one tunnel has turned a cloud security service into a local single point of failure.
PAC files steer explicit proxy traffic but have a narrower scope
A proxy auto-configuration file tells compatible applications when to use a proxy and which proxy endpoint to use. PAC files can be helpful when Client Connector cannot be installed or when the requirement is limited to proxy-aware web traffic. They are also useful for creating explicit bypass logic for destinations that should not traverse the proxy.
The limitation is scope. PAC logic operates at the proxy layer and depends on application behavior. It is not equivalent to a transparent all-port tunnel. Administrators should know which applications honor system proxy settings and which traffic will bypass them.
DNS behavior can also differ by forwarding method. Zscaler’s current documentation notes that explicitly proxied PAC traffic can have DNS resolution performed by Zscaler, while bypassed traffic is resolved locally. Transparent GRE or IPsec flows have different DNS-handling rules depending on how the client and service are configured. This can matter during troubleshooting because name-resolution behavior may change with the forwarding path.
Branch Connector and modern edge designs can simplify branch forwarding
Zscaler also supports branch-focused components and integrations that can create an overlay from a branch edge into the Zero Trust Exchange. These can be attractive where an organization wants a more integrated ZIA/ZPA branch model than manually maintaining tunnels on generic routers. The exact product choice depends on licensing, branch design, SD-WAN strategy, and operational standards.
The important concept for ZDTA and ZDTE is not memorizing every deployment product. It is understanding that a fixed site can forward at the network edge, while a user device can forward at the endpoint. Those layers can coexist. Some organizations deliberately install Client Connector on users even when branch traffic is also tunneled, because the agent preserves user protection and policy continuity off-network.
Document which layer is authoritative for each traffic type so that the environment does not create accidental double forwarding or inconsistent bypass behavior.
Identity, source context, and policy follow the forwarding design
Traffic forwarding and identity are tightly connected. A location tunnel can identify where traffic came from but may need authentication integration to apply granular user policy. Client Connector can carry user and device context directly. Explicit proxy traffic may have its own authentication flow. The policy team should know what identity is available before assuming a rule will match.
This is one place where the existing article on Zero Trust Network Access is useful: modern access decisions should be based on verified context and least privilege rather than network location alone. Forwarding gets traffic to the enforcement point; identity and policy decide what happens next.
Testing should include both authenticated and unauthenticated cases, remote and office locations, and the failure mode when identity services are unavailable.
Resilience requires more than a second tunnel
Availability design should consider forwarding endpoint, service edge, DNS, authentication, WAN path, and client behavior. Two tunnels that share the same ISP or router may not protect against the failure that actually matters. Likewise, Client Connector needs working local internet and service discovery before it can reach the cloud.
Test failover rather than inferring it from configuration. Confirm how quickly traffic moves to a secondary path, whether existing sessions survive, and whether DNS or identity changes during the event. Track user experience as well as tunnel status.
Operational monitoring should show tunnel health, Client Connector status, forwarding decisions, and the location or service edge actually used. Otherwise a failover can “work” while silently sending users through a poor path.
Troubleshoot by proving where traffic stops following the intended path
When policy appears not to apply, first prove whether the traffic reached Zscaler. On Client Connector, inspect forwarding state and exclusions. On GRE or IPsec, verify route selection, tunnel health, and counters. With PAC files, confirm that the target URL is evaluated to the expected proxy and that the application actually honors the proxy setting.
Then check identity and policy. A flow can arrive at the service but match a different user, location, URL category, or rule order than expected. Finally, verify return path and DNS behavior. Problems blamed on “Zscaler blocking the site” are sometimes local resolution or routing issues that occur before policy enforcement.
For 2026 ZDTA/ZDTE study, remember the architecture: forwarding is how traffic reaches enforcement. Choose Client Connector for mobile managed users, tunnels for suitable fixed locations, PAC where explicit proxy steering is appropriate, and build resilience around the real failure domains of each path.