>
> From: "Amos Jeffries" <squid3@treenet.co.nz>
>
>
> 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
Received on Mon Oct 22 2007 - 21:54:15 MDT
This archive was generated by hypermail pre-2.1.9 : Thu Nov 01 2007 - 13:00:01 MDT