4.1 GRE & IPsec Tunnel Configuration

4.1 GRE & IPsec Tunnel Configuration

Architectural Premise: Site-to-cloud traffic forwarding allows enterprise branch offices, headquarters, and campus networks to route outbound internet and cloud-bound traffic directly to the Zscaler Internet Access (ZIA) Public Service Edge without deploying client software on every individual endpoint. By establishing point-to-point GRE (Generic Routing Encapsulation) or IPsec (Internet Protocol Security) tunnels from edge routers, firewalls, or SD-WAN appliances, organizations achieve frictionless direct internet breakout, centralized security inspection, and optimal cloud path routing.

---

1. Site-to-Cloud Traffic Forwarding Architecture

In a modern Secure Access Service Edge (SASE) deployment, enterprise branches no longer backhaul internet-bound traffic over costly private MPLS circuits to centralized corporate data centers. Instead, border routing devices establish secure, high-throughput tunnels directly to the closest ZIA Public Service Edge data center.

+-----------------------------------------------------------------------------+
|                   SITE-TO-CLOUD TRAFFIC STEERING ARCHITECTURE               |
+-----------------------------------------------------------------------------+

  Branch Office LAN
  +------------------------+
  | Laptops, Workstations, | 
  | IoT Devices, Printers, | 
  | Servers & Guest Wi-Fi  |
  +-----------+------------+
              |
              v
  +------------------------+      Primary GRE/IPsec Tunnel (Direct to Nearest DC)
  | Branch Border Router / | ====================================================> [ ZIA Public Service Edge: Primary ]
  | SD-WAN Edge Gateway    |                                                        (e.g., Chicago DC - 104.129.192.1)
  +------------------------+ ====================================================> [ ZIA Public Service Edge: Secondary ]
                                  Secondary GRE/IPsec Tunnel (Failover DC)            (e.g., Dallas DC - 165.225.216.1)

Primary Advantages of Edge Tunnel Forwarding:

• Universal Device Coverage: Protects all endpoints within the physical location—including headless IoT hardware, legacy operating systems, VoIP phones, and guest devices—without requiring Zscaler Client Connector (ZCC) installation.
• Sub-location Scoping: Enables administrators to partition internal RFC 1918 subnets behind the tunnel into discrete Sub-locations with granular policies.
• Surrogate IP Authentication: Maps transient user logins to internal IP addresses for transparent policy mapping on non-browser and background traffic.
• Bandwidth Optimization: Unloads heavy SaaS and video streaming traffic directly to the cloud edge, freeing internal WAN circuits.

---

2. GRE vs. IPsec: Comprehensive Protocol Comparison

Zscaler supports two primary site-to-cloud encapsulation protocols: Generic Routing Encapsulation (RFC 2784/2890) and IPsec VPN (RFC 4301).

Why GRE is Zscaler's Preferred Forwarding Mechanism

1. Ultra-Low Encapsulation Overhead: GRE adds only 24 bytes of packet header overhead, leaving more space for actual user payloads and significantly reducing the risk of packet fragmentation.
2. Hardware Acceleration: Most enterprise routers, switches, and SD-WAN appliances handle GRE encapsulation natively in hardware ASIC forwarding planes without CPU penalties, achieving multi-gigabit throughput.
3. Application-Layer Encryption Inherent in Web Traffic: Over 95% of modern enterprise internet and SaaS traffic is already encrypted end-to-end via TLS/HTTPS (Port 443). Adding a second layer of IPsec tunnel encryption creates redundant cryptographic processing without meaningful security gains for standard internet browsing.

[!NOTE] When to Use IPsec Instead of GRE: Deploy IPsec when:

1. The branch router obtains a dynamic public IP address via DHCP/PPPoE from an ISP.
2. The edge device sits behind a carrier-grade NAT (CGNAT) or upstream firewall that blocks raw IP Protocol 47.
3. Corporate regulatory compliance mandates all traffic leaving the building be encrypted at Layer 3 across the public internet.

---

3. MTU, MSS Clamping, and Fragmentation Mechanics

One of the most frequent sources of performance degradation and intermittent page-load failures in site tunnels is packet fragmentation caused by mismatched Maximum Transmission Unit (MTU) and Maximum Segment Size (MSS) parameters.

+-----------------------------------------------------------------------------+
|                     PACKET ENCAPSULATION OVERHEAD BREAKDOWN                 |
+-----------------------------------------------------------------------------+

  Standard Ethernet Frame (MTU 1500 Bytes):
  +-----------------------------------+---------------------------------------+
  | 20B IPv4 Header | 20B TCP Header |          TCP Payload (MSS = 1460)     |
  +-----------------------------------+---------------------------------------+

  GRE Encapsulated Frame (Outer MTU 1500 -> Tunnel MTU 1476 Bytes):
  +-----------------+----------------+-------------------+-------------------+
  | 20B Outer IP Hdr|  4B GRE Header | 20B Inner IP Hdr  | 20B TCP | MSS=1436|
  +-----------------+----------------+-------------------+-------------------+
  |<------ 24B GRE Overhead -------->|

  IPsec ESP Encapsulated Frame (Outer MTU 1500 -> Tunnel MTU 1400-1420 Bytes):
  +-----------------+----------------+-------------------+-------------------+
  | 20B Outer IP Hdr| 8B UDP (NAT-T) | ESP Hdr/IV/Trailer| Inner IP/TCP/Data |
  +-----------------+----------------+-------------------+-------------------+
  |<------------- ~56-76B IPsec Overhead -------------->|

Mathematical Calculations for MTU and TCP MSS

1. Standard Physical Ethernet Interface:

   • Physical MTU = 1500 bytes
   • Standard IPv4 Header = 20 bytes
   • Standard TCP Header = 20 bytes
   • Default TCP MSS = 1500 - 20 - 20 = 1460 bytes

2. GRE Tunnel Interface:

   • GRE Encapsulation Overhead = 20 bytes (Outer IPv4) + 4 bytes (GRE) = 24 bytes
   • Recommended Tunnel IP MTU = 1500 - 24 = 1476 bytes
   • Clamped TCP MSS = 1476 - 20 (Inner IP) - 20 (Inner TCP) = 1436 bytes

3. IPsec Tunnel Interface (with NAT-T / AES-GCM):

   • IPsec Encapsulation Overhead = 20B (Outer IP) + 8B (UDP 4500) + 8B (ESP Header) + 16B (IV) + 16B (ICV) + Padding = ~56-76 bytes
   • Recommended Tunnel IP MTU = 1400 to 1420 bytes
   • Clamped TCP MSS = 1360 to 1380 bytes (Zscaler recommended standard: 1360-1400 bytes depending on crypto suite)

Path MTU Discovery (PMTUD) and the 'DF' Bit Black Hole

When an endpoint sends a TCP segment with the Don't Fragment (DF) bit set in the IP header, and that packet exceeds the tunnel MTU, intermediate routers drop the packet and return an ICMP Type 3, Code 4 message (Destination Unreachable, Fragmentation Needed and DF Set).

If intermediate firewalls or upstream ISPs drop ICMP messages (a common security practice known as an ICMP Black Hole), the sending endpoint never learns to reduce its packet size. The user experiences hanging SSL handshakes, stalled SaaS applications, and failed file uploads.

[!IMPORTANT] Exam Requirement: To prevent ICMP black holes and packet drops, administrators must configure TCP MSS Clamping on the edge router's tunnel interface (e.g., ip tcp adjust-mss 1436 for GRE or ip tcp adjust-mss 1360 for IPsec). MSS clamping rewrites the TCP SYN packet's maximum segment size during the initial 3-way handshake, forcing both client and server to keep payloads within non-fragmented boundaries.

---

4. Static vs. Dynamic IP Tunnel Provisioning

ZIA identifies incoming tunnel traffic and maps it to the appropriate corporate tenant and security policy based on the authentication credentials associated with the tunnel.

+-----------------------------------------------------------------------------+
|                     STATIC VS. DYNAMIC PROVISIONING MATRIX                  |
+-----------------------------------------------------------------------------+

  Static Public IP Branch:                       Dynamic Public IP Branch:
  [ Edge Router (Fixed IP: 198.51.100.1) ]       [ Edge Router (Dynamic DHCP IP) ]
              |                                              |
              | GRE or IPsec (PSK)                           | IPsec (IKEv1 Aggressive / IKEv2)
              v                                              v
  [ ZIA Match by: Source IP Address ]           [ ZIA Match by: FQDN / UserFQDN ID ]
  (Linked to Static Location: "Chicago-HQ")      (Linked to Dynamic Location: "Store-42")

Provisioning Static IP Locations

1. Static IP Definition: The administrator navigates to Administration > Static IPs & GRE Tunnels in the ZIA Admin Portal and adds the branch's fixed public egress IP address.
2. GRE Tunnel Creation: A GRE tunnel object is defined by selecting the Static IP and pairing it with the primary and secondary ZIA Virtual IP (VIP) addresses.
3. Location Association: A Location (e.g., EMEA-London-HQ) is created and bound to the Static IP or GRE tunnel. All traffic emerging from this tunnel inherits the location's security profile, firewall rules, and DLP policies.

Provisioning Dynamic IP Locations (VPN Credentials)

When a branch connects via consumer broadband, 4G/5G LTE, or dynamic cable modems, the egress public IP changes unpredictably.

1. VPN Credential Creation: In Administration > Static IPs & GRE Tunnels > VPN Credentials, the administrator creates an identity of type FQDN (Fully Qualified Domain Name) or UserFQDN (e.g., branch-store412@enterprise.com) and defines a strong Pre-Shared Key (PSK).
2. Location Binding: A Location is created and associated with the VPN Credential object rather than a static IP address.
3. IKE Configuration on Router:
   • IKEv1: Configured using Aggressive Mode (Main Mode cannot be used with dynamic IPs and PSK because the identity is encrypted in Phase 1 before the responder knows which PSK to look up).
   • IKEv2: Configured using standard IKEv2 with identity payload (IDi) matching the configured FQDN/UserFQDN.

---

5. Keepalives, Health Monitoring, and Failover Mechanics

Enterprise resilience mandates configuring redundant tunnel pairs from each edge site to distinct ZIA data centers.

+-----------------------------------------------------------------------------+
|                   PRIMARY / SECONDARY FAILOVER DYNAMICS                     |
+-----------------------------------------------------------------------------+

  Branch Router
  +-------------------------------------------------------------------------+
  | Primary Tunnel -> Primary ZIA VIP (Weight/Cost: 10)  [ ACTIVE PATH ]     |
  | Secondary Tunnel -> Secondary ZIA VIP (Weight/Cost: 20) [ STANDBY PATH ]|
  | Keepalive Engine: Probes sent every 5 seconds (Fail after 3 missed)     |
  +-------------------------------------------------------------------------+
          |
          |--[ Link Healthy ]----> Primary ZIA Edge (Low Latency)
          |
          X--[ Probes Fail ]-----> Secondary ZIA Edge (Automatic Traffic Reroute)

Health-Check and Keepalive Protocols

• GRE Keepalives: The branch router sends GRE keepalive packets (or ICMP echo requests to the ZIA tunnel internal endpoint IP) at regular intervals (typically every 5 to 10 seconds). If the router fails to receive a response for 3 consecutive probes, the primary tunnel interface is marked Down, and the routing table dynamically shifts default egress traffic to the secondary tunnel.
• IPsec Dead Peer Detection (DPD): For IPsec tunnels, RFC 3706 DPD monitors peer liveness using periodic R-U-THERE and R-U-THERE-ACK messages. Recommended settings: 10-second interval, 3 retries.

ZIA Data Center Virtual IP (VIP) Selection

Zscaler publishes primary and secondary Public Service Edge VIPs dynamically via the Zscaler Cloud Configuration Portal (https://config.zscaler.com/<cloud_name>/cenr). Administrators can query recommended GRE/IPsec VIPs based on the branch's source IP geo-location.

---

6. Practical Configuration Scenario: Cisco IOS XE Dual GRE Configuration

! --- Configure Primary GRE Tunnel to Primary ZIA VIP ---
interface Tunnel1
 description Primary ZIA GRE Tunnel - Chicago DC
 ip address 172.16.100.2 255.255.255.252
 ip mtu 1476
 ip tcp adjust-mss 1436
 tunnel source GigabitEthernet0/0/0
 tunnel destination 104.129.192.1
 keepalive 5 3
!
! --- Configure Secondary GRE Tunnel to Secondary ZIA VIP ---
interface Tunnel2
 description Secondary ZIA GRE Tunnel - Dallas DC
 ip address 172.16.100.6 255.255.255.252
 ip mtu 1476
 ip tcp adjust-mss 1436
 tunnel source GigabitEthernet0/0/0
 tunnel destination 165.225.216.1
 keepalive 5 3
!
! --- Policy-Based Routing / Static Route with Metric Failover ---
ip route 0.0.0.0 0.0.0.0 Tunnel1 10
ip route 0.0.0.0 0.0.0.0 Tunnel2 20

---

7. Exam Traps & Real-World Pitfalls

[!WARNING] Exam Trap (IKEv1 Main Mode vs Aggressive Mode with Dynamic IP): You cannot use IKEv1 Main Mode with Pre-Shared Keys when the initiating branch router has a dynamic public IP address. In Main Mode, identity negotiation occurs in Phase 1 after Diffie-Hellman key exchange, which requires the responder to know the peer's static IP to look up the PSK. Dynamic IPsec with IKEv1 must use Aggressive Mode, or upgrade to IKEv2.