Re: [squid-users] Re: TCP_MISS/Squid-Error: ERR_CONNECT_FAIL

Hi All,
   In my case, tcp connection established between browser and internet
IP's with tproxy.

root_at_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)
tcp 0 1 172.30.11.122:57210 172.30.11.124:80
SYN_SENT 31895/(squid)
tcp 0 0 172.30.11.124:80 172.30.11.122:35454
ESTABLISHED 31895/(squid)

There is an issue in establishing the tcp connection between squid and
internet 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.

root_at_debian:~# ip rule list
0: from all lookup local
32765: from all fwmark 0x1 lookup 100
32766: from all lookup main
32767: from all lookup default
root_at_debian:~# ip route show table 100
local default dev lo scope host
root_at_debian:~#

I followed the the below link for configuring the tproxy and squid stuffs
http://wiki.squid-cache.org/Features/Tproxy4

Any help would be greatly appreciated.

Regards,
Saravanan N

On Thu, Aug 15, 2013 at 4:14 PM, SaRaVanAn
<saravanan.nagarajan87_at_gmail.com> wrote:
> Hi Amos,
> I have uploaded wire-shark dump captured in web-server in the below
> link for your reference.
>
> https://rapidshare.com/files/3145946000/packet_capture_Squid.pcap
>
> (I uploaded, since I faced some problems in Sending here).
>
> Please use the filter tcp to make the dump more clear since it has
> some unnecessary packets.
>
> As per my understanding, initial TCP connection has been established
> between client <-> squid.But there is a problem in establishing TCP
> connection between squid<->server.
>
> I could not able to see the SYN sent by squid in wireshark capture.
> But I could see webserver is sending SYN+ACK in response to that. The
> SYN+ACK sent by webserver was reaching client web machine. Web Client
> machine was sending RST in response to that since it has no idea about
> the port.
>
>
> % netstat -n
> ----------------------
> Active Internet connections
>
> Proto Recv-Q Send-Q Local Address Foreign Address state
>
> tcp4 0 0 172.30.11.122:35123 172.30.11.124:80 ESTABLISHED
> tcp4 0 1 172.30.11.122.22080 172.30.11.124.80 SYN_SENT
> .................
>
>
> The port of local address in SYN_SENT state keep on changing.
> 1) Why is it so?
>
> I presume, Squid has to reply for SYN+ACK sent by web-server
>
> 2) why its reaching web client machine?
>
> 3) what is the normal working behavior?
>
> 4) Whether squid is not able to reach web-server since its sitting on
> the same machine ?
> Note: I am accessing web-server from client machine directly using IP
> without domain name
>
> The same setup and configurations are working fine in case of NAT
> redirection rules without tproxy.
>
> Please help me since I m new to squid. I will give you more details if you want.
>
> Regards,
> Saravanan N
>
> On Thu, Aug 15, 2013 at 5:23 AM, Amos Jeffries <squid3_at_treenet.co.nz> wrote:
>> On 2013-08-13 05:20, SaRaVanAn wrote:
>>>
>>> Hi All,
>>> I observed there is a difference in tcp state machine in both
>>> working(without squid) and Not working scenario.(without squid)
>>>
>>> State machine in working scenario (without squid)
>>> ----------------------------------------------------
>>> client Server
>>> SYN
>>> --------------->
>>> SYN + ACK
>>> <-------------------------
>>> ACK
>>> -------------------------->
>>> GET
>>> --------------------------->
>>> ACK
>>> <----------------------------
>>> TCP segment of a resembled PDU (MTU 1514)
>>> <---------------------------
>>> HTTP/1.1 200 ok (MTU 293)
>>> <------------------------
>>> then connection terminates
>>>
>>>
>>> State machine in Not-working scenario (with squid)
>>
>>
>> You say "with squid". But when Squid is in the picture there are *two* TCP
>> connections operating asynchronously to transfer the request and response
>> client<->squid and squid<->server.
>>
>>
>> What you describe below appears to be a single TCP connections operations,
>> except that there are things happenign on it which are impossible (RST
>> followed by successful packets exchanges). TCP level aborts and resets on
>> one connection affect the other in various ways defined by HTTP semantics
>> and recovery (not TCP synchronous).
>>
>> So what we need is labeling the packets as per which TCP connection it
>> occured on and how the packets on each are sequenced/interleaved across
>> both.
>>
>> For example:
>>
>>
>>> ----------------------------------------------------
>>>
>>> client Server
>>> SYN
>>> --------------->
>>> SYN + ACK
>>> <-------------------------
>>> ACK
>>> -------------------------->
>>> GET
>>> --------------------------->
>>> ACK
>>> <----------------------------
>>> SYN + ACK
>>> <---------------------------
>>> RST
>>> ------------------------>
>>
>>
>> ... after a RST packet is received Squid runs through the connection
>> shutdown code which *doe not* involve delivering any more HTTP on *that*
>> connection.
>>
>> I assume that this is the squid<-><server connection dying.
>>
>>
>>> TCP previous segment not captured
>>> <------------------------------
>>> RST
>>> ------------------------>
>>> TCP last segment not captured
>>> <------------------------------
>>> .........
>>>
>>> TCP segment of a resembled PDU (MTU 1514)
>>> <-------------------------
>>> TCP segment of a resembled PDU (MTU 1514)
>>> <-------------------------
>>> HTTP/1.0 504 Gateway timeout (MTU 1050)
>>> <-----------------------------
>>
>>
>> .. so this response
>>
>>
>>>
>>> then connection terminates
>>>
>>> In case of squid running ,
>>> 1) Why web-server is sending "SYN+ACK" instead of "TCP last segment
>>> not captured" PDU?
>>
>>
>> Because Squid opened the second (squid<->server) connection with a SYN
>> packet that you missed out of the trace?
>>
>>
>>>
>>> 2) Why there is a delay in sending "TCP last segment not captured" PDU?
>>
>>
>> Unknown. What does that "last segment not captured" mean exactly?
>>
>> I think you mean the packet was not fully recorded by the tcpdump program?
>> Try using "-s 0" parameter (or 65535) to do full packet payload capture.
>>
>> I also recommend saving the trace to a file (-w option) and using wireshark
>> to read the capture instead of trying to read the tcpdump command-line
>> abbreviations.
>>
>>
>>
>>>
>>> Moreover I could see there is a variation in HTTP version (1.0 and 1.1) .
>>
>>
>> Because each of the three agents is advertising to each other what highest
>> minor version of HTTP/1.x they are compliant with.
>>
>>
>> Amos
Received on Sat Aug 17 2013 - 16:40:03 MDT