Q: How can I route Internet Protocol (IP) packets from my Local Area Network (LAN) to the Internet through an NT-based RAS client?
This is perhaps the most frequently asked question about RAS. When used with the TCP/IP protocol, you can configure RAS to allow your entire LAN to access the Internet via a single Windows NT-based machine with a dial-up RAS connection. If you can't afford to put in a leased line for Internet access, RAS may work for you, but there are certain requirements that must be met first.
Now, you are ready to configure the NT 3.5x-based RAS client to allow it to function as a router.
Caution: If you are part of the Internet, your shares may be visible to others. You can avoid this by stopping the server service on your LAN clients when you are connected to the Internet. If you run the FTP Server service on any of your LAN clients, you may also need to stop it to prevent other Internet clients from accessing that LAN client.
Q: After upgrading to NT 3.51, I can no longer send or receive TCP/IP packets via my RAS PPP connection. Why?
This problem occurs if you use the same IP address for your network interface card (NIC) that you use for your RAS PPP connection. Using the same IP address for more than one interface is an illegal configuration with TCP/IP. Under NT 3.5, you could use the same IP address for both and properly route packets via your RAS PPP connection due to a bug in RAS. This bug has been fixed in NT 3.51.
To get around this limitation, disable the binding of TCP/IP to your NIC or use a different IP address for the NIC than the one you use for your RAS PPP connection. In addition, make sure you select the "Use default gateway on remote network" check box in the TCP/IP settings of your RAS PhoneBook entry.
Q: How does NT determine whether to send IP packets via the NIC or RAS?
If you have enabled the "Use default gateway on remote network" check box in the TCP/IP settings of your RAS PhoneBook entry, any IP packets with a destination address on the same IP subnet as the NT machine's NIC will be sent via the NIC. If the destination IP address is on a different subnet, the packets will be sent via RAS and the default gateway assigned by the RAS server will locate the destination host. If you have not enabled the "Use default gateway on remote network" check box, packets for all subnets other than RAS will be sent via the NIC.
If you have more than one subnet on your local LAN, packets destined for other subnet addresses on your LAN will be sent to the default gateway. The default will be the remote network if you have the "Use default gateway on remote network" selection enabled. To correct this, you must add a static route to the routing table on your RAS server. For example, if your mail server is on the 199.199.40 network and your local LAN gateway address is 199.199.41.1, you can add a route to your routing table to ensure that all packets destined for this subnet are sent to the LAN gateway. For example: RouteADD199. 199.40.0 MASK 255.255.255.0 199.199.41.1 /P. With this addition to your routing table, all packets destined for the 199.199.40 network will be routed through your local gateway--199.199.41.1. The/P, a new switch in NT 3.51, at the end of the command makes the route persistent, meaning that the entry will be maintained even after you shut down the machine.
Windows NT 3.51 Service Pack 2 includes the Multi-Protocol Router (MPR) software. Using MPR allows you to automate this procedure. (For more information about routing TCP/IP packets on a multihomed RAS machine (i.e., one with more than one network interface, including RAS), see the Microsoft Windows NT 3.5 Resource Kit, Volume 2, Chapter 22 (see the book review "Windows NT Resource Kit" on page 59 of the October, 1995, issue).
Q: How can I automate the logon to a third-party PPP or SLIP server?
RAS includes a scripting language that you can use to automate the logon to a third-party PPP or SLIP server. Your automated logon script will consist of a series of commands--these are sent to the server--and responses--these are received from the server. Your script should be saved in the %system-root%\system32\ras\switch.inf file. Once you have entered your script in this file, you can select it in the RAS PhoneBook application. Choose the Security button, and then select your script in the After Dialing field. Be sure to modify this file with a text editor, as opposed to using Write or another application that might embed printing codes into the file.
For example, if you connect to a third-party PPP or SLIP server that issues the following prompts for information during the logon sequence:
Then you could add the following script to the SWITCH.INF file to automate the logon:
The SWITCH.INF file found in your %systemroot%\system32\ras directory includes some good examples of login scripts. Another good reference is the Microsoft Windows NT 3.5 Resource Kit, Volume 2, Chapter 9.
Q: When I attempt to connect to resources on the remote network from my RAS client machine, I receive an error message stating "Access Denied." Why?
When you connect to a remote network using RAS, the username and password that you enter in the RAS Authentication dialog aren't used by the remote network to grant you access permissions. They are only used by the RAS Server to determine whether you have dial-in permission.
Once you are connected to the remote network, the username and password that you originally used to log on to your machine are used to verify whether you can make a connection to a resource or share. This may change in the future; you may have the option to choose the credentials to use in future versions of RAS.
There are two ways to work around this limitation. One is to log off and then log on to the remote network after making your RAS connection (logging off and logging on will not hang up the RAS connection). A second workaround would be to create a local account that has the same username and password as the account you use for the RAS connection. Then use this account when you log on to your machine.
You could also create a batch file that connects you to the resources that you most commonly use. For example, one line in the batch file might read: Net use * \\srcsvr\spec/u:MyDomain\MyName. This command would connect to the share under the auspices of the MyDomain domain account, MyName. If the password was the same as your local logon password, you would connect to the resource you specified without a problem.
Q: I cannot browse servers on the remote network from my RAS client. Why?
To browse a remote network from File Manager, a RAS client must belong to a valid workgroup or domain on that network.
You can configure your RAS client to belong to such a workgroup by changing its workgroup name to one that exists on the remote network. To configure an NT-based RAS client belonging to a domain on that network, your machine must have a machine account on the remote domain. Ask your Network Administrator to create a machine account for your RAS client.
You can still connect to servers directly using File Manager even if your RAS computer is not a member of a valid workgroup or domain. For example, in the File Manager Connect Network Drive dialog, you can enter a server name and share name and connect to them, even though the server doesn't appear in the browse box. Enter the server and share names in the following format: \\ServerName\ShareName. You may also need to enter your username in domain\username format in the Connect As field.
Q: I can't use RAS on my Windows for Workgroups 3.11-based machine. Every time I attempt to dial a RAS Server, I receive Error 640. What's wrong?
The most common cause of Error 640 is that the amount of free conventional memory is too low on your Windows for Workgroups 3.11-based RAS client machine. To solve this problem, optimize your CONFIG.SYS and AUTOEXEC.BAT files to take advantage of Upper Memory Block (UMB) space by loading Terminate-and-Stay-Resident programs (TSRs) and device drivers into the Upper Memory Area (UMA--which is all the UMBs combined). Also, don't load device drivers and TSRs that you don't use. If you can't optimize your CONFIG.SYS and AUTOEXEC.BAT files any further, one or more of the following situations may exist:
Q: After using RAS to connect to a RAS server with the Internet Packet eXchange (IPX) protocol, I can no longer access local Novell NetWare servers; however, I can access remote NetWare servers. Why do I lose connectivity to my local NetWare servers?
All NetWare client redirectors, including Microsoft Client Services for NetWare (CSNW) redirector, query only one NetWare server's bindery for name-to-address translation. A remote NetWare server accessed with RAS doesn't have information in its bindery about the local NetWare LAN servers, and vice versa.
Like the NetWare redirector, the CSNW redirector cannot connect to disjointed NetWare networks simultaneously, because it relies on the information in a single NetWare server bindery. RAS on NT 3.5x tells the NT CSNW redirector to automatically switch to the remote NetWare LAN, and, in effect, drop the local NetWare connection if an IPX connection was successfully negotiated between the RAS client and server.
To work around this limitation, you can utilize Gateway Services for NetWare (GSNW) on the RAS server or another NT-based machine on the same network segment. Configure the RAS client to use only NetBEUI instead of IPX. The machine running GSNW will act as a gateway to the NetWare machine for non-IPX clients--in this case, your RAS client. By not using IPX for the RAS connection to the remote network, you keep local IPX connectivity.
Q: Can I use RAS software compression when dialing an NT 3.5x-based RAS server from a Windows for Workgroups 3.11-based client? An NT 3.1 client? A Windows 95 client?
Yes, yes, and yes! However, there's some tuning you may need to do. If your RAS server is running NT 3.5, you must install NT 3.5 Service Pack 2. If you are running NT 3.51 on your RAS server, no updates are required on the server side.
If the RAS client is a Windows for Workgroups 3.11 RAS client, you must use the RASMAC.386 file with a file size of 49,209 bytes. If your RASMAC.386 file has a file size of 27,193 bytes, replace it with the RASMAC.386 file found in the SUPPORT\RAS directory on the NT 3.5 Service Pack 2 CD.
When using an NT 3.1 RAS client, you must use the ASYNCMAC.SYS file with a file size of 53,188 or 53,716 bytes. If your ASYNCMAC.SYS file has a file size of 33,732 bytes, replace it with the ASYNCMAC.SYS file found in the support\ras directory on the NT 3.5 U.S. Service Pack 2 CD.
If you are using a Windows 95 Dial-Up Networking client, there's nothing you need to do to utilize compression. NT 3.5x RAS and Windows 95 Dial-Up Networking use the same software compression scheme.
Q: My modem is not listed on the NT Hardware Compatibility List (HCL); can I still use it with RAS?
Yes! However, Microsoft recommends using hardware found on the NT HCL, and while we will try everything we can to get your modem to work with RAS, we cannot guarantee it. If your modem emulates a supported modem, you can attempt to configure RAS to use that supported modem. Consult your modem documentation for any changes that must be made to achieve this emulation. RAS also includes support for a generic "Hayes Compatible 9600" modem, which may work. Some modem manufacturers have created scripts for their modems to use with RAS. Check on the availability of such a script.
You can also edit MODEM.INF and add a new section for your modem. Before you make any changes to MODEM.INF, however, make a backup of the file. Use one of the existing sections for a supported modem as a template for your new section. Modify the settings to reflect the appropriate commands for your modem. These commands can be found in the manual that came with your modem.
You can find additional information about using an unsupported modem with RAS by referring to the NT 3.5x RAS Help file (RASPHONE.HLP), and the Windows NT Remote Access Service Users Guide, Appendix E.
\[Editor's Note: For more information on any of these issues, see Microsoft TechNet, the WINNT forum on CompuServe, the Windows NT area at America Online, The Microsoft Network, and Microsoft's Internet servers--www.microsoft.com and ftp.microsoft.com. The Microsoft Knowledge Base can be found on the Web at http://www.microsoft.com/kb/indexes/winnt.htm.\]