NAT and PPTP

Tue Jul 29 23:50:12 PDT 2003

Thanks for answering my email , even though I am not a programmer
I can surely test things out to the best of my abilities.

It would be nice to be able to have something like a pptpd integrated into the
FreeBSD tree (STABLE and CURRENT) , it would nice of course to be able to setup
pptp tunnel dynamically and not only statically like it is the case right now
in mpd (AFAIK).

My own purpose for using this is securing a bit more 802.11(whatever) in a
large WISP setup. One of my question is how many pptp or pppoe sessions 
can be handled by one FreeBSD box knowing each pptp or pppoe sessions have
to be shaped traffic wise symetrically or asymetrically. 

So having the ability to shape inbound bandwidth and outbound bandwidth directly
inside the pptpd and pppoe thru radius and directly (for some cases) thru ppp.conf
would be really nice (it would require having a special dictionary for radius (I think))
I don't know if this is achievable without too much hassle in the current PPP (PPPOE)
code and if it is at all possible in a PPTP environment?

On Tue, 29 Jul 2003 18:17:33 -0600
Brett Glass <brett at lariat.org> wrote:

> Cristophe:
> 
> Nothing was decided in private e-mail. I'd really like to go for this,
> but will likely need some help analyzing the existing code, abstracting 
> the right parts from pppoed and mpd, and gluing everything together.
> That's why I was hoping to ask Archie and Brian for help. The code for 
> both is tricky and not well documented.
> 
> I do agree that a BSD-licensed pptpd that's made to work with FreeBSD's
> (and NetBSD's, and OpenBSD's) userland PPP is needed. PoPToP is a Linux-
> oriented, GPLed project and cannot be trusted to maintain compatibility
> with the BSDs. (The version in the FreeBSD Ports Collection has serious
> bugs, too, and is far behind the developers' latest version.) What's more, 
> professional programmers, or ones who work on BSD-licensed projects, can't 
> safely look at the code because it's GPLed and license contamination is
> a serious legal threat.
> 
> PPTP is really very close to PPPoE, except that it runs over TCP (for call 
> setup and control) and GRE (for the PPP session) rather than raw MAC-layer 
> Ethernet. The call control mechnism has no real security, and I've
> always thought it wouldn't be too hard to hijack. PPP over SSH would
> probably be more secure, but Windows doesn't support that and most of us
> need to support Windows clients.
> 
> In any event, the most difficult part of PPTP to implement seems to be that
> call control mechanism, which has far more features than necessary. This is 
> what would be good to extract from mpd, since I'll bet Archie spent a LOT 
> of time figuring out how to do it.
> 
> By the way, one thing that surprised me, when I researched it, was that even 
> though it's supposedly a secure "tunneling" protocol, there's no requirement 
> that a PPTP session actually use encryption. (In fact, several models of 
> Linksys routers have a PPTP implementation that does no encryption. This is 
> likely to mislead consumers, who will assume that if they're using PPTP they 
> have encryption.) On the other hand, PPPoE can be just as secure as PPTP, 
> since either can use MPPE to wedge encryption in where PPP normally has 
> compression.
> 
> By the way, is there BSD-licensed code for the enhanced version of MPPE
> that does both encryption AND compression (I believe it's called MPPC)? 
> I understand that Microsoft Windows has it built in, and that it's available
> for Linux as well.
> 
> --Brett
> 
> At 03:12 AM 7/29/2003, Christophe Prevotaux wrote:
>   
> >Hello,
> >
> >Any hopes for anything like a pptpd (like the pppoed) 
> >any time soon ? , discussion stopped in the thread
> >so maybe you guys discussed this further privately
> >and decided something ? 
> >
> >pptpd is a much needed feature nowdays.
> >
> >On Thu, 24 Jul 2003 23:00:45 -0600
> >Brett Glass <brett at lariat.org> wrote:
> >
> >> At 08:50 PM 7/24/2003, Archie Cobbs wrote:
> >>   
> >> >I don't have time to do any real work.. however, the PPTP control
> >> >layer can be used pretty much as is.. i.e., the files pptp_ctrl.[ch].
> >> >It has a fairly clean API that any PPP daemon could use, and all they
> >> >require is some kind of event support.
> >> 
> >> We wouldn't be doing it quite that way; we'd be using it just to
> >> steer the call through PPP (which wouldn't know that it was PPTP;
> >> it would just think the call was PPP with MPPE on the CCP layer).
> >> So, the PPP implementation wouldn't need to know about PPTP call
> >> control.
> >> 
> >> --Brett
> >
> >--
> >===============================================================
> >Christophe Prevotaux      Email: c.prevotaux at hexanet.fr
> >HEXANET SARL                URL: http://www.hexanet.fr/
> >Z.A.C Les Charmilles        Tel: +33 (0)3 26 79 30 05 
> >3 Allée Thierry Sabine   Direct: +33 (0)3 26 61 77 72 
> >BP202                       Fax: +33 (0)3 26 79 30 06
> >51686 Reims Cedex 2                                
> >FRANCE                   HEXANET Network Operation Center             
> >===============================================================
> 

--
===============================================================
Christophe Prevotaux      Email: c.prevotaux at hexanet.fr
HEXANET SARL                URL: http://www.hexanet.fr/
Z.A.C Les Charmilles        Tel: +33 (0)3 26 79 30 05 
3 Allée Thierry Sabine   Direct: +33 (0)3 26 61 77 72 
BP202                       Fax: +33 (0)3 26 79 30 06
51686 Reims Cedex 2 		                   
FRANCE                   HEXANET Network Operation Center             
===============================================================