Integrating SEP and Cloud SWG (formerly known as WSS) using SEP Web and Cloud Access Protection

Products

Endpoint Protection Cloud Secure Web Gateway - Cloud SWG

Issue/Introduction

Best practices for integrating Symantec Endpoint Protection (SEP) and Cloud SWG (formerly known as WSS) using the Web and Cloud Access Protection feature of the SEP client.

Resolution

General

Use the latest version of the SEP client and Web and Cloud Access Protection content

Ensure your clients regularly update to the latest Web and Cloud Access Protection content in order to maintain the best possible performance and functionality.

Symantec has made several enhancements to the WSS integration feature of the SEP client since the its initial release in SEP 14.0.1 MP1. One example of these enhancements is Seamless Integration, which was added to the SEP 14.2 client for Windows clients. In order to take advantage of the latest functionality enhancements, and to remove known product issues or vulnerabilities which may impact Web and Cloud Access Protection, ensure your clients use the latest version of the SEP client.

Roaming Clients

Roaming clients roam between networks. To minimize disruptions to Web connectivity when roaming between networks, ensure the following:

Ensure you are using the latest Web and Cloud Access Protection content and engine.
Each Location should include an enabled Web and Cloud Access Protection Integrations policy.
- In this scenario the SEP client has less to change on the local system as opposed to removing the policy completely for a location switch.
For an On-Net and Off-Net Location scenario, you may also find improvements by pointing to a local/internal proxy, if available, for faster response.

Cloud SWG Bypass Lists

Ensure that there are no entries for Symantec.com domains (e.g. *.wss.symantec.com) in the Cloud SWG bypass list. If wss.symantec.com is bypassed, the SEP Local Proxy Service will be unable to complete the seamless authentication handshake when using a SEP Integration Token.

Local traffic bypass

For situations that require bypassing network traffic from the Windows Local Proxy Service, Symantec provides an exe utility called LPSFlags.exe. This tool allows swapping out the default proxy.pac hosted by LPS with a custom PAC file to bypass the necessary traffic (e.g. SSL VPNs).

For more information on LPSFlags.exe, refer to Bypass Endpoint Protection Web Traffic Redirection using LPSFlags.exe.

SEP for Mac and custom proxy settings for LiveUpdate

SEP for Mac clients cannot make use of custom proxy settings for LiveUpdate while Web and Cloud Access Protection is enabled, instead sending the traffic direct. This is by design and requires custom proxy settings be disabled when Web and Cloud Access Protection is in use. For more information, see Mac clients do not honor custom proxy settings for LiveUpdate with Web and Cloud Access Protection.

Connectivity

Allow WTR through firewall/proxy

If your clients connect to the Internet through a corporate proxy or firewall, ensure you allow unrestricted access to the DNS addresses the SEP client will need for access/authentication.

URL	Port(s)	Purpose
proxy.threatpulse.net	8080	Default Cloud SWG proxy URL
sep-wtr.threatpulse.net	8080	Web and Cloud Access Protection-specific Cloud SWG proxy URL

Ensure Client-id url is sent to WSS

The seamless identification involves the process of identifying the endpoint organisation and negotiating a session key to encrypt an authorisation token for each requests sent to WSS. This process is done seamlessly between the agent and secure gateway handling the web-traffic over the WSS ingress data-path. As such, you need to ensure that the client-id url is not bypassing Cloud SWG.

URL	Port(s)	Purpose
client-id.wss.symantec.com/sso	443	Seamless Identification

WSS proxy URL

Clients using the SEP Web and Cloud Access Protection feature should be configured to use a PAC file that directs them to sep-wtr.threatpulse.net instead of the default proxy.threatpulse.net. This DNS name has been optimized for roaming clients and helps prevent rapid switching between datacenters. This rapid switching between datacenters can cause the following problems with Cloud SWG:

Error: The Specified Client-ID Agent session does not exist
Error: Too many redirects

Configuring Web and Cloud Access Protection for use with on-premise proxies

The SEP Web and Cloud Access Protection engine does not support Kerberos authentication
The current release version of the Microsoft Edge browser does not support NTLM authentication to localhost, and will not authenticate over NTLM through Web and Cloud Access Protection
- The current beta version of Microsoft Edge using the Chromium engine allows NTLM authentication through Web and Cloud Access Protection.

Load balancing egress IPs

The egress IP must be static when using WTR. In situations where multiple egress IPs are available and load balanced end-users utilizing Web and Cloud Access Protection will observe frequent and intermittent 407 Proxy Authentication Required responses resulting in a disruptive web browsing experience.

Compatibility

Discontinue other proxy setting configurations

The Web and Cloud Access Protection engine automatically sets the system proxy settings to point to the local loopback proxy service (http://localhost:2968/proxy.pac by default). Active Directory (AD) Group Policy Object (GPO) configurations for proxy settings will override WTR proxy settings temporarily when computers process GPO configurations. Disable or remove any Group Policy Object (GPO) configurations that set proxy settings to prevent conflicts between GPO and Web and Cloud Access Protection proxy configurations. Additionally, prevent any 3rd party applications from configuring system proxy settings. Examples of 3rd party applications that set proxy settings are Virtual Private Network (VPN) clients, Web traffic debugging utilities, such as Fiddler, and Web traffic anonymizer software. See Endpoint Protection Web and Cloud Access Protection fails to configure proxy settings for more information.

Configure VPN clients for WTR

The Web and Cloud Access Protection engine uses the Local Proxy Service (LPS) to listen on the client's loopback adapter for HTTP/HTTPS requests and forward those requests to the WSS infrastructure. The Web and Cloud Access Protection engine configures the system proxy settings to point to a pac file hosted by LPS (http://localhost:2968/proxy.pac). Any applications that use the system proxy settings will be directed to connect to LPS for all HTTP/HTTPS traffic. The LPS will send its requests to Cloud SWG based on the routing table of the client computer. If the routing table is altered to send traffic through a VPN adapter, the LPS will do so. Use the following best practices to optimize the performance of VPN clients and SEP WTR

Configure SSL VPN clients to bypass the system proxy settings and send VPN traffic directly to the VPN concentrator(s).
Configure all VPN clients for split tunneling. Send internal (Intranet) HTTP/HTTPS traffic directly through the VPN tunnel, and send external (Internet) traffic through the LPS, not through the VPN.

Configure Internet Explorer

Internet Explorer (IE) 11 is the only version of IE currently supported by Microsoft, and the only version tested and certified for use with WTR. To prevent inconsistent behavior when browsing through IE, ensure all clients are updated to the latest stable version of IE. See Inconsistent browsing experience with Internet Explorer 8 and Web and Cloud Access Protection
Ensure the Enhanced Protected Mode for Internet Explorer is disabled. This feature prevents Internet Explorer from making Web requests to the local computer. See Error: The proxy server isn't responding with Web and Cloud Access Protection for more information.

Configure Citrix Clients for WTR

Citrix Receiver and Citrix Workspace clients must be configured to bypass Web and Cloud Access Protection to ensure reliable connectivity/functionality of the Citrix client. See Citrix clients fail to connect with Web and Cloud Access Protection for more details.

Process injection by third party agents

Ensure any 3rd party agents that normally inject a monitoring module (.dll) into running processes are configured to exclude the SEP client's main processes (ccSvcHst.exe) from injection. The SEP client contains security features that will cause the application to crash rather than allow 3rd party code to be injected into the running process.

Some common examples of 3rd party applications that perform process injection are Citrix agents, and AppSense.

Performance

DNS Server performance

Web browsing performance can be significantly impacted by slow DNS responses. For best results, Consider using a DNS provider with a Service Level Agreement, or proven track record of providing DNS responses within a range of no longer than 50 milliseconds.

Clients leveraging Cisco's Umbrella DNS service must be configured to bypass the WSS for the Umbrella DNS service IP addresses. Sending Umbrella traffic through the WSS will result in DNS response times well above 1 to 2 seconds and will result in Web page load times orders of magnitude slower than on a client using a DNS server with a sub-50 millisecond response time. See Slow web browsing through Endpoint Protection Web and Cloud Access Protection with Cisco Umbrella DNS service for more information on bypassing Cisco's Umbrella DNS server addresses.