Netskope Client Network Configuration

This topic describes the various network configuration requirements for Netskope Client with respect to Global Server Load Balancing (GSLB) and how it works.

Client Outbound Connectivity Requirements

For normal functioning, the Netskope Client must be allowed to connect outbound directly to the subnets, domains, ports, and protocols as given in the following tables:

Netskope Client Firewall Allowlist Requirements

The following destinations, ports, and protocols must be allowed on your firewall, proxy, or VPN for the Netskope Client to connect and function correctly. 

Publisher Outbound Connectivity Requirements

This section applies to all Private Access Publisher versions starting with 109.0.0 where the GSLB feature is enabled for Private Access publishers.

NewEdge Traffic Management Gateway Selection

NewEdge Traffic Management 2.0 (GSLB) is a latency-based gateway selection method that uses a proprietary Netskope-hosted API service instead of relying on third-party services such as Google DNS. Global Server Load Balancing (GSLB) provides a better user experience by allowing Netskope to quickly identify and address network issues, improve performance, improve stability, and improve resilience. The Netskope Client now considers many nearby NewEdge data centers and calculates latency (RTT) to each, then selects the data center with the lowest latency. If GSLB cannot be reached then the Netskope Client falls back to the previous extended DNS(EDNS) and local DNS(LDNS) geolocation-based gateway selection behavior.

Supported Operating Systems

GSLB is supported on all operating systems. For more details, view Netskope Client Supported OS and Platform.

Prerequisites

Refer to the tables in the previous sections of this page for Client version and network connectivity requirements. Refer to the Support portal to understand the allowed IP ranges for outbound access on your firewall.

Also, ensure that your VPN is not configured to tunnel those IP ranges through a VPN tunnel. To learn more about VPN compatibility, view VPN Applications.

GSLB Gateway Selection Process

1. The Netskope Client connects to Netskope’s API (gateway.gslb.goskope.com) using HTTPS (tcp/443) to request a list of nearby Netskope data centers.

2. Netskope’s API uses the public IP of the API request to look up the geolocation of the endpoint.

3. Netskope’s API then responds with a list of geographically nearby Netskope data centers.

4. The Netskope Client tests latency to each of the nearby Netskope data centers.

5. The Netskope Client utilizes these latency measurements to pick the best data center (DC). This is generally the one with the lowest latency (RTT); however, in some cases a nearby DC with similar latency characteristics may be selected.

   • If the HTTPS connection to Netskope’s API is steered through a VPN, this will change the public IP of the request and incorrectly geo locate the user, which can result in the Netskope Client connecting to a Netskope data center far from the endpoint.
   • If the endpoint’s public IP is incorrectly registered with geolocation databases, this can result in the Netskope Client connecting to a Netskope data center far from the endpoint.
   • If the HTTPS connection to Netskope’s API is blocked, the Netskope Client will attempt to use EDNS and LDNS for gateway selection.

Netskope Private Access tenants may now take advantage of NewEdge Traffic Management intent-based Zones. Some organizations have inline (or “data in motion”) compliance requirements that restrict inline traffic processing to specific geographical regions.Now, the  Private Access tenants can restrict traffic to supported Zones. To learn more: Configure NewEdge Traffic Management Zones per NPA Tenant.

Gateway Selection Behavior Using EDNS and LDNS

NewEdge Traffic Management 1.0 is a geolocation-based gateway selection method that uses DNS. Initially, the Netskope Client used EDNS to resolve one of the following gateway fully qualified domain names(FQDN):

• gateway-<tenant>[.region].goskope.com

• gateway-backup-<tenant>[.region].goskope.com

  If EDNS resolution fails then the Netskope Client uses LDNS to resolve the gateway FQDNs.

  EDNS Gateway Selection Process

  Refer to the following instructions to understand the EDNS gateway selection process:

  1. The Netskope Client connects to Google DNS (dns.google) using DNS over HTTPS (tcp/443) to request an IP for gateway-<tenant>[.region].goskope.com.

  2. Google DNS uses the public IP of the DNS over HTTPS request to look up the geolocation of the endpoint.

  3. Google DNS then resolves gateway-<tenant>[.region].goskope.com to the Netskope data center geographically closest to the endpoint’s public IP.

  4. The Netskope Client connects to the Netskope data center using the provided IP.

     • If the DNS over HTTPS connection is steered through a VPN, this changes the public IP of the request and incorrectly geo-locates the user, which can result in the Netskope Client connecting to a Netskope data center far from the endpoint.
     • If the endpoint’s public IP is incorrectly registered with geolocation databases, this can result in the Netskope Client connecting to a Netskope data center far from the endpoint.
     • If the DNS over HTTPS connection is blocked, the Netskope Client attempts to use LDNS to resolve gateway-<tenant>[.region].goskope.com.

LDNS Gateway Selection Process

Refer to the following instructions to understand the LDNS gateway selection process:

1. The Netskope client uses the endpoint’s configured DNS server using standard DNS (udp/53) to resolve gateway-<tenant>[.region].goskope.com.

2. The Netskope Client connects to the Netskope data center using the provided IP.

   If the DNS server’s public IP is registered geographically far from the endpoint, this can result in the Netskope Client connecting to a Netskope data center far from the endpoint. For example, if the endpoint is in San Jose, CA, but it is configured to use a corporate DNS server located in Ashburn, VA, the endpoint will connect to a Netskope data center near Ashburn, VA. This would result in significant additional latency for all Internet and Private Access connectivity through Netskope.

GSLB Fallback in China

With the release of version 121.0.7, for tenants using Netskope’s POPs in China, devices running Netskope Client outside China can now fallback to EDNS and then to LDNS when GSLB is not reachable. At the same time, devices with Netskope Client in China continue to use GSLB exclusively to ensure that those users only connect to Netskope POPs within China.

Validate EDNS/LDNS 

You can check for the country code in your logs while debugging:

• If the location is in China:

  2024/09/25 17:33:58.421 stAgentSvc p1d14 t1ed8 info GatewaySelection.cpp:139 gslb [NSClient] Pops fetched begin rtt_protocol:tcp country:CN

• If the location is outside China:

  2024/09/25 09:09:52.105766 stAgentNE p14257 t15367 info GatewaySelection.cpp:139 gslb [NSClient] Pops fetched begin rtt_protocol:http country:US

Netskope Client in a Non-Proxy Environment

Here are the packet flow details of how the cloud app traffic is intercepted and sent through the tunnel when the client is installed in a non-proxy environment:

Netskope Client in an Explicit Proxy Environment

Here are the packet flow details of how the Cloud app traffic is intercepted and sent through the tunnel when the client is installed in an explicit proxy environment:

1. The Client establishes the SSL tunnel between the Client and the Netskope gateway. The Client first tries to connect directly through default gateway to establish the SSL tunnel. If this is blocked, then it looks for system proxy settings, such as PAC (proxy auto-config) files, WPAD (Web Proxy Auto-Discovery Protocol), and manual configuration. The client uses the proxy settings and connects to the Netskope gateway via HTTP Connect.

   The Netskope gateway should be SSL allowlisted if the proxy is configured for SSL decryption. If your environment uses firewall or proxy, ensure that you process the backup gateway URL in the same manner as the primary gateway URL. The backup gateway URL is suffixed with gateway-backup to your primary URL.

2. The browser or native app reads the proxy settings (PAC file, explicit proxy setting) and opens a connection to an explicit proxy server, for example: ep.customer.com.

3. The client parses the initial header of the connection.

4. If the initial header indicates the connection is:

   • Cloud mode (SaaS app): The initial header indicates the hostname of the SaaS application. If the hostname is not a part of the managed SaaS application exception configuration, the Client bypasses the traffic to a local proxy server.

   • Web and All Traffic mode: The initial header indicates the hostname of the web application. If the hostname is a part of the exception, the Client bypasses the traffic to a local proxy server. Otherwise, the traffic is tunneled to the Netskope gateway.

5. If the initial header does not indicate SaaS app HTTPS access, the Netskope Client bypass the traffic and forwards the entire payload to the explicit proxy server. For example:  ep.customer.com.

Netskope Client Log Messages with On-prem Proxy

Steering traffic flow and Log message: With on-prem proxy, the Netskope Client monitors for HTTP CONNECT requests. It checks for the domain name in these requests against the managed domain list. If the name matches then it will reconstruct the TCP SYN packet and send it through the Netskope Tunnel and at the same time it will send TCP RST to on-prem proxy, and it will take control of that connection. After the TCP 3-way handshake with Netskope proxy, it sends the HTTP CONNECT request and the flow continues with Netskope proxy. Since TCP flow will be with destination IP of on-prem proxy when Netskope Client logs the message, it will show destination IP as on-prem Proxy and the domain name will be the managed domain.

Assuming on-prem Proxy IP is 10.10.10.11 and Proxy port is 8080 and the managed domain is www.box.com then you will see the log line as below:

2021/07/18 17:16:11.282 stAgentSvc pfbc t296c 4 tunnel.cpp:618 nsTunnel TLS [sessId 1]
Tunneling flow from addr: 192.168.13.40:49614, 
process: chrome.exe to host: www.box.com,addr: 10.10.10.11:8080