[ale] SSL-based VPNs (OpenVPN) vs IPSec

[Michael H. Warfield]

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!
-------------- 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