WCCP pass through ASA

[ralwarrag]

i want to configure a WCCP in my core router and I have an ASA firewall between my Router and my cache engines and it's preventing the WCCP traffice to go though what is the solutions for this ,,, thanks for your helping

[mahmoudyassin98]

You can't have a WCCP-enabled router and a Cache Engine be separated by a firewall. The firewall handles only packet traffic toward the origin web server and does not handle packet traffic sent to the client by the Cache Engine on behalf of the server.

Please check the below URL:

http://www.cisco.com/en/US/docs/app_ntwk_services/waas/acns/v50/configuration/local/guide/14587apB.html

Regards,

Yassin

[russ]

I also have the same issue, Client/WCCP router located on Pix inside and Bluecoat Proxy located on Pix outside, the Bluecoat proxy then connects to the Internet via a Checkpoint fw.

TAC have confirmed that this is a bug: CSCsk84801

When the Pix receives the WCCP/GRE packet from the WCCP router, it is stripping the GRE header and sending the http packet natively to the outside interface, and not forwarding the GRE packet to the Bluecoat proxy.

The WCCP/GRE behaviour has been confirmed as a definite bug and will be fixed in the next 7.2.3 interim release.

However, having seen Yassin's above link I have asked TAC to confirm if this scenario is supported. I can't see why a firewall can't succesfully pass WCCP packets.

[ralwarrag]

Thanks alot for your this information

[russ]

Here is an explanation from Cisco TAC regarding the issues of passing WCCP through a firewall:

I have confirmed with DE how wccp works. What happens is that the TCP session setup packets from from wccp router to the cache engine are encaps in GRE. The return packet (syn-ack) is not encapsulated in GRE. It will therefore be dropped by the firewall as we have not see the outgoing SYN (bacause it was GRE encaps'd). In order to permit asynchronous tcp connections through the pix, you will need to configure a static nailed statement. eg:

static (inside,outside) 1.1.1.1 1.1.1.1 netmask 255.255.255.255 norandomseq nailed

This wll cause the traffic matching the static to bypass the normal TCP packet and inspection processing. This is not ideal, but this is the only way to get this working as your customer requires. The bug fix CSCsk84801 is obviously therefore still required.

In my case, the static rule needs to be applied from outside to inside.

The bug will be fixed in v8.0.3 and v7.2.3.8.

Hope this helps.

[ralwarrag]

Thanks alot for your usefull information :)

[ralwarrag]

Dear Russ

i have tried it but unfortunatly it didn't work i add static statmnet

static (outsidenet,dmznet) 1.1.1.1 [ip add of the router] 2.2.2.2 [ the ip address of the bluecoat] netmask 255.255.255.255 norandomseq nailed

and thanks alot for your helping :)