Remote-access servers protect your net

Now that most offices have at least one road warrior, the trick is to make network
access efficient enough that users won't be tempted to construct their own back doors.

Connecting modems to computers inside the firewall invites disaster. Few users worry
about this kind of security breach, and the network administrator cannot see a hacker
entering from behind the firewall until it's too late.

A better approach is to install a remote- access server (RAS) that can handle
simultaneous calls and provide dial-up connections at 33.6- or 56-kilobit/sec rates.

It doesn't come cheap, however. You'll pay up to six figures for a configuration
similar to those the National Software Testing Laboratories tested. What you get for the
money is centrally controlled and configured dial-in networking with built-in redundancy.

NSTL tested seven RASes that could each support at least 200 concurrent users. The lab
looked for performance and management usability. Although interfaces differed greatly, all
the devices could handle the management tasks the lab threw at them.

RAS management tools have improved in the last year, but setup is no easier. Many WAN
interface parameters are buried within menu structures--for example, those that configure
the RAS to match the telephone carrier's switch parameters, in our case parameters for 11
T1 link.

All the servers tested had easy-to-understand graphical tools, and some had World Wide
Web interfaces for configuration and management. The lab didn't assume good looks
guaranteed usability. It consulted network managers to understand the real-world issues.

NSTL designed three test scenarios and rough guidelines for the testers to follow. The
ratings, though subjective, are based on firsthand experience. The three test scenarios
were remote management, troubleshooting and fault tolerance. For a server to receive an A,
it had to have the right tools to diagnose and fix problems quickly and easily.

Lower grades indicated that testers could spot and correct a problem but the effort was
time-consuming, identify the problem but not correct it, gather information about the
problem but not diagnose it with certainty, or couldn't find the problem.

In the first remote-management scenario, the tester reacted to a flurry of phone calls
from hypothetical users, suggesting the RAS was down. The tester then dialed into the
unit's management port, rebooted and verified a return to service. All RASes scored
perfectly on this test.

The servers fared nearly as well in the next remote-management test, which called for
the tester to add and delete user accounts remotely. Difficult to navigate were the
interfaces of the Max TNT from Ascend Communications Inc., the Total Control HiPer Access
System from 3Com Corp. and the AS5300 Universal Access Server from Cisco Systems Inc. The
others earned perfect scores.

Each module on the RAServer 2900 from RAScom Inc. used an onboard version of Microsoft
Windows NT for easy account maintenance.

In the third remote-management test, an attacker was suspected of using an authorized
user's account. The tester had to pinpoint the user, force disconnection and prohibit
reconnection. All the devices pinpointed the user. The Multi-Tech and Cisco devices each
lost a point for ease of use because they were less than intuitive in forcing a
disconnect.

The Ascend and 3Com RASes and Multi-Tech Systems Inc.'s CommPlete Communications Server
had trouble blocking a reconnect. The other servers earned perfect scores for this part of
the test.

The next scenario presented two troubleshooting tasks: identifying faulty modems and
removing them from service. The lab evaluated ease of completion for managers on-site with
the RAS and at remote locations.

Most products aced the on-site test, but RAScom's lost points for usability. Even
though it relied on Windows NT for many functions, we had to switch to a command-line
interface to manage some hardware parameters. We would have preferred handling everything
from the same interface.

When it came to tackling the same tasks remotely, all devices earned top ratings except
for the Bay Networks Inc. 5399 MSX Concentrator and RAScom units, which were more
difficult to use than the others.

The testers simulated the final scenario, a power brownout, by reducing power to each
RAS. Testers either cut power to one of several power supplies in the same chassis or to
one chassis among several configured as a single logical entity.

The lab also evaluated ease of restoring power and whether it affected active
connections. The scenarios assumed the hypothetical network manager was on-site, and the
lab evaluated what a manager at a remote site could do to diagnose and fix the problem.

All the products took a power hit with no effect on another chassis or on other modules
within the same chassis. The power cut affected incoming calls only for the Bay server. It
associated phone numbers with specific modules and did not reroute calls to numbers on a
failed module.

When it came to restoring power, all servers except Bay's and the Shiva Corp. LANRover
Access Switch earned perfect scores. Neither had a redundant power supply, but the Bay
chassis can support one.

Configurations with multiple chassis handled active connections flawlessly. Calls would
drop on the chassis with no power, but calls to other chassis weren't affected, and
incoming calls were rerouted to them.

The lab also evaluated remote management of power supply problems. All the devices
except RAScom's and Shiva's made short work of remotely enabling a second power supply.

Rather than use Windows NT for core hardware functions, the RAScom device had a
command-line interface. The Shiva box had just one power supply per chassis. In the tests,
the lab could remotely detect a loss in power but couldn't power-cycle the unit.

On the performance side, NSTL focused on scalability: Would caller 200 enjoy the same
throughput as the first caller?

To check this out, the lab built a complex test bed of 200 modems, a switch emulator
with 11 channelized T1 connections, a Fast Ethernet switch, a Web server with full-duplex
Fast Ethernet connection, and a custom-developed test application that generated Web
requests from up to 200 clients.

To make the calls, NSTL equipped four 200-MHz dual-Pentium Pro systems with 256M RAM
and serial port extenders to generate up to 60 calls each.

Ideally, the throughput would climb at a 45-degree angle as the lab added clients. Two
clients would mean exactly twice the throughput of one, four twice two and so on.

To some extent, scalability is a function of RAS design: Products built around a single
CPU don't scale well. A better approach is to put at least one CPU on board each modem
module so that processing power grows as modems are added.

Performance of most of the devices scaled in a fairly linear way from one to 50
clients. Aggregate throughput tailed off somewhat in moving from 50 to 100 dial-up
clients. But the single-chassis theory didn't hold in all cases. 3Com's Total Control hub,
which handles up to 450 calls in one chassis, had the highest aggregate throughput in the
100-client tests.

When we pushed the number of calls to 200, some products dropped out. Of those that
completed the test, none came close to our ideal of 200-client aggregate throughput,
exactly 200 times that of a single client.

3Com's Total Control HiPer Access System delivered higher aggregate throughput than any
other product. Ascend's Max TNT ranked next with respectable if not totally linear
scalability. Cisco's AS5300 trailed them.

Time constraints prevented the lab from running performance tests on RAScom's RAServer
2900 and Multi-Tech's CommPlete Communications Server. And hardware problems kept Bay's
5399 MSX Concentrator and Shiva's LANRover Access Switch from finishing the tests. Despite
repeated diagnostic attempts by those companies' engineers, lab testers cannot say for
sure why they didn't work.

Ascend's Max TNT supports up to 672 callers per chassis and loads a lot of access into
a small box. It was the easiest product to configure and monitor.

Bay's 5399 MXS Concentrator, like the Max TNT, handles up to 672 calls per chassis. Bay
was the only vendor that said it would support both x2 and K56flex modems. But the lab ran
into configuration difficulties with this device, including a change in routing tables.

Cisco's AS5300 has RAS-specific extensions for setting up user accounts and viewing
configuration parameters. The server had three chassis to handle 200 callers but took up
less space than some single-chassis products.

Multi-Tech's CommPlete Communication Server's distinctive management software, Multicom
Manager, handled virtually all configuration and monitoring through a Web interface.

RAScom's RAServer 2900 had a novel twist: It uses one or more NT servers running
Microsoft's Remote Access Service software. This makes it easy to define and manage user
accounts, because all reside within NT domains, and lets the RAS act as a Web or File
Transfer Protocol server. Hardware management through the separate command-line utility
was inconvenient.

Shiva, one of the oldest players in the RAS market, keeps coming up with new tricks for
its LANRover, including Web-style monitoring tools and virtual groups of phone numbers.

High port density and strong scalability are hallmarks of 3Com's Total Control HiPer
Access System. HiPer modules can handle up to 450 calls per chassis, and NSTL's tests
showed that the device scaled up linearly. The Total Control Manager software let the lab
detect hardware failures, run diagnostics and perform virtually all other management
functions.

Helen Holzbaur is a network project manager at National Software Testing Laboratories
Inc. of Conshohocken, Pa.