Cloud SWG Agent and Proxy Auto-Configuration
search cancel

Cloud SWG Agent and Proxy Auto-Configuration

book

Article ID: 278865

calendar_today

Updated On:

Products

Cloud Secure Web Gateway - Cloud SWG

Issue/Introduction

As a Cloud SWG administrator, my goal is to grasp how the agent utilizes a proxy/PAC to manage application-generated traffic.

Additionally, I aim to leverage a PAC file for executing application-layer redirection or routing within browsers or any proxy-aware application.

Environment

Symantec Enterprise Agent

Symantec Cloud SWG Agent

SEP Agent (Tunnel Mode)

Proxy-Auto Configuration (PAC) File

Resolution

The agent does not modify or suppress the proxy settings on the device. 

Proxy Detection:

The agent monitors proxy traffic in the system, ensuring that proxy requests from applications are routed through Cloud SWG by utilizing the designated proxy destination, ep.threatpulse.net.

This functionality is enforced even for proxies operating on RFC-1918 addresses.

Exempt a specific proxy from proxy detection:

To Exempt a specific proxy: Add the IP address(es) of the proxy to the Cloud SWG portal Bypassed IPs/Subnets list.   Refer to Prevent IP/Subnet From Routing to Cloud SWG and Prevent a Domain From Routing to Cloud SWG.

Note:  The on-prem proxy IP needs to be added even if the proxy is hosted on an RFC1918 address. Even though RFC1918 addresses are bypassed automatically by the agent, the proxy detection does NOT automatically skip RFC1918 addresses.

PAC-based Routing with Cloud SWG and On-Prem Proxies:

Performing application-layer redirection is achievable through a PAC file as follows:

  1. Applications which do not honor the system proxy will behave identically to DIRECT.
  2. Represents an on-prem proxy server that has been bypassed in Cloud SWG.
  3. Represents any other HTTP proxy server that is not bypassed in Cloud SWG.

Note: 

At the application layer, when the request is directed to ep.threatpulse.net. The agent, operating at the network layer, does not conduct protocol analysis on the content encapsulated within the proxy request, therefore, the executable/IP/domain bypass will not be honored.

You will need to add the domain/IP to be sent DIRECT in the PAC file, at this point, the request will be intercepted by the agent. Subsequently, the agent will determine whether to bypass the request or send it through Cloud SWG proxies.

Therefore, anything you bypass in the Cloud SWG bypassed traffic list will also need to be bypassed in the PAC file.

It is recommended that ALL Domain/IP/App bypasses are added in the Cloud SWG Portal.

Note:

ep.threatpulse.net is an internal destination that cannot be bypassed, therefore, It will always be tunnelled.  

The destination ep.threatpulse.net is not available outside of the Cloud SWG tunnel, and as such, your PAC file can use that for “fallback” functionality when the agent is disconnected.  For example, returning “PROXY ep.threatpulse.net:80,1.2.3.4:8080” as a PAC file directive will connect to the cloud proxy when a tunnel is established and will fall back to 1.2.3.4:8080 in the event there is no agent tunnel to the Cloud SWG service.

Additional Information

Logic to determine how PAC file affects routing:

Example PAC File:

function FindProxyForURL(url, host) {

  // Send example1.com direct - example1.com is also bypassed in Cloud SWG configuration

  if (shExpMatch(host, "(*.example1.com|example1.com)")) {

    return "DIRECT";}

  // Send example2.com to internal proxy - 10.1.2.3 is also bypassed in Cloud SWG configuration

  if (shExpMatch(host, "(*.example2.com|example2.com)")) {

    return "PROXY 10.1.2.3:8080";}

  // Send example3.com to external proxy - example3.com is also bypassed in Cloud SWG configuration

  if (shExpMatch(host, "(*.example3.com|example3.com)")) {

    return "PROXY 1.2.3.4:8080";}

  // Always send example4.com explicitly through Cloud SWG proxy if no Tunnel failback to on-prem proxy

  if (shExpMatch(host, "(*.example4.com|example4.com)")) {

    return "PROXY ep.threatpulse.net:80,1.2.3.4:8080";}

  // DEFAULT RULE: send everything else direct

  return "DIRECT"}


The following requests will be processed as follows:

Example1.com

  • The browser will resolve this via the PAC file to be "DIRECT".
  • The browser will establish a TCP connection to example1.com
  • The agent will "see" traffic to example1.com
  • Traffic to example1.com is bypassed, the agent will hand this traffic to the OS for default routing.

Example2.com

  • The browser will resolve this via the PAC file to be "10.1.2.3:8080" 
  • The browser will establish a TCP connection to 10.1.2.3 (NOT example2.com)
  • The agent will "see" traffic to 10.1.2.3 (NOT example2.com)
  • Traffic to 10.1.2.3 is bypassed, the agent will hand this traffic to the OS for default routing

    Note: 10.1.2.3 must be in the Cloud SWG bypass list, even though it is RFC1918 or else the request will be redirected to ep.threatpulse.net:80 instead.

Example3.com

  • The browser will resolve this via the PAC file to be "1.2.3.4:8080" 
  • The browser will establish a TCP connection to 1.2.3.4 (NOT example3.com)
  • The agent will "see" traffic to 1.2.3.4 (NOT example3.com)
  • Traffic to 1.2.3.4 is not bypassed, the agent will redirect the proxy request via ep.threatpulse.net:80

    Note: Even though example3.com is bypassed, the agent does not "see" a request going to example3.com - therefore, the request is still sent through CloudSWG via ep. threatpulse.net:80

Example4.com

  • The browser will resolve this via the PAC file to be "ep.threatpulse.net:80" 
  • The browser will establish a TCP connection to ep.threatpulse.net (NOT example4.com)
  • The agent will "see" traffic to ep.threatpulse.net (NOT example4.com)
  • All traffic to ep.threatpulse.net is sent through the tunnel no matter the configuration, so this traffic will be sent through Cloud SWG via explicit proxy. If there is no tunnel to Cloud SWG, the request is routed via 1.2.3.4:8080 instead.

 Example5.com

  • The browser will resolve this via the PAC file to be "DIRECT" (the default rule)
  • The browser will establish a TCP connection to example4.com
  • The agent will "see" traffic to example5.com
  • Traffic to example5.com is not bypassed, the agent will redirect that traffic through the tunnel to Cloud SWG

Documentation Link: Agents and Proxy Auto-Configuration

Powered by Wolken Software