WGIC doesn't come up asking for password

[pgr]

Hi,

one of my users got the typical WGIC problem after upgrading to 6.1.0. There is no way to get the authentication dialog to come up. On the server I see no connections from that computer. I have ping working fine both ways.

It's Windows 98, the only software running that might be causing problems is AVG antivirus.

No matter how many (dozens) of times I've tried to solve this kind of problem, I never seem to find out exactly what I'm supposed to do other than try all possible combinations of Internet Settings, kill apps, start and restart, toggle WGIC, reset client, whatever.

Can Qbik staff please provide a step-by-step GENERIC procedure on how to troubleshoot these situations?

Also, can we hope for brighter days when Qbik does something to WGIC in order to make it work decently? The current user experience with WGIC using authentication is _terrible_ (sometimes drives you to insanity) and I think if you tried watching the average user using it for 10 minutes, with antivirus software and alg.exe and process "X" hanging it all the time, you would get great ideas on where to improve your software.

Thank you and forgive me if I sound irritated, I do mean to be constructive.

[adrien]

Hi

We understand there are issues with WGIC - it was developed in 1997/1998 when the current OS was Windows 95 and NT4!

Since then a lot has changed, and some changes have caused issues.

We do have plans to address the limitations of the architecture on a more fundamental level.

In your case, I believe you may be right about AVG interfering - I believe it also uses a Winsock 2 Layered Service Provider (LSP), which is what the WGIC also is. I believe there are some tools available that allow you to view all the LSPs installed, and allow you to specify which order they should load in. The LSP approach in my view wasn't properly thought out by the winsock 2 designers, and consequently has some drawbacks.

Some things to help track down issues.

1. Discovering the WinGate WRP service

the first thing the WGIC needs to know about is where is the Winsock Redirector Service it needs to connect to. Normally this is done by a discovery process, which uses UDP broadcast on port 368. This is picked up by the GDP service in WinGate, which then tells the WGIC where to connect to. There are several things that can get in the way of this working:

a) if the client machine is on a different LAN segment to the WinGate server, then the UDP broadcast is unlikely to be relayed to WinGate. Therefore the client can't discover the server.

b) If the Winsock Redirector Service is not running, or is not bound to the interface that the client request is received on, then the GDP server will deem that the WRS is not available to the client, and will not respond.

c) if you have a firewall blocking port 368 UDP on your server, the request may be blocked.

You can see if the WinGate client has been able to find a server by going into the control panel applet, and selecting the servers tab. If even after refreshing you don't see any servers listed in here, then the client is having trouble finding a server.

To get around this, you would need to manually set up a server to use in the WinGate client.

2. Connecting to the Winsock Redirector Service

OK, so once the WGIC knows about a service to connect to, it needs to be able to actually make the connection to it. Since in your case you see no connections made to the service in GateKeeper, you know that the WGIC is not even getting this far.

Even if an application is set to "local" mode, it will still connect to the Winsock Redirector Service, because policy on the server may be configured to override policy on the client, and the client needs to connect to be able to tell this.

At this stage you may be presented with authentication requirements

3. Authentication

If the policies of the Winsock Redirector Service are set to require that users of it be authenticated, then when the WinGate Client connects, it will be asked by the server to authenticate.

There are several things to look for if you are getting a connection and there is no request for password:

a) make sure that the user isn't authenticated or assumed by some other means. I.e. if your policies require users to be assumed, and there is an assumption configured for the client's IP, then they won't be asked to authenticate.

b) policy complexity can mean that sometimes one policy allows unauthenticated access - e.g. since policies are combined the most permissive one is used. If you have your WRP service policies set to have system policies "may also be used", then if there is a system policy that grants unauthenticated access, then the user won't be required to authenticate.

hope this helps.

Regards

Adrien

[pgr]

Thanks for such a comprehensive response. And it is very good news that you are planning on revising WGIC architecture!

Reading your no. 1 "Discovering Wingate WRP Service", I find that, although none of the conditions you state are verified in my case, discovery doesn't happen.

This is not a problem, because it NEVER happened, so I'm used to manually specifiying the server IP address everytime I install or configure Wingate.

I must say I am curious as to why this happens... perhaps port 368 is actually blocked by some policy in Wingate...

About "3. Authentication":

I had a policy (not sure why) in WRS Service specifying "Everyone" and "User may be unknown". I changed this so that access to WRS is ALWAYS authenticated. I will try to see if this helps the issues with WGIC not asking for password (but I can't test the original problem I reported right now, the user is away with his laptop).

I will post back when I have more information. Thanks for your help.