One PC not browsing other subnet

  • Thread starter Thread starter Mark Hanford
  • Start date Start date
M

Mark Hanford

I've been stumped.

We have a network split into two subnets and joined via SonicWall VPN
appliances.
Local network is 192.168.100.x and the remote network is 192.168.1.x.

One particular PC is having a probem where accessing a server locally by
entering the name \\localserver results in the usual shares and printers,
but \\remoteserver just results in a "network path not found" error.
The PC can ping the remote servers, and can see them in the network
neighbourhood, but cannot seem to connect.


I have tried:
Rebooting (haha - step 1)
Remapping all drives
removing and readding the PC from the domain.

The strange thing is that it works for servers in the current site, but not
for servers on the remote site. It can't really be the site-to-site VPN, as
all other clients are fine.

TIA,

Mark Hanford
 
Most browsing problems are related to WINS, the server, the client settings,
or just not having WINS.
We have a network split into two subnets and joined via SonicWall VPN
appliances.
Local network is 192.168.100.x and the remote network is 192.168.1.x.

But it's surprising that ANY of the machine browse the "other" subnet.
When you have a router between two sets of machines you pretty much need
the WINS servers -- all clients must register with the same WINS "database".

This means if you have more than one WINS server then they must replicate.
One particular PC is having a probem where accessing a server locally by
entering the name \\localserver results in the usual shares and printers,
but \\remoteserver just results in a "network path not found" error.

This is name resolution, not browsing. They are two different things and
not
always directly related.
The PC can ping the remote servers, and can see them in the network
neighbourhood, but cannot seem to connect.

That implies that DNS resolution is working but that NetBIOS resolution
(WINS)
is failing.
I have tried:
Rebooting (haha - step 1)

Fine but don't flail.
Remapping all drives
removing and readding the PC from the domain.
Ditto.

The strange thing is that it works for servers in the current site, but not
for servers on the remote site. It can't really be the site-to-site VPN, as
all other clients are fine.

Or course, NetBIOS is broadcast based unless you have a WINS server and
the clients (INCLUDING the Servers as clients) are set to use that WINS
server.

What is your WINS server configuration?
 
Herb Martin said:
Most browsing problems are related to WINS, the server, the client settings,
or just not having WINS.


But it's surprising that ANY of the machine browse the "other" subnet.
When you have a router between two sets of machines you pretty much need
the WINS servers -- all clients must register with the same WINS "database".

This means if you have more than one WINS server then they must
replicate.

We have a WINS server on each site, and we've had this network configuration
for nearly 2 years now without change.
The WINS servers replicate with each other regulary, and the stats indicate
that it has indeed replicated recently.
Also, all other PC's are fine, and this PC has been working until recently.

This is name resolution, not browsing. They are two different things and
not always directly related.
Maybe not, but I thought it best to relate the symptoms.
That implies that DNS resolution is working but that NetBIOS resolution
(WINS)
is failing.


Fine but don't flail.
Don't flail? I'm not sure that rebooting a windows workstation can be
considered "flailing" - it's fixed problems as often as not.
This was done as the symptoms seemed to match those of another problem in
the KB.
Or course, NetBIOS is broadcast based unless you have a WINS server and
the clients (INCLUDING the Servers as clients) are set to use that WINS
server.

What is your WINS server configuration?
Not sure what you mean - there are many options - what do you want to know?
I've done a quick search of the registrations, and both servers give the
same information for the client and the servers.

From what you are saying, it looks like this is heading towards being a WINS
issue. As the other clients are okay, I'm assuming it can't be a problem
with the WINS database "én masse", so (my WINS knowledge is faltering
somewhat now) does the client cache any of this? Could the database be
corrupted in some way that affects only certain clients?

Thanks for the prompt response, Herb
 
We have a WINS server on each site, and we've had this network
configuration
for nearly 2 years now without change.
The WINS servers replicate with each other regulary, and the stats indicate
that it has indeed replicated recently.
Also, all other PC's are fine, and this PC has been working until
recently.

Are all the clients listing one or both of these WINS servers in their
client properties?

"Client" here includes machines that are SERVERS for OTHER purposes and even
the WINS servers themselves.

Servers will not register themselves with WINS unless they are clients.
(Real) Clients
will not lookup server using WINS unless they are clients. Have every
machine use
the correct WINS server(s) in their client properties.
 
Back
Top