Introduction
A Guide to Managing
Remote Users
April 10, 2000
By John Shireley
The
task of granting remote users access to your central network and subsequently
managing those users can be quite daunting. It is especially difficult to
ensure that you’ve covered all the bases because each user's needs
vary in some way, and there isn't a common checklist that you can follow
for every situation.
This chapter will
help you address as many of these variables as possible. It will aid you
in formulating your own strategies in advance, and perhaps point out some
pitfalls and/or solutions that may be new to you. After you have read
this article, you may not have all the answers, but at least you’ll
know the questions to ask.
If you are looking
for a guide to help you decide which aspects of managing remote users
should be of importance to you, you’ve come to the right place. We’ll
cover as many scenarios as possible, restricting ourselves to general
concepts and methods rather than focusing on specific products or bit-level
explanations of protocols. But if you're just getting your feet wet with
supporting remote users, especially dial-up ones, we suggest reviewing
the following Network Computing Design Manual chapters:
The challenges of
remote support and implementation can be frustrating as you strive for
a reliable, secure and speedy connections for your off-site users. The
processes involved can be costly, time-consuming and morale-defeating,
and that's when it works right. At its worst, you’ll end up quitting
your profession in the IT arts, and becoming a simple woodsman.
Differentiating Between
Remote User Types: Individuals vs. Networks
For the most part, remote-support clients can be separated into two distinct
camps: remote users and remote networks. There are some overlapping areas
of concern, but each has distinct support needs. One obvious difference
is that a remote user is most likely going to be mobile, or need connections
that are not static or renewable (for instance, a dial-up user may be
connecting you via the Internet from an ISP that doesn’t provide
static IP addressing). A remote network or branch office, however, will
most likely use the same network mapping terms. However, there are some
notable exceptions, such as a remote office using an analog or digital
(ISDN) dial-on-demand router to connect to the enterprise.
Managing Individual
Remote Users
As with any new technology
or strategy deployed on your network, managing your remote users requires
several stages of preparation.
- 1. Identify the
goals of the project.
- 2. Assess the various
tools you have at your disposal (and research ones you don’t have).
- 3. Develop a solution.
- 4. Test it. I can't
stress this step enough.
Identifying your
users’ needs and goals is the most important part of your planning
regimen. These needs and goals must be clearly and concisely defined.
You must accurately identify the specifics of what they want to do now
and in the near future. Failure to do so may send you back to the drawing
board several weeks or months later. Not only will you have wasted your
time and resources, you will have created an antagonistic atmosphere towards
remote access.
Following are some
key details to work out that will help you to identify, develop and test
an applicable solution (or combination of solutions). They fall under
several categories, including transport issues (bandwidth, equipment and
so on), security, reliability and convenience.
Mobilizing the Troops
Transport issues are extremely important to network support representatives
as they manage remote users. How will remote users get to your network?
What equipment will they need? How reliable will it to be? Should they
use direct-dial or an alternative connection technique, such as TCP/IP
over a public network? These are all valid questions, but they are only
the tip of the iceberg. These days, when remote access is the topic of
conversation, people tend to think more in terms of using the Internet
as the primary medium, leaving direct dial as an alternative connectivity
method. We'll examine both methods, but with the exploding use of public
networks and their increased acceptance in the corporate world, you'll
find more solutions that bypass direct connections altogether.
Is the user going
to be on the move, or is he or she going to be stationary (a telecommuter
working from home)? The level of mobility will determine which security
and access methods will be appropriate. A lack of a static IP address
(having the same IP address assigned each time if the user dials into
an ISP), for example, will prevent you from taking some basic security
steps, such as placing an ACL (access-control list) on a router at the
central network. Being able to recognize your user by only his or her
login ID can restrict your overall security scheme. This will undoubtedly
force you to make exceptions to your security policies, unless you use
a VPN technology. We’ll elaborate on this in a later section.
To effectively manage
a mobile user plan for all possible contingencies. Security issues aside,
stability will be the hardest thing for you to provide or support. A truly
mobile user is one of the most difficult to support and manage, make no
mistake about it. "Mobile" equals analog connectivity subject to the whims
of whatever telco or facility sits between you and your users. You can
leave your fancy T1, DSL and fiber-delivered services behind you, because
it’s back to the 1960s in terms of reliable connectivity. Except
back then, they didn't design the analog infrastructure to accommodate
a 56-Kbps connection through a hotel's switchboard.
Provide your users
with as many alternate paths as you can into your network (without completely
sacrificing security, of course). Make those choices clear and easy to
understand. If the access isn’t simple and robust, your users will
not want to use it, making your job harder in the long run.
Additionally, you’re
not going to be able to hide all the sundry transport mechanisms, making
the connectivity experience less than elegant. Generally speaking, it
will be difficult to find a nonhostile environment for your users to dial
in from. Specifically, they're going to be facing unfamiliar variables
such as dial-tone access (for example will they have to dial a "9"
to get an outside line or need to enter in an access PIN specific to an
LD carrier?). They’ll have to cope with noisy switchboards causing
static on the line and, of course, the inherent background noise found
in most long-distance switched analog connections.
Don’t expect
anything less, or you’re going to get burned. Even if your users
are lucky enough to stay in hotels that have Ethernet connectivity, you’ll
still need to jump through with whatever hoops the hotel setup requires.
These hoops may include being a DHCP client or configuring for a proxy
gateway. This might not sound like a big deal to you, but remember, we’re
talking about your end users, not you. To them, it looks like more voodoo
than they’d care to deal with. This isn't their job, after all; it’s
yours! You will have users who would prefer to dial in using a modem rather
than change any configuration settings.
Plan for the Worst
Part of your planning process should include deflating any incorrect or preconceived
notions that your users may have. Despite the commercials with which the
general public has been inundated, simple, powerful remote access just isn't
reality. That's not to say that things aren't improving every day, but you've
got to rely on your ability to plan ahead and to position your users so
that they can optimize the meager tools you are able to provide.
For starters, make
sure that a user's notebook is equipped with an adapter that supports
both Ethernet (you could get lucky!) and a modem, and, as a last resort,
also supports a cellular phone interface. Make sure that the user doesn't
plan to download a 15-MB file 10 minutes before his or her presentation.
Emphasize that he or she should always test connectivity before it’s
actually needed. Any information that you or your user can obtain in advance
about the available facilities will help you plan your management and
support strategies. Additionally, request to speak with a manager or the
person in charge of the property’s telecommunications services. However,
it’s not unusual to find that these services have been outsourced.
Make sure that your users obtain all costs up front, including installation,
if they need something other than in-room analog services. Please note
that sometimes "available" doesn’t mean "in place,"
and that extra fees may apply.
Another good idea
is to have your users acquire a reliable, removable and portable mass
storage device for transporting large files. Sure, they’d prefer
having a huge hard drives on their notebooks, but those drives won’t
help them if the laptops are damaged in transit. Having something that
can be quickly reconnected to a desktop or other laptop will help prevent
a failed notebook disaster. Be sure it uses something universal between
notebooks and desktops, such as a parallel port or USB-enabled drive.
Should a user experience a failure, he or she can quickly move to something
else in an emergency. Additionally, encourage your roving users to take
as many files along with them as possible instead of downloading them
from your network. Make sure they know which types of files are and aren’t
portable. Many users mistakenly believe that their files can be accessed
only via some kind of network connection (even remotely via modem). They
don’t realize that a file can be made portable merely by loading
its parent application locally. This isn’t the most elegant approach,
but again, we’re talking about contingencies and disaster avoidance.
Pretty isn’t as important.
Finally, what do
you want to host at your site for them to connect to? If you're directly
connected to the Internet (dedicated 24x7), you'll have ample options
available. If not, you'll need to install a dedicated terminal server
(a requisite if you're going to have a lot of remote and mobile end users),
a modem in a server for direct RAS-style connections, or a modem on the
user's stationary PC for a "remote-control" style solution. We'll discuss
these options as we progress, but you should start thinking about them
now. A good source of useful information can be found at:
Application
Usage and Quality of Service
Is the user going
to need an application that resides on the central network, or will he
or she need occasional access to files, resources and e-mail? Your answers
will determine your bandwidth and latency issues and tell you if you’ll
require a more sophisticated client/server or thin-client application
approach, or something as simple as a PoP server account with limited
RAS authentication for occasional file down/uploads.
Any kind of interactive
application usage is not a good idea for your mobile users. It can be
done, but it’s difficult to do well. Some common examples of an interactive
application would include database access, and account entry (any type
of situation where a client is open and actively talking with a server).
This is an area where you must know and understand the specific dynamics
of the expected type of traffic. A well-designed, thin-client technology
really stands out here, but a user that expects to actively edit a large
spreadsheet across an anemic connection is going to be in for a rough
ride. You can find excellent information on this subject at:
Clearly, you can’t
plan on consistent QoS (Quality of Service) from a remote, analog, dial-up
user. So many elements are out of your control and you have very few options
available to remedy the problems this type of user is likely to encounter.
Not to mention your having to deal with a client that is only able to
squeeze out a few kilobits of connectivity when the application requires
a very low latency on the pipe or at least several kilobytes of room to
work in. In most cases you'll be dealing with finicky modems, hotel switchboards
and long-distance carriers. This applies to users that access your network
courtesy of the Internet, as well as your direct dialers.
The ideal method
of dealing with these particular issues is to select the best equipment
available that has been tested with your selected ISPs or your own direct
access gear. You can't control the hotel's switchboard or the LD circuits
between you and them, but you can pretest the equipment you're supplying
to your user, choosing the most compatible configuration. Don't always
choose the equipment that connects the fastest; pick the products that
establish the most reliable connections. Perform "endurance" tests, checking
how long a device can remain connected. Fast connection rates are no indicator
of overall performance. Simply achieving the highest data rate possible
isn’t the only element you need to consider; faster data rates over
analog circuits are more prone to encountering data errors, and may force
more retraining of the modem. A slower but more consistent connection
will provide better overall performance than one that is faster on connect,
but must continually retrain. Allowing for full autonegotiation is better
than trying to force a high data rate that causes the connection to constantly
hiccup midstream. You also can’t trust the initial connection speed
reported by your dial-up client; most only indicate the initial rate.
They don’t demonstrate the whole story as your modem retrains itself
into a downward spiral.
Your options significantly
improve, however, with a remote user dialing in from a fixed location,
such as a home office, especially if the user is local. If he or she is
dialing directly into your network, you have some control over the amount
of bandwidth he or she can receive. Since the user is located in one spot,
he or she can choose the connection type instead of accepting the standard
solution (like the mobile remote-access crowd must do). You can have ISDN
lines installed for your "bandwidth-hungry" group (provided
you’re able to support that interface with corresponding BRIs or
PRIs feeding your terminal serving equipment and that the service is available
in your area).
Many client/server
applications are designed to work with headroom of 64 Kbps to 128 Kbps,
with space to spare. If you’ve got the resources to consider thin-client
technology, such as Citrix’s Winframe or Microsoft’s Terminal
Server, and your applications fit into that model, this solution is a
good way to go. Thin clients operate with very little bandwidth and considerably
improve interactivity for remote users. They also provide virtually complete
control over your end user’s environment if you’re able to use
diskless workstations; you simply feed them their desktop, and they have
no way of permanently changing the configuration. An excellent review
of this technology can be found at:
If you prefer that
your users access your network via the Internet, do a little research
before selecting an appropriate ISP. Bigger is not always better in this
case. Ideally, your user should dial into the same ISP that your corporate
bandwidth originates from, thereby alleviating the amount of network (router)
hops that will occur to reach you. If you’re both using ISP X,
there should only be a few hops because the connection never actually
goes out onto the Internet: All the traffic is carried on the ISP's internal
backbone straight to you. An additional benefit of routing your remote
users to your network via the Internet is that your internal support will
be reduced. You’ll avoid the headaches and costs of having to support
your own private dial-in pool. With no additional lines and no additional
equipment, your existing equipment should be fine, provided that you have
good security.
A final word about
remote-control software–i.e., software that lets a user dial in (either
via a modem, or via IP) and control a selected host. This approach is
a terrific alternative to thin-client technology because it lets a remote
user completely control a local host machine and have all transactions
occur on the local machine. The software only needs to coordinate screen
updates across the connection, which can typically be done quite nicely,
even over the slowest of connections. Your user can work on bloated applications
from home or on a machine located at the office, and not use the bandwidth
that would have otherwise been required to transport the actual data back
and forth. Only screen updates are required to cross the connection. One
disadvantage is that this is resource-intensive in terms of distributing
workstations. If a user already has two computers, one mobile and one
on your network, then this is a great solution. If they don’t, then
you’ll need to dedicate one for that user. You can see how this would
quickly deplete your budget. Security isn’t as much a concern as
it used to be because most products allow for various forms of end-to-end
encryption. Therefore, don’t let that stop you from investigating
the feasibility of remote-control software.
Local
Calling Area or Long Distance
Costs can be decreased
and control over your users’ available bandwidth can be improved
if the individual user is in your local calling area. The elimination
of tariffed billing (such as long-distance charges) makes this scenario
much more attractive than requiring a user to dial into your network via
a long-distance carrier. This could produce a local dial-up pool for you
to manage (analog or digital). It could also increase security, since
your users won’t be routed to you over a public network (like the
Internet) or via long-distance circuits where you’re faced with line
stability issues as well as the added expense.
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:
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.
Helpdesk
Support
Supporting an individual
remote or mobile end user often requires more of your precious time than
supporting a regular LAN user. Remote users tend to have unusual and illogical
problems, and require serious amounts of planning and post-deployment
support, especially the highly mobile ones. Here are some suggestions
for planning your helpdesk approach. Coordinate after-hours’ operations
and broaden the areas of expertise for your staff. They should be trained
in troubleshooting the endless ambiguities of modem or telco switch problems.
Additionally, you will not always be able to use many of the traditional
tools, such as desktop management or control. Remember, if the users can't
get to you, you can't get to them!
If you’re in
an outsourcing relationship you can have them provide much of the actual
connectivity portion of support for your users. They’re not going
to be able to handle every piece of equipment or software configuration
that’s available. But by working with them in advance, you’ll
be able to determine what they can and cannot support efficiently. Standardizing
on equipment and applications will greatly improve how much you can demand
of your outsourcing partner.
Investigate third-party
helpdesk software if you're not already using it. Such applications can
be immensely useful and timesaving. This software also can help you track
individual problems as well as trends that might point to a more centralized
cause, such as an authentication server occasionally failing or a router
flapping. Once you've got a good knowledge base going, it will help you
and your staff remember obscure troubleshooting procedures. The good ones
are expensive, but if you're dealing with a large remote user base, the
cost is more than justified. Obviously installing an expensive helpdesk
application won’t be very cost-effective if you're only using it
to support your remote users. Consider your remote users’ support
needs versus your total support efforts before deployment. The larger
your IT support burden (and managing remote users will certainly increase
it!), the more a centralized trouble-ticket distribution and tracking
system will make sense for you.
Outsourcing
Finally, consider
outsourcing whatever you can unless you have a very large IT department
with plenty of technicians with an abundance of free time. The benefits
of outsourcing your remote user management and support can greatly outweigh
the costs in most cases. Outsourcing will save you both time and money
upon initial deployment, as well as in the future. Good outsourcing firms
will handle all necessary equipment upgrades, as well as maintain your
existing equipment. They contact circuit vendors and handle many of the
other headaches we've discussed here. This is their area of expertise.
Choosing the right
company to partner with can be very rewarding, but always remember that
you're outsourcing part of your access infrastructure, not your policies
on its usage. You determine those policies, so stick to your guns in terms
of developing a strategy with them, and be very proactive about your partnership.
Choosing an outsourcing partner can be a daunting task, but if you apply
the same principles you use when choosing your other vendors you usually
can’t go wrong. Check previous and existing client references. Find
out if they support other networks similar to yours in size and scope,
as well as the number of remote users you’re planning to support.
Investigate their helpdesks options and their flexibility for providing
custom support if you have unusual requirements. Terminating a relationship
with an outsourcing partner can be very painful so make sure it is the
right one for you.
Security
Concerns
We all know how important
security is to our networks, but when dealing with the management of remote
users, you especially need to plan ahead. Remember to balance the elements
of a secure networking environment against convenience to your user and
the cost to your organization. It is virtually impossible to have the
best of all three, so concentrate on your top two and do your best with
the third. The best security options available are not going to be convenient
to end users and are expensive in terms of support and resources. The
most convenient options for users are usually inexpensive, but do not
provide sufficient security. If you don't have your end users authenticate
with passwords when accessing your network, it will be very convenient
for them and inexpensive for you. If you have a complicated security policy
with varying levels of password requirements and exotic hardware, access
to your network is now more secure but also less convenient and certainly
more costly in terms of resources.
For your mobile or
dial-in users, the level of security and complexity is going to increase
exponentially with larger populations. If you're only supporting one mobile
user, you’ll be safe with one point of entry for your network (a
modem or ISDN TA hanging on a server, for instance). This sort of option
is usually available with your server's NOS install options at no additional
cost, whether it’s Novell, NT or Linux. Cost-effectiveness is one
of the most compelling reasons (performance impact issues aside) for instituting
a NOS-based remote-access solution, as it lets you maximize your existing
investments. But there are other good reasons as well, such as a shallower
learning curve than installing a dedicated terminal server or adding auxiliary
authentication devices, such as TACACS or RADIUS servers, into the mix.
An important component
of security is implementing good virus protection. An infected system
can spread chaos throughout your network, thus effectively performing
a successful denial-of-service attack on your network that can provide
additional opportunities to would-be attackers. Whether you deploy server
or client-level protection methods, make sure that your policies are adhered
to as closely as the rest of your security dictums and that your virus
protection is absolutely pervasive. One weak link in the chain is all
it takes to break it.
An additional, and
sometimes overlooked, component, is physical security of your roving users’
laptops. Many of your users simply aren’t aware that if their systems
are stolen or used by an unauthorized person, they are constituting a
major breach of your security. Cached passwords, crypto keys and other
security devices can fall into the wrong hands. Your users need to protect
their systems and treat them for what they are: potential access points
to your corporate network and sensitive files, literally the keys to the
kingdom. You should strongly consider and encourage local file and access
encryption, as well as implement desktop-level firewalling. Some excellent
personal firewall products have developed the past few years that offer
features for protecting your users against a security problem that they
may not have conceived– someone hacking into their notebooks or desktops
while they’re connected to the Internet.
Managing and supporting
remote users who are accessing your network via the Internet also presents
some unique challenges. These include obstacles not encountered
in direct-dial approaches, such as carrying your traffic over a public
network and securing both its transit as well as its sending and receiving
ends. There are several means of achieving a secure environment for them
(and you) that basically fall into two generic categories consisting of
hardware and software.
Hardware solutions
typically require a fixed location, and essentially consist of "black
box" technology that boils down to proprietary (or semiproprietary)
devices using encryption schemas for exchanging secure traffic between
two or more remote locations, usually using WAN links. They can also consist
of matching pairs of equipment that use more standard or well-known mechanisms
such as IPsec.
One of the primary
advantages of using a strictly hardware-based solution for a single at-home
user of a small remote office is that generally there are no configuration
changes or client software that needs to be loaded on each workstation,
assuming the workstation isn’t portable. More about this technique
for a remote network is covered in the section below, but supporting a
single remote user can be done with similar conditions. The hardware (in
most cases, a router) sits in between the remote host and your network
via connecting to the host on one interface (usually Ethernet), and to
the connectivity device (usually an analog or cable modem, ISDN TA or
other device) on the other side. The hardware solution performs all the
work, and essentially remains invisible to the client. However, any form
of encryption does add additional overhead to any connection. Once again
we have the convenience factor versus expense versus security equation.
Encryption generally can require you to either concede some speed, or
some bucks to buy a bigger pipe, unless your needed throughput is relatively
trivial. Larger broadband connection types (where throughput is faster)
are more effected because of the increased amount of traffic being processed.
Another benefit to hardware-based encryption/security devices as far as
TCP/IP connectivity is concerned, is that they are absolutely platform-independent,
and don’t care what kind of client you hang on them.
Make sure that any
hardware solutions you consider support central management. Some firewalls
do not allow access to them from their "external" (public) interface,
and once in place, can’t be managed from the outside. Several features
that may become important to you later on are support for SNMP (for inclusion
in network monitoring efforts), logging to a standard format such as syslog,
and multiple configuration interfaces for console-level access including
telnet. GUI management tools can be useful, but often the more "down
and dirty" text-based console/shell access gives you more granular
control.
Alternatively, you
can use software-based encryption and authentication solutions. These
are usually found in the form of a client application that must be installed
on the remote host, and either a hosting server application, or a hybrid
that has a client software component, and a dedicated hardware device
(usually a router or firewall). A good resource can be found at:
For example you could
configure something like an IPsec-compliant VPN client on a remote workstation,
and configure the complementing service on your access router at your
central network site. Bear in mind that you shouldn’t do this behind
a router or firewall unless it is using NAT, since the re-addressing confuses
the IPsec connection. Configuring the client is usually straightforward
once you’ve worked with the software vendor and ironed out all of
the wrinkles before deployment on a user’s system. Configuring, managing
and maintaining the client largely depends on how the vendor has written
the installation and loading portions. Make sure you thoroughly familiarize
yourself with the software so that you will be able to effectively troubleshoot
in the event of a problem. This secure tunnel allows traffic to cross
a public network, such as the Internet, in a protected manner. Unfortunately,
very few vendors provide client licensing for more than a few OS platforms.
Until standards like IPsec receive wider usage acceptance and improve
on some of the compatibility issues they’ve been struggling with,
you’ll want to test all the platforms’ clients you expect to
be using before choosing a vendor.
Managing
a Remote Site Network
In general, you'll
be connecting a remote network via a fixed digital circuit, and most likely
using routers between the two. With enough bandwidth management planning
and a proper router configuration, your remote users should operate as
though they were in the same building. Depending on the strictness of
your security policy and complexity of your network, you can leave things
well enough alone after you're set up. Usually you will only deal with
issues such as circuit outages or router firmware upgrades as necessary.
There’s another
thing to be aware of when trying to keep the infrastructure invisible
and seamless to your users. A workstation or other host on a remote network
really doesn’t know or care that it’s talking to another host
on another subnet in terms of infrastructure or individual host configuration.
Your connecting routers act as gateways and handle all of that. Security
is still a large concern of course, but as long as you apply the same
policies to your remote network that you do to your local one, and the
transport mechanisms between them, you’ll be fine.
If the remote network
isn’t attached to your central site directly via a point-to-point
circuit and you’re using the Internet to access each other, security
becomes a bigger concern. You need to consider firewall and VPN technologies.
Many dedicated firewalls now offer integrated VPN support. The easiest
way to address this issue would be to configure a pair of dedicated units
to talk to each other directly. This remains invisible to the desktop
clients on either side (or servers), and should ease most of your security
concerns. Since the secure traffic is tunneled from end-to-end by the
hardware, there is nothing further to configure at the desktop level which
greatly decreases your support and management burden.
Another alternative
to consider for connecting smaller client networks via the Internet if
you need to be more budget-conscious is to install them with a dial-on-demand
setup. This eliminates the cost of a dedicated circuit connection on their
side, which most ISPs charge higher fees for. Using ISDN access as an
example, you only need to purchase a single dial-up ISDN account (telco
fees remain the same, of course) from the service provider. Here’s
how it works: You install a router that supports a special feature that
allows it to dial in and share the connection with the rest of the network
by acting as the gateway. When no traffic is present for a predefined
time period, the unit closes the connection. When new traffic is sensed,
it calls the ISP back and re-establishes the connection.
There are several
caveats here, however. This particular setup will only work when you don’t
need to access their network for management purposes during off-hours;
if no one is there using it, it’s down and you can’t access
it (unless you set up "camping," but most ISPs frown on this
since it wastes their resources). Network-to-network security can be a
major hassle if you can’t get a static IP address for your far side.
Because the router is constantly redialing the connection, it’s usually
getting a different IP address assigned. You will not be able to add it
to any access-control lists on your side. In general, it’s an inexpensive
way to have a remote network reach you via the Internet, but there are
quite a few trade-offs for you to consider.
Bandwidth
Considerations
Bandwidth considerations
can be quite intimidating. One of your most difficult challenges will
be determining how much you’re going to need between locations, which
of course is determined by application type and usage patterns. This is
an area where you can’t allocate enough money. To be the most cost-effective,
you’ll need to utilize techniques that allow you to maximize your
available resources. Methods for calculating your bandwidth needs greatly
depend on your particular application.
When determining
the right formula, first address what is the specific type of data (large
files or small files) and the application delivery method (e-mail or database
access, for example), as well as your performance expectations. After
you’ve determined the amount of bandwidth overhead needed for each
application and how many users will require access, you can begin to formulate
what type of connection speed will be necessary by compounding these elements
using a simple linear equation. Bandwidth needed will be the variable
you’re solving for, and you should multiply users by applications
by data overhead (and latency requirements) of each application. There
are many resources already available to you, but make sure you’re
examining the right parameters to meet your unique needs. No one particular
bandwidth calculator will be the precise one, so try several to ensure
that you’re getting the whole picture.
Even after you've
deployed as much bandwidth as possible, you may still run into some latency
or other speed issues, especially as your users increase their traffic
on your circuit. If you suddenly find your T1 feeling more like a rusty,
old modem connection, explore the possible reasons why, and don't limit
yourself to known applications. In fact, the applications that you planned
for most likely are not causing the slow-down problems. Streaming video
from auction sites within the accounting department is more likely the
culprit. Perform a site visit and walk around to see what people are doing.
You'd be surprised at just how brazen some folks are with their Web browsers.
Develop fair usage
policies with management that are enforceable. Consider purchasing some
type of traffic-shaping or limiting device, such as a firewall that is
able to filter based on content. That will return your circuit back to
normal.
If you've eliminated
extraneous traffic as the culprit, it's time to use the packet sniffers
and traffic analyzers. These tools should be in your arsenal: They are
extremely helpful in determining exactly what is happening on your network.
If you find your circuit is getting clobbered by legitimate traffic, it's
time to think about load-balancing across multiple circuits, or upgrading
to a larger one.
Disaster
Recovery
Finally, you should
create a failover or disaster-recovery solution for your remote connection.
Since you’re connecting your remote network with your central one,
there are probably important business processes occurring every day that
can not tolerate a great deal of downtime. One very good method of providing
for recovery from a failed circuit is to have two in place instead of
one. One primary circuit, which is going to be your fattest pipe, and
one secondary circuit for emergency use. In addition to cost savings,
it’s better to use a separate type of circuit as an auxiliary one.
It is less likely to be affected by whatever brought the first circuit
down. Do make sure that your fail-over circuit(s) can meet the bare minimum
of your transfer and latency needs however; it's not going to do you any
good to bring a connection back up that no one can use.
As you can see managing
a remote and mobile workforce requires a great deal of forethought. It
is not enough to merely hang a remote-access server off your Windows NT
server. You must carefully examine your security needs, user requirements,
environmental constraints, network capabilities, and support capacity
long before you divvy out that first dial-up number. But through careful
planning, you can bring your distant workers back into the fold.
|
REPORTS
ANALYTICS
Follow 
