another vpn wins site to site to site problem*

have been working on this one for a while. i think i have come to the
conclusion that it cannot be done in the fashion i am trying to do it in or
with my current setup.

Things are configured as follows and the nature of the problem seems to
mainly be the issue of multihoming. I have a central server (192.168.2.0)
which is a dual nic routing setup. netbios is disabled on the wan link.
wins server is installed on this machine. browsing local subnet works just
fine* client are configured to do so via dhcp which is also running on the
server. on the routing setup, i have tried enabling and disabling
broadcast name resolution through the "server" properties and diabling
netbios over tcp/ip through the demand dial interfaces. i have been told to
disable all of these, i have tried it both ways on both sides and wins still
doesn't build the master browse list. in configuring the demand dial
interfaces from remote sites, should one include the primary wins server?
the other sites configure as follows (x2) 192.168.1.0 and 192.168.0.0
routers connect to the central server properly. everynow and then a partial
browse list shows up in my net places, but has never shown all three subnets
conjoined. i have tried changing the role of pdc to one of the non dual nic
remote sites, the process works, but then it only shows the browse list of
that machine's subnet. does such a scenario require an lmhosts file? it
seems that anything that uses vpn becomes multihomed, rras seems to retrieve
an address for "dial in" whether i want it to or not. as far as i can tell,
wins is not bound to these addresses if netbios resolution is disabled on
them? what would be the best way using these three windows 2003 routers to
come together and form and functional master browse list that incorporates
all 3 subnets??

any help / advice would be eagerly accepted.

cordially,

chris daane

 

I agree with you that this should work. Once your site to site links are
up, you effectively have three segments/subnets linked by routers. Browsing
should work just as it does for a LAN with three segments/subnets linked by
routers.

1. WINS does not build the browse lists. The computer browser service
does that. WINS only supplies the name resolution so that the browse masters
can contact each other across subnet/segment boundaries. See KB 188001
"Description of the Microsoft Computer Browse Service".

2. How is WINS configured? Do you have a single WINS server where all
machines register? Are the browse masters registering in WINS?

3. Apart from your PDC emulator, you can prevent the other RRAS servers
from becoming browse masters. Some other (single homed) machine would then
take on the role.

4. You can use the browstat utility from the support tools to debug the
operation of the browser service. There is also a new GUI utility called
browcon. See KB 818092.

5. There is a new KB on disabling Netbios over TCP/IP on RAS/VPN
interfaces. Apparently this can cause problems with UDP on W2k machines with
SP3 or later. The current advice is to delete the DisableNetbiosOverTcpip
key recommended in KB 292822, and to use IP addresses from a different IP
subnet for the RAS/VPN interfaces to solve the browsing problem. See KB
830063. (I am not at all sure yet how this relates to Server 2003 or to
LAN-to-LAN VPN links!)

 

Currently there is one wins server for each subnet, all with replication.
replication is configured for all ips of all the servers, this includes the
RRAS reserved ips.

 

First up, check in WINS to see if any browse masters are registering
with more than one IP address. This will cause problems.

If that is OK, it's time to start debugging exactly what the browser
service is doing using browstat or browcon. If you are a Technet subscriber,
there is a webcast on browcon on Technet Training CD 25.

 

i read somewhere that putting hte vpn stubs on seperate subnets has positive
effects? do you know anything of this method?

 

That is how I have always done it. Apart from anything else, it makes it
much easier to follow the routing table. And it certainly ties in with the
recommendations in KB 330063, where you don't disable Netbt on the "virtual"
interfaces, just put them in a different subnet.