Pursuing

I can’t count how many times I’ve seen the topic of WCCP in the Cisco support forums where people want to use their Ironport WSA to block traffic from internal users *and* DMZ servers. This clearly DOES NOT WORK, but I’ve never seen a very good explanation of why it doesn’t work. This is my attempt to explain why this DOES NOT WORK.

NOTE: This isn’t a problem exclusive to Ironport WSA. BlueCoat, WebSense, etc. are all affected.

First, let’s look at a simple network and how WCCP behaves. The below drawing shows a single stateful firewall with an INSIDE and OUTSIDE zone.

Generic Firewall

Now let’s add a generic web proxy. Remember, they all act the same way. That’s the beauty of standards. If you followed the implementation guide, the proxy interface’s NIC is on the INSIDE and the firewall redirects web requests to it via WCCP. The proxy then makes the web request on behalf of the user and does its magic analysis, policy enforcement, upside-down-ternet, etc.

Proxied HTTP Session

Most people understand this much intuitively. What’s unclear most of the time is how the return traffic is sent back to the original requester. I can’t say I’m surprised because Cisco’s documentation of WCCP is, well, lacking.

Keeping with the simple network above, you can see that the web server replies back directly to the web proxy. The proxy sees the HTTP payload, does its analysis/magic, and then has to send the packets back to the original requester. The HTTP packets are sent DIRECTLY back to the user, NOT via the WCCP connection. The WCCP connection is one-way only.

Now, what happens when we add a DMZ to our firewall and the boss wants the servers’ outbound web requests to be filtered by the existing proxy? You configure WCCP on the firewall to redirect packets from the DMZ interface, the proxy sees the requests and responses, and then the proxy has to get the packets back to the DMZ server.

Internal Proxy for DMZ RequestDMZ Proxy

See the problem? The proxy will be sending the HTTP payload back to the DMZ server FROM THE INSIDE INTERFACE. Since the firewall is stateful, and the original TCP session to the external web server was initiated on the DMZ interface, not the INSIDE interface, the firewall will drop the packets from the proxy. The DMZ server won’t be able to complete any web requests to external web servers, and everyone will be sad.

There are a few solutions, though none are ideal. The first is to stand up a dedicated web proxy for each firewall zone. Depending on the number of zones and the size of your wallet, this may or may not be feasible.

Multiple Web Proxies

If that doesn’t work, you may be able to configure multiple interfaces on your web proxy, one for each zone. Most proxies have one NIC dedicated for receiving requests, so you’ll probably be limited to using 802.1Q subinterfaces.

802.1Q to Web Proxy

Or, you could destroy your security policy and remove the statefulness of your firewall. This could be done by replacing an ASA with a simple router using ACLs, or by using a tcp-map to disable stateful packet checking for certain flows.

Lastly, you could re-design your entire implementation, remove WCCP, and use the Ironport in explicit proxy mode. Then you’ll be left with all the challenges surrounding new firewall rules, wpad files, trusted CAs, etc.