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.13
