Interesting! So is it correct to say that the machines have no direct route to the internet without the system proxy? In my experience it will attempt to use WinHTTP, but if there’s no definition there the traffic should go direct. I guess if it looks for WinHTTP, finds nothing, and then attempts to go direct with no route this would indeed fail.
Setting a WinHTTP proxy might work, but I guess it could cause some slowness, as traffic would need to be touched first by WinHTTP and then by Z App.
Are you using Tunnel with Local Proxy? You could also try Tunnel mode, as in this mode we just explicitly get web traffic without the need for the system proxy.
Additionally, you can disable this NLA checking process in Windows (though I understand this might not be desirable).
Hi David, Yes the machines have no direct internet access when onsite or via VPN it must go through zscaler.
onsite (trusted network) and for vpn zscaler app is configured to use ‘PAC enforced’
offsite (off-trusted network) is configured for ‘tunnel with local proxy’
I prefer not to disable the NLA service, it is useful so wanted to keep its functionality.
How does configuring the winhttp service with a proxy cause slowness? What I added was ‘gateway.zscaler.net:10171’ 10171 is our dedicated listening port.
Also did you answer my other question of is there a configuration I could apply in zap profile which will produce the same result?? at the moment I have ‘install zscaler ssl cert = on’ ‘disable loopback rest=on’ ‘override wpad=off’ ‘restart winhttp service=off’
So in Enforce PAC its a little different. So this makes more sense. Enforce PAC Z App isn’t actually tunneling anything, it’s just applying a PAC file to the system much like GPO would.
The reason I mentioned potential slowness with WinHTTP would be if you were using it with Z App. We leverage the WinINET proxy, which Microsoft applications typically look at after WinHTTP. So the traffic would leave an application, go through WinHTTP Proxy (then lets say it was bypassed) would go into WinINET proxy and then finally to Z App. This would be the case in Tunnel with Local Proxy.
Setting the WinHTTP to the gateway will work, but keep in mind if you leave this set when Z App goes to off-trusted network and then to tunnel with local proxy, the traffic is going to go to gateway.zscaler.net directly instead of to Z App (because the apps might follow WinHTTP first before WinINET proxy settings).
There’s no configuration in Z App that will set a WinHTTP proxy. As above, we configure the WinINET proxy.
Running Z App in Tunnel mode on-trusted network should work, as we will get all of the 80/443 TCP traffic from the system. Of course though, you can’t use the dedicated proxy port with this mode, so users would just come through as Z App users.
I gotta say I have been forced to use Zscaler for 3 days now on my Mac and it has been 3 days of hell.
Constant connection drops and internet drops making it near impossible to do my job.
This is intolerable!!!
Hi Anthony, I can’t tell from the screenshot what’s going on.
Have you, or has the service owner for your Zscaler deployment, opened a support ticket?
Since using zscaler I am getting constant drops connecting to internal servers and apps.
I caught it in a pcap so I hope somebody can figure it out before I break something.
Same problems here. This issue persists even today. Zscaler App will disrupt network access, but it does so in a way that is very difficult to investigate and understand. It seems that the app fails when a Mac is put into sleep mode. When a Mac is in sleep mode, it maintains a wifi connection. Zscaler seems to get tripped up by that and needs to be restarted every time a Mac comes out of sleep mode. Horrible user experience to say the least.