allanswers.org - Firewalls FAQ

 Home >  LAN >

Firewalls FAQ

Section 1 of 4 - Prev - Next
All sections - 1 - 2 - 3 - 4


URL: http://www.interhack.net/pubs/fwfaq/
Version: 10.0
Archive-name: firewalls-faq
Posting-Frequency: monthly 

                             Internet Firewalls:
                         Frequently Asked Questions

                        Matt Curtin       Marcus J. Ranum

                   cmcurtin@interhack.net   mjr@nfr.com

                         Date: 2000/12/01 19:48:21
                               Revision: 10.0

Contents

   * Contents
   * 1 Administrativia
        o 1.1 About the FAQ
        o 1.2 For Whom Is the FAQ Written?
        o 1.3 Before Sending Mail
        o 1.4 Where Can I find the Current Version of the FAQ?
        o 1.5 Where Can I Find Non-English Versions of the FAQ?
        o 1.6 Contributors
        o 1.7 Copyright and Usage
   * 2 Background and Firewall Basics
        o 2.1 What is a network firewall?
        o 2.2 Why would I want a firewall?
        o 2.3 What can a firewall protect against?
        o 2.4 What can't a firewall protect against?
        o 2.5 What about viruses?
        o 2.6 Will IPSEC make firewalls obsolete?
        o 2.7 What are good sources of print information on firewalls?
        o 2.8 Where can I get more information on firewalls on the Internet?
   * 3 Design and Implementation Issues
        o 3.1 What are some of the basic design decisions in a firewall?
        o 3.2 What are the basic types of firewalls?
             + 3.2.1 Network layer firewalls
             + 3.2.2 Application layer firewalls
        o 3.3 What are proxy servers and how do they work?
        o 3.4 What are some cheap packet screening tools?
        o 3.5 What are some reasonable filtering rules for a kernel-based
          packet screen?
             + 3.5.1 Implementation
             + 3.5.2 Explanation
        o 3.6 What are some reasonable filtering rules for a Cisco?
             + 3.6.1 Implementation
             + 3.6.2 Explanations
             + 3.6.3 Shortcomings
        o 3.7 What are the critical resources in a firewall?
        o 3.8 What is a DMZ, and why do I want one?
        o 3.9 How might I increase the security and scalability of my DMZ?
        o 3.10 What is a `single point of failure', and how do I avoid
          having one?
        o 3.11 How can I block all of the bad stuff?
        o 3.12 How can I restrict web access so users can't view sites
          unrelated to work?
   * 4 Various Attacks
        o 4.1 What is source routed traffic and why is it a threat?
        o 4.2 What are ICMP redirects and redirect bombs?
        o 4.3 What about denial of service?
        o 4.4 What are some common attacks, and how can I protect my system
          against them?
             + 4.4.1 SMTP Server Hijacking (Unauthorized Relaying)
             + 4.4.2 Exploiting Bugs in Applications
             + 4.4.3 Bugs in Operating Systems
   * 5 How Do I...
        o 5.1 Do I really want to allow everything that my users ask for?
        o 5.2 How do I make Web/HTTP work through my firewall?
        o 5.3 How do I make SSL work through the firewall?
        o 5.4 How do I make DNS work with a firewall?
        o 5.5 How do I make FTP work through my firewall?
        o 5.6 How do I make Telnet work through my firewall?
        o 5.7 How do I make Finger and whois work through my firewall?
        o 5.8 How do I make gopher, archie, and other services work through
          my firewall?
        o 5.9 What are the issues about X11 through a firewall?
        o 5.10 How do I make RealAudio work through my firewall?
        o 5.11 How do I make my web server act as a front-end for a database
          that lives on my private network?
        o 5.12 But my database has an integrated web server, and I want to
          use that. Can't I just poke a hole in the firewall and tunnel that
          port?
        o 5.13 How Do I Make IP Multicast Work With My Firewall?
   * A Some Commercial Products and Vendors
   * B Glossary of Firewall-Related Terms
   * C TCP and UDP Ports
        o C.1 What is a port?
        o C.2 How do I know which application uses what port?
        o C.3 What are LISTENING ports?
        o C.4 How do I determine what service the port is for?
        o C.5 What ports are safe to pass through a firewall?
        o C.6 The behavior of FTP
        o C.7 What software uses what FTP mode?
        o C.8 Is my firewall trying to connect outside?
        o C.9 The anatomy of a TCP connection
   * References

1 Administrativia



1.1 About the FAQ



The Firewalls FAQ is currently undergoing revision. The maintainers welcome
input and comments on the contents of this FAQ. Comments related to the FAQ
should be addressed to firewalls-faq@interhack.net. Before you send us mail,
please be sure to see sections 1.2 and 1.3 to make sure this is the right
document for you to be reading.

1.2 For Whom Is the FAQ Written?

  Firewalls have come a long way from the days when this FAQ started.
They've gone from being highly customized systems administered by their
implementors to a mainstream commodity. Firewalls are no longer solely in
the hands of those who design and implement security systems; even
security-conscious end-users have them at home.

We wrote this FAQ for computer systems developers and administrators. We
have tried to be fairly inclusive, making room for the newcomers, but we
still assume some basic technical background. If you find that you don't
understand this document, but think that you need to know more about
firewalls, it might well be that you actually need to get more background in
computer networking first. We provide references that have helped us;
perhaps they'll also help you.

1.3 Before Sending Mail

  Note that this collection of frequently-asked questions is a result of
interacting with many people of different backgrounds in a wide variety of
public fora. The firewalls-faq address is not a help desk. If you're trying
to use an application that says that it's not working because of a firewall
and you think that you need to remove your firewall, please do not send us
mail asking how.

If you want to know how to ``get rid of your firewall'' because you cannot
use some application, do not send us mail asking for help. We cannot help
you. Really.

Who can help you? Good question. That will depend on what exactly the
problem is, but here are several pointers. If none of these works, please
don't ask us for any more. We don't know.

   * The provider of the software you're using.
   * The provider of the network service you're using. That is, if you're on
     AOL, ask them. If you're trying to use something on a corporate
     network, talk to your system administrator.

1.4 Where Can I find the Current Version of the FAQ?

  The FAQ can be found on the Web at

   * http://www.interhack.net/pubs/fwfaq/.
   * http://www.ranum.com/pubs/fwfaq/

It's also posted monthly to

   * comp.security.firewalls,
   * comp.security.unix,
   * comp.security.misc,
   * comp.answers, and
   * news.answers.

Posted versions are archived in all the usual places. Unfortunately, the
version posted to Usenet and archived from that version lack the pretty
pictures and useful hyperlinks found in the web version.

1.5 Where Can I Find Non-English Versions of the FAQ?

  Several translations are available. (If you've done a translation and it's
not listed here, please write us so we can update the master document.)

Norwegian
     Translation by Jon Haugsand
     http://helmersol.nr.no/haandbok/doc/brannmur/brannmur-faq.html

1.6 Contributors

  Many people have written helpful suggestions and thoughtful commentary.
We're grateful to all contributors. We'd like to thank a few by name:
Keinanen Vesa, Allen Leibowitz, Brent Chapman, Brian Boyle, D. Clyde
Williamson, Paul D. Robertson, Richard Reiner, Humberto Ortiz Zuazaga, and
Theodore Hope.

1.7 Copyright and Usage

  Copyright 1995-1996, 1998 Marcus J. Ranum. Copyright 1998-2000 Matt
Curtin. All rights reserved. This document may be used, reprinted, and
redistributed as is providing this copyright notice and all attributions
remain intact. Translations of the complete text from the original English
to other languages are also explicitly allowed. Translators may add their
names to the ``Contributors'' section.

2 Background and Firewall Basics

  Before being able to understand a complete discussion of firewalls, it's
important to understand the basic principles that make firewalls work.

2.1 What is a network firewall?

  A firewall is a system or group of systems that enforces an access control
policy between two networks. The actual means by which this is accomplished
varies widely, but in principle, the firewall can be thought of as a pair of
mechanisms: one which exists to block traffic, and the other which exists to
permit traffic. Some firewalls place a greater emphasis on blocking traffic,
while others emphasize permitting traffic. Probably the most important thing
to recognize about a firewall is that it implements an access control
policy. If you don't have a good idea of what kind of access you want to
allow or to deny, a firewall really won't help you. It's also important to
recognize that the firewall's configuration, because it is a mechanism for
enforcing policy, imposes its policy on everything behind it. Administrators
for firewalls managing the connectivity for a large number of hosts
therefore have a heavy responsibility.

2.2 Why would I want a firewall?

  The Internet, like any other society, is plagued with the kind of jerks
who enjoy the electronic equivalent of writing on other people's walls with
spraypaint, tearing their mailboxes off, or just sitting in the street
blowing their car horns. Some people try to get real work done over the
Internet, and others have sensitive or proprietary data they must protect.
Usually, a firewall's purpose is to keep the jerks out of your network while
still letting you get your job done.

Many traditional-style corporations and data centers have computing security
policies and practices that must be adhered to. In a case where a company's
policies dictate how data must be protected, a firewall is very important,
since it is the embodiment of the corporate policy. Frequently, the hardest
part of hooking to the Internet, if you're a large company, is not
justifying the expense or effort, but convincing management that it's safe
to do so. A firewall provides not only real security--it often plays an
important role as a security blanket for management.

Lastly, a firewall can act as your corporate ``ambassador'' to the Internet.
Many corporations use their firewall systems as a place to store public
information about corporate products and services, files to download,
bug-fixes, and so forth. Several of these systems have become important
parts of the Internet service structure (e.g.: UUnet.uu.net, whitehouse.gov,
gatekeeper.dec.com) and have reflected well on their organizational
sponsors.

2.3 What can a firewall protect against?

  Some firewalls permit only email traffic through them, thereby protecting
the network against any attacks other than attacks against the email
service. Other firewalls provide less strict protections, and block services
that are known to be problems.

Generally, firewalls are configured to protect against unauthenticated
interactive logins from the ``outside'' world. This, more than anything,
helps prevent vandals from logging into machines on your network. More
elaborate firewalls block traffic from the outside to the inside, but permit
users on the inside to communicate freely with the outside. The firewall can
protect you against any type of network-borne attack if you unplug it.

Firewalls are also important since they can provide a single ``choke point''
where security and audit can be imposed. Unlike in a situation where a
computer system is being attacked by someone dialing in with a modem, the
firewall can act as an effective ``phone tap'' and tracing tool. Firewalls
provide an important logging and auditing function; often they provide
summaries to the administrator about what kinds and amount of traffic passed
through it, how many attempts there were to break into it, etc.

This is an important point: providing this ``choke point'' can serve the
same purpose on your network as a guarded gate can for your site's physical
premises. That means anytime you have a change in ``zones'' or levels of
sensitivity, such a checkpoint is appropriate. A company rarely has only an
outside gate and no receptionist or security staff to check badges on the
way in. If there are layers of security on your site, it's reasonable to
expect layers of security on your network.

2.4 What can't a firewall protect against?

  Firewalls can't protect against attacks that don't go through the
firewall. Many corporations that connect to the Internet are very concerned
about proprietary data leaking out of the company through that route.
Unfortunately for those concerned, a magnetic tape can just as effectively
be used to export data. Many organizations that are terrified (at a
management level) of Internet connections have no coherent policy about how
dial-in access via modems should be protected. It's silly to build a 6-foot
thick steel door when you live in a wooden house, but there are a lot of
organizations out there buying expensive firewalls and neglecting the
numerous other back-doors into their network. For a firewall to work, it
must be a part of a consistent overall organizational security architecture.
Firewall policies must be realistic and reflect the level of security in the
entire network. For example, a site with top secret or classified data
doesn't need a firewall at all: they shouldn't be hooking up to the Internet
in the first place, or the systems with the really secret data should be
isolated from the rest of the corporate network.

Another thing a firewall can't really protect you against is traitors or
idiots inside your network. While an industrial spy might export information
through your firewall, he's just as likely to export it through a telephone,
FAX machine, or floppy disk. Floppy disks are a far more likely means for
information to leak from your organization than a firewall! Firewalls also
cannot protect you against stupidity. Users who reveal sensitive information
over the telephone are good targets for social engineering; an attacker may
be able to break into your network by completely bypassing your firewall, if
he can find a ``helpful'' employee inside who can be fooled into giving
access to a modem pool. Before deciding this isn't a problem in your
organization, ask yourself how much trouble a contractor has getting logged
into the network or how much difficulty a user who forgot his password has
getting it reset. If the people on the help desk believe that every call is
internal, you have a problem.

Lastly, firewalls can't protect against tunneling over most application
protocols to trojaned or poorly written clients. There are no magic bullets
and a firewall is not an excuse to not implement software controls on
internal networks or ignore host security on servers. Tunneling ``bad''
things over HTTP, SMTP, and other protocols is quite simple and trivially
demonstrated. Security isn't ``fire and forget''.

2.5 What about viruses?

  Firewalls can't protect very well against things like viruses. There are
too many ways of encoding binary files for transfer over networks, and too
many different architectures and viruses to try to search for them all. In
other words, a firewall cannot replace security-consciousness on the part of
your users. In general, a firewall cannot protect against a data-driven
attack--attacks in which something is mailed or copied to an internal host
where it is then executed. This form of attack has occurred in the past
against various versions of sendmail, ghostscript, and scripting mail user
agents like OutLook.

Organizations that are deeply concerned about viruses should implement
organization-wide virus control measures. Rather than trying to screen
viruses out at the firewall, make sure that every vulnerable desktop has
virus scanning software that is run when the machine is rebooted. Blanketing
your network with virus scanning software will protect against viruses that
come in via floppy disks, modems, and Internet. Trying to block viruses at
the firewall will only protect against viruses from the Internet--and the
vast majority of viruses are caught via floppy disks.

Nevertheless, an increasing number of firewall vendors are offering ``virus
detecting'' firewalls. They're probably only useful for naive users
exchanging Windows-on-Intel executable programs and malicious-macro-capable
application documents. There are many firewall-based approaches for dealing
with problems like the ``ILOVEYOU'' worm and related attacks, but these are
really oversimplified approaches that try to limit the damage of something
that is so stupid it never should have occurred in the first place. Do not
count on any protection from attackers with this feature.

A strong firewall is never a substitute for sensible software that
recognizes the nature of what it's handling--untrusted data from an
unauthenticated party--and behaves appropriately. Do not think that because
``everyone'' is using that mailer or because the vendor is a gargantuan
multinational company, you're safe. In fact, it isn't true that ``everyone''
is using any mailer, and companies that specialize in turning technology
invented elsewhere into something that's ``easy to use'' without any
expertise are more likely to produce software that can be fooled.

2.6 Will IPSEC make firewalls obsolete?

  Some have argued that this is the case. Before pronouncing such a sweeping
prediction, however, it's worthwhile to consider what IPSEC is and what it
does. Once we know this, we can consider whether IPSEC will solve the
problems that we're trying to solve with firewalls.

IPSEC (IP SECurity) refers to a set of standards developed by the Internet
Engineering Task Force (IETF). There are many documents that collectively
define what is known as ``IPSEC'' [4]. IPSEC solves two problems which have
plagued the IP protocol suite for years: host-to-host authentication (which
will let hosts know that they're talking to the hosts they think they are)
and encryption (which will prevent attackers from being able to watch the
traffic going between machines).

Note that neither of these problems is what firewalls were created to solve.
Although firewalls can help to mitigate some of the risks present on an
Internet without authentication or encryption, there are really two classes
of problems here: integrity and privacy of the information flowing between
hosts and the limits placed on what kinds of connectivity is allowed between
different networks. IPSEC addresses the former class and firewalls the
latter.

What this means is that one will not eliminate the need for the other, but
it does create some interesting possibilities when we look at combining
firewalls with IPSEC-enabled hosts. Namely, such things as
vendor-independent virtual private networks (VPNs), better packet filtering
(by filtering on whether packets have the IPSEC authentication header), and
application-layer firewalls will be able to have better means of host
verification by actually using the IPSEC authentication header instead of
``just trusting'' the IP address presented.

2.7 What are good sources of print information on firewalls?



There are several books that touch on firewalls. The best known are:

   * Building Internet Firewalls, 2d ed.
     Authors
          Elizabeth D. Zwicky, Simon Cooper, and D. Brent Chapman
     Publisher
          O'Reilly
     Edition
          2000
     ISBN
          1-56592-871-7
   * Firewalls and Internet Security: Repelling the Wily Hacker
     Authors
          Bill Cheswick and Steve Bellovin
     Publisher
          Addison Wesley
     Edition
          1994
     ISBN
          0-201-63357-4
   * Practical Internet & Unix Security
     Authors
          Simson Garfinkel and Gene Spafford
     Publisher
          O'Reilly
     Edition
          1996
     ISBN
          1-56592-148-8
     Note
          Discusses primarily host security.

Related references are:

   * Internetworking with TCP/IP Vols I, II, and III
     Authors
          Douglas Comer and David Stevens
     Publisher
          Prentice-Hall
     Edition
          1991
     ISBN
          0-13-468505-9 (I), 0-13-472242-6 (II), 0-13-474222-2 (III)
     Comment
          A detailed discussion on the architecture and implementation of
          the Internet and its protocols. Volume I (on principles, protocols
          and architecture) is readable by everyone. Volume 2 (on design,
          implementation and internals) is more technical. Volume 3 covers
          client-server computing.
   * Unix System Security--A Guide for Users and System Administrators
     Author
          David Curry
     Publisher
          Addison Wesley
     Edition
          1992
     ISBN
          0-201-56327-4

2.8 Where can I get more information on firewalls on the Internet?



Firewalls Mailing List
     http://lists.gnac.net/firewalls/ The internet firewalls mailing list is
     a forum for firewall administrators and implementors. To subscribe to
     Firewalls, send subscribe firewalls in the body of a message (not in
     the ``Subject:'' line) to majordomo@lists.gnac.net
Firewall-Wizards Mailing List
     http://www.nfr.net/forum/firewall-wizards.html The Firewall Wizards
     Mailing List is a moderated firewall and security related list that is
     more like a journal than a public soapbox.
Firewall HOWTO
     http://sunsite.unc.edu/LDP/HOWTO/Firewall-HOWTO.html Describes exactly
     what is needed to build a firewall, particularly using Linux.
Firewall Toolkit (FWTK) and Firewall Papers
     ftp://ftp.tis.com/pub/firewalls/
Marcus Ranum's firewall related publications
     http://www.ranum.com/pubs/
Papers on firewalls and breakins
     ftp://ftp.research.att.com/dist/internet_security/
Texas A&M University security tools
     http://www.net.tamu.edu/ftp/security/TAMU/
COAST Project Internet Firewalls page
     http://www.cs.purdue.edu/coast/firewalls/

3 Design and Implementation Issues



3.1 What are some of the basic design decisions in a firewall?

  There are a number of basic design issues that should be addressed by the
lucky person who has been tasked with the responsibility of designing,
specifying, and implementing or overseeing the installation of a firewall.

The first and most important decision reflects the policy of how your
company or organization wants to operate the system: is the firewall in
place explicitly to deny all services except those critical to the mission
of connecting to the Net, or is the firewall in place to provide a metered
and audited method of ``queuing'' access in a non-threatening manner? There
are degrees of paranoia between these positions; the final stance of your
firewall might be more the result of a political than an engineering
decision.

The second is: what level of monitoring, redundancy, and control do you
want? Having established the acceptable risk level (e.g., how paranoid you
are) by resolving the first issue, you can form a checklist of what should
be monitored, permitted, and denied. In other words, you start by figuring
out your overall objectives, and then combine a needs analysis with a risk
assessment, and sort the almost always conflicting requirements out into a
laundry list that specifies what you plan to implement.

The third issue is financial. We can't address this one here in anything but
vague terms, but it's important to try to quantify any proposed solutions in
terms of how much it will cost either to buy or to implement. For example, a
complete firewall product may cost between $100,000 at the high end, and
free at the low end. The free option, of doing some fancy configuring on a
Cisco or similar router will cost nothing but staff time and a few cups of
coffee. Implementing a high end firewall from scratch might cost several
man-months, which may equate to $30,000 worth of staff salary and benefits.
The systems management overhead is also a consideration. Building a
home-brew is fine, but it's important to build it so that it doesn't require
constant (and expensive) attention. It's important, in other words, to
evaluate firewalls not only in terms of what they cost now, but continuing
costs such as support.

On the technical side, there are a couple of decisions to make, based on the
fact that for all practical purposes what we are talking about is a static
traffic routing service placed between the network service provider's router
and your internal network. The traffic routing service may be implemented at
an IP level via something like screening rules in a router, or at an
application level via proxy gateways and services.

The decision to make is whether to place an exposed stripped-down machine on
the outside network to run proxy services for telnet, FTP, news, etc., or
whether to set up a screening router as a filter, permitting communication
with one or more internal machines. There are pluses and minuses to both
approaches, with the proxy machine providing a greater level of audit and
potentially security in return for increased cost in configuration and a
decrease in the level of service that may be provided (since a proxy needs
to be developed for each desired service). The old trade-off between
ease-of-use and security comes back to haunt us with a vengeance.

3.2 What are the basic types of firewalls?

  Conceptually, there are two types of firewalls:

1.   Network layer
2.   Application layer

They are not as different as you might think, and latest technologies are
blurring the distinction to the point where it's no longer clear if either
one is ``better'' or ``worse.'' As always, you need to be careful to pick
the type that meets your needs.

Which is which depends on what mechanisms the firewall uses to pass traffic
from one security zone to another. The International Standards Organization
(ISO) Open Systems Interconnect (OSI) model for networking defines seven
layers, where each layer provides services that ``higher-level'' layers
depend on. In order from the bottom, these layers are physical, data link,
network, transport, session, presentation, application.

The important thing to recognize is that the lower-level the forwarding
mechanism, the less examination the firewall can perform. Generally
speaking, lower-level firewalls are faster, but are easier to fool into
doing the wrong thing.

3.2.1 Network layer firewalls

These generally make their decisions based on the source, destination
addresses and ports (see Appendix C for a more detailed discussion of ports)
in individual IP packets. A simple router is the ``traditional'' network
layer firewall, since it is not able to make particularly sophisticated
decisions about what a packet is actually talking to or where it actually
came from. Modern network layer firewalls have become increasingly
sophisticated, and now maintain internal information about the state of
connections passing through them, the contents of some of the data streams,
and so on. One thing that's an important distinction about many network
layer firewalls is that they route traffic directly though them, so to use
one you either need to have a validly assigned IP address block or to use a
``private internet'' address block [3]. Network layer firewalls tend to be
very fast and tend to be very transparent to users.


                              Figure 1: Screened Host Firewall

 [\begin{figure} \begin{center} \includegraphics {firewalls-faq1} \end{center}\end{figure}]

In Figure 1, a network layer firewall called a ``screened host firewall'' is
represented. In a screened host firewall, access to and from a single host
is controlled by means of a router operating at a network layer. The single
host is a bastion host; a highly-defended and secured strong-point that
(hopefully) can resist attack.


                             Figure 2: Screened Subnet Firewall

 [\begin{figure} \begin{center} \includegraphics {firewalls-faq2} \end{center}\end{figure}]

Example Network layer firewall : In figure 2, a network layer firewall
called a ``screened subnet firewall'' is represented. In a screened subnet
firewall, access to and from a whole network is controlled by means of a
router operating at a network layer. It is similar to a screened host,
except that it is, effectively, a network of screened hosts.

3.2.2 Application layer firewalls

These generally are hosts running proxy servers, which permit no traffic
directly between networks, and which perform elaborate logging and auditing
of traffic passing through them. Since the proxy applications are software
components running on the firewall, it is a good place to do lots of logging
and access control. Application layer firewalls can be used as network
address translators, since traffic goes in one ``side'' and out the other,
after having passed through an application that effectively masks the origin
of the initiating connection. Having an application in the way in some cases
may impact performance and may make the firewall less transparent. Early
application layer firewalls such as those built using the TIS firewall
toolkit, are not particularly transparent to end users and may require some
training. Modern application layer firewalls are often fully transparent.
Application layer firewalls tend to provide more detailed audit reports and
tend to enforce more conservative security models than network layer
firewalls.


                                Figure 3: Dual Homed Gateway

 [\begin{figure} \begin{center} \includegraphics {firewalls-faq3} \end{center}\end{figure}]

Example Application layer firewall : In figure 3, an application layer
firewall called a ``dual homed gateway'' is represented. A dual homed
gateway is a highly secured host that runs proxy software. It has two
network interfaces, one on each network, and blocks all traffic passing
through it.

The Future of firewalls lies someplace between network layer firewalls and
application layer firewalls. It is likely that network layer firewalls will
become increasingly ``aware'' of the information going through them, and
application layer firewalls will become increasingly ``low level'' and
transparent. The end result will be a fast packet-screening system that logs
and audits data as it passes through. Increasingly, firewalls (network and
application layer) incorporate encryption so that they may protect traffic
passing between them over the Internet. Firewalls with end-to-end encryption
can be used by organizations with multiple points of Internet connectivity
to use the Internet as a ``private backbone'' without worrying about their

Section 1 of 4 - Prev - Next
All sections - 1 - 2 - 3 - 4

Back to category LAN - Use Smart Search
Home - Smart Search - About the project - Feedback

© allanswers.org | Terms of use

LiveInternet