Netskope Global Technical Success (GTS)
KB - Simplifying NPA end to end workflow (Part 2)
Netskope Cloud Version - 121
Objective
The objective of the document is to clarify the architecture and flow of Netskope Private access that will help administrators troubleshoot basic NPA issues.
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 basic issues at different levels within the traffic flow.
For simplicity, this guide has been broken down into three parts. This is Part 2 of the document.
Part 1: Link Covers the architectural components and workflow until the client establishes a connection to NPA gateway
Part 2: 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
Before you begin reading this document, it is recommended that you read Part 1 of this Guide
In Part 1, we discussed how the Netskope client establishes a connection to the nearest Private Access Gateway. In , 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
- Publisher has to register itself to Management Plane 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, thePublisher downloads the machine and tenant certificates which are used for mutual authentication with the Stitcher (Publisher Gateway).
- Publisher registration logs can be viewed or downloaded from the Publisher itself. They are present under the logs folder in the 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: xxxxxxxx
2023/05/17 12:21:39 UTC Publisher certificate CN : xxxxx
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, the Publisher will try to establish a connection to Stitcher which resides in the nearest new edge Data Plane.
- The Publisher will attempt to connect to the closest NewEdge POP using will establish a connection to the nearest POP using GSLB (Netskope API), EDNS (DNS over HTTPS), and LDNS (Local DNS) in order of precedence.
- These discovery logs are seen in the Agent.txt log file
- Once the Publisher has obtained the stitcher IP using one of the methods discussed above it will authenticate to the stitcher using the certificates downloaded in Step 1 as part of the Publisher registration. This can be seen in the Agent.txt logs :
>npa-publisher:2024-08-01 13:10:52.736 +00:00] rinfo] agenthandler.cpp:181:operator()():0x7fc2a88ed770 Got stitcher IP via EDNS. Stitcher IP is x.x.x.x
>npa-publisher:2024-08-01 13:10:52.737 +00:00] rinfo] sslclient.cpp:130:prepare():0x0 Connecting to x.x.x.x
>npa-publisher:2024-08-01 13:10:52.753 +00:00] rinfo] socket_tools.cpp:232:connectWithTimeOut():0x0 SO_ERROR value 0
>npa-publisher:2024-08-01 13:10:52.753 +00:00] rinfo] socket_tools.cpp:752:setNoDelay():0x0 Set TCP_NODELAY flag 1 fd 11
>npa-publisher:2024-08-01 13:10:54.077 +00:00] rwarning] sslclient.cpp:71:verify_callback():0x0 Verified: /C=US/ST=CA/L=Santa Clara/O=Netskope Inc./OU=certadmin/CN=xxxxxxxx
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 :
Connectivity using EDNS:
- The 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
- The Publisher sends a DNS over HTTPS request to Google DNS. Google DNS resolves this using Netskope authoritative DNS. The response is partially based on the egress IP address that Google provides to Netskope as part of the DNS over HTTPS request.
anpa-publisher:2024-08-01 13:10:52.317 +00:00] minfo] agenthandler.cpp:172:resolveByEDNS():0x7fc2a88ed770 Querying external DNS server for stitcher.npa.goskope.com
anpa-publisher:2024-08-01 13:10:52.736 +00:00] minfo] agenthandler.cpp:181:0pokljoperator()():0x7fc2a88ed770 Got stitcher IP via EDNS. Stitcher IP is x.x.x.x
anpa-publisher:2024-08-01 13:10:52.737 +00:00] minfo] sslclient.cpp:130:prepare():0x0 Connecting to IP x.x.x.x
Connectivity using Local DNS:
- 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 DNS servers which respond with the nearest Dataplane 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 local DNS.
Summary
In this article it was understood that -
- Publisher registration to Netskope Management Plane is a crucial step in establishing a successful end to end NPA workflow
- In order for the Publisher to connect to the nearest Stitcher, the Publisher will either use GSLB/EDNS/LDNS mechanism to fetch the nearest Data Plane / nearest Data plane 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'.