[squid-users] "NF getsockopt(SO_ORIGINAL_DST)" filling cache.log due to AWS ELB healthchecks

Thu Oct 29 19:39:15 UTC 2015

Hi Eliezer,

It is entirely possible that haproxy is a better solution than squid for
what we are doing.
I have never used either solution, and inherited this 'working' squid
configuration with the task of cleaning things up and stabilizing it.
Regarding your question of 'How do the first layer of proxies send their
request to the second layer of proxies?', all I can tell you is that all
the work is done in the squid.conf, and I've posted the entire contents
with a few replacements for security reasons.
As I've said, I've removed the word 'intercept' several times and the
requests to secondary proxies no longer work.
I just confirmed this behaviour again.
If this is as 'quiet' as I can make the logs then it is what it is.

Thanks!

On Thu, Oct 29, 2015 at 8:35 AM, Eliezer Croitoru <eliezer at ngtech.co.il>
wrote:

> Hey John,
>
> You are 100% doing something wrong!
> From your description and squid.conf there is still something unclear to
> me.
> How do the first layer of proxies send their request to the second layer
> of proxies?
> If it uses a routing method it's one thing and if it's just splicing the
> traffic to the 3128 port it's another.
> Also it will be different if the first layer of proxies know that they are
> talking to a proxy server or they just balance around the connections.
> Sorry to tell you what you might already know that you are missing couple
> fundamentals on how things actually work in order to make it work as it is
> suppose to.
>
> In any case I think your scenario doesn't require you to use intercept and
> you should remove it.
> The fact that it "works" for you this way is probably a result of a very
> special scenario from the squid proxy point of view.
>
> I do not know what you are balancing there an I do like squid but if you
> need to just splice the connections from the LB to the second layer of
> proxies, why do you actually need squid? what do you benefit from squid in
> this picture? just load balance to the proxy directly.
> If you do have an issue when you do not have the intercept flag you should
> start there and start with the access.log to understand what you need...
> and don't play with it.
> *If you don't do NAT\REDIRECT on the proxy machine you don't need
> intercept*
>
> By the way, have you tried haproxy instead of squid? I think it will might
> be better suited for this specific issue.
>
> All The Bests,
> Eliezer
>
>
> On 29/10/2015 16:08, John Smith wrote:
>
>> Hi Amos and Eliezer,
>>
>> My complete squid.conf is in the first post.  The 'interesting' parts are
>> here:
>>
>> acl httpacl port 80
>> acl SSL_ports port 443
>>
>> http_port 3128 intercept
>>
>> cache_peer l2proxy  parent 80 0 no-query no-digest name=http_peer
>> cache_peer_access http_peer allow httpacl
>> cache_peer l2proxy parent 3129 0 no-query no-digest name=https_peer
>> cache_peer_access https_peer deny httpacl
>> never_direct allow all
>>
>> We have 2 layers of proxies for business reasons.
>> The proxies in question are the first layer, they redirect all traffic to
>> a
>> second layer of proxies - l2proxy above
>> http traffic goes out port 80, https traffic goes out port 3129, toward
>> the
>> second layer of proxies.
>> I assume the 'intercept' is what allows / forces the incoming traffic from
>> 3128 to go on to the 2nd layer of proxies.
>> When I remove 'intercept', the second layer of proxies never get called as
>> we need them to be.
>>
>> We don't need squid to do NAT, but we do need it to forward to the second
>> layer of proxies.
>> Things are now working as expected, I'm just trying to reduce the noise in
>> the logs and would clearly welcome any suggestions for improvements.
>>
>> Thanks again,
>> John
>>
>>
>> On Wed, Oct 28, 2015 at 10:00 PM, Amos Jeffries <squid3 at treenet.co.nz>
>> wrote:
>>
>> On 29/10/2015 1:28 p.m., Eliezer Croitoru wrote:
>>>
>>>> Why are you using an intercept port?
>>>> IF you don't need it you dont't.
>>>> Every time any direct conneciton is done to the proxy port 3128 it will
>>>> show this line since the connection is a regular TCP one while the
>>>> "intercept" directive instructs squid to fetch information which exists
>>>> only on NATTED\REDIRECT traffic.
>>>> Pretty simple and straight forward and this is the way squid works..
>>>> You should verify if you need a http_port 1111 or http_port 1111 accel
>>>> or http_port 1111 intercept.
>>>>
>>>> I will be glad to help you in about 20 hours.
>>>>
>>>> Eliezer
>>>>
>>>> On 29/10/2015 02:06, John Smith wrote:
>>>>
>>>>> Hi Eliezer,
>>>>>
>>>>> I've added a single line to my squid.conf:
>>>>> http_port 3130
>>>>>
>>>>> And I've modified my AWS ELB healthcheck to monitor port 3130 instead
>>>>> of
>>>>> 3128.
>>>>> Now my instances are still in the ELB, and the proxy still works as
>>>>> expected, AND the amount of garbage errors in the cache.log has been
>>>>> significantly reduced.
>>>>>
>>>>
>>> They are not garbage. They are telling you very clearly that the message
>>> being received did not go through the kernel NAT system so all the TCP
>>> protocol NAT related stuff is not working properly.
>>>
>>>
>>>>> Unfortunately I'm seeing a single a single line in cache.log every time
>>>>>
>>>> I
>>>
>>>> hit the proxy on port 3128:
>>>>> 2015/10/28 23:53:32| IpIntercept.cc(137) NetfilterInterception:  NF
>>>>> getsockopt(SO_ORIGINAL_DST) failed on FD 61: (92) Protocol not
>>>>> available
>>>>>
>>>>>   From other posts, it appears this warning message related to NAT.
>>>>> I'm not
>>>>> doing NAT on the squid proxies, the load balancer takes care of that.
>>>>>
>>>>
>>> Exactly. You told Squid it had to do NAT with the "intercept" option.
>>> When it tried to do as you instructed ... boom.
>>>
>>>
>>>>> Any ideas how to remove the rest of the noise from my logs?
>>>>>
>>>>
>>> Start with removing the "intercept". It is clearly the wrong thing to
>>> have. Then move on to whatever problem appears next.
>>>
>>> If you let us know what this ELB+Squid pair is supposed to be doing,
>>> and/or share your squid.conf we can perhapse suggest what else you need
>>> to do for other problems.
>>>
>>> AMos
>>> _______________________________________________
>>> squid-users mailing list
>>> squid-users at lists.squid-cache.org
>>> http://lists.squid-cache.org/listinfo/squid-users
>>>
>>>
>>
>>
>> _______________________________________________
>> squid-users mailing list
>> squid-users at lists.squid-cache.org
>> http://lists.squid-cache.org/listinfo/squid-users
>>
>>
> _______________________________________________
> squid-users mailing list
> squid-users at lists.squid-cache.org
> http://lists.squid-cache.org/listinfo/squid-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squid-cache.org/pipermail/squid-users/attachments/20151029/f1e1265c/attachment-0001.html>