Connecting NetWare LAN to NT LAN via Router - drive mapping issue

Are the remote and local LANs sharing a common, properly configured protocol ?
You noted NetBEUI in your question - note that this is not a routable protocol and you should really use something else, or propagate NetBEUI broadcasts through the routers (inadvisable, lots of network traffic).
At home, you can use NetBEUI over DUN to connect to a RAS server, which acts as a NetBEUI gateway to your LAN, in that you can use NetBEUI to access all the other protocols, as long as you've configured RAS to do this.
We need more details - what are the exact components of each LAN you are trying to connect ?
Also, how is your router configured ?
What protocols is it letting through, is it filtering out any ports etc....

Thanks Tim.  Not filtering any ports out.  The Netware network has 10-ish  Win 95 machines on it, all with their gateway set to the router's IP address.  Our network has the router set up to allow the Netware network in unmolested (allegedly).  When I kick off a ping at the remote end, after 3 unsuccessful pings, the network has connected and the 4th ping works.  I can then go into Internet Explorer, type in the address of our Intranet server (http://enginent/cpnet/whatever...) and get a full and fast response.  What I want to be able to do is:
On any of the Win '95 machines on the Netware network, map a network drive (ie 'W') to be a public shared folder on the NT machine on our network.  This will allow the users on the Win '95 machines on the Netware network to run an application (with its data) stored on our network...  I'm pretty sure this should be achievable, I'm just not quite sure why it's not working at the moment.

You really, really need to look into WINS.  This is so well-documented that its nuts, but a place to start is http://www.idg.net/idg_frames/english/content.cgi?vc=docid_9-53395.html

Alternately, if you use Cisco routers, add "ip forward-protocol udp", and "ip helper-address X.X.X.X" to routers at both ends of the WAN link connecting the two sites.  Additionally, remove the line "no ip directed-broadcast" on both routers.  X.X.X.X should be the "directed broadcast" address for the remote subnet.  E.g. if the netware network is addressed 192.168.1.0/255.255.255.0, the directed broadcast address for that subnet is 192.168.1.255.  If the other subnet is addressed 192.168.2.0, its directed broadcast address is 192.168.2.255.

Using these "ip helper" addresses is a Really Bad Idea if you're paying by-the-minute for a connection between the two sites or if you have a low-bandwidth link between sites (e.g. anything under 1Mbps).

Hmmm. I'll take your advice and look up info on WINS.  Is it normally the case that routers (the two in question are an OfficeConnect 521 at the far end and a Netgear RT328 at our end) are set up to block these things by default?  I'd have thought it more likely that the default behaviour would have been to allow everything until blocked.  I understand that NetBeui is not routable, but I thought there was some kind of NetBios that was 'routable'.  Is what I'm trying to do here out of the norm or not? I thought it would be one of the commonest things to want to do, share network drives over the WAN...

To add further info, it is a standard UK ISDN line, therefore only 64K is available and yes, we do have to pay by the minute.  (I don't want to investigate multi-link until the basic setup is working).  Is it a bad idea to have shared drives over a WAN - am I going to keep getting 'keep-alive' packets opening the link?

To further complicate matters, after this link is done, there is another office to connect that only has NetWare, ie NetWare 3.2 to NetWare 3.2 so is that going to cause even more trouble for me? (I've heard that NetWare servers like to check up on each other regularly, thus keeping the link open so I have to investigate spoofing too...)

I am away for a week now so it would be helpful if people could post comments but I can't attempt any changes until Monday 25th onwards.  Thanks for the comments so far.

Depends what client you have on 95...
If it's Client for Microsoft Networks, then you should be able to share something on your NT box using NWLink as a compatible protocol.
If it's Client Services for Netware installed, then all the 95 machines can possibly see is Netware servers....
So - you've got to fool the 95 machines into seeing NT as a Netware server and the only way to do this is to install File and Print Services for Netware on your NT server.
Don't forget to install NWLink on your server as a common protocol.
Also remember to set frame type to 802.2 if you're using NWLink.
Netware 3.2 shouldn't pose a problem.
Having a share with either of these methods over an IDSN link is a problem as you have to wait for it to activate...
So - it can be done, but won't give you the best response (especially for this application you're talking about).
If you want to run the lot over IP (better reliability over this kind of link), then you can share the resource as normal, but the only way I've tried to access it is via Client for Microsoft Networks using TCP/IP as a common protocol.
Not sure how CSNW handles this and if it responds to NetBIOS over TCP/IP in the same way ????
Someone else should have some ideas ?

Maybe I made a bad assumption (that he's going to use CLient for Microsoft Networks).  But this is really the way to go instead of tricking the NT server into thinking it's netware, and tricking the client machines into thinking they're talking to a netware server via CSWN.  He should base his microsoft networking on IP, IMHO (unless there's a compelling reason to use IPX).  In order to do this, he needs to set up WINS first to make his original scenario work (95 machines to NT via IP).

The second situation (2 netware 3.2 LANs connected via ISDN) should really be addressed in a separate question.

Ah, thinking some more about this, if people are going to use this more than maybe 2 hours per day total you may want to look into frame relay.  Tweaking usage parameters on per-minute usage is no fun and somewhat of a "black art."  A bank that I consulted for (I did *not* set up the ISDN links) ended up with a $24,000 bill a couple months ago when their ISDN "backups" were put into use more than they originally planned.  Somebody got fired.

I'm back from holiday now and keen to get this sorted (hence the upping of points).  I agree with McDonc that I should keep NetWare out of this until I come to the point where I need to link the NetWare machines in.  I am, however, still unclear about how I can tell the remote site (W95 machines on Netware 3.2 network) to recognise that '//enginent/public/database' is via the router onto the NT machine.  I've set up the default gateway on the W95 machine to be the router's IP address and I can ping our network fine from the remote site, but when I look in the network neighborhood I can't see any machines to map network drives to, as I can on the local network.  Is it possible to set up the link to allow browsing of the machines names on our site from the remote site?  Do I need to get DNS involved on the W95 machines, or WINS...?

WINS is what you need.  If you set up WINS, you will be able to do all you want to do.  I promise. :)

Alternately, you can use an LMHOSTS file on the 95 machines to tell them where to look for specific computernames.

For example, in the file \WINDOWS\LMHOSTS:

 102.54.94.97     rhino         #PRE #DOM:networking  #net group's DC
 102.54.94.102    "appname  \0x14"                    #special app server
 102.54.94.123    popular            #PRE             #source server

This is right out of the sample LMHOSTS file that ships with 95.

The first line says "there's a computer named 'rhino' at 102.54.94.97 and it's a domain controller for the NETWORKING domain.  i need to preload this name to ip address mapping when i boot up"

The second line is an example of something which is hardly ever used, I won't go into it.

The third line says "there's a computer  named 'popular' at 102.54.94.123.  i need to preload this name to ip address mapping when i boot"

LMHOSTS does the exact same thing that WINS does.  The only difference is that LMHOSTS files need to be kept updated for each machine, while WINS is dynamic.

With either method, you'll be able to "map" a drive to a UNC path which contains the computername in question (e.g. "net use q: \\popular\apps" where apps is a share that was made on the machine popular).

One thing you still may not be able to do is "browse" the network using Network Neighborhood from the remote side.  Browsing and drive mapping use two different facilities, and even though one works, the other may not.

In any case, you'll need to set up WINS (or LMHOSTS on all machines).  Please set up WINS (or LMHOSTS) and get back to us to see if you can do browsing from Network Neighborhood.

Thanks, McDonc - I'll be trying this on Tuesday 2nd Feb - I'll let you know the results

(Mainly at McDonc)
I've not had any joy at the remote site (there's a problem with the ISDN line) but I've got the router back here and I've got it attached to a PC which is emulating the remote site (different subnetwork).  When I set up the LMHOSTS file as you suggested and try a 'find' computer - the PC hangs (irretrievably).  If I take the entry out of LMHOSTS it doesn;t hang but (obviously) doesn't find anything.  I have WINS running on our server on our network (it works too - thanks!) but even if I set the 'remote' PC up to look at the IP address of the WINS server on our network it doesn't work.  I presume I'd need a WINS server on the REMOTE side of the network too?  I'm probably nearly there but...

Can you ping the WINS server from the "remote" computer?

Can you show me the LMHOSTS file on the remote computer?

When you try to ping the entries you've put into the LMHOSTS file from the remote computer by name (e.g. ping WINDOWSPC instead of ping 192.168.1.1), what happens?

If you're not using WINS, from this link http://www.microsoft.com/win32dev/netwrk/browse2.htm:

If some subnets in the domain do not include a Windows NT Server computer:
For each subnet that does not include a Windows NT Server computer, the following must be true:

        The remote subnet must include at least one computer configured to be the master browser. This can be a Windows 95 computer running File and Printer Sharing for Microsoft Networks with Browse Master enabled, or a computer running Windows NT Workstation configured with Maintain Server List enabled.
        The LMHOSTS files for browse masters on other subnets must include entries mapping the computer name and IP address for the remote browse masters that are Windows 95 or Windows NT Workstation computers.

If WINS is not working, this is what you have to make happen.

Read the link, it's way informative.

- Chris

McDonc - Chris, is it?

Success! I don't exactly know what I changed but when I went back to the lmhosts.sam and altered it to match IP addresses it suddenly started to work.... ish.  I went into 'Network Neighborhood' and clicked on the 'entire network' icon, expecting the familiar 'network not available' message.  To my immense surprise, all the machines on the local network showed up and I was easily able to browse around the network, just as if I was on the local lan (OK so it was a bit slower, but acceptable).  I then got cocky and went to the file sharing properties and saw that browse master was set to 'auto' so I changed it to enabled, rebooted the machine, (the ISDN line stayed up all the time) went back to network neighborhood and it said.... 'network not available'  I did a search for a machine name that was in the lmhosts file and it found it, then did a search for one that wasn't in the lmhosts file and it didn't find it.  I then went back to the network settings, changed browse master back to 'auto' and enabled WINS, putting in the IP address of the NT server at the other end of the router.  This time when I went back in to network neighborhood (after reboot) it said the same thing (network not available) BUT when I right-clicked on the 'entire network' icon, suddenly the entire list of machines was there again!  Now this is all well and good, but what the heck is occurring!! Presumably when I enabled WINS I bypassed LMHOSTS because I could find machine names on the network that weren't in the local lmhosts file?  Does WINS always take precedence over lmhosts?  One other note of concern... after I disconnected the ISDN line, I shut down the machine.  On the way 'out' of the system, the ISDN line reconnected for some reason - was the win '95 machine attempting to connect to the WINS server to say 'bye bye' or something?

If you repost one of your comments as an answer, the points are yours with great thanks.