Case 1: Website not working:
Check if the website works at your end on your machine/mobile. Use the website https://geopeeker.com/ to check if the website works from different geo-locations.
a. If the website works at your end and not at the customer’s end, this would mean Zscaler is the cause of the problem. Check the category of the website before doing any SSL/Auth bypass, since a few categories are already added in the Auth/SSL bypass, and adding the website explicitly would not make any difference.
b. Take a header trace from the F12 Developer tools in the browser to see for any redirection. In case you see other domains, check the category of those domains and try adding the redirected domain in SSL/Auth.
c. If the website still does not work, check if it is working from any other customer site. If it works at another location, it is probable that the Zscaler public node of the affected location is blocked at the webserver end. In such cases, redirect the website to another node in the PAC file or ask the user to work with the webmaster to unblock the Zscaler IP.
d. In case the issue is with all locations/sites, ask the user to install Wireshark on their machine. Collect Wireshark captures and header trace with and without Zscaler. Look at the captures, and in case you are unable to find anything, raise a case with Zscaler and provide all details. Use the following when raising the case:
sql
Copy
1. Output of ip.zscaler.com 2. Collect web insights logs for the user and affected website 3. Wireshark and header trace with and without Zscaler
e. In case the website is internal to the customer environment, it may not work via Zscaler since there would be no DNS resolution. In such cases, the website needs to be bypassed from the PAC or sent to Private Zen in the PAC file.
Case 2: Issue with Application while using Zscaler APP:
To determine if Zscaler is the cause, turn off the Zscaler app on the user machine and check if the application access works. If it works, Zscaler is the problem.
a. Ask the user if they are aware of any URLs bound to the application. If they provide URLs, check the category of the website before doing any SSL/Auth bypass, since a few categories are already added in the Auth/SSL bypass, and adding the website explicitly would not make any difference.
b. If the URLs are not known, ask the user to install Wireshark on their machine. Take Wireshark captures with and without Zscaler. Look at the captures for the URL domains. Try adding them in the Auth/SSL bypass if their domains are not added.
Case 3: Website has Source IP Restriction:
Some websites are not accessible via the open internet and need IP whitelisting at their end. In such scenarios, if the website is not working at our end, ask the user if they are aware of any IP restriction at the webmaster.
a. If there is an IP restriction, such websites need to be bypassed in the PAC file. The user needs to get the public IP whitelisted at the webserver end or get Zscaler’s public subnet bypassed if bypassing the website is not allowed.
Case 4: Website uses Non-Standard Port:
Some websites, such as https://icil-rams.ddns.net:89, work on a non-standard port (e.g., Port 89 over HTTPS). Zscaler App does not support traffic on non-standard ports and will send the traffic directly.
For the above case, if you are using a forwarding PAC file to redirect traffic to Zscaler directly and not via the app, use the syntax available in all forwarding PAC files.
Case 5: Slowness Issue with Zscaler:
Slowness issues can be divided into two parts:
Slowness with a particular application/website:
If slowness is with a particular application/website, isolate if the issue is caused by Zscaler or not.
The easiest way to do this is by turning off the Zscaler app if the user is using ZAPP or by removing the Proxy PAC. The traffic on ports 80/443 should be allowed on their network for this to work.
If the website works fine without any slowness, check if Zscaler is doing SSL inspection for the category or URL. If yes, bypass SSL inspection and try accessing again.
If the above step did not resolve the issue, download the ZMTR tool from https://zmtr.zscaler.com/.
Use the ZMTR tool to trace to the destination web server to find out the latency to the website. In some cases, latency through Zscaler may be high due to the geographical distance of the website from the Zscaler node. In such cases, if Zscaler is unable to help, traffic can either be redirected to another Zscaler node/PZen of the company or completely bypassed from Zscaler via PAC.
Slowness with all internet traffic:
In some cases, the whole site faces issues with internet slowness. In such cases, the first step is to check the health of the internet circuit and the utilization of the circuit. If both are normal, follow the below steps for Zscaler.
Go to https://trust.zscaler.com and select the domain on which the company is registered, such as Zscaler.net or ZscalerOne.net.
Image error
-Click on TAB Cloud status and Scroll down to see status of each Cloud Node
In the example above, we see that the Johannesburg node is all green, which means the status of this node is all good, and Zscaler has not reported any incidents on this node.
Moreover, we can also go to the Incidents tab to check if any incidents related to the node are ongoing, as shown in the example below for the NYC III Datacenter.
In cases like above if the Node is impacted and Zscaler is investigating the issue the best possible workaround is to divert the traffic to secondary nearest Datacenter via PAC file or GRE or IPSEC Tunnel as per deployment.
Step to Collect logs to send to Zscaler TAC for slowness investigation:-
1.Take screenshot of ip.zscaler.com
2.On ip.zscaler.com page click on Connection Quality and than click on start test.Download and save the results .
3.Goto Website https://zmtr.zscaler.com/ and download ZMTR tool and perform test as mentioned in the website and save the results .
4.Take Wireshark captures from the machine while browsing few websites.
5.Zip all Outputs/logs and upload it to the Zscaler case.