Advanced WebVPN Features

Cisco ASA provides many advanced WebVPN features to suit the VPN implementations:

• Port forwarding
• URL mangling
• E-mail proxy
• Windows file sharing
• WebVPN access lists

The sections that follow cover these features in more detail.

Port Forwarding

Once a session is established, users can use the features offered by WebVPN. One of the important features is port forwarding, which provides client access to the servers over the known and fixed TCP ports. VPN users connect to the TCP applications offered by the server using Cisco ASA. To use this feature, the authenticated WebVPN users click the "Start Application Access" link on the main page, which launches a Java applet on the client machine showing the IP address and the port number that can be used for the session. Figure 16-18 illustrates the Java applet launched in the client machine.

Figure 16-18. Port-Forwarding Applet

The port-forwarding feature requires you to install Sun Microsystems' Java Runtime Environment (JRE) and configure applications on the end user's PC. If users are establishing the WebVPN tunnel from public machines, such as Internet kiosks or web cafés, they might not be able to use this feature. The installation on Sun's JRE requires administrative rights on the client machine.

You can enable or disable port forwarding by configuring the functions command under the webvpn menu of a default, user group, or user policy. To enable port forwarding, use the functions command with the port-forward parameter, as shown in Example 16-69.

Example 16-69. Enabling Port Forwarding

Chicago(config)# group-policy SecureMeWebGrp attributes

Chicago(config-group-policy)# vpn-tunnel-protocol webvpn

Chicago(config-group-policy)# webvpn

Chicago(config-group-webvpn)# functions port-forward

Port forwarding is configured by using the port-forward command followed by the name of the list in the global configuration mode. The Cisco ASA configuration in Example 16-70 specifies a list called telnet_inside to forward information about a Telnet server located at 192.168.10.20.

Example 16-70. Port-Forwarding List Configuration

Chicago(config)# port-forward telnet_inside 1100 192.168.10.20 23

Note

When port forwarding is in use, the HOSTS file on the WebVPN client is modified to resolve the host name using one of the loopback addresses. Cisco ASA uses an available address in the range from 127.0.0.2 to 127.0.0.254.

If the HOSTS file cannot be modified, the host listens on 127.0.0.1 and the configured local port.

Once the applet is loaded on the client, the user can establish a Telnet connection to the server by using the loopback IP address of 127.0.0.1 on the local port 1100. This will redirect the connection over the WebVPN tunnel to the server at 192.168.10.20 on port 23.

Note

It is recommended to use a local port between 1024 and 65535 to avoid conflicts with the existing network services.

The port list can then be mapped to a default, user group, or user policy. In Example 16-71, the port list telnet_inside is mapped to a user group-policy named SecureMeWebGrp under the WebVPN submenu. Mapping of the list to a policy is done by using the port-forward value command followed by the name of the list.

Example 16-71. Port-Forwarding List Mapping

Chicago(config)# group-policy SecureMeWebGrp attributes

Chicago(config-group-policy)# vpn-tunnel-protocol webvpn

Chicago(config-group-webvpn)# webvpn

Chicago(config-group-webvpn)# functions port-forward

Chicago(config-group-webvpn)# port-forward value telnet_inside

The login page shows a default link of "Start Application Access" to launch the port-forwarding applet. This link can be renamed to accommodate the security policy of an organization. In Example 16-72, the link for the port-forwarding applet on the main login page is changed to "SecureMe Port-Forwarding".

Example 16-72. Configuration of Port-Forwarding Applet name

Chicago(config)# group-policy SecureMeWebGrp attributes

Chicago(config-group-policy)# vpn-tunnel-protocol webvpn

Chicago(config-group-policy)# webvpn

Chicago(config-group-webvpn)# functions port-forward

Chicago(config-group-webvpn)# port-forward value telnet_inside

Chicago(config-group-webvpn)# port-forward-name value SecureMe Port-Forwarding

 

Configuring URL Mangling

Using WebVPN, remote users can browse their internal websites. Cisco ASA terminates the HTTPS connections on the public interface, and then forwards the HTTP or HTTPS requests to the specified server. The response from the web server is then encapsulated into HTTPS and forwarded to the client. This feature, known as URL mangling, is illustrated in Figure 16-19. The following sequence of events takes place when UserA tries to connect to a web server located at 192.168.10.10:

Step 1.	User A initiates an HTTP request to the web server, located on the other side of the WebVPN tunnel. The user request is encapsulated into the SSL tunnel and is then forwarded to the security appliance.
Step 2.	The security appliance de-encapsulates the traffic and initiates a connection to the server on behalf of the web client.
Step 3.	The response from the server is sent to the security appliance.
Step 4.	The security appliance, in turn, encapsulates and sends it to UserA.

Figure 16-19. HTTP Requests Using URL Mangling

With URL mangling, the original protocol, host address, port number, and path get manipulated to establish connectivity to the Cisco ASA. The original protocol field is replaced with https, while the original address and port are replaced with the IP address and port of the security appliance. The mangled path in the URL is augmented with the protocol, port, and host elements of the original URL. Figure 16-20 shows the original and the modified URLs.

Figure 16-20. URL Mangling in WebVPN

Table 16-6 lists four examples of the original and the mangled URLs. The Cisco ASA IP address is 209.165.200.225.

Table 16-6. Original and Mangled URLs in WebVPN

Original URL	Mangled URL
http://www.securemeinc.com	https://209.165.200.225/http/0/www.securemeinc.com
https://internalweb.securemeinc.com/index.html	https://209.165.200.225/https/0/internalweb.securemeinc.com/index.html
http://freedom.securemeinc.com/~free/protect-cgi-bin/simple_query.cgi	https://209.165.200.225/http/0/freedom.securemeinc.com/~free/protect-cgi-bin/simple_query.cgi
http://metrics.securemeinc.com:675	https://209.165.200.225/http/675/metrics.securemeinc.com:675

The flags parameter, shown in Figure 16-20, integrates the original port number and a set of other flag values. It is the ASCII representation in decimal, with the lower 16 bits reserved for the port and the upper 16 bits reserved for flags. Port 0 is used if the original URL either contains 80 (for HTTP) or 443 (for HTTPS). The upper 16 bits are currently not used.

Note

The current implementation of WebVPN cannot modify Java and ActiveX coding in a web page. Additionally, Cisco ASA does not mangle non-HTTP-based URLs such as ftp:// or telnet://.

The configuration of URL mangling involves setting up a URL list to specify the IP address of the web server(s). The command syntax to define a URL list is as follows:

url-list listname displayname url

where:

• listname is the name that is then used to map the url-list to a user or group-policy.
• displayname is the name that is shown to the WebVPN user after a successful user authentication.
• url is the actual URL to a web-server that resides toward the inside interface.

In Example 16-73, a URL list named HTTP_Link is set up with a displayname of Internal and the host URL of http://192.168.10.10.

Example 16-73. URL Mangling List

Chicago(config)# url-list HTTP_Link "Internal" http://192.168.10.10

The URL list is then linked to a user or group-policy by using the url-list command followed by the name of the URL list. In Example 16-74, the URL list HTTP_Link is applied to the SecureMeWebGrp group under the webvpn submenu.

Example 16-74. URL List Mapping to a Group-Policy

Chicago(config)# group-policy SecureMeWebGrp attributes

Chicago(config-group-policy)# webvpn

Chicago(config-group-webvpn)# url-list value HTTP_Link

Cisco ASA can optionally forward HTTP WebVPN sessions to either an HTTP or HTTPS server. These proxy servers act as the intermediary servers between the WebVPN users and the Internet. This greatly enhances network security by filtering unnecessary web traffic in the network. Example 16-75 shows the configuration for Cisco ASA to be set up as an HTTP server located at 192.168.10.100 and as an HTTPS server with an IP address of 192.168.10.200.

Example 16-75. HTTP/HTTPS Proxy Configuration

Chicago(config)# webvpn

Chicago(config-webvpn)# http-proxy 192.168.10.100 80

Chicago(config-webvpn)# https-proxy 192.168.10.200 443

As a security device, Cisco ASA has the capability to filter out Java or ActiveX applets, script tags, display images, and delete cookies from the HTML pages when they are sent over a WebVPN connection. This is done by using the html-content-filter command followed by the selected parameter to filter. The Cisco ASA configuration in Example 16-76 sets up the capability to filter out Java/ActiveX and display images when the HTML pages are sent to the client.

Example 16-76. HTML Content Filtering

Chicago(config)# group-policy SecureMeWebGrp attributes

Chicago(config-group-policy)# vpn-tunnel-protocol webvpn

Chicago(config-group-webvpn)# webvpn

Chicago(config-group- webvpn)# html-content-filter java images

 

E-Mail Proxy

WebVPN provides a way for the remote users to check e-mail using the secure HTTP connection. This feature, known as e-mail proxy, provides a seamless connection from an e-mail client to the server. Users have the option to either authenticate themselves to the GUI WebVPN authentication screen or set up the e-mail client for automatic user authentication.

Cisco ASA supports three types of e-mail proxies: SMTP, IMAP4, and POP3. All of these proxies use their own unique SSL/TLS ports. Cisco ASA uses the default TCP ports of 988, 993, and 995 for SMTP, IMAP4, and POP3, respectively. All of these proxies are disabled until explicitly enabled on the physical interface by configuring the enable command, followed by the name of the interface terminating the connections, under the e-mail proxies' subconfiguration menu. The Cisco ASA configuration in Example 16-77 enables the security appliance to accept IMAP4, POP3, and SMTP proxies on the outside interface.

Example 16-77. Enabling E-Mail Proxy on the Outside Interface

Chicago(config)# imap4s

Chicago(config-imap4s)# enable outside

Chicago(config-imap4s)# pop3s

Chicago(config-pop3s)# enable outside

Chicago(config-pop3s)# smtps

Chicago(config-smtps)# enable outside

Cisco ASA provides protection against denial of service (DoS) attacks against the e-mail servers when deployed as an e-mail proxy. The user has to be authenticated first by the security appliance before the session is opened for e-mail transfer, as illustrated in Figure 16-21. After a successful user authentication, Cisco ASA opens a session to the e-mail server and forwards the user credentials for validation.

Figure 16-21. User Authentication Using E-Mail Proxy

Once the WebVPN session is authenticated, the Cisco ASA's default behavior is to apply the attributes configured under the DfltGrpPolicy group-policy. However, a user group-policy can be applied to the e-mail proxies by configuring the default-group-policy command followed by the name of the user group-policy. In Example 16-78, the IMAP4 proxy is associating the SecureMeWebGrp user group-policy with the authenticated IMAP4 sessions.

Example 16-78. Mapping of User Group-Policy on the IMAP4 Proxy

Chicago(config)# imap4s

Chicago(config-imap4s)# enable outside

Chicago(config-imap4s)# default-group-policy SecureMeWebGrp

 

Authentication Methods for E-Mail Proxy

Cisco ASA supports three methods for e-mail proxy authentication:

• Piggyback authentication
• AAA authentication
• Certificate authentication

Piggyback Authentication

With piggyback HTTPS, a user is required to have a WebVPN session already established before connecting to the e-mail server. The user provides their e-mail username and passwords for authentication. If the VPN and e-mail usernames are different, the user is required to provide both of them, separated by a VPN delimiter (discussed later in this chapter). The VPN user credentials are used to verify only that the WebVPN session is already established. If the session is not established, the user is not allowed to connect to the e-mail server.

Caution

Due to an inherit flaw in SMTP, if piggyback authentication is used with SMTP, an attacker can potentially send spam e-mail messages using any name and using a legitimate user account. This typically happens when the attacker spoofs the IP address and the VPN name of the legitimate user. To remedy this problem, consider using IMAP4 or POP3 for piggyback authentication. Alternatively, you can use certificate authentication for SMTP.

Example 16-79 shows that piggyback authentication is enabled for users who use IMAP4 for e-mail messages.

Example 16-79. Piggyback Authentication for IMAP4

Chicago(config)# imap4s

Chicago(config-imap4s)# enable outside

Chicago(config-imap4s)# authentication piggyback

 

AAA Authentication

AAA authentication is a way to authenticate the VPN users using either the internal or external database. For AAA authentication, users do not need to have a pre-established WebVPN session. When a user checks e-mail, the e-mail client opens the secured connection to Cisco ASA and presents the VPN user credentials. Cisco ASA checks the configured user database and authenticates the user if credentials are valid. After a successful authentication, Cisco ASA forwards the e-mail user credentials to the e-mail server. If the VPN and e-mail usernames are different, a VPN delimiter is used to differentiate them.

Cisco ASA uses an authentication server to validate user accounts. Example 16-80 shows the AAA authentication configuration for RADIUS users who use POP3 for e-mail. The RADIUS server is defined under tag Rad and is located at 192.168.10.30. This tag is then mapped to the POP3 proxy by using the authentication-server-group Rad command.

Example 16-80. AAA Authentication for POP3

Chicago(config)# aaa-server Rad protocol radius

Chicago(config-aaa-server-group)# exit

Chicago(config)# aaa-server Rad host 192.168.10.30

Chicago(config-aaa-server-host)# exit

Chicago(config)# pop3s

Chicago(config-pop3s)# enable outside

Chicago(config-pop3s)# authentication aaa

Chicago(config-pop3s)# authentication-server-group Rad

 

Certificate Authentication

Certificate authentication requires the e-mail user to present the certificate to the security appliance for validation. If the certificate authentication is unsuccessful, the secured connection is terminated, and the e-mail client fails to connect to the server. This method requires two certificates to be installed on the devices:

• A certificate authority (CA) certificate on Cisco ASA and on the e-mail client
• An identity certificate on the client machine that is signed by a CA and authenticated by Cisco ASA

Example 16-81 shows that certificate authentication is enabled for users who check their e-mail using SMTPS.

Example 16-81. Certificate Authentication for SMTPS

Chicago(config)# smtps

Chicago(config-smtps)# enable outside

Chicago(config-smtps)# authentication certificate

Note

SMTP e-mail proxy allows mailhost authentication for additional security. Mailhost authentication requires the use of username, password, and server information. Cisco ASA does not allow the configuration of mailhost authentication for POP3 and IMAP4, because they always perform mailhost authentication. SMTP e-mail proxy is enabled by configuring authentication mailhost under the SMTP proxy.

 

Identifying E-Mail Servers for E-Mail Proxies

After you configure the authentication methods, the next step is to identify the e-mail servers to be used for each proxy. To specify an e-mail server, you can use the server command followed by the IP address or the host name of the server. In the configuration in Example 16-82, one email server, called secureme-email, is set up to serve both IMAP and POP3 users. The server is defined under both the IMAP and POP3 configuration menus.

Example 16-82. Configuration of E-Mail Proxy Servers

Chicago(config)# imap4s

Chicago(config-imap4s)# enable outside

Chicago(config-imap4s)# server secureme-email

Chicago(config-imap4s)# authentication piggyback

Chicago(config-imap4s)# pop3s

Chicago(config-pop3s)# enable outside

Chicago(config-pop3s)# server secureme-email

Chicago(config-pop3s)# authentication aaa

 

Delimiters

Cisco ASA can differentiate the WebVPN username from the e-mail username by using specific delimiters for each of the e-mail proxies. There are two types of supported delimiters:

• Username delimiter
• Server delimiter

Username Delimiter

A username delimiter is used to separate out the VPN username from the e-mail username in the username string when configuring the e-mail client. However, this delimiter is necessary only when both usernames are different from each other. The same username delimiter is used to differentiate the user password from the e-mail server password. The username delimiter can be specified by using the name-separator command followed by the actual delimiter. Cisco ASA supports the following valid username delimiters:

• hash (#)
• comma (,)
• colon (:)
• semicolon (;)
• at (@)
• pipe (|)

The Cisco ASA configuration in Example 16-83 specifies the use of # for the username delimiter for the IMAP4 and POP3 proxies. The default username delimiter on Cisco ASA is the colon (:).

Example 16-83. Configuration of E-Mail Proxy Username Delimiter

Chicago(config)# imap4s

Chicago(config-imap4s)# enable outside

Chicago(config-imap4s)# server secureme-email

Chicago(config-imap4s)# name-separator #

Chicago(config-imap4s)# authentication piggyback

Chicago(config-imap4s)# pop3s

Chicago(config-pop3s)# enable outside

Chicago(config-pop3s)# server secureme-email

Chicago(config-pop3s)# name-separator #

Chicago(config-pop3s)# authentication aaa

Note

You cannot have a username delimiter as a valid character in the user password.

 

Server Delimiter

A server delimiter is used to differentiate the username from the e-mail server name when the username string is entered in the e-mail client. A server name can be either the host name or the IP address of the e-mail server. The server delimiter can be specified by using the server-separator command followed by the actual delimiter. Cisco ASA supports the following valid server delimiters:

• hash (#)
• comma (,)
• colon (:)
• semicolon (;)
• at (@)
• pipe (|)

However, the server delimiter must be different from the username delimiter. Example 16-84 demonstrates the Cisco ASA configuration to use | as the server delimiter for the IMAP4 and POP3 proxies. The default server delimiter on Cisco ASA is at (@).

Example 16-84. Configuration of E-Mail Proxy Server Delimiter

Chicago(config)# imap4s

Chicago(config-imap4s)# enable outside

Chicago(config-imap4s)# server secureme-email

Chicago(config-imap4s)# name-separator #

Chicago(config-imap4s)# server-separator |

Chicago(config-imap4s)# authentication piggyback

Chicago(config-imap4s)# pop3s

Chicago(config-pop3s)# enable outside

Chicago(config-pop3s)# server secureme-email

Chicago(config-pop3s)# name-separator #

Chicago(config-pop3s)# server-separator |

Chicago(config-pop3s)# authentication aaa

Tip

The e-mail client must be properly configured for the e-mail proxy feature to work. Consult the following link for an e-mail client sample configuration:

http://www.cisco.com/en/US/partner/products/hw/vpndevc/ps2284/products_configuration_guide_chapter09186a00801f1fb6.html

 

Windows File Sharing

Cisco ASA supports network file sharing using Common Internet File System (CIFS), a file system that uses the original IBM and Microsoft networking protocols. Using CIFS, users can access their file shares located on the file servers, as illustrated in Figure 16-22. Users can download, upload, delete, or rename the files under the shared directories, but only if the file system permissions allow them to perform those actions.

Figure 16-22. CIFS Browsing on the Security Appliance

To access the shared resources, users can click the Browse Network link and select the proper domain or workgroup. They can browse to the desired shared resource and take the appropriate actions (read, write, delete, rename filename). They can even create subdirectories, assuming that they are allowed to do so. Alternatively, they can enter the NetBIOS name of the server in the Enter Network Path field to display all the shared resources available for that server, as depicted in Figure 16-23.

Figure 16-23. CIFS Support on Cisco ASA

The configuration of CIFS requires the use of a NetBIOS Name Server (NBNS), also known as Windows Internet Naming Server (WINS). When a WebVPN user queries to browse the network, the Cisco ASA contacts the WINS server and acquires the list of available domains, workgroups, and workstations. The command syntax to configure an NBNS server is as follows:

nbns-server ipaddr [master] [timeout timeout] [retry retries]

The nbns-server command can be found under webvpn subconfiguration mode. The ipaddr is the IP address of the NBNS server for CIFS name resolution. The master keyword specifies that the configured NBNS server acts as the master browser in addition to being a WINS server. The timeout value instructs an appliance to wait for the configured number of seconds (default is 2 seconds) before sending another query to the next server. The retry option is used to specify the number of times Cisco ASA has to go through the list of the configured NBNS servers. The default retries is 2, and it ranges from 0 to 10.

Note

You can specify up to three WINS servers in the current version.

The configuration in Example 16-85 sets up Cisco ASA to use three NBNS servers. The first server, 192.168.10.50, acts as a master browser rather than a WINS server. The other two servers, 192.168.10.51 and 192.168.10.52, are the WINS servers. The timeout and retry values are set to their defaults.

Example 16-85. CIFSNBNS Server Configuration

Chicago(config)# webvpn

Chicago(config-webvpn)# nbns-server 192.168.10.50 master timeout 2 retry 2

Chicago(config-webvpn)# nbns-server 192.168.10.51 timeout 2 retry 2

Chicago(config-webvpn)# nbns-server 192.168.10.52 timeout 2 retry 2

Cisco ASA does not enable CIFS functionality until the functions parameter is set up to allow file browsing, file access, and file entry. The configuration in Example 16-86 sets up Cisco ASA with a user group-policy named SecureMeWebGrp, which allows users to browse, access, and enter file information using the functions attribute.

Example 16-86. Configuration of User Group Attributes

Chicago(config)# group-policy SecureMeWebGrp attributes

Chicago(config-group-policy)# webvpn

Chicago(config-group-webvpn)# functions file-access file-entry file-browsing

 

WebVPN Access Lists

Cisco ASA enables network administrators to further their WebVPN security by configuring WebVPN access control lists (ACLs) to manage access to web, file, and e-mail servers. These ACLs affect only the WebVPN traffic and are processed in sequential order until there is a match. If there is an ACL defined but no match, the default behavior on Cisco ASA is to drop the packets. On the other hand, if there is no ACL defined, Cisco ASA allows all traffic to pass through it.

Moreover, this robust WebVPN feature allows these ACLs to be downloaded from a Cisco Secure Access Control Server (CS-ACS) by using the vendor specific attributes (VSAs). This allows central control and management of user access into the corporate network by offloading ACL definitions locally on the security appliance.

Tip

Using CS-ACS Server, a WebVPN ACL can be configured by specifying the webvpn:inacl# prefix in the downloadable ACLs, where # indicates the sequence number of an access control entry (ACE).

The command syntax to create a WebVPN ACL is as follows:

access-list id webtype {deny | permit} url [url_string | any] [log [[disable | default]

 | level][interval secs] [time_range name]]

and

access-list id webtype {deny | permit} tcp [host ip_address | ip_address subnet_mask

 | any] [oper port [port]] [log [[disable | default] | level] [interval secs]

 [time_range name]]

A URL-based WebVPN ACL is used to filter out WebVPN packets if they contain a URL such as http://. A TCP-based WebVPN ACL is used to filter out WebVPN packets if they use TCP encapsulation based on the IP address and the Layer 4 port number.

Table 16-7 describes all the options available in the WebVPN ACL.

Table 16-7. WebVPN ACL Parameters

Feature	Description
any	Specifies all IP addresses or all URLs.
deny	Denies access if packets match the condition.
permit	Permits access if packets match the condition.
tcp	A keyword to specify a TCP-based ACE.
host	A keyword to specify a host IP address.
oper	The operator that is used to compare destination ports in WebVPN packets. The security appliance supports lt (less than), gt (greater than), eq (equal), neq (not equal), and range (inclusive range) as operators.
port	Specifies the TCP or UDP port in the range of 0 to 65535 used for WebVPN packets.
ip_address	The actual IP address of the host or the network address.
subnet_mask	The actual subnet mask when a network address is specified as the IP address.
url	A keyword to specify a URL-based ACE.
url-string	The actual URL used for filtering.
log	Sends a syslog message whenever there is a hit on the ACL.
disable	Does not send a syslog message if packets hit the configured ACE.
default	Uses the default behavior, which generates a syslog 106023 message whenever a packet matches a deny in the ACE.
level	Changes the syslog level when a message is generated. The default level is 6 (informational).
interval	A keyword to specify the time interval to generate the subsequent new syslog messages.
secs	The actual time interval, in seconds. The default time interval is 300 seconds, and it ranges from 1 to 600 seconds.
time_range	A keyword to specify the time-range name.
name	The predefined time-range name.

Note

If you want to include all URLs that are not explicitly matched in the ACL, you can include an asterisk (*) as a wildcard. The following example shows how to block POP3 e-mail access and allow all other protocols:

 access-list blockpop3 webtype deny url pop3://*

 access-list blockpop3 webtype permit url any

In Example 16-87, there is a WebVPN ACL configured called HTTP. The first entry in the list denies WebVPN HTTP traffic destined to an internal server located at wwwin.securemeinc.com. The logging is set to debugging (level 7) with the subsequent syslog messages generated every 60 seconds. The second entry in the list permits all other WebVPN traffic.

Example 16-87. WebVPN ACL Configuration

Chicago(config)# access-list HTTP webtype deny url http://wwwin.securemeinc.com log

 debugging interval 60

Chicago(config)# access-list HTTP webtype permit url any

Once the WebVPN ACL is configured, the next step is to link it to a default, user group, or user policy under the WebVPN configuration menu. Example 16-88 shows that the configured HTTP ACL is mapped to a user group called SecureMeWebGrp by using the filter value command.

Example 16-88. WebVPN ACL Mapping

Chicago(config)# group-policy SecureMeWebGrp attributes

Chicago(config-group-policy)# webvpn

Chicago(config-group-webvpn)# filter value HTTP

Cisco ASA does not apply the WebVPN ACL feature to the user until the functions parameter is set up to filter traffic. In Example 16-89, SecureMeWebGrp is configured for filter function, which turns on WebVPN traffic filtering on the security appliance.

Example 16-89. WebVPN ACL Filtering

Chicago(config)# group-policy SecureMeWebGrp attributes

Chicago(config-group-policy)# webvpn

Chicago(config-group-webvpn)# functions filter

Chicago(config-group-webvpn)# filter value HTTP

Caution

WebVPN ACLs do not block a user from accessing the resources outside the company. These ACLs ensure that WebVPN traffic denied by the ACLs will not pass through the security appliance.