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

Fri Feb 25 09:22:10 EST 2005

IPSec in a NAT environment is new news to me :)

But if it works I want to try it.  Is there a *good* book dedicated on
implementation of IPSec in Linux?  'd also like to find a *good* book on
implementation of QoS in Linux.  And when I mean good I don't mean on
measly chapter simply going over what is in the man pages.  You know
what I mean.

On Fri, 2005-02-25 at 09:08, Michael H. Warfield 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