[ale] SSL-based VPNs (OpenVPN) vs IPSec
M Raju
protocoljunkie at gmail.com
Tue Mar 1 08:05:45 EST 2005
<quote>
Where do you see them make that specific claim? I would like to see
what they state to substantiated it.
</quote>
I have to rephrase my initial sentence. Perhaps I got the notion that
OpenVPN was more secure by reading the SANs paper noted on the OpenVPN
website -> http://www.sans.org/rr/papers/20/1459.pdf by Charlie Hosner
Maybe it is just preference, but I guess I am sticking with IPSec for now..
_Raju
On Fri, 25 Feb 2005 10:46:14 -0500, Michael H. Warfield
<mhw at wittsend.com> wrote:
> 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!
>
>
>
--
May the packets be with you.
More information about the Ale
mailing list