On 18.07.2012 02:07, Peter Olsson wrote:
On Tue, Jul 17, 2012 at 02:43:44PM +1200, Amos Jeffries wrote:
On 17.07.2012 07:35, Peter Olsson wrote:
> Hello!
>
> On Mon, Jul 16, 2012 at 09:03:00PM +0300, Eliezer Croitoru wrote:
>> On 7/16/2012 7:05 PM, Peter Olsson wrote:
>> > We're trying to connect to a remote server that
>> > requires authentication. This works fine when
>> > we place the browser client on the Internet, but
>> > when we place the browser client behind squid the
>> > authentication popup just returns without accepting
>> > the login.
>> can you please be more specific about the topology?
>
> My test setup is very easy. Just a single squid server
> in plain proxy mode, using two network interfaces.
> One interface towards Internet, the other running a
> private network.
>
> I have a single PC client connected to the private interface
> in the squid server. There is no connection from the private
> network to the Internet without passing through the squid proxy.
>
> The squid server is running 3.2.0.18, with the default
> squid.conf installed by the 3.2.0.18 tarball. Only differences
> from default squid.conf are my added visible_hostname and
> changed http_port from 3128 to 80.
Why?
visible_hostname defaults to the machine system hostname.
Since this is a test server that moves around occasionally,
I don't usually have anything in it's /etc/hosts. This seems
to upset squid, which gives this error:
WARNING: Could not determine this machines public hostname.
(It's a FreeBSD 9.0 if that matters.)
/etc/hosts is not related.
There is /etc/hostname config which is required to be set to some value
on every Internet server machine. This is mandatory and is required to
be a DNS resolvable domain name whioch reverse-resolves to the same
name. It MAY be a single label which require appending a domain or
search value from /etc/resolv.conf as well - which Squid tries.
The only reason visible_hostname needs setting is when you have broken
the most basic connectivity requirements for Internet machines.
NP: /etc/hosts is just a quick way to ensure the /etc/hostname meets
those resolvable requirements even when DNS is broken or unavailable.
> There is no transparency or
> routing between interfaces configured in the squid server,
> just plain proxy from inside to outside.
>
> The external server I'm trying to reach is on the Internet.
> If I try to connect to this server through squid, I don't
> get authenticated. If I however move the PC client to the
> Internet, so it doesn't pass through squid, the authentication
> to the external server works fine.
There is a growing collection of known MS software which cannot
handle
the HTTP/1.0<->HTTP1/.1 gateway nature of Squid-3.1 series. But this
should not be an issue with 3.2 series.
Please update to the latest beta though before doing more testing.
3.2.0.20 is out and the latest snapshot has some relevant bug fixes.
3.2 would be best to test with since it provide a full HTTP header
trace at "debug_options 11,2". Those header trace will be the best
starting point to track this down.
Now I run Squid 3.2.0.18-20120717-r11615. Configuration is default
except that I have added debug_options 11,2 at the top of squid.conf.
Same problem in IE 9, three auth popups and then the browser error
page:
You are not authorized to view this page
HTTP Error 401.1
One thing I forgot to mention yesterday is that there is a rather
long wait (about 20-30 seconds) before the first auth popup.
Then there is a shorter wait (a couple of seconds) for the second
popup, and the third popup comes up immediately after the second
has been entered.
I don't see anything strange in cache.log, what should I look for?
Some lines that say "HTTP Client Request"..."HTTP Server Request"
..."HTTP Server Reply" ... "HTTP Client Reply" ... with TCP connection
details and each followed by a dump of the HTTP message headers. These
four sets of headers form one transaction.
There will be multiple transactions for each popup on NTLM.
Or can I post the debug to the list or in private email?
If you wish. Make sure its a test account for the credentials though if
it goes to the list - we may need the actual auth tokens un-obfuscated
to check its syntax and details.
It's about 600 lines in total for the three failed auth attempts.
Amos
