> Others on the list my correct me, as I've only ever done this once. I don't
> know if my setup was "right" or not, but it did work.
>
> I found that:
>
> the client sends a SYN to the remote site, which is sent down the GRE tunnel
> by cisco.
>
> sniffing eth0 should show the GRE packets.
>
> sniffing wccp0 should show the contents of those packets, which should be
> syns to port 80 on various boxes.
>
> your firewall (on the linux host) should accept these and redirect them to
> squid 3128, which knows how to handle them
>
> squid reads the contents of the redirected packet and makes a regular TCP
> request to the site in question
>
> squid makes a regular tcp response (SYN/ACK) to the client, spoofing it's
> from address to be that of the remote website
>
> the client thinks it's talking directly to the site.
>
> the site thinks it's talking directly to the proxy (well, it really is doing
> that)
>
> the CISCO gear WILL DROP an incoming SYN/ACK on an interface different from
> the one the SYN was seen on.
> This means that the squid proxy and the clients must be on the same interface
> of the firewall. If you try to make a dmz with the proxy, and use wccp on
> the firewall between the dmz and the clients, it won't work.
>
> If any of this is wrong I'd love to know as well, as these are my working
> understandings of the system.
>
Thats probably how it goes, seems like it...
Heres what I've done... I moved the whole setup to a another server
thats behind 3 NATs.
I then could drop ALL my firewall rules except the one to redirect from the GRE
to the cache. NOW
it seems to work.
So my NEXT question is, is anyone doing this on a Centos 4 box using
their
default (I think its called RH-Firewall-1-INPUT chain) firewall? It seems like
it was doing something
there that was killing it all. (And I did add 3128:tcp to its list of allow
ports)
Thanks, Tuc
