This guide gives a brief description on the functions and features of Netskope Private Access.
Not applicable
Netskope Private Access is a modern remote access service that:
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:
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:
|
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) |
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.
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:
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.
[KEYPAIR.PEM]
= The path to your KeyPair.pem
file[PUBLISHER]
= The external IP address of the publishercentos
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?
cmd
and then press OK.ssh centos@[publisher]
and then press Enter.centos
centos
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.