The first thing to be aware of is that the term "Virtual Private Network" (VPN) is very often (deliberately) misused. It should not refer to a setting in which in which the traffic related to a particular protocol is secured, as is often done when we use HTTP with TLS or similar protocols, that are part of a particular instance of a particular application. A Virtual Private Network is involved when we are interested in having all traffic between members of a set of networks carried in a secure fashion, whatever the protocol above the network layer may be.

The most common setting in which public network facilities are used to carry the traffic between the nets. This is a tunneling arrangement in which the private traffic is carried inside the tunnel, and the tunnel itself is built with the public network.

Be very careful when someone calls something a VPN. It is very likely it is just a tunneling mechanism to which forms of encryption might be added, or an method of securing individual application instances.

In terms of the WISE model we may think of the set of private networks as the system and the public network as the environment, or dually of the set of private networks as the environment and the public network as the system, depending on our perspective.

Typically the private network uses private addresses (those with prefix 10/8 or 172.16/12 or 192.168/16 (in accordance with RFC 1918). There is a set of 3 RFCs that discussed such addresses:

The situation with IPv6 addressing is more complex, with a class of link-local addresses relating to multiple interfaces at a particular node, and an early notion of site-local addressing now in dispute.

The IPSec protocol, now in its second incarnation, is the first protocol folks typically think of when they desire to secure IP transmission involving a set of IP networks. It is also very complex, having been produced by many committees and many individuals many of whom were not enamored of the KISS principle. It is complex to set up and to keep operating, and suffers from what is to some a major defect, much of it must be done in the kernel space of the operating system.

One of the major stumbling blocks has been the exchange of keys, given that most believe that keys need to be changed frequently (although the meaning of "frequently" varies over a wide wide range). Recently the use of certificates has become better established and has simplified the problem significantly, but the many products on the market suffer from a marked amount of incompatibility at this time. This has led some to recommend this approach only when you are dealing with a fixed set of networks each of which is using compatible equipment and has a substantial devotion to management of the networks.

The idea is fairly simple. Each site is behind some sort of gateway (or perhaps multiple gateways God forbid (any network God will do)). The traffic behind each gateways is handled independently of the VPN, and any traffic leaving a gateway for the wild and wooly world of the Internet on its way to the tame site behind another gateway is suitably addressed and encrypted.

A major defect in the opinion of many (yes, this author included) is that there are four possible selections to begin with: two protocols and two modes. This author (agreeing with others such as A Cryptographic Evaluation of IPsec by H. Ferguson and Bruce Schneier) finds only one of the four understandable and useable. Namely there are two forms of encryption called AH and ESP and two forms of transfer called transport and tunneling, and only one of these really makes sense (to this author). So we will focus on it.

What happens is that as interior IP traffic is traversing the gateway it is wrapped inside a properly coded packet, perhaps performig all of the CIA operations (encryption integrity authentication), and then again wrapped into an IP packet with exterior addressing going to the destination gateway, which then unwraps it into the original interior IP packet.

This is all well and good and understandable, but since the belief is that keys need to be changed there must be a key exchange, and that is a PITA to setup, administer, and execute. Recent improvements in our understanding of certificates have vastly simplified this key exchange. One of the issues is how many and what kinds of ports and protocols firewalls need to allow through at either end, especially whether or not a UDP port (usually 500) needs to be involved.

The key exchange has been done over and over again in many ways, most of them with vastly more complexity than is needed.

There is a strange situation with IPv6. It is widely advertised and believed that IPv6 is "more secure" because it mandates IPSec. That sounds good (you can envision the chief of police saying "my city is safe because we mandate the Ten Commandments for our citizens) but no one has really sorted out how to implement IPSec over IPv6, so the "security" does not exist.

The TLS protocol, as we have earlier seen, is widely used and highly workable in an application to application setting, but as we have also seen in this lectures this kind of security is not a VPN. However there is no difficulty in implementing "an application to tunnel IP" and that is in effect what has been done for what are called TLS VPNs.

Be very careful when considering something that claims to be a TLS (or SSL) VPN. Very often what is really being offered is a way to carry the client traffic through a browser, which is most decidely not a VPN. For one thing HTTP is not even a good protocol substrate:

One arrangement widely termed a VPN began as just tunneling one kind of network protocol over another, which began to be termed a VPN when it was realized that the messages could be encrypted. These include the