# ZIA GRE & IPSec tunnels — choose, build, prove Source: https://ai.techclick.in/blog_zscaler_zia_gre_ipsec_tunnels Markdown: https://ai.techclick.in/blog_zscaler_zia_gre_ipsec_tunnels.md Publisher: Techclick Infosec Pvt Ltd Choose GRE or IPSec IKEv2 for Zscaler ZIA, bind a Location, set MTU/MSS, build primary/backup, and prove the site in Tunnel Insights. Interactive L2 lesson. Quick answer (say this out loud) GRE and IPSec both forward branch internet into a ZIA Public Service Edge . Prefer GRE when protocol 47 is allowed and you want simple encap plus internal-IP visibility. Prefer IKEv2 + PSK when the path must be encrypted or GRE is blocked. Always build primary + secondary to two data centers, bind a Location (GRE static IP and/or VPN credentials), Activate , then prove health in Logs → Insights → Internet & SaaS – Tunnel Insights and the Location name in web logs. Start MTU 1400 / MSS 1360 . Hero · site to ZIA Users stay on the LAN. Internet-bound packets enter GRE or IPSec and only egress after ZIA policy. Tunnel up ≠ Location mapped. ## Why tunnels matter ZIA is not sitting in the branch. To inspect office traffic when Client Connector is not on every device, you forward packets to a Public Service Edge. GRE and IPSec are the classic site-level methods. They are not ZPA app access. If the tunnel is wrong you get silent bypass (no policy), a green VPN with the wrong Location (wrong policy stack), or SaaS that hangs on large objects (MTU black hole). Location-only policy is one door for everyone on that path. After the site is mapped, authentication still decides who is on the wire. #### What the tunnel does Carries internet-bound packets from your edge to a Public Service Edge. Policy and logs start there — not on the router. #### What the Location does Names the site. Binds the GRE static IP and/or VPN credentials so ZIA can apply location policy and write the Location field in web logs. ## Mental model — three objects Memorize three parts before you open the Admin Console. Most “tunnel is up but internet is broken” tickets skip part 2. - Edge device — router or firewall that builds GRE (protocol 47) or IPSec (ESP) and steers internet traffic with PBR. - ZIA cloud objects — a Static IP plus GRE tunnel, and/or VPN credentials , both bound to a Location . Nothing is live until you Activate . - Service Edge path — primary VIP/DC and secondary VIP/DC. Keepalives, IPSLA, RPM, ICMP, or DPD must move traffic when the primary dies. Flow 1 · three objects Users to edge to GRE or IPSec tunnel to ZIA Public Service Edge Location mapping to internet - Users / LAN RFC1918 Edge device PBR + GRE / IKEv2 Tunnel GRE /47 or ESP primary + backup DC ZIA PSE Location + policy Internet Cloud objects: Static IP / GRE tunnel · VPN credentials · Location · Activate Proof: Tunnel Insights health + web log Location name — not only “VPN green” Read left → right. Policy does not start until the packet hits the Public Service Edge and maps to a Location. Say this out loud Tunnel is transport. Location plus credentials is the identity of the site. Policy still decides allow or block after the packet lands on a Service Edge. Path · primary and backup Help’s rule: two tunnels, two data centers. A second tunnel to the same DC is not high availability. ## GRE vs IPSec — how to choose Encryption need is the clean first fork. Then check whether the transit path allows GRE protocol 47, and whether the edge box can fail over cleanly. Flow 2 · choose the method Decision: need encryption or GRE blocked leads to IPSec IKEv2, otherwise dual GRE Need crypto on the path, or is GRE /47 blocked? No Yes GRE dual tunnel Static IP + GRE object Primary / Secondary DC VIP Keepalives + PBR + Location IPSec IKEv2 Add VPN Credential FQDN + New Pre-Shared Key Link to Location · two DCs Both still need dual DCs, Activate, and Tunnel Insights proof Diamond first. Then confirm the edge can detect failure (GRE keepalives / IPSLA / RPM, or IPSec DPD). Question Prefer GRE Prefer IPSec IKEv2 Encryption on the wire to ZIA? Not required. GRE is encapsulation (protocol 47). Yes — IKE + ESP. Help recommends IKEv2. Transit / ACL reality GRE is allowed inbound if the firewall filters it. GRE is blocked, or policy demands IPSec only. Internal IP visibility Preferred: GRE from an internal router, PBR before NAT, then sublocations. Same goal — do not hide every client behind one PAT if you need subnet policy. Documented throughput (Help) Up to 1 Gbps per GRE tunnel when internal IPs are not behind NAT. 400 Mbps per public source IP . More traffic → more source IPs, or NAT-T + source-port randomization with IKEv2. Cloud objects Static IP → Add GRE Tunnel → Location Public IP Addresses. Add VPN Credential → Location VPN Credentials. HA Both: primary + secondary to two different data centers . A second peer in the same DC is not failover. Hard words before the runbook Static IP is the public tunnel source ZIA already knows. Primary / Secondary Data Center VIP are the public destinations of the two GRE tunnels. VPN credentials identify the IPSec peer (Authentication Type FQDN, IP, or XAUTH). Location is the site object policy and logs use. Activate publishes the change. Tunnel Insights is where health is proven. ## GRE runbook Primary source: Zscaler Help Configuring GRE Tunnels and Self-Provisioning of GRE Tunnels (Help Portal export, 01 Aug 2026). ### Guidelines before CLI Two GRE tunnels → two Public Service Edges in different data centers. If the primary path dies, the router must change the routing table so the secondary is used. - PBR so only internet-bound traffic enters the tunnel. Match source/destination/protocol; action is the tunnel nexthop. - Enable GRE keepalives on both tunnels. If the platform has no GRE keepalives, use ICMP probes. Cisco: IPSLA. Juniper: RPM. - Most routers apply PBR before NAT, so ZIA still sees internal client IPs. If NAT runs first, consider disabling it or you lose logging granularity. Use sublocations for internal networks inside the GRE. - If inbound ACLs exist, allow GRE protocol 47 . ### Side A — Provision GRE on ZIA - #### Add GRE Tunnel (self-provision) Path: Infrastructure → Locations → Static IPs & GRE Tunnel → GRE Tunnels → Add GRE Tunnel . The Add GRE Tunnel Configuration wizard opens. - #### Source IP tab Static IP Address : pick one available static IP. One static IP maps to one GRE tunnel config. You cannot change it later on an edit. A static IP already mapped to a Location does not appear in the list. Optional Description . - #### Data Center tab Domestic Preference : enable only if you must prefer DCs in the country of the IP origin even when they are farther. Primary Data Center VIP and Secondary Data Center VIP : each list shows the five geographically closest active DCs; one is auto-selected. Help’s rule: the two VIP destinations must not be the same data center. DCs flagged Do Not Provision (DNP) on config.zscaler.com do not appear. If the org uses Private Service Edges, those VIPs list first. - #### Internal IP Range tab Is Unnumbered IP : enable only if you do not need an internal address on each side. Otherwise Select Internal GRE IP Range from the default pool of 10 ranges, or search other RFC1918 space. Help’s support-provisioned example assigns a /29 that you split into two /30 s: first host = your router, second host = the Service Edge, then repeat on the backup tunnel. - #### Review → Save → Activate The Review tab is the last chance to edit. Save is not enough. Activate the change. https://admin.zscaler.net/#infrastructure/locations/gre-tunnels/add Training mock · not live Infrastructure → Locations → Static IPs & GRE Tunnel → GRE Tunnels → Add GRE Tunnel ### Add GRE Tunnel Configuration Source IP Data Center Internal IP Range Review Static IP Address (from Source IP) 203.0.113.40 · available Domestic Preference · off Primary Data Center VIP Auto · 5 closest · DC-A (not DNP) Secondary Data Center VIP Auto · different DC than primary Help: primary and secondary VIP destinations must not point to the same data center. DNP DCs on config.zscaler.com are hidden. Values are RFC 5737 training placeholders — never invent a live VIP. Back Next Click next: Internal IP Range → pick a range (or Unnumbered) → Review → Save → Activate . Then bind this static IP on the Location. Source: Self-Provisioning of GRE Tunnels . Support path (if self-service is not available) Open a ticket with the public IP of the tunnel source and the physical location of the router . Zscaler assigns inner VIPs from a non-routable pool it manages. Help’s published example shape (not your tenant): Tunnel Source IP 192.0.2.2 , Internal Range 172.18.58.120–127 , Primary Destination 216.66.5.49 with inner 172.18.58.121/30 + 172.18.58.122/30 , Secondary Destination 199.169.149.79 with inner 172.18.58.125/30 + 172.18.58.126/30 . ### Side B — Location object - #### Add Location Path in current Help: Infrastructure → Locations → Location Management → Legacy Locations → Add Location (the GRE article also writes Infrastructure → Locations → Legacy Locations ). UI may say Legacy Locations. - #### General fields Name , Country , optional City/State/Province , Time Zone . Time-based policy uses this timezone — a 08:00–17:00 Cloud App Control rule fires in local hours per Location. - #### Bind the GRE source Help labels this list Public IP Addresses on the GRE article and Static IP Addresses and GRE Tunnels on Configuring Locations. Choose the public tunnel-source IP you provisioned. The same static IP is the public source for both GRE tunnels. - #### Save and Activate Location binding that is not Activated is the classic “tunnel green, logs show unknown location” ticket. https://admin.zscaler.net/#infrastructure/locations/legacy/add Training mock · not live Infrastructure → Locations → Location Management → Legacy Locations → Add Location ### Add Location Name BR-Mumbai-LAB Country India City/State/Province Mumbai Time Zone Asia/Kolkata (IST) Static IP Addresses and GRE Tunnels 203.0.113.40 · GRE source (training) VPN Credentials None on this GRE-only site Cancel Save Click next: Save, then Activate . Confirm the same Name later in web logs. Source: Configuring Locations + Configuring GRE Tunnels step 3. ### Side C — Router / firewall - #### Preferred topology Help prefers two GRE tunnels from an internal router behind the firewall so ZIA sees internal IPs. Source the GRE from a loopback that holds the public static IP; allow protocol 47 on the firewall. If that is not feasible, GRE from the border router and disable NAT so internal IPs remain visible. - #### Primary and secondary GRE Primary: source = your public static IP, destination = Primary Data Center VIP, tunnel IPs = first /30. Secondary: same source, destination = Secondary Data Center VIP, second /30. Enable keepalives (or ICMP / IPSLA / RPM) on both. - #### PBR and NAT order Match internet-bound traffic → nexthop through GRE. Track the primary; if it is down, use the secondary. Do not send private WAN into ZIA. Keep PBR before NAT unless you deliberately want one PAT address. Fill from your console or Support email — do not invent VIPs Tunnel source public IP: _______________ Primary Data Center VIP: _______________ Secondary Data Center VIP: _______________ Internal GRE /30 primary: router ____ / PSE ____ Internal GRE /30 backup: router ____ / PSE ____ Location Name: _______________ Activated?: yes / no Vendor samples on Help: GRE Configuration Example: Cisco 881 ISR , GRE Configuration Example: Juniper SRX . ## IPSec runbook Primary source: Zscaler Help Understanding IPSec VPNs , Configuring an IPSec VPN Tunnel , Adding VPN Credentials . IKEv1 on a new tenant Help recommends IKEv2 (faster, simpler, fixes IKEv1 issues). New tenants cannot establish IKEv1 tunnels to Internet & SaaS unless Support enables it. Design new builds on IKEv2. ### Side A — VPN credentials and Location - #### Collect peers first For each tunnel you need: IP address or hostname of the local gateway, the shared secret, and the IP addresses or hostnames of the Public Service Edges. Plan two VPNs to two different Service Edges. - #### Add VPN Credential Path: Infrastructure → Locations → VPN Credentials → Add VPN Credential . Choose Authentication Type used to identify the peer: FQDN , IP , or XAUTH . For FQDN, User ID is the FQDN (Help: up to 256 characters). Enter New Pre-Shared Key and optional Comments (CSV import limit is 10,240 characters). For Authentication Type IP , the static IP must already be known to Zscaler — submit it to Support first if it is not. You need the FQDN (or IP) and PSK later when you link the Location and when you build IKE on the edge. - #### Link credentials to a Location On Add/Edit Location, use the VPN Credentials control. Without this link the IKE SA can still come up while traffic misses location policy. Save and Activate . https://admin.zscaler.net/#infrastructure/locations/vpn-credentials/add Training mock · not live Infrastructure → Locations → VPN Credentials → Add VPN Credential ### Add VPN Credential Authentication Type FQDN User ID br-mumbai@lab.example.com New Pre-Shared Key •••••••••••• (never a production secret) Comments Training · IKEv2 dual-DC · not live CSV PSK Type values are UFQDN, IP, XAUTH. Bulk import: same page → Sample Import CSV file / Import VPN Credentials (up to 3,000 rows). You can delete an existing XAUTH row via CSV but cannot add a new XAUTH that way. Cancel Save Click next: open the Location → attach this credential under VPN Credentials → Save → Activate . Then build IKEv2 on the edge with the same User ID and PSK. Source: Adding VPN Credentials . ### Side B — Edge VPN (generic, then vendor guide) - #### Local ID rule (Help) If the VPN credential is an FQDN , the peer’s local ID can be a private IP. Otherwise local ID should be the public IP that was provisioned as the static IP / IP-type credential. Private local ID against a public-IP credential → negotiation fails. - #### IKEv2 Phase 1 / Phase 2 Match a supported proposal. Help bolds recommended values in the IKEv2 table. Phase 1 authentication is Pre-Shared Key . Phase 2: ESP , Tunnel Mode . SA lifetime context: Phase 1 24 Hours , Phase 2 8 Hours , unlimited lifebytes. Help recommends disabling PFS for Phase 2. AES-GCM needs the matching subscription; without it Help recommends NULL encryption on the child SA. - #### NAT-T and DPD NAT-T is integrated in IKEv2 when the initiator is behind NAT. NAT keepalive interval in the table: 20 seconds . Enable DPD. Help recommends a 10–20 second DPD interval with at least 3 retries (the supported-parameter table also lists DPD Timeout Interval 20 seconds and DPD Maximum Retries 5). Zscaler does not treat ongoing data as proof the peer is alive. If the device only supports on-demand DPD, allowlist Zscaler IPs so Zscaler-initiated DPD is not dropped. - #### Selectors, MTU, MSS Route-based or policy-based VPN as the platform allows. Steer internet-bound traffic only. Help’s starting values: tunnel MTU 1400 bytes , MSS 1360 bytes (or measure your optimal MTU — see Determining the Optimal MTU for GRE or IPSec Tunnels ). #### Verified IKEv2 vendors (Help list) Cisco ASA, Cisco ISR, Juniper SRX, Juniper SSG, FortiGate FortiOS, Palo Alto Networks PAN-OS, SonicWall TZ. Use the matching Zscaler IPSec configuration guide for CLI — do not copy another vendor’s transform set. #### More than 400 Mbps Help: IPSec is limited to 400 Mbps per public source IP . Add tunnels on different public sources, or multiple IKEv2 tunnels on the same source with NAT-T and source-port randomization. Example given: 800 Mbps → two primary + two backup tunnels. IPSec pilot card IKE: IKEv2 Authentication Type: FQDN (or IP if Support already has the static IP) User ID / FQDN: _______________ Local ID rule: FQDN cred → private IP OK | IP cred → that public IP Primary PSE peer: _______________ Secondary PSE peer: _______________ Location Name: _______________ MTU / MSS start: 1400 / 1360 DPD: 10–20s, ≥3 retries Tunnel Insights both peers: UP? ## Prove it is up A green crypto SA is not the close. You need health on both peers, the correct Location on a test transaction, and a failover you actually ran. Flow 3 · packet after the tunnel is up User HTTPS through PBR into GRE or IPSec, Location map on the Public Service Edge, then internet - User HTTPS PBR match internet only GRE / IPSec encap to PSE Location map policies apply Internet If Location mapping fails, URL and SSL policy look random even when the SA is green. Runtime path. Close the ticket only after the Location name appears on a real transaction. Pilot proof checklist Primary and secondary show healthy in Logs → Insights → Internet & SaaS – Tunnel Insights (Help wording). Some tenants surface this under Analytics; the log path is the one in the GRE and IPSec articles. - Test user hits a unique URL. Web logs show Location = your site Name (example: BR-Mumbai-LAB ). - Internal client IP is visible when you designed PBR-before-NAT (or the expected sublocation hit). - Failover test: shut or fail the primary. Traffic moves to the secondary. No black hole. Restore and confirm it prefers primary again. - A large HTTPS download finishes. If small pages work and large objects stall, clamp MSS ~1360 and set tunnel MTU ~1400, then retest. Edge signals (adapt syntax — the meaning is the same) GRE: tunnel interface up · keepalive / IPSLA / RPM tracking the primary ping <Primary Data Center VIP> source <GRE source> IPSec: IKEv2 SA READY · child SA up · DPD succeeding Both: PBR hit counts incrementing on internet traffic only ZIA: Tunnel Insights both peers Up · web log Location = site Name ## Classic fails Symptom Likely cause First check GRE never comes up Protocol 47 blocked; wrong public source; VIP not provisioned; DNP DC ACL for GRE; Static IP + GRE object; Primary/Secondary VIP; config.zscaler.com IPSec Phase 1 fails PSK / local ID mismatch; IKEv1 on a new tenant; proposal mismatch Authentication Type vs local ID rule; force IKEv2; align Help-supported algorithms Tunnel up, no / wrong Location Location not linked, or change not Activated Public IP / VPN Credentials bind + Activate; web-log Location field SaaS hangs; small pages work MTU black hole Start at MTU 1400 / MSS 1360; retest a large download Failover never happens No keepalive / IPSLA / RPM / DPD; both VIPs in one DC Detection timers; Secondary Data Center VIP is a different DC One public IP for every user; sublocation policy misses NAT before the tunnel Reorder NAT after PBR, or accept one address and drop subnet identity Need more than 400 Mbps on IPSec Hitting the documented per-source-IP limit More public sources, or IKEv2 NAT-T + source-port randomization Unsafe shortcut Shipping one tunnel “for the pilot” and promising HA later. When that DC or path dies, the branch loses inspected internet with no practiced failover. Help’s design is two tunnels, two data centers, on day one. Interview one-liner “For ZIA site forwarding I pick GRE when we want simple encap and internal-IP visibility, IPSec IKEv2 when crypto is required or GRE is blocked; always dual-DC tunnels, a Location bind plus Activate, MTU 1400 / MSS 1360, and Tunnel Insights before production.” ## Knowledge check Six judgment questions. Map each miss to the runbook or traps section, then retry. Q1 The branch must encrypt traffic to ZIA. Transit ACLs drop GRE protocol 47. What do you design? A single GRE tunnel — encryption is optional on all ZIA paths Dual IPSec IKEv2 tunnels to two data centers, VPN credentials linked to a Location PAC only, with no edge tunnel IKEv1 Aggressive on a new tenant, one peer, no Location bind Correct: b . Crypto required and GRE blocked → IPSec IKEv2. Still two DCs and a Location-linked credential. Re-read GRE vs IPSec. Q2 On Add GRE Tunnel, Primary Data Center VIP and Secondary Data Center VIP both resolve to the same data center. What is wrong? Nothing — Help prefers both VIPs in one metro for latency You must enable Domestic Preference first or the wizard will reject Save Help requires the two VIP destinations not point to the same data center — this is not HA You should map a second Static IP Address on the same wizard page Correct: c . Self-Provisioning of GRE Tunnels: primary and secondary VIP destinations must not be the same DC. One static IP still maps to one GRE object. Re-read GRE runbook Side A. Q3 The VPN credential is Authentication Type IP with the site’s public address. The firewall local ID is an RFC1918 address. What happens? It works — PSK alone is enough for IKEv2 Negotiation fails — a private local ID is allowed only when the credential is an FQDN Only SSL inspection breaks; IKE still comes up ZPA App Connectors take over the tunnel Correct: b . Understanding IPSec VPNs: FQDN credential → local ID may be private; otherwise local ID is the public IP. Mismatch fails negotiation. Re-read IPSec Side B. Q4 The firewall shows the tunnel up. Web logs have no Location (or the wrong name) and policy looks random. First check on ZIA? Location is linked to the GRE static IP or VPN credential, and the change is Activated Delete every custom URL category Disable authentication for the org Raise sandbox file-size quota Correct: a . Transport up ≠ site identity mapped. Location bind + Activate is the classic fix. Re-read GRE Side B and Proof. Q5 GRE is up. Logs show one public IP for 200 users. Sublocation policy never hits. First design error? Too many Cloud App Control rules Secondary Data Center VIP is unused SCIM is not enabled NAT ran before PBR / GRE, so ZIA never saw internal client IPs Correct: d . Help: most routers PBR before NAT so internal IPs are preserved. NAT-first hides every user behind one address. Re-read GRE guidelines and traps. Q6 Small HTTPS pages work over the new tunnel. Large file downloads stall. First fix to try? Ignore it — SaaS always fails on ZIA Set tunnel MTU to about 1400 and MSS clamp to about 1360, then retest a large download Remove the secondary tunnel so packets fragment less Switch the org to IKEv1 Aggressive Correct: b . Classic MTU black hole. Help’s IKEv2 table lists MTU 1400 bytes and MSS 1360 bytes as the starting point. Re-read Proof and IPSec Side B. Check answers Reset ## Sources - Zscaler Help — Configuring GRE Tunnels (dual DC, PBR, keepalives / IPSLA / RPM, protocol 47, Location bind, /29 split, Tunnel Insights) - Zscaler Help — About GRE Tunnels / Self-Provisioning of GRE Tunnels (Add GRE Tunnel tabs: Static IP Address, Domestic Preference, Primary/Secondary Data Center VIP, Is Unnumbered IP, Select Internal GRE IP Range) - Zscaler Help — Best Practices for Deploying GRE Tunnels (1 Gbps per GRE tunnel when internal IPs are not behind NAT) - Zscaler Help — Configuring Locations (Legacy Locations, Static IP Addresses and GRE Tunnels, VPN Credentials) - Zscaler Help — Understanding IPSec VPNs (IKEv2 table, NULL vs AES-GCM, local ID rule, DPD, NAT-T, MTU 1400 / MSS 1360) - Zscaler Help — Configuring an IPSec VPN Tunnel (400 Mbps per public source IP, dual peers, IPv6 selectors note) - Zscaler Help — Adding VPN Credentials (Authentication Type, User ID, New Pre-Shared Key) - Zscaler Help — About VPN Credentials (FQDN, XAUTH, or IP) - Zscaler Help — Determining the Optimal MTU for GRE or IPSec Tunnels - Local Help Portal PDF exports used for evidence: Configuring_GRE_Tunnels.pdf , Understanding_IPSec_VPNs.pdf (01 Aug 2026) Related: ZIA traffic flow · ZIA forwarding methods · ZIA authentication · Router GRE / IPSec lab simulator --- Cite this Techclick lesson with the source URL. Do not invent fees, batch dates, or job guarantees. Browse all lessons: https://ai.techclick.in/blogs AI index: https://ai.techclick.in/llms.txt