Behnam B.Marandi wrote:
> I'm testing a squid/tproxy enable cache machine in a network with some 
> clients. one of them does NAT it's users via a PIX machine. Every time 
> we put them behind tproxy/squid, web transfer slows down which is almost 
"slows down" is not specific enough and depends on what you consider 
fast. It's possibly normal or possibly due to loops somewhere or 
possibly faults/delays in the supporting DNS and processing lookups 
Squid must perform.
> unusable and most queries got time out response.
If you are having packet loss issues check for MTU, ECN, and TCP Window 
issues then take a very close and detailed look at the packet routing 
flows. TPROXY requires that there must be no confusion at any point what 
packets are what, and the pre-spoof and post-spoof flows must be kept 
separate.
If there is any point or box which processes both flows be VERY careful 
that the rules involved do not use IP address to decide anything important.
NP: its okay to configure say,
   if src/dst IP is in range X look closer for tproxy flags Y and base 
decision on that,
but DONT whatever you do go:
  if IP is in range X pass out interface Z.
> 
> Does anybody know why this happen? If a packet NAT once - or twice - 
> before cache machine, then tproxy might not be able to route it correctly?
> 
TPROXY only spoofs the 'client' IP used to directly connect to the Squid 
box, on stuff outgoing from Squid. It's not affected by NAT on other 
boxes. IMO, it _is_ likely to be affected and non-compatible with NAT on 
the same box (we have no confirmed cases for or against yet to be certain).
Amos
-- Please be using Current Stable Squid 2.7.STABLE6 or 3.0.STABLE18 Current Beta Squid 3.1.0.13Received on Sun Aug 09 2009 - 02:50:12 MDT
This archive was generated by hypermail 2.2.0 : Sun Aug 09 2009 - 12:00:03 MDT