Applies To:
Show VersionsBIG-IP APM
- 11.5.10, 11.5.9, 11.5.8, 11.5.7, 11.5.6, 11.5.5, 11.5.4, 11.5.3, 11.5.2, 11.5.1
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.
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. SWG identifies users without using session management cookies, and applies a scheme that categorizes and filters URLs, controlling access.
Before you begin
To use SWG, you must configure URL categorization. You might need to configure additional items depending on the other features that you decide to use.
- URL categorization
- To get a working SWG configuration, you must first download URL categories, configure URL filters, and configure schemes.
- Transparent user identification
- If you plan to identify users transparently, you must first download, install, and configure the F5® DC Agent.
- Authentication
- F5 recommends that you use NTLM or Kerberos authentication. If you plan to use
authentication, ensure that you have what you need configured.
- For NTLM, you need an NTLM Auth Configuration in Access Policy Manager® (APM®).
- For Kerberos, you need a domain-joined Kerberos user account and a Kerberos AAA server configured in APM.
- SSL intercept
- To intercept SSL connections that are passing through the proxy, ensure that you have imported a valid subordinate CA certificate and key that is trusted by the endpoints behind the proxy.
- Captive portal
- If you plan to use the captive portal feature, make sure that a certificate and key with the proper common name is imported for use.
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).
About ways to configure user identification for SWG
User identification configuration requires a method setting in the access profile and an access policy configured to support the setting. Based on user identification, you can determine which scheme to assign in the access policy so that Secure Web Gateway (SWG) filters URLs appropriately.
Depending on the access profile type, you can select one of these user identification methods: by IP address (for SWG-Explicit or SWG-Transparent access profile types) or by credentials (for SWG-Explicit type).
Identification by IP address
When you identify users by IP address, you can employ any of these methods.
- transparent user identification
- Transparent user identification makes a best effort to identify users without requesting
credentials. It queries domain controllers and stores a mapping of IP addresses to user
names in an IF-MAP server. Note: To identify users transparently, you must first install and configure the F5® DC Agent.
- explicit user identification
- You can present a logon page in an access policy to request user credentials and validate them. SWG maintains an internal mapping of IP addresses to user names. (You can present the appropriate logon page for the access policy type. For explicit forward proxy, you can present a 407 page. For transparent forward proxy, you can present a 401 page.)
- source IP ranges or subnets
- You can forego actually identifying the user and base the choice of which scheme to apply on whether the IP address is in a source IP range or on a subnet. SWG maintains an internal mapping of IP addresses to sessions.
- single scheme
- You can apply the same scheme to all users. SWG maintains an internal mapping of IP addresses to sessions.
Identification by credentials
When you choose to identify users by credentials, SWG maintains an internal mapping of credentials to sessions. To support this choice, you need an NTLM Auth Configuration object and you should check the result of NTLM authentication in the access policy.
Creating a VLAN for transparent forward proxy
Assigning a self IP address to a VLAN
Creating an access profile for SWG transparent forward proxy
Configuring an access policy for transparent forward proxy
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.
Creating a custom Server SSL profile
Creating a virtual server for forward proxy SSL traffic
Creating a virtual server for forward proxy traffic
Creating a forwarding virtual server
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.
Creating a virtual server for a captive portal
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.
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, and applies a scheme that categorizes and filters URLs, controlling access.
Before you begin
To use SWG, you must configure URL categorization. You might need to configure additional items depending on the other features that you decide to use.
- URL categorization
- To get a working SWG configuration, you must first download URL categories, configure URL filters, and configure schemes.
- Transparent user identification
- If you plan to identify users transparently, you must first download, install, and configure the F5® DC Agent.
- Authentication
- F5 recommends that you use NTLM or Kerberos authentication. If you plan to use
authentication, ensure that you have what you need configured.
- For NTLM, you need an NTLM Auth Configuration in Access Policy Manager® (APM®).
- For Kerberos, you need a domain-joined Kerberos user account and a Kerberos AAA server configured in APM.
- SSL intercept
- To intercept SSL connections that are passing through the proxy, ensure that you have imported a valid subordinate CA certificate and key that is trusted by the endpoints behind the proxy.
- Captive portal
- If you plan to use the captive portal feature, make sure that a certificate and key with the proper common name is imported for use.
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).
About ways to configure user identification for SWG
User identification configuration requires a method setting in the access profile and an access policy configured to support the setting. Based on user identification, you can determine which scheme to assign in the access policy so that Secure Web Gateway (SWG) filters URLs appropriately.
Depending on the access profile type, you can select one of these user identification methods: by IP address (for SWG-Explicit or SWG-Transparent access profile types) or by credentials (for SWG-Explicit type).
Identification by IP address
When you identify users by IP address, you can employ any of these methods.
- transparent user identification
- Transparent user identification makes a best effort to identify users without requesting
credentials. It queries domain controllers and stores a mapping of IP addresses to user
names in an IF-MAP server. Note: To identify users transparently, you must first install and configure the F5® DC Agent.
- explicit user identification
- You can present a logon page in an access policy to request user credentials and validate them. SWG maintains an internal mapping of IP addresses to user names. (You can present the appropriate logon page for the access policy type. For explicit forward proxy, you can present a 407 page. For transparent forward proxy, you can present a 401 page.)
- source IP ranges or subnets
- You can forego actually identifying the user and base the choice of which scheme to apply on whether the IP address is in a source IP range or on a subnet. SWG maintains an internal mapping of IP addresses to sessions.
- single scheme
- You can apply the same scheme to all users. SWG maintains an internal mapping of IP addresses to sessions.
Identification by credentials
When you choose to identify users by credentials, SWG maintains an internal mapping of credentials to sessions. To support this choice, you need an NTLM Auth Configuration object and you should check the result of NTLM authentication in the access policy.
Creating a VLAN for transparent forward proxy
Assigning a self IP address to a VLAN
Creating an access profile for SWG transparent forward proxy
Configuring an access policy for transparent forward proxy
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.
Creating a custom Server SSL profile
Creating a virtual server for forward proxy SSL traffic
Creating a virtual server for forward proxy traffic
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.