So we now have Private Service Edges, Cloud Connectors, and Branch Connectors. What really is the purpose of each? I’ve poured through the documents and it seems they all really do the same thing, in a way. Just not sure to be honest.
Esp. you want full disaster recovery options (ie ZS public cloud down) then you must have ZIA/ZPA-PSEs.
Also if you have eg a big office/factory footprint in LATAM (not in Brazil, not near Sao Paulo or Rio) then you want PSEs there as well; otherwise latency and stuff kills your performance.
Of course and as always also a matter of the price tag attached.
Well understood for the PSE’s, but what about the Cloud Connector and Branch Connectors? Why would I need those instead of the PSE’s?
Now I have one location on Guam that I’ve thought about a PSE, but is a Branch Connector the better choice at that location instead of going all the way to Japan or Indonesia for the nearest Zscaler DC?
Branch Connector and Cloud Connector both serve the same purpose: they are there to forward traffic from your network to the Zscaler Zero Trust Exchange.
I.e. BC and CC are used for traffic forwarding purposes only; no policy enforcement occurs on these machines. The critical difference in BC vs. CC is that BC is deployed on a branch and carries traffic from your branch to the Zero Trust Exchange. In contrast, CC is deployed on a cloud environment (e.g. Azure or AWS) and carries traffic from that cloud environment to the Zero Trust Exchange.
ZPA PSEs use your company network to bridge connections between a user (Client Connector) and the application (App Connector). By default, that function resides inside the Zscaler Zero Trust Exchange, but you can bring that function into your network to serve certain use cases. For example, let’s say you are using ZPA for on-prem users, and those users need to access an application on the same company network or an application only a few hops away. In the default scenario, that traffic would follow this path: Client Connector (local) → Service Edge (cloud) → App Connector (local). As you can see, the internet connection at that location might become a bottleneck if a large amount of data is transferred because all that traffic needs to go out to the Zero Trust Exchange before returning to the network to reach the App Connector. In those scenarios, deploying a Private Service Edge (PSE) will ensure your traffic remains local to the network: Client Connector (local) → Service Edge (local) → App Connector (local).
I hope that helps.
This is an interesting topic.
We are in the process of selecting a cloud security solution and Zscaler is high on the list of prospects.
What we really need to understand is the amount of bandwidth our local devices send/receive and the best way of calculating this as there is an additional charge for local branch connectors which I believe is based on bandwidth usage. We need more clarity and transparency on this subject, as so far looking at the resources available to us, it is not super clear.
I understand that we will need a branch connector which is a VM device on the local branch for devices that cannot install a client connector for authentication. So devices like IOT, Printers, and some servers… So the Branch connector will be using location-based Identities which we will allow based on Location, IP address, Mac address, etc. If a client connector is installed on a device then this won’t count towards the bandwidth as this will be part of the user cost .
I Just need to try and get to the detail so we understand our true predicted costs as if we are not careful these could add up.
Anyways, as you can see I am still learning, and maybe I just need more clarity and understanding in Branch connectors, so any advice on this would be most appreciated. As I am on the journey and really want to understand the detail on this part. I am still going through the forums and still trying to get upto speed
Very nice explanation, the best so far and should be part of the docs because no where does it make the distinction that the CC is for cloud install.
So, how does the BC/CC fit into the network, does it become the default gateway for the devices and if the device has ZCC then the traffic is just transparently passed on to the next hop?
I’m very interested in this because we have Zscaler and VeloCloud SD-WAN, with the VeloCloud Cloud Security Service (CSS) using an IPSeC tunnel to Zscaler to pass any unidentified Internet bound traffic to Zscaler. The struggles we have is that there’s no way for the VeloCloud to identify the ZCC Z-Tunnel 2.0 traffic effectively. What we’ve tried to do is use Windows Policy Based QoS to mark any traffic coming from the ZTunnel.exe process with a specific DSCP marking so that when the VeloCloud sees traffic with this marking, then it knows to steer it directly and not pass it through the CSS, avoiding the Tunnel-In-Tunnel issues. Problem is, this is not reliable as not all traffic can be marked by Windows for some odd reason, been working a case on that for 6+ months.
But my wonder is, can a BC resolve this issue for me by being able to send traffic coming from devices that does not have ZCC installed and sending that to Zscaler, but transparently dropping ZCC traffic back to the network for the next hop. If this is the case, then I can say any traffic coming from a BC will go direct to Internet and not hit the CSS, and confidently know all outbound traffic is being passed through Zscaler appropriately.
Are there any benefits to using BC over GRE tunnels on our routers?
We are looking at using ZIA from our offices with 10Gb internet access and have been working out how we build multiple 1Gb GRE tunnels that are required for ZIA, does using BC make this any simpler?
If you use ZCC, you wouldn’t need to build the GRE/IPSeC tunnels for all traffic, only traffic that does not have the ability to run ZCC. This would reduce the amount of tunnels needed in order to support ZIA on those devices. Now the BC is something of a mystery and I admit that may change the conversation to make that the method for ZIA forwarding on-prem and still eliminating the GRE/IPSeC tunnel overhead. Not 100% clear on the role of the BC/CC.