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

Thu Oct 29 20:02:49 UTC 2015

John,

The fact that intercept is changing that seems to be a very specific bug.
You should remove it and find the 'correct' way to make it work.

Chico Venancio
CEO e Diretor de Criação
VM TECH - (98) 9 8800 2743

2015-10-29 16:39 GMT-03:00 John Smith <burnncrashnow at gmail.com>:

> 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
>>
>
>
> _______________________________________________
> 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/97e0f575/attachment-0001.html>