Is it « proxy chaining » when using Client Connector + forwarding profile?


I’m trying to setup zscaler connector on a LAN using a http proxy (squid).

I’ve read this part of doc : Choosing Traffic Forwarding Methods | Zscaler

I was thinking at first i had to setup proxy chaining.

Now, i’m not sure. As we are using zscaler client connector , i think it’s more like setting up a forwarding profile.

So to sum up, with zscaler client connector and an http proxy, all i need to do is to enforce the proxy in the forwarding profile.

Zscaler Mobile → Administration (top menu) → Forwarding profile (left menu)

Can you confirm, please ?

Thank you.

Proxy chaining is not recommended nor required when using the Zscaler client connector. Traffic will be forwarded to the Zscaler proxy with just ZCC, with the option of a PAC file to provide flexibility and control of the traffic forwarded to the Zscaler cloud, most often to provide a simple method to bypass the Zscaler cloud for certain destinations and hardcode a specific proxy location you would like a client to go to (e.g. have traffic stay within a particular country or region, use a specific proxy for testing, specify a sub-cloud for data compliance requirements). The PAC file can be specified in either the app profile or the forwarding profile with the latter providing additional flexibility and the option of on/off corporate network criteria.

1 Like

Thank you for your reply.

If i sum up:

using ZCC means « no need to use proxy chaining ».

But, if ZCC gateway is a proxy, should i set up « proxy forwarding » this way ?
Zscaler Mobile → Administration (top menu) → Forwarding profile (left menu)

Is there something to do for making ZCC use the proxy server ? It only tries direct
connection. Even when setting globally windows to use proxy server.
For example, typical connection attempt of ZCC :

source dest proto ports
(my_ZCC_host) TCP 50186 → 80 [SYN] (my_ZCC_host) TCP 80 → 50186 [SYN, ACK]
(my_ZCC_host) TCP 50186 → 80 [ACK]
(my_ZCC_host) HTTP GET /generate_204 HTTP/1.1 (my_ZCC_host) TCP 80 → 50186 [ACK] (my_ZCC_host) HTTP HTTP/1.1 400 Bad Request (text/html) (my_ZCC_host) TCP 80 → 50186 [FIN, ACK]
(my_ZCC_host) TCP 50186 → 80 [ACK]
(my_ZCC_host) TCP 50186 → 80 [FIN, ACK] (my_ZCC_host) TCP 80 → 50186 [ACK]
(my_ZCC_host) (my_proxy) TCP 49851 → 3128 [ACK]
(my_ZCC_host) TCP 50187 → 443 [SYN]

Does it means a http proxy is not enough ? Socks proxy ?

I’m probably misunderstanding your question, but I’ll clarify what I mean and hopefully, I can figure out what you’re asking. :wink:

The ZCC agent allows for directly connecting the client to the Zscaler cloud proxy. No need for any additional configuration in the forwarding proxy or elsewhere to do that. You can also tunnel from a device that supports IPSEC/GRE directly to the Zscaler proxy and all clients behind that device can be direct to the Zscaler proxy without any ZCC agent on the client or you can use ZCC and the network tunnel and the network tunnel is what directs traffic to the Zscaler proxy (in that case the ZCC agent is there to get more information about the client, authenticate through the Zscaler cloud, and directly connect to the Zscaler cloud when the client leaves the corporate network and doesn’t have the IPSEC/GRE tunnel to get to the Zscaler proxy and doesn’t want to backhaul all the way to the corporate network).

That’s it. There is no reason to “configure a proxy” on the client, in the browser or in the ZIA Admin console, or the Mobile Portal / Forwarding Policy. If you choose to Enforce Proxy as an option in the Mobile Portal, that’s because you intend to use a PAC File and enforce only that PAC file, it only applies to HTTP/S traffic, and doesn’t employ the same traffic forwarding as tunnel or tunnel + local proxy options (btw, tunnel is the default).

If you are referring to a 3rd-Party proxy (e.g. Microsoft ISA or generic Squid proxy for example that you want to send after you send to the Zscaler proxy), you would configure that in the ZIA Admin Portal as described here. That will forward to a second proxy, but for performance, compatibility, and complexity issues, it’s not a best practice, but good for a transition from older legacy technology to the zero trust exchange approach Zscaler offers.

So, I guess the question is: what is “my_proxy” in your trace? 3rd-Party proxy solution? If so, the procedure below is what you are looking for and not the forwarding method in the Mobile Portal.

1 Like

Thank you for your answer.
Yes i’m using squid proxy on the gateway.

I had already followed instructions in the link you gave me, but something seems go wrong.

I’ve opened a ticket with assistance, but thank you again for taking time.

No problem. Hope it helps and I’m sure support can walk you through the process again and figure out what the issue is.

BTW: I did notice one area that may be a simple fix. Are you sure the is the right URL based on your cloud. If you do an will tell you which cloud you are accessing. For instance, if it said: You are accessing the Internet via Zscaler Cloud: Los Angeles in the cloud, you would enter: ${}

I think gateway hosts are geolocalizing the host requesting. zscalertwo is imho a backup of

~$ for host in; do printf "%s : %s\n" $host $(dig +short "$host"); done : :

So this range is for France. But if you do the same from your PC (or just ping them if you don’t have dig on your PC), you will get IP in the range of your geographic area.