[ale] SSL-based VPNs (OpenVPN) vs IPSec
Michael H. Warfield
mhw at wittsend.com
Fri Feb 25 10:53:28 EST 2005
On Fri, 2005-02-25 at 09:20 -0500, M Raju wrote:
> "So my statement was that I just don't see any advantage of an SSL based
> VPN (vtun or stunnel or OpenVPN) over IPSec vis-a-vis NAT. And I still
> don't."
> Thanks for the insight. One more thing, what would you say about the
> argument regarding Userland vs Kernal space? OpenVPN claims that
> operating in Userland offers more security...
Where do you see them make that specific claim? I would like to see
what they state to substantiated it.
I do see on their site where they tout user land implementation as
being more extensible, easier to port, easier to add new cyphers,
modular designed, etc, etc, etc... I'll buy those claims (though, I'm
not sure they are totally relevant against IPSec). But I don't see any
specific claim that it "offers more security".
It's also worth noting that what most people view as IPSec is actually
several modules, most of which are userland. IKE (Internet Key
Exchange) daemon and setkey are both user land tools. The only thing
that is "kernel space" is KLIPS (Kernel Level IP Sec) on 2.4 or the
USAGI IPSec stack in 2.6. That only implements the packet encapsulation
and routing. All of the key exchange and session negotiation and
management in the various IPSec implimentations are all user land
applications.
At one time, OpenVPN had a distinct advantage in being able to take
advantage of new algorithms, like AES, and advanced authentication
methods, like PKI X.509, but these are largely supported under Pluto
(from OpenSWAN) and Racoon (from IPSec-Tools) so that advantage has also
evaporated. And now OpenVPN (2.0) is even using the IPSec ESPinUDP
encapsulation that's at the heart of IPSec NAT-T. So we seem to have a
convergence of technology here and it's only the nature of the user land
support apps that are distinguishing them, now (plus doing the actual
traffic encapsulation in user land in the case of OpenVPN).
It is definitely easier to set up and configure OpenVPN than IPSec.
But IPSec is the open interoperability standard and supported by RFCs.
You won't get OpenVPN talking with Cisco routers or CheckPoint VPN-1.
Sometimes that interoperability is shaky in IPSec, but, at least, it's
there in principle and they have connectathons for testing and debugging
interoperability between different vendors implementations. OpenVPN is
a single implementation.
A downside that I've noticed in user land implementations of the
encapsulation schemes seems to be a bit of reliability. Somethings
things just seem to go wrong (to the point of not even being able to
shut down the system because you can't get the damn thing to release the
"tun" device). I don't see the added complexity of passing all the
tunneled network traffic from kernel space to user space and back again
and managing all the device communications and routing from user land as
an advantage for a VPN at all. Something goes "bump in the night" at
the other end of a VPN connection, you're often not in a position to
readily fix it remotely. Many will argue that it's not a problem with
the VPN per se, but a problem with the tun/tap devices. I would agree.
But that's just the point. The VPN is dependent on these tun/tap
implementations and a lot of kernel-mode user-land transitions. I think
I would prefer to have the encapsulation stacks in-line in the protocol
stacks in the kernel.
> _Raju
> On Fri, 25 Feb 2005 09:08:35 -0500, Michael H. Warfield
> <mhw at wittsend.com> wrote:
> > On Fri, 2005-02-25 at 08:11 -0500, Christopher Fowler wrote:
> > > Sure. We have a FC2 server at our home office running our demo
> > > software. It is at IP Address 192.168.3.1 and runs Vtun
> > > (http://vtun.sourceforge.net/). It listens on port 5001. Our firewal
> > > will send any traffic from the Internet on 5001 to 192.168.3.1:5001.
> >
> > Ah! The missing detail! You have a DNAT on one side. That's
> > sufficient.
> >
> > IPSec can do that as well. Just forward 500/udp and 4500/udp and NAT-T
> > across the other NAT will work just fine.
> >
> > > At the customers site we ship a device that has vtun on it. 99.9% of
> > > the time it too is behind a nat firewall and has a private IP. The
> > > device runs in client mode oand our server in server mode. So the
> > > device tries to connect to 66.23.198.138:5001 and then our firewall
> > > sends that to 192.168.3.1:5001. It is authenticated and then pppd is
> > > ran on each device. PPP is used between the two. The tunnel is
> > > encrypted and compressed.
> >
> > > In this model they don't meet in the middle. One has to contact the
> > > other. This is why having them both behind NAT firewalls work. So we
> > > only have 1 server but we have 20 devices out there with a P-T-P tunnel
> > > into that server. Everyone of those devices are behind firewalls with
> > > private IPs.
> >
> > But, the question was, what configuration do you have where IPSec will
> > not work. IPSec will work in this configuration. Once side has a DNAT.
> > That's fine. That' works equally well.
> >
> > > Why? Our customer install devices in networks they do not control. Our
> > > software communicates on many ports. It was a PITA to have our
> > > customers instruct the network guys at the remote site what ports needed
> > > to be open a nat'ed. So it was just easier to have the device create a
> >
> > But you just said one side had this. That's all you need for any of
> > these to work. The other side works through the NAT with NAT-T.
> >
> > > tunnel from inside the remote network and all our traffic could flow in
> > > that tunnel. The only issues we ever face is the fact that on the
> > > remote network 5001 could be blocked for outgoing traffic. That can
> > > easily be fixed.
> >
> > > I'm not using OpenVPN. I'm using Vtun. Maybe that is why you're
> > > confused as to how I've got it to work.
> >
> > Actually, no I'm not. I understand, now, how you've got it to work,
> > but that's not how I was confused. I was confused why you believed the
> > others wouldn't work. Both OpenVPN and IPSec will work equally well in
> > the environment you described. The statement was that this is why you
> > had to use an SSL based VPN. But that's why I said "Apples <=> Oranges"
> > because SSL gives you no advantage there. IPSec NAT-T even encorporates
> > "keep alives" to keep the NAT sessions "warm" and open for the UDP
> > activity.
> >
> > So my statement was that I just don't see any advantage of an SSL based
> > VPN (vtun or stunnel or OpenVPN) over IPSec vis-a-vis NAT. And I still
> > don't.
> >
> >
> > > On Thu, 2005-02-24 at 23:59, Michael H. Warfield wrote:
> > > > On Thu, 2005-02-24 at 22:42 -0500, Christopher Fowler wrote:
> > > > > Meet in the middle type negotiated is a problem. Same reason I can't
> > > > > simply use a tun device either. For double NAT you need a client and
> > > > > server model. That is why I have to use SSL based Vtun
> > > >
> > > > Apples <=> Oranges...
> > > >
> > > > You need something on a public IP address. That's why a Teredo server
> > > > must be on a public address. But, once the negotiation is done, two
> > > > clients can communicate with each other behind NATs without involving
> > > > the server.
> > > >
> > > > What you haven't shown me is how you get around not having a server on
> > > > a public IP. If you have a server on a public IP, then IPSec over NAT
> > > > (using NAT-T) should work just fine (I do it all the time), even with
> > > > two clients behind NATs, but it routes through the server, as would
> > > > OpenVPN. Outside of some of the weird magic Teredo pulls (you really
> > > > don't want to go there), almost all the VPNs require a server in the
> > > > middle or a static NAT translation in the traffic path.
> > > >
> > > > I just don't see any advantage to an SSL based VPN over an IPSec VPN
> > > > for this purpose. Can you give me an example (with configs) where you
> > > > have an SSL based VPN that works where an IPSec VPN would not?
> > > >
> > > >
> > > > > On Thu, 2005-02-24 at 21:31, Michael H. Warfield wrote:
> > > > > > On Thu, 2005-02-24 at 20:48 -0500, Christopher Fowler wrote:
> > > > > > > My #1 problem with IPSec is how it has to be used. I have two devices
> > > > > > > that needs a tunnel between them. Both devices are behind a NAT
> > > > > > > Firewall. They do not have a public interface. This is where IPSec is
> > > > > > > useless. IPSec requires that these devices have public interfaces. In
> > > > > > > my case I can only use a SSL based VPN like Vtun. There are not any
> > > > > > > other options.
> > > > > >
> > > > > > > Maybe I'm wrong about IPSec but based on what I've read it can't be
> > > > > > > natted. It has to be on a public interface.
> > > > > >
> > > > > > IPSec can be NAT'ed under a variety of circumstances. Some devices
> > > > > > actually attempt to NAT protocols 50 and 51 but this is highly
> > > > > > unreliable. A better option is IPSec NAT-T, which is IPSec over UDP,
> > > > > > which is now supported by a released RFC. What happens there is that
> > > > > > BOTH IKE and IPSec AH/ESP get encapsulated in UDP on port 4500. That
> > > > > > fixes the single NAT case. FreeSwan / Openswan / Stronswan all support
> > > > > > IPSec NAT-T, as does L2TP on Windows XP. If you have a double NAT case,
> > > > > > I'm not sure how you would manage the "meet in the middle" negotiation
> > > > > > issue. How does OpenVPN handle it? In the IPv6 world, we have critters
> > > > > > such as Teredo which operate between two NAT'ed clients but it requires
> > > > > > the mediation of a Teredo server on a public address. I can see
> > > > > > establishing a VPN tunnel (IPSec or SSL or IPv6) across clients that are
> > > > > > each NAT'ed as long as you have a public "touch stone" where they can
> > > > > > negotiate across a server. But, one way or the other, the two NAT'ed
> > > > > > clients have to establish their endpoints from behind those NAT devices.
> > > > > >
> > > > > > > On Thu, 2005-02-24 at 18:54, Michael H. Warfield wrote:
> > > > > > > > On Tue, 2005-02-22 at 15:06 -0500, M Raju wrote:
> > > > > > > > > I have been thinking of playing with OpenVPN and convert my existing
> > > > > > > > > setup at home which comprises of mainly an IPSec VPN for WiFi/External
> > > > > > > > > access - OpenBSD Firewall/Access Point running (ISAkmpd), Racoon on OS
> > > > > > > > > X and OpenSWAN for Linux.
> > > > > > > >
> > > > > > > > > Anyone prefer SSL over IPSec? Found an interesting paper on OpenVPN Security ->
> > > > > > > >
> > > > > > > > > http://www.sans.org/rr/papers/20/1459.pdf
> > > > > > > >
> > > > > > > > Personally, I would avoid an ssl based VPN like the plague. There is
> > > > > > > > no "perfect forward secrecy" or rekeying and the session keys can be
> > > > > > > > determined from the PKI authentication keys (in other words, if you
> > > > > > > > compromise the key from either end, you can decrypt the traffic, which
> > > > > > > > is not the case with IPSec w/ PFS and Diffie-Hellman).
> > > > > >
> > > > > >
> > > > > > > > > _Raju
> > > > > >
> > > > > > Mike
> > --
> > Michael H. Warfield | (770) 985-6132 | mhw at WittsEnd.com
> > /\/\|=mhw=|\/\/ | (678) 463-0932 | http://www.wittsend.com/mhw/
> > NIC whois: MHW9 | An optimist believes we live in the best of all
> > PGP Key: 0xDF1DD471 | possible worlds. A pessimist is sure of it!
> >
> >
> >
>
>
--
Michael H. Warfield | (770) 985-6132 | mhw at WittsEnd.com
/\/\|=mhw=|\/\/ | (678) 463-0932 | http://www.wittsend.com/mhw/
NIC whois: MHW9 | An optimist believes we live in the best of all
PGP Key: 0xDF1DD471 | possible worlds. A pessimist is sure of it!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 307 bytes
Desc: This is a digitally signed message part
More information about the Ale
mailing list