> > From: "Amos Jeffries" <squid3@xxxxxxxxxxxxx> > > > Thanks for the quick response :- > >> >> Most common failure like this requires 'you need to patch the kernel', >> but >> it sounds like that's been done. >> > > Yupe this has been done. > >> Next step is seeing what tcpdump shows about the two types of traffic. >> And possibly what type of router/balancer is doing the splitting? >> > > This has been done too. Very clearly, tcpdump shows that for the > none NAT-ed leg, the identity of the original requests have been > spoofed, but the bad thing is that, it also spoofed the NAT-ed leg > as well despite there is a POSTROUTING rule to do SNAT in > the nat table. Seems to me the 'tproxy' directive in squid makes > iptables nat POSTROUTING SNAT useless ! No not useless. The NAT should be symmetrically unmangling any mangled destination on incoming traffic. As far as NAT is concerned the client is the real requestor. You just need to be careful that the unmangling happens BEFORE the tproxy return redirection toward squid. The internal side of the NAT gateway can and should be treated identical to the non-NAT firewall you mentioned. Both need to operate independant of tproxy and on the external side of any tproxy operations. Amos
