<div dir="ltr">Shucks. No dice. I tried the following three variations, which all resulted in the same "invalid magic" proxy protocol errors in the squid logs and connection aborted errors in the curl logs as before:<div><br></div><div>```</div><div>curl --haproxy-protocol --proxy http://<un>:<pw>@localhost:3128 -v <a href="https://www.google.com">https://www.google.com</a><br></div><div>curl --haproxy-protocol --proxy http://<un>:<pw>@localhost:3128 -v --header "X-Forwarded-For: 192.168.0.2" <a href="https://www.google.com">https://www.google.com</a><br></div><div>curl --haproxy-protocol --proxy http://<un>:<pw>@localhost:3128 -v --proxy-header "X-Forwarded-For: 192.168.0.2" <a href="https://www.google.com">https://www.google.com</a><br></div><div>```</div><div><br></div><div>That `--haproxy-protocol` option seems like it should have done the trick. Am I just shooting myself in the foot with bad curl commands?</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Oct 18, 2021 at 5:32 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/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><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>
<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: invalid magic<br>
> squid-proxy_1 | exception location: Parser.cc(260) Parse from 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>> remote=<a href="http://172.24.0.1:65426" rel="noreferrer" target="_blank">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>> 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>> remote=<a href="http://172.24.0.1:65426" rel="noreferrer" target="_blank">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>> 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 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>>> 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 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 in getting<br>
> > proxy protocol to work so that I get access to client IP addresses<br>
> > beyond that of the private IPs of my NLB. As soon as I 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 Squid to<br>
> always expect/require PROXY protocol messages on connections to that<br>
> listening port. Otherwise, Squid will expect naked HTTP 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 allow on<br>
> that port (and, hence, which PROXY protocol messages to trust). Denied<br>
> connections will be closed.<br>
> <br>
> <br>
> HTH,<br>
> <br>
> Alex.<br>
> <br>
<br>
</blockquote></div>