Branch in Bengaluru has a static public IP on a 1-Gbps ISP link. No regulatory requirement to encrypt the underlay. Which forwarding method gives the best throughput with the simplest config?

Correct answer: (d) GRE — no encryption overhead, higher throughput, simpler config, and a public IP at the branch makes GRE viable. Correct: (d). GRE is the right choice when you have a public IP and no encryption mandate — it tunnels all branch IP traffic with minimal overhead and saturates the link better than IPSec on the same hardware. (a) IPSec adds CPU/crypto overhead for no benefit here. (b) PAC only catches browser traffic. (c) ZCC alone leaves printers, IoT, and any non-agent device unprotected.

After enabling a GRE tunnel from your Pune branch, users report: "Salesforce login screen partially loads, then hangs. PDF downloads stop midway." What's the most likely cause and fix?

Correct answer: (b) MTU/MSS issue — GRE adds 24 bytes of header, leaving 1476 inner MTU on a 1500 link. TCP sessions that hit the cap break silently. Fix: ip mtu 1400 / ip tcp adjust-mss 1380 on the GRE tunnel interface (use 1360 for IPSec instead). Correct: (b). Classic GRE MTU/MSS issue. Mid-flow large TCP packets exceed the inner MTU and get dropped silently — symptoms are "half-loads" and stalled transfers. Modern Zscaler recommendation: MTU 1400 / MSS 1380 on GRE (MSS 1360 on IPSec because of the extra 20-byte ESP overhead). (a) SSL inspection is unrelated to MTU. (c) PSE load wouldn't produce these patterns. (d) Location IP is for source identification, not packet sizing.

Your remote sales team uses Outlook native client (TCP), Slack with audio/video (UDP), Zoom (UDP), and Chrome. You want every protocol monitored by ZIA. Which ZCC tunnel mode?

Correct answer: (a) Z-Tunnel 2.0 — all TCP+UDP via DTLS, captures non-web protocols. Correct: (a). Z-Tunnel 2.0 routes every TCP and UDP socket from the endpoint — covering Slack RTP and Zoom UDP that Tunnel 1.0 / PAC would miss. (b) HTTPS-only misses RTP. (c) PAC only intercepts browser HTTP(S). (d) DNS forwarding doesn't tunnel data, just filters by domain.

You configured a PAC file change at 09:00. Users say "still using the old PAC" at 10:00 even after restarting Chrome. Where's the culprit?

Correct answer: (c) Browser caches the PAC aggressively. Force-refresh via chrome://net-internals/#proxy → Re-apply settings (or restart with proxy reset). Browser cache, not Zscaler. Correct: (c). Browsers and OSes cache PAC files for hours. Restarting Chrome doesn't clear the proxy cache — you need Chrome's net-internals proxy reset, or change the PAC URL (versioned URL trick: proxy.pac?v=2 ). (a) PAC isn't pushed by the CA — it's hosted at a URL fetched by the client. (b) Nanolog is logs, unrelated. (d) Sub-Cloud variant affects PSE selection, not PAC distribution.

A laptop is on Wi-Fi at home. ZCC is installed and Trusted Network Detection is configured. What should ZCC do?

Correct answer: (b) Enable Z-Tunnel 2.0 to the nearest PSE because the TND tests (internal DNS hostname, DNS suffix, gateway in 10.x) fail on home Wi-Fi. Correct: (b). When TND tests fail, ZCC knows it's on an untrusted network and enables its Z-Tunnel to the nearest PSE — that's the entire point of TND-aware ZCC. (a) is the inverted logic — TND should fail at home. (c) would break the user's internet. (d) ZCC doesn't downgrade to PAC.

Your warehouse has 50 IP cameras. You can't install agents on them and there's no router available for a tunnel — just a flat L2 network with DHCP. How do you give those cameras at least some Zscaler protection?

Correct answer: (d) Point the cameras' DHCP at Zscaler's DNS resolvers via DNS-based forwarding. Get category-level enforcement (block known-bad domains, malware C2s) without full traffic tunneling. Correct: (d). DNS-based forwarding is built for exactly this scenario — IoT/OT devices where you can't install ZCC and can't tunnel. You get category enforcement (no malware domains, no porn-flagged C2s) at the DNS layer. It's not full inspection but it's the realistic best option. (a) cameras don't run GRE. (b) ZCC can't install on most IP cameras. (c) blocking removes legitimate functions (firmware updates, remote viewing).

You configured TND with one test: "DNS resolves portal.company.com to 10.20.30.40 ". Users at home complain ZCC isn't tunneling — they're getting the office policy. What went wrong?

Correct answer: (c) portal.company.com is also resolvable externally (public DNS returns a different IP, but it still resolves), so the test passes everywhere — fix by using a name that ONLY resolves internally (e.g. nas.corp.local ) or test against the internal gateway IP. Correct: (c). Classic TND test design failure — the hostname resolves from the public internet (just to a different IP), so the "can I resolve this name?" check passes even from home Wi-Fi. ZCC then assumes it's on the corporate network. Use a name that ONLY exists in internal DNS (e.g. nas.corp.local ) or pivot to a gateway-IP test. (a) ZCC is fine. (b) the tunnel choice is unaffected. (d) Sub-Cloud has nothing to do with TND.

Your branch sits behind ISP NAT. You want an encrypted tunnel to ZIA. Which method survives NAT, and what's the key port?

Correct answer: (a) IPSec IKEv2 with NAT-T on UDP 4500 — survives NAT cleanly with port-mapping. UDP 500 (IKE) initiates; NAT-T moves to 4500. Correct: (a). GRE (protocol 47) and ESP (protocol 50) both fail behind most NATs because there's no port to map. IPSec NAT-T wraps ESP inside UDP 4500 specifically to survive NAT — that's why it exists. (b) GRE survives some 1:1 NATs but not port-PAT, which is what ISPs run. (c) bare ESP behind NAT fails. (d) PAC is a browser proxy config, not a tunnel.

You deployed ZCC with Z-Tunnel 2.0 default, GRE on each branch. A user in the Pune branch hits ip.zscaler.com . What should they see?

Correct answer: (b) Their branch public IP (because TND passes — ZCC backs off — branch GRE handles forwarding from the branch router). Source IP reported is the branch's WAN IP, not the user's laptop NAT IP. Correct: (b). When TND passes (laptop is on branch LAN), ZCC backs off and the branch GRE tunnel forwards the user's request. From the PSE's POV, source IP = branch WAN IP. (a) home Wi-Fi IP would mean ZCC is tunneling directly — wouldn't happen if TND correctly identifies the branch. (c) ip.zscaler.com reports the source IP that hit the PSE, not the egress. (d) request will succeed.

Rolling out Zscaler to a 4000-user company. You can ship branch GRE tunnels in 6 weeks but need users protected day 1. Sequence the rollout.

Correct answer: (c) Deploy ZCC (Z-Tunnel 2.0) to all laptops immediately — gives day-1 coverage everywhere (office + roaming). Then bring up branch GRE tunnels over 6 weeks. Enable Trusted Network Detection so ZCC defers to GRE inside each branch as soon as the tunnel is live. Never have an "uncovered" window. Correct: (c). ZCC-first is the modern playbook — day-1 coverage everywhere, branches activated when GRE tunnels come up, TND prevents dual-tunneling. (a) branch-first creates a multi-week window where laptops aren't covered when roaming. (b) PAC only covers browsers. (d) leaves a 6-week coverage gap.

Traffic Forwarding — getting traffic into ZIA · Batch 11 Lesson 3

Why this lesson matters

Lessons 1 and 2 gave you the platform mental model. From here on, every lesson is something you actually configure. Forwarding is the foundation — the first checkbox on any new ZIA rollout: "how does the user's packet reach a PSE?" Pick the wrong method, and either policy never applies (the user is invisible to Zscaler) or traffic is broken (the tunnel won't come up, or apps misbehave because the wrong things are tunneled).

There are exactly five forwarding methods. Most enterprise deployments combine 2–3 of them — typically GRE / IPSec for branches + ZCC for laptops + maybe PAC for one legacy app. After this lesson you'll know which to reach for in any scenario.

The five methods at a glance

Method	Who it covers	What it tunnels	Pros	Cons
GRE	Branch (router/firewall has public IP)	All IP traffic from branch LAN	Highest throughput · no IPSec overhead · simple config	No encryption · needs public IP at branch · MTU drops 24 bytes
IPSec IKEv2	Branch (incl. NAT'd) · cloud VPCs	All IP traffic from the local subnet	Encrypted underlay · works behind NAT · pre-shared key or cert	Higher CPU · NAT-T 4500/UDP · throughput cap ~250 Mbps per tunnel
PAC file	Browsers only	Only HTTP(S) traffic the browser/OS proxies	Zero infrastructure · works on any browser	Doesn't catch non-browser traffic (Slack RTP, Outlook MAPI) · users can disable proxy
ZCC (Z-Tunnel 1.0)	Roaming laptops	HTTP(S) only — TLS-wrapped to PSE	Auth-bound · IdP-aware · forces tunneling	Misses non-web protocols (UDP, custom TCP)
ZCC (Z-Tunnel 2.0)	Roaming laptops + BYOD	All TCP/UDP from the endpoint via DTLS	Catches every protocol · DTLS lower latency than TLS · default for modern rollouts	Slightly higher endpoint CPU than 1.0
DNS-based	Anywhere DNS is in your control	Nothing — just steers DNS to Zscaler's resolvers for category enforcement	Useful for IoT/OT where you can't install ZCC and can't tunnel	Not a real forwarder — just DNS-level filtering, not full inspection

The decision tree — pick the right method in 30 seconds

Forwarding method decision tree

Walk the tree. For each user population, the right method is usually obvious once you answer 1–2 questions about their environment.

GRE — the branch workhorse

GRE (Generic Routing Encapsulation) wraps every IP packet in a GRE header and tunnels it to the nearest PSE. No encryption, no IKE negotiation — just an IP-in-IP wrapper. That simplicity is why GRE outperforms IPSec on the same hardware at the branch.

When to pick GRE

Branch router/firewall has a static public IP (not behind NAT)
You don't have an explicit "encrypt underlay" mandate (most enterprises don't, because the underlay ISP doesn't see your decrypted traffic anyway — TLS in the payload protects it)
You want maximum throughput per tunnel — GRE pushes 1+ Gbps cleanly on modest hardware where IPSec needs heavy CPU

The MTU gotcha (you will hit this)

GRE adds 24 bytes of header. On a 1500-MTU link, that leaves 1476 bytes for the inner IP packet. If your branch router doesn't reduce the inner-interface MTU (or doesn't set TCP MSS clamping), TCP sessions will silently break for any packet that hits the cap — typical symptoms: SaaS login pages half-load, file uploads stall, Slack message images don't render. The fix is one line:

Cisco IOS · MSS clamping for GRE (MTU 1400 / MSS 1380)

interface Tunnel100
 ip mtu 1400
 ip tcp adjust-mss 1380   ! GRE — use 1360 instead when running IPSec

Zscaler's modern recommendation: MTU 1400 / MSS 1380 for GRE; MTU 1400 / MSS 1360 for IPSec (extra 20 bytes for ESP overhead). Use the IPSec numbers when the tunnel is encrypted, the GRE numbers when it isn't.

IPSec IKEv2 — when GRE won't do

IPSec gives you the same forwarding outcome (all branch IP → PSE) but adds encryption of the underlay. Use IPSec when:

Branch router sits behind NAT — GRE breaks behind NAT, IPSec NAT-T (UDP 4500) survives it
Compliance or contract requires encrypted transit — even though TLS-in-payload protects the data, some auditors insist on link-layer crypto
Branch is on an untrusted MPLS or wireless backhaul where you don't trust the ISP

The Zscaler IPSec configuration cheat-sheet

Cisco IOS · IKEv2 IPSec to ZIA (modern crypto suite)

! Phase 1 — IKEv2 (modern: AES-GCM-256 + SHA256 + ECDH group 19/20)
crypto ikev2 proposal ZS_IKEv2
 encryption aes-gcm-256
 integrity sha256
 group 19              ! or 20 — ECDH P-256 / P-384, Zscaler-preferred
crypto ikev2 policy ZS_IKEv2_POLICY
 proposal ZS_IKEv2

! Phase 2 — IPSec (AES-GCM does AEAD; no separate auth needed)
crypto ipsec transform-set ZS_IPSEC esp-gcm 256
 mode tunnel

! Peer = nearest PSE VIP (lookup from config.zscaler.com per your cloud)
crypto ikev2 keyring ZS_KR
 peer ZSCALER
  address 104.129.198.x
  pre-shared-key        ! single symmetric key — used both directions

! Apply
crypto map ZS_MAP 10 ipsec-isakmp
 set peer 104.129.198.x
 set transform-set ZS_IPSEC
 match address ZS_TUNNEL_ACL

interface GigabitEthernet0/0/0
 crypto map ZS_MAP

! IMPORTANT — MSS clamp for IPSec overhead (1360 for IPSec, 1380 for plain GRE)
ip tcp adjust-mss 1360

⚠Common Mistake — IPSec tunnel UP but no traffic

You see "tunnel up" in show crypto ikev2 sa but users still report no internet. The Phase-2 SA exists, but the encryption-domain ACL (ZS_TUNNEL_ACL) doesn't match your branch's outbound web traffic. Always set it to permit ip <branch_subnet> any — not just permit ip <branch_subnet> <pse_ip>, because the PSE doesn't terminate the inner traffic to itself.

PAC files — small but mighty (and abused)

A PAC file is JavaScript that the browser/OS evaluates to decide "for URL X, which proxy do I go through?" Zscaler hosts a default PAC at https://pac.<yourcloud>.net/<companyname>/proxy.pac (e.g. https://pac.zscalerthree.net/acme/proxy.pac) — note the URL matches your tenant's cloud, not always zscaler.net, and is always HTTPS in modern tenants. The PAC says "for almost every URL, go through the nearest Zscaler PSE; for these listed exceptions, go direct."

Three PAC flavours you'll meet in tenants:

Standard PAC — Zscaler-hosted default. Use this 95% of the time. Updates centrally; no per-endpoint deployment.
Forwarding PAC — your own custom JavaScript URL. Use when you need site-specific exceptions (e.g. an internal CRM that must go direct, never via Zscaler).
Default PAC — the fallback ZCC uses if it can't reach the configured PAC URL.

PAC's big limitation: only browser/HTTPS traffic obeys it. The Slack desktop client, Outlook native, Zoom UDP, custom thick-client apps — none of them honour the PAC. That's the #1 reason modern rollouts have moved from PAC-only to ZCC.

ZCC — Z-Tunnel 1.0 vs Z-Tunnel 2.0

Zscaler Client Connector (ZCC) is the endpoint agent. It does identity-aware tunneling — the user's IdP session decides which Location/Department policy applies. The choice you need to make on every rollout: which tunnel mode.

Aspect	Z-Tunnel 1.0	Z-Tunnel 2.0
Protocol scope	HTTPS only (CONNECT-tunneled)	All TCP + UDP
Underlay	TLS over TCP/443	DTLS over UDP/443 (TLS fallback if UDP blocked)
Performance	Higher latency for non-web traffic that has to TLS-CONNECT first	Lower latency — direct DTLS, no per-flow CONNECT
Best for	Legacy environments where UDP/443 outbound is firewalled	Default for modern enterprise rollouts (2022 onward)

Default to Z-Tunnel 2.0 unless your branch firewall blocks UDP/443 outbound (rare). If you need universal protocol coverage and aren't sure what your branch firewall allows, ship Z-Tunnel 2.0 with TLS-fallback enabled — the client will start DTLS, fail back to TLS within a second if blocked, and users won't notice.

Trusted Network Detection — the "I'm at the office" check

A laptop running ZCC needs to know: am I on the corporate LAN (where the branch GRE/IPSec tunnel already handles forwarding) or am I on home/coffee-shop Wi-Fi (where ZCC needs to tunnel directly)? Without that detection, ZCC tunnels everything from inside the office too — wasteful, sometimes breaks split-tunnel apps.

Trusted Network Detection (TND) is the answer. You define one or more "tests" that uniquely identify "on corporate network" — e.g. "can I resolve internal.company.com to 10.20.30.40?" or "is my DNS suffix corp.local?". When all tests pass, ZCC backs off and lets the branch GRE/IPSec handle forwarding. When any test fails, ZCC kicks in and tunnels directly to the PSE.

Trusted Network Detection — ZCC roaming logic

ZCC re-evaluates Trusted Network tests on every network change — Wi-Fi join, VPN connect, ethernet plug. The branch GRE/IPSec keeps doing its job inside the office; ZCC kicks in everywhere else.

GRE / IPSec Branch Lab Cloud Connector Lab Tunnel Troubleshooting

Method 6 — Cloud Connector & Branch Connector

Cloud Connector is a lightweight VM Zscaler ships for AWS, Azure, GCP. You deploy it in your VPC; outbound workload traffic egresses through it, picking up ZIA inspection without IPSec/GRE. Modern alternative to building tunnels from cloud to Zscaler — and the only practical option when your workloads are ephemeral (autoscaling, k8s). Configured under Administration → Cloud & Branch Connector.

Branch Connector is Zscaler's own appliance (or VM) for small branches that lack a firewall capable of GRE/IPSec. Drops in like an SD-WAN CPE, registers to your tenant, forwards all internet traffic to ZIA. Sized from 100 Mbps to multi-Gbps SKUs. Replaces "SD-WAN + GRE" for greenfield branches.

When to pick which: Cloud Connector for IaaS workloads (AWS/Azure/GCP egress). Branch Connector for branches without an HQ firewall. GRE/IPSec for branches that already have a capable edge firewall.

💡Pro Tip — GRE tunnel health check

GRE tunnel health check: Zscaler runs an internal keepalive against endpoint.zscaler.net. When the tunnel is up but the keepalive fails (asymmetric routing, MTU mismatch), traffic blackholes — the BGP/static route says "tunnel up", but no inner packets arrive. Real L3 troubleshooting starts at this keepalive: if it's failing, your routing/MTU is the problem, not Zscaler.

Real-world scenario — hybrid rollout for a 12-branch enterprise

Your company has 12 branches (4 with public IPs, 8 behind ISP NAT), 800 roaming laptops, 200 BYOD phones, and 50 IoT cameras in the warehouse. Here's the forwarding picture you sketch:

4 branches with public IPs → GRE tunnels to nearest PSE. MSS clamped to 1360. Trusted Network Detection on every laptop so ZCC defers to GRE inside the branch.
8 NAT'd branches → IPSec IKEv2 with NAT-T. Same MSS clamping. PSK rotated every 90 days (cron + Zscaler API).
800 laptops → ZCC with Z-Tunnel 2.0, IdP-tied (Azure AD). TND tests defined to detect each branch.
200 BYOD phones → ZCC mobile (iOS/Android) — same Z-Tunnel 2.0 — but in app-level VPN mode so only sanctioned apps tunnel.
50 IoT cameras → DNS forwarding only. Their DHCP gives them Zscaler resolvers. Category-level enforcement (block known-bad domains). Full inspection not possible because we can't install ZCC.

Five methods used here, six available in total (Cloud Connector / Branch Connector covers cloud workloads and SD-WAN-less branches — see the next section). One fleet, one policy plane (the CA). That's a clean modern rollout.

💡Pro Tip — start with ZCC even for branches you GRE later

On day 1 of a new tenant rollout, deploy ZCC to all laptops before standing up branch GRE tunnels. Reason: ZCC gives you immediate coverage everywhere, including the office, while branch network work proceeds. Then enable Trusted Network Detection — ZCC backs off inside the branch once GRE is live. You never have a "user uncovered" window. Going branch-first is the older method and creates blackouts during the rollout.

✓Verify — for each user, confirm the right forwarder is active

Have the user open https://ip.zscaler.com. The page tells you:

Source IP — should be the branch's public IP (GRE/IPSec) or the user's home/ISP IP (ZCC roaming)
Method — implicitly visible via the IP class
PSE — should be the geographically-nearest one
Inspected = Yes — confirms the traffic actually traversed Zscaler

Combine with the ZCC tray-icon "Show Tunnel" detail to confirm Z-Tunnel 2.0 is in use, not 1.0.

Common production gotchas

⚠Common Mistakes — bookmark these

Forgetting MSS clamping — symptoms look random (SaaS half-loads, file uploads die). Always clamp: ip tcp adjust-mss 1380 for GRE, 1360 for IPSec (extra 20 bytes for ESP).
Whitelisting the PSE VIP on the wrong cloud — covered in Lesson 1. Pull IP list from config.zscaler.com/<your-cloud>/cenr/json.
PAC file caching by the browser — change the PAC, browser still uses the old one. Force-refresh with chrome://net-internals/#proxy → "Re-apply settings".
Z-Tunnel 1.0 deployed by default — older ZCC install profiles default to 1.0. Modern rollouts should explicitly set Z-Tunnel 2.0 in the ZCC policy.
TND test points at an internal hostname that's also externally resolvable — e.g. you test against portal.company.com which resolves both ways. Result: ZCC thinks home Wi-Fi is the office. Use a name that ONLY resolves inside (e.g. nas.corp.local) or test against gateway IP.
Dual-tunneling — both GRE and ZCC tunneling the same traffic. Wastes bandwidth, doubles policy hits. TND on the laptops is the fix.

📌 Quick reference (memorise before Module 5)

6 forwarding methods: GRE · IPSec · PAC · ZCC (Z-Tunnel 1.0 / 2.0) · DNS · Cloud Connector / Branch Connector
GRE: branch with public IP, fastest, no encryption, MSS clamp 1360
IPSec IKEv2: branch behind NAT or encrypted-underlay mandate, NAT-T UDP 4500
PAC: browser-only, hosted by Zscaler at https://pac.<yourcloud>.net/<tenant>/proxy.pac (HTTPS, cloud-specific)
Z-Tunnel 1.0 = HTTPS only. Z-Tunnel 2.0 = all TCP+UDP via DTLS (default)
DNS forwarding: only category enforcement, no inspection — use for IoT/OT
Trusted Network Detection (TND): ZCC backs off when corporate-network tests pass
Always: MSS clamp on tunnels · ZCC first then branches · TND on every laptop
Diagnose: https://ip.zscaler.com from each user — confirms source, PSE, inspected=Yes

▶ QUICK LAB · ~15 MIN

Pick the right forwarding method for your scenario:

Diagram your current network: branches, HQ, cloud workloads, roaming users.
For each location, pick: GRE / IPSec / PAC / Z-Tunnel / Cloud Connector / Branch Connector.
Now compute MTU/MSS for the GRE path: source MTU 1500 → minus 24 GRE bytes → MTU 1476. Set MSS clamp to 1380 to be safe.
Test with ping -M do -s 1372 8.8.8.8 through the tunnel — should succeed. -s 1500 should fail with DF set.

What's next — Lesson 4

Now that traffic actually reaches the PSE, the next lesson layers identity on top: how ZIA + ZPA authenticate users (Hosted DB · SAML · Kerberos), IdP integration (Azure AD / Okta / Ping) with a full SAML assertion walkthrough, SCIM provisioning, ZIdentity overview, and ZCC enrollment as part of a clean deployment.

Module 3 → Authentication & Deployment (next) Practice ZDTA on exam.techclick.in

Traffic forwarding — five ways to get user traffic into ZIA