[ale] SSL-based VPNs (OpenVPN) vs IPSec
Michael H. Warfield
mhw at wittsend.com
Fri Feb 25 10:30:09 EST 2005
On Fri, 2005-02-25 at 09:16 -0500, Christopher Fowler wrote:
> IPSec in a NAT environment is new news to me :)
FreeSWAN / KLIPS implemented IPSec NAT-T quite a while back (as in
several years ago). In fact, they ended up with two flavors of the UDP
encapsulation based on two iterations of the IETF drafts at the time
(managed transparently - users never knew or saw any difference).
AFAIK, this was done in the FreeSWAN 2.x days. I don't think NAT-T was
in the 1.x FreeSWAN, though I could be wrong on that point. It was a
long time ago. Openswan and Strongswan are both forks off the final
iterations of FreeSWAN (2.0.4 / 2.0.5). To enable NAT-T in a FreeSWAN /
Openswan / Strongswan you merely add the configuration
"nat_traversal=yes" to the global setup. With that enabled, if pluto
detects NAT at either end (or both) it will switch to port 4500/udp
(there's a hysterical/historical reason for why the port shift is
required and it's due to dain-bramaged NAT devices that try to be TOO
helpful on port 500 and dick it up) and enable ESPinUDP encapsulation.
Additionally, there is a (currently) undocumented per-connection option
to "force" NAT-T (for things like firewall traversal where the firewall
is blocking ESP/AH and not blocking UDP but where there still is no
actual NAT). You add the configuration option "forceencaps=yes" in the
individual connection definitions to force pluto to select ESPinUDP
encapsulation for that connection. I've used NAT-T for several years
now but I always had to FORCE the NAT-T mode with a compile time option
in pluto until just recently (~6 months ago) when OpenSWAN added the
"forceencaps" option (definitely in the 2.3 flavor - unsure about the
2.2 flavor that comes with Fedora Core 3 base install). Now I can just
install the rpm on Fedora Core and have it work and be able to force the
connections I want forced.
Pluto, the FreeSWAN/Openswan/Stronswan IKE implimentation, works with
both KLIPS (Kernel Level IPSec) from their own project in the 2.4
kernels or with the 2.6 IPSec implementation which is now native in the
kernel source tree.
Linux 2.6 includes NAT-T (final draft and RFC 3947, same as the
ESPinUDP encapsulation of KLIPS) in its native IPSec implementation.
Both ipsec-tools (Kame SetKey/Racoon) and Pluto from OpenSWAN/StrongSWAN
are capable of utilizing the 2.6 native implimentation of IPSec NAT-T.
If you are using ipsec-tools, you add the configuration option
"nat_traversal yes;" to enable it or "nat_traversal force;" to force it
into the individual connection definitions.
To use Openswan or Stronswan with the 2.6 kernel IPSec, you also need
the "setkey" program from the ipsec-tools. So you're only using Pluto
from the Swan projects at that point, instead of Racoon, for your IKE
part (the user land session / key negotiation daemon). Sooo... On
Fedora Core 3, you would install both the ipsec-tools rpm and the
openswan rpm (even though they are lacking a dependency in there at this
time).
> 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
That's a really good question. Most of the "dead trees editions" I'm
aware of are not fully up to date and the final NAT-T RFC is relatively
recent. While FreeSWAN is now official terminated as an active project,
both OpenSWAN and StrongSWAN are under active development and some
options (such as the forceencaps option) are not well documented (if at
all). The OpenSWAN wiki may be your best bet, there.
> 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.
I'm not real big on "dead trees editions" much lately and I haven't
seen all that much about QoS outside of the IPv6 arena. So I'm not
really aware of much in the way of books out there. Maybe someone else
can make some recommendations?
> 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
--
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