[squid-users] How to enable proxy protocol v2 on squid version 4.6.1, and NLB

[Amos Jeffries]

On 21/06/19 10:45 pm, summaiya wrote:
> Hi All, 
> 
> I have deployed EC2 Egress URL Filtering Squid Proxy solution, I have used
> AWS PrivateLink to centralize web filtering in explicit mode. Squid proxy
> farm is implemented by a Network Load Balancer which distributes TCP
> requests across multiple Target Squid proxy instances, running in separate
> Availability Zones
> 
> My setup is similar to that mentioned in this blog :-
> https://aws.amazon.com/blogs/networking-and-content-delivery/how-to-use-aws-privatelink-to-secure-and-scale-web-filtering-using-explicit-proxy/
> 
> I have installed Squid version 4.6.1, but the access log do not show the
> client ip address, even though I added the below rules:- 
> http_port 3128 require-proxy-header
> http_port 3128

You cannot have two identical listening ports. Remove the second.

> proxy_protocol_access allow localnet
> 

This access control is supposed to *only* match true for the specific
machines who are allowed to send PROXY protocol traffic to your Squid
(aka the where A/B machinery).

WARNING: If you open it to a whole network like AWS you are effectively
allowing anyone else with AWS hosted services to use your proxy and
worse, to control what information shows up in your log files - so you
cannot see who the abuser/attacker is. Use these features with extreme
care, they actively hide attacks from your regular logging view(s).


> The proxy settings at the client are below :-
> [root at ip-172-16-1-99 ~]# export | grep proxy
> declare -x
> http_proxy="http://vpce-05a51748abb0bfd68-4e77o32h.vpce-svc-070d1304cc7cc5b5f.eu-west-2.vpce.amazonaws.com:3128"
> declare -x
> https_proxy="http://vpce-05a51748abb0bfd68-4e77o32h.vpce-svc-070d1304cc7cc5b5f.eu-west-2.vpce.amazonaws.com:3128"
> declare -x no_proxy="169.254.169.254
> 
> But still the access logs do not show the client ip address, am I missing
> something in the solution.Do I have to enable the proxy protocol v2 at NLB
> level as welll, will it break the application? 
> I checked most of the similar blogs, but I did not find any proper solution.
> 

Since you do not already know the answer to that question I suspect you
may be misunderstanding what PROXY protocol is.

PROXY is a wrapper protocol for use between two intermediaries. Such
that the frontend one can inform the backend about details of TCP
connections it is relaying.


>From your log below it looks like the NLB is the frontend and Squid the
backend. But I am not completely clear on your full HTTP route design,
so there may be other middleware agents to take into account.

Hopefully the above details can help you answer the question for
yourself about where to enable PROXY and whether its actually usable in
your topology. Keep in mind that others using it for their designs does
not mean yours is able to.


> Squid Access logs :- showing ip address of NLB not client ip address 
> 
> [root at ip-10-0-0-193 squid]# cat access.log
> 1560426278.960      0 10.0.0.17 TAG_NONE/400 4546 NONE error:invalid-request
> - HIER_NONE/- text/html
> 1560426279.647      0 10.0.0.17 TAG_NONE/400 4546 NONE error:invalid-request
> - HIER_NONE/- text/html
> 
> Kindly provide some steps which I need to take care at squid servers conf
> file and at client instance.

10.0.0.17 is connecting to your Squid and sending something which is not
a PROXY protocol header.

So yes at very least *if* that is a middleware machine; then it needs to
support sending PROXY protocol (and to have it enabled).

Amos