Netskope Global Technical Success (GTS)

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

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 basic issues at different levels within the flow.

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

Part 1: 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: Link 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

Netskope private access architecture comprises of below main components : 

Netskope Client: Netskope client resides on the end user’s system and steers the Private Application traffic towards Netskope Gateway

NPA Gateway (Different from SWG Gateway): Nearest selected gateway in the New edge POP to which the Netskope client establishes the tunnel to.

Stitcher (Internal component): NPA Publisher establishes a tunnel to Stitcher. Internal components inside the New Edge DCs broker the connection between Netskope Gateway and Stitcher to provide the Private Application access to the end user. Stitcher resides in POP B.

Publisher: A Netskope component that gets deployed in the customer environment to provide access to the Private Application. 

Private Application: The Application to be accessed by the end user.

Let’s try to understand the NPA end to end workflow from scratch considering that an end user is trying to access a Private Application : 

Step 1 : Is the NPA feature enabled for the end user ?

• Netskope client will first check if NPA functionality is enabled for the end user. This is enabled from the backend and can be verified from the NSDebuglogs. There is a log line "secureAccess": "true”
• By seeing this , Netskope client understands that NPA functionality is enabled for end users from the backend. This is found in nsconfig.json file 

Step 2 : Are Private Apps steering enabled for the end user under Steering Configuration ?

• The client verifies the steering configuration applied to end user from nssteering.json and checks whether Private Apps are enabled for the end user under Steering configuration
• This is a crucial step as Netskope client won’t be able to steer Private Application traffic if the Private Apps are not steered from the steering configuration

• This can be verified from the nssteering.json file :

Step 3 : NPA enrollment 

First time enrolment : 

• Netskope client connects to Management Plane for enrolling itself if it has not enrolled itself before.
• The enrollment process is triggered when the client sees that npaaccesscert.pem is present under Netskope Agent directory or not.
• Netskope client connects to MP by looking at the MP URLs which can be found under nsconfig.json

• During the enrolment process, Client connects to MP and fetches the enrolment token. After fetching the enrolment token it connects to another component inside MP and sends the token along with device id to enrol itself.
• The device id is generated by the Netskope client using the hardware identifier of the system. Hence the device id will be unique for every device. In case of multi-user mode, the client will share the device id in the format : “deviceid-username”. In response to the device id, Netskope client will generate a unique CN for all the users logging into the machine and every logged in user will have a different NPA certificate.
• After the enrollment, The NPA Client Downloads the client cert & CA certs (npaccesscert.pem, npaccesskey.pem & npatenantcert.pem) and stores it in the directory. So it will not trigger enrollment next time.The CN of npaccesscert.pem is used as a unique identifier for the user and can be used for further troubleshooting. This is the same Common_name presented in deviceInfo updates. rseen in NPADebuglogs]

"DESKTOP-CU8AH3N:2024-07-15 19:15:23.803 +05:30] 2info] neClientTransportHander.cpp:569:sendGwDeviceAssessment():0x56446e8 Received device info request. Device Info: {"device": {"assessment": {"alternative_steering_detected": 0, "architecture": "unknown", "custom_classification_id": 907, "eee_support": true, "gw_resolution": "EDNS", "last_logon_time": 1721051045, "lz4_support": true, "machine_name": "DESKTOP-CU8AH3N", "managed": true, "npa_srpv2": false, "on_prem_status": 2, "org_key": "********", "os": "Windows", "os_version": "10.0.19045", "perusermode": false, "policyVersion": 3, "publisher_selection": false, "scan_files": e], "schema": "urn:newedge:client.assessment:version/1.0", "seamless_policy_update": true, "system_health": {"anti_spyware": y], "anti_virus": n], "firewall": ,]}, "tunnel_type": 0, "user_email": "smurtuza@netskope.com", "user_key": "********"}, "client_version": "117.0.0.2090", "common_name": "e4e08a2840a4600f", 

Step 4 : Client connectivity to Netskope Gateway : 

Netskope client establishes a connection to nearest Netskope POP. The POP selection can be done based on EDNS or using GSLB service. If an EDNS connection fails, the POP selection is done using LDNS.

You can verify the same using NSDebugLogs : 

Using EDNS : 

2024/07/15 19:14:28.679 stAgentSvc p9d8 t1bfc info restapi.cpp:88 restapi SSL resolve EDNS downloaded successfully

2024/07/15 19:14:28.757 stAgentSvc p9d8 t1bfc info nsDnsResolver.cpp:218 dnsResolver Hostname gateway.npa.goskope.com resolved by EDNS

2024/07/15 19:14:28.804 stAgentSvc p9d8 t1bfc info npaTunnelMgr.cpp:631 CNpaTunnelMgr Set NPA (current) status from nNPA_IS_STARTING] to nNPA_IS_STARTED]

Using GSLB : 

In this fashion, Netskope client successfully establishes a connection to Netskope Gateway and starts steering Private Application Traffic

Summary

In this article it was understood that -

• Netskope client first checks if NPA has been enabled for the end user or not
• If NPA has been enabled, it further checks if the Private App steering has been configured under the steering configuration
• Netskope client checks the enrolment status of NPA and commences the same if not enrolled already (by connecting to MP)
• Once done, the Netskope client will establish a connection to the nearest POP using one of the methods it is supposed to use - EDNS / GSLB and start steering Private App traffic.

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