For example, while the AnyConnect Client has a trusted network detection feature, ScanSafe also has a similar feature. Rather than combine the two, each runs independently, letting ScanSafe work in a non-AnyConnect environment. Similarly, all of the Web-based security policies established on the IronPort S-Series Web proxy are completely independent of the policies set up for ScanSafe; you can't reuse any of the components and you can't easily translate the policy from one to the other.

We chose to focus on the third type of Web security: the Web proxy. Cisco's approach to applying Web-based security to VPN users requires a tight linkage between the ASA VPN concentrator and the S-series Web proxy, in order to transfer authentication information to the Web proxy. Making that linkage is very simple — you just put a common port number and shared secret into both devices, click the "test" button, and if everything is correct, you're done.

The ASA sends the username, but not any group membership information, over to the IronPort S-series, so we had to link to our Active Directory (NTLM or LDAP are supported) to get this information. Once that was settled, we were able to apply user- and group-based Web security policies.

One of the most important parts of the integration between the AnyConnect client, the ASA appliance, and the IronPort S-Series is the automatic download of proxy information to AnyConnect clients. We tested this with Windows (Internet Explorer), Mac (Safari, Chrome, and Firefox), and iPhone systems all running the AnyConnect client and had seamless experiences browsing through the VPN tunnel, passed to the IronPort S-Series proxy, and off to the Internet.

The IronPort S-series has a fairly standard set of protections, including URL filtering (for example, blocking gambling sites), malware scanning with two different engines (Webroot and McAfee in our test system), and Web reputation checking, used to block access to known bad Web pages or objects. The IronPort S-series also supports sanctioned man-in-the-middle, a way to "break in" to the SSL conversation by pretending to be the encrypted Web server with a fake public-key infrastructure certificate.