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.
|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.)|
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.
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).
Only L7 ACLs work with Secure Web Gateway (SWG) explicit forward proxy.
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).
When you identify users by IP address, you can employ any of these methods.
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.
Before you begin, gather the IP addresses of the nameservers that you want to associate with a forward zone.
|Dynamic Date Time||Branch by day of week or time of day.|
|AD Group Lookup||Branch by user group. Requires branch rule configuration.|
|LDAP Group Lookup||Branch by user group. Requires branch rule configuration.|
|LocalDB Group Lookup||Branch by user group. Requires branch rule configuration.|
|RADIUS Class Lookup||Branch by the class attribute. Requires branch rule configuration.|
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.
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 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.
|RADIUS Class Lookup||session.radius.last.attr.class||RADIUS Auth|