[squid-users] Intercepting proxy creates forwading loop

[Amos Jeffries]

On 17/03/18 06:57, Patrick Nick wrote:
> Hello list, 
> 
> I have resolved first problem about cache_peer using Kerberos
> authentication. Now I want to make that setup transparent/intercepting.
> Keep in mind that my situation does NOT involve browsers or port 80 at
> any point, it's a pure machine-to-machine API communication.
> 
> I have added the "intercept" keyword to my config, here is a part of my
> config that seems relevant:
> 
> http_port 3128 intercept
> cache_peer my.company.webserver.net
> <http://my.company.webserver.net/> parent 8081 0 no-query
> login=NEGOTIATE:myPrincipal originserver
> 
> And here is how I test it by using the rather new curl option
> "--connect-to" which allows to send the request to a different host:port
> than specified in the "Host:" http header:
> 
> curl -b ~/cookies.txt -c ~/cookies.txt -H'Content-Type:
> application/json' "http://my.company.host.net:8081/status" --connect-to
> "my.company.host.net:8081
> <http://my.company.host.net:8081>:my.squid.host.net:3128
> <http://my.squid.host.net:3128>" -v
> 
> The result is always "HTTP/1.1 403 Forbidden" and in the logs I see
> "WARNING: Forwarding loop detected for:".
> 
> I don't understand how a loop can form. I've seen many tutorials talking
> about using iptables to redirect traffic to a different port, but I
> don't think that I need that, since the curl-option should take care of
> that.

You absolutely DO need the iptables part, because Squid "intercept" is
integrated with the machines NAT system. Squid outbound connection for
intercepted traffic prefers the same IP:port the client used (aka
transparency) to avoid security issues like CVE-2009-0801.

Since curl did a "connect-to" to Squid's IP:port directly and
my.squid.host.net != my.company.host.net ... Squid copies that with a
connection to my.squid.host.net:3128 and sends the request for
my.company.host.net:8081 there. Et Voila`, Loop.


> I assume that squid should receive the request and then send it on to
> what's specified in the "Host:" header. Is this wrong?

Sort of wrong yes. Squid uses the TCP connection IP:port with
modification to undo NAT in accordance with the local machines NAT
records. Host header (and thus caching which relies on it) is only used
if it correlates reliably with those details.


> What kind of loop is forming here and how do I break it?

A transparent forwarding loop.

Add the iptables part of the config and send test requests *exactly* as
the clients would in their real traffic. No shortcuts like curl
--connect-to, unless that is actually how the client connects.


Amos