Choosing a ZIA forwarding method: GRE, IPSec, PAC or Client Connector
Four questions that decide how a site or a user should send traffic to Zscaler Internet Access, and the mistakes each method invites.
Zscaler Internet Access can only inspect traffic that reaches it. There are several ways to get traffic there, and design questions on the ZDTE exam often come down to picking the right one for a described site or user. Four questions settle most cases.
1. Is there a user on the device?
Servers, cloud workloads and IoT devices have no user to sign in and often cannot run an agent. Their traffic is forwarded by the network: a tunnel from the site, or a Cloud Connector or Branch Connector placed in the path. Identity then comes from the location, not from a person.
2. Does the device leave the office?
A laptop that roams needs protection wherever it is, so the answer is Zscaler Client Connector. It also brings device posture, and it is the same agent that ZPA and ZDX use. For anything beyond web traffic, the tunnel must be Z-Tunnel 2.0, which carries all ports and protocols. Z-Tunnel 1.0 only carries web traffic.
3. Does the site have a static public IP?
| Site has | Use | Why |
|---|---|---|
| Static IP, router supports GRE | GRE tunnels | No encryption overhead, so the most throughput per tunnel |
| Dynamic IP, or no GRE support | IPSec tunnels | The site identifies itself with credentials, so its address can change |
Either way, build two tunnels to two different Zscaler data centres. One tunnel is a single point of failure, however reliable the data centre.
4. Is a browser the only thing that needs covering?
A PAC file tells the browser to use Zscaler as a proxy. It needs no agent and no tunnel, which makes it useful for kiosks and devices that cannot be managed. It covers only applications that honour the proxy setting, and the user still has to be identified somehow.
Host the PAC file on Zscaler and use its variables. When a browser fetches the file, Zscaler replaces them with the nearest healthy data centre for that client:
return "PROXY ${GATEWAY}:80; PROXY ${SECONDARY_GATEWAY}:80; DIRECT";
One file then serves every region. Hard-coded addresses per country lose both the automatic choice and the failover.
Mistakes each method invites
- GRE: translating addresses before the tunnel. Zscaler then sees one source IP for the whole site, and rules for sublocations such as guest Wi-Fi never match.
- IPSec: expecting GRE throughput from one tunnel. Scale with more tunnels.
- PAC: ending without
DIRECTand then being surprised that browsing stops when the proxy is unreachable. That is a choice between failing open and failing closed; make it deliberately. - Client Connector: tunnelling in the office as well, on top of the site tunnel. Trusted network detection avoids the double hop.