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

Michael H. Warfield mhw at wittsend.com
Fri Feb 25 09:15:56 EST 2005


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