To use Secure Web Gateway (SWG), you must configure URL categorization. You might need to configure additional items depending on the other features that you decide to use.

URL categorization

To get a working SWG configuration, you must first download URL categories, configure URL filters, and configure schemes.

Transparent user identification

If you plan to identify users transparently, you must first download, install, and configure a BIG-IP user identification agent, either the F5 DC Agent or the F5 Logon Agent.

Authentication

F5 recommends that you use NTLM or Kerberos authentication. If you plan to use authentication, ensure that you have what you need configured.

• For NTLM, you need an NTLM Auth Configuration in Access Policy Manager (APM).
• For Kerberos, you need a domain-joined Kerberos user account and a Kerberos AAA server configured in APM.

SSL intercept

To intercept SSL connections that are passing through the proxy, ensure that you have imported a valid subordinate CA certificate and key that is trusted by the endpoints behind the proxy.

Captive portal

If you plan to use the captive portal feature, make sure that a certificate and key with the proper common name is imported for use.

When deployed as an application service, the Secure Web Gateway iApps template can set up either an explicit or a transparent forward proxy configuration. You can download the template from the F5 DevCentral iApp Codeshare wiki at (http://devcentral.f5.com/wiki/iapp.Codeshare.ashx).

User identification configuration requires a method setting in the access profile and an access policy configured to support the setting. Depending on the access profile type, you can select one of these user identification methods: by IP address (for SWG-Explicit or SWG-Transparent access profile types) or by credentials (for SWG-Explicit type).

1. On the Main tab, click Network > VLANs. The VLAN List screen opens.
2. Click Create. The New VLAN screen opens.
3. In the Name field, type a unique name for the VLAN.
4. For the Interfaces setting,
   1. From the Interface list, select an interface number.
   2. From the Tagging list, select Untagged.
   3. Click Add.
5. Click Finished. The screen refreshes, and displays the new VLAN in the list.

1. On the Main tab, click Network > Self IPs.
2. Click Create. The New Self IP screen opens.
3. In the Name field, type a unique name for the self IP address.
4. In the IP Address field, type the IP address of the VLAN. The system accepts IPv4 and IPv6 addresses.
5. In the Netmask field, type the full network mask for the specified IP address.

   For example, you can type ffff:ffff:ffff:ffff:0000:0000:0000:0000 or ffff:ffff:ffff:ffff::.

6. From the VLAN/Tunnel list, select the VLAN.
7. Click Finished. The screen refreshes, and displays the new self IP address.

1. On the Main tab, click Access Policy > Per-Request Policies. The Per-Request Policies screen opens.
2. Click Create. The General Properties screen displays.
3. In the Name field, type a name for the policy and click Finished. A per-request policy name must be unique among all per-request policy and access profile names. The policy name appears on the Per-Request Policies screen.
4. In the Access Policy column for the per-request policy that you want to update, click the Edit link. The visual policy editor opens in another tab.
5. To create different branches for processing HTTP and HTTPS traffic, add a Protocol Lookup item.
   1. Click the (+) icon anywhere in the per-request policy to add a new item. A popup screen opens, listing predefined actions on tabs such as General Purpose, Authentication, and so on.
   2. Type prot in the Search field, select Protocol Lookup, and click Add Item. A Properties popup screen opens.
   3. Click Save. The Properties screen closes. The visual policy editor displays.
6. If you configured SSL forward proxy bypass in the client and server SSL profiles, include an SSL Intercept Set item to ensure that SSL traffic is not bypassed until this policy determines that it should be. It is important to include SSL Intercept Set when the default SSL bypass action in the client SSL profile is set to Bypass.
7. To retrieve the requested URL and the categories to which it belongs, add a Category Lookup item.
   Important: A Category Lookup item is required to trigger event logging for SWG, to provide a response web page for the Response Analytics item, and to provide categories for the URL Filter Assign item.
   1. Click the (+) icon anywhere in the per-request policy to add a new item. A popup screen opens, listing predefined actions on tabs such as General Purpose, Authentication, and so on.
   2. Type cat in the Search field, select Category Lookup, and click Add Item. A Properties popup screen opens.
   3. From the Categorization Input list, select how to obtain the requested URL. For HTTP traffic, select Use HTTP URI (cannot be used for SSL Bypass decisions). For SSL-encrypted traffic, select either Use SNI in Client Hello (if SNI is not available, use Subject.CN) or Use Subject.CN in Server Cert. If you select Use HTTP URI (cannot be used for SSL Bypass decisions), the SafeSearch Mode list displays and Enabled is selected.
   4. From the Category Lookup Type list, select the category types in which to search for the requested URL. Select one from Custom categories first, then standard categories if not found, Always process full list of both custom and standard categories, or Process standard categories only. Depending on your selection, the Category Lookup Type item looks through custom categories or standard categories or both, and compiles a list of one or more categories from them. The list is available for subsequent processing by the URL Filter Assign item.
   5. Click Save. The Properties screen closes. The visual policy editor displays.
8. To enable Safe Search for SSL-encrypted traffic, add an additional Category Lookup item, specify Use HTTP URI (cannot be used for SSL Bypass decisions) as the Category Lookup Type, and retain the default setting (Enabled) for SafeSearch Mode.
9. At any point in the policy where a decision to bypass SSL traffic is made, add an SSL Bypass Set item.
10. Add any of these items to the policy.

    Item	Description
    Dynamic Date Time	Branch by day of week or time of day.
    AD Group Lookup	Branch by user group. Requires branch rule configuration.
    LDAP Group Lookup	Branch by user group. Requires branch rule configuration.
    LocalDB Group Lookup	Branch by user group. Requires branch rule configuration.
    RADIUS Class Lookup	Branch by the class attribute. Requires branch rule configuration.

11. To configure a branch rule for a LocalDB Group Lookup item:
    1. In the visual policy editor, click the name of the item. A Properties popup screen opens.
    2. Click the Branch Rules tab.
    3. To edit an expression, click the change link. An additional popup screen opens, displaying the Simple tab.
    4. If the Local Database action in the access policy was configured to read groups into the session.localdb.groups session variable, edit the default simple expression, User is a member of MY_GROUP, replacing MY_GROUP with a relevant group.
    5. If the Local Database action in the access policy was configured to read groups into a session variable other than session.localdb.groups, click the Advanced tab; edit the default advanced expression, expression is expr { [mcget {session.localdb.groups}] contains "MY_GROUP" }, replacing MY_GROUP with a relevant group and session.localdb.groups with the session variable specified in the Local Database action.
    6. Click Finished. The popup screen closes.
    7. Click Save. The popup screen closes. The visual policy editor displays.
12. To configure a branch rule for AD, LDAP, or RADIUS group or class lookups:
    1. In the visual policy editor, click the name of the policy item. A Properties popup screen opens.
    2. Click the Branch Rules tab.
    3. To edit an expression, click the change link. An additional popup screen opens, displaying the Simple tab.
    4. Edit the default simple expression to specify group or class that is used in your environment. In an LDAP Group Lookup item, the default simple expression is User is a member of CN=MY_GROUP, CN=USERS, CN=MY_DOMAIN. You can use the simple expression editor to replace the default values.
    5. Click Finished. The popup screen closes.
    6. Click Save. The popup screen closes. The visual policy editor displays.
13. To trigger inspection of the response web page contents, add a Response Analytics item. A Category Lookup item must precede this item.
    1. In the Max Buffer Size field, type the number of bytes to buffer.
    2. In the Max Buffer time field, type the number of seconds to retain response data in the buffer.
    3. For the Reset on Failure field, retain the default value Enabled to send a TCP reset if the server fails.
    4. For each type of content that you want to exclude from analysis, click Add new entry and then select a type from the list. The All-Images type is on the list by default because images are not scanned.
    5. Click Finished. The popup screen closes.
    6. Click Save. The fallback branch after this item indicates that a failure occurred during content analysis. The Success branch indicates that content analysis completed. The popup screen closes. The visual policy editor displays.
14. Add a URL Filter Assign item after the Response Analytics item, if included on the branch; otherwise, add it anywhere on a branch after a Category Lookup item. In this item, you must specify a URL filter to apply to the URL categories that the Category Lookup item returned. If any URL category specifies the Block filtering action, this item blocks the request. This item also blocks the request if the Response Analytics item identified malicious content.

1. On the Main tab, click Access Policy > Access Profiles. The Access Profiles List screen opens.
2. Click Create. The New Profile screen opens.
3. In the Name field, type a name for the access profile.
   Note: An access profile name must be unique among all access profile and per-request policy names.
4. From the Profile Type list, select SWG-Transparent. With this type, only the access policy items that are valid for Secure Web Gateway (SWG) transparent forward proxy are available in the visual policy editor.
5. Select the Custom check box for Settings. The settings become available.
6. Optional: To use NTLM authentication before a session starts, from the NTLM Auth Configuration list select a configuration. In the case of a shared machine, an IP address might already be associated with a user or a session. Using NTLM authentication ensures that the system can associate the IP address with the correct session (new or existing) or with a new user each time a user logs on to the shared machine.
7. Optional: To direct users to a captive portal, for Captive Portal select Enabled and, in the Primary Authentication URI field, type the URI. You might specify the URI of your primary authentication server if you use single sign-on across multiple domains. Users can then access multiple back-end applications from multiple domains and hosts without needing to re-enter their credentials, because the user session is stored on the primary domain. For example, you might type https://logon.siterequest.com in the field.
8. In the Language Settings area, add and remove accepted languages, and set the default language. A browser uses the highest priority accepted language. If no browser language matches the accepted languages list, the browser uses the default language.
9. Click Finished. The Access Profiles list screen displays.
10. To enable Secure Web Gateway event logging for this access profile, add log settings.
    1. Click the name of the access profile that you just created. The Properties screen displays.
    2. On the menu bar, click Logs. The General Properties screen displays.
    3. In the Log Settings area, move log settings from the Available list to the Selected list.
    You can configure log settings in the Access Policy Event Logs area of the product.

1. On the Main tab, click Access Policy > Access Profiles. The Access Profiles List screen opens.
2. Click the (+) icon anywhere in the access policy to add a new action item.
   Note: Only an applicable subset of access policy items is available for selection in the visual policy editor for any access profile type.
   A popup screen opens, listing predefined actions on tabs such as General Purpose, Authentication, and so on.
3. If you specified an NTLM Auth configuration in the access profile, verify that authentication succeeded.
   1. Type NTLM in the search field.
   2. Select NTLM Auth Result from the results list.
   3. Click Add Item. A properties popup screen opens.
   4. Click Save. The Properties screen closes. The visual policy editor displays.
4. Assign an SWG scheme to the access policy: Scheme assignment is mandatory.
   1. Click the (+) icon anywhere in the access policy to add a new action item.
   2. On the Assignment tab, select SWG Scheme Assign and click Add Item. A Properties screen opens.
   1. To display the available schemes, click the Add/Delete link.
   2. Select one scheme and click Save. The Properties screen closes and the visual policy editor displays.
5. To supply LDAP group information for use in the per-request policy, add an LDAP Query item anywhere in the access policy and configure its properties:
   1. From the Server list, select an AAA LDAP server. An LDAP Query uses SSL connections when you select an LDAP AAA server that is configured for LDAPS.
   2. Specify the SearchDN, and SearchFilter settings. SearchDN is the base DN from which the search is done.
   3. Click Save.
   This item populates the session.ldap.last.attr.memberOf session variable.
6. To supply Active Directory groups for use in the per-request policy, add an AD Query item anywhere in the access policy and configure its properties:
   1. From the Server list, select an AAA AD server.
   2. Select the Fetch Primary Group check box. The value of the primary user group populates the session.ad.last.attr.primaryGroupID session variable.
   3. Click Save.
7. To supply RADIUS class attributes for use in the per-request policy, add a RADIUS Auth item anywhere in the access policy and configure its properties:
   1. From the Server list, select an AAA RADIUS server.
   2. Click Save.
   This item populates the session.radius.last.attr.class session variable.
8. To supply local database groups for use in the per-request policy, add a Local Database item anywhere in the access policy and configure its properties:
   1. From the LocalDB Instance list, select a local user database.
   2. In the User Name field, retain the default session variable.
   3. Click Add new entry A new line is added to the list of entries with the Action set to Read and other default settings.
   4. In the Destination column Session Variable field, type session.localdb.groups. If you type a name other than session.localdb.groups, note it. You will need it when you configure the per-request access policy.
   5. In the Source column from the DB Property list, select groups.
   6. Click Save.
   This item populates the session.localdb.groups session variable.
9. Optional: To identify a user transparently, perform these substeps. To use transparent user identification, you must have installed and configured a BIG-IP user identification agent, either the F5 DC Agent or the F5 Logon Agent.
   1. On an access policy branch, click the plus symbol (+) to add an item to the access policy.
   2. From the Authentication tab, select Transparent Identity Import and click Add Item. The transparent identity import access policy item searches the database in the IF-MAP server for the client source IP address. By default, this access policy item has two branches: associated and fallback. A properties screen opens.
   3. Click Save. The visual policy editor displays.
   4. Add any additional access policy items to the fallback or associated branches. You might add Kerberos authentication on the fallback branch.
10. Optional: To add Kerberos authentication to the access policy, perform these substeps:
    1. On an access policy branch, click the plus symbol (+) to add an item to the access policy.
    2. On the Logon tab, select HTTP 401 Response and click Add Item. A Properties screen opens.
    3. From the HTTP Auth Level list, select negotiate and click Save. The properties screen closes.
    4. Click the (+) icon on the negotiate branch. A popup screen opens.
    5. Type ker in the search field, select Kerberos Auth from the results, and click Add Item. A properties screen opens.
    6. From the AAA Server list, select an existing server.
    7. From the Request Based Auth list, select Disabled.
    8. Click Save. The properties screen closes and the visual policy editor is displayed.
    Note: The Max Logon Attempts Allowed setting specifies attempts by an external client without a Kerberos ticket to authenticate on SWG forward proxy.
11. Click the Apply Access Policy link to apply and activate the changes to the access policy.

1. On the Main tab, click Local Traffic > Profiles > SSL > Client. The Client profile list screen opens.
2. Click Create. The New Client SSL Profile screen opens.
3. In the Name field, type a unique name for the profile.
4. From the Parent Profile list, select clientssl.
5. To avoid issues with privacy concerns, you might need to enable SSL forward proxy bypass for URLs that expose personal user information, such as those for financial or government sites.
   1. Scroll down to the SSL Forward Proxy list, and select Advanced.
   2. Select the Custom check box for the SSL Forward Proxy area.
   3. From the SSL Forward Proxy list, select Enabled. You can update this setting later but only while the profile is not assigned to a virtual server.
   4. From the CA Certificate list, select a certificate.
   5. From the CA Key list, select a key.
   6. In the CA Passphrase field, type a passphrase.
   7. In the Confirm CA Passphrase field, type the passphrase again.
   8. In the Certificate Lifespan field, type a lifespan for the SSL forward proxy certificate in days.
   9. Optional: From the Certificate Extensions list, select Extensions List.
   10. Optional: For the Certificate Extensions List setting, select the extensions that you want in the Available extensions field, and move them to the Enabled Extensions field using the Enable button.
   11. From the SSL Forward Proxy Bypass list, select Enabled. You can update this setting later but only while the profile is not assigned to a virtual server. Additional settings display.
   12. For Default Bypass Action, retain the default value Intercept. You can override the value of this action on a case-by-case basis in the per-request policy for the virtual server.
       Note: Bypass and intercept lists do not work with per-request policies. Retain the setting None for the remainder of the fields.
6. Click Finished.

1. On the Main tab, click Local Traffic > Profiles > SSL > Server. The SSL Server profile list screen opens.
2. Click Create. The New Server SSL Profile screen opens.
3. In the Name field, type a unique name for the profile.
4. For Parent Profile, retain the default selection, serverssl.
5. From the Configuration list, select Advanced.
6. Select the Custom check box. The settings become available for change.
7. From the SSL Forward Proxy list, select Enabled. You can update this setting later, but only while the profile is not assigned to a virtual server.
8. From the SSL Forward Proxy Bypass list, select Enabled (or retain the default value Disabled). The values of the SSL Forward Proxy Bypass settings in the server SSL and the client SSL profiles specified in a virtual server must match. You can update this setting later but only while the profile is not assigned to a virtual server.
9. Scroll down to the Secure Renegotiation list and select Request.
10. Click Finished.

1. On the Main tab, click Local Traffic > Virtual Servers. The Virtual Server List screen opens.
2. Click the Create button. The New Virtual Server screen opens.
3. In the Name field, type a unique name for the virtual server.
4. In the Destination Address field, type 0.0.0.0/0 to accept any IPv4 traffic.
5. In the Service Port field, type 443 or select HTTPS from the list.
6. From the Configuration list, select Advanced.
7. From the HTTP Profile list, select http.
8. For the SSL Profile (Client) setting, from the Available list, select the name of the Client SSL forward proxy profile you previously created, and using the Move button, move the name to the Selected list.
   Important: To enable SSL forward proxy functionality, you can either:

   • Disassociate existing Client SSL and Server SSL profiles from a virtual server and configure the SSL Forward Proxy settings.
   • Create new Client SSL and Server SSL profiles and configure the SSL Forward Proxy settings.

   Then with either option, select the Client SSL and Server SSL profiles on a virtual server. You cannot modify existing Client SSL and Server SSL profiles while they are selected on a virtual server to enable SSL forward proxy functionality.
9. For the SSL Profile (Server) setting, from the Available list, select the name of the Server SSL forward proxy profile you previously created, and using the Move button, move the name to the Selected list.
   Important: To enable SSL forward proxy functionality, you can either:

   • Disassociate existing Client SSL and Server SSL profiles from a virtual server and configure the SSL Forward Proxy settings.
   • Create new Client SSL and Server SSL profiles and configure the SSL Forward Proxy settings.

   Then with either option, select the Client SSL and Server SSL profiles on a virtual server. You cannot modify existing Client SSL and Server SSL profiles while they are selected on a virtual server to enable SSL forward proxy functionality.
10. For the Address Translation setting, clear the Enabled check box.
11. For the VLAN and Tunnel Traffic setting, retain the default value All VLANs and Tunnels list.
12. From the Source Address Translation list, select Auto Map.
13. If you are using a captive portal, in the Access Policy area from the Access Profile list, select the access profile that you configured for transparent forward proxy, and from the Per-Request Policy list, select the per-request policy you configured earlier.
14. Click Finished.

1. On the Main tab, click Local Traffic > Virtual Servers. The Virtual Server List screen opens.
2. Click the Create button. The New Virtual Server screen opens.
3. In the Name field, type a unique name for the virtual server.
4. In the Destination Address field, type 0.0.0.0/0 to accept any IPv4 traffic.
5. In the Service Port field, type 80, or select HTTP from the list.
6. From the HTTP Profile list, select http.
7. For the VLAN and Tunnel Traffic setting, retain the default value All VLANs and Tunnels list.
8. From the Source Address Translation list, select Auto Map.
9. In the Access Policy area, from the Access Profile list, select the access profile that you configured earlier.
10. From the Per-Request Policy list, select the per-request policy that you configured earlier.
11. Click Finished.

1. On the Main tab, click Local Traffic > Virtual Servers. The Virtual Server List screen opens.
2. Click the Create button. The New Virtual Server screen opens.
3. In the Name field, type a unique name for the virtual server.
4. From the Type list, select Forwarding (IP).
5. In the Source Address field, type 0.0.0.0/0.
6. In the Destination Address field, type 0.0.0.0/0 to accept any IPv4 traffic.
7. In the Service Port field, type * or select * All Ports from the list.
8. From the Protocol list, select * All Protocols.
9. From the VLAN and Tunnel Traffic list, retain the default selection, All VLANs and Tunnels.
10. From the Source Address Translation list, select Auto Map.
11. Click Finished.

1. On the Main tab, click Local Traffic > Profiles > SSL > Client. The Client profile list screen opens.
2. Click Create. The New Client SSL Profile screen opens.
3. In the Name field, type a unique name for the profile.
4. For the Parent Profile list, retain the default value, clientssl.
5. Select the Custom check box.
6. In the Certificate Key Chain area, select a certificate and key combination to use for SSL encryption for the captive portal. This certificate should match the FQDN configured in the SWG-Transparent access profile to avoid security warnings, and should be generated by a certificate authority that your browser clients trust.
   Note: If the key is encrypted, type a passphrase. Otherwise, leave the Passphrase field blank.
7. Click Finished.

1. On the Main tab, click Local Traffic > Virtual Servers. The Virtual Server List screen opens.
2. Click the Create button. The New Virtual Server screen opens.
3. In the Name field, type a unique name for the virtual server.
4. In the Destination Address field, type the IP address for a host virtual server. This field accepts an address in CIDR format (IP address/prefix). However, when you type the complete IP address for a host, you do not need to type a prefix after the address. Type a destination address in this format: 162.160.15.20.
5. In the Service Port field, type 443 or select HTTPS from the list.
6. From the HTTP Profile list, select http.
7. For the SSL Profile (Client) setting, move the profile you configured previously from the Available list to the Selected list.
8. Scroll down to the Access Policy area.
9. From the Access Profile list, select the access profile you configured previously.
10. From the Per-Request Policy list, select the per-request policy that you configured earlier.
11. Click Finished.

Web traffic that originates from your enterprise networks is now inspected and controlled by F5 Secure Web Gateway forward proxy.

Per-request policy items that look up the group or class to which a user belongs rely on the access policy to populate these session variables.

A tool that captures HTTP traffic can reveal what appears to be an extra redirect after a user attempts to gain access using a captive portal but fails, and the access policy goes to a Deny ending. Instead of immediately redirecting the user to the logout page, the user is first redirected to the landing URI, and then a request to the landing URI is redirected to the logout page.

This sample output shows both redirects: the 302 to the landing page http://berkeley.edu/index.html and the 302 to the logout page http://berkeley.edu/vdesk/hangup.php3.

Although the 302 to the landing page might seem to be an extra redirect, it is not. When a request is made, a subordinate virtual server transfers the request to the dominant virtual server to complete the access policy. When the dominant virtual completes the access policy, it transfers the user back to the subordinate virtual server, on the same original request. The subordinate virtual server then enforces the result of the access policy.

To use Secure Web Gateway (SWG), you must configure URL categorization. You might need to configure additional items depending on the other features that you decide to use.

URL categorization

To get a working SWG configuration, you must first download URL categories, configure URL filters, and configure schemes.

Transparent user identification

If you plan to identify users transparently, you must first download, install, and configure a BIG-IP user identification agent, either the F5 DC Agent or the F5 Logon Agent.

Authentication

F5 recommends that you use NTLM or Kerberos authentication. If you plan to use authentication, ensure that you have what you need configured.

• For NTLM, you need an NTLM Auth Configuration in Access Policy Manager (APM).
• For Kerberos, you need a domain-joined Kerberos user account and a Kerberos AAA server configured in APM.

SSL intercept

To intercept SSL connections that are passing through the proxy, ensure that you have imported a valid subordinate CA certificate and key that is trusted by the endpoints behind the proxy.

Captive portal

If you plan to use the captive portal feature, make sure that a certificate and key with the proper common name is imported for use.

When deployed as an application service, the Secure Web Gateway iApps template can set up either an explicit or a transparent forward proxy configuration. You can download the template from the F5 DevCentral iApp Codeshare wiki at (http://devcentral.f5.com/wiki/iapp.Codeshare.ashx).

User identification configuration requires a method setting in the access profile and an access policy configured to support the setting. Depending on the access profile type, you can select one of these user identification methods: by IP address (for SWG-Explicit or SWG-Transparent access profile types) or by credentials (for SWG-Explicit type).

1. On the Main tab, click Network > VLANs. The VLAN List screen opens.
2. Click Create. The New VLAN screen opens.
3. In the Name field, type a unique name for the VLAN.
4. For the Interfaces setting,
   1. From the Interface list, select an interface number.
   2. From the Tagging list, select Untagged.
   3. Click Add.
5. Click Finished. The screen refreshes, and displays the new VLAN in the list.

1. On the Main tab, click Network > Self IPs.
2. Click Create. The New Self IP screen opens.
3. In the Name field, type a unique name for the self IP address.
4. In the IP Address field, type the IP address of the VLAN. The system accepts IPv4 and IPv6 addresses.
5. In the Netmask field, type the full network mask for the specified IP address.

   For example, you can type ffff:ffff:ffff:ffff:0000:0000:0000:0000 or ffff:ffff:ffff:ffff::.

6. From the VLAN/Tunnel list, select the VLAN.
7. Click Finished. The screen refreshes, and displays the new self IP address.

1. On the Main tab, click Access Policy > Per-Request Policies. The Per-Request Policies screen opens.
2. Click Create. The General Properties screen displays.
3. In the Name field, type a name for the policy and click Finished. A per-request policy name must be unique among all per-request policy and access profile names. The policy name appears on the Per-Request Policies screen.
4. In the Access Policy column for the per-request policy that you want to update, click the Edit link. The visual policy editor opens in another tab.
5. To create different branches for processing HTTP and HTTPS traffic, add a Protocol Lookup item.
   1. Click the (+) icon anywhere in the per-request policy to add a new item. A popup screen opens, listing predefined actions on tabs such as General Purpose, Authentication, and so on.
   2. Type prot in the Search field, select Protocol Lookup, and click Add Item. A Properties popup screen opens.
   3. Click Save. The Properties screen closes. The visual policy editor displays.
6. If you configured SSL forward proxy bypass in the client and server SSL profiles, include an SSL Intercept Set item to ensure that SSL traffic is not bypassed until this policy determines that it should be. It is important to include SSL Intercept Set when the default SSL bypass action in the client SSL profile is set to Bypass.
7. To retrieve the requested URL and the categories to which it belongs, add a Category Lookup item.
   Important: A Category Lookup item is required to trigger event logging for SWG, to provide a response web page for the Response Analytics item, and to provide categories for the URL Filter Assign item.
   1. Click the (+) icon anywhere in the per-request policy to add a new item. A popup screen opens, listing predefined actions on tabs such as General Purpose, Authentication, and so on.
   2. Type cat in the Search field, select Category Lookup, and click Add Item. A Properties popup screen opens.
   3. From the Categorization Input list, select how to obtain the requested URL. For HTTP traffic, select Use HTTP URI (cannot be used for SSL Bypass decisions). For SSL-encrypted traffic, select either Use SNI in Client Hello (if SNI is not available, use Subject.CN) or Use Subject.CN in Server Cert. If you select Use HTTP URI (cannot be used for SSL Bypass decisions), the SafeSearch Mode list displays and Enabled is selected.
   4. From the Category Lookup Type list, select the category types in which to search for the requested URL. Select one from Custom categories first, then standard categories if not found, Always process full list of both custom and standard categories, or Process standard categories only. Depending on your selection, the Category Lookup Type item looks through custom categories or standard categories or both, and compiles a list of one or more categories from them. The list is available for subsequent processing by the URL Filter Assign item.
   5. Click Save. The Properties screen closes. The visual policy editor displays.
8. To enable Safe Search for SSL-encrypted traffic, add an additional Category Lookup item, specify Use HTTP URI (cannot be used for SSL Bypass decisions) as the Category Lookup Type, and retain the default setting (Enabled) for SafeSearch Mode.
9. At any point in the policy where a decision to bypass SSL traffic is made, add an SSL Bypass Set item.
10. Add any of these items to the policy.

    Item	Description
    Dynamic Date Time	Branch by day of week or time of day.
    AD Group Lookup	Branch by user group. Requires branch rule configuration.
    LDAP Group Lookup	Branch by user group. Requires branch rule configuration.
    LocalDB Group Lookup	Branch by user group. Requires branch rule configuration.
    RADIUS Class Lookup	Branch by the class attribute. Requires branch rule configuration.

11. To configure a branch rule for a LocalDB Group Lookup item:
    1. In the visual policy editor, click the name of the item. A Properties popup screen opens.
    2. Click the Branch Rules tab.
    3. To edit an expression, click the change link. An additional popup screen opens, displaying the Simple tab.
    4. If the Local Database action in the access policy was configured to read groups into the session.localdb.groups session variable, edit the default simple expression, User is a member of MY_GROUP, replacing MY_GROUP with a relevant group.
    5. If the Local Database action in the access policy was configured to read groups into a session variable other than session.localdb.groups, click the Advanced tab; edit the default advanced expression, expression is expr { [mcget {session.localdb.groups}] contains "MY_GROUP" }, replacing MY_GROUP with a relevant group and session.localdb.groups with the session variable specified in the Local Database action.
    6. Click Finished. The popup screen closes.
    7. Click Save. The popup screen closes. The visual policy editor displays.
12. To configure a branch rule for AD, LDAP, or RADIUS group or class lookups:
    1. In the visual policy editor, click the name of the policy item. A Properties popup screen opens.
    2. Click the Branch Rules tab.
    3. To edit an expression, click the change link. An additional popup screen opens, displaying the Simple tab.
    4. Edit the default simple expression to specify group or class that is used in your environment. In an LDAP Group Lookup item, the default simple expression is User is a member of CN=MY_GROUP, CN=USERS, CN=MY_DOMAIN. You can use the simple expression editor to replace the default values.
    5. Click Finished. The popup screen closes.
    6. Click Save. The popup screen closes. The visual policy editor displays.
13. To trigger inspection of the response web page contents, add a Response Analytics item. A Category Lookup item must precede this item.
    1. In the Max Buffer Size field, type the number of bytes to buffer.
    2. In the Max Buffer time field, type the number of seconds to retain response data in the buffer.
    3. For the Reset on Failure field, retain the default value Enabled to send a TCP reset if the server fails.
    4. For each type of content that you want to exclude from analysis, click Add new entry and then select a type from the list. The All-Images type is on the list by default because images are not scanned.
    5. Click Finished. The popup screen closes.
    6. Click Save. The fallback branch after this item indicates that a failure occurred during content analysis. The Success branch indicates that content analysis completed. The popup screen closes. The visual policy editor displays.
14. Add a URL Filter Assign item after the Response Analytics item, if included on the branch; otherwise, add it anywhere on a branch after a Category Lookup item. In this item, you must specify a URL filter to apply to the URL categories that the Category Lookup item returned. If any URL category specifies the Block filtering action, this item blocks the request. This item also blocks the request if the Response Analytics item identified malicious content.

1. On the Main tab, click Access Policy > Access Profiles. The Access Profiles List screen opens.
2. Click Create. The New Profile screen opens.
3. In the Name field, type a name for the access profile.
   Note: An access profile name must be unique among all access profile and per-request policy names.
4. From the Profile Type list, select SWG-Transparent. With this type, only the access policy items that are valid for Secure Web Gateway (SWG) transparent forward proxy are available in the visual policy editor.
5. Select the Custom check box for Settings. The settings become available.
6. Optional: To use NTLM authentication before a session starts, from the NTLM Auth Configuration list select a configuration. In the case of a shared machine, an IP address might already be associated with a user or a session. Using NTLM authentication ensures that the system can associate the IP address with the correct session (new or existing) or with a new user each time a user logs on to the shared machine.
7. Optional: To direct users to a captive portal, for Captive Portal select Enabled and, in the Primary Authentication URI field, type the URI. You might specify the URI of your primary authentication server if you use single sign-on across multiple domains. Users can then access multiple back-end applications from multiple domains and hosts without needing to re-enter their credentials, because the user session is stored on the primary domain. For example, you might type https://logon.siterequest.com in the field.
8. In the Language Settings area, add and remove accepted languages, and set the default language. A browser uses the highest priority accepted language. If no browser language matches the accepted languages list, the browser uses the default language.
9. Click Finished. The Access Profiles list screen displays.
10. To enable Secure Web Gateway event logging for this access profile, add log settings.
    1. Click the name of the access profile that you just created. The Properties screen displays.
    2. On the menu bar, click Logs. The General Properties screen displays.
    3. In the Log Settings area, move log settings from the Available list to the Selected list.
    You can configure log settings in the Access Policy Event Logs area of the product.

1. On the Main tab, click Access Policy > Access Profiles. The Access Profiles List screen opens.
2. Click the (+) icon anywhere in the access policy to add a new action item.
   Note: Only an applicable subset of access policy items is available for selection in the visual policy editor for any access profile type.
   A popup screen opens, listing predefined actions on tabs such as General Purpose, Authentication, and so on.
3. If you specified an NTLM Auth configuration in the access profile, verify that authentication succeeded.
   1. Type NTLM in the search field.
   2. Select NTLM Auth Result from the results list.
   3. Click Add Item. A properties popup screen opens.
   4. Click Save. The Properties screen closes. The visual policy editor displays.
4. Assign an SWG scheme to the access policy: Scheme assignment is mandatory.
   1. Click the (+) icon anywhere in the access policy to add a new action item.
   2. On the Assignment tab, select SWG Scheme Assign and click Add Item. A Properties screen opens.
   1. To display the available schemes, click the Add/Delete link.
   2. Select one scheme and click Save. The Properties screen closes and the visual policy editor displays.
5. To supply LDAP group information for use in the per-request policy, add an LDAP Query item anywhere in the access policy and configure its properties:
   1. From the Server list, select an AAA LDAP server. An LDAP Query uses SSL connections when you select an LDAP AAA server that is configured for LDAPS.
   2. Specify the SearchDN, and SearchFilter settings. SearchDN is the base DN from which the search is done.
   3. Click Save.
   This item populates the session.ldap.last.attr.memberOf session variable.
6. To supply Active Directory groups for use in the per-request policy, add an AD Query item anywhere in the access policy and configure its properties:
   1. From the Server list, select an AAA AD server.
   2. Select the Fetch Primary Group check box. The value of the primary user group populates the session.ad.last.attr.primaryGroupID session variable.
   3. Click Save.
7. To supply RADIUS class attributes for use in the per-request policy, add a RADIUS Auth item anywhere in the access policy and configure its properties:
   1. From the Server list, select an AAA RADIUS server.
   2. Click Save.
   This item populates the session.radius.last.attr.class session variable.
8. To supply local database groups for use in the per-request policy, add a Local Database item anywhere in the access policy and configure its properties:
   1. From the LocalDB Instance list, select a local user database.
   2. In the User Name field, retain the default session variable.
   3. Click Add new entry A new line is added to the list of entries with the Action set to Read and other default settings.
   4. In the Destination column Session Variable field, type session.localdb.groups. If you type a name other than session.localdb.groups, note it. You will need it when you configure the per-request access policy.
   5. In the Source column from the DB Property list, select groups.
   6. Click Save.
   This item populates the session.localdb.groups session variable.
9. Optional: To identify a user transparently, perform these substeps. To use transparent user identification, you must have installed and configured a BIG-IP user identification agent, either the F5 DC Agent or the F5 Logon Agent.
   1. On an access policy branch, click the plus symbol (+) to add an item to the access policy.
   2. From the Authentication tab, select Transparent Identity Import and click Add Item. The transparent identity import access policy item searches the database in the IF-MAP server for the client source IP address. By default, this access policy item has two branches: associated and fallback. A properties screen opens.
   3. Click Save. The visual policy editor displays.
   4. Add any additional access policy items to the fallback or associated branches. You might add Kerberos authentication on the fallback branch.
10. Optional: To add Kerberos authentication to the access policy, perform these substeps:
    1. On an access policy branch, click the plus symbol (+) to add an item to the access policy.
    2. On the Logon tab, select HTTP 401 Response and click Add Item. A Properties screen opens.
    3. From the HTTP Auth Level list, select negotiate and click Save. The properties screen closes.
    4. Click the (+) icon on the negotiate branch. A popup screen opens.
    5. Type ker in the search field, select Kerberos Auth from the results, and click Add Item. A properties screen opens.
    6. From the AAA Server list, select an existing server.
    7. From the Request Based Auth list, select Disabled.
    8. Click Save. The properties screen closes and the visual policy editor is displayed.
    Note: The Max Logon Attempts Allowed setting specifies attempts by an external client without a Kerberos ticket to authenticate on SWG forward proxy.
11. Click the Apply Access Policy link to apply and activate the changes to the access policy.

1. On the Main tab, click Local Traffic > Profiles > SSL > Client. The Client profile list screen opens.
2. Click Create. The New Client SSL Profile screen opens.
3. In the Name field, type a unique name for the profile.
4. From the Parent Profile list, select clientssl.
5. To avoid issues with privacy concerns, you might need to enable SSL forward proxy bypass for URLs that expose personal user information, such as those for financial or government sites.
   1. Scroll down to the SSL Forward Proxy list, and select Advanced.
   2. Select the Custom check box for the SSL Forward Proxy area.
   3. From the SSL Forward Proxy list, select Enabled. You can update this setting later but only while the profile is not assigned to a virtual server.
   4. From the CA Certificate list, select a certificate.
   5. From the CA Key list, select a key.
   6. In the CA Passphrase field, type a passphrase.
   7. In the Confirm CA Passphrase field, type the passphrase again.
   8. In the Certificate Lifespan field, type a lifespan for the SSL forward proxy certificate in days.
   9. Optional: From the Certificate Extensions list, select Extensions List.
   10. Optional: For the Certificate Extensions List setting, select the extensions that you want in the Available extensions field, and move them to the Enabled Extensions field using the Enable button.
   11. From the SSL Forward Proxy Bypass list, select Enabled. You can update this setting later but only while the profile is not assigned to a virtual server. Additional settings display.
   12. For Default Bypass Action, retain the default value Intercept. You can override the value of this action on a case-by-case basis in the per-request policy for the virtual server.
       Note: Bypass and intercept lists do not work with per-request policies. Retain the setting None for the remainder of the fields.
6. Click Finished.

1. On the Main tab, click Local Traffic > Profiles > SSL > Server. The SSL Server profile list screen opens.
2. Click Create. The New Server SSL Profile screen opens.
3. In the Name field, type a unique name for the profile.
4. For Parent Profile, retain the default selection, serverssl.
5. From the Configuration list, select Advanced.
6. Select the Custom check box. The settings become available for change.
7. From the SSL Forward Proxy list, select Enabled. You can update this setting later, but only while the profile is not assigned to a virtual server.
8. From the SSL Forward Proxy Bypass list, select Enabled (or retain the default value Disabled). The values of the SSL Forward Proxy Bypass settings in the server SSL and the client SSL profiles specified in a virtual server must match. You can update this setting later but only while the profile is not assigned to a virtual server.
9. Scroll down to the Secure Renegotiation list and select Request.
10. Click Finished.

1. On the Main tab, click Local Traffic > Virtual Servers. The Virtual Server List screen opens.
2. Click the Create button. The New Virtual Server screen opens.
3. In the Name field, type a unique name for the virtual server.
4. In the Destination Address field, type 0.0.0.0/0 to accept any IPv4 traffic.
5. In the Service Port field, type 443 or select HTTPS from the list.
6. From the Configuration list, select Advanced.
7. From the HTTP Profile list, select http.
8. For the SSL Profile (Client) setting, from the Available list, select the name of the Client SSL forward proxy profile you previously created, and using the Move button, move the name to the Selected list.
   Important: To enable SSL forward proxy functionality, you can either:

   • Disassociate existing Client SSL and Server SSL profiles from a virtual server and configure the SSL Forward Proxy settings.
   • Create new Client SSL and Server SSL profiles and configure the SSL Forward Proxy settings.

   Then with either option, select the Client SSL and Server SSL profiles on a virtual server. You cannot modify existing Client SSL and Server SSL profiles while they are selected on a virtual server to enable SSL forward proxy functionality.
9. For the SSL Profile (Server) setting, from the Available list, select the name of the Server SSL forward proxy profile you previously created, and using the Move button, move the name to the Selected list.
   Important: To enable SSL forward proxy functionality, you can either:

   • Disassociate existing Client SSL and Server SSL profiles from a virtual server and configure the SSL Forward Proxy settings.
   • Create new Client SSL and Server SSL profiles and configure the SSL Forward Proxy settings.

   Then with either option, select the Client SSL and Server SSL profiles on a virtual server. You cannot modify existing Client SSL and Server SSL profiles while they are selected on a virtual server to enable SSL forward proxy functionality.
10. For the Address Translation setting, clear the Enabled check box.
11. For the VLAN and Tunnel Traffic setting, retain the default value All VLANs and Tunnels list.
12. From the Source Address Translation list, select Auto Map.
13. If you are using a captive portal, in the Access Policy area from the Access Profile list, select the access profile that you configured for transparent forward proxy, and from the Per-Request Policy list, select the per-request policy you configured earlier.
14. Click Finished.

1. On the Main tab, click Local Traffic > Virtual Servers. The Virtual Server List screen opens.
2. Click the Create button. The New Virtual Server screen opens.
3. In the Name field, type a unique name for the virtual server.
4. In the Destination Address field, type 0.0.0.0/0 to accept any IPv4 traffic.
5. In the Service Port field, type 80, or select HTTP from the list.
6. From the HTTP Profile list, select http.
7. For the VLAN and Tunnel Traffic setting, retain the default value All VLANs and Tunnels list.
8. From the Source Address Translation list, select Auto Map.
9. In the Access Policy area, from the Access Profile list, select the access profile that you configured earlier.
10. From the Per-Request Policy list, select the per-request policy that you configured earlier.
11. Click Finished.

1. On the Main tab, click Local Traffic > Profiles > SSL > Client. The Client profile list screen opens.
2. Click Create. The New Client SSL Profile screen opens.
3. In the Name field, type a unique name for the profile.
4. For the Parent Profile list, retain the default value, clientssl.
5. Select the Custom check box.
6. In the Certificate Key Chain area, select a certificate and key combination to use for SSL encryption for the captive portal. This certificate should match the FQDN configured in the SWG-Transparent access profile to avoid security warnings, and should be generated by a certificate authority that your browser clients trust.
   Note: If the key is encrypted, type a passphrase. Otherwise, leave the Passphrase field blank.
7. Click Finished.

1. On the Main tab, click Local Traffic > Virtual Servers. The Virtual Server List screen opens.
2. Click the Create button. The New Virtual Server screen opens.
3. In the Name field, type a unique name for the virtual server.
4. In the Destination Address field, type the IP address for a host virtual server. This field accepts an address in CIDR format (IP address/prefix). However, when you type the complete IP address for a host, you do not need to type a prefix after the address. Type a destination address in this format: 162.160.15.20.
5. In the Service Port field, type 443 or select HTTPS from the list.
6. From the HTTP Profile list, select http.
7. For the SSL Profile (Client) setting, move the profile you configured previously from the Available list to the Selected list.
8. Scroll down to the Access Policy area.
9. From the Access Profile list, select the access profile you configured previously.
10. From the Per-Request Policy list, select the per-request policy that you configured earlier.
11. Click Finished.

Web traffic that originates from your enterprise networks is now inspected and controlled by F5 Secure Web Gateway forward proxy.

Per-request policy items that look up the group or class to which a user belongs rely on the access policy to populate these session variables.

A tool that captures HTTP traffic can reveal what appears to be an extra redirect after a user attempts to gain access using a captive portal but fails, and the access policy goes to a Deny ending. Instead of immediately redirecting the user to the logout page, the user is first redirected to the landing URI, and then a request to the landing URI is redirected to the logout page.

This sample output shows both redirects: the 302 to the landing page http://berkeley.edu/index.html and the 302 to the logout page http://berkeley.edu/vdesk/hangup.php3.

Although the 302 to the landing page might seem to be an extra redirect, it is not. When a request is made, a subordinate virtual server transfers the request to the dominant virtual server to complete the access policy. When the dominant virtual completes the access policy, it transfers the user back to the subordinate virtual server, on the same original request. The subordinate virtual server then enforces the result of the access policy.