Local Calling Area or Long Distance

April 10, 2000
By John Shireley

Print this entire chapter Browse this chapter by content Managing Individual Remote Users Mobilizing the Troops Plan for the Worst Application Usage and Quality of Service Local Calling Area or Long Distance Establish How Much Bandwidth is Appropriate Choosing a RAS Thatęs Right for You Helpdesk Support Outsourcing Security Concerns Managing a Remote Site Network Bandwidth Considerations Disaster Recovery

Here’s a neat little trick to help you support your mobile users that not many people take advantage of. Have a toll-free number installed at your central location and have it "call forwarded" to just about any number in the world. This will help you get around the outrageous long-distance bills that hotels add onto your phone bill. Have your user's system configured to dial that "800" number, and then forwarded to your own dial-up pool or to your favorite ISP if you like to receive their traffic Internet-style.

Establish How Much Bandwidth is Appropriate

Will your user be spending most of his or her workday utilizing the connection? If so, a faster and more reliable connection will be required to prevent poor productivity. Generally speaking, a simple modem connection would be ineffective. Off-site users should receive the maximum available bandwidth if they're expected to do interactive work. They’re usually daytime workers and will be contending with the rest of your user base for access to your network's resources. The last thing they need to deal with is a retraining modem. Get them a minimum of a digital connection; the cost effectiveness of the expense of the circuit and equipment versus lost productivity can run into hundreds or thousands of dollars per month (see Figure 1).

Figure 1

A firm cost-savings comparison is difficult to present because there are very few fixed, recurring costs. However, there are certain gross generalizations that can be used, such as a worker's hourly cost to your employer versus their effectiveness of working off site over a slow link. If it takes twice as long to interact with a centralized application remotely versus at an office desk, it’s safe to assume that the employer is only receiving about half of what her or she paid for in terms of overall productivity.

If you're going to be supporting more than a few remote users for dial-in access, you'll need to start thinking about density and scalability. Incidentally, a good rule of thumb for determining the number of modem ports needed for an x population of callers is to estimate 10 users to one port, but you should decrease that ratio for a calling population that requires a longer connection time. An excellent resource for scaling issues can be found at:

• Building Scalable Remote Access by Mike Fratto
  http://www.networkcomputing.com/netdesign/sraa.html

Choosing a RAS That’s Right for You

Choosing an appropriate RAS solution doesn’t have to be complicated. Basically, your choices will boil down to an integrated server NOS element (such as authenticating to the built-in RAS services on Microsoft Windows NT or Novell NetWare), a dedicated external resource (such as a terminal server with integrated authentication functions), or possibly a separate authentication database management application. This will provide a more diverse approach that includes separate terminal servers, authentication servers and resource servers.

For fewer than 32 users on a fairly powerful access server, you can use a multiport serial interface board and hang your modems or TAs off of that server, controlling them via the NOS’ version of RAS for direct connectivity. For more than 32 users, plan to use dedicated terminal servers as well as dedicated authentication database management applications for easier policy management and user access privileges. Some of the well-known solutions are RADIUS and TACACS. They act as stand-alone authentication services running encrypted database traffic to/from your terminal server. They grant or deny access levels as a result of a variety of predetermined factors based on your overall security needs. They also can control client configuration parameters and many other variables that further lessen the management burden. Each product has supports different features, so you’ll need to do some comparison shopping. Most will run on a variety of platforms, so regardless of your server farm's makeup, you should have little trouble finding the right one for you.

Choosing which NOS-based solution is right for you depends on several factors. If you’re a single platform shop and wish to remain with that platform by utilizing an existing production server, that’s OK, but not the best solution, especially if it’s your only one. All the major NOSes have fairly stable integrated RAS schemes for you to utilize, including both direct-dial or virtual interfaces. It’s best to keep any RAS server activities off of your production servers so as to minimize load and maximize your diversity and security. Direct server RAS support can be as simple as adding a single modem, or as complicated as adding multiport serial boards with multiple external modems or ISDN TAs. In general, it’s better to go with "smart" multiport boards because they contain their CPUs and don’t put as much of a load on the RAS server.

Security methods can become more extensive at your discretion, including using techniques, such as "dial back," that require your end user's point of origin to be known to you in the form of the dial-back phone number. Your server hangs up, and calls the correspondent back at the predetermined number and continues the authentication scheme from there. That helps to protect against intruders "war dialing" your company's known phone number pool, looking for an open modem with which to tamper.

Other considerations include the use of a third-party RADIUS system. There are many available for a wide variety of platforms, and their use and deployment can greatly enhance your authentication, authorization and accounting efforts. Most of them can easily be integrated with your existing network without requiring any changes to your in-place user security management efforts. No re-entry of user names or passwords is necessary in many cases, since they can use just about any of your existing systems, such as NT Domains or NDS services. Many also support the use of "proxy" RADIUS, whereby one RADIUS server talks to another one across the network or across the Internet. These can be especially useful given their ability to be deployed in conjunction with an ISP or other outsourcing partner. They can manage your remote access without having to actually manage your individual user accounts.

A note about the placement of an authentication server (such as RADIUS) in relation to your firewall: it is better that you keep the RADIUS box and its related terminal servers and databases inside your protected network for users dialing in who only need access to internal resources. If you’re also allowing access to the Internet from inside your network after dialing in, it’s better to place the whole shebang outside your protected network, or on an optional interface on your firewall or router (see Figure 2).

Figure 2

Additionally, usage is split equally between inside resource access and external Internet access, or you have many specific insecure services running, you’ll want to keep those resources outside of your internal network on an optional interface (an additional network segment, sometimes referred to as a DMZ) as well. It’s usually better to put your RADIUS or other authentication server inside your network so that you have some amount of control over access to it.