10-22-2007 12:27 AM - edited 03-11-2019 04:28 AM
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
10-23-2007 11:41 PM
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:
Regards,
Yassin
10-24-2007 07:33 AM
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.
10-24-2007 11:57 AM
Thanks alot for your this information
10-26-2007 03:36 AM
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.
10-26-2007 05:21 AM
Thanks alot for your usefull information :)
10-26-2007 11:12 PM
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 :)
Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: