Encapsulation in VPN

IPSec and PPTP are more popular. The PPTP is using for client to server. IPSec can be used as cleint to server or site to site VPN. This search result may help.

Virtual Private NetworksLearn about the Microsoft commitment to support VPN interoperability through standards such as L2TP/IPsec and PPTP. Connecting Remote Users to Your Network ... technet.microsoft.com/en-us/network/bb545442.aspx

Thx for your response. But it seems that PPTP can support only one tunnel at a time for each user. Therefore, its proposed successor, L2TP (a hybrid of PPTP and another protocol, L2F ) can support multiple, simultaneous tunnels for each user.

So, shouldn't L2TP be popular ?

PPTP and L2TP are the layer 2 VPN technologies from CPE (customer premise equipment) to CPE. IPSec is the primary layer 3 VPN technology providing a CPE to CPE tunnel. Refer-

Further from another link from internet, i found that it seems that PPTP separates the control and data channels into control stream that runs over TCP and a data stream that runs over GRE (a less popular Internet standard). But, in contrast L2TP combines the control/data channels and uses high-performance UDP. This makes L2TP more "firewall friendly" than PPTP -- a crucial advantage for an extranet protocol -- since most firewalls do not support GRE.

So, i wonder how PPTP is popular compared to L2TP ? Any ideas ?

Thx in advans, Karthik Balaguru

i don't know much about VPN, but i do believe it's a field dominated by proprietary/gateway solutions: cisco vpn, intel vpn, ...

No.

IPSEC is very widely used for infrastructure VPNs and is not proprietary. Cisco interoperates with Checkpoint interoperates with Draytek interoperates with OpenVPN ....... Never found a problem in dozens of cases.

What is often proprietary are the VPN client solutions where one of the VPN endpoints is an individual PC.

Cisco, Microsoft, Checkpoint all have their own proprietary inplementations.

I would say that PPTP maintains its popularity with small to medium sized organisations because it does not require certificates. If you have an established certificate system in your organisation (and a person capable of maintaining it), L2TP is the obvious choice.

If you do not, setting up and maintaining this simply to support a few dialup VPN clients is a big ask. Making a few changes to your firewall for GRE is pretty minor by comparison.

RFCs are written around standards, and IPsec is the one that gets picked often :)

I vaguely remember this is to do with the encryption setups since the various L2 protocols seem to be less versatile.

You need to remember VPNs are often specified by security depts, not IP, so security can be considered more important than simplicity.

life as usual isnt that simple.

if you look at how IPsec is used in practice for "non single client" setups you tend to get another protocol within the IPsec wrapper.

router to router links are often used in a resilient network - where you want multicast then you get IPsec -> GRE tunnel -> encap packet.

Where you have client PC style VPNs a different set of constraints apply - Cisco VPN client on a PC is IPsec by default (last few times i used it)., but if you want to get it thru a NAT based SOHO router, you "hide" the IPsec by wrapping that in a UDP or TCP stream.

So you get UDP wrapper stream -> IPsec -> encap packet.

The TCP setup is a good fallback where the error handling is needed or a firewall doesnt allow UDP. So if you have a really poor link, or low thruput and high jitter such as older 3G links then TCP encap instead of UDP.

Other VPN client setups seem to do similar things.

If you want simple then throw all the thick client stuff out and go for SSL - but there are some apps that just do not work well or at all in a web front end setup.

Meanwhile, at the comp.dcom.sys.cisco Job Justification Hearings, bod43 chose the tried and tested strategy of:

OpenVPN is proprietary and will not work with a Draytek router.

I think you should know that "what is popular" is not determined by what can do most, what is technically superior and other such reasons that you run in to when you do a comparison of VPN technologies as a technician.

What is popular is determined by what sells best, or what is part of something that already sells best. When it can do the job, it is used.

OpenVPN community edition has been released under the GPL. Hardly proprietary. If it does not work, then hack on the source.

OK. Was working by memory.

I recall now, maybe we passed OpenVPN through our firewall and did not terminate on it. Sorry.

I wouldn't say it's proprietary between Microsoft and Cisco, for after all, THEY developed L2TP as a joint venture, which became an industry standard.

L2TPIn order to make use of the features of both PPTP and L2F, L2TP was developed in a joint venture between Microsoft and Cisco. ...

Some companies do have their own propietary stuff, such as OpenVPN, but I haven't used it, so I can't comment on it.

Could use a pre-shared key for the L2TP which is about like using a password. However I just use PPTP being the small to medium size kinda guy that I am :-)

Yes, that is true. Agreed :-) Thinking on the similar lines, another query popped up in my mind. In the case of L2TP, Is it mandatory that in the 'voluntary tunnel mode', the tunnel should end at the remote client and in the 'compulsory tunnel mode', the tunnel should end at the ISP ?

Are there no other scenarios with other endpoints ?

Thx in advans, Karthik Balaguru

The 'Tunneling models' section in the below link clarifies it.

Lemme know if there are other scenarios apart from those mentioned in the above link.

Thx, Karthik Balaguru

In which sense do they "interoperate"?

In which sense is OpenVPN proprietary?

I went to the trouble of setting up a personal OpenVPN server (and corresponding clients) specifically because of the endless problems I had with firewalls when using PPTP (and I don't know about other people, but I can't make any change to most of the firewalls to which I'm exposed; and even when I could I still had problems when several machines within the same NAT subnet tried to use the same VPN).

Stefan

Meanwhile, at the comp.dcom.sys.cisco Job Justification Hearings, Stefan Monnier chose the tried and tested strategy of:

Which 'they' are you referring to?

There's only one implementation of the OpenVPN protocol [that I know of - recompiling for different platforms and writing pretty front ends don't count as reimplementations in my book]. OpenVPN Solutions LLC [the copyright holder] are therefore in a position to dictate what the OpenVPN protocol consists of, for example, changing the default UDP port. Anyone can take the source and extend it in ways that make it incompatible with OpenVPN, at which point it's no longer OpenVPN.

In the sense that OpenVPN built their own protocol rather than relying on one of the existing standards.

There is a lot I like about OpenVPN, but the client side stuff is just downright nasty to configure, maintain, or even use. It's great for techies, but I couldn't imagine putting it in front of an end user.

While it is true (AFAIK) that OpenVPN is the only implementation of the OpenVPN protocol, the protocol is built on SSL - thus the encryption part is very much standard. The authentication methods are also standard - it's only a certain amount of control information that is OpenVPN specific, and information on that is easily available as is the reference source code (the OpenVPN code).

As OpenVPN source code is under the GPL, it is certainly true that anyone can take that code and extend it or change it. It won't be OpenVPN any more (I'm guessing the name is trademarked), and if it is incompatible then it will be of pretty limited use. However, this means that if the OpenVPN Technologies (the company behind OpenVPN) ever decided to make a new version that is incompatible and closed off, then it would be a simple matter to fork the code and release a "FreeVPN" that remained open and free. The only reason that no one has done anything like that, or bothered to make other implementations of the protocol, is that the official OpenVPN software and support do a perfectly good job.

As for your examples of port numbers, OpenVPN has had an IANA official port number since 2004. And if you want to change it, it's just an entry in the configuration file.

I would say the same thing about any VPN solution other than OpenVPN. For the most part, we have windows clients and linux servers. When someone needs OpenVPN access, I just give them a copy of the windows installer, and generate a key and a configuration file (which is simply a sample config file with the remote address modified appropriately). The setup is vastly easier than other ways to handle VPNs, especially if the client is behind a router or needs to connect to multiple VPNs.

In other cases, we've provided routers with OpenWRT installed and the client configured. The user plugs in the router, and has VPN access via one of the network ports. It couldn't be easier.