Explicit Proxy over IPSec and GRE Tunnels

In certain cases, you may 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, and other configurations are 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. The PAC file, as noted in the first point, already contains most of that information, if not all.
Often administrators do not want to manipulate servers by installing a client, or server subnets by directing them through tunnels due to their critical nature to the business. Explicit proxy is an excellent alternative to and can be set and locked down using a number of methods (GPO, for instance).
Explicit proxy is browser-centric. While Windows and OS X have OS-based proxy settings, these generally work fine (see FAQ), and all operating systems can install browsers that are OS agnostic (like FireFox) when it comes to explicit proxy. This means you can cover platforms that are currently not supported by the Netskope Client like Linux with explicit proxy.

You can use an existing or new PAC file, or manual proxy settings, over IPSec or GRE tunnels with the Netskope Platform.

For example:

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 8080, either manually or via a PAC file. Ensure you don't use any other IP addresses to send traffic.
The session is redirected down the IPSec or GRE tunnel by the access list on the firewall or router matching on port 8080, which terminates at the Netskope IPSec or GRE headend.
The cloud forward proxy sees the request (more specifically, the HTTP request method) incoming on port 8080 and routes it to the appropriate cloud service on port 80 or 443 for proxying.
If you have Cloud Firewall enabled, Explicit Proxy IP addresses and ports used for tunnels must be defined in your Steering Configuration to start listening on the specified ports for HTTP/HTTPs traffic.

The test is set up as shown:

For this first test, Firefox 74.0 (64-bit) on Windows 10 is being used due to its ease of proxy configuration (other browsers on Windows tend to use the OS proxy settings) with the following 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.

Important

8080 traffic must be sent to the cloud over the tunnel via access lists for this to work properly.

Three test cases will be tested to show the different identities shown in Skope IT, as well as the different internal IP’s being captured, just as they would be over an IPSec or GRE tunnel without explicit proxy.

Test Case 1 – Single Workstation, No Netskope Client

As expected, the access method is IPSec and the identity is reported as the internal IP address of the workstation. The traffic is going over 8080, an ACL is redirecting 8080 down the tunnel, and the Netskope Forward Proxy intercepts and blocks based on a policy prohibiting Gambling sites.

Test Case 2 – Two Workstations, No Netskope Clients

In this scenario, two Windows 10 workstations are going over an IPSec tunnel, both using Firefox configured for explicit proxy. The internal IP address is properly identified from both, and is the only identity provided. The access method is seen as IPSec.

Test Scenario 3 – Two Workstations, One With Netskope Client, One Without

As shown, the workstation with the Netskope client is still showing IPSec as the access method, but the username is being captured along with the internal IP. The Netskope Client on this workstation shows as such:

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

The host without the Client continues to show only the Internal IP address as the identity:

As an additional example, a PAC file has been created (see Explicit Proxy PAC File Example) and applied with the following settings/exceptions as shown here:

Points to 163.116.128.80:8080 for HTTP/HTTPS
No proxy for https://www.bestcasinosites.net (take it DIRECT). The test policy blocks Gambling, but this statement will allow this domain by not sending it to the explicit proxy
DIRECT statement for fail through in case of any issues with upstream proxy (tunnel goes down, for instance).

Before applying the PAC to the browser, the above mentioned site resulted in a block (notice timestamp):

With the PAC file in place containing do not proxy for bestcasinosites.net, the request was sent direct via the native port 443, not 8080, and therefore was not sent down the tunnel to the forward proxy and blocked. This resulted in access to the site, as well as no log entry in Skope IT.

In summary, explicit proxy over IPSec or GRE works as expected, applying all manual settings or the PAC config, and the tunnel behaves as it would in any other scenario (action determined by access lists). The internal IP addresses are tracked properly, and while the Client deactivates intelligently due to a protected site, the Client adds identity while also listing the correct internal IP address.

FAQ

Q. Can I use any browser to achieve this?

A. Yes, but there are exceptions based on the OS.

On Linux/Mac, any browser should work just fine using manual explicit configurations in the OS, the browser (if available), or a PAC file.
On Windows 10, there’s a known issue with FTP and File protocols if hosting the PAC file on the host itself. See Windows 10 does not read a PAC file referenced by a file protocol for more information.

Q. Do I have to use the provided IP for explicit proxy?

A. Yes, it is preferred that 163.116.128.80 is used when configuring explicit proxy. This IP address has been reserved specifically for this purpose.

Q. What ports can I configure to work with explicit proxy? Could I send FTP to the explicit proxy?

A. The only proxy settings currently supported are HTTP and HTTPS. All other traffic sent to the proxy will be dropped. Likewise, 80, 443, and 8080 are the only ports supported. All other port traffic will be dropped.

Q. Should you intercept all three ports using access lists on the router/firewall and send them down the IPSec or GRE tunnel?

A. No, for two reasons:

You’ll effectively break the ability to bypass with the explicit proxy config. Let’s say you set a bypass as shown in the config above for .bestcasinos.net, and you’re blocking Gambling as a category. The request would bypass the explicit proxy on 8080, and get sent over 443, and would get intercepted by the access list and be sent down the tunnel and then blocked, which negates the purpose of using the PAC/manual explicit proxy settings for bypass.
Simplification is a great use case for explicit proxy; rather than listen on all three ports, listening on one port simplifies the config on both the host and the router/firewall. As in this case, the PAC file often already exists, theres no need to change the configuration if already using 8080.

Explicit Proxy PAC File Example

This is the PAC file used for testing.

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 :8080 *, bypass all else */
if (url.substring(0, 5) == 'http:' ||
url.substring(0, 6) == 'https:')
{
return 'PROXY 163.116.128.80:8080';
}
return 'DIRECT';
}

In this section:

Netskope Help