Usage guide: Zscaler (VPN) proactive troubleshooting

This page outlines various ways to use the pack, including use case examples.

Administrators can refer to the Configuration guide to set up and customize the installed content.

The Zscaler (VPN) proactive troubleshooting library pack enables IT teams to:

Automate the detection and remediation of connectivity issues on endpoints.
Reduce the number of connectivity-related tickets by proactively resolving such cases.

Library pack uses

Jump to Use cases on this page to see relevant scenario applications.

Use the library pack content for the following purposes.

Visibility

This library pack focuses on the Zscaler (VPN) proactive troubleshooting workflow. This workflow automatically identifies connectivity-related issues on endpoints caused by the incorrect state of the Zscaler (VPN) application. If possible, it should then apply automated remediation to proactively fix the issue. This will help avoid time losses for users and IT personnel, as well as extra tickets.

Workflow triggering

This workflow is designed to be used for the automated detection of connectivity-related issues through the Events trigger.

Depending on the web applications configured in your environment that require a Zscaler VPN connection to access them, you will need to define the correct error codes to trigger this workflow.

Below is an example of an NQL query that returns common HTTP error codes caused by an incorrect ZScaler connection state and which can be used as a trigger :

web.errors
| where code == 600 or code == 601 or code == 606
| list code

HTTP error codes 600, 601 and 606 are non-standard and typically indicate connection issues that are preventing you from accessing a web application.

Predefined workflow structure and steps

The Zscaler (VPN) proactive Troubleshooting workflow follows a sequence of steps to diagnose and resolve issues efficiently.

When triggered, the workflow notifies the user that an issue has been detected when opening a business application and that troubleshooting has begun. This message is followed by the "Get ZScaler status" remote action, which checks the status of the ZScaler application.
First, the workflow checks whether the ZScaler application is running. If it is not running and the device is Windows-based, the workflow will prompt the user to confirm whether it is the right time to restart Zscaler and trigger the remote action "Reset Zscaler connection". If it is a macOS device, the user will be notified that ZScaler is not running and asked to turn it on.
Next, the workflow checks the states of ZPA (Zscaler Private Access) and ZWS (Zscaler Workload Segmentation). The following states are considered normal: "ON", "CONNECTING" and "TUNNEL_FORWARDING". If both ZPA and ZWS statuses are equal to "-", Zscaler is considered to be in an unauthenticated state. All other states are considered abnormal and will trigger a ZScaler restart attempt.
If the application is considered to be in an unauthenticated state, the user will be asked to re-authenticate via a Teams message. If the user confirms re-authentication in the Teams message, the workflow will pause for five minutes and then trigger the "Get Zscaler status" remote action to re-evaluate the application's status. If the status changes to "Authenticated", the user will be informed by a Teams message that the issue has been resolved. Otherwise, the workflow will terminate with the appropriate output.
If ZPA or ZWS is in an abnormal state, the workflow checks whether the device is Windows- or macOS-based. If it is a Windows device, the workflow will prompt the user to confirm whether it is the right time to restart Zscaler and trigger the remote action "Reset Zscaler connection". If the device is running macOS, the user will be notified that Zscaler is not running and asked to turn it on.