Synthetic Probes
Network Probes
Use Cases & Principles
A Network Probe test is a synthetic test that provides end-to-end and hop-by-hop network performance analysis. It can be triggered from NSClients and/or Netskope Enterprise Stations. It helps you easily diagnose any degraded end users and corporate sites connectivity to the Netskope POPs by discovering the whole network path between them and measuring hop-by-hop performances. You can identify network degradations at all infrastructure layers between your users/sites and the Netskope POPs, such as:
- Local end user connectivity
- Local corporate networks
- Connection to the local ISP
- Interconnection between consecutive ISPs, up to the Netskope POP
When assigning IPSec/GRE tunnels to a site, any Enterprise Station linked to the site will automatically trigger Network Probe tests to the top two POPs that are part of the IPSec/GRE tunnels configuration.
These top two POPs are determined based on the volume of data being sent through all active tunnels.
If the “Monitor NSClient connectivity” option is selected in the site configuration (please refer to the Sites section for more information), the Enterprise Station linked to the site will also mimic the NSClient behavior by targeting the Netskope POP which is determined by the GSLB service.
The GSLB service is being invoked for each Network Probe test, and the test is only performed to the best POP identified.
Network Probe tests are based on the traceroute principle.
Network Probe tests can use either ICMP or UDP to perform the traceroute. The method used is configured at the site level.
The principle of UDP-based Network Probe test can be schematized as follows :
The Network Probe discovers the network path to a target by sending UDP segments with an incremental IP header TTL (Time To Live) field. So the first UDP segment is sent from the NSClient/Enterprise Station to the target with a TTL=1 value in the IP header. As this packet cannot be routed by the first router on the path, the router drops the packet and sends an ICMP error message “TTL exceeded in transit” back to the NSClient/Enterprise Station. The process continues with a TTL=2 IP header field to discover the second router. It goes on with incremental TTL field values up to the target. When the target is reached, this latter replies back with an ICMP error message “Destination unreachable – Port unreachable”, informing the NSClient/Enterprise Station that the used UDP port is closed.
At each hop, a minimum of 6 probing segments are being sent. In case the NSClient/Enterprise Station does not receive ICMP error messages back, it automatically increases the number of tests. Up to 12 tests per hop can be triggered. If the router is configured so that it drops packets without generating ICMP error messages, the router is still identified in the path visualization graph but no performance metrics can be computed.
Each UDP segment sent uses a different UDP server port (from 33.435 to 33.535). When the UDP segments reach the target, this latter should at least have one of the 6 different UDP ports closed (in most of the cases, the majority of UDP ports > 1.024 will be closed, if not all), so that it sends ICMP error messages “Destination unreachable – Port unreachable” back to the NSClient/Enterprise Station.
From all collected data, the NSClient/Enterprise Station computes network round trip times as well as packet loss for each hop.
Traffic Steering Requirements
In order to discover the underlay network path between a corporate site and the Netskope POP, the Network Probe tests traffic must not be steered through Netskope.
In order to achieve this, you must configure a policy-based routing rule in your corporate firewall so that the non-HTTPS traffic from the Enterprise Station IP address bypasses the secured tunnels.
App Probes
Use Cases & Principles
An App Probe test is a synthetic test that provides application availability and performance monitoring.
It can be triggered from NSClients and/or Netskope Enterprise Stations and helps you easily identify any web service unavailability and performance issues by testing specific domains (for NSClients) and/or URLs (for Enterprise Stations) at application level.
This test is not limited to the web application performance itself, it also covers the whole infrastructure chain between the end user and the application, helping you to find the root cause of any performance degradation by providing performance telemetry that monitors:
- The network infrastructure and services between the end user and the Netskope POP
- The Netskope infrastructure itself
- The network infrastructure between the Netskope POP and the monitored application
- The servers that are delivering the application
Traffic Steering Requirements
The App Probe tests traffic must be sent through a secured tunnel in order to mimic typical real users behavior.
In order to achieve this, you must configure a policy-based routing rule in your corporate firewall so that HTTPS traffic from the Enterprise Station IP address is steered through the secured tunnel.
Configuration
To monitor the reachability, availability, and performance of applications through synthetic testing, please do the following:
- Specify what you want to monitor.
This step is done by creating custom apps. Please refer to the Custom Applications section for more details. - Define the location from which you want to monitor.
This step is done by creating App Probes, which can be applied to either NSClients or Enterprise Stations.
Once you have created custom applications (in case you need to monitor applications that are not covered by predefined applications), navigate to the “App Probes” configuration menu (1) and select either the “Netskope Client” or “Station” tab depending on the source from which you want to trigger the execution of App Probes tests (2).
App Probe for NSClients
- Select the “Netskope Client” tab at the top of the App Probes view to see the list of existing App Probes.
- You can easily find an existing App Probe by searching by name in the search box.
- Selecting an App Probe allows you to edit, deactivate, or delete it.
When there is no App Probe selected, click on “Create” to create a new App Probe:
From this view, you can configure:
- The name of the App Probe policy to apply to selected NSClients (1)
- The application you want to monitor.
This can be a predefined or a custom application (2) - The scope of monitoring, that is the NSClients from which you want to monitor the application (3). You can include in the scope:
- Users and/or
- Specific users
- Users groups
- Organization units
- Operating systems and/or
- Windows
- MacOS
- Devices based on their classification
- Managed
- Unmanaged
- Unconfigured
- Users and/or
- The interval between consecutive tests (4).
This can be between 5 minutes and 1 hour, by 5 minutes increments. The default value is 5 minutes. - The order in which to enforce the App Probe policy (5).
This specifies the order in which App Probe policies are being enforced.
App Probe for Enterprise Stations
Select the “Station” tab at the top of the App Probes view to see the list of existing App Probes.
You can easily find an existing App Probe by searching by name in the search box (1).
Selecting an App Probe (2) allows you to edit or delete it (3).
When there is no App Probe selected, click on “Create” to create a new App Probe:
Predefined Applications
In case of a predefined application, select it from the dropdown list and select up to three domains defining the application that you want to monitor:
Once selected, these domains will be visible under “Enabled domains” section:
Now that the monitoring targets have been defined, click on the “Choose” button to select one or multiple Enterprise Stations to assign this monitored application to:
Click on Create to finalize the App Probe creation process:
You are all done.
Custom Applications
Applying an App Probe to an Enterprise Station for a custom application is straightforward.
Select the “Custom” tab from the “Monitored Application” section (1), select the desired application from the dropdown list (2) and apply it to one or multiple Enterprise Stations (3):
Click on “Create” to finalize the App Probe creation:
You are all done.
Custom Apps
With P-DEM Enterprise enabled, all DEM-supported SaaS applications are automatically and proactively monitored through real user traffic analysis. It means that the end user experience score as well as application RTT are being computed and provided in the “User Overview” dashboard.
In addition to these applications, you can synthetically monitor any kind of web-based applications.
There are more than 80k applications in the Netskope CCI (Cloud Confidence Index) database. Any of these can be selected as a targeted monitored application.
If the application you want to monitor is not part of the provided list, then you can create your own.
A custom application is defined by a list of maximum three web targets.
When monitored from an NSClient, a custom application can be made up of three domains.
However, when monitored from an Enterprise Station, a custom application can include any URL, which makes it the ideal solution for monitoring specific web based API calls for example.
Custom Applications for NSClient
To access the custom application for NSClient configuration menu, click on the “Custom Apps” menu (1), then select the “Netskope Client” tab (2).
If you have previously created custom applications, they will appear in the table.
Click “Create” (3) to create a new custom application.
As previously mentioned, the definition of a custom application to monitor from NSClients can include up to three domains. In the “Domains” section, each domain must be filled in a separate line.
Custom Applications for Enterprise Station
In addition to targeting domains, the Enterprise Station is also able to test the reachability of any URL and provides advanced configuration options.
To access the custom application for Enterprise Station configuration menu, click on the “Custom Apps” menu (1), then select the “Netskope Station” tab (2).
If you have previously created custom applications, they will appear in the table.
Each line corresponds to one custom application. For each application, you can see its name, description and number of URLs that have been specified to define the application.
Click “Create” (3) to create a new custom application.
Specify the name you want to use for this application. This name will be used in the different dashboards.
Click “Create” at the bottom to define a first URL target for this new custom application.
Section 1: General
In the first section, you can configure:
| Parameter | Description |
| Name | Name of the target |
| Description | Description of the App Probe target (optional) |
| Method | HTTP method used to test the target.The supported methods are GET, POST, PUT, HEAD, DELETE, PATCH, OPTIONS, CONNECT and TRACE |
| Target URL | URL of the tested target. The URL can contain a domain name, an IPv4 or an IPv6 address. You can add a port in case the web service does not run on traditional ports like 443 (e.g. : https://www.netskope.com:4545) |
Section 2: Request
In the second section, you can configure:
| Parameter | Description |
| HTTP Redirect | By default, Netskope follows HTTP redirections.When disabled, the App Probe test analysis stops at the first server.In case of redirections, the response code is then like 301, 302, … |
| Headers | Optional headers can be added.For example, this can be useful when JWT (JSON Web Token) bearers are used for authentication, when you explicitly expect specific response format, or to activate some CORS (Cross-Origin Resource Sharing) headers. |
Section 3: Response
In the third section, you can configure:
| Parameter | Description |
| Expected Status | By default, Netskope expects a status code between 200 and 299.You can specify any status code (range) according to your specific requirements.If for an App Probe test, the Enterprise Station gets another response status code from the server, then the targeted web service will be considered unavailable and the response codes will be provided in the Application Details dashboard. |
Section 4: Advanced
In the last section, you can configure:
| Parameter | Description |
| TLS security | By default, the App Probe test validates the server certificate.In case you want to test servers with embedded self-signed certificates, you may want to disable this option. |
| User agent | By default, the user agent for each App Probe test is like “Netskope/_version_”.Depending on potential constraints at the server level, you may change this.We provide prefilled user agents for Chrome Windows, Firefox Windows, Edge Windows and Safari MacOS. |
| Max. redirect | Maximum number of redirections before aborting the test.This would generate an error (type “Too many redirections”). |
| Timeout | Maximum number of seconds waiting for a server response before aborting the test and generating an error (type “Timeout”).The default value is set to 10 seconds. |
| Connect Timeout | Maximum number of seconds waiting for a server connection setup before aborting the test and generating an error (type “Connect”).The default value is set to 5 seconds. |
When you are done with the configuration, click on “Create an App Probe Target” .
You can see the newly created App Probe target in the list of the targets which are part of the currently created custom application:
