Updated Date: 05/07/2026
Integrating Application Access and Secure Web Gateway
Access Policy Manager® (APM®) can be configured to act as a transparent forward proxy to support remote clients that connect using application access, network access, or portal access.
Note: Using a distinct APM transparent forward proxy configuration to process traffic from remote clients separately from a forward proxy configuration used for processing traffic from internal clients provides an important measure of network security.
-
Create a wildcard virtual server for HTTP traffic on the connectivity interface
-
Create a wildcard virtual server for SSL traffic on the connectivity interface
Before you start to create an Access Policy Manager (APM®) transparent forward proxy configuration to support remote access clients, you must have completed these tasks.
- You must have a working Network Access, Portal Access, or Application Access configuration.
- You need a per-request policy configured for forward proxy.
- On a BIG-IP system with an SWG subscription, you must ensure that the URL database is downloaded. You can also configure any URL filters that you want to use in addition to, or instead of, the default URL filters.
- On a BIG-IP system without an SWG subscription, if you want to designate only a few URLs for specific handling, you probably do not need to configure user-defined URL categories and filters. However, if you need to control access to many URLs, for better performance and ease-of-use you should configure user-defined URL categories and filters.
Tasks for integrating an Access Policy Manager (APM®) remote access configuration with a transparent forward proxy configuration for APM follow this order.
- First, update the existing application access, network access, or portal access configuration to add a secure connectivity profile to the virtual server if one is not already specified.
- Next, create a transparent forward proxy configuration for APM. The per-request policy is part of this configuration.
- Finally, update the access policy in the existing application access, network access, or portal access configuration if needed. If the per-request policy uses group or class lookup items, add queries to the access policy to populate the session variables on which the lookup items rely.
You create a connectivity profile to configure client connections.
-
On the Main tab, click Access > Connectivity / VPN > Connectivity > Profiles.
A list of connectivity profiles displays.
-
Click Add.
The Create New Connectivity Profile popup screen opens and displays General Settings.
-
Type a Profile Name for the connectivity profile.
-
Select a Parent Profile from the list.
APM provides a default profile, /Common/connectivity.
-
Click OK.
The popup screen closes, and the Connectivity Profile List displays.
The connectivity profile displays in the list.
Update a virtual server that is part of an Access Policy Manager application access, network access, or portal access configuration to enable a secure connectivity interface for traffic from the client.
-
On the Main tab, click Local Traffic > Virtual Servers.
The Virtual Server List screen opens.
-
Click the name of the virtual server you want to modify.
-
Scroll down to the Access Policy area.
-
From the Connectivity Profile list, select the connectivity profile.
-
Click Update to save the changes.
You create an access profile to provide the access policy configuration for a virtual server that establishes a secured session.
-
On the Main tab, click Access > Profiles / Policies > Access Profiles (Per-Session Policies).
The Access Profiles (Per-Session Policies) screen displays.
-
Click Create.
The New Profile screen displays.
-
In the Name field, type a name for the access profile.
Note: An access profile name should be unique among all per-session profile and per-request policy names.
-
From the Profile Type list, select SWG-Transparent. Additional settings display.
-
From the Profile Scope list, select the required profile criteria. Default is Profile.
- Profile: Gives an user access only to resources that are behind the same access profile. This is the default value.
- Virtual Server: Gives an user access only to resources that are behind the same virtual server.
- Global: Gives an user access to resources behind any access profile that has global scope.
- Named: Gives an SSL Orchestrator user access to resources behind any access profile that has global scope.
-
From the Customization Type list, select the required page style for an access profile. Default is Modern. Available options are Modern and Standard. You can also use Standard but Modern customization is simpler and provides better compatibility for modern cross-platform and cross-device applications.
-
In the Settings area, click the Custom checkbox to enable the options. Configure the available options as applicable.
-
In the Configurations area, configure the following parameters:
-
When SWG-Transparent profile type is selected, the User Identification Method option is selected as IP address and remains unchanged.
-
IP Address: Use this option only in an environment where a client IP address is unique and can be trusted, typically, in an internal network. This option is not for use with internal NAT or shared systems. In the case of a shared machine, an IP address might already be associated with a user or a session. Using Kerberos or 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 a shared machine. Selecting this option ignores the existing cookies.
When IP address is selected, the default authentication type is set as None and the NTLM auth configuration and Kerberos auth configuration are optional.
-
-
From the Authentication type list, select the required authentication type from the list. Available options are NTLM Only, Kerberos Only, Both, and None.
-
From the NTLM Auth Configuration list, select the required NTLM auth configuration object from the list. Default is None.
-
From the Kerberos Auth Configuration list, select the required Kerbreos auth configuration object from the list. Default is None.
-
-
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.
-
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.comin the field. -
In the Language Settings area, add and remove accepted languages, and set the default language.
If any browser language does not match with the accepted languages list, the browser uses the default language.
-
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.
You do not need to add any actions or make any changes to the access policy.
Before you begin, you need to know the name of the connectivity profile specified in the virtual server for the remote access configuration that you want Access Policy Manager (APM) to protect.
You configure a virtual server to process web traffic on the secure connectivity interface for a remote access client.
-
On the Main tab, click Local Traffic > Virtual Servers.
The Virtual Server List screen opens.
-
Click Create.
The New Virtual Server screen opens.
-
In the Name field, type a unique name for the virtual server.
-
In the Destination Address/Mask field, type
0.0.0.0to accept any IPv4 traffic. -
In the Service Port field, type
80, or select HTTP from the list. -
From the Configuration list, select Advanced.
-
From the HTTP Profile (Client) list, select a previously-created HTTP/2 profile for client-side traffic.
-
Scroll down to the VLAN and Tunnel Traffic setting and select Enabled on.
-
For the VLANs and Tunnels setting, move the secure connectivity interface to the Selected list.
-
From the Source Address Translation list, select Auto Map.
-
Scroll down to the Port Translation setting and clear the Enabled check box.
-
In the Access Policy area, from the Access Profile list, select the access profile that you configured earlier.
-
In the Access Policy area, from the Per-Request Policy list, select the policy that you configured earlier.
-
Click Finished.
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.
-
On the Main tab, click Local Traffic > Profiles > SSL > Client.
The Client SSL profile list screen opens.
-
Click Create.
The New Client SSL Profile screen opens.
-
In the Name field, type a unique name for the profile.
-
From the Parent Profile list, select clientssl.
-
From the SSL Forward Proxy list, select Advanced.
-
Select the Custom check box for the SSL Forward Proxy area.
-
Modify the SSL Forward Proxy settings.
-
From the SSL Forward Proxy list, select Enabled.
-
From the CA Certificate list, select a certificate.
Important: 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.
-
From the CA Key list, select a key.
Important: 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.
-
In the CA Passphrase field, type a passphrase.
-
In the Confirm CA Passphrase field, type the passphrase again.
-
In the Certificate Lifespan field, type a lifespan for the SSL forward proxy certificate in days.
-
From the Certificate Extensions list, select Extensions List.
-
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.
-
Select the Cache Certificate by Addr-Port check box if you want to cache certificates by IP address and port number.
-
From the SSL Forward Proxy Bypass list, select Enabled.
Additional settings display.
-
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.
Note: If you select Bypass and do not specify any additional settings, you introduce a security risk to your system.
-
-
For detailed information on the different settings of the SSL:Client page, refer to the SSL Traffic Management chapter (Create a custom Client SSL profile section) of the SSL Administration guide.
-
Click Finished.
Create a custom server SSL profile to support SSL forward proxy.
-
On the Main tab, click Local Traffic > Profiles > SSL > Server.
The Server SSL profile list screen opens.
-
Click Create.
The New Server SSL Profile screen opens.
-
In the Name field, type a unique name for the profile.
-
For Parent Profile, retain the default selection, serverssl.
-
From the Configuration list, select Advanced.
-
Select the Custom check box.
The settings become available for change.
-
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.
-
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.
-
Scroll down to the Secure Renegotiation list and select Request.
-
For detailed information on the different settings of the SSL:Server page, refer to the SSL Traffic Management chapter (Create a custom Server SSL profile section) of the SSL Administration guide.
-
Click Finished.
Before you begin, you need to know the name of the connectivity profile specified in the virtual server for the remote access configuration that you want Secure Web Gateway (SWG) to protect. Also, if you do not have existing client SSL and server SSL profiles that you want to use, configure them before you start.
You configure a virtual server to process SSL web traffic coming in on the secure connectivity interface for a remote access client.
-
On the Main tab, click Local Traffic > Virtual Servers.
The Virtual Server List screen opens.
-
Click Create.
The New Virtual Server screen opens.
-
In the Name field, type a unique name for the virtual server.
-
In the Destination Address/Mask field, type
0.0.0.0to accept any IPv4 traffic. -
In the Service Port field, type
443or select HTTPS from the list. -
From the Configuration list, select Advanced.
-
From the HTTP Profile (Client) list, select a previously-created HTTP/2 profile for client-side traffic.
-
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.
-
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.
-
Scroll down to the VLAN and Tunnel Traffic setting and select Enabled on.
-
For the VLANs and Tunnels setting, move the secure connectivity interface to the Selected list.
-
From the Source Address Translation list, select Auto Map.
-
Scroll down to the Port Translation setting and clear the Enabled check box.
-
For the Address Translation setting, clear the Enabled check box.
-
In the Access Policy area, from the Access Profile list, select the access profile that you configured earlier.
-
In the Access Policy area, from the Per-Request Policy list, select the policy that you configured earlier.
-
Click Finished.
Add queries to the access policy to populate any session variables that are required for successful execution of the per-request policy.
Note: Class lookup or group lookup items in a per-request policy rely on session variables that can only be populated in this access policy.
-
On the Main tab, click Access > Profiles / Policies > Access Profiles (Per-Session Policies).
The Access Profiles (Per-Session Policies) screen displays.
-
Click the name of the access profile that you want to edit.
The properties screen opens.
-
In the General Properties area, click the Edit Access Policy for Profile profile_name link.
The visual policy editor opens the access policy in a separate screen.
-
Click the (+) icon anywhere in the access policy to add a new 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.
-
To supply LDAP group information for use in the per-request policy, add an LDAP Query item anywhere in the policy and configure its properties:
-
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.
-
Specify the SearchDN, and SearchFilter settings.
SearchDN is the base DN from which the search is done.
-
Click Save.
This item populates the session.ldap.last.attr.memberOf session variable.
-
-
To supply Active Directory groups for use in the per-request policy, add an AD Query item anywhere in the policy and configure its properties:
-
From the Server list, select an AAA AD server.
-
Select the Fetch Primary Group check box.
The value of the primary user group populates the session.ad.last.attr.primaryGroupID session variable.
-
Click Save.
-
-
To supply RADIUS class attributes for use in the per-request policy, add a RADIUS Auth item anywhere in the policy and configure its properties:
-
From the Server list, select an AAA RADIUS server.
-
Click Save.
This item populates the session.radius.last.attr.class session variable.
-
-
To supply local database groups for use in the per-request policy, add a Local Database item anywhere in the policy and configure its properties:
-
From the LocalDB Instance list, select a local user database.
-
In the User Name field, retain the default session variable.
-
Click Add new entry
A new line is added to the list of entries with the Action set to Read and other default settings.
-
In the Destination column Session Variable field, type
session.localdb.groups.If you type a name other than
session.localdb.groups, note it. You will need it when you configure the per-request access policy. -
In the Source column from the DB Property list, select groups.
-
Click Save.
This item populates the session.localdb.groups session variable.
-
The access policy is configured to support the per-request policy.
Click the Apply Access Policy link to apply and activate your changes to this access policy.
Note: To ensure that logging is configured to meet your requirements, verify the log settings for the access profile.
When you configure the BIG-IP system so that Access Policy Manager (APM) can act as a transparent forward proxy for use by remote access clients, you might want to understand how these objects fit into the overall configuration.
- Secure connectivity interface
- In a remote access configuration, a connectivity profile is required on the virtual server to specify a secure connectivity interface for traffic from the client. In the APM configuration, wildcard virtual servers must listen on the secure connectivity interface for traffic from remote access clients.
- Per-request policy
- In any APM forward proxy configuration, the determination of whether a user can access a URL must be made in a per-request access policy. A per-request access policy determines whether to block or allow access to a request based on time or date or group membership or other criteria that you configure.
- Access policies
- The access policy in the remote access configuration continues to authenticate users, assign resources, and evaluate ACLs, if any. In addition, this access policy must populate any session variables used in the per-request policy. An access profile of the SWG-Transparent type is required; however, it is not necessary to include any items in the access policy.
This table lists some of the many per-request policy items that read session 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 |