Applies To:
Show VersionsBIG-IP APM
- 11.6.5, 11.6.4, 11.6.3, 11.6.2, 11.6.1
Overview: Configuring SWG explicit forward proxy
A Secure Web Gateway (SWG) explicit forward proxy deployment provides an easy way to handle web requests from users. For explicit forward proxy, you configure client browsers to point to a forward proxy server. A forward proxy server establishes a tunnel for SSL traffic. Other virtual servers (wildcard SSL and wildcard forwarding IP virtual servers) listen on the tunnel. The listener that best matches the web traffic directed to the forward proxy server handles the traffic.
In any deployment of explicit forward proxy, you must consider how best to configure browsers on client systems to point to the proxy server and how to configure your firewall to prevent users from bypassing the proxy. This implementation does not explain how to do these tasks. However, here are some best practices to consider.
Configuration | Recommendation |
---|---|
Client browser | Consider using a group policy that points to a Proxy Auto-Configuration (PAC) file to distribute the configuration to clients and periodically update it. |
Firewall | A best practice might be to configure the firewall to trust outbound connections from Secure Web Gateway only. Note that possibly not all applications will work with a firewall configured this way. (Secure Web Gateway uses ports 80 and 443.) |
Task summary
SWG explicit forward proxy configuration prerequisites
To use Secure Web Gateway (SWG), you must configure URL categorization. You might need to configure additional items depending on the other features that you decide to use.
- URL categorization
- To get a working SWG configuration, you must first download URL categories, configure URL filters, and configure schemes.
- Transparent user identification
- If you plan to identify users transparently, you must first download, install, and configure a BIG-IP user identification agent, either the F5 DC Agent or the F5 Logon Agent
- Authentication
- F5 recommends that you use NTLM or Kerberos authentication. If you plan to use
authentication, ensure that you have what you need configured.
- For NTLM, you need an NTLM Auth Configuration in Access Policy Manager (APM).
- For Kerberos, you need a domain-joined Kerberos user account and a Kerberos AAA server configured in APM.
- SSL intercept
- To intercept SSL connections that are passing through the proxy, ensure that you have imported a valid subordinate CA certificate and key that is trusted by the endpoints behind the proxy.
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 ACLs and SWG explicit forward proxy
Only L7 ACLs work with Secure Web Gateway (SWG) explicit forward proxy.
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. 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.
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 run a script when the client logs out. Note: To identify users transparently, you must first install and configure one BIG-IP user identification agent, either the F5 DC Agent or the F5 Logon 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.
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 DNS resolver
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.
Creating a tunnel for SSL forward proxy traffic
Creating a custom HTTP profile for explicit forward proxy
Configuring a per-request policy for SWG
Creating an access profile for SWG explicit forward proxy
Configuring an access policy for SWG explicit forward proxy
Creating a virtual server to use as the forward proxy server
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 SSL forward proxy traffic
Creating a virtual server to reject traffic
Implementation result
Web traffic that originates from your enterprise networks is now inspected and controlled by F5 Secure Web Gateway forward proxy.
Session variables for use in a per-request policy
Per-request policy items that look up the group or class to which a user belongs rely on the access policy to populate these session variables.
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 |