Hello, we want to access an address using Google Cloud services directly from our own local firewall. Only our local IP addresses are allowed to log into the site. That’s why we added this address to directhosts in Zscaler.
The problem starts here. There is no problem in accessing the interface of the site, but when we want to log in, we get the error that our IP address is not allowed. Although the address is apparently added to DirectHosts and passes through our local firewall, a few IP addresses still go through Zscaler in the background.
We found and bypassed these IP addresses from the Zscaler logs. However, we could not log in to the site again the next day because Google Cloud services changed the IP address.
Our problem was solved by using only PAC file without using Client Connector. Only the hostname is added in the PAC file.
But our employees have to use client connector, when we activate the client connector, we cannot log in to the website again.
What is the mistake we made for the Client Connector?
Thank you for your support.
It’s not a mistake with ZCC per se, as you know, it’s difficult to specify a static list of IPs with a variable list of IP addresses and a partial list of destination URLs. This sounds to me like an issue that would better be solved with either Source IP Anchoring (SIPA) or a Virtual Private Service Edge for ZIA. Adding the SIPA subscription (additional cost required) would redirect traffic from ZIA to a VM called an “app connector” in a location of your choice (local to your firewall or in the public cloud since the application is in the cloud as well). A virtual PSE would provide a VM specially designed to scan traffic the same way the public service edges you are connecting does, except they are hosted on your local network behind the firewall and require you route all or just Google traffic through it. Either way, it means you’re back at determining which destination goes through the local VM, which means you’ve got the same problem if the IPs for Google Cloud services change. The one alternative is to use the entire IP range which may or may not be manageable.
You may want to consider an Identity Proxy subscription instead of this approach, or better yet, re-evaluate what real security threat you are concerned with. It is relatively simple to determine your source IP and spoof it, so “traffic coming directly from your local firewall’s egress IP” is not really a strong security layer. And technically, it is coming directly from your local firewall from Zscaler’s perspective, so why not enable the required security policy for that traffic, along with exceptions for SSL decryption where appropriate and scan the traffic for threats, enabled SaaS protection, DLP, out-of-band CASB, compliance, and other data protection functions that truly protect that traffic beyond making sure it emanates from a particular IP address or bypassing security policy that would protect the traffic more than manipulating its source IP.
My apologies for going into so much detail, you could say this is a question I’ve addressed with many of my colleagues and customers for quite some time.
As Mark Harris suggested you have a few different options to try and resolve your issue. It sounds to me like you are restrciting access to a web service to a certain set of Source IPs that identify as “Your Company”. We have this all over the place as well and for that reason we have deployed Virtual Service Edges (VZENs) inside our network and direct traffic to these with a PAC file entry. These VSEs sit behind a firewall and their private IPs get NAT’d to publics IPs that are yours. So you get all the prtection from Zscaler, but its only used by your in your Network.
However, my stance on this is that using Source IP as a means to identify traffic is not “Cloud Friendly”. In a world where IPs change all over the place because services are hosted all over the show, source IP doesnt really cut it anymore. I try and make the argument to ditch the source IP identification and instead move the auth mechanism for the web service to SAML with 2FA. That way you can access it from wherever but use good authentication mechanisms to access the service, therefore protecting the sensitive content. You can also use your local internet breakouts to access the service, reducing backhaul on the WAN.
However, getting everyone to understand this and buy into it is proving very difficult!