Since version 5.0.1, SWG includes its own proxy. Still some deployments are configured to use an external proxy instead. In these cases SWG runs in Inline mode and is able to coexist with an external proxy that handles the connection requests for the most common web protocols (HTTP, HTTPS, FTP, etc). Where an external proxy is used, some differences exist when compared to using SWG's own proxy. This article covers these differences and provides technical related information about deploying SWG to interact with an external proxy.
The location SWG has on the traffic flow compared to the external proxy will affect the visibility SWG has of the connections generated by the proxy. When an external proxy is used to connect to the internet, it should be placed upstream of the SWG. This will effectively allow SWG to see the source IP of the connections coming from the internal hosts and apply policies based on these IP addresses. Reports will also display the source of outbound traffic appropriately.
If the external proxy is placed downstream of SWG, it will hide the source IP address of the connections as all the traffic will be seen as coming from the proxy. It will also make impossible for SWG to apply policies based on source IP addresses or subnets and will cause reports to display all outbound connections coming from a single IP address, the proxy IP address.
When using an external proxy with SWG, the product must be properly configured to be aware of the presence of the proxy and to analyze that traffic. The proxy must not block any of the SWG required ports and URLs.
By using an external proxy, SWG is effectively running in Inline mode and is proxy-aware. Some limitations are imposed to the capabilities of SWG if compared to the use of its own proxy:
HTTPS traffic blocking: SWG will be able to see and block URLs based on policies but won't be able to redirect the HTTPS session to properly display the blocking page (see Can SWG Block an HTTPS address? ). The blocking page is displayed when using SWG's own proxy.
Whitelist vs Blacklist scenario: in the event SWG is configured with a whitelist entry (IP address) that must take precedence over a blacklisted entry this will not work. SWG will be able to see the request going out and match against the blacklist entry but won't see the IP address of a target that has been whitelisted. The connection will be seen as coming from the proxy in all instances. This will result in the blacklist applying and blocking page will be displayed. This works as expected when using SWG's own proxy.
For more information regarding SWG deployment check the documentation that comes with the product and the Symantec Web Gateway (SWG) - Best Practices: New Deployments article.