Netskope Global Technical Success (GTS)

Simplifying NPA: End-to-End workflow - Part 3

Objective

The objective of the document is to help understand the architecture and flow of Netskope Private access that will help IT Admins troubleshoot basic NPA issues with ease at different stages within the workflow.

Requirement

Netskope Private access license is required

Context

Netskope private access is popularly used by our customers. This document will help the IT Administrators understand the end to end flow for NPA which can guide them to troubleshoot understanding the NPA Architecture better.

For simplicity, this article has been broken down into three parts. This is Part 3  of the document.

Part 1: Link Will cover the architectural components and workflow until the client establishes a connection to NPA gateway

Part 2: Link Will cover details around how the Publisher establishes a connection to the nearest Stitcher residing in New Edge POP.

Part 3: Will cover end to end Private Application access details given that Netskope client is already connected to nearest POP in Part 1 and Publisher is already connected to nearest Stitcher residing in POP B.

Details

Before you begin reading this document, it is recommended that you read Part 1 and Part 2 of this document.

In Part 1 and Part 2 we discussed how the Netskope client establishes a connection to the nearest Gateway and how Publisher establishes a connection to the Stitcher in the nearest POP.

This document will cover the different stages when a user tries to access a Private Application provided that the Netskope client is already connected to the nearest POP and the Publisher is already connected to the Stitcher in the nearest POP.

Understanding the concept of SRP

• When a User tries to access a Private Application, the Netskope client has to first understand whether the Application access is to be provided to the end user or not based on the Steering profile and Policies configured on the tenant.
• This is determined by means of SRP (Service Routing Policy) which is like a Routing Table that client leverages to make decisions of whether or not to steer a Private Application for an end user.
• SRP is downloaded by the Netskope client every 15 minutes by default and upon tunnel initiation. Changes to the Private App definition will also trigger SRP download. The SRP download logs can be found in npadebuglogs
• SRP for every user is unique as the assignment of Private applications and Policies differ for every user.
• In order to download SRP, the Netskope client sends device information to the Gateway it has established the tunnel to. The gateway checks the device information and makes a call to Netskope MP to fetch the SRP. The MP has different components which work together to determine steering profile, policies configured for the user etc. Based on this the MP components will provide the unique SRP for the user to the Gateway and the Gateway provides this information to the requesting Client.
• Based on the SRP received from the gateway, the Client makes Application routing decisions.

SRP Download flow:

Netskope Client <—> Netskope Gateway <—> MP components

Let’s try to create a New Private Application and understand the Application access flow: 

• Once the above Private Application has been created, the Netskope client will receive the new SRP in 15 minutes by default.
• If you want to force the SRP download, it can be done in the below ways : 

1. Disable and then enable the client.

2. Restart the client service.

3. Reboot the endpoint.

4. Disconnect and then reconnect the network interface.

• Once the new SRP has been downloaded, you will see the below information in npadebuglogs. Along with this, you will see a log line “SRP live status is 1” which means that the Private Application list to be steered has been refreshed and downloaded by the Netskope client. If you see a log line “SRP Live status is 0”, it means that the Netskope Client is using cached SRP.

• Now, when the user tries to access the Private Application,the request reaches the NS gateway where Policy evaluation is performed. NS gateway already has a sense of the Publisher that is connected to the Private Application, this information is available as a part of the SRP. This can also be seen in the npadebuglogs as shown below.
• The log line “Getting Policy Rule for host” is generated when the Application is accessed by the end user.

• Netskope gateway routes this request to an internal component which forwards the request to the appropriate stitcher that the Private Application is connected to (Remember we learned in Part 2 that the Publisher connect to the stitcher in the nearest POP)
• This is how Application access is granted using NPA.
• The Application access status can be viewed from Web UI under Skope IT - Network events :

This completes the Application access flow using NPA. 

Terms and Conditions

• All documented information undergoes testing and verification to ensure accuracy.
• In the future, it is possible that the application's functionality may be altered by the vendor. If any such changes are brought to our attention, we will promptly update the documentation to reflect them.

Notes

• This article is authored by Netskope Global Technical Success (GTS).
• For any further inquiries related to this article, please contact Netskope GTS by submitting a support case with 'Case Type – How To Questions'.