[ previous ] [ next ] [ threads ]
 
 From:  Fred Wright <fw at well dot com>
 To:  m0n0wall at lists dot m0n0 dot ch
 Subject:  Re: [m0n0wall] several PPTP client via NAT simultaneously
 Date:  Wed, 2 Jul 2003 22:56:22 -0700 (PDT)
On Wed, 2 Jul 2003, Vincent Jardin wrote:

> >
> > It's actually much worse than that.  Not only do you have to contend with
> > the GRE traffic, but you have to deal with the TCP-based control
> > connection, which is only permitted by the protocol to exist once per pair
> > of endpoints.  There's even a mechanism in the protocol to close one of
> > the "redundant" connections that could occur if you have a bidirectional
> > client/server relationship between two machines.  Microsoft tried really
> > hard to surpass the NAT-unfriendliness of FTP. :-) L2TP is much more
> > straightforward, but less widely supported.
> 
> However, le Microsoft's L2TP requires IPSec. It means that it cannot work with 
> a NAT ;-)
> IPSec can disabled by changing the registry !!!

Microsoftisms notwithstanding, L2TP doesn't require IPsec any more than
PPTP does.  PPTP and L2TP have essentially the same security model, i.e.
neither one provides much in the way of security by itself, but needs to
be combined with some other mechanism to provide a secure tunnel.  This
can be either "inside" or "outside" the tunnel.  The "inside" method
(typically PPP-layer encryption, e.g. MPPE) protects the payload, but
leaves open some possibilities for attacks involving the control
information.  The "outside" method (typically IPsec) is more secure, but
tends to impose more constraints on the underlying architecture.

Although it's common to use MPPE "inside" PPTP and IPsec "outside" L2TP,
the other combinations are just as valid.  While L2TP/MPPE is less secure
than L2TP/IPsec, it's at least as secure as PPTP/MPPE, and perhaps more
so, due to the usual "Microsoft oopses" in the latter.

It's not strictly true that IPsec is incompatible with NAT.  It's true of
transport mode (since most of the IP header is treated as immutable), but
tunnel mode allows NAT processing of the outer header.  However, there's
the usual problem of protocol-specific demultiplexing being needed (based
on the SPI in this case), and avoiding "collisions" in the SPI when
multiple local machines communicate with a single remote machine.

					Fred Wright