Zscaler Source IP Anchoring (SIPA) – Architecture & Configuration Guide

What is Source IP Anchoring?

Source IP Anchoring (SIPA) is a Zscaler ZPA capability that ensures traffic to a third-party application always exits from a fixed, predictable public IP address — rather than a dynamic or shared Zscaler egress IP.

In enterprise deployments, App Connectors sit on private IP addresses inside your network, VPC, or VNet. They do not carry public IPs directly on their interfaces. When an App Connector sends traffic toward the internet, it follows the subnet’s default route — typically toward a firewall, NAT gateway, or cloud egress device. That device performs NAT and the traffic exits using a static public IP assigned to the NAT device. That static NAT IP is what the third party sees and what gets added to the allowlist.

This is the Zscaler-recommended design. Zscaler documentation explicitly states that App Connectors should use private IP addresses and that the anchored source IP comes from the NAT or egress device, not from the App Connector interface itself.

The reason SIPA matters: many third-party applications, partner portals, SaaS platforms, and legacy systems enforce access control by source IP. Without SIPA, traffic exits from whichever shared Zscaler cloud node handles the session — which changes constantly across tenants and datacenters. The third party gets a different source IP on every connection and has no reliable address to allowlist. SIPA solves this by locking the egress path so the third party always sees the same static public IP.

This is not a simple toggle. SIPA requires coordinated configuration across both ZIA and ZPA, and the failure modes are specific to each layer.

Traffic Flow

Most documentation shows App Connectors directly carrying a public IP. In a properly designed deployment, The flow is:

┌──────────────────────────┐
│      User Device         │
│   Zscaler Client         │
│   Connector (ZCC)        │
└────────────┬─────────────┘
             │
             │  1. User accesses SIPA-protected application
             ▼
┌──────────────────────────┐
│  Zscaler Internet        │
│  Access (ZIA)            │
│  Forwarding Policy       │
└────────────┬─────────────┘
             │
             │  2. Policy matches → routes to ZPA Gateway
             ▼
┌──────────────────────────┐
│  Zscaler Private         │
│  Access (ZPA)            │
│  Client Forwarding       │
│  Policy                  │
└────────────┬─────────────┘
             │
             │  3. Two rules enforce ZIA → ZPA path
             ▼
┌──────────────────────────┐
│  Application Segment     │
│  Source IP Anchor = ON   │
└────────────┬─────────────┘
             │
             │  4. Access Policy evaluated
             ▼
┌──────────────────────────┐
│  Access Policy           │
│  Client = ZIA Service    │
│  Edge                    │
└────────────┬─────────────┘
             │
             ▼
┌──────────────────────────┐
│  ZPA Server Group        │
└────────────┬─────────────┘
             │
             ▼
┌──────────────────────────┐
│  App Connector Group     │
└────────────┬─────────────┘
             │
             ▼
┌──────────────────────────┐
│  App Connectors          │
│  (Private Subnet)        │
└────────────┬─────────────┘
             │
             │  5. Traffic follows default route toward egress
             ▼
┌──────────────────────────┐
│  Firewall / NAT Gateway  │
│  (Static Public NAT IP)  │
└────────────┬─────────────┘
             │
             │  6. Traffic exits with static NAT IP
             ▼
┌──────────────────────────┐
│  Third-Party Application │
│  (IP Allowlisted)        │
└──────────────────────────┘

The third-party application sees the NAT gateway’s static public IP — not the App Connector’s private IP, and not a shared Zscaler cloud IP. The App Connector IP is internal and never exposed externally.

Full Traffic Path Summary

User
 → ZCC (agent on endpoint)
 → ZIA (forwarding policy routes to ZPA Gateway)
 → ZPA (client forwarding policies enforce ZIA → ZPA path)
 → Application Segment (Source IP Anchor = ON)
 → Access Policy (Client Type = ZIA Service Edge)
 → Server Group → App Connector Group
 → App Connectors (private IPs, follow default route)
 → Firewall / NAT Gateway (static public IP — this is the anchored IP)
 → Third-Party Application (sees the static NAT public IP)

The critical path detail engineers miss: ZCC must not reach ZPA directly. Traffic must pass through ZIA first so the forwarding policy can route it to the correct ZPA gateway. If ZCC hits ZPA directly, the Access Policy client type (ZIA Service Edge) will never match and the session fails.

Step-by-Step Configuration

Step 1 — ZIA Forwarding Policy

This is where SIPA begins. Without a ZIA forwarding rule, traffic from ZCC goes straight to the internet through ZIA’s standard egress — the App Connector is never involved.

In the ZIA Admin Portal, go to Policy > Forwarding Rules and create a new rule:

• User / Group — scope to the users or groups that need SIPA routing
• Destination — the application’s domain or IP
• Forward Method — set to ZPA
• ZPA Gateway — select the SIPA-configured gateway

Step 2 — ZPA Client Forwarding Policy (Two Rules Required)

This is the most commonly misconfigured part of SIPA. Two rules are needed and the order matters.

Go to ZPA Admin Portal > Policy > Client Forwarding Policy.

Rule 1 — Bypass ZCC Direct Access

Tells ZPA: if ZCC requests this application directly, bypass it back toward ZIA. This forces the correct path — ZCC → ZIA → ZPA — rather than ZCC hitting ZPA directly and skipping the forwarding policy entirely.

Rule 2 — Allow ZIA Service Edge

Tells ZPA: when traffic arrives from ZIA (presented as ZIA Service Edge), allow it through and forward to the App Segment. Without this rule, ZIA’s handoff to ZPA gets rejected.

Step 3 — Application Segment

Go to ZPA Admin Portal > Applications > Application Segments and open the segment for the target application.

The field that enables anchoring: Source IP Anchor — must be ON. This is easy to miss as it sits lower in the configuration screen. Without it, the App Connector sends traffic through its normal egress path without any anchoring guarantee and the third party sees an inconsistent source.

Other fields to verify:

• Domain / IP — matches what the application is accessed as
• Ports — correct TCP/UDP ports listed
• App Connector Groups — includes the dedicated SIPA connector group
• Segment Group — assigned, so the segment is available in Access Policy

Step 4 — Access Policy

Go to ZPA Admin Portal > Policy > Access Policy and create a rule.

The most common SIPA failure lives here. Client Type must be ZIA Service Edge, not Zscaler Client Connector.

By the time traffic reaches this policy evaluation, it has already been handed off from ZIA internally. ZPA sees it as coming from ZIA Service Edge, not from the ZCC client. If the rule is scoped to ZCC, it will not match and the session drops.

Place this rule above any broader rules that could match the same application with a different client type. ZPA evaluates top-down and stops at the first match.

Step 5 — Server Group and App Connector Group

The Server Group links the Application Segment to the App Connectors. Confirm the group is pointing to the dedicated SIPA App Connector Group — not a shared group used by other applications.

For the App Connector Group, use a dedicated group containing only the connectors whose egress path you control and have confirmed routes through the correct NAT device. Do not mix these with connectors from other subnets or VPCs that egress through different NAT gateways, as that defeats the purpose.

Minimum two App Connectors for redundancy. If one is down during maintenance, SIPA traffic continues via the remaining connector — and the third party’s allowlist does not need to change because both connectors egress through the same NAT IP.

Step 6 — Confirm the NAT Egress IP

Before handing over to the third-party team for allowlisting, validate the egress IP from the App Connector’s perspective. From the App Connector host or the subnet it sits in, confirm outbound traffic to the internet exits via the expected static public IP on the NAT/firewall device.

Provide the NAT gateway’s static public IP to the third-party team — not the App Connector’s private IP. If you have multiple App Connectors behind the same NAT, only one IP needs to be allowlisted. If connectors span multiple NAT gateways with different public IPs, provide all of them.

Important Engineering Notes

NAT symmetry matters. If you have multiple firewalls or NAT gateways in the path, ensure that SIPA traffic always exits through the same device carrying the allowlisted static IP. Asymmetric routing where different sessions hit different NAT devices will cause intermittent SIPA failures — the ZIA/ZPA policy will look correct but the third party will see varying source IPs. This is one of the harder failures to diagnose because nothing looks wrong on the Zscaler side.

Cloud NAT gateway behaviour. In AWS, a NAT Gateway has a fixed Elastic IP. In Azure, a NAT Gateway or outbound rule with a public IP prefix gives you control over egress IPs. In GCP, Cloud NAT allows you to assign static external IPs. Confirm which IP is actually being used before handing it to the third party.

Multiple App Connectors behind a single NAT. This is the recommended HA design. All connectors egress through the same NAT IP, so the third party only needs to allowlist one address. Make sure the subnet routing is correct for all connector hosts.

Do not assign public IPs directly to App Connector interfaces. Zscaler recommends keeping App Connectors on private IPs. The anchored source IP comes from the NAT layer, not from the connector itself.

Engineering Checklist

Common Failures

Traffic not reaching App Connector at all — ZIA Forwarding Rule is missing or not matching. Check the forwarding policy first — without it, ZIA handles the traffic itself and the App Connector is never in the path.

Access Policy not matching — Client Type is set to ZCC instead of ZIA Service Edge. Most frequent single mistake. Change it to ZIA Service Edge.

Third party still rejecting connections — Source IP Anchor is not enabled on the App Segment. The App Connector egresses normally without anchoring. Enable the toggle and retest.

Intermittent failures — works sometimes, fails others — NAT asymmetry. Some sessions are exiting through a different NAT device carrying a different public IP. Audit the routing from the App Connector subnet and ensure all traffic hits the same NAT gateway.

Works for some users, fails for others — ZIA Forwarding Rule or Access Policy conditions are excluding some users. Check group membership against rule conditions.

Multiple IPs appearing at third party despite SIPA — Multiple App Connector Groups are selected in the Access Policy, or connectors span subnets behind different NAT devices. Lock down to a single connector group behind a single controlled NAT egress.

Quick Reference

Traffic Path at a Glance