2

I'm configuring a squid proxy to work as a sort of a gateway for traffic egress. The environment in which this is deployed has a client that makes a request through a load balancer which then sends it on to the squid proxy. To not obfuscate the original client ip the load balancer uses the proxy protocol. Squid (3.5+) "supports" the proxy protocol and allows it to be used in an acl. A working configuration that I have seen to allow proxy protocol access is below:

acl localnet src 10.0.0.0/8 http_port 3128 require-proxy-header http_port 3128 proxy_protocol_access allow localnet

However this doesn't allow me to filter the subsequent requests based on dstdomain. I've also tried

acl allowed dstdomain .google.com acl localnet src 10.0.0.0/8 http_port 3128 require-proxy-header http_port 3128 proxy_protocol_access allow localnet allowed

But this causes my curl requests to return with error 53 empty requests. I've tried

acl allowed dstdomain .google.com http_port 3128 require-proxy-header http_port 3128 proxy_protocol_access allow allowed

This has the same behavior as the one directly above. I've tried also 

acl localnet src 10.0.0.0/8 http_port 3128 require-proxy-header http_port 3128 proxy_protocol_access allow localnet acl allowed dstdomain .google.com http_access allow allowed http_access deny all

And this results in all the traffic being allowed out. (I've also tried swapping those 2 blocks as well with the same results.

Am I missing something? Does someone have a working configuration that allows for domain filtering and proxy protocol?

Improve this question

2 Answers 2

Reset to default
3

After looking at this more, I was able to fix the config so it would work. This works:

acl localnet src 10.0.0.0/8 http_port 3128 require-proxy-header http_port 3128 proxy_protocol_access allow localnet acl allowed dstdomain .google.com .yahoo.com http_access allow allowed http_access deny all

Although I had tried this before, I was running into a snag with an http_access deny all was listed above.

The proxy_protocol_access simply establishes where the proxy protocol can be accepted from. In looking at the cache.log on reload, it seems to indicate that any dstdomain filtering in proxy_protocol_access is not actually allowed.

As a note: The rules are applied in order of appearance in the configuration and as things match they are applied. So if a deny appears above, the request is denied.

Additional logging information can be provided for troubleshooting using the debug_options specifically debug_options 3,28 for configuration file troubleshooting. (More info here: http://wiki.squid-cache.org/KnowledgeBase/DebugSections)

http://www.squid-cache.org/Doc/config/proxy_protocol_access/

Improve this answer
0

A little late, but for those working with Squid as a forward proxy (i.e. egress to internet), with load balancers between Squid and your workload, you may want to try it out this way.

I had issues with finding out my client IP addresses at Squid forward proxy when the clients were behind an AWS Network Load Balancer. Instead, the NLB's IP addresses were being logged and detected at the Squid forward proxy, causing problems with my domain filtering.

To solve this, I enabled Proxy Protocol for both the NLB and Squid.

In the Squid Config:

acl localnet src 10.0.0.0/20 acl loadbalancers src 10.0.16.0/27 10.0.16.32/27

Where localnet is your vpc or subnet, where your workload is hosted. And loadbalancers are the IPs of your NLB. If you are using AWS NLB, enable Proxy Protocol V2, this will append the proxy protocol header to the request - informing downstream servers to look out for your client IP addresses.

http_port 3128 require-proxy-header #http_port <some-other-port-if-required>

For your http listener port and mode, just declare it once for this port. You need the mode require-proxy-header as squid will then look out for the client IPs behind the load balancer. If you expose the same port twice, you'd get a duplicate listener error in the access logs.

proxy_protocol_access allow loadbalancers

According to the documentation, you need to declare this with when require-proxy-header mode is enabled. Essentially saying that your load balancers are proxies and will be sending out a proxy header, look out for client IP.

acl mydomains dstdomain .google.com .yahoo.com http_access allow mydomains localnet http_access deny all

Business as usual, setting ACL mapping of desired destination URLs to be accessed or blocked from your localnet resources.

Improve this answer

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.