> -----Original Message----- > From: Michael D. Schleif [mailto:[EMAIL PROTECTED]] > Sent: January 9, 2002 9:31 AM > To: Brock Nanson > Cc: [EMAIL PROTECTED] > Subject: Re: [Leaf-user] DCD, ipsec & windows networking ??? > > > > Brock Nanson wrote: > > > > The catch to all this is browse lists. Unless you are > running Samba > > boxes on *both* ends of the VPN doing browse list > synchronization, you > > won't see the machines in both LAN's in Network > Neighborhood. I also > > found that having one of the Samba boxes do WINS serving > helped... I > > never needed the lmhosts or hosts files on the > workstations. However, > > if you don't have Samba, you can map resources by IP > without issue. I > > found that transfers were MUCH faster this way, rather than using > > Network Neighborhood. Don't know why... Just a M$ thing I guess. > > > > As far as firewall rules go, I can't say for sure as I'm > using Eiger, > > not Dachstein, but the only issue I had was with SNMP being > blocked by > > default when I tried to get a Jet Direct card going on the > other side. > > Virtually everything else goes straight down the tunnel as it's > > encrypted anyway. So, if your tunnel is up and operational, you > > should be able to cut/paste at will. But the local browse > broadcasts > > aren't routable and hence, won't find their way onto the > other subnet. > > What do you mean, ``able to cut/paste at will''?
**** I'm assuming you want to be able to open Network Neighborhood and see all the machines on each LAN (which must be in different workgroups!). Clicking on a machine would give you the shared resources, further clicking would show files etc. This is what you want, right? Assuming this, then the cut/paste reference relates to moving, opening, copying files with point/click in Windows Explorer or where ever - typical Windows file manipulation. > > What about shares? If we cannot browse to the other side > with explorer, how do we map shares? Manually, by knowing > the name/address and share name? **** Yes. You would need to 'map network drive' and specify '\\192.168.x.y\share' by knowing all in advance. You would then be able to browse the files. In order to 'browse' (and you used the exact term!), you need a browse list. These are generated within the subnet by multicast (? I'm on thin ice here - not 100% sure of the details!!) which is not routable through the VPN. Luckily, Samba has the ability to elect itself the masterbrowser on the LAN and share browse information with Samba servers on other LANs through the VPN. This is how I got it working. To the best of my knowledge, NT won't do this. I found that Samba would then report the workgroup name for the other end, but NOT the machines within. For some reason, I needed WINS active on ONE Samba server (all workstations across the LANs pointed to it) to enable browsing of the actual workstations within the remote workgroup. I've never satisfied myself as to why this was, or that it was the only way! However, the browse list would include all the local workstations but only the master browsers on the remote LANs. Clicking on the remote workgroup effectively asks the remote browsemaster for a browse list. How or why it was unable to return the list without WINS active is beyond my comprehension. It may be as simple as not being able to map the IP of the remote browsemaster from the name in Network Neighborhood... At least that's my suspicion. Just as a FYI, I found the VPN to be horribly slow when doing file operations from within Network Neighborhood. If I located the resource, then mapped it as a drive, the same operations were much faster when accessed via the mapped drive. Brock _______________________________________________ Leaf-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user
