Web Proxy request fails periodically.

[wrarmstrong]

On an earlier post I mentioned that I was getting occasional proxy failures and that I would post the details when it happened again. Well, here are the details:

This is the error that I got in the browser:

Socket Error 10049 {Thd 820} [socket #1798, 0.0.0.0:1436 to :0]

I checked the log file and didn't find anything too interesting other than the fact that these several entries were found grouped together in the log file with the same thread and context id. The thread id matches the thread id in the error above.

User Unknown: responding with code 407 Proxy authorization required
User Unknown: responding with code 407 Proxy authorization required
User Unknown: responding with code 407 Proxy authorization required
User Bill: responding with code 407 Proxy authorization required
User Bill: responding with code 504 Socket Error

[adrien]

Hi Bill

that error 10049 we used to see in WG6, relates to a DNS lookup failure.

Those 407 "errors" aren't actually an error condition, just the result of policy rejecting the request with an auth challenge... I need to change the way those are logged.

the 504 also would be relating to the DNS lookup.

Do the DNS resolver logs shed any light?

Regards

Adrien

[wrarmstrong]

I don't have debug logging turned on for my DNS server, so there's not much to see.

One odd thing though is that I quite often get the error as I'm navigating around the WinGate web site. For example I've gotten it when clicking on the Submit button on this forum. I would have thought that at that point the DNS lookups wouldn't have gone any further than the cache. That suggests that there may be an issue with the DNS client.

I used to see errors like this every once in a while with WinGate 6, but it is happening much more frequently with WinGate 7.

[adrien]

Hi Bill

could you please turn on debug logging for the DNS Client? Probably easier if you get it to use its own file as well.

When you see the lookup fail that you'd expect to succeed can you email the log to me at adrien at qbik dot com

thanks

Adrien

[wrarmstrong]

Ironically I got the error again when I clicked on the Submit button for my last post. Luckily I had previously turned on debug logging for the DNS client. I looked at the log entries. There as a reverse lookup to look up the IP address of my server, followed by a couple of lookups for forum.wingate.com. None of the DNS Client entries indicated that there were any errors. The WWW Proxy Service did show its error in the log though.

[adrien]

Hi Bill

that makes me wonder whether the response from the DNS client is valid. Perhaps it cached a bogus response, or passed a bogus response through (but didn't notice it was bogus).

Would you be able to do a test with nslookup?

from command prompt

nslookup

then from nslookup command prompt the commands

set server X.X.X.X (IP of your WinGate server)
set type=A
set debug=on
www.wingate.com. (with dot on the end to prevent nslookup from appending name suffix)

the output should show what is coming back from the DNS client. If you could please cut and paste that here it would be appreciated.

Thanks

Adrien

[wrarmstrong]

Here you go.

Code: Select all

Server:  [192.168.0.3]
Address:  192.168.0.3

------------
Got answer:
    HEADER:
        opcode = QUERY, id = 5, rcode = NOERROR
        header flags:  response, want recursion, recursion avail.
        questions = 1,  answers = 1,  authority records = 2,  additional = 2

    QUESTIONS:
        www.wingate.com, type = A, class = IN
    ANSWERS:
    ->  www.wingate.com
        internet address = 210.55.214.36
        ttl = 3600 (1 hour)
    AUTHORITY RECORDS:
    ->  wingate.com
        nameserver = ns1.qbik.com
        ttl = 162093 (1 day 21 hours 1 min 33 secs)
    ->  wingate.com
        nameserver = ns2.qbik.com
        ttl = 162093 (1 day 21 hours 1 min 33 secs)
    ADDITIONAL RECORDS:
    ->  ns1.qbik.com
        internet address = 210.55.214.33
        ttl = 9642 (2 hours 40 mins 42 secs)
    ->  ns2.qbik.com
        internet address = 210.55.214.34
        ttl = 82483 (22 hours 54 mins 43 secs)

------------
Non-authoritative answer:
Name:    www.wingate.com
Address:  210.55.214.36

By the way, the proxy request is failing quite frequently right now. It seems as though if I let a page sit for a while and then click on a link or a button I get the failure, but if I'm fairly active, keeping the requests going there is no problem.

[wrarmstrong]

Note that the DNS server is on the same server as WinGate and that the DNS client is configured to use 127.0.0.1 as the proxy server. I don't know if that makes a difference or not.

[wrarmstrong]

Please ignore my previous post. I did your test again on the server using 127.0.0.1 and got a completely different response. Here is the correct one:

Code: Select all

Server:  localhost
Address:  127.0.0.1

------------
Got answer:
    HEADER:
        opcode = QUERY, id = 3, rcode = NXDOMAIN
        header flags:  response, auth. answer, want recursion, recursion avail.
        questions = 1,  answers = 0,  authority records = 1,  additional = 0

    QUESTIONS:
        www.wingate.com.jackieandbill.home, type = A, class = IN
    AUTHORITY RECORDS:
    ->  jackieandbill.home
        ttl = 3600 (1 hour)
        primary name server = jb-media.jackieandbill.home
        responsible mail addr = hostmaster.jackieandbill.home
        serial  = 116
        refresh = 900 (15 mins)
        retry   = 600 (10 mins)
        expire  = 86400 (1 day)
        default TTL = 3600 (1 hour)

------------
------------
Got answer:
    HEADER:
        opcode = QUERY, id = 4, rcode = NOERROR
        header flags:  response, want recursion, recursion avail.
        questions = 1,  answers = 1,  authority records = 0,  additional = 0

    QUESTIONS:
        www.wingate.com, type = A, class = IN
    ANSWERS:
    ->  www.wingate.com
        internet address = 210.55.214.36
        ttl = 3137 (52 mins 17 secs)

------------
Non-authoritative answer:
Name:    www.wingate.com
Address:  210.55.214.36

[adrien]

OK, looks like it's working fine.

Any chance of looking at the computer with remote desktop or remote gatekeeper?

I'm wondering if there's some setting somewhere that's actually stopping WinGate WWW proxy from even doing a DNS lookup, which then causes this.

e.g. connection control settings, WWW Proxy Server connection settings, or even policy script playing with connection settings.

Adrien

[adrien]

HI Bill

it should actually be possible from looking in the logs to see whether the WWW proxy made a DNS lookup or not for the request.

Normally we try to minimise the number of lookups, e.g. if the connection to the upstream server is persistent, and a subsequent request comes in, to the same server, we reuse the same connection.

So if there had been a number of requests made on that thread, the lookup could have been made for a request earlier than the one that fails.

Regards

Adrien

[wrarmstrong]

Hi Adrien,

I would be happy to provide you with my log files. If you send me an email, I will respond with the log files, or if you have an alternate way to provide them that does not make them open to the public that would be fine.

Also if you need to take a look at my configuration that would be no problem. We could set up a WebEx or Live meeting. Just let me know.

Bill

[adrien]

Hi Bill

Remote Gatekeeper access from here would allow me access to all the logs, and your config so that would be useful, or some webex type system. We commonly use and recommend teamviewer.

If you could email credentials and connection settings through to me at adrien at qbik dot com would be great.

Regards

Adrien

[adrien]

HI Bill

Just checking through your logs for 15th. There's something very odd going on with auth.

Normally NTLM is a 3 step handshake. So you see 2 entries of unknown making a request, and getting a 407, then the 3rd one succeeds. In your case, I'm seeing 3 unknowns getting a 407, then Bill getting a 407 (plain wrong) then the 504.

So there are too many auth challenges. I'm wondering if this is a policy issue. The existing policy only specifies auth in one case - where the user isn't authed. So that shouldn't be doing this. did you make any policy mods recently which could have fixed this?

I'm also suspecting that the extra auth cycles are clearing the server IP WinGate looked up, since the DNS logs show the records were answered out of cache (as you mentioned you expected).

I see this auth thing is still happening though, so I doubt it's policy causing it. Perhaps something odd about the user account in windows? I see it's using negotiate for auth. Maybe that means it's using kerberos or something?

Regards

Adrien

[wrarmstrong]

Hi Adrien

I haven't made any significant policy changes recently. The logic in the policy that you looked at is the same logic that I've been running for several days.

The server that WinGate is running on is a Microsoft Windows Home Server (which is essentially Windows Server 2003). I don't have a domain controller. All of the user accounts are local accounts so it should not be using Kerberos authentication. I can't explain why the authentication behavior is different than what you are used to seeing.

Bill

[adrien]

Hi Bill

Could you do a packet capture of this? It should be fairly simple to capture the necessary packets.

there are some tricks with the packet capturing in Wg7 though. You'll need to

a) in the capturing dialog, we need a filename. We had to write our own folder/file browser dialog since GK can be remote, and we are exploring the WinGate server folders and files. Basically you need to select / create a file and it must end in .cap (to be visible for selection). So, browse to a folder you want to store captures in, click the right-most icon in the top right of the dialog (Create file), enter a filename, with the .cap on the end, select it, then ok.

b) for the filter, you should be able to just set dest port 80 to 80, source IP being the source IP of your client computer, and mask 255.255.255.255.

The state WinGate needs to be in to capture this auth cycle is that in activity in Gatekeeper, no activity or even computer icon should be showing for your client machine's IP. Then there won't be any cached credentials, and policy will require auth.

If you could email me the capture file I should be able to see what's going on with your auth. I'm not sure if Home server does kerberos or not.

Regards

Adrien

[adrien]

p.s.

another quick check to see if the auth is a problem, would be to set the WWW proxy to use Basic auth instead, and see if you still get the 504 errors.

If they stop, you know the extra auth cycles are breaking something.

Regards

Adrien

[giox069]

I had the same problem "wingate "Socket Error 10049"" with wingate 6.2.2 installed on a DC which is also DNS server.
In my case the DNS setting of my LAN card was set as 127.0.0.1 and all the rest of windows applications (including the browser) was working. But clients connected via wingate were unable to have internet access.
Changing from 127.0.0.1 to the LAN interface IP own address solved the problem.