# Zscaler Tunnel Chooser

> Answer six questions about a location - bandwidth, HA, static IP, encryption, GRE support, endpoint NAT - and get the deterministic GRE-vs-IPsec recommendation with the minimum tunnel count, computed from Zscaler's own published figures, every step shown.

- Tool: https://ronutz.com/en/tools/zscaler-tunnel-chooser
- Family: Networking

---

## What it does

Answer six questions about a location - required bandwidth, whether high availability is required, whether the egress IP is static, whether transit must be encrypted, whether the edge device supports GRE, and whether the internal tunnel endpoints are source-NATed - and the tool returns the deterministic forwarding recommendation: GRE or IPsec, the per-tunnel capacity figure that applies and the documented rule it comes from, and the minimum number of primary and backup tunnels that covers the requirement. Every elimination step is shown in order, so the answer teaches the reasoning rather than replacing it. Same answers, same recommendation, always; everything runs in your browser and contacts nothing.

## The published figures it computes from

All capacity numbers are Zscaler's own, live-verified on 2026-07-21 against the help portal. A GRE tunnel carries up to 1 Gbps - unless the internal tunnel endpoint addresses are source-NATed, in which case the figure drops to 250 Mbps, because the service load-balances GRE traffic on the inner addresses and NAT collapses them into one. An IPsec tunnel carries up to 400 Mbps per public source IP address. The scale-out shapes mirror the documentation's own worked examples: 2 Gbps of GRE is two primaries plus two backups on distinct public source IPs; 800 Mbps of IPsec is two plus two, reached either through different public source IPs or through multiple tunnels on the same IP using NAT Traversal with source-port randomization under IKEv2.

## How the elimination works

GRE is preferred when its three preconditions hold - a static public egress address, a GRE-capable device, and no encryption mandate - because it is the simpler encapsulation, forwarded at hardware rate, with the higher per-tunnel ceiling. Any failed precondition routes the answer to IPsec, which tolerates dynamic addresses (peers identified by fully qualified domain name), provides encryption by construction, and asks only that IKEv2 and Dead Peer Detection be configured. The tunnel count is then a ceiling division of the required bandwidth by the applicable per-tunnel figure, and the backup count mirrors the primaries when high availability is required - each backup pointed at a Public Service Edge in a different data center, the documented primary/secondary shape. When no HA is requested, the tool returns the true minimum and says plainly that the vendor still recommends a secondary.

## What it will not pretend

The figures are forwarding-plane guidance for location tunnels, not promises about any specific circuit, and the tool says which documented rule produced each number rather than inventing precision. Roaming users are out of scope by design: a laptop off the network forwards through Zscaler Client Connector's Z-Tunnel, not through a location tunnel - a boundary this tool states rather than blurs.

## Sources

The GRE figures, the source-NAT rule, and the scale-out examples come from Understanding Generic Routing Encapsulation (GRE). The IPsec per-source-IP limit, its two scale-out shapes, and the primary/secondary recommendation come from Configuring an IPSec VPN Tunnel. The GRE preconditions, the dynamic-IP cue toward IPsec, and the MTU field guidance come from Choosing Traffic Forwarding Methods.

## Standards and references

- [Zscaler Help: Understanding Generic Routing Encapsulation (GRE)](https://help.zscaler.com/zia/understanding-generic-routing-encapsulation-gre) - 1 Gbps per GRE tunnel; 250 Mbps when internal tunnel endpoints are source-NATed (inner-address load-balancing rationale); scale-out via additional tunnels with different public source IPs (2 Gbps = 2 primaries + 2 backups; 3 Gbps = 3 + 3)
- [Zscaler Help: Configuring an IPSec VPN Tunnel](https://help.zscaler.com/zia/configuring-ipsec-vpn-tunnel) - 400 Mbps per public source IP; scale-out via different public source IPs or same-IP NAT-T + source-port randomization under IKEv2 (800 Mbps = 2 + 2; 1200 Mbps = 3 + 3); primary/secondary to Public Service Edges in different data centers; DPD
- [Zscaler Help: Choosing Traffic Forwarding Methods](https://help.zscaler.com/zia/choosing-traffic-forwarding-methods) - GRE preconditions (static egress IP, GRE-capable device); IPsec as the documented alternative for dynamic IPs or devices without GRE; MTU field guidance (min of appliance and path MTU; 1400 fallback)

## Related reading

- [Getting Traffic to ZIA: The Forwarding Decision](https://ronutz.com/en/learn/zia-traffic-forwarding-methods.md): A cloud proxy only protects what reaches it, so every ZIA design starts with the same question: how does traffic get there? The four working answers - Client Connector on the device, tunnels from the location, PAC files steering browsers, and proxy chaining from an existing edge - what each one covers, what each one misses, and how real deployments layer them.
- [GRE Tunnels: The Simplest Envelope in Networking](https://ronutz.com/en/learn/gre-tunnels-fundamentals.md): Generic Routing Encapsulation puts one packet inside another and asks nothing else of the path - no encryption, no authentication, just an envelope with a forwarding address. Why that simplicity is the point: the 24-byte anatomy, what GRE can carry that plain routing cannot, the keepalive question, and the trade a designer accepts when choosing GRE over an encrypted tunnel.
- [IPsec and IKE: How Encrypted Tunnels Negotiate Themselves](https://ronutz.com/en/learn/ipsec-and-ike-fundamentals.md): IPsec is two jobs in one suite: IKE negotiates who you are and which keys to use; ESP carries the protected packets. IKEv1 versus IKEv2, what a security association actually is, tunnel versus transport mode, why NAT almost broke everything until NAT-T, and why encryption always costs throughput - with a live worked example of the capacity math.
- [Locations and Sublocations: Teaching the Cloud Where Your Sites Are](https://ronutz.com/en/learn/zia-locations-and-sublocations.md): A ZIA location is a site the platform recognizes - by its tunnels or its egress addresses - and the recognition is what unlocks per-site policy, authentication expectations, and bandwidth control. Sublocations subdivide a site by internal network segment: the guest Wi-Fi policed differently from the corporate floor, the servers differently from both. The Gateway Options toggles, the three documented bandwidth modes, and why egress identification is the whole game.
- [The Zscaler Zero Trust Exchange: A Proxy Where the Perimeter Used to Be](https://ronutz.com/en/learn/zscaler-zero-trust-exchange-architecture.md): Zscaler's platform is not a firewall in the cloud - it is a globally distributed proxy that terminates every connection, inspects what it can see, and only then connects onward. Where ZIA, ZPA, and ZDX sit on that switchboard, what a Public Service Edge actually does, and why connect-to-app-not-network is the architectural sentence that explains everything else.
- [Tunnel Overhead, MTU, and MSS: The Byte Math Every Tunnel Owes](https://ronutz.com/en/learn/tunnel-overhead-mtu-and-mss.md): Every tunnel adds bytes, every path has a ceiling, and the difference between the two is where mysterious slowness lives. The overhead each encapsulation charges, why fragmentation is the worst of the three escapes, how Path MTU Discovery is supposed to work and how firewalls break it, and MSS clamping - the one-line fix that makes TCP fit on the first try.
- [Zscaler Tunnel Types: Z-Tunnel, GRE, and IPsec, With the Numbers](https://ronutz.com/en/learn/zscaler-tunnel-types-z-tunnel-gre-ipsec.md): Three tunnels carry traffic to the Zero Trust Exchange, and they are not interchangeable: the Client Connector's Z-Tunnel for devices, GRE and IPsec for locations. The published capacity figures - 1 Gbps, the 250 Mbps NAT penalty, 400 Mbps per source IP - the scale-out shapes the documentation itself uses, the HA pattern, and the MTU habit that keeps all three healthy.