On 9/23/19 4:14 PM, Tom Karches wrote:
> The suggestion was to move to Squid 4 as noted here :
> http://squid-web-proxy-cache.1019090.n4.nabble.com/error-in-parsing-Proxy-protocol-version-2-by-Squid-proxy-protocol-td4686763.html
>
> This was back in Oct 2018. Has anything changed since then?
Yes
I am enabling proxy protocol on our FortiADC load balancer so that the
source IP of the proxy request can be logged. In the current configuration,
the address that is logged belongs to the NAT pool used by the load
balancer.
I added these config settings to configure the proxy_protocol_access. The
>> On 22 Sep 2019, at 14:41, Alex Rousskov
>> wrote:
> On 9/22/19 9:18 AM, Nikolaus wrote:
>
>> The access.log contains error code / detail "ERR_SECURE_CONNECT_FAIL /
>> SQUID_ERR_SSL_HANDSHAKE" - which is not too helpful - but the cache.log
>> contains the more detailed "ERROR: negotiating T
Just for clarity for future searches I think that was intended to be
reply_header_access/reply_header_replace combo. It all starts sounding the same
after a while.
From: squid-users on behalf of
senor
Sent: Monday, September 23, 2019 10:08 AM
To: squid-
Thank you Alex. I suspected I was missing something. In this case I didn't
realize the error page would still need to flow through
http_reply_access/reply_header_replace. I think that's what I need.
I didn't want to touch the code unless I could do something as complete as what
you described. I
On 9/23/19 12:49 AM, senor wrote:
> I have custom error pages with content needing the Content-Type
> header to reflect what it is (like JSON). I don't see any current
> options providing that option for error page handling.
I would start with http_reply_access/reply_header_replace combo, denying
Hi,
My squid ACL can't catch AD user's group of membership.That's why can't
send the request correct outgoing interface
Users member of group_g_internet_socialmediausers and its correct interface
IP address is 10.65.12.247. 10.65.12.250 is general outgoing address
### NTLM
> auth_param ntlm progra
