<div dir="ltr">Got it. Thanks for your help, Alex!</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Oct 19, 2021 at 9:27 PM Alex Rousskov <<a href="mailto:rousskov@measurement-factory.com">rousskov@measurement-factory.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 10/19/21 4:56 PM, Ty Martin wrote:<br>
<br>
> That `--haproxy-protocol` option seems like it should have done the<br>
> trick. Am I just shooting myself in the foot with bad curl commands?<br>
<br>
It look like curl --haproxy-protocol does not work the way you want for<br>
HTTPS requests sent through HTTP proxies:<br>
<br>
> curl --haproxy-protocol -x <a href="http://127.0.0.1:3128/" rel="noreferrer" target="_blank">http://127.0.0.1:3128/</a> https://...<br>
>> CONNECT localhost:443 HTTP/1.1<br>
...<br>
> < HTTP/1.1 200 Connection established<br>
><br>
> * Proxy replied 200 to CONNECT request<br>
> * CONNECT phase completed!<br>
<br>
>> PROXY TCP4 127.0.0.1 127.0.0.1 35628 3128<br>
<br>
The above PROXY protocol message is sent to the HTTP origin server<br>
inside the CONNECT tunnel instead of being sent to Squid _before_ the<br>
tunnel.<br>
<br>
<br>
A similar curl command "works" for plain HTTP requests (because, without<br>
CONNECT, it is impossible to distinguish the target of the PROXY<br>
protocol message):<br>
<br>
> curl --haproxy-protocol -x <a href="http://127.0.0.1:3128/" rel="noreferrer" target="_blank">http://127.0.0.1:3128/</a> http://...<br>
> * Connected to 127.0.0.1 (127.0.0.1) port 3128 (#0)<br>
>> PROXY TCP4 127.0.0.1 127.0.0.1 35634 3128<br>
>> GET http://... HTTP/1.1<br>
<br>
FWIW, my v5.2-based Squid groks the above correctly, forwarding the<br>
request (if proxy_protocol_access allows it). This indicates that the<br>
basic PROXY protocol support in my Squid works.<br>
<br>
<br>
Unfortunately, there is no curl --proxy-haproxy-protocol (yet?) so you<br>
will need to find another way to test. Alternatively, you can share<br>
Squid debugging logs and/or packet captures when using your network load<br>
balancer.<br>
<br>
<br>
Alex.<br>
<br>
<br>
> On Mon, Oct 18, 2021 at 5:32 PM Alex Rousskov wrote:<br>
> <br>
> On 10/18/21 5:16 PM, Ty Martin wrote:<br>
> > Ah, yep. Adding the following to my config got things working in AWS:<br>
> <br>
> > acl private src <a href="http://172.0.0.0/8" rel="noreferrer" target="_blank">172.0.0.0/8</a> <<a href="http://172.0.0.0/8" rel="noreferrer" target="_blank">http://172.0.0.0/8</a>><br>
> > proxy_protocol_access allow private<br>
> > http_port 3128 require-proxy-header<br>
> <br>
> <br>
> > I was trying to test it locally without success by running the Docker<br>
> > container and hitting it with a curl along the lines of:<br>
> > `curl --proxy http://<un>:<pw>@localhost:3128 -v --header<br>
> > "X-Forwarded-For: 192.168.0.2" <a href="https://www.google.com" rel="noreferrer" target="_blank">https://www.google.com</a><br>
> <<a href="https://www.google.com" rel="noreferrer" target="_blank">https://www.google.com</a>><br>
> <br>
> To test using curl, try curl --haproxy-protocol ...<br>
> <br>
> PROXY protocol (all versions) is not HTTP.<br>
> <br>
> Alex.<br>
> <br>
> <br>
> > --- Resulting Squid logs ---<br>
> > ```<br>
> > squid-proxy_1 | 2021/10/18 19:55:33| PROXY protocol error:<br>
> invalid magic<br>
> > squid-proxy_1 | exception location: Parser.cc(260) Parse from<br>
> conn6<br>
> > local=<a href="http://172.24.0.2:3128" rel="noreferrer" target="_blank">172.24.0.2:3128</a> <<a href="http://172.24.0.2:3128" rel="noreferrer" target="_blank">http://172.24.0.2:3128</a>><br>
> <<a href="http://172.24.0.2:3128" rel="noreferrer" target="_blank">http://172.24.0.2:3128</a> <<a href="http://172.24.0.2:3128" rel="noreferrer" target="_blank">http://172.24.0.2:3128</a>>><br>
> remote=<a href="http://172.24.0.1:65426" rel="noreferrer" target="_blank">172.24.0.1:65426</a> <<a href="http://172.24.0.1:65426" rel="noreferrer" target="_blank">http://172.24.0.1:65426</a>><br>
> > <<a href="http://172.24.0.1:65426" rel="noreferrer" target="_blank">http://172.24.0.1:65426</a> <<a href="http://172.24.0.1:65426" rel="noreferrer" target="_blank">http://172.24.0.1:65426</a>>> FD 12 flags=1<br>
> > squid-proxy_1 | connection: conn6 local=<a href="http://172.24.0.2:3128" rel="noreferrer" target="_blank">172.24.0.2:3128</a><br>
> <<a href="http://172.24.0.2:3128" rel="noreferrer" target="_blank">http://172.24.0.2:3128</a>><br>
> > <<a href="http://172.24.0.2:3128" rel="noreferrer" target="_blank">http://172.24.0.2:3128</a> <<a href="http://172.24.0.2:3128" rel="noreferrer" target="_blank">http://172.24.0.2:3128</a>>><br>
> remote=<a href="http://172.24.0.1:65426" rel="noreferrer" target="_blank">172.24.0.1:65426</a> <<a href="http://172.24.0.1:65426" rel="noreferrer" target="_blank">http://172.24.0.1:65426</a>><br>
> > <<a href="http://172.24.0.1:65426" rel="noreferrer" target="_blank">http://172.24.0.1:65426</a> <<a href="http://172.24.0.1:65426" rel="noreferrer" target="_blank">http://172.24.0.1:65426</a>>> FD 12 flags=1<br>
> > ```<br>
> ><br>
> > --- Resulting client logs ---<br>
> > ```<br>
> > * Proxy CONNECT aborted<br>
> > * CONNECT phase completed!<br>
> > * Closing connection 0<br>
> > curl: (56) Proxy CONNECT aborted<br>
> > ```<br>
> ><br>
> > Any idea offhand what I'm missing from the local testing scenario? I<br>
> > thought adding a "X-Forwarded-For" header via curl would be treated as<br>
> > proxy protocol v1 by Squid, but the "invalid magic" protocol error<br>
> gives<br>
> > me the impression I'm not going about it the right way.<br>
> ><br>
> > On Mon, Oct 18, 2021 at 12:48 PM Alex Rousskov<br>
> > <<a href="mailto:rousskov@measurement-factory.com" target="_blank">rousskov@measurement-factory.com</a><br>
> <mailto:<a href="mailto:rousskov@measurement-factory.com" target="_blank">rousskov@measurement-factory.com</a>><br>
> > <mailto:<a href="mailto:rousskov@measurement-factory.com" target="_blank">rousskov@measurement-factory.com</a><br>
> <mailto:<a href="mailto:rousskov@measurement-factory.com" target="_blank">rousskov@measurement-factory.com</a>>>> wrote:<br>
> ><br>
> > On 10/18/21 12:11 PM, Ty Martin wrote:<br>
> ><br>
> > > I am looking to run Squid as a forward proxy with basic auth<br>
> in Docker<br>
> > > on AWS ECS behind a network load balancer. I seem to have things<br>
> > up and<br>
> > > running for the most part; however, I am having difficulty<br>
> in getting<br>
> > > proxy protocol to work so that I get access to client IP<br>
> addresses<br>
> > > beyond that of the private IPs of my NLB. As soon as I<br>
> enable proxy<br>
> > > protocol v2 on the AWS NLB, requests to Squid start failing with<br>
> > errors<br>
> > > similar to the following:<br>
> > ><br>
> > > Squid log: `1634330668.200 5 <nlb-private-ip> NONE_NONE/400<br>
> > 2032 -<br>
> > > error:invalid-request - HIER_NONE/- text/html`<br>
> > > Client log: `X-Squid-Error: ERR_PROTOCOL_UNKNOWN 0`<br>
> ><br>
> > > http_port 3128<br>
> ><br>
> > You must use require-proxy-header http_port option to tell<br>
> Squid to<br>
> > always expect/require PROXY protocol messages on connections<br>
> to that<br>
> > listening port. Otherwise, Squid will expect naked HTTP<br>
> traffic and<br>
> > fail to parse incoming (PROXY protocol) connection bytes.<br>
> ><br>
> > According to proxy_protocol_access documentation, after adding<br>
> > require-proxy-header to http_port, you must also use<br>
> > proxy_protocol_access to tell Squid which TCP connections to<br>
> allow on<br>
> > that port (and, hence, which PROXY protocol messages to<br>
> trust). Denied<br>
> > connections will be closed.<br>
> ><br>
> ><br>
> > HTH,<br>
> ><br>
> > Alex.<br>
> ><br>
> <br>
<br>
</blockquote></div>