On 18/08/2013 4:39 a.m., SaRaVanAn wrote:
Hi All,
In my case, tcp connection established between browser and internet
IP's with tproxy.
root@debian:~# netstat -natp | grep squid
tcp 0 0 0.0.0.0:3128 0.0.0.0:*
LISTEN 31895/(squid)
tcp 0 0 0.0.0.0:3129 0.0.0.0:*
LISTEN 31895/(squid)
These next two connections look like:
tcp 0 1 172.30.11.122:57210 172.30.11.124:80
SYN_SENT 31895/(squid)
Squid (pretending to be client 172.30.11.124) connecting to server
172.30.11.122.
tcp 0 0 172.30.11.124:80 172.30.11.122:35454
ESTABLISHED 31895/(squid)
client 172.30.11.124 to server 172.30.11.122 (being received by Squid
instead).
Since the server and the client are on the same subnet range I think you
are hitting the "triangular routing" problem.
Where the server route table says that it should be sending packets for
172.30.11.* directly to the client instead of back through the Squid
box. The SYN packet would get TPROXY'd through Squid but the SYN-ACK
packet from the server would go to the client directly instead of Squid
and things go bad.
There is an issue in establishing the tcp connection between squid and
internet IP's.
Nope. There is a problem connecting between Squid and some server on
172.30.11.* IP's.
Squid is sending SYN request via loopback interface to the websever.
But the webserver is replying back to the browser directly, which in
turn initiates RST of the connection.
I am missing something in routing the packets back to the squid.
If the client was connecting to an Internet server the IP address
received by Squid as the destination should have been the Internet
global IP address for that server. Instead Squid got a 172.* address.
This looks a bit like like you have NAT going somewhere along the way
and changing that servers IP before Squid gets it.
Amos
