Encapsulation in VPN

Have a question or want to start a discussion? Post it! No Registration Necessary.  Now with pictures!

Threaded View


Hi,
For data ecapsulation, VPN relies on either of the
following technologies like GRE , IPSec, L2F,
PPTP and L2TP .  But, which of the above
technologies is popular ? If they vary based
on the requirements, can you pls lemme know
a document/link that maps the technologies
against the requirements w.r.t VPN ?

Thx in advans,
Karthik Balaguru

Re: 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


--
Bob Lin, Microsoft-MVP, MCSE & CNE
Networking, Internet, Routing, VPN Troubleshooting on
http://www.ChicagoTech.net
How to Setup Windows, Network, VPN & Remote Access on
http://www.HowToNetworking.com


Quoted text here. Click to load it


Re: Encapsulation in VPN


wrote:
Quoted text here. Click to load it

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- http://www.networkdictionary.com/networking/vpn.php

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

Re: Encapsulation in VPN


On Sat, 19 Dec 2009 14:09:33 -0800, karthikbalaguru wrote:

Quoted text here. Click to load it

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

Re: Encapsulation in VPN


Quoted text here. Click to load it

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.


Re: Encapsulation in VPN


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

Quoted text here. Click to load it

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

--
 <http://ale.cx/ (AIM:troffasky) (UnSoEsNpEaTm@ale.cx)
 09:47:26 up 22 days, 13:40,  8 users,  load average: 0.00, 1.02, 1.32
 Plant food is a made up drug


Re: Encapsulation in VPN


alexd wrote:

Quoted text here. Click to load it

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

--
http://www.mailtrap.org.uk /

Re: Encapsulation in VPN


Quoted text here. Click to load it

OK. Was working by memory.

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


Re: Encapsulation in VPN


Quoted text here. Click to load it

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. ...
http://zaielacademic.net/security/l2tp.htm

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

--
Ace

This posting is provided "AS-IS" with no warranties or guarantees and
confers no rights.

Please reply back to the newsgroup or forum for collaboration benefit
among responding engineers, and to help others benefit from your
resolution.

Ace Fekay, MCT, MCITP EA, MCTS Windows 2008 & Exchange 2007, MCSE &
MCSA 2003/2000, MCSA Messaging 2003
Microsoft Certified Trainer

For urgent issues, please contact Microsoft PSS directly. Please check
http://support.microsoft.com for regional support phone numbers.



Re: Encapsulation in VPN


Quoted text here. Click to load it

In which sense do they "interoperate"?

Quoted text here. Click to load it

In which sense is OpenVPN proprietary?

Quoted text here. Click to load it

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

Re: Encapsulation in VPN


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

Quoted text here. Click to load it

Which 'they' are you referring to?

Quoted text here. Click to load it

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.

--
 <http://ale.cx/ (AIM:troffasky) (UnSoEsNpEaTm@ale.cx)
 20:09:39 up 37 days, 4 min,  5 users,  load average: 0.00, 0.02, 0.05
 DIMENSION-CONTROLLING FORT DOH HAS NOW BEEN DEMOLISHED,
 AND TIME STARTED FLOWING REVERSELY


Re: Encapsulation in VPN


alexd wrote:
Quoted text here. Click to load it

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.

Re: Encapsulation in VPN


Quoted text here. Click to load it

Cisco, Checkpoint, Draytek, and OpenVPN.  Or to put the question more
precisely and avoid potential misunderstandings on my part:

  What is meant by "interoperates" in "Cisco interoperates with
  Checkpoint interoperates with Draytek interoperates with OpenVPN"?

In my world, "interoperate" in this context would mean something like "a
client from one company can connect to a server of the other company".
But clearly, that's not what is meant above since only an OpenVPN client
can connect to an OpenVPN server (don't know about the other ones).


        Stefan

Re: Encapsulation in VPN




Quoted text here. Click to load it

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.

Re: Encapsulation in VPN


Dave Warren wrote:
Quoted text here. Click to load it

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.

Re: Encapsulation in VPN


Stefan Monnier wrote:
Quoted text here. Click to load it

I think the poster means that the protocol is not an official standard
held by an independent body.  That's true, even though it is built
around existing standards and is freely available.

Quoted text here. Click to load it

I have no doubt that OpenVPN is much easier to configure and work with
both for the server and clients.  Most of the servers I have configured
have been on small, cheap LinkSys routers using OpenWRT, with multiple
OpenVPN configurations - an independent OpenVPN network for each network
port on the device.  Different clients have OpenVPN connections to
different servers, and can easily connect to or disconnect from the
networks as they require.  Each server can have multiple clients for the
different VPN networks as needed.  Each client can be connected to
multiple servers.  And both the servers and clients are typically behind
at a NAT router.  This kind of flexibility is simply impossible with
other VPN solutions.

Re: Encapsulation in VPN




Quoted text here. Click to load it

   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.
 


Re: Encapsulation in VPN


Quoted text here. Click to load 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  :-)

--
Phillip Windell

The views expressed, are my own and not those of my employer, or Microsoft,
or anyone else associated with me, including my cats.
-----------------------------------------------------



Re: Encapsulation in VPN


On Sat, 19 Dec 2009 14:09:33 -0800 (PST), karthikbalaguru

Quoted text here. Click to load it
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.

Quoted text here. Click to load it
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.

Quoted text here. Click to load it
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.

Quoted text here. Click to load it
--
Regards

stephen_hope@xyzworld.com - replace xyz with ntl

Re: Encapsulation in VPN


Quoted text here. Click to load it

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.

Site Timeline