Using RAS for Host Access

Using Remote Access Service (RAS), you can easily set up a Windows NT Server 4.0 system to act as a gateway between remote systems and your LAN-based hosts (e.g., UNIX systems, IBM mainframes, IBM AS/400s, Digital Equipment VAXs). In this environment, remote systems can dial in to the RAS server and then directly access a host using TCP/IP-based services such as Telnet or FTP. Similarly, if you have a conventional SNA environment attached to your LAN, you can also use RAS to accommodate access to IBM mainframes and AS/400s via SNA Server.

You can use a wide variety of remote systems to access a host via a RAS server, but I'll focus on these three remote system configurations: a Macintosh system using TCP/IP to access a UNIX host, a Windows 3.x system using TCP/IP to access a UNIX host, and a Windows 3.x system using SNA Server to access an IBM host. (The absence of DOS, NT Workstation, and UNIX configurations from this list does not mean that you cannot use them as remote systems--I've excluded them for the sake of my sanity.) I'll also touch briefly on using SNA Server to access an IBM host from Windows 95 and NT Workstation systems.

TCP/IP for Host Access
Before jumping into the remote system configurations for direct TCP/IP access to a host, let's pause and look at three big-picture considerations that relate to the way TCP/IP operates. First, do you have (or need) a TCP/IP router (called a gateway) in your LAN? Second, do you have a name server in your LAN, and if so, is it configured to support your host? Third, how should you assign the IP address to the remote system? Let's examine each of these considerations.

A TCP/IP gateway provides a path that lets your TCP/IP traffic travel from one logical network (IP subnet) to another. If all your local and remote systems use IP addresses that reside in the same subnet, you don't need a gateway. If your remote systems use IP addresses that reside in a separate subnet, you must have a gateway in place to move traffic between the subnets. The most common application for a TCP/IP gateway is to provide a link to the Internet (which, of course, is a huge collection of TCP/IP subnets).

The second consideration--name serving--affects your ability to reference hosts by name. For example, if you want to launch a Telnet session to a UNIX host named AIXLAB, you would probably like to say

TELNET AIXLAB
A name server provides a central service to convert IP names into IP addresses. If you have a name server, make sure you configure the name of your UNIX host in it. If you don't have a name server, don't feel obligated to implement one: You have two alternatives.

First, you can define host-to-address mapping files in each remote system in a hosts file. Most TCP/IP implementations support the ability to resolve names from such a file. Second, you can avoid using names entirely and use only the IP address to initiate connections. For example, if the IP address for AIXLAB is 216.56.55.63, you can use the command

TELNET 216.56.55.63
The final consideration is how to set the IP address on the remote system. You have two options: You (or the user) can manually configure the IP address on the remote system, or you can have the IP address download from the RAS server dynamically.

Given a choice, opt for letting the server determine the address. This approach provides centralized control and eliminates the possibility of a typo in an IP address. Unfortunately, you will find that many Point-to-Point Protocol (PPP) implementations do not support dynamic address assignment, or even worse, their implementations of dynamic address assignment are incompatible with Microsoft's implementation (hey, it happens). In these cases, you must manually assign IP addresses in your remote systems.

Time to PPP
With a backdrop now in place, let's talk about two specific configurations for direct TCP/IP access to a host system in your LAN: access from a Macintosh and access from a Windows 3.x system. Strangely enough, the Macintosh connection is the easier connection to set up--the Macintosh operating system better integrates TCP/IP than does the Windows 3.x environment.

To enable Mac-to-AS/400 access over TCP/IP, you need the MacTCP control panel installed on your Mac, and you need add-on support for PPP. In my testing (and in real life), I use the ConfigPPP program; however, you can find many other free PPP implementations on the Web. ConfigPPP installs as both a system extension and a control panel. You must configure both the MacTCP and the ConfigPPP modules (via their control panel interfaces).

First, access the MacTCP control panel and select the PPP interface in the opening dialog box. Press More to access the detailed configuration options, as shown in Screen 1. Perform the following actions in this dialog box:

1. In the Obtain Address field, select Server to have the address downloaded from the RAS server, or select Manually to set up a static address. Screen 1 shows the configuration to obtain an address from the server.
2. In the Routing Information area, set the Gateway Address to the address of your IP router, or to 0.0.0.0 if a router is not present. (The example in Screen 1 does not define a gateway.) If you choose to server-assign the IP address, the RAS server can also download the IP address of the default gateway.
3. If you chose Server in step 1, skip to step 4. If you chose Manually, configure the IP address in the IP Address configuration area. You must first choose the class of address (A, B, or C) and then set the address value. The format of this entry field is rather strange, so be prepared to spend some time to figure it out.
4. If you are using a name server, specify the name of the domain it services and its IP address. For example, Screen 1 shows that the system at 204.56.55.1 handles names for the duke.com domain.

Press OK when you complete the configuration. You must restart your Mac to put these settings into effect.

Next, move to the ConfigPPP process. In the ConfigPPP control panel dialog box, shown in Screen 2, make the following settings on the opening panel:

1. Set the Port Name to the location of your modem attachment. Usually, this setting is Modem Port.
2. Set the desired Idle Timeout. A value of None means that the PPP connection will not time out and disconnect when no traffic is present. (I find no time out desirable.)
3. Set the Echo Interval to Off.
4. In the check-box section, select only Hangup on Close.

The previous ConfigPPP steps set only basic system-level information. You must now define the particulars of your RAS connection. Click New and specify a name for this connection--a logical name that does not have to match the computer name of the RAS server. After specifying a name, you return to the initial ConfigPPP display. Then, click Config to set the configuration details as follows:

1. Set the Port Speed to the speed at which you want your Mac to talk to your modem. This setting needs to be at least as fast as your modem speed.
   2. Set Flow Control as appropriate for your modem connection. I usually ignore this field and specify None.
   3. Enable Tone Dialing or Pulse Dialing as appropriate for your phone system.
   4. Specify the phone number for your RAS server in the Phone Num field.
   5. Specify any modem initialization strings you want performed before dialing commences. I usually set this to ATZ, which clears all temporary settings in the modem.
   6. Set the Modem Connect Timeout to a value long enough to let the Mac and the RAS server handle option negotiation and logon. I usually go with 90 seconds.
   7. Finally, press Authentication, and then specify a username and password in the appropriate fields. This username and password must match a username and password defined in the RAS server--you cannot use this method to log on to an NT domain.

   Now that you have properly configured MacTCP and ConfigPPP, you can click Open in the ConfigPPP control panel dialog box to initiate a connection. The ConfigPPP module then instructs your modem to dial out and negotiate a connection with the NT RAS server. When the connection is established, the status of the link (shown in the upper left corner of the ConfigPPP panel) changes from PPP Down to PPP Up. And that's it.

   Once the call is established, you can connect to your LAN-based host via Telnet, FTP, or even a Web browser (assuming your host is running Web serving software). The Mac doesn't come with any of these handy programs, so you will have to purchase commercial programs or obtain shareware programs. If you elect to purchase programs, you might as well purchase a full-blown Telnet emulator to give you a complete range of capabilities.

   PPP from Window
   For Windows 3.x to host access over TCP/IP, you need add-on software--Windows and Windows for Workgroups (WFW) do not support PPP connections natively. You can use commercial products such as NetManage's Chameleon, or shareware packages such as Trumpet WinSock. Most TCP/IP vendors that market Windows 3.x products offer a product for PPP connectivity.

   In theory, the steps for configuring a Windows PPP connection are similar to the steps for establishing a Mac PPP connection. You define how you want the IP address set; configure a gateway, if present; configure a DNS server, if present; and define the characteristics of the RAS connection (e.g., phone number, speed, and user and password information).

   For my testing, I used NetManage's Chameleon 4.6. I chose that package because I always used Chameleon for PPP Internet connections during those dark days when I used 16-bit operating systems daily.

   At first glance, the fit between Chameleon and RAS seemed perfect--Chameleon supports dynamic IP address assignment via DHCP or BOOTP, and it has a variety of connect-time logon options. However, none of these options did me any good. I was unable to establish a connection using DHCP or BOOTP (I had to manually assign an IP address), and I could not find any logon script that worked with NT RAS. That doesn't mean I was unable to connect, but I had to be creative and come up with some interesting workarounds, as you will see shortly.

   When you use Chameleon, you set up configuration options in the product's Custom program. You use the same program to initiate dialing.

   To set up the initial configuration, you must add an interface defined as a PPP connection. This process is simple: Just use the Add option on the Interface drop-down menu. After you create an interface, you can configure it via the Configuration option on the Setup drop-down menu. In the Configuration dialog box, shown in Screen 3, you configure the RAS connection on the following tabbed pages:

   • IP Configuration, where you set the IP address of the remote system
   • Name Resolution, where you configure your name server (if present)
   • Gateway, where you define your gateway
   • Port, Dial, and Modem, where you configure items such as modem attachment, modem speed, and the phone number of your RAS server
   • Login, where you set your login authentication information

   For the sake of this discussion, I'm going to focus on the IP Configuration and Login tabs--the other tabs are self-explanatory. As I mentioned earlier, I was unable to establish a RAS connection from Chameleon using dynamic address assignment. That problem led me to manually configure the IP address, as shown in Screen 3. This IP address resides in the same subnet as my host system, so I didn't need a gateway (although I did have one present). After I set a manual address, I was able to establish a connection into the RAS server--but I wasn't able to log on. That situation led me to the Login tab.

   On the Login tab, shown in Screen 4, I specified a User Name and User Password that correspond to a username and password defined on the RAS server (again, you can't use domain names in most PPP implementations). NT RAS does not provide prompts for logon scripts, so I disabled the script I had defined and figured that Chameleon would automatically log me on just like the Mac does. As things turn out, this assumption was sort of right and sort of wrong.

   Having configured my access name and password and having designated that I did not want scripting support, I fired up the connection again. To my surprise, Chameleon displayed a Terminal window when it initiated the connection. It seems Chameleon wanted me to log on manually because I had not defined a script for it to use to log me on automatically. This arrangement is fine, except that RAS does not provide any logon prompts.

   Here's where things got interesting. I let Chameleon establish a connection to the RAS server. I waited until the modem activity died down (just a few seconds), and then I pressed Done to signal that I had completed the logon process. Well much to my surprise, Chameleon finished the logon process, and I was connected to the RAS server. Somewhere along the way, Chameleon automatically logged me on, even though it presented a Terminal window. (For the record, I searched NetManage's Web site for an INI setting or some fix for this behavior, but I came up empty.)

   After I closed the Terminal window, I was in. I then established a link to my local UNIX host using Chameleon's Telnet program and transferred files using the Chameleon FTP program. Again, you can use other products than Chameleon to get a PPP connection--I'm just a creature of habit. If you don't have Windows-based PPP software, I encourage you to explore all your options. Make sure you inquire about support for NT RAS connections.

   RAS and SNA Server
   If you look in the Network program group in a WFW system, you'll find an inconspicuous entry called Remote Access. This program lets you dial up a RAS server and connect into a Microsoft network (e.g., a LAN Manager network; a WFW network; a Win95 network; or in our case, an NT network).

   Once connected, you can access shared files and printers as though you were attached to the LAN. Because an SNA Server system is, in many ways, just another NT server in a Microsoft network, the Remote Access program provides a convenient and relatively easy way to connect to an SNA Server system so that you can, in turn, connect to an IBM system.

   This article assumes you have mastered the SNA Server installation and configuration process. (If you haven't, consult Michael Otey, "SNA Server 3.0 for Interoperability with the AS/400," March 1997.) Also, I strongly recommend that you install and run the SNA client software on a system in your LAN before you try to install and run it on a remote system. After you conquer the client installation process on a LAN-based system, you can graduate to a remote system.

   WFW does not install the Remote Access program by default; therefore, the first time you access the program, WFW will ask you whether you want to install the program. Naturally, you say yes and then provide the disk or CD-ROM when you see the installation prompt. During the installation process, you define your modem and serial port (COM:) settings. All things considered, the installation is less than demanding. After you complete the installation steps, you must restart your system to wrap up this phase of the configuration process.

   By default, Remote Access uses the NetBEUI protocol to communicate with the remote network. You can change the protocol Remote Access uses or add support for IPX or TCP/IP via the Network Settings program. I must warn you that WFW doesn't excel at these other protocols, and if you want to use TCP/IP, you must have installed the WFW's optional TCP/IP subsystem. For the sake of this article, let's stick with the NetBEUI protocol. You need to enable support for NetBEUI in the RAS server and the SNA Server system.

   Before you can use Remote Access for SNA connections, you must install the client software that comes with SNA Server. The SNA Server CD-ROM includes client software for DOS, Windows, Win95, NT, and OS/2. To install the WFW software, simply run the SETUP program contained in the appropriate client directory (\CLIENTS\WIN3X, in this case).

   You have only two important choices to make during the installation process. First, what protocol do you want to use? Select Microsoft Networking (Named Pipes) to specify that you want NetBEUI support. Second, you must specify how you want the client to find the server. You can specify Local, in which case, the client will search for the SNA Server system in the domain, or you can specify Remote and cough up the name of the SNA Server system. I usually opt for the Remote method and explicitly provide the name of the SNA Server system (i.e., the computer name of the hosting NT system).

   After answering the configuration questions, the SETUP program will create a program group called Microsoft SNA Server Client with three applications in it: SNA Setup, which is the SETUP program you just used to install the software; Client Config, a program that lets you change the protocol selection and SNA Server detection method; and a stripped down 3270 or 5250 emulator. You must restart your WFW system to complete the installation process. (Check Microsoft's Web site to make sure you have all the latest Service Packs for SNA Server. The Service Packs cover the server-side and client-side software, and you need to install both. During my testing, I was unable to successfully make a connection using SNA Server 3.0 until I downloaded Service Pack 1 and installed both the server- and client-side updates.)

   OK, so now you're ready to dial, right? Right! Start the Remote Access program, and it will prompt you to create a phone book entry. This part is easy--just enter a name for the entry (any name will do), the phone number of your RAS server, and an optional description. Press OK to return to the main Remote Access screen, shown in Screen 5. Make sure the phone book entry is highlighted in the window, and press Dial.

   When you press dial, Remote Access doesn't dial (that would be way too obvious). Instead, it presents an Authentication dialog box that requests your username, password, and optional domain for the network you are dialing into. Support for domain-based authentication is one of the key benefits of RAS over PPP. With PPP, you're locked into user definitions stored on the RAS server; here, you can use any domain user authorized for remote access.

   After you specify a user, password, and optional domain, press OK; the Remote Access program will initiate communications with your modem and instruct it to dial out. When the RAS server answers, the Remote Access program will present your user, password, and domain credentials to the server; if the server accepts them, you will be logged on to the network.

   Once you're in, you can access the SNA Server system. But before you do that, test the connection. An easy way to test the connection is to bring up File Manager and select Connect to Network Drive. If nothing shows up in the list of available systems, you have trouble--most likely, mismatched protocols (e.g., your client is using NetBEUI, but everything in your LAN is using TCP/IP).

   If you see a list of servers, make sure the SNA Server system is on that list. If it's not, you either have a protocol mismatch or a user authorization problem. Look at the SNA Server system's configuration to diagnose a protocol mismatch problem, and try to access the system using the same user, password, and domain information from a LAN-based system to diagnose a user authorization problem. For the sake of argument, let's assume a list appears and your SNA Server system is on it.

   Under WFW, the SNA Server client software doesn't initiate a connection until a client program requests it. Therefore, to test the link, you can run on the terminal emulation applet. You need to configure the host connection via the Session Configuration entry on the Session drop-down menu. When you select this entry, the SNA client software attempts to establish the link to the SNA Server software so that it can obtain configuration information.

   You configure mainframe and AS/400 links differently; however, both cases are fairly straightforward--especially if you read the SNA Server documentation first. Once you complete the configuration information, press OK to receive (after a brief delay) an IBM sign-on menu. Getting this menu means you have successfully completed the RAS and SNA client installation process. You can now install additional third-party client-side emulation/access software (e.g., Attachmate, Wall Data, or WRQ terminal/printer emulation software)--as long as it supports SNA Server, of course.

   Windows 95 and NT Clients
   The installation process for Remote Access software under Win95 and NT Workstation 4.0 is much simpler than the Macintosh, Windows, or WFW procedures. Simply start the Dial-Up Networking utility in My Computer, and the configuration wizard guides you through the entire process. The installation of the SNA Server client software is equally simple. Microsoft learned lots of lessons from WFW, as clearly evidenced by the superior networking and dial-up capabilities you find in Win95 and NT.

   Keep On RASing
   RAS provides a fairly painless method for facilitating remote access to LAN-based hosts. You can use the ubiquitous PPP protocol to run an end-to-end TCP/IP connection from almost any kind of system, or you can implement SNA Server to accommodate SNA links between remote clients and your IBM systems. Even better, you can offer both kinds of connections through the same RAS server.

   But that's not all RAS can do. You can (and probably already do) use RAS to access NT file and print servers. You can also use RAS to provide access to a centralized Internet connection, to Novell NetWare servers, and more. RAS is one of those technologies that grows on you--implement it for one application today, and who knows what you'll be using it for tomorrow.