Configuring the Web Isolation feature on the Edge SWG (ProxySG) appliance

search cancel

Configuring the Web Isolation feature on the Edge SWG (ProxySG) appliance

book

Article ID: 201609

calendar_today

Updated On:

Products

ProxySG Software - SGOS

Issue/Introduction

The Symantec Web Isolation solution is a client-less solution that enables and protects users to browse the Internet safely on any device using any browser. The zero footprint negates the need for software installation on clients. Starting in SGOS 7.3.x, you can easily configure the Edge Secure Web Gateway (SWG) appliance to forward HTTP and HTTPS requests to a Web Isolation service. You can then write policy to make decisions concerning the isolated traffic.

The default Symantec cloud Web Isolation service is linked to the High Risk Isolation (HRI) service. The HRI service is automatically configured and uses secure tunnel mode to forward traffic to Web Isolation. The HRI service requires minimal additional configuration on the appliance through the Visual Policy Manager (VPM) or content policy language (CPL) policy.

You can also configure the Web Isolation service to use a custom Web Isolation service that uses secure tunnel mode instead of the HRI service. To use the custom service, link the Edge SWG serial number to the Web Isolation service. For more information, view the full list of requirements.

You can also configure the Web Isolation service to use a dedicated cloud or on-premises Web Isolation service. This option doesn’t support secure tunnel mode and does require advanced configuration through the CLI and Web VPM or CPL. For more information, see Configure a Custom Web Isolation Service.

Warning: Isolation policy using the Isolate action is only available in the Web VPM. Its use is not supported with the Legacy Java VPM. If you add Isolate actions to policy through the Web VPM, the actions are removed if you open the Legacy Java VPM.

Resolution

Requirements to use Web Isolation

SGOS 7.3.x and later
(Optional) A current Management Center release 1.1.3.1 and later
(Only required when authentication headers need to be forwarded to Web Isolation) Authentication configured for URLs that the isolation service isolates and for isolation virtual domain resources
SSL interception policy to isolate HTTPS requests
(Custom isolation service only) Determine the following:
- FQDN or IPv4/IPv6 address of the isolation service host
- Port to use for proxying HTTP/S requests
- Whether or not to secure connections to the isolation server, including sensitive header information

Configuration Differences

Before proceeding, review the following comparison of the default cloud isolation service configuration versus the custom isolation service configuration.

Settings and options	Configuration
Configuration settings (service, device profile, server CCL)	Default service: These settings are pre-configured and do not require modification. Custom service: Configure the settings appropriately and as required for the on-premises service, using the CLI or the Edge SWG Admin Console.
Sending headers to the isolation service	Default service and custom service: Specify the headers to send to the isolation service using the CLI or the Edge SWG Admin Console.
Types of traffic to intercept	Default service: The cloud isolation service supports isolation of requests that are uncategorized and threat risk level 5 or higher. Custom service: There are no categorization or threat risk level restrictions for a custom isolation service.
Enabling isolation policy	Default service and custom service: Configure web isolation policy using Web VPM or CPL to determine what traffic to isolate and SSL-intercept the traffic to isolate.

Note: You cannot enable the cloud isolation service and a custom service at the same time.

Considerations and Limitations

Configure policy for HTTPS interception appropriately to ensure that the HTTPS requests you want to isolate are forwarded to the isolation service as intended.
If the default policy is DENY, you must allow the HTTPS requests you want to isolate by specifying the ALLOW rule and isolation rules in separate layers. In CPL, the isolation rules can be in the same layer as ALLOW if they are on the same line.
When policy includes rules for isolation and forwarding/SOCKS gateway forwarding, and a given request matches both isolation policy and forwarding policy, the Edge SWG appliance sends the request to the Web Isolation service.
When policy includes rules for isolation and URL rewrite, and a given request matches both isolation policy and URL rewrite policy, the request might not be isolated. As a workaround, compose policy so that requests you want to isolate are not subject to URL rewrite rules.
Web Isolation is not supported for HTTPS reverse proxy transactions.
Web Isolation is a cloud-based service and does not have access to internal resources. Internal domains that are uncategorized and internal IP ranges must be bypassed from Web Isolation.

Upgrade/Downgrade Considerations

If you upgrade from version 6.7.x to 7.x, and if the default keyring includes an invalid or expired CA certificate, some features might not function. For example, the appliance cannot download a database, and the event log contains messages such as "Policy compile had errors" and "Error: Keyring does not have a certificate authority's certificate: 'default'". To work around this issue, set the Web Isolation service to use a keying that includes a valid, non-expired CA certificate. See Step 2.
In version 7.3.6 and later, the default port is 443 instead of 8080. If you currently use the default web isolation service hostname and port, upgrading will change the port from 8080 to 443. If you then downgrade to version 7.3.5 or earlier, the configuration retains the port 443 setting. If you configured a custom web isolation service, issuing the #(config isolation) service cloud command in version 7.3.6 reverts the service to default settings, including the new default port. Issuing the command in versions up to 7.3.5, however, will reset the port to 8080. In this case, issue the #(config) isolation service isolation-jump.prod.fire.glass secure 443 command to use the default service.
If you are running version 7.1.x or 7.2.x and have an existing forwarding policy for an on-premises or cloud isolation service, you can continue to use your custom service after an upgrade to version 7.3.x. After an upgrade, specify the isolation server's hostname (and port, if applicable) using the following CLI command:
If you have configured web isolation with forwarding hosts, you can disable the Web Isolation service to allow forwarding-based isolation to work as intended. The command to disable the service is available in version 7.3.4:

#(config) isolation
#(config isolation) disable

If you are upgrading from 7.1.x or 7.2.x, have an existing forwarding policy for an on-premises isolation service, and want to use Symantec’s cloud isolation service, you must first remove the existing policy. Then, follow the steps in Configure the Cloud Web Isolation Service.

Configure the Cloud Web Isolation Service

The cloud isolation service comes with presets and requires minimal configuration.

Step 1: Send HTTP headers to the isolation service

You can send the originating client IP address, authenticated user, or authenticated group details in the HTTP headers of traffic forwarded to the isolation service. For the Edge SWG appliance to send these authenticated user and group details, you must enable authentication for:

Any requests that the appliance forwards to the isolation service using the isolate() policy gesture
The isolation virtual domain resources. These virtual domain resources are part of the Web Isolation service:
- (SGOS 7.3.14.x and later) The isolation virtual domain resources are predefined in the Web Isolation policy using the SYMC_PS_IsolationResourcesAuth condition. To use this condition, ensure the Edge SWG appliance has the policy services version 63436 or later. To view the version, use the show policy-services CLI command. The following is an example of what the configuration might look like:
```
#show policy-services

License Type:           Subscription

Licensed Until:         Fri, 31 Dec 2027 00:00:00 UTC

Service:                Enabled

Download method:        Direct

Last successful download:

  Time:                 Thu, 09 Nov 2023 17:16:03 UTC

  Downloaded from:      https://subscription.es.bluecoat.com/defaultpolicy/database

  Version:              63436
```
- (SGOS 7.3.13.x and earlier) You must define the following isolation virtual domain resources in the Edge SWG policy:
  - global-shared.fire.glass
  - docisolation.prod.fire.glass
  - docisolation-eu.prod.fire.glass
  - doc-isolation-prod.prod.fire.glass
  - doc-isolation-prod-eu.prod.fire.glass
  - shared.fire.glass

To configure the Edge SWG appliance to forward the headers, use either the Edge SWG CLI or the Edge SWG Admin Console. To use the Admin Console, you must either have:

A current Management Center release
SGOS 7.4.x
SGOS 7.3.12.1 and later

You can send one or more of the available headers to the isolation service. For best security, enable Web Isolation in secure mode when sending headers. In version 7.3.11.1 and later, the Admin Console and the CLI warn you if the service is configured to send headers in non-secure mode.

Configure the Edge SWG Appliance to Send HTTP Headers

Use the CLI to Forward Headers

In the CLI, issue the following command:


#(config isolation) send {authenticated-user | authenticated-groups | client-address}

Use the Admin Console to Forward Headers

In the Edge SWG Admin Console:

Click Administration > Data & Cloud Services > Isolation.
In the Isolation section, for Include Headers, select one or more of the options:

User: Authenticated user (X-Authenticated-User).
Group: Group of the authenticated user (X-Authenticated-Groups).
Client Address: Originating client IP address (X-Forwarded-For).

Select Save to apply the changes.

Enable Authentication for the URLs and the Isolation Virtual Domain Resources

To enable authentication in the Edge SWG policy for the Web Isolation virtual domain resources:

Define conditions for:
- Any requests that the appliance forwards to the isolation service using the isolate() policy gesture
- The isolation virtual domain resources. These virtual domain resources are part of the Web Isolation service:
  - (SGOS 7.3.14.x and later) The isolation virtual domain resources are predefined in the Web Isolation policy using the SYMC_PS_IsolationResourcesAuth condition.
  - (SGOS 7.3.13.x and earlier) You must define the following isolation virtual domain resources in the Edge SWG policy. When creating the condition, do not use SYMC_PS_IsolationResourcesAuth as the condition name. If you use this name and upgrade to 7.3.14.x and later, your policy won’t compile and you will receive a duplication error message:
    - global-shared.fire.glass
    - docisolation.prod.fire.glass
    - docisolation-eu.prod.fire.glass
    - doc-isolation-prod.prod.fire.glass
    - doc-isolation-prod-eu.prod.fire.glass
    - shared.fire.glass
Add a rule to authenticate requests based on the conditions you defined in step 1.

Example CPL for SGOS 7.3.14.x and Later

In the following example CPL, isolated_urls defines the requests that the appliance forwards to the isolation service; and domains_to_auth combines the isolated_urls conditions and the predefined isolation virtual domain resources. The domains_to_auth rule specifies that the URLs and domains authenticate to localrealm.

define url.domain condition isolated_urls
  example.com
  ..
end


define condition domains_to_auth
  condition=isolated_urls
  condition=SYMC_PS_IsolationResourcesAuth
End

<ssl-intercept>
   condition=isolated_urls ssl.forward_proxy(https)

<proxy>
  condition=isolated_urls isolate(yes)

<proxy>
  condition=domains_to_auth authenticate(localrealm)

Example CPL for SGOS 7.3.13.x and Earlier

In the following example CPL, IsolationResourcesAuth defines the virtual domain resources; isolated_urls defines the requests that the appliance forwards to the isolation service; and domains_to_auth combines the two previous conditions. The domains_to_auth rule specifies that the URLs and domains authenticate to localrealm.

define url.domain condition IsolationResourcesAuth
  global-shared.fire.glass
  docisolation.prod.fire.glass
  docisolation-eu.prod.fire.glass
  doc-isolation-prod.prod.fire.glass
  doc-isolation-prod-eu.prod.fire.glass
  shared.fire.glass
end IsolationResourcesAuth

define url.domain condition Isolated_urls
  example.com
  ..
end

define condition domains_to_auth
  condition=isolated_urls
  condition=IsolationResourcesAuth
end

<ssl-intercept>
   condition=isolated_urls ssl.forward_proxy(https)

<proxy>
  condition=isolated_urls isolate(yes)

<proxy>
  condition=domains_to_auth authenticate(localrealm)

Step 2: Create Web Isolation policy

To enable or disable Web Isolation in policy rules, use the Web VPM or CPL. These instructions are for the Web VPM.

To create Web Isolation policy:

Log in to the Edge SWG Admin Console.
Click Visual Policy Manager. The Web VPM opens.
Click Add Layer. The Add a Layer dialog displays layer types.
Note: If the default policy is DENY, add an ALLOW rule to a separate layer.
Select one of the layers that supports the Web Isolation action object: Web Access or Web Request. Then, click OK.
Click Add rule. The new rule is added to the layer.
In the policy rule, under Action, select Set and click Add a new object. In the list of objects, select Web Isolation.
Specify the isolation behavior for traffic matching this policy rule:
- Select Do not isolate to disable web isolation. This option is selected by default.
- Select Isolate to enable web isolation.
- For If the isolation service is unavailable, select one of the following options:
  - Fail closed, deny the request (recommended): Deny the request.
  - Fail open, continue without web isolation: Process the request and send it directly to the origin content server.
  Only the If the isolation service is unavailable setting is functional in the initial release for the cloud isolation service.
Click Apply > Set to save the object.
Make other policy changes as needed then click Apply Policy to install policy.

Note: Make sure to exclude all internal traffic from web isolation. Add a rule that includes internal IP ranges and domains and set it to Do not isolate. See the following Example for more information.

Example: Write isolation policy in the Web VPM

This example describes how to create the following VPM policy:

Specify internal IP addresses and domains.
Disable Symantec Web Isolation for requests matching these internal sites.
Specify requests from authenticated users for certain categories of URLs.
Enable Symantec Web Isolation for requests matching these users and categories, and block requests if the isolation service is unavailable.
Set a policy ID to determine the frequency of policy rule hits in access logs.

Note: If preferred, you can refer to the CPL for this example.

Log into the VPM:

Log in to the Edge SWG Admin Console.
Click Visual Policy Manager. The Web VPM opens.

Create policy objects for internal traffic:

To create VPM objects for internal domains and servers, select Operations > View All Objects.
In the All Objects list, select Add a new object and add the following objects from the list (use the search function if needed):
- Destination IP Address & Subnet: Specify an internal IP Address. Create one object for each IP address/subnet to exclude from isolation.
- Request URL: Specify an internal URL (can be a URL or an IP address). Create one object for each URL/address to exclude from isolation.
In the All Objects list, select Add a new object > Combined Destination Object and combine objects created in the previous step. In this example, you want to create distinct combined objects for internal servers and two sets of internal domains:
- Add all Destination IP Address & Subnet objects to a combined object you name internal_servers.
- Add all Request URL objects specifying domains to a combined object you name internal_destinations1.
- Add all Request URL objects specifying IP addresses to a combined object you name internal_destinations2.
- Add internal_destinations1 and internal_destinations2 to a combined object you name do_not_isolate_internal_destinations.
Add a Web Access layer. Select Add Layer > Web Access > Add.
In the Add New Web Access layer dialog, enter a layer name and click OK.
In the layer rule, under Destination, select Set and click Add a new object. In the list of objects, select the internal_servers combined object.
Under Action, select Set and click Add a new object. In the list of objects, select Web Isolation. Set the object to Do not isolate.
Click Apply > Set to save the object.
Add another rule to the layer. under Destination, select Set and click Add a new object. In the list of objects, select the do_not_isolate_internal_destinations combined object.
Under Action, select Set and click Add a new object. In the list of objects, select Web Isolation. Set the object to Do not isolate.
Click Apply > Set to save the object.

The Web Access Layer has the following rules configured:

Create policy objects for certain requests coming from authenticated users:

Select Add Layer > Web Access > Add to add another Web Access Layer.
In the layer rule, under Source, select Set and click Add a new object. In the list of objects, select Authenticated User and click Apply > Set.
Under Destination, select Set and click Add a new object. In the list of objects, select Request URL Category. Name the object categories_to_isolate, select categories, and click Apply > Set.
Under Action, select Set and click Add a new object. In the list of objects, select Web Isolation.
Specify the isolation behavior for traffic matching this policy rule.
Click Apply > Set to save the object.
Under Track, select Set and click Add a new object. In the list of objects, select Policy ID. Enter a policy ID and click Apply > Set.

The Web Access Layer has the following rule configured:

Click Apply Policy to install policy.

If Web Isolation does not occur as expected, review Troubleshooting.

Configure a Custom Web Isolation Service

Configuring a custom isolation service requires more advanced configuration through the Edge SWG CLI (or Edge SWG Admin Console) and VPM/CPL. These instructions are for the CLI and CPL.

Step 1: Enable the custom Web Isolation service

(Version 7.3.4 and later) If the Web Isolation service was disabled previously, make sure that it is enabled before configuring Web Isolation policy. Otherwise, policy compilation warnings occur, such as "Warning: 'isolate' Isolation service is disabled; it must be enabled in order to use the isolate action using the CLI isolation->enable command"; in addition, the appliance will return exception pages for traffic matching the isolation rules.

#(config) isolation
#(config isolation) enable

(All versions) Configure the service using the Edge SWG CLI:

Log in to the CLI and enter #(config) mode.
Enter isolation mode:
```
#(config) isolation
#(config isolation)
```
Specify the isolation service hostname and port, and whether or not to wrap HTTP/S requests inside an SSL tunnel:
```
#(config isolation) service <hostname> {secure | non-secure} [<port>]
```
where:
- hostname: Hostname or IPv4/IPv6 address for the custom isolation service.
- secure: Send HTTP/S requests wrapped inside an SSL tunnel to the isolation server. To use this option, you must ensure that the isolation service supports SSL tunnel termination, and specify an SSL device profile to secure the SSL tunnel to the isolation service.
  Note: For on-premises services and dedicated services, which do not have the SSL tunnel terminator, specify non-secure. secure mode is the default.
- non-secure: Do not use an SSL tunnel to the isolation server. If you currently use non-secure mode for an-premises service and want to change to a cloud service that supports SSL termination, specify secure mode.
  Note: Specifying non-secure means that HTTP/S requests are not sent inside an SSL tunnel. If you forward headers using the #(config isolation) send command, the headers are not encrypted.
- port: Port for the isolation server. If unspecified up to version 7.3.5, port 8080 is the default for secure and non-secure connections. In version 7.3.6 and later, port 443 is the default for secure and non-secure connections.

Step 2: Configure custom Web Isolation service settings

Note: If you use Management Center, or you are running SGOS 7.4.x, or SGOS 7.3.12.1 and later, you can use the Edge SWG Admin Console to configure these settings.

The Web Isolation settings are set to the cloud isolation service defaults. In the CLI, configure different settings if:

You specified secure in the previous step. You must also specify an existing SSL device profile to use for securing the HTTP/S requests to the isolation service over a secure tunnel. This device profile specifies the client certificate and the CA to use for validating the certificate from the isolation service SSL tunnel terminator:
```
#(config isolation) tunnel-ssl-device-profile <SSL_device_profile>
```
Note: This device profile is not used to validate the isolated traffic. After the SSL tunnel to the isolation service is terminated, the HTTP/S requests are forwarded to the isolation service and the Edge SWG appliance will use the bluecoat-isolation or specified server-ccl to validate the isolation proxy certificate.
See #(config isolation) server-ccl <server_CCL_name> for more information.
You want to use an existing SSL keyring other than the default for SSL interception:
```
#(config isolation) issuer-keyring <keyring>
```
Specify a keyring that contains the correct certificate for SSL interception for your deployment. Otherwise, the appliance uses the default keyring. The specified keyring is used for SSL interception of Shared Isolation Domains.

After specifying a different keying for SSL interception, or if you change back to the default keyring, clear both the Edge SWG cache (using # clear-cache command) and the browser cache.

Note: To isolate HTTPS requests, enable SSL interception and write policy that includes SSL intercept rules for the traffic you want to isolate. SSL intercept policy should use this keyring for the isolated traffic.
If not using cloud, specify a CCL to validate the isolation server certificate used for isolated requests.
For instructions on creating a CCL and adding CA certificates to the list, refer to Manage CA Certificate Lists.
```
#(config isolation) server-ccl <server_CCL_name>
```
Otherwise, the appliance uses the bluecoat-isolation CCL.
Note: See #(config isolation) tunnel-ssl-device-profile <SSL_device_profile> to specify the device profile used to secure connection to the isolation service.
You want to send originating client IP address, authenticated user, or authenticated group details in the HTTP headers of traffic forwarded to the isolation service:
```
#(config isolation) send {authenticated-user | authenticated-groups | client-address}
```
You can send one or more of the available headers. For best security, enable Web Isolation in secure mode when sending headers.
To disable sending headers, use the following command:
```
#(config isolation) no send {authenticated-user | authenticated-groups | client-address}
```
Tip: After you configure a custom service, you can use the #(config isolation) service cloud command to revert to default settings if needed.

Step 3: Verify Web Isolation

To display the current Web Isolation configuration, use #(config isolation) view CLI command. The following is an example of what the configuration might look like:

#(config isolation) view

Issuer keyring: default
Server CCL: bluecoat-isolation
Service: isolation.example.com secure 443
Tunnel SSL device profile: bluecoat-isolation-tunnel
Attributes sent in requests:
Authenticated user: yes
Authenticated groups: yes
Client address: no

Tip: Using the command > show isolation provides the same information.

Examples: Write Web Isolation CPL

See below for an example of web isolation policy in CPL. The web VPM Web Isolation object provides the same Web Isolation policy as the CPL, except for the following gestures which have no VPM equivalent:

You can use the isolated= condition to test if Web Isolation was enabled for a transaction (based on the isolate() property/Web Isolation object) and status of the Web Isolation service. The condition tests yes if the service status is healthy and the request is isolated; it tests no if the service status is not healthy, or is healthy but the request is not isolated.
You can use the set() action to set or substitute isolated request headers. Refer to the Content Policy Language Reference for details on supported headers.
The predefined condition SYMC_IsolationResourcesAuth does not have an equivalent Web VPM object. You can use this condition in a CPL layer of the Web VPM.
(SGOS 7.3.13.x and earlier) The condition you defined in your authentication policy for the isolation virtual domain resources. You can use this condition in a CPL layer of the Web VPM.

See the CPL below for examples of usage.

Note: The properties in bold text will be functional in a future release.

Example CPL for SGOS 7.3.14.x and later

; internal servers and addresses to exclude from isolation

define condition do_not_isolate_internal_destinations
  condition=internal_destinations1
  condition=internal_destinations2
end condition do_not_isolate_internal_destinations

define subnet internal_servers
  <list_of_IP_addresses>
end subnet internal_servers

define condition internal_destinations1
  url.domain="internal1.example.com"
  url.domain="internal2.example.com"
end condition internal_destinations1

define condition internal_destinations2
  url.domain="##.##.##.##"
  url.domain="##.##.##.##"
  ...
end condition internal_destinations2


; request categories to isolate

define condition categories_to_isolate
  url.category=(<list_of_categories>)
end condition categories_to_isolate

; do not isolate traffic to the specified destinations
<Proxy>
  condition=do_not_isolate_internal_destinations isolate(no)
  url.address=internal_servers isolate(no) 

; isolate authenticate user requests to sites with the specified categories
<Proxy>
  define condition domains_to_auth
    condition=isolation_match_criteria
    condition=SYMC_PS_IsolationResourcesAuth
  end

<Proxy>
  condition=domains_to_auth authentication(localrealm)
<Proxy>
  authenticated=yes condition=isolation_match_criteria isolate.fail_open(no) 

; SSL-intercept requests matching the specified condition
; and using the default keyring
<SSL-Intercept>
 condition=ssl_intercept_list ssl.forward_proxy(https) ssl.forward_proxy.issuer_keyring("default")

; when condition is met, isolate traffic using the specified settings
<Proxy>
  condition=isolation_match_criteria isolate(yes) isolate.read_only(yes) \
    isolate.read_only.allow_override(no) isolate.display_banner(yes) isolate.disable_logging(no) \
      isolate.fail_open(no) action.set_isolation_header(yes)

; block uncategorized requests that weren't isolated
<SSL>
condition=non_isolation_uncategorized deny

; define condition for traffic to SSL-intercept
define condition ssl_intercept_list
 <list_of_categories_and_other_criteria>
end condition ssl_intercept_list

; define condition for isolating HTTP and HTTPS traffic
; HTTPS sites must be SSL-intercepted for isolation to work
define condition isolation_match_criteria
 <list_of_urls_and_other_criteria>
end condition isolation_match_criteria

; define action to set the specified isolation header as x-client-address substitution
define action set_isolation_header
  set(isolate.http_connect.header.x-Forwarded-For,"$(x-client-address)")
end action set_isolation_header

; define condition for non-isolated URLs to block
define condition non_isolated_uncategorized
 url.category=none isolated=no
end condition non_isolated_uncategorized

If Web Isolation does not occur as expected, review Troubleshooting.

Example CPL for SGOS 7.3.13.x and earlier

; internal servers and addresses to exclude from isolation

define condition do_not_isolate_internal_destinations
  condition=internal_destinations1
  condition=internal_destinations2
end condition do_not_isolate_internal_destinations

define subnet internal_servers
  <list_of_IP_addresses>
end subnet internal_servers

define condition internal_destinations1
  url.domain="internal1.example.com"
  url.domain="internal2.example.com"
end condition internal_destinations1

define condition internal_destinations2
  url.domain="##.##.##.##"
  url.domain="##.##.##.##"
  ...
end condition internal_destinations2


; request categories to isolate

define condition categories_to_isolate
  url.category=(<list_of_categories>)
end condition categories_to_isolate

; do not isolate traffic to the specified destinations
<Proxy>
  condition=do_not_isolate_internal_destinations isolate(no)
  url.address=internal_servers isolate(no)

;Define the isolation virtual domain resources
define url.domain condition IsolationResourcesAuth
  global-shared.fire.glass
  docisolation.prod.fire.glass
  docisolation-eu.prod.fire.glass 
  doc-isolation-prod.prod.fire.glass
  doc-isolation-prod-eu.prod.fire.glass
  shared.fire.glass
end IsolationResourcesAuth

define condition domains_to_auth
  condition=isolation_match_criteria
  condition=IsolationResourcesAuth
end

<Proxy>
condition=domains_to_auth authenticate(localrealm)

  ; isolate authenticate user requests to sites with the specified categories
<Proxy>
  authenticated=yes condition=isolation_match_criteria isolate(yes) isolate.fail_open(no)

; SSL-intercept requests matching the specified condition
; and using the default keyring
<SSL-Intercept>
 condition=ssl_intercept_list ssl.forward_proxy(https) ssl.forward_proxy.issuer_keyring("default")

; when condition is met, isolate traffic using the specified settings
<Proxy>
  condition=isolation_match_criteria isolate(yes) isolate.read_only(yes) \
    isolate.read_only.allow_override(no) isolate.display_banner(yes) isolate.disable_logging(no) \
      isolate.fail_open(no) action.set_isolation_header(yes)

; block uncategorized requests that weren't isolated
<SSL>
condition=non_isolation_uncategorized deny

; define condition for traffic to SSL-intercept
define condition ssl_intercept_list
 <list_of_categories_and_other_criteria>
end condition ssl_intercept_list

; define condition for isolating HTTP and HTTPS traffic
; HTTPS sites must be SSL-intercepted for isolation to work
define condition isolation_match_criteria
 <list_of_urls_and_other_criteria>
end condition isolation_match_criteria

; define action to set the specified isolation header as x-client-address substitution
define action set_isolation_header
  set(isolate.http_connect.header.x-Forwarded-For,"$(x-client-address)")
end action set_isolation_header

; define condition for non-isolated URLs to block
define condition non_isolated_uncategorized
 url.category=none isolated=no
end condition non_isolated_uncategorized

If Web Isolation does not occur as expected, review Troubleshooting.

Remove or Disable Web Isolation Policy

Up to version 7.3.3, you can simply uninstall Web Isolation policy if you no longer want to use it.

In version 7.3.4 and later, you must uninstall the Web Isolation policy and then disable the service. Disabling the service before removing policy will return exception pages for traffic matching the isolation policy rules. Disable the service using the CLI:

#(config) isolation
#(config isolation) disable

Troubleshooting

If you encounter browser error messages or other unexpected behavior after making configuration changes, clear both the Edge SWG cache (using # clear-cache command) and the browser cache and test the configuration again.
If the default policy is DENY and isolation policy only works when you change the default to ALLOW, you must specify an ALLOW rule and isolation rules in separate layers. In CPL, the isolation rules can be in the same layer as ALLOW if they are on the same line, as in the following example:
<Proxy>
condition=do_not_isolate_internal_destinations isolate(no) ALLOW
If users receive exception pages for requests that should be isolated, see the previous section Remove or Disable Web Isolation Policy.
If Web Isolation policy does not behave as expected, you can review the access log to check if requests are isolated. In the Admin Console, click Administration > Logging> Access Logging and locate the Logging Formats table. Create a new log format or edit an existing one, and add the x-isolated access log field to it. If policy includes the isolated= gesture, the access log indicates yes or no as well as the protocol and URL for the transaction.
If there are issues with isolating HTTPS requests, check if policy is configured correctly to intercept the HTTPS traffic that you want to forward to Web Isolation.
You can also check the health status of the Web Isolation service. In the Admin Console, click Reports > Health Checks. Look for the iso.server health check. The following example shows a failed health check:

A failed health check might indicate an error in configuration. Review the steps in Configure the Cloud Web Isolation Service or Configure a Custom Web Isolation Service.

- To verify that the configured headers are forwarded to the Isolation, view the activity reports in Web Isolation:
  1. In Web Isolation, click Reports > Activity Logs.
  2. Look for the following fields for the header-to-field mappings:
    - authenticated-user: Username
    - authenticated-groups: User Groups
    - client-address: Source IP

Feedback

thumb_up Yes

thumb_down No