WG: [squid-users] https from different Subnet not working

From: Jarosch, Ralph <Ralph.Jarosch_at_justiz.niedersachsen.de>
Date: Tue, 14 Jul 2009 11:11:25 +0200

Hi Gaven,

>Hi Ralph,

>I'll add a couple of thoughts, but not really an answer.

>On Tue, 14 Jul 2009, Jarosch, Ralph wrote:

>> If I connect from an branch office with the subnet 10.37.34.*/24 to an https website i´ve no Problems.
>> If I do the same from another location with an subnet like 10.39.85.*/24 I get the following error message.

>Presumably you're using the same URL to test in both places and the same
>proxy settings?

Yes this is correct same Url on both location

>I'll note in passing that you're running a very ancient version of squid
> (2.5.STABLE12). I doubt an upgrade would fix your problem, but at some
>point, you should consider an upgrade nonetheless.

The Problem is that Redhat only Supports Squid 2.5./12

>> The requested URL could not be retrieved
>> --------------------------------------------------------------------------------
>> While trying to retrieve the URL: http.yyy.xxx:443
>> The following error was encountered:
>> Unable to determine IP address from host name for
>> The dnsserver returned:
>> Name Error: The domain name does not exist.
>> This means that:
>> The cache was not able to resolve the hostname presented in the URL.
>> Check if the address is correct.
>> Your cache administrator is webmaster.
>> --------------------------------------------------------------------------------
>> Generated Tue, 14 Jul 2009 08:10:39 GMT by xxxxxxx (squid/2.5.STABLE12)
>>
>> The requester url was https://www.ebay.com

>It's a little odd that you removed the URL from the output, only to tell us
>it afterward, but how and ever. Also, you've removed the name of the web
>proxy that generated the error, which is a little unhelpful as you appear
>to have 5 proxy servers.

Ok yyy.xxx is the FQDN from our local domain.

>What the above error tells you is that the squid web proxy couldn't get a
>DNS response for the site you wanted to go to, ie

Ok I know
The response come from the parent proxy of the cache_peers

>" The cache was not able to resolve the hostname presented in the URL."

>It seems surprising that that problem would happen in a repeatable way that
>affected one client but not another.

Absolutely. It is absolute crazy that all class c networks which are 10.37 works fine an all other class c that have addresses like 10.59, 10.39 10.61 doesn't work.

>I note that you have several parent cache peers:

>> cache_peer 10.37.132.5 parent 3128 7 no-query proxy-only no-digest sourcehash
>> cache_peer 10.37.132.6 parent 3128 7 no-query proxy-only no-digest sourcehash
>> cache_peer 10.37.132.7 parent 3128 7 no-query proxy-only no-digest sourcehash
>> cache_peer 10.37.132.8 parent 3128 7 no-query proxy-only no-digest sourcehash

>I wonder could it be that only one of the cache peers is having DNS issues?
>Could you point a browser directly at each individual parent cache and see
>can you get the webpage you're looking for.
 
No its happens on all cache_proxy´s

>Gavin

Ralph
Received on Tue Jul 14 2009 - 09:13:57 MDT

This archive was generated by hypermail 2.2.0 : Tue Jul 14 2009 - 12:00:03 MDT