An isolation session can be initiated from Internet & SaaS policies or Private Applications policies. However, an isolation browser initiated from Private Applications policies can send traffic only via Private Applications.

This means that any applications defined in Private Applications are forwarded via the Private Applications client on the isolation container, and any traffic which is not defined as an application configured for Private Applications is sent directly to the internet. This creates a gap in the security policies defined by the organization. To avoid this, Isolation supports sending any non-private application traffic via Internet & SaaS even though the isolation session is initiated via a Private Applications policy. To learn more about Private Applications policies within Isolation, see About Isolation Policy and Configuring Isolation Policies.

A user might want the ZPA isolation to isolate SaaS applications. The user accesses a dummy URL which is configured as a browser access application. However, the URL is rewritten to its full extent when pushed into isolation. To learn more, see Secure SaaS Access from Unmanaged Devices via User Portal.

Users who isolate private web applications might also want to also enforce DLP policies or security policies on the traffic. This is typical to ensure that any file of a malicious nature is not uploaded onto the isolated web application, nor is there any sensitive information matching a downloaded DLP policy. To ensure this, Isolation can forward the private application traffic via Internet & SaaS to ensure all these policies are applied, and that Internet & SaaS provides connectivity to the private applications via the Source IP Anchoring route. To learn more, see Understanding Source IP Anchoring.

This feature can be enabled per Private Applications isolation profile. To learn more, see Creating Isolation Profiles for Private Applications and Editing Your Isolation Profile for Private Applications.