Skills Tested
Enabling WCCP functionality between the Cisco WSA and ASA to provide transparent proxy support
Configuring proxy bypass lists
Creating and applying custom URL categories Solution and Verification
This exercise builds upon the basic configuration of the Cisco WSA in Exercise 2.2.
Configuring and customizing how the WSA will process HTTP and HTTPS requests transparently proxied by the Cisco ASA is fundamental, yet very important. It enables the administrator to control how access requests are processed both for security and efficiency purposes.
For all verification syntax that follows:
Required output appears in red Required tasks appear in indigo Variable syntax appears in green
Task 1: Configure WCCPv2 Proxy Support on the Cisco WSA (Client) and the Cisco ASA (Server)
Verify connectivity between the WSA (WCCP client) and ASA (WCCP server). The router-ID on the ASA will be the highest IP address configured on the device (within the ASA context), and it is used to form a GRE tunnel with the WSA.
Click here to view code image
ASA1# changeto context c1 ASA1/c1(config)# show wccp Global WCCP information:
Router information:
Router Identifier: 192.168.2.20 Protocol Version: 2.0
Service Identifier: 90
Number of Cache Engines: 1 Number of routers: 1
Total Packets Redirected: 201578
Redirect access-list: WCCPRedirectionList -> name must match list below
Total Connections Denied Redirect: 0 Total Packets Unassigned: 0
Group access-list: wccpservers -> name must match list below
Total Messages Denied to Group: 0 Total Authentication failures: 0 Total Bypassed Packets Received: 0
To ensure that the GRE tunnel has been established between the WCCP client and server, debugs on the ASA can be enabled that should show the periodic liveliness check. The WCCP server is
responsible for redirection of interesting traffic to the client. The clients will then apply configured service policy criteria on the assigned traffic.
Click here to view code image
ASA1/c1# debug wccp packet
WCCP-PKT:D90: Received valid Here_I_Am packet from 192.168.2.50 w/rcv_id 00000213 WCCP-PKT:D90: Sending I_See_You packet to 192.168.2.50 w/ rcv_id 00000214
Verify whether the redirection criteria are correctly configured:
Click here to view code image
ASA1/c1# show access-list
access-list WCCPRedirectionList line 1 extended permit tcp any any eq www access-list WCCPRedirectionList line 2 extended permit tcp any any eq https access-list wccpservers line 1 extended permit ip host 192.168.2.50 any
From the web browser, connect to http://10.50.40.7 and verify the output on R7. If the configuration is correct, the HTTP connection source address will be that of the WSA.
Click here to view code image
R7# show ip http server history
! note this must be completed after attempting a connection from a browser otherwise the history may be blank.
HTTP server history:
local-ipaddress:port remote-ipaddress:port in-bytes out-bytes
10.50.40.7:80 192.168.2.50:4507 332 192 17:21:11 04/07 10.50.40.7:80 192.168.2.50:49622 375 192 17:21:23 04/07 10.50.40.7:80 192.168.2.50:24928 379 192 17:21:37 04/07 10.50.40.7:80 192.168.2.50:39850 375 2077 17:21:45 04/07 Task 2: Configure Proxy Bypass on the Cisco WSA
From the web browser, connect to http://10.50.80.6 then verify the output on R6. This will test the proxy bypass list and should show the HTTP connection coming from the actual source address of the client browser device, not the WSA.
Click here to view code image
R6# show ip http server history
! note this must be completed after attempting a connection from a browser otherwise the history may be blank.
HTTP server history:
local-ipaddress:port remote-ipaddress:port in-bytes out-bytes
10.50.80.6:80 192.168.2.25:63596 256 192 20:12:15 09/06 10.50.80.6:80 192.168.2.25:63597 295 1986 20:12:23 09/06 10.50.80.6:80 192.168.2.25:63598 248 137 20:12:23 09/06 Task 3: Create a Custom URL Access Policy on the Cisco WSA
From the web browser, connect to http://10.50.30.3. The connection should be denied and an error page generated by the WSA displayed:
This Page Cannot Be Displayed Configuration
Click here to view code image
! ASA1/c1
wccp 90 redirect-list WCCPRedirectionList group-list wccpservers
wccp interface inside 90 redirect in
access-list WCCPRedirectionList extended permit tcp any any eq www access-list WCCPRedirectionList extended permit tcp any any eq https access-list wccpservers extended permit ip host 192.168.2.50 any Tech Notes
WCCP Support Across Cisco Products
WCCP support and functionality varies between WCCP server types. At the time of this writing, the ASA has the following capabilities:
Redirection of multiple TCP and UDP port-destined traffic Unicast WCCP via UDP/2048
Authentication for cache engines in a service group Multiple cache engines in a service group
GRE encapsulation for traffic redirection
The following WCCPv2 features are not supported for the ASA but are supported on Cisco Catalyst switches and ISR routers:
Multiple routers in a service group Multicast WCCP
Layer 2 for traffic redirection WCCP source address spoofing Transparent Proxy Versus Explicit Proxy
Using WCCP as the proxy mechanism is known as transparent proxy because the client browser settings do not have to be modified for connections to be forwarded to the WSA. The WCCP server intercepts the request and forwards it to the WSA to be proxied. DNS resolution of websites is done by the client device.
Explicit proxy requires the client browser to connect to the WSA. The WSA uses DNS to resolve the website and then connects to that site.
Connection Assignment and Redirection
Two of the more advanced WCCP concepts are those of assignment and redirection.
Assignment refers to the method by which traffic is distributed to the WSA, and it is more relevant when multiple WSAs are sharing the load within a service group.
Two assignment methods exist, both of which track the source and destination IP addresses plus
source and destination ports. An algorithm is used that assigns the result to a specific “bucket.” These buckets are distributed among the WSAs within a specific service group. The assignment algorithms are
Hash-Based Assignment: Uses a software-based hash algorithm to determine which WCCP appliance receives traffic. In hardware-based platforms, the Netflow table is used to apply hardware assistance. It consists of a byte-level (8-bit) XOR computation divided into 256
buckets.
Mask-Based Assignment: Uses the ACL Ternary Content-Addressable Memory (TCAM) to assign WCCP entities. This method is fully handled by hardware and consists of a bit-level AND divided into 128 buckets (7 bits).
The Cisco ASA uses hash-based assignment to assign a connection to a specific bucket. The following command on the ASA illustrates how hash-based assignment is done:
Click here to view code image
ASA1/c1# show wccp 90 hash 10.50.70.6 192.168.2.25 80 1024 WCCP hash information for:
Primary Hash: Dst IP: 10.50.70.6 Bucket: 120
Cache Engine: 192.168.2.50
Because there is support for only one WSA per service group, all 256 buckets are assigned to the same WSA:
Click here to view code image
ASA1/c1(config)# show wccp 90 buckets WCCP hash bucket assignments:
Index Cache Engine:
00 192.168.2.50 FF NOT ASSIGNED
XX| 0 1 2 3 4 5 6 7 8 9 A B C D E F
00| 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 10| 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 20| 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 30| 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 40| 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Traffic is forwarded to a WSA using either the GRE (IP encaps) or L2 (MAC rewrite).
When determining the most efficient WSA deployment, the following performance guidelines are useful:
MASK (HW) > HASH (SW). HW must take TCAM resources into consideration.
L2 (HW) > GRE (SW).
Use GRE if WSA is located in another subnet. Check whether the device can do GRE in HW.
Use L2 if WSA and WCCP device are in the same subnet. ASA is the exception and must use GRE.
Service Groups
An assignment method and a forwarding method are defined per service group. Traffic service types and traffic-handling requirements are also configured within the service group. Types of traffic service include support for standard “well-known” (default port 80) traffic or for dynamic services (which support other non-HTTP protocols). Traffic-handling options allow for functions such as IP address spoofing, where the original source address of the client requester is used, although the return traffic from the server will be forwarded back to the WSA by the WCCP server.
Figure 1a-2 illustrates WCCP configuration options on the WCCP client (WSA) for creating service groups that handle traffic of interest redirected from the WCCP server.
Figure 1a-2 WSA WCCP Configuration Parameters
Section 3: Secure Access
The exercises in this section cover fundamental ways to secure network access via wired and wireless methods. Legacy remote access VPNs via Easy Virtual Private Networks (EZVPN) using IKEv1 can be built between various client and server platforms—in this case, the Cisco ASA will be the server and the Cisco IOS router takes on the role of client. DMVPN has evolved over phase 1, 2, and now phase 3, which is covered here. The Cisco IOS–based Certificate Authority (CA) server exercise must be completed and will be used in other exercises in this guide. Wireless security is an increasingly important topic, and we start with some basic security access methods that will be expanded upon in other lab exercises.