Intercepting proxy creates forwading loop

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Intercepting proxy creates forwading loop

Patrick Nick
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 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: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.
I assume that squid should receive the request and then send it on to what's specified in the "Host:" header. Is this wrong? What kind of loop is forming here and how do I break it?


_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: Intercepting proxy creates forwading loop

Yuri Voinov

http://www.squid-cache.org/mail-archive/squid-users/201105/0264.html

http://squid-web-proxy-cache.1019090.n4.nabble.com/Squid-3-5-1-intercept-Forwarding-loop-detected-for-td4669756.html

https://www.google.com/search?q=Squid+forwarding-loop

This can helps?


16.03.2018 23:57, Patrick Nick пишет:
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 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: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.
I assume that squid should receive the request and then send it on to what's specified in the "Host:" header. Is this wrong? What kind of loop is forming here and how do I break it?



_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users

-- 
"C++ seems like a language suitable for firing other people's legs."

*****************************
* C++20 : Bug to the future *
*****************************

_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users

signature.asc (673 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Intercepting proxy creates forwading loop

Amos Jeffries
Administrator
In reply to this post by Patrick Nick
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
_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users