Netskope Global Technical Success (GTS)

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

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 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:  Covers the architectural components and workflow until the client establishes a connection to NPA gateway

Part 2: Link Provides  details around accessing a Private Application via NPA with different logs seen at different stages

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

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: Is 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 enrollment : 

• Netskope client connects to the Management Plane for enrollment if it has not enrolled previously.
• Enrollment is triggered if the npaaccesscert.pem file is not present in the Netskope Agent directory

• Netskope client connects to Management Plane by looking at the Management Plane URLs which can be found under nsconfig.json

• During the enrollment process, the agent connects to the Management Plane and fetches the enrollment token. After fetching the enrollment token it connects to another component inside the Management plane and sends the token along with device id to enroll 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 ST Agent 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. seen in NPADebuglogs]

eDESKTOP-CU8AH3N:2024-07-15 19:15:23.803 +05:30] Ninfo] 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": _], "schema": "urn:newedge:client.assessment:version/1.0", "seamless_policy_update": true, "system_health": {"anti_spyware": "], "anti_virus": "], "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. The preference is to use GSLB first (if enabled). If not, Netskope client will use EDNs and fallback to LDNS if EDNS resolution fails.

You can verify this selection  in the nsdebuglog.log file: : 

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 aNPA_IS_STARTING] to uNPA_IS_STARTED]

Using GSLB : 

• GSLB is an API introduced by Netskope to eliminate dependency on Google’s DNS Server for DNS resolutions when Netskope components enquire for nearest Data planes.
• The GSLB service uses Netskope’s native Steering API to determine the closest Datacenter for a Netskope client to connect to.
• This API is hosted on Management Planes and Data Planes. Each NewEdge  Dataplane has an RTT Endpoint corresponding to client RTT measurement requests.
• The Netskope client makes a call to the GSLB API to obtain a list of Data planes  to connect to. The API call returns a list of 10 Netskope Data planes to Netskope clients based on the egress IP address of the client. The Netskope client then measures the round trip times to these Data Planes
• The RTT measurements are passed on to the GSLB Service which in turn returns an ordered list of Data planes to which the Netskope client can connect to. Based on the ordered list, Netskope client will select a Data Plane for connection. Note that Data Plane Selection for NPA traffic steering is not strictly RTT based. Data plane candidates within 10ms or so of each other are considered roughly equivalent and selected randomly, but consistent for a given device.  Preference is also given to in country data planes as well.

Once complete, the Netskope client successfully establishes a connection to Netskope Private Access Gateway and starts steering Private Application Traffic

Summary

• Netskope client first checks if NPA has been enabled based on the current user’s assigned Steering Configuration
• If NPA has been enabled, it further checks if the Private App steering has been configured under the steering configuration
• Netskope client checks the enrollment status of NPA and initiates enrolment if not enrolled already via the Management Plane
• Once enrolled, the Netskope client will establish a connection to the nearest POP using GSLB (Netskope API), EDNS (DNS over HTTPS), LDNS (Local DNS)  in order of precedence 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'.