We have been using ZCC fine for a while and have two use cases where the Zscaler Service is not meeting our requirements. The answer has traditionally been use a IPSec/GRE tunnel but we have hit two limitations:
We have many non-contiguous guest networks and we have reached the IPsec Client security association limit of 8 and Zscaler won’t increase so now we have to provision more hardware to establish additional tunnels and complicating our routing / site failover. GRE is not an option for us and is also not recommended
To complicate this a bit more Zscaler is to charge us for the ingress/egress GB per month for our guest traffic which is not a trivial cost. So
Traffic from our internal devices must be authenticated, this was fine for many years with an AD integrated on premise proxy as we had a log of HTTP 407 / 401s. The behaviour of the Zscaler service is to redirect unauthenticated requests to the iDP for authentication which device to cloud integrations can’t complete (AzureAD forms based auth) and Zscaler has no record of this attempt in the activity logs This makes it very difficult to identify all the urls a device is trying to reach so we can whitelist / remove auth.
So what are others doing, retaining a on-premise proxy appliance for logging/visibility? We also have many systems that point to our to be decommissioned on prem proxies so we need a device to bind these ips:port to. I have configured vips on a loadbalencer that forward to gateway.zscaler.net:80 and preserving the X-Forwarded IP of the client but the authentication issue above still complicates support
I have heard rumours that Zscaler may be developing a on-premise virtual proxy appliance that would forward to Zscaler but perform auth locally but not sure what the ETA is.
Keen to hear if other users have decommissioned their on-premise proxies or retained the service for infra integrations. As a side not all our user endpoints are always-on with ZCC.