|
VPNs
are the most common means of ensuring secure connectivity
between diverse locations. A look at the implementing
VPN services in the enterprise. by Graeme K. Le Roux
 As
the name suggests, a VPN (Virtual Private Network) is
a network within a network based on the simple premise
that the payload of an IP datagram can be anything including
another IP datagram or even a packet from a lower ISO/OSI
layer.
If you simply pick such a payload up from one location,
wrap it in an IP datagram, carry it via normal mechanisms
to another location and unwrap it, then the payload
will act exactly as if the two locations were connected
in a more traditional manner i.e. via a leased line,
or an Ethernet network.
There is a useful side effect of this method of transport
the payload of an IP datagram does not interact with
the network carrying it. For example, you don't expect
a Web page that you are downloading to interact with
the TCP/IP session carrying it. The reverse is also
true a router in an IP internetwork doesn't make routing
decisions based on the contents of a particular datagram's
payload.
Of course if you wrap an IP datagram in another IP datagram,
you end up with two complete and distinct sets of IP
headers including all the option fields, etc. which
effectively doubles your network overhead. If given
reasonable network capacity this is tolerable in most
cases. However, care has to be taken when running VPNs
over analogue modems. You also incur some extra processing
overhead if you try to run a VPN between older hosts.
In
the case of VPNs in a TCP/IP environment, the most interoperable
way of implementing VPNs is via IPSec operating in tunnel
mode. There is another IPSec mode called transport mode
which is intended for a direct connection between two
hosts rather than for connections which have to pass
through gateways. Tunnel mode can be used between two
hosts. In fact, this is one of its more important uses
as this is usually how a remote host uses a VPN over
the Internet to access a network, with teleworking being
the most common example.
| What
kind of VPN do you need? |
|
An IP VPN is commonly defined as
a routed link between two or more points across
a heterogeneous network topology, with various
degrees of security that ensure privacy for all
parties. The idea behind the IP VPN is to leverage
on the Internet's reach and low cost, in order
to eliminate the more expensive dedicated links
common today.
You can set up VPNs in several ways, but Customer
Premises Equipment (CPE)-based IP VPNs and network-based
IP VPNs are the most common approaches. The difference
lies in the network architecture: In CPE-based
VPNs, the routing intelligence resides at an end-user
site, while in carrier-based VPNs, it resides
at the provider's edge, where it can be extended
out to many end-user locations.
There are three types of VPNs. First, remote-access
VPNs allow telecommuters or home workers to access
their corporate data networks. Second, site-to-site
VPNs connect remote offices over the Internet.
Site-to-site VPNs use secure point-to-point connections
in a mesh topology overlaid on the Internet, or
even on a single provider's network.
Third, extranet VPNs connect a "community
of interest," such as a company, its partners,
suppliers, and customers, and so on, to an enterprise
network and perhaps other relevant destinations.
In extranet VPNs, an authorized third-party user
arrives at the enterprise firewall after traversing
the public network, and the destination (often
the home office) VPN gateway terminates the traffic
and grants trans-firewall access where appropriate.
When it's time to engineer your VPN, you need
to consider many issues, such as the timeline
for deployment and what applications the VPN will
serve.
For intranet and extranet users, you need to consider
what type of data is involved and whether you
ought to set priority levels based on the type
of traffic. You also need to know the number of
users, how many classes of users you have, and
what specific restrictions apply to these user
groups. Consider also the type of resource access
to grant, as well as assigning QoS levels.
Next, decide whether to use a CPE- or network-based
solution. Each approach has pros and cons, but
remember that most first-generation network-based
solutions encrypt data only from service provider
edge to service provider edge the access link
isn't secured.
It's
also possible for service providers to install
devices they own and control on the customer premises.
Alternatively, some software overlay VPNs offer
a mix of CPE- and network-based equipment or service
options.
|
VPN
and NAT
Another common usage of the IPSec tunnel mode is to
connect two physically separate IP networks that use
private addresses across the public Internet.
Consider two networks which have one router each and
where each router has a single physical connection to
the Internet and a single physical connection to their
respective LANs. Because we are using private addresses
in each LAN, the routers have to perform NA(P)T (Network
Address and Port Translation) to provide Internet access
for all hosts on each LAN. By implementing IPSec on
each of these routers, they can act as in IPSec terms
Security Gateways (SGs).
We can now establish an IPSec tunnel between the LAN
interfaces of each router and thus avoid the need to
perform NAT (Network Address Translation) on traffic
flowing between the networks. In most cases (Windows
VPN services being an example), such IPSec tunnels are
implemented as a Virtual Network Adaptor to which a
separate IP address is assigned.
This way, each router's single LAN interface has two
IP addresses one for direct access to the Internet via
NA(P)T in the normal way, and a second for apparently
direct access to the remote LAN. At each site the local
IP address for Internet access remains as the LAN's
default gateway, while the local IP address for the
VPN is advertised as the route to the remote LAN.
We can effectively restrict Internet access by simply
advertising the IP address that gives Internet access
only to those hosts which are permitted such access.
This is easy to implement with DHCP. For example, you
might set DHCP to provide the VPN's local IP address
as the default gateway to all workstations while setting
up your mail server to use the IP address for the Internet
as its default gateway.
Note that if you have mail servers at both sites set
this way, they would send e-mail between each other
via the public Internet rather than the VPN. To avoid
this, you could set up a secondary route for mail.
To try this sort of configuration, simply use Windows'
built-in routing service and VPN capabilities, as well
as a standard tracert utility. Later Cisco routers also
provide a good platform for experiment. One caveat though:
try not to experiment your alternate mail route on a
live system.
Security
We can force traffic between two networks across the
Internet using simple NAT. But NAT can't provide privacy.
Just wrapping one datagram inside another does not disguise
the content of the original datagram, or prevent someone
on the Internet from intercepting it, reading it and
even editing it and then forwarding it.
Obviously, if you are going to use the Internet as a
backbone transport for your company network then this
is unacceptable.
For this reason IPSec provides a standard framework
to support encryption algorithms, from NULL (i.e. no
encryption) to triple DES, IDEA, etc. It supports both
symmetric and asymmetric (aka public key) algorithms.
For the paranoid, you can use IPSec to encrypt every
packet on your company network using a public key algorithm
to ensure that only specific hosts can read the contents.
The aggregate processing overhead would be huge, but
it can be done.
VPNs that are based on IPSec are probably best used
with higher bandwidth access services such as cable
or ADSL. While VPNs can be used over Internet connections
based on analogue modems, their processing overheads
can be withering. Where a standard TCP/IP connection
will incur about 11 percent overhead, a VPN will incur
about 20 percent, or one-fifth of the available bandwidth.
If you are going to try this, consider very carefully
just what types of data you want to transfer over your
VPN. Text is best and heavy graphics is worst. In addition,
the stronger your VPN encryption, the more CPU time
your connection is going to use up. If you are using
a laptop from batteries, this can mean not only slow
application response but shorter battery life.
Selling VPN
VPN implementation tends to be a rather technical subject
and is probably not something you can discuss the finer
points with the company board. Fortunately, the business
case for the use of VPNs is something which tends to
be a lot clearer.
To present a case for VPN, first of all work out how
many of your leased line services can be replaced with
cheaper Internet access services such as ADSL or cable,
as well as the cost of such links. Remember that you
will need a fixed Internet IP address to enable you
to establish a VPN.
This does not mean a static IP address range has to
be allocated; it just means that whenever the session
to any local ISP is reset, the IP's authentication server
has to assign the same IP address to the new PPP (or
PPPoE) session.
This is a software setting in most authentication schemes
(RADIUS, TACACS, etc) and most ISPs will be happy to
set it up for you. Next, you need to work out the cost
of the security gateways you will need at each site.
This may be a new box or an upgrade of an existing device.
If all these are not significantly cheaper than your
existing system, forget about using VPNs between your
offices.
Follow that by doing the same sort of calculations for
the teleworkers in your company, particularly those
who take laptops home; using a VPN means you can assign
a private address to a remote host.
This allows you to extend your security wall to the
remote host-along with your security policies. In fact,
if you can get a suitable broadband connection to the
teleworker's home you can provide them with a Windows
Terminal instead of a laptop. This will be cheaper and
a lot more secure.
Using IPSec and a suitable encryption algorithm will
also allow you to provide a much higher level of general
security in your network. This is because VPN encryption
keys can be easily and quickly changed in the event
of a security breach, such as if a laptop has been stolen
or an employee urgently sacked.
The swiftness afforded by IPSec means that there will
be minimal impact on operations. Most companies will
look favorably on anything that will allow them to provide
clients with an assurance of greater data security and
integrity, especially if it makes economic sense.
What you have
Another point in favor of VPNs in a Windows environment
is that you already have most of the software required,
since the basics are built into Windows.
If you use routers from any of the major vendors you
may find that you have IPSec support built into your
routers as well.
In fact, a good place to start a VPN deployment is with
the management interfaces for your network; set your
routers to accept management connections only via encrypted
VPNs.
You can probably do this without board level approval,
and when you have done it successfully you may find
it easier to convince management to allow you to at
least investigate applying the same technology to the
rest of your network.
Graeme K. Le Roux is the director
of Morsedawn (Australia), a company which specialises
in network design and consultancy and writes for Network
Computing-Asian Edition.
|
|| Feedback
|| Subscribe-
