Connecting With SO HO Remote-Access Servers

Terminal servers are very limited in functionality and likely will cause you more headaches in the long run because they require training users on a new application, typically with a command-line interface. Unless you have compelling reasons, stay away from proprietary serial protocols because you'll have to install and support their clients on every machine in your shop that dials in. In any event, if the chosen client is difficult to use or doesn't install cleanly, you'll spend an inordinate amount of time troubleshooting miscellaneous problems.

Some of the servers in the higher port-density range offer advanced features, such as Terminal Access Controller Access Con trol (TACACS) and Remote Authentication Dial In User Service (RADIUS) authentication, LAN-to-LAN bridging and ISDN. Although these features might be useful for SOHO remote access, they aren't necessary and you may end up paying for more server than you need. Unless you already have support for these high-end services, or if they're critical to your needs, their inclusion should be used only to decide between two similar vendors. If you do decide that you need these services, go with a vendor that has lots of experience in building large-scale remote-access servers and LAN-to-LAN bridges. Typically, you'll get a more stable product with a clear upgrade path through the product line.

Nearly all remote-access servers support the Point-to-Point Protocol (PPP) and Serial Line IP (SLIP). These are used to encapsulate other LAN protocols, such as IPX/SPX and TCP/IP, and effectively extend your network over an asynchronous link. For Microsoft Windows 3.x and DOS, look for vendors that provide dialers and enough l icenses to cover your user base so that you won't have to purchase third-party dialers for your users. If the server supports PPP and you have to pay for client licenses, you may be better off both in functionality and price in buying a PPP dialer from a third party.

Of course, to use IPX/SPX or TCP/IP with PPP/SLIP, you'll need to have the required stacks on the remote clients. You'll need to have both PPP/SLIP clients and the appropriate protocol stacks installed for Windows 3.x/DOS. Some vendors send limited stacks along with their servers. For IPX/SPX you normally get an Open Data-link Interface (ODI) stack, including a basic set of Virtual Loadable Modules (VLMs); it's up to you to provide the other common utilities, such as MAP.EXE and a LOGIN.EXE program on the clients.

Be sure to test any IPX/SPX installations prior to rolling out the clients to users because in many cases the client installation programs modify the existing NET.CFG, AUTOEXEC.BAT and CONFIG.SYS files. If users have an IPX or IP stack installed or a multiboot AUTOEXEC.BAT, you most likely will need to manually edit those files because the installation programs only know how to deal with a limited set of configurations. The best installation programs keep their configuration and program files in their own directory tree. For IP, you'll most likely see a WINSOCK.DLL and PING.EXE. You must also provide other TCP/IP clients. For Windows95 machines, the required stacks are built into the OS. With a simple installation from Windows95, you can connect via PPP as a remote node to most major network protocols. However, if you haven't made the move to Microsoft Windows95, look for clients that include both DOS and Windows 3.x clients, so your users can make remote connections from either environment.

Security and Use Issues If you're concerned about security, you have a range of choices in remote-access servers. Remote-access servers can be a weak point in any network because they typically bypass other security measures and p rovide a direct path onto your LAN. To safely install one of these devices, you need to understand and balance not only users' needs but also your security policy. SOHO remote-access servers provide a number of different security and access enforcement methods that may suit your needs. Typical mechanisms rely on user ID-password pairs, time-of-day restrictions and connection-duration restrictions. Although they don't all enforce security, they can serve to limit usage and set usage priorities.

Authentication at its simplest relies on the user ID-password pair. If you have NetWare servers on your LAN, for example, remote-access servers that will authenticate against the bindery, and Novell Directory Service using bindery emulation, will certainly make user administration easier than if you had to maintain two separate access lists. Other servers offer other authentication through options as such TACACS or RADIUS. If you have these installed or are planning on having one installed, server support should be part of your purchasing decision. If you are using a token-based security mechanism such as Security Dynamics' SecureID, for your remote users, make sure your remote-access solution supports it.

For added security, dial-back and roving dial-back are often available. You add a telephone number, or numbers for roving dial-back, into a user's record, and after he or she dials in and authenticates, the server disconnects the call and then dials the dial-back number. On reconnect, the user again authenticates and an online session is initiated. The dial-back mechanism helps to ensure that only authorized users are connecting to the LAN because all connections are initiated by the server. On an economic note, you may also reap the benefits of lower costs because, with the exception of the initial call, the entire session is billed back to your office using your long-distance carrier.

Restricting Protocols If you need to further restrict users to specific services on the network, many remote-acces s servers in the higher port-density range let you grant or deny access to specific LAN protocols. This is possible with PPP because user authentication occurs during the initial negotiation of the Link Control Protocol (LCP). Once the LCP is established, the network protocols are negotiated. If you deny access to certain protocols, you effectively reduce your exposure to entire ranges of services. This not only is beneficial for security reasons, but also may reduce user online time. For example, if your LAN is attached to the Internet and you have remote-access servers that run IP and IPX, by restricting users to only IPX on the remote-access server, you won't let them use your limited ports to surf the Internet.

Like any other network purchasing decision, you must factor in many different variables and understand the environment in which you will be placing new equipment. This is especially true when access to the device is largely a function of a user-to-port ratio. The margin for error between adequ ate port density and too few ports is extremely thin when dealing with less than eight ports. Likewise, you'll want to examine what your users will need from a remote-access device and then choose the one that offers the best mix of features. You don't want to compromise your established security mechanisms, but you don't want a gaping hole into your LAN either.

Mike Fratto is an independent network consultant in the central New York area. He can be reached at mafratto@syr.edu.