Hi, 2005-04-05, k keltezéssel 15.40-kor Wayne Smith ezt írta:

Sorry for the self follow up, but a little more info

The workstation that is doing the requesting ends up receiving packets with syn/ack set. The workstation that did the requesting never actually creates an initial syn packet to the apache server (squid was doing that in it's behalf after getting the response from the redirector script).

What type of packet mangling is required to have the locally produced (but spoofed) syn from squid get its response to occur locally?

Again, I'm hoping I have the right forum. It's a patched kernel to allow the truly transparent proxy, but it's also a hacked squid to take advantage of that functionality. As far as I can tell, squid is doing it's job making the connection to apache, but the reply ends up going out the NIC to the workstation instead of being grabbed and thrown back to squid.

Any help appreciated.

This seems to be the effect of a limitation of the tproxy kernel patch: source address faking does not work for traffic sent to localhost. Unfortunately I don't know of any quick fix for that problem, so you're left with two choices: * you try to configure Squid so that it doesn't try to fake the source address when connecting to the apache running on localhost * you move the apache serving the cached update files to a separate machine I don't know whether or not the first option can be done with the current Squid patch, but it would be a useful feature to avoid problems like this one. -- Regards, Krisztian Kovacs