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

[Christopher Fowler]

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.  

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.

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

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