Re: [squid-users] Squid 3.3.5 problems with Tproxy

On 10/07/2013 2:12 a.m., x-man wrote:
> Hello,
>
> recently migrated from squid 3.1.19 to 3.3.5, and under 3.1.19 I was having
> perfect TPROXY setup working, and now absolutely same config is failing in
> 3.3.5

The only change related to TPROXY between 3.1 and 3.3 is the addition of
HTTP Host: header security.
Squid 3.3 is not only spoofing the client IP on the outgoing traffic but
is also sending any traffic which fails the Host: validation direct to
the original server IP being used by the client.

> This is the log I managed to get
>
> 91.239.13.61 is the web site i'm trying to open
>
> and 192.168.1.106 is my test PC IP address
>
> The browser shows error: "Error 324 (net::ERR_EMPTY_RESPONSE): The server
> closed the connection without sending any data."
>
> What can be the problem, and is it somehow related to this BUG #3329:
> ---
> 2013/07/09 19:39:04.523 kid1| Connection.cc(32) ~Connection: BUG #3329:
> Orphan Comm::Connection: local=91.239.13.61:80 remote=192.168.1.106:59222 FD
> 12 flags=17
> -----
>
>
>
> 2013/07/09 19:39:04.523 kid1| Intercept.cc(364) Lookup: address BEGIN:
> me/client= 91.239.13.61:80, destination/me= 192.168.1.106:59222
> 2013/07/09 19:39:04.523 kid1| TcpAcceptor.cc(264) acceptOne: Listener:
> local=[::]:8081 remote=[::] FD 15 flags=25 accepted new connection
> local=91.239.13.61:80 remote=192.168.1.106:59222 FD 12 flags=17 handler
> Subscription: 0x254b210*1
> 2013/07/09 19:39:04.523 kid1| AsyncCall.cc(18) AsyncCall: The AsyncCall
> httpAccept constructed, this=0x25529e0 [call141]
> 2013/07/09 19:39:04.523 kid1| cbdata.cc(419) cbdataInternalLock: cbdataLock:
> 0x21920e8=3
> 2013/07/09 19:39:04.523 kid1| AsyncCall.cc(85) ScheduleCall:
> TcpAcceptor.cc(292) will call httpAccept(local=91.239.13.61:80
> remote=192.168.1.106:59222 FD 12 flags=17, flag=-1, data=0x21920e8)
> [call141]
> 2013/07/09 19:39:04.523 kid1| ModEpoll.cc(139) SetSelect: FD 15, type=1,
> handler=1, client_data=0x254cc58, timeout=0
> 2013/07/09 19:39:04.523 kid1| AsyncCallQueue.cc(51) fireNext: entering
> httpAccept(local=91.239.13.61:80 remote=192.168.1.106:59222 FD 12 flags=17,
> flag=-1, data=0x21920e8)
> 2013/07/09 19:39:04.523 kid1| AsyncCall.cc(30) make: make call httpAccept
> [call141]
> 2013/07/09 19:39:04.523 kid1| cbdata.cc(510) cbdataReferenceValid:
> cbdataReferenceValid: 0x21920e8
> 2013/07/09 19:39:04.523 kid1| client_side.cc(3335) httpAccept: httpAccept:
> local=[::]:8081 remote=[::] FD 15 flags=25: accept failure: (0) No error.

Here is the problem. For some reason Squid is encountering an error
accept()'ing the new connection, but there is no system code or message
available about it.

Can you try with the latest 3.3 release please? any fix which you get
will be for the latest code.

> 2013/07/09 19:39:04.523 kid1| AsyncCallQueue.cc(53) fireNext: leaving
> httpAccept(local=91.239.13.61:80 remote=192.168.1.106:59222 FD 12 flags=17,
> flag=-1, data=0x21920e8)
> 2013/07/09 19:39:04.523 kid1| cbdata.cc(456) cbdataInternalUnlock:
> cbdataUnlock: 0x21920e8=2
> 2013/07/09 19:39:04.523 kid1| Connection.cc(32) ~Connection: BUG #3329:
> Orphan Comm::Connection: local=91.239.13.61:80 remote=192.168.1.106:59222 FD
> 12 flags=17
>
> Please share your thoughts....
>
>
>
>
> --
> View this message in context: http://squid-web-proxy-cache.1019090.n4.nabble.com/Squid-3-3-5-problems-with-Tproxy-tp4660968.html
> Sent from the Squid - Users mailing list archive at Nabble.com.
Received on Tue Jul 09 2013 - 14:38:51 MDT