Talk:Virtual private network

Textbooks and conflict of interest

I've written books in this area, but wanted to leave it to others to recommend appropriate references or further reading. I happen to think they are informative on customer and provider VPN relationships :-). For the customer side, WAN Survival Guide (Wiley, 2001), and for the provider side, Building Service Provider Networks (Wiley, 2002).

I did put in a public domain, very basic tutorial. Howard C. Berkowitz 12:18, 14 July 2008 (CDT)

Query

The current initial definition reads: "A virtual private network (VPN) a set of sites, owned by customers, which are connected through some type of backbone." I think that is seriously misleading. Yes, there are quite a few VPNs to which that definition applies, but it does not seem general enough.

I'd prefer something like "A Virtual Private Network, or VPN, is a network which can safely be used as if it were private, even though some of its communication uses insecure connections. All traffic on those connections is encrypted."

To my way of thinking, the current article is clear and well-written, but mostly wrong as a general description of VPNs. Provider-based VPNs are an important class of VPN, but they should be described either under a sub-heading or in a separate article, not as the main VPN article.

However, I thought I'd ask here before making major changes Sandy Harris 08:54, 1 August 2008 (CDT)

Some good points, Sandy, that probably need some expansion or clarification of its terms. Let me start with "customer". I'll come back to why I think the definition is accurate, and my first example is one where your revision wouldn't have been applicable.

In IETF discussions and documents, "customer" is used in several ways. It's perfectly acceptable to have no contracted external provider, but you will still have an internal network administrator that is considered the "provider". Let me take one simple and real example of what was totally invisible to outside providers, but where the separation still made sense.

Companies A and B merged, and their network groups consolidated. Both had numbered their networks in IPv4 private address space, so there were many address collisions in 10.0.0.0/8. They consolidated their network administration team, and asked for help because they weren't ready to renumber everything. Unfortunately, we don't have a whiteboard handy, and I note that graphics of some of these are useful.

In the first design, we arbitrarily said the former customer A network would be the "backbone" as well as providing for the needs of A. This was done without encryption, but with Generic Route Encapsulation (GRE) tunnels. Assume you are at a company B factory, site B1, which has several routers around its campus, numbered in B space. Router B1R2 connects to a client LAN with end user BU100 on it. B1R0 interconnects the three local B-space only routers, and then had a frame relay interface B1R0C1 ("connector 1") that linked it to sites B2 and B3 in other cities.

It turned out that company A had an facility of its own in the same city as B1, with local routers A1R1, A1R2 (LAN only) and a much faster wide area link on A1R0. In city A99, there was a main router, A99R0 and two office routers, A99R1 and A99R2. At this point, assume A and B run completely different routing protocols. There also was a B facility, B99, in city 99.

On router B1R0, we created a tunnel interface on the WAN interface, the tunnel in B space. The WAN interface itself was in A space and connected to A99R0, where there was another tunnel interface in B space mapped onto the WAN interface. In city 99, some people in company B moved to the building with router A99R1 in it.

At this point, an ugly one, A-space is both the enterprise A VPN and the backbone. B space is real space in B-only facility, but is always a VPN mapped onto A space in the WAN.

For the interim step, we configured B space tunnel interfaces on A99R0 and A99R1. We added an Ethernet interface, A99R1C2, to the router where the B people were moving to the A company location, and numbered that interface in B space. When a packet started out in City 1 on router B1R2, it would go by an in-town WAN link to B1R0. The packet would physically go over a new local line that connected B1R0 to A1R0, and that line terminated on a second WAN interface in A1R0, which again had both an A-space physical address and a B-space tunnel address. There was a B-space tunnel over the WAN link between the cities. When the packet arrived at A99R0, that router had an A-space physical interface to the A99R1 site, with B-space interfces mapped onto it. Ethernet interface A99R1C2 was actually numbered in B space, and the former B people still thought their computer talked B address space to city 1; the packets atarted on a B space interface, traveled over the B tunnels in City 1 to the B tunnels in city 99, and eventually got to the B-space Ethernet, A99R1C2.

Subsequently, we added a third space, Y, into 172.16.0.0/16, and created a true backbone space, Z, in 192.168.0.0/16 and began renumbering both A and B into it; see my RFC 2071 for some of the router-specific techniques. At this point, A, B, and Y are all VPNs mapped onto Z-space.

Nothing went over the public Internet; the WAN was all dedicated line and frame relay, which were judged to be secure enough without encryption. Essentially, we mapped a VPN for B space onto the combined user and backbone A. No ISPs involved. No encryption.

Where the provider-provisioned VPN terminology became very useful were to describe routers:

• A space only and B space only routers were the equivalent of CEs, which, in a PPVPN, is only aware of its own VPN.
• Routers with interfaces in more than one VPN(A, B, or Y) were PE; they might also connect to Z space.
• Routers, which initially just aggregated traffic onto faster links and were in Z space only were P routers.

I'm perfectly willing to make the point that the "provider" may be internal to an enterprise, but it is quite common to use multiple VPNs, sometimes encrypted and sometimes not, in a network run by the enterprise's network group. If some of the inter-site links are on the public Internet, they certainly would be encrypted, but the ISP has absolutely no idea that several enterprise VPNs are running over it. If he looked at the line, he would only see IPSec packets in public address space he assigned.

I definitely would not say that that an architectural model with the concepts of CE, PE, and P, and backbones, is a provider-provisioned only technique. It's quite common to have the architecture in pure intranets. CE/PE/P is not unique to BGP/MPLS PPVPNs. As you can see, the functions all existed in a pure GRE backbone. Encryption may be present in all, part, or none of the backbone and/or VPNs.

Howard C. Berkowitz 12:42, 1 August 2008 (CDT)

To me, your example is a real private WAN, or set of them. I would not use the virtual unless some of the privacy is implemented by encrypting otherwise insecure links. But then, the only VPN work I've done was on FreeS/WAN, Linux IPsec, so perhaps I have too narrow a view. Anyone else care to chime in? Sandy Harris 19:22, 1 August 2008 (CDT)

Virtualization need have nothing to do with encryption

I'm not making these examples up out of random opinion, but IETF work that easily go back ten years.

In 2000, http://www.ietf.org/rfc/rfc2764.txt observed "VPN is simply defined as the 'emulation of a private Wide Area Network (WAN) facility using IP facilities' (including the public Internet, or private IP backbones). As such, there are as many types of VPNs as there are types of WANs, hence the confusion over what exactly constitutes a VPN...In this document a VPN is modeled as a connectivity object"

To take your example with Linux IPSec, surely you don't think that the encrypted paths were physical? They were mapped onto IP, which is agnostic of the transmission medium.

GMPLS, ASON, and other work assume multiple levels of abstraction or multiplexing. If I go to an undersea optical ring in the Southwest Pacific, I'd find ten or more wavelengths over it, each running OC-192 signal (about 10 Gbps). Each one of those lambdas (i.e., wavelengths) could be leased to a different international carrier, who is a wholesaler to ten national telecommunications provider. The fiber lessor puts ten 802.1Q-in-Q tunneled VLANs, each carrying ten of their customers' entire bandwidth. Into each of those customer appearance, the customer puts ten of his own 802.1Q (not Q-in-Q) VLANs. Into each one of those VLANs is an assortment of IP tunnels using IPIP, IPSec, GRE, and L2TP, all appearing as an interface (sortware defined, but routers don't care). They could also be MPLS or GMPLS tunnels. Every one of those GRE tunnels could hve ten IPSec domains within it.

What, then, is real? What is virtual? I can keep stacking protocols, and this is not a hypothetical -- I constantly see networks at that level. When there is a single fiber cut and hundreds of apparently independent circuits die, it gives a sense of how much encapsulation there may be -- and, for that matter, if I had done a good failover on that fiber, the users might never notice that a kilometer of fiber is now wrapped around a truck's wheel.

If you have authoritative definitions that say security is the determinant of a VPN, I'd like to see them. Howard C. Berkowitz 20:08, 1 August 2008 (CDT)

VPN Consortium http://www.vpnc.org/vpn-technologies.html gives:

"A virtual private network (VPN) is a private data network that makes use of the public telecommunication infrastructure, maintaining privacy through the use of a tunneling protocol and security procedures. ...

"Before the Internet became nearly-universal, a virtual private network consisted of one or more circuits leased from a communications provider. ... The VPN customer trusted the VPN provider to maintain the integrity of the circuits and to use the best available business practices to avoid snooping of the network traffic. Thus, these are called trusted VPNs.

"As the Internet became more popular ... Seeing that trusted VPNs offered no real security, vendors started to create protocols that would allow traffic to be encrypted at the edge of one network ... and then decrypted when it reached ... Networks that are constructed using encryption are called secure VPNs.

"A secure VPN can be run as part of a trusted VPN, creating a ... hybrid VPNs.

I concede that the definition of VPN need not include encryption, but I still much prefer their definition to what is in the article because it does mention security and does not involve "customers" and "providers", neither of which are necessarily required either.

I understand that you prefer it, but the IETF routinely uses the CE/PE/P router terminology with "provider" understood to mean the operator of the backbone, which can be, and often is, the same enterprise. In the example I gave of the merged companies, the only WAN connections were frame relay or private line; the "provider" of the VPN was the network operations group of the merged companies. I've personally given presentations at the North American Network Operators Group (NANOG) where it was completely understood that the outside service provider simply provided IP or data link connectivity, and the VPN function was an overlay operated by the "customer" — but many enterprise network groups consider the end users as their "customer".

Indeed, one of the more common reasons that ISPs will recommend that the customer run his own VPN is that the enterprise does not want the ISP to see unencrypted data. The CE/PE/P router architecture works perfectly well in keeping several differently encrypted networks running over the same facilities; the CE routers only see one VPN, the PE are aware of multiple VPNs and may participate in IPSec, and the P routers just carry IP packets between the PE and P routers.

I believe there are enough authoritative sources that use CE/PE/P, without becoming confused about business relationships, that this really should remain in the article. The IETF is a bit wider in scope than the VPN Consortium. No one at NANOG became confused, nor did any of the technical reviewers of my book on enterprise WANs. Howard C. Berkowitz 20:30, 2 August 2008 (CDT)

To me, the quoted RFC definition "VPN is simply defined as the 'emulation of a private Wide Area Network (WAN) facility using IP facilities' (including the public Internet, or private IP backbones)." is much better — both clearer and more general and therefore more accurate — than either the current article lede or Virtual_private_network/Definition. Sandy Harris 02:13, 13 March 2010 (UTC)

Sure; we can go with that. Howard C. Berkowitz 02:15, 13 March 2010 (UTC)

Quick overview

My quick assessment is this article is detailed, but most readers won't get it. It needs diagrams, simpler explanations building to more complex ones. I think this article is one where secondary sources would be helpful as additions, to form some kind of bridge, so that readers can get a sense of what the whole vpn idea is about. But I haven't read this article in depth (although it looks intimdating.) If my help is needed here, let me know.--Thomas Wright Sulcer 18:09, 12 March 2010 (UTC)

I've noticed changes. It's getting better.--Thomas Wright Sulcer 05:43, 14 March 2010 (UTC)

Understandability

I use VPN daily. For me it is a great invention, as retired professor I can access through VPN from home all sites that my former university pays for. In practice this means access to almost all professional journals, JSTOR, and some software download sites. Yet, I don't understand a word of the present article and it gives me a deja vu. I worked most of my life with IBM mainframes and with great effort was able to read some relevant manuals that were written in a language called Ibmese. The present article is perhaps not written in Ibmese proper, but definitely in a dialect closely related to it. --Paul Wormer 10:37, 14 March 2010 (UTC)

OK, you give me an idea. To use a VPN, there is some relevant and non-obvious knowledge. For example, in many implementations, once you bring up the VPN client software, you will lose all other direct Internet connectivity from that machine. (Yes, there are workarounds, but dangerous without expert review).

So, I'm thinking about adding to the "business needs" section a section on "user experiences. Under each of these sections, I might put a FAQ and "common myths" section.

Your comments, Paul, are really useful. It's not that you are telling me specifically something hat is wrong with the article, but telling me something it lacks -- even if it's indirect, such as "I'm a VPN user and don't know why some things happen." In writing what is here, I had been thinking much more from the viewpoint of the IT person who buys a VPN, or the VPN provider.

This is the sort of thing that is very helpful to me -- the "non-expert" who is really an expert on readability. If you can think of any questions you had as a VPN user, I'll do my best to answer them. Howard C. Berkowitz 14:05, 14 March 2010 (UTC)

Howard, you say "in many implementations, once you bring up the VPN client software, you will lose all other direct Internet connectivity from that machine." I admit that I don't know anything about networks (including VPN), but this is not my experience. After I've started VPN, I can do anything that I can do without it (and more, such as accessing restricted sites). It happens to me all the time that I forget that I have VPN running (to annoyance of my wife who cannot access the internet from her laptop when I have VPN up). --Paul Wormer 14:44, 14 March 2010 (UTC)

I did say "in many implementations", not necessarily all. In your case, do you know if you are truly connecting to those sites through your normal Internet Service Provider, or whether your machine is doing so via the Internet access of the university or wherever you are going with the VPN? I am working on some drawings that might illustrate this.

The situation with your wife's machine does make me think that the VPN client is changing something in your environment. Do you go through a common router, perhaps a wireless one? It may be that the router is VPN-aware and is blocking your wife's machine.

Assuming these are Windows machines, here is one way to investigate:

• With the VPN not running, go to the Start menu, and, under Run, type in cmd. A command line window will appear.
• Type in ipconfig. Note the values for ip address, subnet mask, default gateway, and DNS. Do this for your computer and your wife's
• Bring up the VPN and repeat the process, starting on your machine. If any of the parameters have changed, especially IP address, this is the VPN client at work. Default gateway might be the same as before. If it is not, your VPN client and the router have agreed on new addresses.
• It may be possible to get your wife's machine to work by manually assigning it an address in the new address space, but this could be tricky — depending on how smart the router may be, it may be explicitly blocking everything except your machine address

Howard C. Berkowitz 01:23, 15 March 2010 (UTC)

Howard, I know that I get a (dynamic) university IP address as soon as I start VPN. I'm then cut off from my private provider and use the university as provider. My desktop (which has an antenna) acts as a wireless router for my wife's laptop that normally goes onto the net through our private provider. As soon as I start VPN she is cut off from the private provider. I suspect that she could work through the university network if I would install VPN on her laptop, which I never bothered to do. For me the great thing of VPN is that my PC is integrated completely in the university network with all its privileges. --Paul Wormer 07:36, 15 March 2010 (UTC)

That's along the lines I suspected. Almost certainly, then, when you access an external site, the traffic goes to the university, then back out the university's firewall and to its service provider rather than yours; yours is cut off, which is what I was trying to say. The diagrams should help. Howard C. Berkowitz 15:32, 15 March 2010 (UTC)

Addition?

The paper Moat: A virtual private network appliance and service platform by Denker, Bellovin, et al. [1] is specifically about FreeS/WAN usage at Bell Labs, but has some good general discussion of VPN design & motivations. Sandy Harris 23:09, 10 June 2010 (UTC)