6.0.3 ENS must be disabled to allow DNS at command prompt

[MPHinteractive]

We upgraded from 5.2.3 to 6.0.3 last night. This morning I find that internet access through our cable modem fails, even on the Wingate server itself, unless I disable ENS. I have tried turning off ENS in Wingate and/or stopping the Wingate service without fixing the problem. When I disable ENS so that it doesn't load at system startup, we regain internet access.

Wingate is running on a clean Windows 2000 Pro computer with current Microsoft patches. The other services running on the computer are Abyss, DNS2go, Symantec Corporate Antivirus, and SETIathome.

With ENS loaded I can ping my ISP's DNS servers by IP number, but when I try to use nslookup to resolve names the function times out. I am unable to ping other name servers even by IP address, and of course I can't ping any websites (google.com, for example) because DNS doesn't resolve. Disabling ENS and rebooting allows me to perform all of these functions.

I tried removing and reinstalling Wingate 6.0.3 and have the same issues.

We're currently running in limp-along mode without ENS, but that means I don't have a firewall and I have to manually redirect the PCs in my office through the proxy.

Looking forward to your help! Thanks...

Park

[MPHinteractive]

One minor correction to my earlier post... The alternate DNS servers I tried don't respond to pings even normally. However, when I tried to use nslookup to reference them with the ENS driver loaded, they timed out same as the regular ISP DNS servers. Something about the ENS driver prevents DNS resolution from working in this configuration??

Park

[Pascal]

Are your adapters detected correctly as "Internal" and "External"? Do you get any corresponding firewall hits when attempting the nslookups, etc.?

[MPHinteractive]

I had previously double-checked that the internal and external adapters were correctly identified - sorry I didn't specify that.

I just re-enabled the ENS driver, rebooted the machine and tried pinging. It failed again, with the ENS driver loaded but ENS disabled in Wingate. I then tried enabling ENS in Wingate - no luck pinging google.com that way either. Wingate does not show any firewall traffic in either case.

I am doing all this on the Wingate server machine itself.

Had to tag the ENS driver not to load and reboot again just to get back on the forum!

Park

[genie]

If you try to resolve a name, does Wingate report any UDP protocol firewall hits?

[MPHinteractive]

I tried pinging google.com, and then tried using nslookup to resolve google.com. Both failed, and Wingate's firewall did not report any activity.

I turned on ENS debug logging during this process but didn't see anything obvious in the log files. Not that they make much sense to me... (grin)

Park

[adrien]

Hi Park

How does your computer connect to the cable modem? Is it a PCI card, or USB (thereby coming with network drivers), or do you connect to it with an ethernet cable?

Adrien

[MPHinteractive]

Hi, we connect with ethernet cables. Thanks again.

[genie]

What if you try nslookup on the client machine with the DNS server set to your ISP DNS? Like, start nslookup and type down server <ipaddress>.

[MPHinteractive]

Gave it a shot. The client machine I used (another Windows 2000 machine, IP 192.168.16.3) is configured to use the Wingate server (192.168.16.2) as the DNS server by default. I started nslookup and typed "server 63.240.76.4" to switch to my ISP's primary DNS server. nslookup reported that it couldn't resolve the name of that server, but went ahead and set it as the default. I then typed "google.com" to try and resolve google against the ISP's DNS server. The result was two timeouts, same as I see on the main Wingate server itself.

Meanwhile, the Wingate server firewall isn't showing anything, and the Wingate NAT log file shows the following...

10/29/04 08:53:34 192.168.16.3 Guest 0000000116 Requested: NAT: UDP 192.168.16.3:1427 <-> 63.240.76.4:53
10/29/04 08:53:36 192.168.16.3 Guest 0000000117 Requested: NAT: UDP 192.168.16.3:1428 <-> 63.240.76.4:53
10/29/04 08:54:06 192.168.16.3 Guest 0000000117 Traffic 0 56 56 0 30s
10/29/04 08:54:11 192.168.16.3 Guest 0000000116 Traffic 0 56 56 0 37s

I'd like to figure this out - I support a lot of clients running Wingate and I'm hesitant to do any 6.x upgrades until we figure out what's up here.

What do we try next?

[adrien]

Hi Park

You sure it's not just a dud DNS server? When I try to use it, I get nothing back either.

> www.microsoft.com
Server: ns6.attbi.com
Address: 63.240.76.4

DNS request timed out.
timeout was 2 seconds.
DNS request timed out.
timeout was 2 seconds.
*** Request to ns6.attbi.com timed-out
>

Adrien

[Pascal]

Yeah, I had the same result from an ADSL connection outside of a WinGate server - the DNS Server was (is) dead?

[MPHinteractive]

I've tried a variety of DNS servers and can't get responses from any of them with the ENS driver loaded...

With the ENS unloaded, here's a dump this morning from pinging the primary DNS server, then using it for name resolution...

==============
C:\>ping 63.240.76.4

Pinging 63.240.76.4 with 32 bytes of data:

Reply from 63.240.76.4: bytes=32 time=40ms TTL=54
Reply from 63.240.76.4: bytes=32 time=30ms TTL=54
Reply from 63.240.76.4: bytes=32 time=30ms TTL=54
Reply from 63.240.76.4: bytes=32 time=30ms TTL=54

Ping statistics for 63.240.76.4:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 30ms, Maximum = 40ms, Average = 32ms

C:\>ping 204.127.198.4

Pinging 204.127.198.4 with 32 bytes of data:

Reply from 204.127.198.4: bytes=32 time=60ms TTL=54
Reply from 204.127.198.4: bytes=32 time=70ms TTL=54
Reply from 204.127.198.4: bytes=32 time=60ms TTL=54
Reply from 204.127.198.4: bytes=32 time=61ms TTL=54

Ping statistics for 204.127.198.4:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 60ms, Maximum = 70ms, Average = 62ms

C:\>nslookup
Default Server: ns6.attbi.com
Address: 63.240.76.4

> google.com
Server: ns6.attbi.com
Address: 63.240.76.4

Non-authoritative answer:
Name: google.com
Addresses: 216.239.37.99, 216.239.57.99, 216.239.39.99

>
==============

Everything works fine with ENS unloaded; everything goes to heck with ENS loaded. This has consistently been the case for several days. It's an ENS issue, I'm afraid.

This was a product upgrade; could that be the problem? I've done a standard uninstall and reinstall with no change. Is there a way to thoroughly zap the old install before I do a reinstall?

Park

[genie]

Hi, Park

Do you have an ability to run network protocol sniffer on your wingate machine (commview, NetPatrol, etc.)? If you run it there, can you capture traffic to and from port 53 (UDP) so we can see what the actual UDP traffic is?

[MPHinteractive]

Never tried running a sniffer before, but just gave it a shot for you guys. These are CommView evaluation version logs, so I hope they give you the information you need.

I set a rule to only record traffic in- or outbound on port 53. I ran a standard test regimen (start nslookup, look for mphinteractive.net, look for google.com, exit nslookup) through various combinations of variables:

A) ENS driver disabled OR loaded

B) monitor traffic on server internal network card OR server external card

C) running nslookup on the server OR on a pc inside the network

I have posted the results logs to my web server at...

http://mphoffice.dns2go.com:9180/Traffi ... server.txt
http://mphoffice.dns2go.com:9180/Traffi ... server.txt
http://mphoffice.dns2go.com:9180/Traffi ... ext-pc.txt
http://mphoffice.dns2go.com:9180/Traffi ... int-pc.txt
http://mphoffice.dns2go.com:9180/Traffi ... server.txt
http://mphoffice.dns2go.com:9180/Traffi ... server.txt
http://mphoffice.dns2go.com:9180/Traffi ... ext-pc.txt
http://mphoffice.dns2go.com:9180/Traffi ... int-pc.txt

Hope this helps... I'll be in the office for a while this evening and will watch for troubleshooting responses from you guys to try and speed up the give-and-take here. Thanks...

Park

[genie]

Hi, Park - thanks for the captures, we are working on them now. Since you are at the office, can you open your gatekeeper for external binding and give us user/password info so we can take a loot at the config? Just drop me an email in case you are willing to go that far :)

[MPHinteractive]

Any news yet? ...

[genie]

Not yet - traffic snapshots looked normal - can you open your gatekeeper access for us so we can try configuration changes?

[MPHinteractive]

Sigh... I emailed you (genie@qbik.com) after your post of 11/2 saying that I was willing to do that but needed some directions. I followed the message up 30 minutes later with a second email that I thought I'd figured it out. If I did it right, my Remote Control Service has been bound to the external port since 11/2 for you guys to do diagnostics or whatever. (Not great for security, and of course I've got no firewall with ENS down either.)

Sorry if I sound a little frustrated, but I did what you asked 1 1/2 days ago and haven't seen any progress on your end. Nor did you respond to my emails telling me ifI needed to do something different. Tomorrow this problem will have been going on for a week. It's causing disruption at my office: I have to configure every customer PC we work on with the proxy ports, then remember to remove those settings before returning the computer; and my office email server with its spam-filtering capabilities is set to work through ENS, not via proxy. It's also taking up a lot of my time working with you to solve the problem, and I don't have gobs of spare time to throw at the issue right now.

I probably would have stayed at version 5.2.3 for a while, but I had upgraded my key to 6.0.3 in anticipation of eventually upgrading Wingate. Then the 5.2.3 started indicating an "illegal key" because I'd upgraded it, so I went ahead with the upgrade. Now I'm stuck and the answer isn't coming fast.

Like I said before, I support a couple dozen Wingate installations in libraries, offices, and other locations. I'm sure as heck not going to sell/upgrade them to 6.0.3 until I know it works here.

-end rant- Didn't mean to unload like that. Sorry! I do appreciate the personal support and understand that the time difference inhibits rapid responses. I'd just like to see more progress being made, especially when I'm putting in extra effort at my end to do packet captures and other stuff.

Thanks for continuing to look into this.

Park Hunter

[Pascal]

Hi Park,

Gene is sick at the moment, a summer flu caught him a couple of days ago. He's still responding to forum posts from home, but doesn't have access to his e-mail at the office and probably not to GateKeeper, etc.

I understand it's a tough one, especially with things open like that - can you resend the appropriate login / ip information to me? My direct email address is pascalv at qbik dot com.

[Pascal]

Hi Park, got your email and connected in. I sent you a detailed email about what I think might be the problem (Relating to Realtek 8029 chipset).

[MPHinteractive]

SOLVED!!! So far at least... Thanks for coming through, guys.

Pascal's emailed response to my question was very helpful, so I am copying it below for the benefit of others who might have a similar problem. I followed his final suggestion (ticking the option for the "Realtek chipset in use" in the advanced options program). After a reboot my problems were solved.

Didn't have any idea the network card driver could be such an issue!

Thanks again... Park

===========
Park:

For now, you can unbind the Remote Control Service from your External
Adapter. (I didn't want to do that remotely, best to let you manage your
config yourself)

A look through everything makes it all seem 100% perfect. I definately
does not look as if you've configured anything incorrectly. However,
your external adapter is a Realtek 8029 chipset based card.

They're very popular, but certain driver revisions for those cards have
an EXCEPTIONALLY buggy driver. The easiest answer might be to simpy
ensure you have the latest drivers for that network card (Or swap for
another network card if you have a spare on available).

Alternatively, and this might be the easiest thing to try - in our
driver we attempt to compensate for various network card chipsets
/drivers that have this problem. Unfortunately, we can't always detect
those erroneous cases, so you need to flag it as such.

If you look on the Start Menu, under Progams -> Wingate you will find a
utility called "Advanced Options". On the "Hardware Specific" section it
has a tick for "Realtek 8029 Chipset in use". Try changing the state of
that. (It will require a reboot)

Regards,

Pascal
===========