Hi there,
I recently inherited a zscaler setup that I am learning as I am going. I am hoping someone here with more experience could clear up some confusions I have in regards to ZCC.
So, for context we have GRE tunnels setup at all our internal sites, and then have 2 test sites with ZCC installed on endpoints. We are using tunnel 2.0 (tunnel only) with a redirect of web traffic to the ACC listening proxy. As far as I am aware from reading forums and docs, this redirects all http/https traffic to the ZCC tunnel 1.0 listening proxy? So all traffic from the computer to the client will be treated as tunnel 1.
On the App profile connected to the forwarding profile we have a PAC file with some bypasses for zscaler updates, and region locking our region to its appropriate proxy. In addition we are using the VPN bypasses.
Our users are having issues with 401 unauthorized requests when ZCC is installed which I assume is related to proxies and the way packet are being formed(?)
Anyway, my question is. With the Redirect Web Traffic option, are all bypasses suppose to go through the .PAC file? From my understanding, which could be wrong, the VPN bypasses are host only and ONLY for tunnel2.0 traffic, so any 80/443 traffic wont get applied to any bypass configured there?
General best practice for bypassing is to use a PAC-based bypass for any 80/443 destinations, and a combination of IP-based or custom application-based bypasses for any tunnel 2.0 exclusions. Managing a number of bypasses or FQDNs that resolve to multiple IPs using the VPN gateway bypass is not best practice.
I would also suggest enabling the WFP driver and requesting flow logging enabled for ZCC so you can track bypassed transactions.
Regarding the tunneling stuff, sounds like there’s some at architectural design work you may need to consider at a higher level. Generally speaking, best practice for Tunnel 2.0 is to let that traffic go direct to Zscaler, and have a policy based route to forward any other traffic to your GRE tunnel while excluding that ZCC traffic, if that makes sense.
Tunnel1.0 is basically the old Proxy style of doing things, where each session spins up a separate HTTPCONNECT tunnel. You can, in theory put these over GRE tunnels, but that’s not recommended.
Tunnel2.0 is more like a VPN, where it’s a persistent packet-based tunnel that all your traffic (destined to the internet) goes. This traffic should not go over GRE tunnels, as that can create issues.
Are you trying to send all ports and protocols through ZIA?
I think that makes sense to me, what about disabling tunnel 2.0 and 1.0 completely on ZCC when on a defined trusted network? All traffic will be going through ZIA via GRE at all sites.
Then when off-network tunnel 2.0 is active, which usually is at home so all traffic would be direct to Zscaler through the internet, no double tunneling.
This is how I imagine a more proper setup would be, other than what you mentioned with policy based routing specific traffic to avoid the GRE
Is there any downside to this setup, my understanding is that tunnel 2.0/1.0 is just another way to get through ZIA?
Hey! Thanks for the response. Yes so we are sending all ports and protocols through ZIA with tunnel 2.0. This is an intentional design for us.
I had my doubts about the tunnel being always on, even when on trusted-networks. I will campaign to have that changed to off.
However what I’m most curious about is how bypassing works. So we bypass all 80/443 traffic to ZCC through the 1.0 listener. I understand to bypass domains completely we need to use the app profile .PAC file. If we bypass using the built in VPN Gateway bypass, does 80/443 still follow those rules?
And one last question, does every port that isn’t 80/443 also go through the app profile .PAC file? If so, why do I need to redirect 80/443 as tunnel 1.0.
Hope I am making sense, I am still a noob with zscaler so please feel free to tell me I am misunderstanding something.
You can do it that way for trusted network, but splitting that traffic off of the GRE gives you a lot more headroom and flexibility by just letting ZCC do the same thing. Will also simplify any troubleshooting from a client perspective.
I don’t really know the size of your deployment and scale may not matter as much, but larger customers (say >10k users egressing from a single site) gain a tremendous advantage in reducing total traffic volume over GRE
I’m confused about what you’re trying to do. If you’re sending everything Tunnel2.0, then why are you redirecting or bypassing 80/443 traffic?
Most customers have Tunnel2.0 on at all times, and give no internet access from local networks, other than to Zscaler and bypassed apps. This way, your users and infrastructure are always going through ZIA.
The other ports won’t be impacted by the PAC, since that’s just for web traffic forwarding. You shouldn’t have to do much with the PAC in a Tunnel2.0 deployment.
Ok thank you for your suggestions and expertise! Appreciate it greatly. I have a good amount of work ahead of me taking ownership of this environment.
To answer your question about size, we are a school board spread over 70 or so sites. Our biggest site would be ~2,000 users going through GRE where the average may be closer to 500, with ZCC only deployed out to 2 sites so far, the rest are GRE only. So the traffic throughput is not much of a concern, however you make a great point about flexibility and troubleshooting.
There is a best practice page from ZScaler about bypassing web traffic on tunnel 2.0.
Under version3.8 and later, the setting they refer to turning on bypasses all http/https traffic and sends it to ZCC as tunnel1.0 instead of tunnel 2.0.
As for why, some of our clients are getting 401 unauthorized responses from web servers when the packets are going through ZCC. GRE to ZIA works no problem, it’s only when it goes through ZCC.
The idea here is that I’m trying to bypass these websites from being proxied through ZCC while I figure out why the web servers are sending back the 401
Ha, I probably know or onboarded your account SE. Reach out to your account team, they can point you toward resources to help.
That’s an option you can do, if you want to be able to use the App PAC to bypass web traffic. Most customers just use ZCC with tunnel2.0 and bypass very few sites, so that’s not an issue.
You should be able to see the ZIA logs for the traffic and get more info on the traffic. It’s likely you have different policies for GRE (typically only servers and IOT) and user based traffic (typically ZCC), so you may be able to identify the issue that way. If not, you can always run a capture with ZCC and get deeper info.
Bypassing, especially from PAC, should always be your absolute last resort, as it’s going to be so hard to get that back in.