Netskope Global Technical Success (GTS)

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

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 2 of the document.

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

Part 2: 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

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

In Part 1, we discussed how the Netskope client establishes a connection to the Nearest Gateway. In this section, we will discuss how the Publisher will establish a connection to the nearest stitcher which resides in POP B in the above diagram.

Step 1: Publisher Registration to Netskope Management Plane (Usually done during the Publisher deployment stage)

• Publisher has to register itself to MP to download the machine certificates which will be used for mutual authentication with stitcher (stitcher.npa.goskope.com)
• A Registration token is essential for the Publisher to successfully register the Publisher. The Publisher registration token can be fetched from the Web UI under Security Cloud Platform – Publisher - New Publisher using the Token generated from the Web UI

• Once the Registration is successful,  Publisher downloads the machine certificates and tenant certificates which are later used for mutual authentication with Stitcher
• Publisher registration logs can be fetched from the Publisher itself. They are present under the logs folder with the name publisher_wizard.log 

• You can find the Publisher Registration logs as below, if there is a failure in registration, the logs will indicate the same : 

2023/05/17 12:21:28 UTC Executing command: docker image inspect new_edge_access:latest

2023/05/17 12:21:28 UTC No local repoDigest found.

2023/05/17 12:21:39 UTC Registering with your Netskope address: ns-12046.us-sjc1.npa.goskope.com

2023/05/17 12:21:39 UTC Publisher certificate CN: bdcf6508135b7663

2023/05/17 12:21:39 UTC Attempt 1 to register publisher.

2023/05/17 12:21:43 UTC Publisher registered successfully.

Step 2: Publisher connects to Stitcher in POP B

• Once the certificates have been downloaded, Publisher will try to establish a connection to Stitcher which resides in the nearest new edge POP. 
• Publisher will try to find the nearest New Edge POP to connect to Stitcher either using EDNS / GSLB based on what it is configured to use
• These discovery logs are seen in Agent.txt file
• Once the Publisher has obtained the stitcher IP using one of the methods discussed below, it will authenticate to the stitcher using the certificates downloaded in Step 1. This can be seen in the Agent.txt logs : 

lnpa-publisher:2024-08-01 13:10:52.736 +00:00] 1info] agenthandler.cpp:181:operator()():0x7fc2a88ed770 Got stitcher IP via EDNS. Stitcher IP is S163.116.213.71]

lnpa-publisher:2024-08-01 13:10:52.737 +00:00] 1info] sslclient.cpp:130:prepare():0x0 Connecting to 163.116.213.71

lnpa-publisher:2024-08-01 13:10:52.753 +00:00] 1info] socket_tools.cpp:232:connectWithTimeOut():0x0 SO_ERROR value 0

lnpa-publisher:2024-08-01 13:10:52.753 +00:00] 1info] socket_tools.cpp:752:setNoDelay():0x0 Set TCP_NODELAY flag 1 fd 11

lnpa-publisher:2024-08-01 13:10:54.077 +00:00] 1warning] sslclient.cpp:71:verify_callback():0x0 Verified: /C=US/ST=CA/L=Santa Clara/O=Netskope Inc./OU=certadmin/CN=certadmin/emailAddress=certadmin@netskope.com

Connectivity using EDNS :

• Publisher will first try to establish a TLS connection to EDNS on port 443 in order to find the nearest POP to connect to, ie Publisher will try to resolve stitcher.npa.goskope.com
• It sends a request to Google DNS. Google DNS further sends this request to Netskope’s backend appending the Source IP from which the request originated and Netskope’s backend responds back with the nearest POP based on the Source IP of the received request. This can be viewed in Agent.txt logs

enpa-publisher:2024-08-01 13:10:52.317 +00:00] 1info] agenthandler.cpp:172:resolveByEDNS():0x7fc2a88ed770 Querying external DNS server for stitcher.npa.goskope.com

enpa-publisher:2024-08-01 13:10:52.736 +00:00] 1info] agenthandler.cpp:181:0pokljoperator()():0x7fc2a88ed770 Got stitcher IP via EDNS. Stitcher IP is a163.116.213.71]

enpa-publisher:2024-08-01 13:10:52.737 +00:00] 1info] sslclient.cpp:130:prepare():0x0 Connecting to 163.116.213.71

Connectivity using LDNS:

• If connecting to EDNS fails for some reason, the Publisher will try to resolve stitcher.npa.goskope.com by connecting to LDNS server
• The local DNS server then queries the external DNS server and Netskope’s backend responds with the nearest POP based on the source IP of the external DNS server.
• The Publisher then establishes a connection to stitcher.npa.goskope.com based on the IP returned by Netskope’s backend

Connectivity 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 POPs
• If GSLB service for NPA has been enabled from the backend for a tenant, the Publisher will initiate an API call to Netskope’s GSLB service in response to which the API call is returned with a list of nearest POPs based on the Source IP of the request (http://gateway.gslb.goskope.com/)
• The request returns a list of POPs with minimum RTT and this list is retained by the Publisher in its memory. Based on the returned POPs, the Publisher will connect to the first POP in its list.
• If for some reason, the POP is not reachable, the Publisher will connect to the next available POP in the list.
• The logs for connectivity to nearest POP using GSLB can be found in the agent.txt file and they will look like below : 

Summary

In this article it was understood that -

• Publisher registration to Netskope Management Plane is a crucial step in establishing successful end to end NPA workflow
• In order for the Publisher to connect to nearest Stitcher, the Publisher will either use EDNS / LDNS / GSLB mechanism to fetch nearest POP / nearest POP list (when using GSLB)
• This completes the Publisher connectivity flow to the nearest stitcher

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