Users access Web resources via Cloud SWG using WSS Agent.
Web isolation is used to sandbox risky websites when going through Cloud SWG - using a dedicated Cloud Web Isolation tenant.
Users access emails via Symantec Email Cloud service.
When a user clicks on a link embedded within an email, the web site is typically rendered on the users browser without any issues.
If the email link references some suspicious or risky sites, the site should be isolated via the dedicated Web isolation platform.
When this happens, a "Forbidden" string appears on a blank page instead of the page being accessed - no other information is available.
Email Cloud Security Service.
Dedicated Web isolation tenant.
Double isolation occurs due to multiple isolation platforms.
A number of options exist:
1. Disable Web isolation via Cloud SWG policies for the clicktime.symantec.com endpoint. A sample CPL includes
2. Create a policy on the dedicated isolation tenant to 'pass' and not 'isolate' traffic for clicktime.symantec.com. Although Cloud SWG will send request into isolation service, isolation will not take place and the double isolation problem is not visible.
HAR files are key to troubleshooting interoperability issues like this.
HAR files show that the request to clicktime.symantec.com (triggered by clicking link within email) trigger a Web isolation event to happen (200 OK response includes links to dedicated Web isolation tenant endpoint) as expected.
However, during this isolated session, the user-agent generates a request to eu-west-email-isolation.prod.fire.glass, one of the shared email Cloud isolation server endpoints. This 'double' isolation causes the email cloud isolation server to return the 403 forbidden.
Interoperability between Email Cloud, Cloud SWG and dedicated Web isolation tenants requires that the clicktime.symantec.com requests not be isolated by Web isolation and the bypass policy change addresses this.