Re: [squid-users] Squid DNS Issues

On 28/06/11 22:45, Richard Zulu wrote:
> Thank you Amos,
>
> On Tue, Jun 28, 2011 at 2:17 AM, Amos Jeffries<squid3_at_treenet.co.nz> wrote:
>> On Mon, 27 Jun 2011 08:05:59 +0300, Richard Zulu wrote:
>>>
>>> Hey,
>>> I have squid version 3.1.9 working as a web forward proxy serving
>>> close to 500 users with over 54000 requests every other day.
>>> However, of recent, it is failing to communicate with the DNS Server
>>> completely which leads to few requests being completed.
>>> This has led to a long queue as to the requests supposed to be
>>> completed which later causes squid to hang.
>>> Shifting the very users to another squid cache causes similar
>>> problems. What could be the issue here?
>>> Some of the errors generated in the cache.log are here below:
> The NAT Failure below and the queue congestion is causing my proxy
> server to hang.

Hang? the queue congestion is an exponential queue size increase each
time the warning appears.

I don't think those two would lead to that (maybe, but I don't think
so). Slower than normal access times on every request, sure, but not a hang.

The absence of DNS responses would lead to a hang. So getting back to
that. Do you have any clues about why Squid may not be able to
communicate with it? DNS is critical like having the cables plugged in.

>
> However, I have read the link, I DNAT all the traffic to port 80 for
> my users to my proxyserver
> All the users surf using private IPs on their machines with one public
> IP on the gateway, which is where i do the DNAT to squid.
> How best can i separate normal traffic from NATTED traffic to my squid
> on my gateway and what might be causing NON-Natted traffic to show up
> in my proxy, is it a NAT Vulnerability?

Ouch. The NAT port change has to be done one the Squid box to retain the
destination IP properly.
  I recommend looking into policy routing the port 80 packets to the
Squid box. Then doing the DNAT step on the Squid box.
  http://wiki.squid-cache.org/ConfigExamples/Intercept/IptablesPolicyRoute

>
>>> getsockopt(SO_ORIGINAL_DST) failed on FD 128:
>>
>> NAT failure.
>>
>> Could be a couple of things. Some seriously bad, and some only trivial.
>>
>> * On Linux if you allow non-NAT clients to access a port marked "intercept"
>> or "transparent". The ports for direct client->proxy and NAT connections
>> need to be separate and the NAT one firewalled away so it cant be accessed
>> directly. See the squid wiki config examples for DNAT or REDIRECT for the
>> iptables "mangle" rules that protect against these security vulnerabilities.
>> http://wiki.squid-cache.org/ConfigExamples/Intercept/LinuxDnat
>> http://wiki.squid-cache.org/ConfigExamples/Intercept/LinuxRedirect
>>
>> * On OpenBSD 4.7 or later (may or may not need some patches) it can be the
>> same as Linux. OR if they have partial but broken SO_ORIGINAL_DST support it
>> shows up but means only that the OS is broken.
>>
>> * On other non-Linux systems it is a Squid bug. Means nothing, but I want
>> to get it fixed/silenced.
>>
>>
>>> squidaio_queue_request: WARNING - Queue congestion
>>
>> http://wiki.squid-cache.org/KnowledgeBase/QueueCongestion
>>
>>
>>> urlParse: URL too large (12404 bytes)
>>
>> Exactly what it says. URL is too big for Squid to handle. There should be a
>> 4xx status sent back to the client so it can retry or whatever.
>>
>>
>>> statusIfComplete: Request not yet fully sent "POST
>>>
>>>
>>> http://person.com/ims.manage.phtml?__mp[name]=ims:manage&action=bugreport&js_id=47&"
>>
>> Server or client disconnected halfway through a POST request.
>>
>>
>>> WARNING: unparseable HTTP header field {Web Server}
>>
>> http://wiki.squid-cache.org/KnowledgeBase/UnparseableHeader
>>
>> Amos
>>

-- 
Please be using
   Current Stable Squid 2.7.STABLE9 or 3.1.12
   Beta testers wanted for 3.2.0.9 and 3.1.12.3