Thursday, January 24, 2013

Cisco Ironport WSA with WCCP and IP Spoofing

Recently I had to set up a transparent proxy with the Cisco Ironport Web Security Appliance (WSA) using WCCP on a Catalyst 6500 with a Sup720, with IP spoofing and web cache ACLs enabled. Like with many technologies, this turned out to be pretty simple but I couldn't find it documented all in one place. Perfect blog fodder!

The network topology looked like this (simplified, but not by much):



Normally when you set up a transparent proxy with WCCP, the IP address of the proxy server is used as the source of the HTTP requests. The problem in this topology is that I wanted the real source address of the client to appear in the firewall logs. The IP spoofing feature on the WSA allows this to happen, but it requires configuring bidirectional WCCP redirection on the Cat6k. If this had been a Cisco ASA firewall, we could have enabled WCCP there and saved some trouble, but in this case the network was using a firewall from another vendor that didn't support WCCP.

One important thing to realize about WCCP on the Catalyst 6500 with the Sup720 is that WCCP egress redirection is done with software switching rather than in hardware, so if you find yourself wanting to use the command "ip wccp redirect out", you're virtually guaranteeing that you're going to redline the CPU on your supervisor. Thus, we want to do only ingress redirection.

The 6500 configuration is as follows:

! this ACL prevents web traffic to internal servers (not shown in diagram)
! from being inspected
ip access-list extended ACL_WCCP
 deny   ip any 10.0.0.0 0.255.255.255
 deny   ip any 192.168.0.0 0.0.255.255
 permit ip any any


! define the web cache, referencing the ACL above 
! this WCCP service handles only standard HTTP traffic
ip wccp web-cache redirect-list ACL_WCCP
! a second WCCP service is used for reverse-path redirection, which
! is required for IP spoofing to work
ip wccp 90


interface Vlan 10
 description to client networks
 ip wccp web-cache redirect in

interface Vlan 30
 description to firewall cluster 
 ! WCCP service group 90 is applied inbound on the return path
 ! from the Internet so that IP spoofing will work
 ip wccp 90 web-cache redirect in

If you have multiple layer 3 interfaces going to client networks, you need to enable WCCP on all of them if reverse-path redirection is enabled. If we weren't using reverse redirection (i.e., if we weren't using IP spoofing), this wouldn't be the case: we could simply leave WCCP disabled on interfaces whose traffic shouldn't be proxied. With reverse redirection, though, the return traffic is always sent to the proxy server; if the proxy server sees the return traffic but not the egress traffic, it gets dropped. If you need to use IP spoofing and still have certain types of web traffic bypass the proxy, you would need to do this with ACLs applied to the WCCP service, rather than simply by leaving WCCP disabled on certain interfaces.

On the WSA, you create two WCCPv2 services under the Network-->Transparent Redirection menu, one with service group 0 (the default), and one with service group 90 (matching the the IOS configuration above). On group 90, you enable "redirect based on source port". For both groups, you enter the IP address of the SVI as the upstream router address (the IP address of VLAN 20 in this case). The WCCP service on the WSA then registers automatically with the Sup720.

Under the Security Services--> Web Proxy Settings menu, you enable transparent mode with IP spoofing for transparent connections only.

That's it: now you have a transparent proxy, with IP spoofing so that your firewall logs show accurate client IP addresses. Handling HTTPS traffic or HTTP traffic on non-standard ports is beyond the scope of this post.

3 comments:

Lars Gierling said...

"If this had been a Cisco ASA firewall, we could have enabled WCCP there and saved some trouble"
I'd like to know how to configure this with an Cisco ASA. In my opinion ip spoofing is not supported from Cisco ASA?!

Anonymous said...

We've had some interesting issues with this. Maybe you can provide some insight.

We are trying to deny outbound traffic from all hosts except the proxy (thus forcing hosts to use the proxy for outbound HTTP traffic).

However, we've found that Interface Permit HTTP ACLs are required for the source hosts even if those source hosts are using the proxy server.

Is this normal behavior?

jswan said...

Anonymous:

Two things:

1) If you're using transparent mode with source-address rewriting, you definitely need to permit those source addresses, because the WSA won't rewrite them.

2) If you're using the same physical interface for the ingress and egress traffic on the WSA (like we are), you would need to permit the real internal addresses to access the WSA itself on port 80. You should be able to block that traffic to the Internet, but not to the WSA.

Hope that helps.