Internet access via DSL dies until reboot

[Guest]

The sole Win2000 workstation (SP4) on our LAN periodically cannot access the
Internet via DSL until it (the workstation) is restarted. All protocols fail
(ftp, http, smtp, etc). The issue is specific to the Win2000 machine, NT and
XP machines on the same network do not experience this problem. The problem
never kicks in when actually accessing the Internet, but after a period of
inactivity. When the machine cannot access the Internet, it can still
communicate perfectly with other machines on the LAN. Anti-virus/worm
software (Nortons) on the machine is up to date. Any suggestions?

TIA, John

 

[Kurt]

I'd start with some general troubleshooting.
Can you ping the near side of thedefault gateway?
Can you ping the far side?
How 'bout something on the other side by IP address?
By fqdn?
tracert google.com - where does it stop?

....kurt

 

[Frankster]

Check that the 2000 machine's TCP/IP properties point ONLY to your internal
DNS server. Remove the public DNS entry(s) if present.

-Frank

 

[Guest]

Frank

Thank you for your response. The machine has only 2 external DNS servers
defined, as per other machines on the network, and as per the instructions
supplied by the ISP when I installed the DSL connection. So, I'm reluctant to
change this setup unless you can explain the ratiomale behind your suggestion.

The problem has not recurred since posting the original message but I'll do
some investigation next time it cuts in. I'd hoped installing SP4 would fix
the issue as it does appear to be W2000 specific, and while SP4 does appear
to have halved the frequency with which it occurs, it still continues.

John

 

[Kurt]

Frankster's instructions apply if you are running a Windows Active
Directory. If you don't have internal name servers and only need DNS for the
Internet, your ISP's DNS will do just fine. But you still need to narrow the
problem down. Otherwise it's like saying, "My car won't go - what's wrong?".
In most cases basic tools like ping, nslookup and tracert will get you
closer to the problem.

....kurt

 

[Frankster]

Kurt, I'm not sure why everyone keeps saying that this only applies if you
are running AD. I had this problem myself before I learned better, without
AD.

Look at it this way, even in a non-AD environment, if you configured your
hardware router with TCP/IP properties that included both internal and
external dns servers, sooner or later, when one dns server was not reachable
for some reason, and the next was tried, you'd still have a problem, right?
Still, the inside dns would not know about outside resources and vice versa.
Even without AD, right? This is why inside dns in a split dns environment
needs forwarders, right? Am I missing something? I don't see where it only
applies to AD systems.

-Frank

 

[Kurt]

If you need to resolve internal names with DNS then I'd say you are right.
However, I've not seen a Windows network that uses DNS except AD. Even NT4
domains didn't require DNS for internal name resolution. And workgroups rely
solely on broadcast netBios resolution (or WINS if they have routed
segments). I doubt the OP even has an internal name server. But I'll give
you that if he does, then you are right.

....kurt

 

[Frankster]

If you need to resolve internal names with DNS then I'd say you are right.

Ah... okay, then it makes sense. Internal DNS is the real point, not AD.

However, I've not seen a Windows network that uses DNS except AD.

Well, I have seen many. Especially in a mixed OS environment. Often a Unix
box provides DNS for the Windows boxes. Very routine.

Even NT4 domains didn't require DNS for internal name resolution.

No, they didn't *require* it, but they would use it in a DNS environment.

I doubt the OP even has an internal name server. But I'll give you that if
he does, then you are right.

...kurt

True, he may not. There are many possibilities for his problems. You asked a
number of pointed questions to help narrow down the cause - he didn't answer
any of your questions. My comment was just one thing to check... with the
limited info he posted. His symptoms are indicative of a misconfigured split
DNS (seemingly intermittent outside connection). But yes, there are many
other things that could cause this symptom. If he provided more detail it
would help. Since he used vague phrases such as "cannot access the Internet"
and "The problem never kicks in", it is pretty difficult to provide help.

-Frank

 

[Kurt]

"> Ah... okay, then it makes sense. Internal DNS is the real point, not AD.

Yes, you got me there! Internal DNS is the issue, not AD specifically.

....kurt

 

[Guest]

Ah... okay, then it makes sense. Internal DNS is the real point, not AD.


Well, I have seen many. Especially in a mixed OS environment. Often a Unix
box provides DNS for the Windows boxes. Very routine.


No, they didn't *require* it, but they would use it in a DNS environment.


True, he may not. There are many possibilities for his problems. You asked a
number of pointed questions to help narrow down the cause - he didn't answer
any of your questions. My comment was just one thing to check... with the
limited info he posted. His symptoms are indicative of a misconfigured split
DNS (seemingly intermittent outside connection). But yes, there are many
other things that could cause this symptom. If he provided more detail it
would help. Since he used vague phrases such as "cannot access the Internet"
and "The problem never kicks in", it is pretty difficult to provide help.

A very belated follow-up - hopefully someone is still listening! The machine
has behaved for nearly 3 weeks but finally misbehaved again today. I was
light on detail as I expected this to be a known W2000/DSL issue - and that
someone would say to install patch xyz.

A packet trace shows that once the problem cuts in, for any attempt to
communicate with an address on the far side of the DSL router, the machine
begins by issuing an ARP request for 0.0.0.7 (at least thats the value used
on this occasion) instead of the gateway actual IP. Running "ipconfig /all"
still shows the correct value for the default gateway.

Thanks, John