VPNs, 101

Editor's Note - 05.02.02

Hello readers,

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!

send comments/feedback

VPNs, 101

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 VPN.

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 nightmare.

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 information. (jay@securitypronews).

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 endpoints?

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 the communication.

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.