- SWG is agnostic to the network equipment manufacturer – as long as networking standards are met SWG supports all equipment. The SWG Implementation Guide is the best place to look for examples of supported network configurations.
- SWG should not be on the WAN side of a NAT Server, Proxy, Firewall, or other networking equipment which masks client IP addresses, and should not be placed in front of web servers as we do not support reverse proxy
- RADIUS support for GUI authentication:
- SWG supports RADIUS with RFC 2548
- SWG supports only user authentication attributes in RFC 2865
- SWG is not compatible with connection throttling features of various firewalls or network devices.
- Example: ISA limits the number of concurrent connections below that of SWG’s 100,000 connections. Issues are created when SWG continues to send connections to the ISA server.
- Support for particular switches or firewalls
- SWG supports all physical switches. For virtual switches, SWG only supports the VMWare virtual switch built into ESX Servers used by the 84v.
MLT (802.3ad Multilink Trunking)
SMLT (Split Multilink Trunking)
- SWG is compatible with networks utilizing MLT or SMLT upstream or downstream from the SWG connection.
- SWG cannot be directly connected to an MLT or SMLT link.
- SWG does not send blocking page (does not block) end user PCs which sit on subnets behind VLANs other than SWG VLAN
- VLAN configuration is only required when SWG is connected to the VLAN trunk. In this scenario:
- The network must support vlan tagging
- All vlan traffic that is expected to be forwarded must be configured in the SWG Internal network configuration section
- VLAN is only supported in single home Inline mode on a physical appliance
- VLAN is not supported for Proxy operating mode, Tap/Span operating mode, Dual Homing configuration or the 84v (virtual appliance)
- TCP sequence randomization not supported in VLAN trunk configuration
|Network Load Balancing
- The load balancer must manage traffic so that a client transaction to a web server must travel back and forth through the same SWG to complete the transaction. In other words, a request from a client to a web server sent through SWG1 should not be returned through SWG2 back to the client. We have very limited testing of load balance configurations.
- SWG supports external proxy servers on the network.
- SWG does not support external proxy authentication if required for SWG to reach the internet
- In order for SWG LDAP integration to work properly, the external proxy server must be on the other side of the SWG from the clients.
- If both external proxy server and clients are on the LAN side of the SWG, all traffic will appear to come from the external proxy server IP. In this case the traffic will be inspected, but LDAP integration and SWG inspection policies will not work properly.
SWG in proxy mode supports basic 401 authentication initiated by external websites. Websites that require NTLM 401 authentication or a higher level of 401 authentication are not supported.
Traffic through SWG Inline is not affected by this issue.
NTLM web authentication is not supported by SWG proxy.
- Some Web Servers implement NTLM authentication for users accessing the site. In Inline and Tap mode, this has no impact. However, SWG Proxy cannot access the site when the website uses anything higher than basic web authentication.
- Basic authentication is supported.
- Web authentication is mostly used by companies for internal sites where SWG proxy is not involved. If an end user needs to access a web site that requires web authentication, they should have an exception added in their browser or PAC file.
- If NTLM web authentication is enabled and a user attempts to access that site via SWG proxy, the end user will receive an authentication error message in their browser and the page will not load.
- 1 user 1 IP
- 1 user to many different hosts will also work
- In order for authentication to work properly, SWG must be able to associate a user to a unique IP address or addresses.
- This means that client IP addresses must not be masked by a NAT server or an external Proxy server before they are inspected by the SWG.
- IP addresses must not be shared by many users logged into a shared centralized server
- For Inline operating mode, only NTLMv1 is supported
- Windows 7 and Windows 2008 Server require non-default security settings in order to authenticate using NTLMv1
- NTLM is the preferred method for LDAP integration
- Relies on Windows Server Security Audit logs
- These logs must be enabled on the AD server in order for DCInterface to work.
- DCInterface also requires 1 user 1 IP (or 1 user to multiple unique IPs) in order to properly apply LDAP based policies.
- DCInterface does not work with Windows 2008 R2 Terminal Services even when virtual IPs are employed
- This is because the Windows Security Audit logs do not honor the VIPs for the TS session
- One DCInterface per domain controller
- For Windows Server 2008 Domain Controllers, only Kerberos security event ID 4768 is supported
|VDI agnostic for virtual client machines
As long as all the other supported parameters are met, virtual client machines are supported regardless of the hardware or software infrastructure providing the virtualization. In this context we refer to one user logged into one virtual client machine running a supported OS and a supported browser as if they were logged into their own physical client machine.
- SWG QA has done extensive testing on virtual clients and AD Servers running on VMWare and Dell hardware.
Windows 2008 R2 provides native support for virtual IPs for users logging into a terminal services session via RDP
- For TS to work properly, each user needs to have their own IP address
- NTLM authentication is supported if virtual IP is configured for use with RDP / TS sessions AND if other supported parameters are met (e.g. TS users access a supported browser on the server to access the internet, SWG is “between” the server and the internet firewall for inline mode; or the browser proxy settings are configured to be inspected by the SWG, etc.).
- Other terminal server solutions (such as Citrix) that leverage this TS framework and meet all the other supported parameters are expected to work
- DCInterface does not work properly with Windows 2008 R2 TS configuration and is not likely to work with other TS solutions.
- This is because the Windows Security Audit logs do not honor the VIPs for the TS session
- Block by file extension or with keyword is not supported over SSL
- Blacklist not supported for embedded urls
- Blacklist by IP is not supported over HTTPS
- IP blacklists are not mapped to a domain.
- So, when an IP blacklist is created, and a user goes to a domain which maps to that IP, the domain is not blocked.
- We are limited to Level 0 I18N support.
- For blacklist configuration, we do not support non-ascii characters (such as double-byte characters) in the blacklist keyword field.
- SSL Deep Inspection supports streaming mode for file inspection.
- SWG 5.0.1:
- SSL Proxy doesn't support user configured black list
- SWG 5.0.2
- User configured black list domain only, it applies to SSL Proxy tunnel / deep inspection traffic
- User configured black list has keyword or file extention, it doesn't apply to SSL Proxy tunnel / deep inspection
See below "SWG Inspection" tables for additional specifics regarding blacklist limitations
- Whitelist IP address is not supported in proxy mode
- Ignore (whitelist) authentication is not supported in proxy mode.
- Solution is to use a PAC file for this.
- Whitelists are not applied to embedded urls
- Whitelist is not supported over FTP Proxy
See below "SWG Inspection" tables for additional specifics regarding whitelist limitations
- A number of applications configurable in our UI are no longer supported. (Release notes are created as these are discovered.)
- Enabling APC can have a performance impact
|Model 84v (virtual SWG appliance)
- Bypass is not supported on an 84v.
- Not supported to run virtual appliance Inline or Inline+Proxy configuration, please see http://www.symantec.com/docs/TECH183599.
- SWG does not support DLP for Tablets
- SWG supports DLP Network Prevent for Web
- Versions supported - 11.0, 11.6
- SWG functions as an ICAP client for Symantec Network Prevent for Web.
- SWG is not an ICAP server and not an ICAP client for any other products or functionality.
SWG goes into bypass when the following conditions occur:
- Service is disabled
- Device is rebooted
- File system is corrupted/bad
- The filtering process or the change execution process has been recovered five times because of repetitive crashes
- (8490) Hardware watchdog reboots system if it is unresponsive due to resource exhaustion.
|Recommended base configurations
- See "SWG Inspection" tables below.
- External-facing Web Servers
- SWG is not designed to protect against threats targeted specifically against external facing web servers
- SWG cannot be used as a reverse proxy.
|Detection limitations per operating mode
||See "SWG Inspection" table below
Default configurations /
Default Policy configuration
- If there are no policies configured in the Policies -> Configuration page, the Global Default policy is used (e.g. Monitor Operating Mode, Block Operating Mode).
- The Default policy will detect malware file downloads (Anti-Virus), "built-in" Blacklist URLs, Phone Home detections and Botnets
- The Default policy will either block or monitor these detections depending on whether Block or Monitor is selected as the Operating Mode
- When a policy is configured in Policies -> Configuration:
- The configured policy will override the Global Default policy for all Work Groups (IP addresses, Subnets and LDAP groups) defined in the policy
- URL Filter policy uses the same default settings regardless of the Global Default setting (Monitor operating mode, Block Operating Mode). Even when SWG is configured in Monitor Operating Mode, the default URL Filter policy will block some categories
- The Global Default policy will be applied to any clients outside the Work Groups defined in the policy
- Policies are evaluated in the order that they are listed in the UI from top to bottom. Policies where the action for the category is "Ignore" will cause SWG to proceed to the next relevant policy and apply the action for the category in that policy. If all policies that match the packet contain "Ignore" as the action for the category, then SWG applies the action within the Global Default policy.
- Non-Default Detections
- Symantec Insight detections will be dormant until this feature "Enable Insight Policies" is enabled on the Insight configuration tab
- Browse time monitor will not be enabled until this feature is enabled in the Modules tab
- SWG Browse time monitor will track an end user as "active" when a page consistently auto loads content - even if the user is not actively clicking on links or buttons
- Unless you are on a page a certain amount of time to meet the minimum threshold, we do not count the time or track the user's activity
- SWG Browse time monitor tracks the total amount of time an end user is on the internet, not the amount of time an end user is on a specific site
- URL Filtering will be dormant until the following are met:
- URL Filtering license is installed
- Content filter is enabled in the Modules Tab
- Policy is enabled containing URL Filtering detections
- Application Control detections will be dormant until the following conditions are met:
- Application Control module is enabled in the Modules tab
- A policy which contains AC detections is enabled