ZPA-ZIA - Keeping Source IP - SIPA

Greetings community,

I have been reading some posts about IP anchoring and I am really confused.

Is IP Anchoring designed to keep my own public IP (configured in our edge firewall outside interface) for my local traffic when destined to internet? (Note I am using ZIA and ZPA)
Let’s say I want to access the public website www.acme.com, but acme is expecting my traffic coming in from my company’s public IP, since I am using ZIA, acme will see that traffic coming in from Zscaler, so it will block it, Will IP Anchoring solve this scenario or not?
If that is the case, what would be in my example the IP or subnet or FQDN for the Application segment?
That really confused me because The Application segment seems to be everywhere in the SIPA configuration, in the very first step and at the end, where it confuses me the most, since is both the destination and also is included in the ZPA Gateway when forwarding the traffic to ZPA.

Could someone clarify for me, if I want my internal traffic (i.e., from subnet to go to the internet (i.e., to www.acme.com) while keeping my external IP considering that I am using ZIA, if SIPA is the way to go, and if it is, what am I supposed to put in the App segment?, www.acme.com???
Any clarification will be highly appreciated,
Be safe!!

Hi Josh,

With using ZPA SIPA with ZIA, the traffic is forwarded to ZIA, inspected as normal, and then forwarded over ZPA, from the ZIA public service edge towards an app connector where it will be egressed out likely via a NAT boundary which includes your organisations public IP address.

For http/https traffic this is forwarded via the same way that you would forward traffic to ZIA from a location. Such as PAC file, Tunnel, Client connector using ztunnel1 or 2. For road warriors or home workers this feature requires traffic to be forwarded to ZIA using ztunnel 2.0

Providing the feature is enabled on your tenant you simply configure an app segment for source IP anchored applications, or perhaps for the specific application include an application such as www.acme.com, or this could even include a *.acme.com, with the destination ports that are required for the application. Ensure that source IP anchor is enabled for the application segment. I tend to place the application segment into an application segment group for SIPA, which I apply to the client forwarding and access policy later. I also create a server group with dynamic discovery just for Source IP Anchoring.

Next configure a client forwarding policy in ZPA matching on the application segments with a rule action of Only Forward Allowed Applications, to ensure that the traffic isn’t forwarded via ZPA directly from the client connector

Then configure an access policy to permit the traffic, matching ZIA Service Edge, and the application segment.

As the application segment has been configured with Source IP anchor enabled, the application segment will be synced into your ZIA tenant, and available for configuration within ZIA forwarding control.

First add gateway for ZPA within ZIA admin portal, under administration, Forwarding methods Zscaler private access., and select the server group you created earlier, you will see the application segments populate.

Then configure ZIA forwarding control, under policy, ZIA forwarding control. Select the forwarding method as ZPA, and select the application segment, or segments, with action to forward to the ZPA gateway (the ZPA server group you created earlier). You can match based upon location etc.

At this point you should be ready to test, and will see within the live logs for ZPA traffic originating for the ZIA service edge, additionally ZIA transaction logs have a log field for forwarding method, forwarding rule, Application segment, gateway name, to show that this traffic is forwarded to ZPA.

It is also possible to forward non-web traffic via ZIA and then onwards to ZPA for SIPA. However this requires that DNS control policy has been enabled to resolve traffic so that it is forwarded to ZPA via ZIA.

Example guide is available below.



Thank you so much Dan, this is a really good explanation, I did not know that we were able to use a public FQDN in an app segment for starters, I guess the private part of ZPA tricked me.

Very helpful. Thank you!!!

Hello Dan,
I think I am missing the last piece of the puzzle to understand this.
When the traffic is forwarded from ZIA->ZPA->App connector-> Internet, how come it does not get forwarded again to ZIA->ZPA>… in an endless cycle???
if I have a default route ( over my GRE tunnel with Zscaler, what guarantees that the traffic that was forwarded to the App connector and it is supposed to go directly thru my NAT edge device this time, does not go thru Zscaler this 2nd time as it did the first time??
Obviously, it does not happen, because this works, but I dont get how.

HI Josh,
Your router is likely configured so that the app connector does not follow the route to forward traffic over the GRE tunnel. This is likely performed by policy based routing to exclude the app connector from being forwarded over the GRE tunnel.

1 Like

Ohhh, got it, it all makes sense now, GRE tunnels are still pending, but yes, we need to send the app connector traffic directly to the Internet, no thru ZIA.

Thanks again Dan!! Never another community forum has been so helpful to me like this one.

I really appreciate your time in helping me and I hope it will help other people in the future too.


Hey @dhume :slight_smile: HNY :slight_smile:

Thanks for the above. We’ll be testing this in production, as we’d really like to get rid of VZENs and complex PAC logic. This seems like an appropriate solution. Although I was aware about it for quite some time, its configuration is indeed a bit confusing to grasp, your post explains it very clearly and now it makes sense.

We’ve just attempted this configuration, but missed the step with Client Forwarding Policy… because of that my ZCC with ZPA On was sending traffic via ZPA the moment app segment was configured… and I was wondering what takes precedence and how to predict. But, now with Only Forward Allowed Applications in place… it always takes ZIA-ZPA path and is predictive.


Hi Tym,

Hope you are well. ZPA client forwarding policy will take precedence. Traffic directed to forward to ZPA will “win” over traffic forwarding to ZIA

Pleased you found my post and it helped!

Thanks @dhume

Can you please clarify this sentence of yours? :slight_smile:

I’ll correct that typo :wink:

If you specify a client forwarding policy in ZPA to forward an application to ZPA, the client connector will be instructed to forward this traffic to ZPA, when previously it would’ve been forwarded to ZIA.

Exception to this would be when forwarding via TWLP, or there is a PAC file in the browser and the client doesn’t not intercept the DNS request and resolve to 100.64.1.x address. The PAC file in this forwarding method would have to have logic to resolve host, and if resolve to carrier grade NAT then the traffic is bypassed.

1 Like