Thank you for the reply Amos. I went back and read the documentation yesterday with a fresh set of eyes and realized what I was doing wrong. Your summary at the end of your reply is exactly where I ended up once I understood what the follow_x_forwarded_for directive was doing. To be fair, the documentation is straight-forward enough, I simply mis-understood what it was really doing (might have been lack of sleep). I ended up turning on debug and reading through cache.log to see the rule and it's lack of matching (that's when I went back and re-read the docs - having my light bulb moment). I modified my squid.conf almost exactly as you referenced (I didn't know I could put in a range of IPs like that for the haproxy hosts, so thanks!) and re-tested. The end result is exactly what I was expecting / hoping for. Hopefully this thread can serve as a clearer example for future generations ;) Cheers, Joey -----Original Message----- From: squid-users <squid-users-bounces@xxxxxxxxxxxxxxxxxxxxx> On Behalf Of Amos Jeffries Sent: Friday, June 7, 2019 4:34 AM To: squid-users@xxxxxxxxxxxxxxxxxxxxx Subject: Re: Attempting to use follow_x_forwarded_for in ACL On 7/06/19 2:38 am, Joey Officer wrote: > Greetings all, > > > > squid.conf references the ability to use the x-forwarded-for header in > ACLs by using the follow_x_forwarded_for in ACL, referenced here: > http://www.squid-cache.org/Doc/config/follow_x_forwarded_for/ and here > http://www.squid-cache.org/Doc/config/acl_uses_indirect_client/ > > > > There appear to be three pre-reqs, which I’ve met: > > > > squid.conf: acl_uses_indirect_client on > > squid built with --enable-follow-x-forwarded-for (confirmed) > > and the appropriate ACL entries (see below) > More correctly; configuration to tell Squid which clients to trust X-Forwarded-For headers from. > > > In my scenario, I have a pair of squid hosts (squid ver 3.5.6) sitting > behind a pair of haproxy/keepalived hosts which provide balancing and > redundancy/availability. Haproxy is configured to add an > x-forwarded-for header (if one doesn’t already exist) and I can see > the x-forwarded-for header in the request if I run packet capture on > the squid hosts. > > > > For this scenario, I have a box sitting on the 192.168.4.0/24 network, > which has access to three IPs on 192.168.2.0/24 network (2.30, 2.31, > and > 2.32 which are haproxy1, haproxy2, and keepalived vIP respectively). > Hosts wanting internet access must using the haproxy-vip as a proxy > IP, which is then forwarded to the real squid backends. To sum up: > > > > haproxy1 – 192.168.2.30 > > haproxy2 – 192.168.2.31 > > haproxy-vip – 192.168.2.32 > > squid1 – 192.168.2.128 > > squid2 – 192.168.2.129 > > zone1 – 192.168.3.0/24 with hosts having a proxy configured as > 192.168.2.32:3128 > > client1 – 192.168.4.31 with a proxy configured as 192.168.2.32:3128 > > > > Squid will see the real-ip of the client connection as the haproxy-vip > endpoint and not the real-client IP. If I understand the > documentation correctly, I should be able to perform something like > the following in an ACL: > "client" is the initiating end of a single TCP connection. It is a relative term. The client on traffic arriving to Squid really is the haproxy-vip IP. There may be X-Forwarded-For header chains passed in by the client(s) on the other side of the HAProxy. Or other clients that bypass the HAProxy to connect directly with Squid. None of the IP's are necessarily what you consider the "real" client. Understanding that is important to understanding what follow_x_Forwarded_for does and how to use it safely. follow_x_forwarded_for tells Squid which clients it can trust to receive X-Forwarded-For values from. In other words your HAProxy machines *only* are trusted to deliver true XFF headers: acl haproxy src 192.168.2.30-192.168.2.32 follow_x_forwarded_for allow haproxy follow_x_forwarded_for deny all So whatever IPs connected to the HAProxy will be treated as Squid client-IP instead of the HAProxy themselves. Any clients bypassing the haproxy and connecting to Squid will remain being recorded properly as the "real" client. And any fake values a "real" client tries to inject will be ignored. > > # create acl source references > > acl zone1 src 192.168.3.0/24 > > acl client1 src 192.168.4.31/32 > > > > # acl to test x-forwarded-for matching header > > acl testing_proxy_dst dstdomain .google.com > > follow_x_forwarded_for allow zone1 testing_proxy_dst > > follow_x_forwarded_for allow client1 testing_proxy_dst > What you are doing here is telling Squid to trust any values / lies the zone1 or cleint1 machines send in their XFF headers - but *not* to trust the HAProxy frontends. I hope that makes it clear what is going on. Amos _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
