Netskope Global Technical Success (GTS)

KB - Simplifying NPA end to end workflow (Part 3)

Netskope Cloud Version - 121

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 at different stages within the traffic flow. This workflow only applies to client based NPA.

Requirement

Netskope Private access license is required

Context

This document will help the IT Administrators understand the end to end flow for NPA which can guide them to troubleshoot  and understand the NPA.

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

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

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

Part 3: Covers 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/Data plane and the Publisher is already connected to the Stitcher in the nearest POP/Data plane

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.
• The SRP is downloaded by the Netskope client every 15 minutes by default and upon tunnel initiation.
• The SRP download logs can be found in npadebuglogs present in the Netskope client logs folder, a copy of which is available to save from the Netskope Client UI.
• 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 Private Access  Gateway it has established the tunnel to. The gateway checks the device information and makes a request  to the Netskope Management Plane to fetch the SRP. The Management Plane 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 steering decisions.

SRP Download flow

Netskope Client <—> Netskope Gateway <—> Management Plane 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 up to15 minutes by default.  The exact timing is based on the last time the client received an SRP. 
• You can force the download of an updated SRP by:  

1. Disabling and then enabling the client.

2. Restarting  the client service.

3. Rebooting the endpoint.

• Once the new SRP has been downloaded, you will see the below information in npadebuglogs. , You will see a log line “SRP live status is 1” which means that the SRP 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 and the download of a new SRP failed.

•  When the user or devices tries to access the Private Application,the request reaches the Netskope gateway where policy evaluation is performed. NS gateway already has a map of the Publishers that are 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 or device

• 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'.