Explicit Proxy over IPSec and GRE Tunnels - Netskope Technical Documentation

In certain use cases, you might want to use explicit proxy over IPSec or GRE tunnels. For example:

There is an existing proxy PAC file in place, and you want to use it for exceptions, but you have other configurations already scripted into the PAC file.
There’s a current resource limitation in the IPSec or GRE tunnel origin gear, and you want to limit the number of ACL’s/Objects required to get traffic to the cloud; however, the PAC file already contains all or most of that information.
You don’t want to manipulate servers by installing a client or server subnets by directing them through tunnels due to their critical nature to the organization. Explicit proxy is an excellent alternative where you can set and lock down using a number of methods (e.g., GPO).
Explicit proxy is browser-centric. While Windows and OS X have OS-based proxy settings, these generally work fine, and all operating systems can install browsers that are OS agnostic (e.g., Firefox) when it comes to explicit proxy. This way you can cover platforms that aren’t supported by the Netskope Client with explicit proxy, such as Linux.

General Guidelines

When configuring EPoT, consider the following:

You can use an existing or new PAC file or manual proxy settings over IPSec or GRE tunnels.
The explicit proxy configuration can point HTTP/HTTPS traffic to one of the reserved IP addresses 163.116.128.80 or 163.116.128.81 on port 80 (recommended) or 8080, either manually or using a PAC file. You can also point to the DNS record epot.goskope.com. Ensure you don’t use any other IP addresses to send traffic.
Netskope strongly recommends using port 80 for EPoT and does not recommend port 8080.
With Cloud Firewall:
- If you’re using port 80, you don’t need to do anything additional.
- If you’re using port 8080, you must also define port 8080 in your Steering Configuration under Non-Standard Ports.
The browser session is redirected down the IPSec or GRE tunnel by the access list on the firewall/router matching on port 80 or 8080, which terminates at the Netskope IPSec or GRE headend.
The cloud forward proxy sees the incoming HTTP request on port 80 or 8080 and routes it to the appropriate cloud service on port 80 or 443 for proxying.
You must create steering exceptions in your PAC file.
You can use any browser; however, consider the following exceptions:
- On Linux or MacOS, you must use manual explicit configurations in the OS, the browser (if available), or PAC file.
- On Windows 10, there’s a known issue with FTP and File protocols if you’re hosting the PAC file on the host itself. To learn more: Microsoft documentation.
The only proxy settings currently supported are HTTP and HTTPS. Netskope drops all other traffic (e.g., FTP) sent to the proxy. Likewise, Netskope only supports ports 80, 443, and 8080. All other port traffic will be dropped.
Netskope doesn’t recommend intercepting all three ports using access lists on the router/firewall and sending them down the IPSec or GRE tunnel, because:
- You can effectively break the ability to bypass with the explicit proxy configuration. For example, let’s say you set a bypass as shown in the configuration above for.bestcasinos.net, and you’re blocking gambling as a category. The request bypasses the explicit proxy on 8080, gets sent over 443, gets intercepted by the access list, and then is sent down the tunnel and blocked. This behavior negates the purpose of using the PAC/manual explicit proxy settings for bypass.
- Simplification is a great use case for explicit proxy. Rather than listening on all three ports, listening on one port simplifies the configuration on the host and the router/firewall. Usually, the PAC file already exists, and there’s no need to change the configuration if already using 80 or 8080.

Explicit Proxy over Tunnel Use Cases

Netskope uses Firefox 74.0 (64-bit) on Windows 10 for all use cases due to its ease of proxy configuration (other browsers on Windows tend to use the OS proxy settings). Following are the browser connection settings:

The IP address 163.116.128.80 used is reserved for explicit proxy.
Domains that should not be sent to the proxy can be configured here as well. In this instance, .bestcasinosites.net, .zoom.com, .zoom.us and .lastpass.com; notice no wildcard. The first site is for testing the bypass to avoid blocking; the last three sites are for ensuring that those services are not intercepted and broken by the explicit proxy.
The traffic is being sent over an IPSec tunnel that can be created by any capable CPE (customer premise equipment) to the Netskope cloud; see the Netskope UI for supported versions/ciphers, etc.
80 traffic must be sent to the cloud over the tunnel via access lists for this to work properly.

Below are three uses cases showing the different identities in Skope IT as well as the different internal IP addresses being captured, just as they will be over an IPSec or GRE tunnel without explicit proxy.

Use Case #1: One Device Without Netskope Client

In Skope IT, you can see that the access method is IPSec, and Netskope reports the device’s identity as the internal IP address. The traffic is going over 80, an ACL is redirecting 80 down the tunnel, and the Netskope Forward Proxy intercepts and blocks based on a policy prohibiting gambling sites.

Use Case #2: Two Devices Without Netskope Client

In Skope IT, you can see two devices running Windows 10 going over an IPSec tunnel and using Firefox configured for explicit proxy. Netskope identifies the internal IP address for both devices and reports the access method as IPSec.

Use Case #3: One Device With Netskope Client & One Device Without Netskope Client

In Skope IT, Netskope still shows IPSec as the access method for the device even thought it’s running the Netskope Client. However, Netskope also captures the username along with the internal IP address.

The Netskope Client installed on this device has the following configuration settings:

The Netskope Client detects the tunnel and upstream proxy. While the client steering is deactivated, it continues to pass on identity information (i.e., The Netskope Client on this device was enrolled via SAML 2.0/Okta User Enrollment).

However, the device without the Netskope Client installed only shows the internal IP address as the identity:

Use Case #4: Using Explicit Proxy to Block Gambling

Following is the example PAC file script for Explicit Proxy:

function FindProxyForURL(url, host) {
  /* Convert all URLs to lower case, more consistent and better for pattern matching*/
  url = url.toLowerCase();
  host = host.toLowerCase();
  /* Send all hosts with no FQDN direct to internet */
  if (isPlainHostName(host)) {
    return "DIRECT";
  }
  /* Don't proxy IDP servers. */
  /*
    if ((dnsDomainIs(host, '.okta.com'))
    {
    return 'DIRECT'
    }
  */
  /* Send Zoom urls direct…if this is not used, proxy will break Zoom! */
  if (dnsDomainIs(host, ".zoom.com") || dnsDomainIs(host, ".zoom.us")) {
    return "DIRECT";
  }
  /* Don’t send RFC1918 and a few others to the proxy */
  if (
    isInNet(host, "10.0.0.0", "255.0.0.0") ||
    isInNet(host, "127.0.0.0", "255.0.0.0") ||
    isInNet(host, "169.254.0.0", "255.255.0.0") ||
    isInNet(host, "172.16.0.0", "255.240.0.0") ||
    isInNet(host, "192.168.0.0", "255.255.0.0")
  ) {
    return "DIRECT";
  }
  /* Send only http and https to proxy on :80 *, bypass all else */
  if (url.substring(0, 5) == "http:" || url.substring(0, 6) == "https:") {
    return "PROXY 163.116.128.80:80";
  }
  return "DIRECT";
}

Here are the configured browser settings and exceptions:

The example PAC file points to 163.116.128.80:80 for HTTP/HTTPS.
In the browser settings, no proxy for https://www.bestcasinosites.net (take it DIRECT). This policy blocks gambling but allows the domain because it’s going through the explicit proxy.
DIRECT statement for fail-through in case of any issues with upstream proxy (e.g., tunnel goes down).

Before applying the PAC to the browser, Netskope blocked the gambling site in Skope IT:

After applying the PAC file with No Proxy set for bestcasinosites.net, Netskope sent the traffic request directly via the native port 443, not 80. Hence, Netskope didn’t send it down the tunnel to the forward proxy and block it. It allowed access to the site and didn’t log the entry in Skope IT.

Overall, explicit proxy over tunnel works well when applying all manual settings or configuring a PAC, and the tunnels behave depending on the actions you set in your access lists. You can track the internal IP addresses properly in Skope IT, and while the Netskope Client deactivates intelligently due to a protected site, it adds identity while also listing the correct internal IP address.

Use Case #5: Using Explicit Proxy with Steering Disabled on Netskope Client

Ensure you steer achecker<Tenant ID>.goskope.com through the IPSec or GRE tunnel. Also, under Tunnel Settings in Client Configuration select Enable device classification and client-based end user notifications when the client is not tunneling traffic.