Netskope Client Network Configuration

Client Version: 109.0.0 or later

The following section applies to tenants with Client version 109.00 or later where the GSLB feature is enabled for SWG and NPA.

Client Version: 103.0.0 to 108.x.x

This section applies to tenants with Client version 103.0.0 or later where the GSLB feature is enabled for SWG and disabled for NPA.

All Client Versions

This section applies to all tenants with any Client version where the GSLB feature is disabled for SWG and NPA.

Publisher Outbound Connectivity Requirements

This section applies to all NPA Publisher versions starting with 109.0.0 where the GSLB feature is enabled for NPA 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

New behavior 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 connects to the Netskope data center with the lowest latency.

   • 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  NPA 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.

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:

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.

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