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.
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).
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.
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.
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.
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.
|
Local Database |
RADIUS Class Lookup | session.radius.last.attr.class | RADIUS Auth |
A tool that captures HTTP traffic can reveal what appears to be an extra redirect after a user attempts to gain access using a captive portal but fails, and the access policy goes to a Deny ending. Instead of immediately redirecting the user to the logout page, the user is first redirected to the landing URI, and then a request to the landing URI is redirected to the logout page.
This sample output shows both redirects: the 302 to the landing page http://berkeley.edu/index.html and the 302 to the logout page http://berkeley.edu/vdesk/hangup.php3.
POST https://bigip-master.com/my.policy?ORIG_URI=http://berkeley.edu/index.html 302 http://berkeley.edu/index.html GET http://berkeley.edu/index.html 302 http://berkeley.edu/vdesk/hangup.php3Although the 302 to the landing page might seem to be an extra redirect, it is not. When a request is made, a subordinate virtual server transfers the request to the dominant virtual server to complete the access policy. When the dominant virtual completes the access policy, it transfers the user back to the subordinate virtual server, on the same original request. The subordinate virtual server then enforces the result of the access policy.
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.
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).
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.
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.
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.
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.
|
Local Database |
RADIUS Class Lookup | session.radius.last.attr.class | RADIUS Auth |
A tool that captures HTTP traffic can reveal what appears to be an extra redirect after a user attempts to gain access using a captive portal but fails, and the access policy goes to a Deny ending. Instead of immediately redirecting the user to the logout page, the user is first redirected to the landing URI, and then a request to the landing URI is redirected to the logout page.
This sample output shows both redirects: the 302 to the landing page http://berkeley.edu/index.html and the 302 to the logout page http://berkeley.edu/vdesk/hangup.php3.
POST https://bigip-master.com/my.policy?ORIG_URI=http://berkeley.edu/index.html 302 http://berkeley.edu/index.html GET http://berkeley.edu/index.html 302 http://berkeley.edu/vdesk/hangup.php3Although the 302 to the landing page might seem to be an extra redirect, it is not. When a request is made, a subordinate virtual server transfers the request to the dominant virtual server to complete the access policy. When the dominant virtual completes the access policy, it transfers the user back to the subordinate virtual server, on the same original request. The subordinate virtual server then enforces the result of the access policy.