Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I netadmin a school. The school connects to the outside world via a VPN implemented on equipment ouside my control (all in-school hosts have 10.x.x.x IP addresses). The only way out to the Web is via an upstream filtering proxy server that serves multiple schools.

The school has a local Squid proxy under my complete control, which all the school browsers are configured to use. It's currently set up to use the upstream proxy as its parent and pass user credentials through, except for a whitelist of domains and URLs for which I have Squid supply preset credentials. This allows me, among other things, to make selected YouTube videos accessible to students even though the upstream (domain-level) filter restricts YouTube as a whole to staff, and to let stuff like update checks happen quietly without pestering users for credentials at inconvenient times.

Upstream has recently decided to cut over from its ISP-supplied web filter to Zscaler, which doesn't seem to use HTTP authentication; it does some complicated browser-based dance with redirection, HTTPS and cookies instead.

Does anybody know of a way to configure Zscaler to require authentication credentials per request rather than per browser session, and to configure Squid to supply those?

share|improve this question
I don't have enough mojo to create a zscaler tag, apparently. Would be good if somebody who does could add one. – flabdablet Aug 14 '12 at 13:43
Done. Good luck with this problem. – tomfanning Aug 14 '12 at 13:51
up vote 2 down vote accepted

So it turns out there is in fact no reasonable way to do this and I need to resort to a kluge. Not too bad of a kluge, but a kluge all the same.

Zscaler can identify proxies that chain to it as "Organization’s Internet Gateway Locations". For requests arriving at Zscaler via proxy chaining from your organization's local proxy server, you can apply a default filtering policy based on the gateway location even if Zscaler hasn't done any cookie-based authentication. This is just as well, since end users can actually disable cookie-based auth simply by setting their browsers to use a bogus User Agent string.

The Zscaler site administrator can also create "sublocations", allowing default filtering policy to be set separately for multiple local proxies. Zscaler identifies the main location and all sublocations by the IP address of the proxy server that's chaining to it. This stuff is all in the Administration page under "Internet Gateways and SSL", and one of the useful options there is the ability to turn authentication off entirely for any given location or sublocation.

My school only has the one campus and the one Squid proxy server on that campus, but that proxy now looks like four from Zscaler's point of view. As well as the original IP address statically assigned to eth0 and registered with Zscaler as our Internet Gateway Location, it now has three more assigned to eth0:1, eth0:2 and eth0:3 with corresponding sublocations (squid, staff and student) set up on the Zscaler end, all with authentication turned off.

So now I can do all user authentication locally and use acl proxy_auth tags in squid.conf to mark users as staff or students and tcp_outgoing_address tags to choose the IP addresses that Zscaler will see my requests coming from based on my local user and site rules.

Three sublocations with local-only auth plus a main location with Zscaler auth left on (for visiting staff who come with their own Zscaler credentials) gives me as much granularity as I was using on our old filter, and hopefully my on-site users won't even notice that anything has changed.

share|improve this answer
Nice thing, this kludge. I had to do the same thing years ago when one of my educational Customers had an uncooperative upstream proxy (not ZScaler or anything like it) that couldn't handle any useful type of authentication. The upstream advised me to set static IP addresses on PCs for "staff" / "student", etc. I advised them that they could die in a fire and installed Squid w/ NTLM authentication and different tcp_outgoing_address settings. It worked great. – Evan Anderson Jan 31 '14 at 13:30

Done in Apache with the SetHeader module, with a user agent string for wget, works flawlessly. This bypasses authentication, as zscaler knows that wget could never do their nonstandard authentication.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.