Troubleshooting ZIA
Welcome to Troubleshooting ZIA! In hybrid work environments, users look for a satisfying digital experience, which includes fast, secure
connectivity and seamless collaboration. However, ensuring a smooth experience has challenges and requires e ective troubleshooting
skills.
This module will help you identify the root cause of issues and troubleshoot them e ectively.
COUR SE OVER VIEW
Introduction
Learning Objectives
FUN DAMEN TALS OF TR OUB LESH OOTIN G
Troubleshooting—Overview
Zscaler Support Ticket
Key Takeaways
UR L CLASSIFICATION
URL Classi cation—Overview
URL Reclassi cation
Key Takeaways
TR OUB LESH OOTIN G TOOLS
Standard Troubleshooting Tools
ZIA Troubleshooting Tools
Client Connector Logs
Key Takeaways
ZIA ISSUES
Localizing ZIA Issues: Troubleshooting ZIA Issues
Isolating ZIA Issues
Key Takeaways
SUMMAR Y
Recap
Lesson 1 of 16
Introduction
In this module, you will learn to solve issues related to URL classi cation,
understand the use of localizing and isolating ZIA issues, and familiarize
yourself with troubleshooting tools.
C O NT I NU E
Lesson 2 of 16
Learning Objectives
By the end of this module, you will be able to:
1
Comprehend the basic concepts of troubleshooting
2
Examine URL classi cation and rectify issues by reclassifying the URLs
3
Localize and isolate ZIA issues to identify the root cause
4
Solve common ZIA issues using troubleshooting tools
L E T ' S G E T S TA R T E D
Lesson 3 of 16
Troubleshooting—Overview
Let’s start by understanding the steps involved in the process of troubleshooting various issues that you may face.
This set of steps can help you narrow down the cause of an issue and enable a speedy response by identifying the root cause of the issue.
While troubleshooting is an important skill, documenting the resolution to the issue is equally important, as it enables the creation of an internal
knowledge base system.
Troubleshooting Process—Localize the Problem
The rst step in troubleshooting any connectivity issue is to identify precisely where the connection is failing and who is impacted by the failure.
With an internet access connection through Zscaler, an issue can occur in any of the following areas:
The end user’s device
Local network (either the user’s home network/corporate LAN or co ee shop, etc.)
Between the end user’s Corporate Firewall and the Zscaler Cloud
Between the end user and Zscaler directly
Between the end user and the identity provider (authentication issues)
Between Zscaler and the internet (i.e., the third-party website or service)

In the diagram, the primary and secondary tunnels are indicated by the colors green and red,
respectively.
Troubleshooting Process—Isolate the Problem
The second step is to isolate what logical process is failing, allowing you to identify a solution to the problem:
Are there network connectivity problems?
Is there a connection issue between speci c infrastructure entities?
Is there some form of miscon guration of either the network connections or a Zscaler policy?
Troubleshooting Process—Troubleshooting Cycle
The nal stage is to engage the troubleshooting cycle:
1
Form a theory as to what the problem is from the information you gathered in the previous steps.
2
Figure out how to test the theory (refer to internal documentation or your knowledge base).
3
Test the theory:
If the theory proves correct, step out of the process and document the solution.
If the theory is proved incorrect, go back to the rst step and work through the other possible causes of
the issue.
The troubleshooting process is a cycle.
If your hypothesis does not seem to t the data you are seeing:
1
Check your hypothesis.
2
Check with the end user and ask more follow-up questions about the issue.
3
Reiterate through the resolution steps after localizing and isolating the problem.
4
See if another hypothesis presents itself.
Finally, if you run out of options, escalate the ticket to the next support tier or to Zscaler, providing as much information as possible.
This information can include these details:
Steps and tasks undertaken
Performed tests
Test results
Let’s further discuss the Zscaler Support Ticket in detail.
C O NT I NU E
Lesson 4 of 16
Zscaler Support Ticket
Any ticket raised with Zscaler will require the following information:
Issue Subject: Provide a summary of the problem with the main symptom and scope. This is a free-text eld; it should be as
concise as possible but give a complete indication of the nature of the problem.
Description: Provide a detailed description of the problem. This is a free-text eld that allows you to fully explain what the nature
of the problem is, what its symptoms are, where and when the problem occurs, what process you suspect is at fault, and what
steps you have taken to identify the problem or what corrective actions you have taken with no success.
Ticket Type: Select from the available types: “Problem,” “Question,” “Categorization,” or “Provisioning.”
Ticket Priority: Select from the available priorities: “Urgent,” “High,” “Medium,” or “Low.”
Zscaler Support Ticket—General Information Gathering
Select each tab below to learn about the required information for the speci c problem to move the ticket forward:
Tra c Forwarding Method
–
Which tra c forwarding method is used (IPsec Tunnel (VPN); GRE Tunnel; PAC over IPsec; PAC over GRE; PAC Only; Proxy
Chaining; Private or Virtual Service Edge; Explicit Proxy; Zscaler Client Connector)?
Zscaler Cloud
–
Which Zscaler Cloud(s) are experiencing the issue?
Zscaler Data Centers Used
–
Which Zscaler data centers are used (the ZIA Public Service Edge from the ip.zscaler.com output)?
Problem/Incident Periods
–
When did the problem start? When did it stop? Is it ongoing?
Issue Scope
–
What is the scope (intermittent or always; all or some data centers; all or some sites; all or some users; all or some end-user
website destinations) of the issue?
Trigger Event
–
What seems to have triggered this event?
Work-Around
–
Is there a work-around? Has it been applied?
Upload a File
–
Are there proxy text screenshots, Zscaler Analyzer outputs, or server/ rewall/router or Zscaler Client logs?
Options for Raising a Support Ticket
There are di erent ways of raising a support ticket.
To illustrate this better, the video below will show these ways.
Select play to watch the video below.
Select here for a transcript of the video
–
Let’s look at a scenario where you have to raise a support ticket. Consider this situation. You are an IT Support Engineer working
for SafeMarch.com. Your manager has asked you to raise a ticket with Zscaler support to report an ongoing incident and request
their technical assistance.
In this scenario, there are three ways to raise a ticket. The rst method is to call our support team, depending on your contract
type—which can be 24×7×365 or 8×5 business hours. The second method is to raise a support ticket using the help portal. Ensure
you raise a ticket for the ZIA product in this case. On this page, you will need to provide all the details that you can nd in the ZIA
Admin Portal. Normally, you would use this method only if you do not have access to the Admin Portal. The third and preferred
method is to raise a support ticket via the ZIA Admin Portal, as this self-populates your user and company information and other
relevant details about your ZIA instance. Now you know how to raise a support ticket.
C O NT I NU E
Lesson 5 of 16
Key Takeaways
The key takeaways from this topic are as follows:
1
2
3
The stages involved in the troubleshooting process are localizing, isolating, and troubleshooting the
problem based on your hypothesis.
A certain amount of information is needed to raise a Zscaler Support Ticket and begin the
troubleshooting process; the more information you can provide, the quicker the case will be resolved.
There are three ways to raise a ticket: through a phone call, help.zscaler.com, and the ZIA Admin Portal
(preferred).
C O NT I NU E
Lesson 6 of 16
URL Classi cation—Overview
Let’s start by understanding the classi cation of the URLs in ZIA.
ZIA organizes URLs in a hierarchy of categories for granular ltering and policy creation. There are six prede ned
classes, each divided into prede ned super-categories and categories.
Prede ned Classes
Select each tab below to learn about the six prede ned classes and their super-categories:
Bandwidth Loss
–
The super categories in “Bandwidth Loss” are:
Entertainment/Recreation
News and Media
User-De ned
Business Use
–
The super categories in “Business Use” are:
Business and Economy
Education
Information Technology
Internet Communication
Job/Employment Search
Microsoft O ce 365 (applicable only for SSL Inspection Policy)
General Sur ng
–
The super categories in “General Sur ng” are:
Government and Politics
Miscellaneous
Travel
Vehicles
Legal Liability
–
The super categories in “Legal Liability” are:
Adult Material
Drugs
Gambling
Illegal or Questionable
Militancy/Hate Extremism
Tasteless
Violence
Weapons/Bombs
Productivity Loss
–
The super categories in “Productivity Loss” are:
Games
Health
Religion
Shopping and Auctions
Social and Family Issues
Society and Lifestyle
Special Interests/Social Organizations
Sports
Privacy Risk
–
The super category in “Privacy Risk” is Security.
Custom Categories
Besides the prede ned categories, you can create custom categories based on your organization’s requirements. Using
URLs, keywords, and IP ranges, you can block speci c websites, a speci c range of IP addresses for websites, and
websites based on any words that may appear in a URL, respectively.
You can visit the Zscaler Help portal documentation for current limits of custom URLs, custom categories, keywords,
and custom IP ranges while creating Custom URL Categories.

See the help portal article here for the current limits: https://help.zscaler.com/zia/about-urlcategories.
C O NT I NU E
Lesson 7 of 16
URL Reclassi cation
Sometimes, there could be a situation where a website is misclassi ed, and you need to recategorize it.
To illustrate this better, the video below will show a scenario where you will have to recategorize a misclassi ed
website.
Select play to watch the video below.
Select here for a transcript of the video
–
Let’s look at a scenario where you will have to recategorize a misclassi ed website. Consider this situation. While trying to access
a certain URL, an end user receives an error noti cation. It informs them that the URL is inaccessible as long as it belongs to a
misclassi ed character that the corporate IT team does not permit. Taking a cue, the user complains about the issue to the IT help
desk, of which you are a member. You review the access logs of that URL using Zscaler tools and nd the URL to be classi ed
with an incorrect category.
Now, to resolve this issue and restore the user’s access, you must again categorize the URL but this time correctly. There are three
ways to do this. The rst method is to submit a change request support ticket. The next method is to use Site Review to look up a
URL, and then select the Modify Categories option. This service is available for all Zscaler users. The last method is to submit a
review of the URL based on the End User Noti cation. You can use any of these methods as per your requirements. Now you
know how to recategorize a misclassi ed website.
Knowledge Check
Which of the following prede ned classes does the Education, Internet Communication, and Job/Employment Search supercategories belong to?
Bandwidth Loss
Business Use
General Sur ng
Legal Liability
SUBMIT
C O NT I NU E
Lesson 8 of 16
Key Takeaways
The key takeaways from this topic are as follows:
1
2
The URLs are classi ed into six prede ned classes for granular ltering and policy creation.
Misclassi ed websites can be recategorized by following one of the three ways of reclassifying the
URLs.
C O NT I NU E
Lesson 9 of 16
Standard Troubleshooting Tools
Now that you know about recategorizing and resolving URL issues, let’s look at some commonly used network troubleshooting tools.
Select each tab below to learn the use of standard troubleshooting tools:
IP Address Utility
–
The ipcon g (Windows), ifcon g (Mac), or ip addr (Linux) utility allows you to review the interface con guration of the network
adapters installed on a Windows, a Mac, or a Linux PC, respectively. Use the options/all (Windows) or -a (Mac) for full details.
Verify that the device has a valid IP con guration, a valid gateway set, and a valid DNS server con guration.
Ping
–
The ping utility is available at the command line on both Windows and Mac OS X machines and can be used to evaluate the
extent of a network outage. You can ping local addresses to con rm the device has connectivity, then ping the gateway IP address
to verify that the gateway is functioning.
Also, ping by FQDN to verify DNS resolution is working, and if not, ping by IP address, for example, to the 8.8.8.8 address of the
Google public DNS service. Check the round-trip time of the pings to determine the end-to-end latency on the connection.
Traceroute
–
The traceroute (Mac) or the tracert (Windows) utility shows the path of the tra c from a source to a destination and the roundtrip time taken for each hop. Using this tool, you can identify problems in the route as well as trace the route to internet
destinations to validate end-to-end connectivity path with round-trip time.
nslookup
–
The nslookup command-line tool helps you obtain domain name or IP address mapping for any speci c DNS record. You can also
use this utility to forward resolve an FQDN to an IP address or reverse resolve a public IP address to the matching FQDN.
WinMTR
–
The WinMTR utility combines the functions of the ‘ping’ and ‘traceroute’ commands in a third-party GUI-based application for
Windows. It also allows exporting data to a le that could subsequently be uploaded to a support ticket if necessary.
HTTP Header Trace
–
HTTP Header Trace plug-ins are available for popular browsers, and they give real-time visibility into the HTTP headers as pages
load. The results can be saved in a le provided to ZIA Technical Support.
Protocol Analyzer
–
A Protocol Analyzer is a tool for monitoring and analyzing data tra c over a communication channel. You can use Wireshark, a
widely used protocol analyzer, to capture packets on the wire as transactions take place. The packet captures can be saved to a le
for analyzing the protocol ows or uploaded to a support ticket.
C O NT I NU E
Lesson 10 of 16
ZIA Troubleshooting Tools
While the standard troubleshooting tools deal with common network issues, you need separate tools for ZIA-speci c issues.
Select each tab below to learn about the ZIA-speci c troubleshooting tools:
Proxy Test
–
You can check the Proxy Test page (https://ip.zscaler.com) to see the status of the user’s connection, along with key data about it.
You can view the output on the Proxy Test page.
ZIA Trust Site
–
You can check the ZIA Trust page (https://trust.zscaler.com) for the current ZIA cloud status and ongoing incidents and known
outages or issues.
Zscaler Con g Portal
–
You can use the cloud-speci c con guration pages (https://con g.zscaler.com). Then, from the ‘Cloud’ drop-down, select the
cloud that your organization is provisioned on to review your settings and check for miscon gurations.
ZIA Cloud Performance Test
–
The Zscaler Cloud Performance Test (http://speedtest.zscaler.com) is a browser-based tool for collecting performance
troubleshooting information for end users, such as download or upload bandwidth between the browser and the ZIA Public
Service Edge or ZIA Private Service Edge to which the tra c is forwarded.
ZIA Remote Assistance
–
An administrator can enable remote assistance on your ZIA Admin Portal, allowing ZIA Support to review your settings, policy
con gurations, and assignments.
ZIA Analyzer
–
The ZIA Network Analyzer analyzes the path between your location and the ZIA Public Service Edge you are connected through or
the time your browser takes to load a web page. The results can be saved to a le and uploaded to a support ticket. You can
download this tool from the Help Portal Tools page or the Proxy Test page.
C O NT I NU E
Lesson 11 of 16
Client Connector Logs
Finally, let’s look at the troubleshooting tools available on the More tab of Client Connector.
These tools can be enabled on the Client Connector portal under Policy > Mobile > Zscaler Client Connector
Con guration > Zscaler Client Connector Portal. Besides clearing log les, you can set di erent log modes to specify
the type of information stored in the various logs. For example, as shown in the image below, the Debug mode logs
all Client Connector activities that could assist ZIA Support with troubleshooting issues.
In normal cases, Info or Warning log modes are used. Debug mode is used only for detailed logging to support
troubleshooting.
It is recommended to collect log les manually by using the Export Logs function, as shown in the image below. The
log les are then exported as a zip le, which can be attached to a support ticket.
Listed in the table below are the log le names and the type of information each le contains:
Log File Name
Content
AppInfo
System and app info
Setupapi.dev
Error in driver installation
ZSAAuth
Authentication/Login issues
ZSAService
Service/Registry and session-related issues
ZSATray
UI/Interaction and Windows proxy settings
ZSATunnel
Tra c/Network issues
ZSAUpdate
App update/Auto-update issues

The Help portal (https://help.zscaler.com/z-app/zscaler-app-errors) provides detailed information about
any Client Connector error codes you may see in the log les.
Knowledge Check
Which of the following troubleshooting tools is used to capture packets on the wire as transactions take place?
Traceroute
WinMTR
HTTP Header Trace
Protocol Analyzer
SUBMIT
C O NT I NU E
Lesson 12 of 16
Key Takeaways
The key takeaways from this topic are as follows:
1
Using standard troubleshooting tools helps isolate the cause of connectivity issues.
2
Using ZIA-speci c troubleshooting tools helps isolate the cause of ZIA-related issues.
C O NT I NU E
Lesson 13 of 16
Localizing ZIA Issues: Troubleshooting ZIA Issues
By now, you are familiar with the di erent standard and ZIA-speci c troubleshooting tools. So, let’s turn your
attention to resolving connectivity issues.
When an end user device fails to connect with the ZIA cloud, you must rst localize the issue by identifying its root
cause and capturing the maximum data from the a ected end user.
Let’s look at two scenarios where you will have to localize the connectivity issues between the users and ZIA.
Scenario One
You are assigned an incident ticket from the local IT team at your organization. As per the ticket, the users at the
location cannot access the internet and this location is connected to ZIA through a functional GRE tunnel.
In this scenario, you can begin troubleshooting the issue by following the steps listed below:
1
Ask one of the users at this location to show you any end user message (EUN) they see while
accessing the internet:
If there is an EUN, then the issue is more likely due to policy miscon guration on Zscaler. You need
to x the policy issue.
If there is no EUN and you could see only normal “No internet” message on the browser, then you
need to look further to isolate the issue.
2
Access Zscaler connectivity tool (http://ip.zscaler.com) to determine what the issue might be from
a user device on the location:
If you are not able to reach Zscaler connectivity tool, then the issue could be at your local network.
Check DNS or Firewall rule or routing on the local network and resolve the issue.
If you could reach Zscaler connectivity tool, verify Zscaler Cloud, virtual IP, and your Gateway IP
address.
3
You can check the performance from the client to the Zscaler data center (the client is connected to)
using the Zscaler Speed Test site (http://speedtest.zscaler.com/):
You can use the Zscaler Speed Test tool to verify Datacenter info, HTTP Ping, HTTP Jitter,
Download Bandwidth, Upload Bandwidth, Cloud Path, etc.
You can share the information gathered on the Zscaler Speed Test tool with Zscaler support or with
your peers in the organization for advance troubleshooting.
4
There could be issues with DNS if you are using an internal DNS or a third-party public DNS service:
To test DNS resolution, you can either use the nslookup command on the user device or ping to a
public FQDN, which will resolve the IP address and send an ICMP request.
You can ping to the DNS Server IP and validate RTT to check if there is any latency. You can also try
traceroute/tracert utility to check the path to the DNS IP and any delay in the path.
Scenario Two
Take another scenario. A few employees from a certain location reported slow internet connection and di culty
accessing websites.
Here, to localize the issue, you must verify the connections between the users and the ZIA cloud.
Select each tab below to learn about the information that you will need when troubleshooting latency issues:
Full Path of the User’s Connection
–
You will require as much information as possible about the full path of the user’s connection that is experiencing the problem,
which includes:
The user’s connection to Zscaler
The user’s egress point IP addresses
The result of the Z-Speed test to the local ZIA Public Service Edge
Screenshots of the issue
Physical Location of the User
–
You will require as much information as possible about the other end of the connection and the service or site that the user is
connecting to, such as its physical location and its current performance.
To evaluate this, you will need:
The destination host name or IP address of the server
The server transaction logs at the time of the reported problem (if available)
Extracts from the Zscaler Web Insights Logs from the Admin Portal
An account of the situation when accessing the destination from other locations
Data in Real Time
–
You will require real-time data (at the time that the problem is occurring) from across the path of the data, which includes:
The output from the Zscaler Analyzer tool (speci cally the page load times and per-hop latency recorded)
A Wireshark trace on the data path
Header traces from the a ected browser
The output from MTR/WinMTR (while the problem is apparent)
The output from the Chrome cSpeed plugin (if available)
Using Zscaler tools, you can capture the dynamic data in real time when the problem is occurring.
Select each tab below to learn how Zscaler tools are used to capture the real-time data:
Proxy Test Website Data
–
Load ip.zscaler.com and record the information displayed and the environmental variables.
Z-Speed Output
–
Navigate to the Connection Quality test page (from ip.zscaler.com) and run the test against the ZIA Public Service Edge that the
user connects to.
Web Insights Logs
–
Load the Web Insights report from the Zscaler Analytics menu and view and export the related logs to a le.
Zscaler Analyzer Output
–
Run Zscaler Analyzer and capture the page load and latency data to the destination in question, both with and without Zscaler.
Zscaler Client Connector
–
Run packet capture to capture tra c speci c to the Client Connector and collect and export logs.
Real-time performance data can also be captured by third-party tools to assist in troubleshooting latency issues.
Select each tab below to learn more about the usage of third-party tools to capture the real-time performance:
Header Trace Data
–
Load a Header Trace plug-in to the browser, connect to the destination site both with and without Zscaler, and save the Header
Trace output.
MTR/WinMTR Output
–
Use the native MTR utility on Macs or install WinMTR on Windows; then, test to the destination in question both with and
without Zscaler.
cSpeed Output
–
Install the cSpeed plug-in for Chrome, connect to the destination in question, and record the results both with and without Zscaler.
Server Transaction Logs
–
Log in to the server (if possible) and view and export the appropriate transaction logs to a le both with and without Zscaler.
Wireshark Trace(s)
–
Take a trace from the user’s device and the egress gateway device simultaneously and save the traces to a le both with and
without Zscaler.
Localizing ZIA Issues: Additional Examples
The connectivity issues do not end with the users and can occur between ZIA and destinations on the internet. They
can happen even due to an outage at a destination. Other issues are related to authentication, ZIA service policies,
and settings con guration.
The following data is required by Zscaler when raising a latency related ticket:
Basic Data
Real-time Data
User’s physical location
Cloud Performance Monitor Test result
User’s egress IP address
Header trace from a ected browser
Basic Data
Real-time Data
User’s Zscaler connection method
Web Insights Logs from Zscaler
Output from ip.zscaler.com
Performance data from Zscaler Speed Test site
Relevant screenshots
Output from Zscaler Analyzer
Physical location of the destination host/service
Wireshark trace(s)
Host name/IP of destination
Zscaler Client Connector packet captures and logs
C O NT I NU E
Lesson 14 of 16
Isolating ZIA Issues
After localizing a connectivity issue, your next step is to isolate it and nd the failing logical process.
You can begin by addressing the following common connectivity issues:
1
The user cannot connect to the internet.
2
Tra c does not reach the ZIA Public Service Edge.
3
The user is unable to authenticate to ZIA.
No Internet Access—Root Causes
First, let’s discuss the predominant issue faced by the users—network connectivity. This issue is best solved by
spotting the root cause.
Select each tab below to learn about the root causes of not having internet access:
NO CONNECTIVITY
DOMAIN NAME SYSTEM (DNS)
FIREWALL POLICIES
You can perform several tests to identify the cause of no connectivity.
For instance, on a Windows machine, you can:
Run the ipcon g command and verify the client has an IP address.
Run the ping command to the default gateway of the client.
Subsequently, you can verify that the ISP is reachable.
To do this, you can:
Run the ping command to an external IP address (for example, the Google DNS site 8.8.8.8 responds to
pings).
Run the traceroute command to an external IP address.
Verify the availability of the ZIA Public Service Edge you are trying to reach by visiting the
URL https://trust.zscaler.com (for the real-time status of the ZIA cloud).
NO CONNECTIVITY
DOMAIN NAME SYSTEM (DNS)
FIREWALL POLICIES
You need to verify that the DNS query is correctly resolved to the required hosts.
For a user device with explicit proxy settings (a PAC le is applied to it), the following need to be resolved:
The server on which the PAC le is stored
The ZIA Public Service Edge
For the transparent proxy scenario, where the user connects through a tunnel at a xed location, the host in
the URL that the client is attempting to access must be resolvable.
NO CONNECTIVITY
DOMAIN NAME SYSTEM (DNS)
FIREWALL POLICIES
“Firewall blocking access to the location” and “Firewall blocking the client from outbound connections” are
policies related to the rewall con guration.
In such scenarios, the customer’s rewall may be either:
Blocking access to the location the user is trying to access (either a URL or the ZIA Public Service Edge)
Blocking the client from all outbound connections
Tra c Not Reaching the ZIA Public Service Edge—Root Causes
The next user issue arises when tra c from the user does not reach the ZIA Public Service Edge. The ZIA proxy test
page may state: “The request received from you did not have an XFF header, so you are quite likely not going through
the Zscaler proxy service.”
There are four main methods for sending tra c from the user devices to the ZIA Public Service Edge—GRE tunnels,
IPSec VPN, PAC le or proxy settings, and Zscaler Client Connector. The common issues with these methods have at
least ve potential main root causes.
Select each tab below to take a detailed look at these root causes:
Malfunction in GRE Tunnels
–
Malfunctions in the GRE tunnel may be attributed to three main causes:
The GRE parameters may not be correct. Verify all settings on both the local router and the ZIA Admin Portal.
The ACLs that direct tra c through the GRE tunnel may not operate as expected. You need to verify that web tra c is not
bypassing the GRE tunnel by visiting ip.zscaler.com from a PC behind the GRE tunnel.
The GRE tunnel may be unstable. Troubleshooting this issue requires an escalation to ZIA support while at the same time,
verifying the GRE tunnel con guration in the on-premises router and on the Zscaler portal.
Malfunction in IPSec VPN
–
If IPSec tunnels are in use, they may not operate as expected for similar reasons to the GRE case. To identify the root cause of this
issue, verify the tunnel status of the on-premises VPN router.
Incorrect PAC File or Proxy Settings
–
The PAC le may be miscon gured.
The following are the possible causes of miscon guration:
There may be a syntax error in the PAC le. You can use the ZIA Admin Portal to verify the PAC le syntax.
The PAC le may have some statements that cause all the tra c to bypass the proxy, thus matching the script’s RETURN
‘DIRECT’ clause.
To identify the root cause of this issue, verify the PAC le con guration.
The proxy settings may be incorrect in the browser.
The following are the possible causes of incorrect settings:
The proxy port in the proxy URL may be incorrect.
There may not be any PAC le con guration at all. Therefore, no proxy is de ned in the system.
The ZIA domain may, for some reason, be in an exception list.
To identify the root cause of this issue, verify the proxy settings on the user device.
Zscaler Client Connector Problems
–
When your users are using Zscaler Client Connector, they may face some of the following issues:
The incorrect Forwarding or App pro le is being applied to the user.
Client Connector may need an upgrade, repair, or complete reinstallation.
The end user may be on a network with a captive portal and has not yet logged in through the portal.
To identify the root cause of the issue, verify the Client Connector status.
Another common scenario where you need to isolate the issue is when a user cannot authenticate.
Select each tab below to look at the root causes for a user failing to authenticate:
AUTHENTICATION PROMPT FAILS
USER AUTHENTICATION FAILS
SAML FAILS
If the user is not prompted to log in, consider these three primary reasons:
The speci ed location does not have authentication enabled.
The user’s tra c does not reach the ZIA Public Service Edge.
The SAML IdP is not exempted from Authentication.
If the IdP is not exempted from Authentication, the IdP’s user auth page will not be reachable even if
Authentication is enabled at the location.
In such cases, verify the location-based con guration and network connectivity, and check that the IdP is
exempted from authentication under Administration > Advanced Settings > Authentication Exemptions.
AUTHENTICATION PROMPT FAILS
USER AUTHENTICATION FAILS
SAML FAILS
At times, a user is prompted for their credentials, and yet the authentication is unsuccessful. This is most
likely due to cookies. If the user agent has cookies disabled, you will not be able to complete the
authentication process.
The following are other less likely causes:
SAML is not con gured correctly. Con guring SAML entails several steps and complexities.
The Lightweight Directory Access Protocol (LDAP)/AD server cannot be reached.
The ZIA Public Service Edge has temporarily lost connectivity to the Central Authority.
The user may type an incorrect (or nonexistent) username, the password may be inaccurate or might have
expired, or the account may be disabled.
AUTHENTICATION PROMPT FAILS
USER AUTHENTICATION FAILS
SAML FAILS
For SAML con guration, you need to:
Verify that the user agent bypasses the ZIA Public Service Edge while connecting to the SAML server.
Verify that on-premise rewalls or other security systems are not denying access to the SAML server.
Knowledge Check
Which of the following is a root cause of a user experiencing the No Internet Access issue when connected via GRE tunnel at an
o ce location?
Incorrect rewall rules
Zscaler Client Connector problems
User authentication failure
SAML failure
SUBMIT
C O NT I NU E
Lesson 15 of 16
Key Takeaways
The key takeaways from this topic are as follows:
1
2
Localizing ZIA issues is essential to identify the actual cause of an issue and x it e ectively by
capturing the maximum data.
An issue can be isolated by identifying the failed logic behind the process and addressing issues in
network connectivity, infrastructure entities, and miscon guration.
C O NT I NU E
Lesson 16 of 16
Recap
In Summary
This module has introduced you to the root cause of issues and troubleshooting tools.
You now have a better understanding of how to solve issues related to URL classi cation. You also explored the use of localizing and isolating ZIA
issues.
From this module, you should now be able to:
1
Comprehend the basic concepts of troubleshooting
2
Examine URL classi cation and rectify issues by reclassifying the URLs
3
Localize and isolate ZIA issues to identify the root cause
4
Solve common ZIA issues using troubleshooting tools
C O NT I NU E
Thank You!