Note - 05.02.02
VPN (Virtual Private Network) has become quite the buzzword in the
IT industry over the past couple of years. Many experts in the field have
said that information security will determine the future of computing as
we know it. That being said, I have put together a very basic introduction
to VPNs that I think will help give you an understanding of what VPNs are
and how they are used.
I have had an interest in VPNs for quite some time; however, finding
information on VPNs that is easily digestible is difficult. I have looked
at several books on the subject and most of them are written in a manner
that lends more to confusion than enlightenment (IMHO). Recently I bought
a book regarding VPNs that was earning rave reviews: "Building Linux Virtual
Private Networks (VPNs)" by Oleg Kolesnikov and Bri Hatch. You may recognize
Bri Hatch from his book "Hacking Linux Exposed"-- another title I would
recommend for those interested in security.
Don't let the title throw you off. The first few chapters of the
book discuss VPNs in general terms so that you understand the basic functionality
of them. Discussions about the OSI model and basic networking have been graciously
omitted, as it is assumed the reader will already know these things. This
is a very easy to read book that I would highly recommend to *anyone* considering
implementing a VPN on their network, regardless of whether you intend to
use Linux to do it or not. This book is that good.
Read on and enjoy!
by Jay Fougere
I am sure that most of you have heard of Virtual Private Networks,
but do you know what they are and what they are good for? VPNs are a secure
way for machines to communicate through a public network, privately.
A VPN is simply a network that emulates a private network, such
as what you may have with leased lines. It does this by creating a "tunnel"
through the Internet. This tunnel is simply an encrypted "pipe" between two
nodes. The advantage to this is the extreme cost savings over using leased
lines. The main problem with this should be obvious; it can be difficult
to use the Internet to transmit sensitive data securely.
VPNs emulate a private network by specifying endpoints for the
tunnel, and encrypting all of the data that passes through the tunnel. This
way, when it is set up properly, you have one of three scenarios. You either
have a network-to-network VPN, a client to network VPN, or a client-to-client
I think those definitions are relatively self-explanatory, but
just so that there is no confusion I am going to elaborate a bit on them.
The endpoints of the tunnel must be specified. That being said, a client-to-client
VPN is just that. No machines other than the two clients (endpoints) can
use the tunnel, regardless of whether there are other machines on the same
physical network as these machines. A client-to-network VPN is similar, except
that one of the endpoints is a router. On the client end, the configuration
would be the same as that in a client-to-client VPN. The network endpoint
would act as an access point to the VPN for an internal network, or it would
provide access to the internal network from the VPN (or it could do both).
Normally the network endpoint will have two network cards - one
for the internal network and one for the VPN, the same as a router. A single
network card can be used, but (without getting into a lengthy discussion
as to why) you are asking for trouble by doing this. The machine in question
will decrypt/encrypt traffic on the VPN network interface while the internal
network interface will communicate normally to the internal network (i.e.
without encryption). A network-to-network VPN is the same as a client-to-network
VPN, except that both endpoints are networks (routers) rather than individual
machines. This is one of the most popular implementations of a VPN as it
can connect internal networks in remote offices without sacrificing security.
The important thing to remember is that the endpoints are specifically
defined, removing the possibility of a machine on the Internet seeing this
traffic as it passes. It is not that simple in reality; all of the traffic
will still need to be routed by devices on the Internet, but the payload
is invisible to these devices.
An important thing to remember with VPNs is that there will be
some processing overhead involved. While an old 486 could keep up with routing
the amount of traffic you will have between networks, it will probably not
have the processing power to encrypt/decrypt all of this traffic. There are
other methods of setting up endpoints for a VPN as well; some routers have
VPN functionality and there are several manufacturers of VPN appliances.
There are many ways to accomplish this, both commercial and Open
Source. Regardless of whether you choose a commercial solution or an Open
Source solution, the same protocols and techniques are used. We will take
a look at some of the most popular VPN protocols throughout the rest of this
article. Each method of deploying a VPN has its pros and cons.
The first protocol that I would like to discuss is PPTP
(Point to Point Tunneling Protocol). PPTP is a proprietary
protocol developed independently by Microsoft and is available
on Microsoft server products using RRAS (Routing and Remote
Access Server). I mention PPTP because it may seem like
the obvious choice for those of you using Microsoft products;
be warned that there are flaws inherent in PPTP that may
compromise your VPN (see below).
Because of these flaws, PPTP may not be your best choice. This is not to
say that there is no good time to use PPTP. It could be used on an internal
network to ensure privacy of sensitive documents. The chances of employees
having the skills required to compromise PPTP are slim compared to crackers
on the Internet. For instance, you may have accounting documents that only
a select few employees need to access, in a single location network. The
easiest (read as "least costly") way to do this may be to use PPTP. You will
need to evaluate the appropriateness of using PPTP on a case-by-case basis.
A more popular and more secure choice might be Layer-2 PPPoE (Point
to Point Protocol over Ethernet). Because PPP traffic has already implemented
TCP/IP, it is relatively easy to encrypt this traffic before it traverses
the network. There are several well-known encryption protocols that can be
used to encrypt this traffic; all of them have their own specific advantages
and disadvantages. SSHv1 (Secure SHell version 1) and SSHv2 are both susceptible
to attack, although they are not nearly as vulnerable as PPTP. SSHv1 is vulnerable
to a "man in the middle" attack while SSHv2 can be subject to traffic analysis-based
attacks. SSL (Secure Sockets Layer) can be implemented, although administration
can become quite cumbersome. The same applies to PKI (Public Key Infrastructure)
solutions, being that keeping track of keys can quickly become an administration
IPSec (IP Security) is the last of the "standard" VPN protocols.
IPSec is probably the best choice for security and inter-operability. Many
commercial solutions are based on IPSec. The problem with IPSec is that it
can be more difficult to administer than the previous two examples; not to
mention, due to the various ways in which IPSec is implemented, inter-operability
amongst vendors is not guaranteed.
IPSec was developed by the IETF, although vague definitions in
the protocol lend themselves to problems with compatibility amongst vendors.
IPSec is actually implemented in three parts, which is why it can be difficult
to administer, yet it remains one of the most secure (and popular) implementations
of VPNs. Keep in mind that there are several commercial implementations of
IPSec that reduce much of the administrative overhead of IPSec.
The first part of IPSec is IKE (Internet Key Exchange).
This is the portion of the protocol devoted to exchanging
keys for encryption/decryption. There are claims that
vulnerabilities exist in IKE that could make IKE insecure.
In my searches on the subject, the only problems that
I have been able to find relate to Microsoft Windows 2000's
implementation of IPSec. If any readers have more information
on this, please let me know so that I can pass on this
The Authentication Handler (AH) is the next step in IPSec communications.
This is the part of IPSec that authenticates both ends of the communication.
After all, what good is encrypted communication if you cannot verify the
Once keys have been handled and authentication has taken place,
ESP (Encapsulating Security Payload) will encode the data in the communication.
Depending on your implementation one of several ciphers can be used to encrypt
There are several protocols available that are not standard.
As they are not standard, I won't discuss them here. One
of these protocols may even be the ideal solution for
your situation. If there is enough interest, a future
article could be devoted to these, let me know.
Wait For AOL To Show Some Strength
ACLU Sues Firm Over Its Filtering Software
Qualcomm Beats Estimates, Despite Wireless' Weakness
Counterfeit Nikes Seized
Entertainment Industry May Start Hacking
Java Takes Center Stage
Exel Opens New Facility In Australia
Almost All Java Web Apps Need Model 2
Analysts Downgrade AOL After SEC Probe Disclosed
CMC Net Profit Rises By 116%
Add Headlines To Your Site For Free!
Free Email Newsletters