Source IP Anchoring – Configuration Guide
What Is Source IP Anchoring?
Source IP Anchoring is a ZPA feature that forces user sessions through a specific App Connector so the application server always sees traffic coming from a fixed, known IP — the App Connector’s internal IP — rather than a random cloud egress address.
By default, ZPA load-balances across any available connector in a group. That works fine for most applications, but it becomes a problem when the application cares about where the traffic is coming from. If you have three App Connectors in a group and ZPA picks a different one each session, the application sees three different source IPs. For anything with IP-based allowlisting, IP-locked licensing, or strict audit requirements, that inconsistency causes access failures or compliance gaps.
Source IP Anchoring solves this by pinning a specific Access Policy rule to a specific App Connector Group. Every session that matches that rule goes through only those connectors — so the source IP the application sees is always predictable.
Common scenarios where this comes up:
- A legacy application or ERP system that only accepts connections from a specific IP range
- A SaaS vendor portal that restricts logins to your corporate IP
- A software licence tied to a source IP (common with older enterprise tools)
- Partner or third-party APIs that validate your organisation’s IP before responding
- Compliance requirements where access to sensitive systems must be attributed to a known, documented source
Before You Start
Make sure the following are already in place before touching policy:
- At least one App Connector is deployed and showing as Connected in the ZPA Admin Portal
- That connector can actually reach the application server over the internal network (test with a ping or curl from the connector host if needed)
- The Application Segment for the target application already exists
- You have admin access to the ZPA portal with permission to modify Access Policy
Also confirm the App Connector’s private IP before doing anything else. That is the IP you will hand to the application owner or firewall team for allowlisting. Go to Infrastructure > App Connectors, find the connector you plan to use, and note down its private IP address.
Configuration
1. Create a Dedicated App Connector Group
The anchoring is enforced at the connector group level in the Access Policy rule. The most important thing here is that this group contains only the connectors you want anchored traffic to flow through. If you put anchored and non-anchored connectors in the same group, ZPA can still pick any of them and the anchoring falls apart.
Go to Infrastructure > App Connector Groups and check if a suitable group already exists. If one does, confirm it only contains the intended connectors. If not, create a new one.
When creating the group:
Name — Use something that makes the purpose obvious, like ACG-FinanceApp-Anchored or ACG-SourceIP-DC1. Vague names cause problems later when someone is troubleshooting at 2am and has no idea what a group is for.
Description — Write a brief note explaining why this group exists. “Dedicated connector group for Source IP Anchoring — Finance app requires fixed source IP for allowlisting” is enough.
Location — Select the region where the connector is physically deployed. This helps Zscaler select a broker geographically close to the connector, which reduces latency in the tunnel path.
App Connectors — Add only the specific connectors you want to use for this anchored traffic. If you are setting up HA with two connectors, add both here, but make sure both IPs are provided to the application team for allowlisting since either one could serve a session.
Override Version Profile — Leave this as Default unless your org has a specific patching schedule that requires controlling which software version runs on this connector group.
Save the group.
2. Check the Application Segment
Go to Applications > Application Segments and open the segment for the application you are anchoring.
The key things to verify:
Domain or IP — Should match the application’s internal FQDN or IP exactly as users would connect to it.
Ports — Make sure the correct TCP or UDP ports are listed. ZPA will only broker connections on ports defined here, so if a port is missing the connection will fail silently from the user’s perspective.
App Connector Groups — The anchored connector group you just created needs to be associated with this segment. If it is not listed here, the segment will not be reachable via those connectors.
Segment Group — Needs to be assigned to a Segment Group. This is required for the segment to appear as selectable in the Access Policy.
Health Reporting — Keep this enabled. It surfaces connectivity issues in the portal and makes troubleshooting significantly easier.
If the segment is already working for other users via a different connector group, you can simply add the new anchored group alongside the existing one. The Access Policy rule will control which group gets used for which users.
3. Create the Access Policy Rule
Go to Policy > Access Control > Access Policy and add a new rule. This is the step that actually enforces the anchoring.
Rule Name — Name it clearly. Something like Allow-FinanceApp-SourceIPAnchor tells anyone reading the policy exactly what it does and why it exists. Generic names like Rule-47 or New Rule become a maintenance problem.
Rule Order — This matters more than most people realise. ZPA evaluates rules top-down and stops at the first match. If you have an existing broad rule that already matches your users and this application, it will fire before your anchoring rule ever gets evaluated. Place the anchoring rule above any broader rules that could match the same users or applications.
Status — Enabled.
Conditions — Define who this rule applies to. You probably do not want to anchor every single user through a specific connector — only the users or groups that actually need consistent source IP. Common condition types:
- SAML Attributes are the most common approach if your IdP passes department or role attributes. For example,
department = Finance. - SCIM Groups work well if you are syncing groups from Azure AD or Okta. Select the specific group that needs access.
- Posture Profile can be layered on top if you also want to enforce device compliance alongside anchoring.
- Client Type — if this should only work via ZCC (not browser access), restrict to the ZCC client type here.
Keep conditions as specific as needed. Overly broad conditions mean more traffic gets forced through a limited connector group unnecessarily.
Applications — Select the Application Segment or Segment Group for the target application. Do not select a broad segment group that covers unrelated applications unless you intend to anchor all of them through the same connector.
App Connector Group — This is the field that enforces anchoring. Select only the dedicated connector group you created in step 1. Do not add additional groups here. If you add multiple groups, ZPA treats it as load-balancing across all of them, which is exactly what you are trying to prevent.
Action — Allow.
Save the rule.
4. Confirm Rule Order
After saving, scroll through the Access Policy list and confirm the new rule sits above any existing rules that cover the same users or applications. If the order is wrong, drag it to the correct position and save the order.
5. Notify the Application Team
Before testing, give the application or firewall team the App Connector’s private IP (or both IPs if you have two connectors in the group for HA) so they can allowlist it on the application side. If the allowlist is not updated, the connection will reach the application but get rejected there, and it will look like a ZPA issue when it is not.
Tell them: all ZPA user sessions for this application will now originate from that IP. If a second connector is in the group for redundancy, both IPs may appear as source.
6. Test
Have a test user access the application through ZCC. Confirm access works, then check the application server logs or firewall logs to verify the source IP is the App Connector’s IP — not the user’s real IP and not a Zscaler cloud address.
In the ZPA Admin Portal, check Analytics > Users or your SIEM log stream to confirm the session used the correct App Connector Group.
Troubleshooting
Application still sees varying source IPs — A broader Access Policy rule is matching before the anchoring rule. Review rule order and move the anchoring rule above any rules that could match the same users and application.
User cannot access the application at all — Check the connector status in the portal first. If the connector shows as Connected, the issue is likely a network path problem between the connector and the application server. Verify the connector can reach the app on the required port.
Anchoring works for some users but not others — The conditions on the rule are excluding some users. Check the SAML attributes or SCIM group membership for the affected users against what the rule expects.
Multiple connector IPs are still appearing in app logs — More than one connector group is selected in the Access Policy rule. Edit the rule and remove all but the single anchored group.
Connector shows Connected but app is unreachable — There is likely a firewall rule between the connector and the application server blocking the traffic. Confirm the app port is open from the connector’s IP to the server.