F5 Logo MyF5
Search
  1. MyF5 Home
  2. Knowledge Centers
  3. BIG-IP APM
  4. BIG-IP Access Policy Manager: Secure Web Gateway
  5. Transparent Forward Proxy Configurations
Manual Chapter : Transparent Forward Proxy Configurations

Applies To:

Show Versions Show Versions

BIG-IP APM

  • 12.1.6, 12.1.5, 12.1.4, 12.1.3, 12.1.2, 12.1.1, 12.1.0
Manual Chapter
Table of Contents | << Previous Chapter | Next Chapter >>

Transparent Forward Proxy Configurations

Overview: Configuring transparent forward proxy in inline mode

In transparent forward proxy, you configure your internal network to forward web traffic to the BIG-IP® system with Secure Web Gateway (SWG). This implementation describes an inline deployment. You place the BIG-IP system directly in the path of traffic, or inline, as the next hop after the gateway.

swg

Secure Web Gateway transparent forward proxy inline deployment

The gateway sends traffic to the self IP address of a VLAN configured on the BIG-IP system. Wildcard virtual servers listen on the VLAN and process the traffic that most closely matches the virtual server address. A wildcard virtual server is a special type of network virtual server designed to manage network traffic that is targeted to transparent network devices.

Note: Transparent forward proxy provides the option to use a captive portal. To use this option, you need an additional virtual server, not shown in the figure, for the captive portal primary authentication server.

Task summary

About the iApp for Secure Web Gateway configuration

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).

SWG transparent forward proxy configuration prerequisites

Ensure that prerequisites are complete before beginning the configuration.

Per-request policy
A per-request policy is required in any Secure Web Gateway (SWG) forward proxy configuration. A per-request policy must specify the logic for processing URL requests.
URL categorization
On a BIG-IP® system with an SWG subscription, you must download and install a URL database and schedule updates for it. On a system without an SWG subscription, you can configure user-defined URL categories and filters to control access by filtering URLs.
Transparent user identification
On a system with an SWG subscription, if you plan to identify users transparently, you must first download, install, and configure an F5® user identification agent, either the F5 DC Agent or the F5 Logon Agent.
Note: User identification agents are available only on a BIG-IP® system with an SWG subscription.
Authentication
If you include authentication in your access policy and the first site that a user accesses uses HTTP instead of secure HTTP, passwords are passed as clear text. To prevent this from happening, 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.

SWG transparent forward proxy example: Clear text password

F5® recommends using NTLM or Kerberos authentication in a Secure Web Gateway (SWG) forward proxy configuration to prevent passwords from being exposed in clear text. With Captive Portals disabled in an SWG transparent type access profile, other types of authentication (AD Auth, LDAP Auth, or RADIUS Auth) in the access policy will work. However, the configuration is not secure because passwords can be exposed in clear text.

HTTP 401 + RADIUS Auth password in clear text

Access policy that can expose passwords in clear text (with captive portal disabled)

SWG transparent forward proxy example: Encrypted password

F5® recommends using NTLM or Kerberos authentication in a Secure Web Gateway (SWG) forward proxy configuration to prevent passwords from being exposed in clear text. With Captive Portals enabled in an SWG transparent type access profile, using a Logon Page with other types of authentication (AD Auth, LDAP Auth, or RADIUS Auth) in the access policy will also work to keep passwords secure.

LOgon Page + AD Auth password secure

Access policy that keeps passwords secure (with captive portals enabled)

Creating a VLAN for transparent forward proxy

You need a VLAN on which the forward proxy can listen. For increased security, the VLAN should directly face your clients.
  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.
The new VLAN appears in the VLAN list.

Assigning a self IP address to a VLAN

Assign a self IP address to a VLAN on which the forward proxy listens.
  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 network mask for the specified IP address.

    For example, you can type 255.255.255.0.

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

Creating an access profile for SWG transparent forward proxy

You create an access profile to provide the access policy configuration for a virtual server that establishes a secured session.
  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.
    Note: After you complete this step, the User Identification Method is set to IP Address and cannot be changed.
    Additional settings display.
  5. To use NTLM authentication before a session starts, from the NTLM Auth Configuration list select a configuration.
    Important: For NTLM authentication to work, you must also enable the Captive Portals setting and specify an IP address in the Primary Authentication URI field for the virtual server that you configure for the captive portal.
    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.
  6. 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.
  7. 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.
  8. Click Finished.
    The Access Profiles list screen displays.
The access profile displays in the Access Profiles List. Default-log-setting is assigned to the access profile.

Verifying log settings for the access profile

Confirm that the correct log settings are selected for the access profile to ensure that events are logged as you intend.
Note: Log settings are configured in the Access Policy Event Logs area of the product. They enable and disable logging for access system and URL request filtering events. Log settings also specify log publishers that send log messages to specified destinations.
  1. On the Main tab, click Access Policy > Access Profiles .
    The Access Profiles List screen opens.
  2. Click the name of the access profile that you want to edit.
    The properties screen opens.
  3. On the menu bar, click Logs.
    The access profile log settings display.
  4. Move log settings between the Available and Selected lists.
    You can assign up to three log settings that enable access system logging to an access profile. You can assign additional log settings to an access profile provided that they enable logging for URl request logging only.
    Note: Logging is disabled when the Selected list is empty.
  5. Click Update.
An access profile is in effect when it is assigned to a virtual server.

Configuring an access policy for transparent forward proxy

You configure an access policy for Secure Web Gateway (SWG) transparent forward proxy to populate session variables with group or class attribute information for use in the per-request policy. You can also add access policy items to collect credentials and to authenticate a user, or you can add items to transparently identify the user without requesting credentials.
Note: If you include authentication in your access policy and the first site that a user accesses uses HTTP instead of secure HTTP, passwords are passed as clear text. To prevent this from happening, F5® recommends using Kerberos or NTLM authentication.
  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. To add Kerberos authentication to the access policy, add these actions in order: HTTP 401 Response, Variable Assign, and Kerberos Auth using 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. On the Assignment tab, select Variable Assign and click Add Item.
      For Kerberos authentication to work correctly with SWG transparent forward proxy, you must assign the virtual server proxy domain name to a session variable.
    6. Click Add new entry.
      An empty entry appears in the Assignment table.
    7. Click the change link in the new entry.
      A popup screen opens.
    8. In the left pane, retain the selection of Custom Variable and type this variable name: session.server.network.name.
    9. In the right pane, in place of Custom Variable, select Text and type the domain name for the proxy virtual server.
    10. Click Finished.
      The popup screen closes.
    11. Click Save.
      The properties screen closes. The visual policy editor displays.
    12. On an access policy branch, click the plus symbol (+) to add an item to the access policy.
    13. Type ker in the search field, select Kerberos Auth from the results, and click Add Item.
      A properties screen opens.
    14. From the AAA Server list, select an existing server.
    15. From the Request Based Auth list, select Disabled.
    16. Click Save.
      The properties screen closes and the visual policy editor displays.
    Note: The Max Logon Attempts Allowed setting specifies attempts by an external client without a Kerberos ticket to authenticate on forward proxy.
  5. To identify a user transparently using information provided by a BIG-IP® user identification agent, perform these substeps:
    For this step of the access policy to succeed, you must have installed and configured either the F5® DC Agent or the F5 Logon Agent. Either agent is supported on a BIG-IP system with an SWG subscription only.
    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.
  6. 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.
  7. 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.
  8. 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.
  9. Click the Apply Access Policy link to apply and activate the changes to the access policy.
To apply this access policy to network traffic, add the access profile to a virtual server.
Note: To ensure that logging is configured to meet your requirements, verify the log settings for the access profile.

Creating a custom Client SSL forward proxy profile

Creating a Client SSL forward proxy profile makes it possible for client and server authentication, while still allowing the BIG-IP® system to perform data optimization, such as decryption and encryption. This profile applies to client-side SSL forward proxy traffic only.

  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.
The custom Client SSL forward proxy profile now appears in the Client SSL profile list screen.

Creating a custom Server SSL profile

Create a custom server SSL profile to support SSL forward proxy.
  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.
The custom Server SSL profile is now listed in the SSL Server profile list.

Creating a virtual server for forward proxy SSL traffic

You configure a virtual server to handle SSL web traffic.
  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 VLAN and Tunnel Traffic setting, retain the default value All VLANs and Tunnels list.
  11. From the Source Address Translation list, select Auto Map.
  12. For the Address Translation setting, clear the Enabled check box.
  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. If you are using a captive portal and the per-request policy that you configured earlier includes application filtering, perform these substeps:
    1. From the Classification list, select Enabled.
    2. Scroll down to the Resources area.
    3. For Policies, make sure that sys_CEC_video_policy is enabled.
    Note: The per-request policy uses application filtering when it runs an Application Lookup action.
  15. Click Finished.
The virtual server now appears in the Virtual Server List screen.

Creating a virtual server for forward proxy traffic

You configure a virtual server to handle web traffic going to port 80.
  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 Configuration list, select Advanced.
  7. From the HTTP Profile list, select http.
  8. For the VLAN and Tunnel Traffic setting, retain the default value All VLANs and Tunnels list.
  9. From the Source Address Translation list, select Auto Map.
  10. For the Address Translation setting, clear the Enabled check box.
  11. If the per-request policy that you configured earlier includes application filtering, perform these substeps:
    1. From the Classification list, select Enabled.
    2. Scroll down to the Resources area.
    3. For Policies, make sure that sys_CEC_video_policy is enabled.
    Note: The per-request policy uses application filtering when it runs an Application Lookup action.
  12. In the Access Policy area, from the Access Profile list, select the access profile that you configured earlier.
  13. From the Per-Request Policy list, select the per-request policy that you configured earlier.
  14. Click Finished.
The virtual server now appears in the Virtual Server List screen.

Creating a forwarding virtual server

For Secure Web Gateway transparent forward proxy in inline mode, you create a forwarding virtual server to intercept IP traffic that is not going to ports 80 or 443.
  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.

Creating a Client SSL profile for a captive portal

You create a Client SSL profile when you want the BIG-IP® system to authenticate and decrypt/encrypt client-side application traffic. You create this profile if you enabled Captive Portals in the access profile and if you want to use SSL.

  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.
After creating the Client SSL profile and assigning the profile to a virtual server, the BIG-IP system can apply SSL security to the type of application traffic for which the virtual server is configured to listen.

Creating a virtual server for a captive portal

You configure a virtual server to use as a captive portal if you enabled the Captive Portals setting in the access profile.
Note: If you do not plan to use client-side SSL, select a service port other than 443 and do not select an SSL client profile.
  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 Configuration list, select Advanced.
  7. From the HTTP Profile list, select http.
  8. For the SSL Profile (Client) setting, move the profile you configured previously from the Available list to the Selected list.
  9. Scroll down to the Access Policy area.
  10. From the Access Profile list, select the access profile you configured previously.
  11. Click Finished.
The virtual server appears in the Virtual Server List screen.

Implementation result

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 read session variables

This table lists per-request policy items that read session variables and lists the access policy items that populate the variables.

Per-request policy item Session variable Access policy item
AD Group Lookup session.ad.last.attr.primaryGroupID AD Query
LDAP Group Lookup session.ldap.last.attr.memberOf LDAP Query
LocalDB Group Lookup session.localdb.groups
Note: This session variable is a default in the expression for LocalDB Group Lookup; any session variable in the expression must match the session variable used in the Local Database action in the access policy.
Local Database
RADIUS Class Lookup session.radius.last.attr.class RADIUS Auth

About redirects after access denied by captive portal

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. 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. 

POST  https://bigip-master.com/my.policy?ORIG_URI=http://berkeley.edu/index.html
302   http://berkeley.edu/index.html

GET   http://berkeley.edu/index.html
302   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 server 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.

Overview: Configuring transparent forward proxy

In transparent forward proxy, you configure your internal network to forward web traffic to the BIG-IP® system with Secure Web Gateway (SWG). Use this implementation when your topology includes a router on which you can configure policy-based routing or Web Cache Communication Protocol (WCCP) to send any traffic for ports 80 and 443 to the BIG-IP system.

This implementation describes only the configuration required on the BIG-IP system.

swg

Secure Web Gateway transparent forward proxy deployment

The router sends traffic to the self-ip address of a VLAN configured on the BIG-IP system. Virtual servers listen on the VLAN and process the traffic that most closely matches the virtual server address. Secure Web Gateway identifies users without using session management cookies. A per-request policy, configured to use action items that determine the URL category and apply a URL filter, controls access.

Note: Transparent forward proxy provides the option to use a captive portal. To use this option, you need an additional virtual server, not shown in the figure, for the captive portal primary authentication server.

Task Summary

SWG transparent forward proxy configuration prerequisites

Ensure that prerequisites are complete before beginning the configuration.

Per-request policy
A per-request policy is required in any Secure Web Gateway (SWG) forward proxy configuration. A per-request policy must specify the logic for processing URL requests.
URL categorization
On a BIG-IP® system with an SWG subscription, you must download and install a URL database and schedule updates for it. On a system without an SWG subscription, you can configure user-defined URL categories and filters to control access by filtering URLs.
Transparent user identification
On a system with an SWG subscription, if you plan to identify users transparently, you must first download, install, and configure an F5® user identification agent, either the F5 DC Agent or the F5 Logon Agent.
Note: User identification agents are available only on a BIG-IP® system with an SWG subscription.
Authentication
If you include authentication in your access policy and the first site that a user accesses uses HTTP instead of secure HTTP, passwords are passed as clear text. To prevent this from happening, 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.

SWG transparent forward proxy example: Clear text password

F5® recommends using NTLM or Kerberos authentication in a Secure Web Gateway (SWG) forward proxy configuration to prevent passwords from being exposed in clear text. With Captive Portals disabled in an SWG transparent type access profile, other types of authentication (AD Auth, LDAP Auth, or RADIUS Auth) in the access policy will work. However, the configuration is not secure because passwords can be exposed in clear text.

HTTP 401 + RADIUS Auth password in clear text

Access policy that can expose passwords in clear text (with captive portal disabled)

SWG transparent forward proxy example: Encrypted password

F5® recommends using NTLM or Kerberos authentication in a Secure Web Gateway (SWG) forward proxy configuration to prevent passwords from being exposed in clear text. With Captive Portals enabled in an SWG transparent type access profile, using a Logon Page with other types of authentication (AD Auth, LDAP Auth, or RADIUS Auth) in the access policy will also work to keep passwords secure.

LOgon Page + AD Auth password secure

Access policy that keeps passwords secure (with captive portals enabled)

About the iApp for Secure Web Gateway configuration

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).

About user identification with a logon page

User identification by IP address is a method that is available for these access profile types: SWG-Explicit, SWG-Transparent, and LTM-APM.

Note: Identify users by IP address only when IP addresses are unique and can be trusted.

To support this option, a logon page must be added to the access policy to explicitly identify users. The logon page requests user credentials and validates them to identify the users. For explicit forward proxy, a 407 response page is the appropriate logon page action. For transparent forward proxy, a 401 response page is the appropriate logon page action. For LTM-APM, the Logon Page action is appropriate.

Secure Web Gateway (SWG) maintains an internal mapping of IP addresses to user names.

About user identification with an F5 agent

Transparent user identification makes a best effort to identify users without requesting credentials. It is not authentication. It should be used only when you are comfortable accepting a best effort at user identification.

Transparent user identification is supported in Secure Web Gateway (SWG) configurations for either explicit or transparent forward proxy. An agent obtains data and stores a mapping of IP addresses to user names in an IF-MAP server. An F5® DC Agent queries domain controllers. An F5 Logon Agent runs a script when a client logs in and can be configured to run a script when the client logs out.

Note: Agents are available only on a BIG-IP® system with an SWG subscription.

In an access policy, a Transparent Identity Import item obtains the IP-address-to-username-mapping from the IF-MAP server. This item can be used alone for determining whether to grant access or be paired with another query to look up the user or validate user information.

To support this option, either the F5 DC Agent or the F5 Logon Agent must be downloaded, installed, and configured.

Creating a VLAN for transparent forward proxy

You need a VLAN on which the forward proxy can listen. For increased security, the VLAN should directly face your clients.
  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.
The new VLAN appears in the VLAN list.

Assigning a self IP address to a VLAN

Assign a self IP address to a VLAN on which the forward proxy listens.
  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 network mask for the specified IP address.

    For example, you can type 255.255.255.0.

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

Creating an access profile for SWG transparent forward proxy

You create an access profile to provide the access policy configuration for a virtual server that establishes a secured session.
  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.
    Note: After you complete this step, the User Identification Method is set to IP Address and cannot be changed.
    Additional settings display.
  5. To use NTLM authentication before a session starts, from the NTLM Auth Configuration list select a configuration.
    Important: For NTLM authentication to work, you must also enable the Captive Portals setting and specify an IP address in the Primary Authentication URI field for the virtual server that you configure for the captive portal.
    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.
  6. 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.
  7. 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.
  8. Click Finished.
    The Access Profiles list screen displays.
The access profile displays in the Access Profiles List. Default-log-setting is assigned to the access profile.

Verifying log settings for the access profile

Confirm that the correct log settings are selected for the access profile to ensure that events are logged as you intend.
Note: Log settings are configured in the Access Policy Event Logs area of the product. They enable and disable logging for access system and URL request filtering events. Log settings also specify log publishers that send log messages to specified destinations.
  1. On the Main tab, click Access Policy > Access Profiles .
    The Access Profiles List screen opens.
  2. Click the name of the access profile that you want to edit.
    The properties screen opens.
  3. On the menu bar, click Logs.
    The access profile log settings display.
  4. Move log settings between the Available and Selected lists.
    You can assign up to three log settings that enable access system logging to an access profile. You can assign additional log settings to an access profile provided that they enable logging for URl request logging only.
    Note: Logging is disabled when the Selected list is empty.
  5. Click Update.
An access profile is in effect when it is assigned to a virtual server.

Configuring an access policy for transparent forward proxy

You configure an access policy for Secure Web Gateway (SWG) transparent forward proxy to populate session variables with group or class attribute information for use in the per-request policy. You can also add access policy items to collect credentials and to authenticate a user, or you can add items to transparently identify the user without requesting credentials.
Note: If you include authentication in your access policy and the first site that a user accesses uses HTTP instead of secure HTTP, passwords are passed as clear text. To prevent this from happening, F5® recommends using Kerberos or NTLM authentication.
  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. To add Kerberos authentication to the access policy, add these actions in order: HTTP 401 Response, Variable Assign, and Kerberos Auth using 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. On the Assignment tab, select Variable Assign and click Add Item.
      For Kerberos authentication to work correctly with SWG transparent forward proxy, you must assign the virtual server proxy domain name to a session variable.
    6. Click Add new entry.
      An empty entry appears in the Assignment table.
    7. Click the change link in the new entry.
      A popup screen opens.
    8. In the left pane, retain the selection of Custom Variable and type this variable name: session.server.network.name.
    9. In the right pane, in place of Custom Variable, select Text and type the domain name for the proxy virtual server.
    10. Click Finished.
      The popup screen closes.
    11. Click Save.
      The properties screen closes. The visual policy editor displays.
    12. On an access policy branch, click the plus symbol (+) to add an item to the access policy.
    13. Type ker in the search field, select Kerberos Auth from the results, and click Add Item.
      A properties screen opens.
    14. From the AAA Server list, select an existing server.
    15. From the Request Based Auth list, select Disabled.
    16. Click Save.
      The properties screen closes and the visual policy editor displays.
    Note: The Max Logon Attempts Allowed setting specifies attempts by an external client without a Kerberos ticket to authenticate on forward proxy.
  5. To identify a user transparently using information provided by a BIG-IP® user identification agent, perform these substeps:
    For this step of the access policy to succeed, you must have installed and configured either the F5® DC Agent or the F5 Logon Agent. Either agent is supported on a BIG-IP system with an SWG subscription only.
    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.
  6. 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.
  7. 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.
  8. 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.
  9. Click the Apply Access Policy link to apply and activate the changes to the access policy.
To apply this access policy to network traffic, add the access profile to a virtual server.
Note: To ensure that logging is configured to meet your requirements, verify the log settings for the access profile.

Creating a custom Client SSL forward proxy profile

Creating a Client SSL forward proxy profile makes it possible for client and server authentication, while still allowing the BIG-IP® system to perform data optimization, such as decryption and encryption. This profile applies to client-side SSL forward proxy traffic only.

  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.
The custom Client SSL forward proxy profile now appears in the Client SSL profile list screen.

Creating a custom Server SSL profile

Create a custom server SSL profile to support SSL forward proxy.
  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.
The custom Server SSL profile is now listed in the SSL Server profile list.

Creating a virtual server for forward proxy SSL traffic

You configure a virtual server to handle SSL web traffic.
  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 VLAN and Tunnel Traffic setting, retain the default value All VLANs and Tunnels list.
  11. From the Source Address Translation list, select Auto Map.
  12. For the Address Translation setting, clear the Enabled check box.
  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. If you are using a captive portal and the per-request policy that you configured earlier includes application filtering, perform these substeps:
    1. From the Classification list, select Enabled.
    2. Scroll down to the Resources area.
    3. For Policies, make sure that sys_CEC_video_policy is enabled.
    Note: The per-request policy uses application filtering when it runs an Application Lookup action.
  15. Click Finished.
The virtual server now appears in the Virtual Server List screen.

Creating a virtual server for forward proxy traffic

You configure a virtual server to handle web traffic going to port 80.
  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 Configuration list, select Advanced.
  7. From the HTTP Profile list, select http.
  8. For the VLAN and Tunnel Traffic setting, retain the default value All VLANs and Tunnels list.
  9. From the Source Address Translation list, select Auto Map.
  10. For the Address Translation setting, clear the Enabled check box.
  11. If the per-request policy that you configured earlier includes application filtering, perform these substeps:
    1. From the Classification list, select Enabled.
    2. Scroll down to the Resources area.
    3. For Policies, make sure that sys_CEC_video_policy is enabled.
    Note: The per-request policy uses application filtering when it runs an Application Lookup action.
  12. In the Access Policy area, from the Access Profile list, select the access profile that you configured earlier.
  13. From the Per-Request Policy list, select the per-request policy that you configured earlier.
  14. Click Finished.
The virtual server now appears in the Virtual Server List screen.

Creating a Client SSL profile for a captive portal

You create a Client SSL profile when you want the BIG-IP® system to authenticate and decrypt/encrypt client-side application traffic. You create this profile if you enabled Captive Portals in the access profile and if you want to use SSL.

  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.
After creating the Client SSL profile and assigning the profile to a virtual server, the BIG-IP system can apply SSL security to the type of application traffic for which the virtual server is configured to listen.

Creating a virtual server for a captive portal

You configure a virtual server to use as a captive portal if you enabled the Captive Portals setting in the access profile.
Note: If you do not plan to use client-side SSL, select a service port other than 443 and do not select an SSL client profile.
  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 Configuration list, select Advanced.
  7. From the HTTP Profile list, select http.
  8. For the SSL Profile (Client) setting, move the profile you configured previously from the Available list to the Selected list.
  9. Scroll down to the Access Policy area.
  10. From the Access Profile list, select the access profile you configured previously.
  11. Click Finished.
The virtual server appears in the Virtual Server List screen.

Implementation result

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 read session variables

This table lists per-request policy items that read session variables and lists the access policy items that populate the variables.

Per-request policy item Session variable Access policy item
AD Group Lookup session.ad.last.attr.primaryGroupID AD Query
LDAP Group Lookup session.ldap.last.attr.memberOf LDAP Query
LocalDB Group Lookup session.localdb.groups
Note: This session variable is a default in the expression for LocalDB Group Lookup; any session variable in the expression must match the session variable used in the Local Database action in the access policy.
Local Database
RADIUS Class Lookup session.radius.last.attr.class RADIUS Auth

About redirects after access denied by captive portal

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. 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. 

POST  https://bigip-master.com/my.policy?ORIG_URI=http://berkeley.edu/index.html
302   http://berkeley.edu/index.html

GET   http://berkeley.edu/index.html
302   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 server 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.

Table of Contents | << Previous Chapter | Next Chapter >>
Contact Support Contact Support

Have a Question?

Support and Sales >

About F5

Education

F5 Sites

Support Tasks




©2023 F5 Networks, Inc. All rights reserved.


Trademarks Policies Privacy California Privacy Do Not Sell My Personal Information