Manual Chapter : LTM SSL Forward Proxy and Per-Request Policies

Applies To:

Show Versions Show Versions

BIG-IP APM

  • 14.1.2, 14.1.0
Manual Chapter

LTM SSL Forward Proxy and Per-Request Policies

Overview: Adding a per-request policy to LTM SSL forward proxy

If you have an LTM® SSL forward proxy configuration, you can add a per-request policy to it. Every time a client makes a URL request, the per-request policy runs. The policy can contain any available per-request policy action item, including those for URL and application categorization and filtering.
Complete these tasks before you start:
  • Configure any application filters that you want to use.
  • Configure any URL filters (and user-defined URL categories) that you want to use.
  • Configure a per-request policy.
  • Have an LTM SSL forward proxy configuration set up.

Creating an access profile for LTM-APM

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
    Profiles / Policies
    .
    The Access Profiles (Per-Session Policies) screen opens.
  2. Click
    Create
    .
    The New Profile screen opens.
  3. In the
    Name
    field, type a name for the access profile.
    A access profile name must be unique among all access profile and any per-request policy names.
  4. From the
    Profile Type
    list, select
    LTM-APM
    .
    Additional settings display.
  5. 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.
  6. Click
    Finished
    .
    This creates an access profile with a default access policy.
The access profile displays in the Access Profiles List. Default-log-setting is assigned to the access profile.
You can configure the access policy further but you are not required to do so.

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.
Log settings are configured in the
Access
Overview
Event Log
Settings
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
    Profiles / Policies
    .
    The Access Profiles (Per-Session Policies) 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.
    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.

Creating a per-request policy

You must create a per-request policy before you can configure it in the visual policy editor.
  1. On the Main tab, click
    Access
    Profiles / Policies
    Per-Request Policies
    .
    The Per-Request Policies screen opens.
  2. Click
    Create
    .
    The General Properties screen opens.
  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.

Processing SSL traffic in a per-request policy

To use SSL forward proxy bypass in a per-request policy, both the server and client SSL profile must enable SSL forward proxy and SSL forward proxy bypass; and, in the client SSL profile, the default bypass action must be set to
Intercept
.
Configure a per-request policy so that it completes processing of HTTPS requests before it starts the processing of HTTP requests.
These steps describe how to add items for controlling SSL web traffic to a per-request policy; the steps do not specify a complete per-request policy.
  1. On the Main tab, click
    Access
    Profiles / Policies
    Per-Request Policies
    .
    The Per-Request Policies screen opens.
  2. In the
    Name
    field, locate the policy that you want to update, then in the
    Per-Request Policy
    field, click the
    Edit
    link.
    The visual policy editor opens in another tab.
  3. To process the HTTPS traffic first, configure a branch for it by adding a
    Protocol Lookup
    item at the start of the per-request policy.
    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. In the Search field, type
      prot
      , select
      Protocol Lookup
      , and click
      Add Item
      .
      A properties popup screen opens.
    3. Click
      Save
      .
      The properties screen closes. The policy displays.
    The Protocol Lookup item provides two default branches: HTTPS for SSL traffic and fallback.
  4. Before you add an SSL Bypass Set, or an SSL Intercept Set, item to the per-request policy, you can insert any of the following policy items to do logging or to base how you process the SSL traffic on group membership, class attribute, day of the week, time of day, or URL category:
    • AD Group Lookup
    • LDAP Group Lookup
    • LocalDB Group Lookup
    • RADIUS Class Lookup
    • Dynamic Date Time
    • Logging
    • Category Lookup
      Category Lookup is valid for processing SSL traffic only when configured for SNI or Subject.CN categorization input and only before any HTTP traffic is processed.
    If you insert other policy items that inspect the SSL payload (HTTP data) before an SSL Bypass Set item, the SSL bypass cannot work as expected.
  5. At any point on the HTTPS branch where you decide to bypass SSL traffic, add an
    SSL Bypass Set
    item.
The per-request policy includes items that you can use to complete the processing of SSL traffic. Add other items to the policy to control access according to your requirements.
A per-request policy goes into effect when you add it to a virtual server. Depending on the forward proxy configuration, you might need to add the per-request policy to more than one virtual server.

Configuring policies to branch by local database user group

If you plan to look up local database groups from the per-request policy, you must configure local database-related items in the access policy and the per-request policy to use the same session variable.
  1. On the Main tab, click
    Access
    Profiles / Policies
    .
    The Access Profiles (Per-Session Policies) screen opens.
  2. In the Per-Session Policy column, click the
    Edit
    link for the access profile you want to configure.
    The visual policy editor opens the access policy in a separate screen.
  3. On a policy branch, click the
    (+)
    icon to add an item to the policy.
    A popup screen displays actions on tabs, such as General Purpose and Authentication, and provides a search field.
  4. In the search field, type
    local
    , select
    Local Database
    , and click
    Add Item
    .
    A popup properties screen opens.
  5. Configure properties for the Local Database action:
    1. From the
      LocalDB Instance
      list, select a local user database.
    2. Click
      Add new entry
      A new line is added to the list of entries with the Action set to
      Read
      and other default settings.
    3. In the
      Destination
      column in the
      Session Variable
      field, type the name of the variable in which to store the user groups retrieved from the local database.
      In the per-request policy, the default value that the LocalDB Group Lookup item uses is
      session.localdb.groups
      . If you enter a differentvalue, note it. You will need it to update the advanced expression in the LocalDB Group Lookup item in the per-request policy.
    4. In the
      Source
      column from the
      DB Property
      list, select
      groups
      .
    5. Click
      Save
      .
      The properties screen closes. The policy displays.
    This is not a complete access policy, but you can return to it and complete it later. You can close the visual policy editor or leave it open.
    The access policy includes a Local Database action that can read groups into a session variable.
  6. On the Main tab, click
    Access
    Profiles / Policies
    Per-Request Policies
    .
    The Per-Request Policies screen opens.
  7. In the
    Name
    field, locate the policy that you want to update, then in the
    Per-Request Policy
    field, click the
    Edit
    link.
    The visual policy editor opens in another tab.
  8. Click the
    (+)
    icon anywhere in the per-request policy to add a new item.
  9. In the search field, type
    local
    , select
    LocalDB Group Lookup
    , and click
    Add Item
    .
    A popup properties screen opens.
  10. Click the Branch Rules tab.
  11. Click the
    change
    link in the entry for the default expression.
    A popup screen opens.
  12. If the session variable you typed in the access policy Local Database action was
    session.localdb.groups
    , perform these substeps.
    1. In the
      User is a member of
      field, remove
      MY_GROUP
      and type the name of a group.
    2. Click
      Finished
      .
      The popup screen closes.
    3. Click
      Save
      .
      The properties screen closes and the policy displays.
  13. If you typed a session variable other than
    session.localdb.groups
    in the access policy Local Database action, perform these substeps.
    1. Click the Advanced tab.
      In the field, this expression displays.
      expression
      is
      expr
      { [
      mcget
      {
      session.localdb.groups
      }]
      contains
      "
      MY_GROUP
      " }
    1. In the expression, replace
      session.localdb.groups
      with the name of the session variable you typed into the Local Database action.
    2. In the expression, replace
      MY_GROUP
      with the name of a group that should match a local database group.
    3. Click
      Finished
      .
      The popup screen closes.
    4. Click
      Save
      .
      The properties screen closes and the policy displays.
    This is not a complete per-request access policy, but you can return to it and complete it later.
The access and per-request policies are configured to use the same session variable. The access policy is configured to support the use of LocalDB Group Lookup in the per-request policy.
Complete the configuration of the access and per-request policies.

Categorizing URLs using custom categories in a per-request policy

These steps apply to a BIG-IP system on which URL categories are available only by creating them in Access Policy Manager (APM).
If you haven't configured URL categories and URL filters yet in APM, configure them before you start this task.
Look up the category for a URL request and use it in a policy branch rule, or to assign a URL filter, and so on.
These steps provide guidance for adding items to control traffic based on the URL category; they do not specify a complete per-request policy.
  1. On the Main tab, click
    Access
    Profiles / Policies
    Per-Request Policies
    .
    The Per-Request Policies screen opens.
  2. In the
    Name
    field, locate the policy that you want to update, then in the
    Per-Request Policy
    field, click the
    Edit
    link.
    The visual policy editor opens in another tab.
  3. Add a
    Category Lookup
    item and set its properties:
    A Category Lookup item triggers event logging for URL requests and provides categories for a URL Filter Assign item.
    1. From the
      Categorization Input
      list, select an entry based on the type of traffic to be processed. .
      • For HTTP traffic, select
        Use HTTP URI (cannot be used for SSL Bypass decisions)
        .
      • For SSL-encrypted traffic, select
        Use SNI in Client Hello (if SNI is not available, use Subject.CN)
        .
      • Use Subject.CN in Server Cert
        is not supported for reverse proxy.
    2. For
      Category Lookup Type
      , you can only retain the default setting
      Process custom categories only
      .
    1. Click
      Save
      .
      The properties screen closes. The policy displays.
  4. To add a
    URL Filter Assign
    item, do so anywhere on a branch after a Category Lookup item.
    A URL filter applies to the categories that a Category Lookup item returns. If the filter specifies the
    Block
    action for any URL category, URL Filter Assign blocks the request.
    If URL Filter Assign does not block the request and the filter specifies the confirm action for any URL category, URL Filter Assign takes the
    Confirm
    per-request policy branch and the policy exits on the ending for it.
    1. From the
      URL Filter
      list, select a URL filter.
    2. To simplify the display in the visual policy editor if the URL filter does not specify confirm actions, select Branch Rules, and click
      x
      on the
      Confirm
      entry.
    3. Click
      Save
      .
      The properties screen closes and the policy displays.
Now the per-request policy includes an item that looks up the URL category. You can add other items to the policy to control access according to your requirements.
SSL bypass and SSL intercept are not supported when you are protecting internal resources from incoming requests. They are supported in a forward proxy configuration.
A per-request policy goes into effect when you add it to a virtual server.

Configuring a per-request policy to control access to applications

Access Policy Manager (APM) supports a preset group of application families and applications. You can configure your own application filters or use one of the filters that APM provides: block-all, allow-all, and default.
Configure a per-request policy to specify the logic that determines whether to allow access to the applications or application families.
This task provides the steps for adding items to control requests based on the application name or application family or based on an application filter. It does not specify a complete per-request policy.
  1. On the Main tab, click
    Access
    Profiles / Policies
    Per-Request Policies
    .
    The Per-Request Policies screen opens.
  2. In the
    Name
    field, locate the policy that you want to update, then in the
    Per-Request Policy
    field, click the
    Edit
    link.
    The visual policy editor opens in another tab.
  3. Add an
    Application Lookup
    item to the policy.
    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. From the General Purpose tab, select
      Application Lookup
      , and click
      Add Item
      .
      A Properties popup screen opens.
    3. Click
      Save
      .
      The Properties screen closes. The visual policy editor displays. A single branch, fallback, follows the
      Application Lookup
      item.
  4. To branch by application family or application name, add branch rules to the
    Application Lookup
    item.
    1. Click the name of the application lookup item.
      A Properties popup screen displays.
    2. Click the Branch Rules tab.
    3. Click
      Add Branch Rule
      .
      A new entry with
      Name
      and
      Expression
      settings displays.
    4. Click the
      change
      link in the new entry.
      A popup screen opens.
    5. Click the
      Add Expression
      button.
      Settings are displayed.
    6. For
      Agent Sel
      , select
      Application Lookup
      .
    7. For
      Condition
      select
      Application Family
      or
      Application Name
      .
    1. From the list,
      Application Family is
      or
      Application Name is
      , select a family or name.
    1. Click
      Add Expression
      .
      The expression displays.
    2. Continue adding branches and when you are done, click
      Finished
      .
      The popup screen closes. The Branch Rules popup screen displays.
    3. Click
      Save
      .
      The visual policy editor displays.
    Newly created branches follow the
    Application Lookup
    item.
  5. To apply an application filter to the request, add an
    Application Filter Assign
    item on a branch somewhere after the Application Lookup item.
    A Properties popup screen displays.
  6. From the
    Application Filter
    list, select an application filter and click
    Save
    .
    The popup screen closes.
To put the per-request policy into effect, add it to the virtual server.
To support application filtering, classification must be enabled on the virtual server.

Configuring a per-request policy to branch by group or class

Add a group or class lookup to a per-request policy when you want to branch by user group or class.
The access policy must be configured to populate session variables for a group or class lookup to succeed. This task provides the steps for adding items to branch by group or class. It does not specify a complete per-request policy.
  1. On the Main tab, click
    Access
    Profiles / Policies
    Per-Request Policies
    .
    The Per-Request Policies screen opens.
  2. In the
    Name
    field, locate the policy that you want to update, then in the
    Per-Request Policy
    field, click the
    Edit
    link.
    The visual policy editor opens in another tab.
  3. On a policy branch, click the
    (+)
    icon to add an item to the policy.
    The actions you can use for building a per-request policy are displayed on a popup screen with actions on tabs, such as Authentication, Classification, and General Purpose, and a search field.
  4. On the Authentication tab, select an option:
    AD Group Lookup
    ,
    LDAP Group Lookup
    , or
    RADIUS Class Lookup
    to the per-request policy.
  5. Click
    Add Item
    .
    A properties popup screen opens.
  6. Click the Branch Rules tab.
  7. To edit an expression, click the
    change
    link.
    An additional popup screen opens, displaying the Simple tab.
  8. Edit the default simple expression to specify a 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.
  9. Click
    Finished
    .
    The popup screen closes.
  10. Click
    Save
    .
    The popup screen closes. The visual policy editor displays.
A per-request policy goes into effect when you add it to a virtual server.

Creating a DNS resolver

You configure a DNS resolver to resolve DNS queries and cache the responses. The next time the system receives a query for a response that exists in the cache, the system returns the response from the cache.
  1. On the Main tab, click
    Network
    DNS Resolvers
    DNS Resolver List
    .
    The DNS Resolver List screen opens.
  2. Click
    Create
    .
    The New DNS Resolver screen opens.
  3. In the
    Name
    field, type a name for the resolver.
  4. Click
    Finished
    .
When you create an OAuth Server, creating a DNS Resolver with a forward zone named . (period) is mandatory to forward all requests.

Adding forward zones to a DNS resolver

Before you begin, gather the IP addresses of the nameservers that you want to associate with a forward zone.
Add a forward zone to a DNS resolver when you want the BIG-IP system to forward queries for particular zones to specific nameservers for resolution in case the resolver does not contain a response to the query.
Creating a forward zone is optional. Without one, a DNS resolver can still make recursive name queries to the root DNS servers; the virtual servers using the cache must have a route to the Internet.
When you create an OAuth Server, creating a DNS Resolver with a forward zone named . (period) is mandatory.
  1. On the Main tab, click
    Network
    DNS Resolvers
    DNS Resolver List
    .
    The DNS Resolver List screen opens.
  2. Click the name of the resolver you want to modify.
    The properties screen opens.
  3. On the menu bar, click
    Forward Zones
    .
    The Forward Zones screen displays.
  4. Click the
    Add
    button.
    You add more than one zone to forward based on the needs of your organization.
  5. In the
    Name
    field, type the name of a subdomain or type the fully qualified domain name (FQDN) of a forward zone.
    To forward all requests (such as when creating an OAuth server), specify . (period) as the name.
    For example, either
    example
    or
    site.example.com
    would be valid zone names.
  6. Add one or more nameservers:
    1. In the
      Address
      field, type the IP address of a DNS nameserver that is considered authoritative for this zone.
      Based on your network configuration, add IPv4 or IPv6 addresses, or both.
    2. Click
      Add
      .
      The address is added to the list.
    The order of nameservers in the configuration does not impact which nameserver the system selects to forward a query to.
  7. Click
    Finished
    .

Adding a DNS resolver to the http-explicit profile

An HTTP profile defines the way that you want the BIG-IPsystem to manage HTTP traffic.
APM provides a default
http-explicit
profile for Secure Web Gateway (SWG) explicit forward proxy. You must add a DNS resolver to the profile.
  1. On the Main tab, click
    Local Traffic
    Profiles
    Services
    HTTP
    .
    The HTTP profile list screen opens.
  2. Click the
    http-explicit
    link.
    The Properties screen displays.
  3. Scroll down to the Explicit Proxy area.
  4. From the
    DNS Resolver
    list, select the DNS resolver you configured previously.
  5. Ensure that you retain the default values for the
    Tunnel Name
    and
    Default Connect Handling
    fields.
    The default value for
    Tunnel Name
    is
    http-tunnel
    . The default value for
    Default Connect Handling
    is
    Deny
    .
  6. Click
    Finished
    .

Updating the virtual server for SSL forward proxy

To add per-request processing to an LTM SSL forward proxy configuration, associate the access profile, custom HTTP profile, and per-request policy with the virtual server.
  1. On the Main tab, click
    Local Traffic
    Virtual Servers
    .
    The Virtual Server List screen opens.
  2. Click the name of the virtual server that is configured for LTM SSL forward proxy.
    SSL client and server profiles that are configured specifically for SSL forward proxy are associated with this virtual server.
  3. From the
    HTTP Profile
    list, select
    http-explicit
    .
  4. From the
    HTTP Profile
    list, select the HTTP profile you configured earlier.
  5. In the Access Policy area, from the
    Access Profile
    list, select the access profile that you configured earlier.
  6. From the
    Per-Request Policy
    list, select the per-request policy that you configured earlier.
  7. Click
    Update
    .
The access policy and per-request policy are now associated with the virtual server.

Example policy: SSL forward proxy bypass

SSL bypass decision based on group membership and URL category
policy with protocol lookup, group lookup, category lookup, and ssl bypass set
1
SSL traffic exits on the HTTPS branch of Protocol Lookup.
2
A lookup type item, such as LocalDB Group Lookup, identifies users in a group, Directors.
3
With SSL Bypass Set, any SSL request on the Directors branch is not intercepted or inspected.
4
Category Lookup processes HTTPS traffic when configured to use SNI or Subject.CN input.
Finance or Govt is a standard URL category that SWG maintains on a system with an SWG subscription. User-defined URL categories can provide an alternative on systems without an SWG subscription.
5
For users in a group other than Directors, bypass only requests that contain private information (determined through Category Lookup).
6
SSL traffic processing is complete. Now is the time to start processing HTTP data with actions that inspect the SSL payload. Using data provided by Category Lookup, URL Filter Assign item determines whether to allow or block traffic.
(For this example to be valid, both the server and client SSL profiles on the virtual server must enable SSL forward proxy and SSL forward proxy bypass; the client SSL profile must set the default bypass action to
Intercept
.)

Overview: SSL forward proxy client and server authentication

With the BIG-IP® system's
SSL forward proxy
functionality, you can encrypt all traffic between a client and the BIG-IP system, by using one certificate, and to encrypt all traffic between the BIG-IP system and the server, by using a different certificate.
A client establishes a three-way handshake and SSL connection with the wildcard IP address of the BIG-IP system virtual server. The BIG-IP system then establishes a three-way handshake and SSL connection with the server, and receives and validates a server certificate (while maintaining the separate connection with the client). The BIG-IP system uses the server certificate to create a second unique server certificate to send to the client. The client receives the second server certificate from the BIG-IP system, but recognizes the certificate as originating directly from the server.
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.
A virtual server configured with Client and Server SSL profiles for SSL forward proxy functionality
A virtual server configured with Client and Server SSL profiles for SSL forward proxy     functionality
  1. Client establishes three-way handshake and SSL connection with wildcard IP address.
  2. BIG-IP system establishes three-way handshake and SSL connection with server.
  3. BIG-IP system validates a server certificate (Certificate A), while maintaining the separate connection with the client.
  4. BIG-IP system creates different server certificate (Certificate B) and sends it to client.

Task summary for SSL Forward Proxy on a single BIG-IP system

To implement SSL forward proxy client-to-server authentication, as well as application data manipulation, you perform a few basic configuration tasks. Note that you must create both a Client SSL and a Server SSL profile, and enable the SSL Forward Proxy feature in both profiles.

Creating a custom Client SSL forward proxy profile

You perform this task to create a Client SSL forward proxy profile that 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 SSL 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. From the
    SSL Forward Proxy
    list, select
    Advanced
    .
  6. Select the
    Custom
    check box for the SSL Forward Proxy area.
  7. Modify the SSL Forward Proxy settings.
    1. From the
      SSL Forward Proxy
      list, select
      Enabled
      .
    2. From the
      CA Certificate
      list, select a certificate.
      If the BIG-IP system is part of a DSC Sync-Failover group, always select a non-default certificate name, and ensure that this same certificate name is specified in every instance of this SSL profile in the device group. Taking these actions helps to ensure that SSL handshakes are successful after a failover event.
    3. From the
      CA Key
      list, select a key.
      If the BIG-IP system is part of a DSC Sync-Failover group, always select a non-default key name, and ensure that this same key name is specified in every instance of this SSL profile in the device group. Taking these actions helps to ensure that SSL handshakes are successful after a failover event.
    4. In the
      CA Passphrase
      field, type a passphrase.
    5. In the
      Confirm CA Passphrase
      field, type the passphrase again.
    6. In the
      Certificate Lifespan
      field, type a lifespan for the SSL forward proxy certificate in days.
    7. From the
      Certificate Extensions
      list, select
      Extensions List
      .
    8. 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.
    9. Select the
      Cache Certificate by Addr-Port
      check box if you want to cache certificates by IP address and port number.
    10. From the
      SSL Forward Proxy Bypass
      list, select
      Enabled
      .
      Additional settings display.
    11. From the
      Bypass Default Action
      list, select
      Intercept
      or
      Bypass
      .
      The default action applies to addresses and hostnames that do not match any entry specified in the lists that you specify. The system matches traffic first against destination IP address lists, then source IP address lists, and lastly, hostname lists. Within these, the default action also specifies whether to search the intercept list or the bypass list first.
      If you select
      Bypass
      and do not specify any additional settings, you introduce a security risk to your system.
  8. Click
    Finished
    .
The custom Client SSL forward proxy profile now appears in the Client SSL profile list screen.

Creating a custom Server SSL forward proxy profile

You perform this task to create a Server SSL forward proxy profile that 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 server-side SSL forward proxy traffic only.
  1. On the Main tab, click
    Local Traffic
    Profiles
    SSL
    Server
    .
    The Server SSL 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. From the
    Parent Profile
    list select
    serverssl
    .
  5. Select the
    Custom
    check box for the Configuration area.
  6. From the
    SSL Forward Proxy
    list, select
    Enabled
    .
  7. Click
    Finished
    .
The custom Server SSL forward proxy profile now appears in the Server SSL profile list screen.

Creating a load balancing pool

Ensure that at least one virtual server exists in the configuration before you start to create a load balancing pool.
Create a pool of systems with Access Policy Manager to which the system can load balance global traffic.
  1. On the Main tab, click
    DNS
    GSLB
    Pools
    .
    The Pool List screen opens.
  2. Click
    Create
    .
    The New Pool screen opens.
  3. In the General Properties area, in the
    Name
    field, type a name for the pool.
    Names must begin with a letter, and can contain only letters, numbers, and the underscore (_) character.
    The pool name is limited to 63 characters.
  4. From the
    Type
    list, depending on the type of the system (IPv4 or IPv6), select either an
    A
    or
    AAAA
    pool type.
  5. In the Configuration area, for the
    Health Monitors
    setting, in the
    Available
    list, select a monitor type, and move the monitor to the
    Selected
    list.
    Hold the Shift or Ctrl key to select more than one monitor at a time.
  6. In the Members area, for the
    Load Balancing Method
    settings, select a method that uses virtual server score:
    • VS Score - If you select this method, load balancing decisions are based on the virtual server score only.
    • Quality of Service - If you select this method, you must configure weights for up to nine measures of service, including
      VS Score
      . Virtual server score then factors into the load balancing decision at the weight you specify.
  7. For the
    Member List
    setting, add virtual servers as members of this load balancing pool.
    The system evaluates the virtual servers (pool members) in the order in which they are listed. A virtual server can belong to more than one pool.
    1. Select a virtual server from the
      Virtual Server
      list.
    2. Click
      Add
      .
  8. Click
    Finished
    .

Creating a virtual server for client-side and server-side SSL traffic

You can specify a virtual server to be either a host virtual server or a network virtual server to manage application traffic.
  1. On the Main tab, click
    Local Traffic
    Virtual Servers
    .
    The Virtual Server List screen opens.
  2. Click
    Create
    .
    The New Virtual Server screen opens.
  3. In the
    Name
    field, type a unique name for the virtual server.
  4. For a network, in the
    Destination Address
    field, type an IPv4 or IPv6 address in CIDR format to allow all traffic to be translated.
    The supported format is address/prefix, where the prefix length is in bits. For example, an IPv4 address/prefix is
    0.0.0.0/0
    , and an IPv6 address/prefix is
    ::/0
    .
  5. In the
    Service Port
    field:
    • If you want to specify a single service port or all ports, confirm that the
      Port
      button is selected, and type or select a service port.
    • If you want to specify multiple ports other than all ports, select the
      Port List
      button, and confirm that the port list that you previously created appears in the box.
  6. 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.
    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.
  7. 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.
    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.
  8. Assign other profiles to the virtual server if applicable.
  9. In the Resources area, from the
    Default Pool
    list, select the name of the pool that you created previously.
  10. Click
    Finished
    .
The virtual server now appears in the Virtual Server List screen.

Implementation result

After you complete the tasks in this implementation, the BIG-IP® system ensures that the client system and server system can authenticate each other independently. After client and server authentication, the BIG-IP system can intelligently decrypt and manipulate the application data according to the configuration settings in the profiles assigned to the virtual server.