Difference in use of "App Profile PAC file" and "Forwarding Profile PAC file"

Hi,
I have some difficulties in understanding the different “use-cases” of “App Profile PAC” and “Forwarding Profile PAC”

My customer likes to use ZAPP with filter driver and tunnel mode.

Due to customer requirements, we need to send traffic not only Zscaler but some traffic needs to be sent to “on-site proxies”, for example “PROXY <RFC 1918 IP address>:8080”; or “PROXY proxy.acme.com:8080”; ( we call this “proxy switching”)

I checked the availble documentation here
https://help.zscaler.com/z-app/configuring-zscaler-app-profiles
and here
https://help.zscaler.com/z-app/configuring-forwarding-profiles-zscaler-app (with the enforce Proxy settings) but I did not find clarification.

  • What exactly is the different use of the pac files in forwarding profile and app profile?

  • I understand that App Profile PAC is only used by ZAPP and used for selecting a specific ZEN; and for bypassing the ZTunnels

  • Forwarding Profile PAC will be applied as “System Proxy” beside ZAPP?

  • Nils from Zscaler told me, that “proxy switching” needs to be done in the “Forwarding Profile PAC file”

  • But how do I get traffic to Zscaler, if we are using a PAC in the forwarding profile. Do I have to use ${ZAPP_LOCAL_PROXY}"? My first assumption was that this variable can only be used if “tunnel with local proxy” is used.

  • Do I need the same “DIRECT” exceptions in both PAC files? If not, which exceptions to put where? Both ZAPP training slides contain “Optionally specify Z-Tunnel bypasses” “App Profile PAC file” and “Forwarding Profile PAC file”.

Thank you and best regards
Andreas

2 Likes

Forwarding profile PAC applies only to Tunnel with Local Proxy and Enforce PAC modes. Tunnel mode does not use a forwarding profile PAC.

Forwarding PAC is what directs OS/Browser traffic toward Z-App, other proxy, or direct. App profile PAC directs traffic toward Zscaler Service Edge or Direct.

Tunnel with local proxy:
Browser ==> Forwarding PAC ==> Z-App ==> App profile PAC ==> Zscaler Service Edge

Tunnel mode:
Browser ==> Packet Filter/Z-App ==> App profile PAC ==> Zscaler Service Edge

You could use On Trusted Network to select TWLP forwarding mode and set a Forwarding PAC to handle these exceptions for other proxies. Off Trusted Network could use Tunnel mode. Both modes support the packet filter driver.

Forwarding PAC

// Conditions for local proxy selection....
RETURN "PROXY somelocalproxy:80;";

//Default forwarding to Z-App
RETURN "PROXY ${ZAPP_LOCAL_PROXY};";
13 Likes

Hi,
thank you for your answer.

I will do further testing based on that.
Best regards
Andreas

Hi,
my customer is now about to roll-out the Zscaler Client connector.

We are now wondering about the exception we need in the App profile PAC and the Forwarding Profile PAC.

In the Forwarding PAC we definitely need to have the exceptions that use the “different proxies”.

But what about the “DIRECT” exceptions. Do we need these exceptions only in the forwarding pac or also in the app profile pac?
If only Browser/System proxy applications are used, it should be sufficient to have the exceptions only in the forwarding pac.
But what about “systemproxy-un-aware” applications, like any winhttp?
Such application should never see the forwarding pac. That may require the same exceptions in the app profile pac?

Best regards
Andreas

Tunnel with local proxy:
Browser ==> Forwarding PAC ==> Z-App ==> App profile PAC ==> Zscaler Service Edge

Tunnel mode:
Browser ==> Packet Filter/Z-App ==> App profile PAC ==> Zscaler Service Edge

Hi,

you also mention that a Forwarding PAC is only used in “Tunnel with local proxy” mode.

What happens if I select “Tunnel” and configure also a pac in the forwarding profile?

Thank you and best regards
Andreas
tunnel

Hi,
we have now almost completed our test with successful results:
Zscaler Client Connector with
Forwarding Profile

  • Packet filter driver
  • Tunnel with Ztunnel 1.0
  • System Proxy Settings: Enforce/Use Automatic Configuration Script: httx://pac.zscloud.net/acme.com/zcc_fp.pac
  • always on

The PAC file zcc_fp.pac contains exceptions for all URLs that require a different proxy.
(During tests we found out that an internal SharePoint returned a “401 unauthorized”, perhaps due to issues with IE 11 Security Zones. So we have also DIRECT exceptions for that SharePoint.)
The default return statement is: return “PROXY localhost:9000”; // that is the proxy listener of ZCC
The Macro does not work in “Tunnel-mode”.

AppProfile for Windwos:
We have activated all switches and we have configured the VPN bypass as well as the pac file:
httx://pac.zscloud.net/acme.com/zcc_app.pac
zcc_app.pac contains all direct exceptions including the authentication exceptions for our azure AD as well as the return statement for the ZIA PSE.

Best regards
Andreas

1 Like

This made my life easier. Finally understood the difference with PACs in profiles and apps. Thanks!

1 Like

Hi,
we have now completed our test with successful results:
Zscaler Client Connector with
Forwarding Profile

  • Packet filter driver
  • Tunnel with Ztunnel 1.0
  • System Proxy Settings: Enforce/Use Automatic Configuration Script: httx://pac.zscloud.net/acme.com/zcc_fp.pac
  • always on

The PAC file zcc_fp.pac contains exceptions for all URLs that require a different proxy. It is “automatically configured” in the Browser (aka WinINet Systemproxy). Applications that do not use the IE settings (aka WinINet Systemproxy) are not aware of that pac file.
Originally I used return “PROXY localhost:9000” as return statement since macro does not work in Tunnel-mode.
After “more thinking” we now just use “return DIRECT”. “Direct” causes traffic on port 80 or 443 and this traffic is subsequently “catched” by Zscaler Client Connector in Tunnel Mode.
This also allows us to remove the SharePoint exceptions, since all traffic is sent DIRECT from a browser perspective (Direct = Transparent Proxy; “PROXY localhost:9000” = Explicit Proxy).

AppProfile for Windows:
We have activated all switches and we have configured the VPN bypass as well as the pac file:
httx://pac.zscloud.net/acme.com/zcc_app.pac
zcc_app.pac contains all direct exceptions including the authentication exceptions for our azure AD as well as the return statement for the ZIA Public Service Edge.
Remember, “return DIRECT” in AppProfile PAC means “bypass Zscaler”.

Best regards
Andreas

Hi,

There’s something I’m missing with that answer.
I found this in the Zscaler documentation on Forwarding Profiles/Tunnel mode:

Capture d’écran 2021-09-15 à 11.17.02

Isn’t it contradictory to what you said ?

And we have indeed a configuration with a PAC file which I can see in my windows proxy settings (the forwarding profile’s pac file). So does it mean that the pac file is pushed, but not used ?

Thanks,
Sébastien

Hi
is it contradictory?
In our tunnel 1.0 environment, we are using “Tunnel” in the forwarding profile with a hosted pac file in “Use automatic configuration Script”. This is named zcc_fp.pac.

The zcc_fp.pac does basically:
For some URLs: return “PROXY proxy1.acme[.]com:8080”; //bypass traffic away from Zscaler Client Connector
for some other URLs: return “PROXY proxy2.acme[.]com:8080”; //bypass traffic away from Zscaler Client Connector
by default: return “DIRECT” //tunnel traffic to Zscaler Client Connector

While some URLs are sent to proxy1 and proxy2; while DIRECT basically means use Zscaler Client connector to forward URLs to Zscaler. These URLs (i guess*) may also use non-standard ports.

In the windows proxy settings I see a pac hosted locally 127.0.0.1:9000/systemproxy-xyz.pac.
If I “download” this pac, it is the zcc_fp.pac.

*When this systemproxy-xyz.pac / zcc_fp.pac is not configured in the windows proxy settings and an URL like httX://foobar.com:4711 is accessed, this URL would not be forwarded to Zscaler, since the client connector tunnel 1.0 only processes port 80&443 // This is commonly used to get web traffic on nonstandard ports when in Tunnel mode. Update: Thinking a second time about this, you may need something like “return 127.0.1:9000” to send non-standard ports to zscaler. This is similar to ${ZAPP_LOCAL_PROXY} in TWLP mode. I think I need to test this. :slight_smile:
Best regards
Andreas

A post was merged into an existing topic: Sharepoint 401 unauthorize error on Tunnel 2.0

Hi,
(Disclaimer: never worked with ZPA, so my ideas are from ZIA) :smiley:

401 is issued by the server due to failing authentication. As I mentioned in a previous post, using “DIRECT” helped us to avoid this but never investigated the reason. :slight_smile:
I found this - and actually hijacking this thread. :innocent:
Per-site configuration by policy | Microsoft Docs
Maybe it helps to configure the SharePoint site?
" By default, Microsoft Edge evaluates URLACTION_CREDENTIALS_USE to decide whether Windows Integrated Authentication is used automatically, or if the user will see a manual authentication prompt. Configuring the AuthServerAllowlist site list policy will prevent Zone Policy from being consulted."

Update for my Tunnel 2.0 configuration…

Hi,
what I have done in my Tunnel 2.0 configuration:

Pacfile used in App Profile:

  • return “DIRECT” for URLs that bypass Zscaler

  • return “DIRECT” for URLs that should use “my personal explicit Proxy”

  • return “PROXY ${GATEWAY_FX}:443; PROXY ${SECONDARY_GATEWAY_FX}:443;” //for everything else - with this statement you can configure the ZEN node, either with Gateway Variables or a specific ZEN; you can also have a conditional selection, if you evaluate the ${COUNTRY} Variable, for example.

Pacfile used in Forwarding Profile:

  • return “PROXY ${ZAPP_TUNNEL2_BYPASS}”; for URLs that bypass Zscaler

  • return “PROXY w.x.y.z:3128”; // IP address of my “personal explicit proxy”

  • return “DIRECT”; for “all” traffic that uses Zscaler

Destination Exclusions in App Profile:

  • IP address of my “personal explicit proxy”
1 Like

A post was split to a new topic: Sharepoint 401 unauthorize error on Tunnel 2.0

Moderator Closed

The original topic was answered. If there are other issues, please create a new topic that highlights current issues so we can provide the most up-to-date solutions!

Thanks