<div dir="ltr">Thanks for your reply, Amos.<div class="gmail_extra"><br><div class="gmail_quote">On Mon, Jun 12, 2017 at 9:50 PM, Amos Jeffries <span dir="ltr"><<a href="mailto:squid3@treenet.co.nz" target="_blank">squid3@treenet.co.nz</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 13/06/17 13:48, David Kewley wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I want my clients to explicitly address squid as a proxy (not use tproxy), but have squid spoof the source addresses in the forwarded connection, so that further hops know the original source address from the IPv4 headers.<br>
<br>
I could find no indication that anyone else has done this, and when I tried various things, I could not get it working.<br>
<br>
Is this possible today? If not, is it worth considering as a future feature? Or am I overlooking a reason that this cannot work even in theory?<br>
</blockquote>
<br></span>
It is not possible.<br>
<br>
No, it is a terrible idea.<br>
<br>
It is prohibited by the OS kernel as part of the anti-malware protections, in this case to prevent the local machine being used to attack its surrounding network nodes. And by Squid to make it harder to use Squid as viral payload and damage the brand reputation.<br></blockquote><div><br></div><div>What exactly is the "it" that you're saying is prohibited by the OS kernel? Source spoofing alone, or something else?</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Also, HTTP contains multiplexing and persistent connections. So there is no particular relation between one incoming/client connection and the outgoing/server connection(s) the traffic from that client goes out on. Added to that, a client request may generate multiple outgoing requests of various types, or Squid may itself generate traffic for its own needs without any client interaction.<br>
<br>
So doing this just degrades the proxy performance. And not in a small way - intercepted traffic pinning everything as this would need comes out about 10% nominal (90% reduction), and at the extreme end proxies with NTLM going through to an origin see only 1% of nominal performance. Nominal for me being what I clocked a big clients network doing in real-world traffic a few years back: ~20000 requests per second a few years back (Squid Project got approx 2x that in controlled lab tests).</blockquote><div><br></div><div>Good to know there are strong performance implications, thanks. I don't understand these systems deeply enough to have anticipated this, so I appreciate the heads-up. Too many systems to learn, too quickly...</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I got the nearly-equivalent functionality working for reverse proxying using nginx, but so far I've found no way to do it with forward proxying. Nginx doesn't do https forward proxying (no handling of CONNECT).<br>
</blockquote>
<br></span>
So Nginx can be used to attack networks from inside. Good no know we now have to watch out for that in viral payloads too.</blockquote><div><br></div><div>"Can be used to attack" because of source spoofing, or something else?</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
If squid can't do what I'm looking for today, I would welcome pointers to other possible approaches.<br>
</blockquote>
<br></span>
Squid supports X-Forwarded-For fully - it was invented by Squid devs back in the day, and Squid is still the authoritative implementation for how it is supposed to work. As an old feature just about all other HTTP server and intermediary software have support for that too so you should have no issue pulling the data out at the receiving end, or in HTTP processing DPI software / firewalls etc. It is sent on all outgoing Squid messages unless you explicitly configure something else to happen with the forwarded_for directive.<br>
 <<a href="http://www.squid-cache.org/Doc/config/forwarded_for/" rel="noreferrer" target="_blank">http://www.squid-cache.org/D<wbr>oc/config/forwarded_for/</a>><br></blockquote><div><br></div><div>I'll ask the team managing the next-hop device to evaluate that possibility; it looks to me from the docs like it might work. Thanks for the suggestion.</div><div></div></div><br></div><div class="gmail_extra">David</div></div>