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:
```
curl --haproxy-protocol --proxy http://<un>:<pw>@localhost:3128 -v https://www.google.com
curl --haproxy-protocol --proxy http://<un>:<pw>@localhost:3128 -v --header "X-Forwarded-For: 192.168.0.2" https://www.google.com
curl --haproxy-protocol --proxy http://<un>:<pw>@localhost:3128 -v --proxy-header "X-Forwarded-For: 192.168.0.2" https://www.google.com
```
That `--haproxy-protocol` option seems like it should have done the trick. Am I just shooting myself in the foot with bad curl commands?
On Mon, Oct 18, 2021 at 5:32 PM Alex Rousskov <rousskov@xxxxxxxxxxxxxxxxxxxxxxx> wrote:
On 10/18/21 5:16 PM, Ty Martin wrote:
> Ah, yep. Adding the following to my config got things working in AWS:
> acl private src 172.0.0.0/8
> proxy_protocol_access allow private
> http_port 3128 require-proxy-header
> I was trying to test it locally without success by running the Docker
> container and hitting it with a curl along the lines of:
> `curl --proxy http://<un>:<pw>@localhost:3128 -v --header
> "X-Forwarded-For: 192.168.0.2" https://www.google.com
To test using curl, try curl --haproxy-protocol ...
PROXY protocol (all versions) is not HTTP.
Alex.
> --- Resulting Squid logs ---
> ```
> squid-proxy_1 | 2021/10/18 19:55:33| PROXY protocol error: invalid magic
> squid-proxy_1 | exception location: Parser.cc(260) Parse from conn6
> local=172.24.0.2:3128 <http://172.24.0.2:3128> remote=172.24.0.1:65426
> <http://172.24.0.1:65426> FD 12 flags=1
> squid-proxy_1 | connection: conn6 local=172.24.0.2:3128
> <http://172.24.0.2:3128> remote=172.24.0.1:65426
> <http://172.24.0.1:65426> FD 12 flags=1
> ```
>
> --- Resulting client logs ---
> ```
> * Proxy CONNECT aborted
> * CONNECT phase completed!
> * Closing connection 0
> curl: (56) Proxy CONNECT aborted
> ```
>
> Any idea offhand what I'm missing from the local testing scenario? I
> thought adding a "X-Forwarded-For" header via curl would be treated as
> proxy protocol v1 by Squid, but the "invalid magic" protocol error gives
> me the impression I'm not going about it the right way.
>
> On Mon, Oct 18, 2021 at 12:48 PM Alex Rousskov
> <rousskov@xxxxxxxxxxxxxxxxxxxxxxx
> <mailto:rousskov@xxxxxxxxxxxxxxxxxxxxxxx>> wrote:
>
> On 10/18/21 12:11 PM, Ty Martin wrote:
>
> > I am looking to run Squid as a forward proxy with basic auth in Docker
> > on AWS ECS behind a network load balancer. I seem to have things
> up and
> > running for the most part; however, I am having difficulty in getting
> > proxy protocol to work so that I get access to client IP addresses
> > beyond that of the private IPs of my NLB. As soon as I enable proxy
> > protocol v2 on the AWS NLB, requests to Squid start failing with
> errors
> > similar to the following:
> >
> > Squid log: `1634330668.200 5 <nlb-private-ip> NONE_NONE/400
> 2032 -
> > error:invalid-request - HIER_NONE/- text/html`
> > Client log: `X-Squid-Error: ERR_PROTOCOL_UNKNOWN 0`
>
> > http_port 3128
>
> You must use require-proxy-header http_port option to tell Squid to
> always expect/require PROXY protocol messages on connections to that
> listening port. Otherwise, Squid will expect naked HTTP traffic and
> fail to parse incoming (PROXY protocol) connection bytes.
>
> According to proxy_protocol_access documentation, after adding
> require-proxy-header to http_port, you must also use
> proxy_protocol_access to tell Squid which TCP connections to allow on
> that port (and, hence, which PROXY protocol messages to trust). Denied
> connections will be closed.
>
>
> HTH,
>
> Alex.
>
_______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
