Skip to main content

Netskope Help

Netskope Client Network Configuration

For the normal functioning of the client, a set of outbound domains and port 443 must be allowed in the user's firewall or proxy. The following table describes the list of domains and ports used by the client.

Note

  • Firewall address: We recommend the use of IP addresses instead of domain names to configure firewall or proxy rules allowlist. If your environment uses a 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 the primary URL.

  • HTTP/2: We negotiate HTTP/2 for all domains if the origin server supports it, otherwise, we fallback to HTTP 1.1. All other traffic will continue to leverage HTTP 1.1. In addition, the Netskope Client and GRE / IPSEC and iOS access methods are fully supported. The protocol change is completely transparent to users, no configuration is required by admins. Contact Support to enable this feature in your account.

  • iOS device behind NAT: While using Guest WiFi for your iOS users, all iOS devices behind a NAT device establish a VPN connection with the Netskope Cloud VPN server with a NATted IP address. Netskope recommends you to use multiple NAT IPs to avoid slow VPN connection or performance degradation. By using multiple NATted IPs, the VPN connection gets distributed to multiple VPN gateways because of the load balancing algorithm that is currently based on the source IP address.

Table 22. Network Settings for Secure Web Gateway (SWG)

Domain

Purpose

  • Primary: gateway-<tenant_hostname>.goskope.com

  • Backup: gateway-backup-<tenant_hostname>.goskope.com

For client data plane connectivity. This domain needs to be SSL allowlisted on the egress firewall if SSL interception is enabled. Also, do the same for gateway-backup-{tenant_hostname}.goskope.com

addon-<tenant_hostname>.goskope.com

For downloading configuration files and dynamically detecting proxies.

download-<tenant_hostname>.goskope.com

For downloading client package updates.

achecker-<tenant_hostname>.goskope.com

For client enforcement. This is required to enforce the end-user to install the Client on their device. If the Client is not installed in the users' device, access to an app or domain specified in the steering configuration is restricted and the user is redirected to a browser page with instructions to install the Client.

sfchecker.goskope.com

To verify secure forwarder connection.



Note

For international deployments, use one of the following as per the region of the your home PoP:

  • <tenant_hostname>.eu.goskope.com

  • <tenant_hostname>.de.goskope.com.

  • <tenant_hostname>.au.goskope.com.

To learn more about the network settings for Network Private Access (NPA), view NPA settings.

Netskope Client POP Selection
Existing Behavior (Prior to version 100.0.0)

The Netskope Client resolves the IP Address of the Netskope gateway (gateway-tenant_hostname.goskope.com) using DNS over HTTPS to be able to allow the user to connect to the best possible PoP based on the users’ location. In the event that ECS and DNS over HTTPS fails, the Client will resolve the IP Address using LDNS.

New Behavior (Applicable from version 100.0.0)

Note

This behavior is currently in Controlled General Availability. Contact your Sales Representative or Netskope Support to enable this for your tenant.

Supported operating systems

  • Windows versions 10, 11

  • macOS versions 11,12, 13

Prerequisite

Ensure that the following IP ranges are allowed for outbound access on your firewall:

  • 8.39.144.0/24

  • 31.186.239.0/24

  • 163.116.128.0/17

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.

Netskope adds a new service in the cloud to enhance the Gateway selection that helps the Netskope Client to connect to the nearest Netskope POP. This eliminates the need to use Google DNS service (dns.google) to resolve the NS Gateway domains. While making a REST API call to gateway.gslb.goskope.com, the GSLB services provides a POP list based on the client IP address. The list contains the RTT endpoints used to calculate the RTT for each POP.

Limitation

The new POP selection enhancement is not applicable for NPA (Netskope Private Applications).

Note

Netskope recommends blocking DNS over HTTPS (DoH) as it enforces the browsers to use the DNS hostname resolution. In this way, Netskope Client continues to monitor the DNS responses and maintain the IP address to hostname mapping.

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:

  1. The Client establishes the SSL tunnel between the Client and the Netskope gateway.

  2. Browser/App sends a DNS request for a managed cloud service (For example: Box.com)

  3. Browser/App receives a DNS response (For example: 74.112.184.73)

  4. The Client driver captures DNS response and creates a map of domain and IP (For example: Box.com = 74.112.184.73 for cloud app domains)

  5. Browser/App sends packets to Box.com (For example: DST IP 74.112.184.73)

  6. Client tunnels Box traffic (For example: DST IP 74.112.184.73) through the SSL tunnel.

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 will first try 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. 

    Note

    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 a SaaS app, then the client sends the entire payload through that SSL tunnel to the Netskope gateway.

  5. If the initial header does not indicate SaaS app HTTPS access, the TCP proxy opens a connection to 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
In this section: