Article Number: 000126828
What is Netskope Private Access?
Summary: Netskope Private Access is part of the Netskope security cloud and enables zero-trust secure access to private enterprise applications in Hybrid IT.
Article Content
Symptoms
This guide gives a brief description on the functions and features of Netskope Private Access.
Affected Products:
- Netskope
Affected Versions:
- Release 70+
Cause
Not applicable
Resolution
Netskope Private Access is a modern remote access service that:
- Fans out to enable access to applications in multiple networks, both in the public cloud (such as Amazon Web Services, Azure, Google Cloud Platform) and in the data center.
- Provides zero trust application level access instead of network access with lateral movement.
- Is delivered as a cloud service with a worldwide footprint that scales.
Netskope Private Access delivers these benefits through a capability called Service Publishing. Service Publishing makes enterprise applications available at and through the Netskope cloud platform instead of at the enterprise's network edge.
The Netskope cloud platform becomes the location on the Internet through which enterprise applications are accessed. In a sense, this externalizes the access components of the demilitarized zone (DMZ). Externalizing remote access in this way has several advantages over traditional virtual private networks (VPN) and proxy-based remote access approaches. Service Publishing’s overall architecture and delivery-as-a-service model is consistent with IT trends. These include infrastructure as a service, Hybrid IT, and the decentralized delivery of enterprise applications from the data center, public cloud, and software as a service (SaaS).
Netskope Private Access extends Netskope’s platform for secure access to SaaS and web. This includes secure access to private applications that live behind an enterprise’s firewalls in the data center and the public cloud.
The following are common questions that are asked about Netskope Private Access:
Note: Some questions may redirect you to a different page due to the complexity and length of the answer.
Netskope Private Access system requirements differ between deployment environments. For more information, reference: System Requirements for a Netskope Private Access Publisher.
| Component | URL | Port | Notes |
|---|---|---|---|
| Client | gateway.npa.goskope.com Before February 2020: gateway.newedge.io |
TCP 443 (HTTPS) | |
| Publisher | stitcher.npa.goskope.com Before February 2020: stitcher.newedge.io |
TCP 443 (HTTPS) UDP 53 (DNS) |
DNS is not required to be allowed outbound if there is a local network DNS server internally. |
| Client and publisher | ns[TENANTID].[MP-NAME].npa.goskope.com Before February 2020: ns-[TENANTID].newedge.io |
TCP 443 (HTTPS) | This is needed one time only during the registration. Example URL: ns-1234.us-sv5.npa.goskope.com [MP-NAME] variables:
|
Note:
- [TENANTID] = The tenant identification unique to your environment
- [MP-NAME] = The Netskope management plane location
- For assistance in identifying your [TENANTID] or [MP-NAME], reference: How to Get Support for Netskope.
- The default ports may differ from the ports in your environment.
To connect users with applications and services, a Netskope Private Access administrator must configure private app policies within the Netskope UI in a few places. Here are the configuration options and details for known application and service types.
| Application | Protocol and Port | Factors |
|---|---|---|
| Web Traffic | TCP: 80, 443 (custom ports: 8080, so forth) UDP: 80, 443 |
Google Chrome uses the QUIC protocol (HTTP/S over UDP) for some web applications. Duplicating the web browsing ports for both TCP and UDP can provide a performance improvement. |
| SSH | TCP: 22 | |
| Remote Desktop (RDP) | TCP: 3389 UDP: 3389 |
Some Windows Remote Desktop Protocol (RDP) client apps (such as newer Windows 10 versions) prefer to use UDP:3389 to perform Remote Desktop connectivity. |
| Windows SQL Server | TCP: 1433, 1434 UDP: 1434 |
The default port for Windows SQL Server is 1433, though this can be customized in your environments. For more information, reference Configure the Windows Firewall to Allow SQL Server Access (https://docs.microsoft.com/sql/sql-server/install/configure-the-windows-firewall-to-allow-sql-server-access?view=sql-server-2017) . |
| MySQL | TCP: 3300-3306, 33060 TCP: 33062 (for admin-specific connections) |
For general MySQL connection use cases, only port 3306 is required, but some users may take advantage of the additional MySQL feature ports. Netskope recommends using a port range for MySQL database private apps. MySQL blocks connections from the Netskope Private Access publisher because it detects the reachability test as a potential attack. Using a range in the port configuration results in the Netskope Private Access publisher performing a reachability check only on the first port in the range. This prevents MySQL from seeing this traffic and avoiding the port block. For more information, reference MySQL Port Reference Tables (https://dev.mysql.com/doc/mysql-port-reference/en/mysql-ports-reference-tables.html) . |
Note: The default ports may differ from the ports in your environment.
Yes. Netskope Private Access can tunnel apps outside of that list. Netskope Private Access supports both the TCP and UDP protocols and all associated ports, with one notable exception: Netskope does not tunnel most DNS traffic, but we do support tunneling DNS service (SRV) lookups over port 53. This is needed for service discovery, which is used in various Windows Active Directory scenarios involving LDAP, Kerberos, and more.
Note: Sometimes applications like VoIP can be problematic. This is not caused by tunneling, but rather configuration. For example, applications that perform dynamic port allocation when establishing a connection can be problematic. This is because an admin cannot know which ports to set up by the service end of the application in advance. Because of this, there is no way to know what ports to specify.
The polling interval is about one minute.
Netskope Private Access Publisher tries to connect to a configured port on a private app to check whether the private app is reachable.
Important factors to consider:
- The publisher works best when you define private apps by hostname (for example, jira.globex.io) and port (for example, 8080).
- When an app is specified with multiple ports or a port range, the publisher uses the first port from the list or range to check availability.
- The publisher cannot check reachability for private apps that are defined with a wildcard (*.globex.io) or CIDR block (10.0.1.0/24). It also does not check reachability of apps with port ranges defined (3305-3306).
If the registration fails (for example, because a digit was missed while entering the registration code), SSH into the publisher and provide a new registration token.
If the registration succeeded, but you decided to register the publisher with another token, this is unsupported and not advised. In this scenario, reinstall the publisher.
No. Netskope Private Access does not tunnel ICMP, only TCP and UDP. You cannot run ping or traceroute over Netskope Private Access to test network connections.
No. Netskope Private Access does not support protocols that establish connections from a private app to a Client. For example, FTP Active mode is not supported.
No. The publisher does SSL pinning for the registration process and server-side certificate authentication against a specific certificate.
In this case, if there is any proxy which terminates the TLS connection, the destination must be allowlisted/bypassed (*.newedge.io).
The private app host sees the connection as originating from the IP address of the publisher that is connecting to it. There is no range. Depending upon the number of publishers used to connect to the private app host, allowlist each of those IP addresses.
If deployed into Amazon Web Services, assign the Amazon Machine Image (AMI) a KeyPair.pem that you already have (or generate a new KeyPair.pem) during the provisioning of the publisher.
From an SSH client, type ssh -i [KEYPAIR.PEM] centos@[PUBLISHER] and then press Enter.
Note:
[KEYPAIR.PEM]= The path to yourKeyPair.pemfile[PUBLISHER]= The external IP address of the publisher- The default username for the publisher is:
centos
- The default username for Amazon Web Service AMIs is:
ec2-user
After successfully using SSH to connect to the publisher, you are placed into an interactive command-line interface (CLI) menu. You can choose option 3 to be placed into a normal UNIX CLI for additional troubleshooting. For more information, reference What is a good method for troubleshooting accessibility issues to a private app/service behind a publisher?
- Right-click the Windows Start Menu and then click Run.
- In the Run UI, type
cmdand then press OK.
- In the Command Prompt, type
ssh centos@[publisher]and then press Enter.
Note:
- [publisher] = The external IP address of the publisher
- The default credentials for the publisher are:
- Username:
centos - Password:
centos
- Username:
- The password must be changed after first login.
Publishers work in active/passive mode. All traffic goes to a first publisher if it is operational (connected). If it goes down, we switch over to a secondary publisher.
The first best option is to use the Troubleshooter. Click Troubleshooter from the Private Apps page.
Choose the private app and device that you are trying to access, and then click Troubleshoot.
The Troubleshooter renders the list of performed checks, issues which may affect your configuration, and solutions.
To contact support, reference Dell Data Security International Support Phone Numbers.
Go to TechDirect to generate a technical support request online.
For additional insights and resources, join the Dell Security Community Forum.
Additional Information
Videos
Article Properties
Affected Product
Netskope
Last Published Date
31 Jan 2023
Version
14
Article Type
Solution