On 21/12/2012 3:44 a.m., Ali Jawad wrote:
Hi
I did miss to point out an important factor, the server is a remote
transparent proxy, in other words
my pc "uses a custom dns to point certain sites to proxy server" --
Internet Gateway ---- Transparent proxy with public IP and redirect
port 80 to proxy
So you have:
1) custom DNS pointing webstes at the proxy with "transparent" option set?
--> BROKEN. DNS pointing at a proxy is "reverse-proxy" configuration.
http_port requires reverse-proxy "accel" option and related settings.
2) a "transparent" proxy (which type? there there are 5 types of
"transparent" supported by Squid today, all of which work very diferently)
redirecting traffic to itself.
--> BROKEN. lookup "forwarding loops" for lot of detaisl on what is
wrong with that.
If I make two assumptions about your setup and the error (which you
still have not presented proper details about). I can assume that the
3.3 is rejecting your traffic at the Host: header validation stage, when
the TCP destination IP address is not found in the kernel NAT tables or
the one found does not match the HTTP request destination domain. There
are several major problems with NAT interception methods which means the
NAT operation *must* be performed on the Squid box - this rejection is
the visible result of remote-box NAT operation sending conflicting
information at TCP/IP and HTTP protocol layers.
Amos