Switch to full style
Use this forum to post questions relating to WinGate, feature requests, technical or configuration problems
Post a reply

Not impressed

Jan 03 08 4:10 am

After spending out a lot of money for Wingate, I'm becoming increasingly less impressed with this software. It seems incapable of doing the most simplest of things.

For example, I can't use the WGIC program because it interferes with printing to network printers, and also stops our accountants from using programs such as Sage. You'd think it would be easy enough to tell WGIC to ignore such problems, but no, its not that easy. So I'm relying on NAT to authenticate people, using the AD database to get username and password information. But half the time it doesn't authenticate people even though they log onto the domain correctly. Wingate assumes they are guests and won't let them do anything on the net. Most of our machines I've had to point back to our router for a direct internet connection, bypassing Wingate altogether.

I'm sorry if I sound disappointed, but to be honest I am. Originally I considered getting some shareware or freeware to handle internet security, but decided to go for a commercial product like Wingate so that I could avoid all the teething troubles you get with shareware - only to find Wingate is full of holes and bugs itself.

So, no, I'm not happy.

Jan 03 08 4:32 am

Secondly,

If I give an example...

USERA is logged into a computer called "TEST". And that works fine. So USERA logs out, and USERB logs into the same computer. Gatekeeper still thinks USERA is logged in, and doesn't recognise that a different user is using that computer. What's all that about? Why doesn't gatekeeper tell the difference? Surely this should all be handled by the Logoff/Logon routine?!

So to make sure its not just a refresh problem, I disable USERA in Gatekeeper - and lo and behold USERB is locked out, even though I've disabled USERA. Same computer, different user, but Wingate doesn't tell the difference.

Is this why some of my users can't seem to use the program because it doesn't authenticate them properly and assigns them as Guest? Why doesn't Wingate take the user info from the Domain log in, as its supposed to do?

Jan 04 08 5:56 am

Hi

WinGate maintains a table which maps IP address to username. This is used by default for new sessions. This is to avoid users having to authenticate explicitly each time they try to do anything (which would soon become annoying to your users).

When no sessions are connected from that machine, the table entry for that IP is aged and timed out.

So it sounds like something is keeping a session open, which is maintaining the credentials of the first user. Can you see any sessions open from that machine when no user is logged in?

Adrien

Jan 04 08 6:01 am

ps, on your first issue with the WinGate Internet Client, to stop application using it, is a matter of entering that application name into the applications tab of the WinGate Internet Client control applet in Start->Settings->Control Panel.

You mention using NAT to authenticate people? NAT itself can't do any auth (there's no auth facility built into IP protocol, only higher level protocols such as HTTP, POP3, SMTP etc). So do you mean you are intercepting connections with the WWW proxy, and forcing auth there? There are several reasons why forcing auth (esp NTLM) with intercepted connections can be problematic.

Sorry, I'm trying to get a clearer picture of your setup and how you are using WinGate.

Have you tried configuring web browsers to use WinGate explicitly as a proxy? This is the recommended method if you wish to use NTLM authentication.

Jan 04 08 8:11 am

adrien wrote:Sorry, I'm trying to get a clearer picture of your setup and how you are using WinGate.



Okay. I'm sorry for my tone earlier. Its just that I've spent a lot of time on this and don't seem to be getting anywhere.

So lets start again.

Here's what we want to do.

We have a network of about 15 users, everyone is on a domain being controlled by 3 domain controllers each running 2003 Server. Wingate is installed on one of the domain controllers called "Server" - how original eh? I told Wingate to use the Active Directory for its user database, and I've turned off Wingate's own DHCP and DNS services, since Windows 2003 does this already. I've also turned off the POP3, SMTP and IMAP4 services, since we collect mail from a dedicated mail server and have no need for Wingate to do it for us.

The only things we need to do with Wingate is

1) Monitor each user's internet access
2) Restrict each user from using certain websites and from using MSN Messenger
3) Do all of this with minimal disruption to the users - in other words using the same login credentials as when they log into Windows

Now - from what I understand from reading a lot of posts here, in order to restrict access to MSN, and in order to authenticate to Wingate using the Windows login I have to use WGIC. This is fine, I have no problems using WGIC and everyone seems to authenticate correctly. However, when WGIC is installed it caused a lot of other problems such as connecting to network printers, causing AVG to ask for authentication when the system boots up, and one user says he can't use Sage (our accounting program).

In a few posts I've seen where people have complained about WGIC, the solution is to remove it and use NAT instead - but then I can't authenticate to Wingate and therefore track what each user is doing, plus I can't then stop people from using MSN. So you can see my problem.

My ultimate aim would be for everyone to log into Windows, have WGIC run in the background and authenticate that user to Wingate at the same time, and most importantly WGIC then doesn't interfere with anything at all except to block the applications I want to block. Does that make sense?

Jan 08 08 6:54 am

Hi

There are actually several ways to use the windows login for web browsing. One as you mentioned is using the WGIC, however it's also possible to use HTTP authentication support of browsers as well.

There are 3 things involved in getting browser-based authentication working.

1. Configure the browsers to use the proxy directly (rather than intercepting the connections). I believe you can set Internet Explorer configuration options using group policy under Active Directory.

2. Configure the WWW proxy policies to require authentication for access. There are actually many ways to do this (depending on policy requirements), but it's most common to:

a) on the policy tab of the proxy under "users can access this service", select (at the bottom) "are ignored" for System policies
b) Add a new recipient, choose "user must be authenticated"

3. You'll probably want to avoid the login dialog popping up, in which case you can configure IE to automatically log in using the current windows login. This is done by customising the security zone (Tools->Internet options->Security->Custom level->User Authentication (at the bottom))

As for MSN, depending on how you wish to block this, there are several options as well. One way is to block the EXE from loading (which requires the WGIC), however you can alternatively block port 1863 (used by MSN) in the extended networking settings under port security.

Hope this helps

Regards

Adrien

Jan 08 08 7:52 am

I've tried blocking port 1863, but unfortunately MSN is intelligent enough to figure out if that port is blocked and then goes out on port 80 instead.

Jan 08 08 11:39 am

I did a bit more reading on blocking MSN.

Looks like there are some web servers you can block in the WWW proxy that will prevent MSN from operating on HTTP as well.

for starters block messenger.hotmail.com.

Regards

Adrien

Jan 08 08 10:36 pm

Thanks for all your help. I'm slowly getting to where I need to be.

I have more questions however

1) Is there any way to do this automatic authentication using Firefox? Most of our computers use Firefox now for a few reasons. I'm wondering if anyone has come across an add-on tool or something which allows Firefox to use the windows authentication in the same way Explorer does it (as explained above).

2) We use a router for connection to the internet, IP address of the router is 192.168.0.1 The IP address of the server with wingate is 192.168.0.9 If I'm just using WWW proxy direct from the browser, do I set the default gateway of each machine to the router or the wingate server? If setting it to the router, how do I then block port 1863?
[/list]

Jan 09 08 12:09 am

Hi,

There is a utility which might suit for Authentication in this thread: http://forums.qbik.com/viewtopic.php?t=4094&highlight=qbikauth

Or directly:

http://www.wingate.com/downloads/QbikAuth.exe

With the FireFox clients, Proxy, Gateway and DNS of the Internal NIC in Wingate should be all for WWW proxy service.

Jan 09 08 3:52 am

The Qbikauth program looks okay. I assume you can run this at startup by dropping it into the startup folder. Not ideal really for what I wanted, but it should work.

One question I have with this.. when I right click the Qbikauth program when it's running in the taskbar, I get the option to logout. Upon doing this, I can still browse websites, and according to Gatekeeper I'm still authenticated. Upon logging out, should I not lose my access rights?

Does Qbikauth remember different logins for different user profiles?

Regarding MSN Messenger, adding messenger.hotmail.com made little difference. I could still log in, as MSN reverts to an IP address (which can change) if it senses messenger.hotmail.com is being blocked. I've now blocked port 1863 AND 443, and that seems to have done it - but for how long I don't know. MSN seems to find ways to get around the blocks I put in.

Jan 09 08 12:55 pm

QbikAuth simply logs out its own session and your machine stays authenticated only for as long as there are other sessions active + the certain lingering timeout. In other words until the machine itself disappears from Gatekeeper activity screen it stays authenticated. You can reduce this lingering timeout, though.

Jan 09 08 10:46 pm

harlequinfloors wrote: I've now blocked port 1863 AND 443, and that seems to have done it - but for how long I don't know. MSN seems to find ways to get around the blocks I put in.


Blocking Port 443 could be difficult for SSL.

For MSN there is some stuff on this thread: http://forums.qbik.com/viewtopic.php?t=17080

Jan 09 08 11:00 pm

Yeah, I read that, but the problem seems to be that MSN Messenger tries to connect in the following sequence..

Port 1863 - if blocked try
Port 443 - if blocked try
Port 80

So, blocking "gateway.dll" is redundant unless port 443 is blocked, because otherwise it will never get there. At least.. that's what I have observed anyway.

Jan 09 08 11:07 pm

You can try blocking on HTTP headers if the connection goes through proxy.

Jan 09 08 11:11 pm

I gave up using proxy because it requires that every piece of software to be blocked needs the proxy settings added, and its too easy for users to change settings. Therefore I've gone down the Qbikauth.exe route, and simply having each PC's gateway pointing to the Wingate server. That way I get authentication and all internet traffic gets passed along, not just Firefox or IE.
Post a reply