Uppgrade from WG.4.4 to 6.3, Authenticate and DNS-problems?

[Ulf]

Hi!
Wingate has always worked like a charm for me,since V.3. PRO,Unlimited users. I work at a big Highschool in Sweden as a network administrator and i used wingate primary to check the students internet usage,block certain sites etc. as a control-tool. great program. The first time i got problems was when installing "Autodesk Inventor 2002" and its License-server..had a long email session with deerfield staff,but we couldnt solve the problem..so i had to remove 40 computers out of Wingate with Inventor,Pity!

But now i really got big troubles..
we are running a Novellserver 6 and win2k clients with nvcl 4.90sp2 and zenworks 4.
it started with the migration of my server to a new big campus server,outside my subnet.
i had Wingate 4.4 PRO then and my clients couldnt find the novellserver at all,the wingateserver failed to route to the new subnet.
Then i uppgraded to wingate 6.3 and voila! it worked again..BUT
I kept all the old settings but now i cant see:

1:the user who is logging on.

i could see computername: guest: and (*username) in WG4.4 (*in realtime,not in log) but thats enough for me
with basic authentication,no other user accounts.
Now i only see :computername.

2: sitenames in text.

Now its only TCP/IP numbers.
and its useless to me.

i guess its some configurationthing,but i really tried a lot to no avail
and i wonder if the authenticateproblem have something to do with Zenworks policypackage? wich include a central profile for students,its removed after logout?
The adress resulotion most have something to do with DNS ?
But i put in the two DNS servers we use in the school in wingate DNS.

I could really need a hand here,thanks
so please give me something to chew on...

Ulf/Polhemsgymnasiet

[Pascal]

Hi Ulf,

Apologies for the delay in getting back to you. Think this might help though.

2: sitenames in text.

How are your clients connecting through WinGate? From the sound of it it is NAT, not proxy / WGIC. With NAT, the client makes a DNS request (Normally through WinGate) which gets answered. It then makes a connection to the IP, without using the name at all. You need the traffic to pass through a WinGate Service for it to 'know' the name.

1:the user who is logging on

The scenario above might be the cause of this. When looking at our servers, the users who have authenticated are shown properly. However, when using NAT or Intercepts the username is not shown. I'll run some tests on it this afternoon, however, the layout of the display has changed since 4.4 - quite a bit, actually.

[Ulf]

thanks for the reply..

I´m running WGIC.
i´m trying to run trough WWW Proxy service.

When students are logged on its a(NAT) connection in gatekeeper with only TCP-IP numbers.

I suspect its a Zenworks 4 problem with the"Dynamic local user policy package"
Because when i log on as a "administrator" who is not included in the DLU-policy package,and have a stationary profil on the local computer it works with both "Log on-username" and name resulotion on IP-adresses in Gatekeeper.
And i have to use DLU, orders from the top....

Any Hints??...

ULF

[Pascal]

The easiest way to turn a NAT connection into a proxy connection is to enable intercepts. You can do that on the appropriate proxy's sessions tab.

What this does is whenever a session comes in (NAT or WGIC) it is redirected through the appropriate proxy. (Depending on which ports the proxies have been told to intercept).

This allows you to then (a) specify per service policies, (b) use plugins and (c) see the information as you've described.

However, if you are using WGIC they should be showing up correctly.

[Ulf]

Hello again!
It works with the name resulotion in gatekeeper when i intercept port :2080.
But no "Log in Name"..

I wonder if this problem occures because i have remains of older WGIC´s left on the computers? if i scan the registry there are three remaining keys.
i will attemp to locatate and remove every trace of the old WGIC,and reinstall the new one..

Ulf.

[Pascal]

It should not be necessary to intercept port 2080. All that should be necessary would be to turn intercepts on for port 80 in the Web Proxy.

Is it possible for you to email me a registry export of your WinGate configuration, please? Then I can import it tomorrow morning and have a look at it.

[Pascal]

I can't see anything wrong with that configuration EXCEPT for the intercept of port 2080. That could potentially be right, though - depending on what exactly the clients are doing. Because traffic on port 2080 (WGIC) is destined to the local WinGate Machine the intercept you added should not be doing anything. It's only if your clients are connecting through WinGate to a server outside on port 2080 that it should make a difference. (Be intercepted) So I suspect, like you indicated in your previous post, that the problem might be with the client setup.

Now, from your posts it sounded as if the clients are connecting out through NAT (Even though you want them to use WGIC / Proxy).

If the clients are using WGIC they should be showing up as a WRP Control Session, with other sessions underneath them. (Those sessions should be showing as HTTP / etc. even if they are not intercepted) When you are using WGIC all that should be necessary on the client computers would be to setup DNS so it points to your DNS Server and to install WGIC. You don't need to configure proxies, etc. (Generally) Traffic going through WGIC is treated as a TCP/UDP Link session. It does not go through any proxies.

If the clients are using proxies you only need to specify the IP address + port number of the WinGate Server in the appropriate applications.

If you are using NAT, all you need to do is make the WinGate Server the default gateway (As well as DNS if it's your network's DNS Server) for the applicable client machines. When you are using a pure NAT system the traffic will show up as you indicated in one of your posts (The pink/blue arrows with only IP Addresses).

Now, when you are using WGIC OR NAT you can intercept ports in the Services. If, for example, you turn "Intercept Port 80" on for the WWW Proxy Service:

If a machine makes a NAT connection to www.msn.com (Port 80) that traffic will be redirected to the WWW Proxy Service.

If a machine makes a WGIC connection to www.msn.com (Control port 2080, TCP Link port variable) that traffic will be redirected to the WWW-Proxy Service.

I hope that helps - it's a bit of a verbose explanation but I can't see anything wrong with your server configuration; so feel it's best to detail possible client setups. After you've checked the client setups get back to me; then we can see what else we need to do.

One suggestion - you are blocking a large number of executable files with your WRP policies. If you have an Enterprise license the Central Configuration allows you to specify which executables are allowed to run. You can even return a message to the user to indicate why they are not allowed to run that application. If you are using WGIC that becomes a very good way to restrict user access (And Internet Access) to the applications that YOU want them to run.

[Ulf]

Hi again!
When i intercept port :80 i can see the http/name now,but still no authentication, just computername.

I´m still suspicius about Novell zenworks 4 and the mandatory profiles for the students,it is set to remove the profile when they log out,and they allways have a default profile when they log in. they had local profiles
Before in WG 4.4. i could see:
Computername:[loginname](guest)

And i i have found a more serious problem now..
Bad connections to diskmappings for example: h:/home on the server, if you click on it it says that the "mapping is wrong"or "the server is disconnected" but if you try to click on the diskmapping a couple of times ..then it works?
typical nonstable connection

Any suggestions?

Ulf.

[Pascal]

Which view are you using in GateKeeper? Are you viewing by "Machine" or by "User"? The layout of the display has changed since 4.4. Also, can you see the appropriate user names in History?

About the network traffic - that should not be related to WinGate. However - is it only to the WinGate server or more general across the network? If it's only to the WinGate Server, it could potentially be driver related. The easiest thing to try would be to ensure that you have the latest network card drivers for everything; but, I suspect that might be the case anyway.

If that is the case; can you post more information about your network card / setup here, or email it to me directly. This would be the full results of an "ipconfig / all" so we can see the makes and models of the network cards; and a "route print" so we can see the route table that the driver will have to work with.

Also, OS, Service Pack level, etc.