two winxp home machines, varied results

[briansmccabe]

Hello all -

I have two win xp home machines that, up until yesterday, were
networking beautifully together. Both machines have shared directories
and mapped drives etc, and one has a printer that the other also uses.

Starting some time yesterday, one machine ("brian" is its name) was
able to see the other's (named "heidi") shared dirs, but "heidi" was no
longer able to see "brian"'s shared dirs or "brian"'s printer. I did
absolutely nothing to cause this that I am aware of - I wasn't even
home when this stuff stopped working.

I have tried everything online that I can find. I ran through a list
of ping commands from each machine to the other. Brian can ping
everything just fine; heidi cannot ping brian by name nor by IP. I have
verified that "enable netbios over tcp/ip" is set to "enable" on both
machines. I have checked done "ipconfig /all" on both machines and have
found that the node type for each machine is "unknown." I verified this
by looking in the registry for both machines.

I am virtually certain that the problem lies within "brian" and not
"heidi" because port requests that my router is supposed to forward to
"brian" stopped working some time yesterday as well. They continue to
not work. I thought perhaps the network card (which is built into the
motherboard) needed a driver upgrade, so I installed the latest driver
I could find for it. That did nothing.

this is not the first time this has happened (i.e., everything
networking swimmingly, and then POOF - out of nowhere, everything goes
to hell). The last time it happened, I caved and simply reformatted
both machines. Needless to say, I have no interest in doing that again.
There's got to be a better way.

One other thing that is worth pointing out is that the last time this
happened, the same scenario unfolded - "brian" could utilize shared
resources on "heidi" but not vice versa; and the router stopped
forwarding port requests to "brian" as outlined in the router's
configuration. "brian" also has a VPN adapter (cisco's latest) so that
I can VPN into work. I don't know if this is relevant or not.

ANY help would be tremendously appreciated. My printer and several
vital shared files are on my machine that my wife has to be able to
access so this is actually pretty important.

Thanks in advance -

Brian Mc

 

[Chuck]

Hello all -

I have two win xp home machines that, up until yesterday, were
networking beautifully together. Both machines have shared directories
and mapped drives etc, and one has a printer that the other also uses.

Starting some time yesterday, one machine ("brian" is its name) was
able to see the other's (named "heidi") shared dirs, but "heidi" was no
longer able to see "brian"'s shared dirs or "brian"'s printer. I did
absolutely nothing to cause this that I am aware of - I wasn't even
home when this stuff stopped working.

I have tried everything online that I can find. I ran through a list
of ping commands from each machine to the other. Brian can ping
everything just fine; heidi cannot ping brian by name nor by IP. I have
verified that "enable netbios over tcp/ip" is set to "enable" on both
machines. I have checked done "ipconfig /all" on both machines and have
found that the node type for each machine is "unknown." I verified this
by looking in the registry for both machines.

I am virtually certain that the problem lies within "brian" and not
"heidi" because port requests that my router is supposed to forward to
"brian" stopped working some time yesterday as well. They continue to
not work. I thought perhaps the network card (which is built into the
motherboard) needed a driver upgrade, so I installed the latest driver
I could find for it. That did nothing.

this is not the first time this has happened (i.e., everything
networking swimmingly, and then POOF - out of nowhere, everything goes
to hell). The last time it happened, I caved and simply reformatted
both machines. Needless to say, I have no interest in doing that again.
There's got to be a better way.

One other thing that is worth pointing out is that the last time this
happened, the same scenario unfolded - "brian" could utilize shared
resources on "heidi" but not vice versa; and the router stopped
forwarding port requests to "brian" as outlined in the router's
configuration. "brian" also has a VPN adapter (cisco's latest) so that
I can VPN into work. I don't know if this is relevant or not.

ANY help would be tremendously appreciated. My printer and several
vital shared files are on my machine that my wife has to be able to
access so this is actually pretty important.

Thanks in advance -

Brian Mc

Brian,

You, quite likely, have a browser problem. Now I AM NOT Talking about the
program that you use to surf the web. The browser is the subsystem that
provides the content of Network Neighborhood.
<http://nitecruzr.blogspot.com/2005/04/nt-browser-or-why-cant-i-always-see.html>

Check each computer for misconfigured / overlooked firewalls, and for registry
setting restrictanonymous.
Misconfigured / overlooked firewalls (maybe packaged with the VPN?):
<http://nitecruzr.blogspot.com/2005/05/your-personal-firewall-can-either-help.html>
Registry setting restrictanonymous:
<http://nitecruzr.blogspot.com/2005/07/restrictanonymous-and-your-server.html>

If no help yet, provide "browstat status" and "ipconfig /all" from each
computer, and we'll diagnose the problem. Read this article, and linked
articles, and follow instructions precisely:
<http://nitecruzr.blogspot.com/2005/05/troubleshooting-network-neighborhood.html#AskingForHelp>

 

[Guest]

Brian,

As chuck said, you need to check for the firewall settings in the Computer
named Brian.

Can you let me know the results of the command ipconfig /all of both the
computers ?

Thanks

 

[Brian McCabe]

Thanks for being so willing to help out. I appreciate it!!

I was gonna address this last, but I think I had a bit of a
breakthrough at the end of my research so this info is getting bumped
to the top.

The only firewall I have on my machine *aside* from the Cisco VPN
client (more on that in a minute) is Windows Firewall that came with
SP2. Oh yeah, that reminds me: both machines are WinXP Home with the
latest updates installed. Anyway, regarding the Cisco VPN client -
there was a setting in there called "stateful firewall (always on)"
that was CHECKED. I unchecked it and have tried a few things.
NEWSFLASH: I can now ping "brian" from "heidi" by name and by IP. Also,
port requests on my router that are set up to forward to "brian" are
working again as well. Finally, I attempted to map a drive on "heidi"
to a shared dir that resides on "brian" and was able to do so. To me,
that accomplishes everything I have been trying to keep stable. BUT
that raises another question or two: is it safe to disable the
"stateful firewall" on my VPN client? Perhaps I should check with the
IT guys at work?

I'll go ahead and include the remainder of my findings in this post in
case you want to see them and / or there's something else I need to be
aware of. If you consider the problem solved and do not have the time
to review this info, I understand.

Ok, here's what I found with regards to the restrictanonymous presence
in the registry.

on "brian", the following registry dirs had keys named either
"restrictanonymous" or "restrictanonymousSAM." In each case, the value
for "restrictanonymous" was 0 and the value for restictanonymousSAM was
1.

HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Control\Lsa
HKEY_LOCAL_MACHINE\SYSTEM\ControlSet003\Control\Lsa
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa

Furthermore, there were also a pair of dirs that had my search criteria
("restrictanonymous") in the name of the dir itself.

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows
NT\CurrentVersion\SeCEdit\Reg
Values\MACHINE/System/CurrentControlSet/Control/Lsa/RestrictAnonymous

which has the following keys and their corresponding values:

(Default) REG_SZ (value not set)
DisplayName REG_SZ Network access: Do not allow anonymous
enumeration of SAM accounts and shares
DisplayType REG_DWORD 0
valueType REG_DWORD 4


HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows
NT\CurrentVersion\SeCEdit\Reg
Values\MACHINE/System/CurrentControlSet/Control/Lsa/RestrictAnonymousSAM

which has the following keys and their corresponding values:

(Default) REG_SZ (value not set)
DisplayName REG_SZ Network access: Do not allow anonymous
enumeration of SAM accounts (NOTE: does NOT say "and shares" at the
end)
DisplayType REG_DWORD 0
valueType REG_DWORD 4


The registry findings for "heidi" were identical to that of "brian".

Here is the IPCONFIG and BROWSTAT listings for each machine. NOTE: The
"browstat" command does not appear to have worked.

IPCONFIG info for "brian"


Windows IP Configuration



Host Name . . . . . . . . . . . . : brian

Primary Dns Suffix . . . . . . . :

Node Type . . . . . . . . . . . . : Unknown

IP Routing Enabled. . . . . . . . : No

WINS Proxy Enabled. . . . . . . . : No

DNS Suffix Search List. . . . . . : hsd1.ut.comcast.net.



Ethernet adapter Local Area Connection:



Connection-specific DNS Suffix . : hsd1.ut.comcast.net.

Description . . . . . . . . . . . : VIA Rhine II Fast Ethernet
Adapter

Physical Address. . . . . . . . . : 00-E0-4C-97-B6-3B

Dhcp Enabled. . . . . . . . . . . : Yes

Autoconfiguration Enabled . . . . : Yes

IP Address. . . . . . . . . . . . : 192.168.15.102

Subnet Mask . . . . . . . . . . . : 255.255.255.0

Default Gateway . . . . . . . . . : 192.168.15.1

DHCP Server . . . . . . . . . . . : 192.168.15.1

DNS Servers . . . . . . . . . . . : 192.168.15.1

Lease Obtained. . . . . . . . . . : Thursday, August 25, 2005
10:09:53 PM

Lease Expires . . . . . . . . . . : Saturday, August 27, 2005
10:09:53 PM



BROWSTAT info for "brian"

'browstat' is not recognized as an internal or external command,
operable program or batch file.


IPCONFIG info for "heidi"



Windows IP Configuration



Host Name . . . . . . . . . . . . : heidi

Primary Dns Suffix . . . . . . . :

Node Type . . . . . . . . . . . . : Unknown

IP Routing Enabled. . . . . . . . : No

WINS Proxy Enabled. . . . . . . . : No

DNS Suffix Search List. . . . . . : hsd1.ut.comcast.net.



Ethernet adapter Local Area Connection:



Connection-specific DNS Suffix . : hsd1.ut.comcast.net.

Description . . . . . . . . . . . : Compaq NC3161 Fast Ethernet
NIC

Physical Address. . . . . . . . . : 00-50-8B-D7-6B-F6

Dhcp Enabled. . . . . . . . . . . : Yes

Autoconfiguration Enabled . . . . : Yes

IP Address. . . . . . . . . . . . : 192.168.15.101

Subnet Mask . . . . . . . . . . . : 255.255.255.0

Default Gateway . . . . . . . . . : 192.168.15.1

DHCP Server . . . . . . . . . . . : 192.168.15.1

DNS Servers . . . . . . . . . . . : 216.148.227.68

204.127.202.4

Lease Obtained. . . . . . . . . . : Thursday, August 25, 2005
10:07:07 PM

Lease Expires . . . . . . . . . . : Friday, August 26, 2005
10:07:07 PM



BROWSTAT info for "heidi"

'browstat' is not recognized as an internal or external command,
operable program or batch file.


So there you have it. All I have done here is compile information; I
did not edit any registry entries because from following the guide you
provided on the restrictanonymous aspect of the registry, it did not
look like editing anything was neccesary. I included the search
findings here in case you needed to peruse them.

 

[Chuck]

Thanks for being so willing to help out. I appreciate it!!

I was gonna address this last, but I think I had a bit of a
breakthrough at the end of my research so this info is getting bumped
to the top.

The only firewall I have on my machine *aside* from the Cisco VPN
client (more on that in a minute) is Windows Firewall that came with
SP2. Oh yeah, that reminds me: both machines are WinXP Home with the
latest updates installed. Anyway, regarding the Cisco VPN client -
there was a setting in there called "stateful firewall (always on)"
that was CHECKED. I unchecked it and have tried a few things.
NEWSFLASH: I can now ping "brian" from "heidi" by name and by IP. Also,
port requests on my router that are set up to forward to "brian" are
working again as well. Finally, I attempted to map a drive on "heidi"
to a shared dir that resides on "brian" and was able to do so. To me,
that accomplishes everything I have been trying to keep stable. BUT
that raises another question or two: is it safe to disable the
"stateful firewall" on my VPN client? Perhaps I should check with the
IT guys at work?

Brian,

You're asking a very interesting question here. One that must be analysed in
TWO directions. Most firewalls are used to protect one environment against
another. But which environment do you trust? Are you protecting your home LAN
from your work LAN, or vice versa?

As networks become more complex, and more common, bidirectional protection
becomes more significant.

So what protection does a VPN bundled firewall provide? What is intended to
provide? What happens when it is disabled, for convenience? These are all
issues which I have yet to think about. Please do discuss this with the IT
guys, and please please do let us know what they say.

I'll go ahead and include the remainder of my findings in this post in
case you want to see them and / or there's something else I need to be
aware of. If you consider the problem solved and do not have the time
to review this info, I understand.

I'm here to learn. If there's anything else to learn, I'lll keep posting. If
you keep posting, I will too.

Ok, here's what I found with regards to the restrictanonymous presence
in the registry.

on "brian", the following registry dirs had keys named either
"restrictanonymous" or "restrictanonymousSAM." In each case, the value
for "restrictanonymous" was 0 and the value for restictanonymousSAM was
1.

HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Control\Lsa
HKEY_LOCAL_MACHINE\SYSTEM\ControlSet003\Control\Lsa
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa

That is called a Registry "Key". The "CurrentControlSet" key is the relevant
one. The others were current at some previous time. Only adjust
"CurrentControlSet".

Furthermore, there were also a pair of dirs that had my search criteria
("restrictanonymous") in the name of the dir itself.

The leaf elements are called "values". The "value" named "restrictAnonymous"
(please note the small "r" in the name!) (Microsoft named this thing) must be
"0". This is all Microsoft terminology.

Please don't confuse "restrictAnonymous" and "restrictAnonymoussam". Those are
two separate values! Please don't change "restrictAnonymoussam", only
"restrictAnonymous", IFF necessary!

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows
NT\CurrentVersion\SeCEdit\Reg
Values\MACHINE/System/CurrentControlSet/Control/Lsa/RestrictAnonymous

which has the following keys and their corresponding values:

(Default) REG_SZ (value not set)
DisplayName REG_SZ Network access: Do not allow anonymous
enumeration of SAM accounts and shares
DisplayType REG_DWORD 0
valueType REG_DWORD 4


HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows
NT\CurrentVersion\SeCEdit\Reg
Values\MACHINE/System/CurrentControlSet/Control/Lsa/RestrictAnonymousSAM

which has the following keys and their corresponding values:

(Default) REG_SZ (value not set)
DisplayName REG_SZ Network access: Do not allow anonymous
enumeration of SAM accounts (NOTE: does NOT say "and shares" at the
end)
DisplayType REG_DWORD 0
valueType REG_DWORD 4


The registry findings for "heidi" were identical to that of "brian".

Here is the IPCONFIG and BROWSTAT listings for each machine. NOTE: The
"browstat" command does not appear to have worked.

BROWSTAT info for "heidi"

'browstat' is not recognized as an internal or external command,
operable program or batch file.


So there you have it. All I have done here is compile information; I
did not edit any registry entries because from following the guide you
provided on the restrictanonymous aspect of the registry, it did not
look like editing anything was neccesary. I included the search
findings here in case you needed to peruse them.

Please read instructions about using the Path properly. Or run browstat
directly from the folder where you copied it.
<http://nitecruzr.blogspot.com/2005/05/using-path-and-making-custom-program.html>
<http://nitecruzr.blogspot.com/2005/05/browstat-utility-from-microsoft.html>
<http://nitecruzr.blogspot.com/2005/06/command-window.html>

But based upon what you say above about the VPN firewall, this point may be
moot.

At any rate, I suspect the problem may be identified, and based upon what you
get from the IT guys at work, may be solved. Please do let us know what they
say about their needs. I provide advice so I may learn, and may instruct
others. Your situation is one which should be of interest to many - WHO is
being protected by a VPN firewall?

Some background: AOL customers, using AOL purely as a portal, but providing
their own ISP, access the AOL servers thru a VPN. Some time ago, the
effectiveness of this setup became embarrassingly obvious:
<http://nitecruzr.blogspot.com/2005/12/todays-security-alert.html#7/28>

The AOL situation may be relevant to yours. In both directions. Please keep us
updated on this.

 

[Brian McCabe]

Hi all -

Thanks again for the assistance. I apologize for the delay in a
followup post.

Here's what I did. I did not speak to anyone on the IT team. I did,
however, speak to a friend who used to be on the IT team and is now on
my team (web development team). He said if I were to ask the IT guys,
they would definitely say to have the stateful firewall turned on. But
based on the fact that a) I need to be able to have my network at home
running smoothly and b) I need the VPN access to work, I am choosing to
leave it off.

I think the rationale that IT wants the stateful firewall turned on
is due to them being interested in protecting their network. If someone
VPNs in to the network on a machine that is wide open to all manner of
illicit attacks from various online trojan hives etc, the network's
integrity could become compromised. Hence the overpowering, "always on"
stateful firewall. Sure, it could goof up the user's home network, but
from the perspective of my employer, I am sure their thinking is
"better your network than ours" and perhaps rightly so.

On the other hand, if a person VPNs in from a machine that is well
protected *independent* of the stateful firewall built into the Cisco
VPN client, I think it is ok to shut off the Cisco stateful firewall.
My home network is adequately firewalled, and there are *zero*
configuration options with the built-in Cisco firewall, so using it is
nothing but a headache. I feel comfortable moving forward having the
stateful firewall disabled.

 

[Chuck]

Hi all -

Thanks again for the assistance. I apologize for the delay in a
followup post.

Here's what I did. I did not speak to anyone on the IT team. I did,
however, speak to a friend who used to be on the IT team and is now on
my team (web development team). He said if I were to ask the IT guys,
they would definitely say to have the stateful firewall turned on. But
based on the fact that a) I need to be able to have my network at home
running smoothly and b) I need the VPN access to work, I am choosing to
leave it off.

I think the rationale that IT wants the stateful firewall turned on
is due to them being interested in protecting their network. If someone
VPNs in to the network on a machine that is wide open to all manner of
illicit attacks from various online trojan hives etc, the network's
integrity could become compromised. Hence the overpowering, "always on"
stateful firewall. Sure, it could goof up the user's home network, but
from the perspective of my employer, I am sure their thinking is
"better your network than ours" and perhaps rightly so.

On the other hand, if a person VPNs in from a machine that is well
protected *independent* of the stateful firewall built into the Cisco
VPN client, I think it is ok to shut off the Cisco stateful firewall.
My home network is adequately firewalled, and there are *zero*
configuration options with the built-in Cisco firewall, so using it is
nothing but a headache. I feel comfortable moving forward having the
stateful firewall disabled.

Brian,

If that's what works for you, then it's your decision. Are there other
employees with your situation? If so, what are they doing?

It's in your own long term interest to discuss this with IT, and to give them a
chance to find a solution. Be careful, if you should cause any problem that the
IT group has to resolve, and they find out that you're operating without
protection of the firewall, then you could be at risk.

 

[Brian McCabe]

The email that they distribute to employees using a VPN connection
gives pretty explicit instructions in how to set it up, and there's no
mention whatsoever of the stateful firewall - nothing about turning it
on, off, it being optional, etc. Nothing. So I highly doubt my standing
at work would be jeopardized by having this feature turned off.
Besides, I'm *not* operating without firewall protection -- I am
operating without *that* firewall's protection, that's all. The fact
that that particular firewall gives me no configuration options makes
it far too cumbersome to work with. I think the guys in IT would be
inclined to agree with that, as a matter of fact. If they were dealing
with employees who have no computer savvy, I could see them insisting
it be turned on but that's not the case with myself and the other
people on my team who are utilizing it.

 

[Chuck]

The email that they distribute to employees using a VPN connection
gives pretty explicit instructions in how to set it up, and there's no
mention whatsoever of the stateful firewall - nothing about turning it
on, off, it being optional, etc. Nothing. So I highly doubt my standing
at work would be jeopardized by having this feature turned off.
Besides, I'm *not* operating without firewall protection -- I am
operating without *that* firewall's protection, that's all. The fact
that that particular firewall gives me no configuration options makes
it far too cumbersome to work with. I think the guys in IT would be
inclined to agree with that, as a matter of fact. If they were dealing
with employees who have no computer savvy, I could see them insisting
it be turned on but that's not the case with myself and the other
people on my team who are utilizing it.

OK, Brian. Just as long as you know the liabilities. Stay safe.