From owner-freebsd-current Mon Dec 28 06:25:25 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id GAA05717 for freebsd-current-outgoing; Mon, 28 Dec 1998 06:25:25 -0800 (PST) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from smtp1.andrew.cmu.edu (SMTP1.ANDREW.CMU.EDU [128.2.10.81]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id GAA05710 for ; Mon, 28 Dec 1998 06:25:23 -0800 (PST) (envelope-from mwhite@cmu.edu) Received: from DEIMOS.REM.CMU.EDU (DEIMOS.REM.CMU.EDU [128.2.108.154]) by smtp1.andrew.cmu.edu (8.8.5/8.8.2) with ESMTP id JAA01835; Mon, 28 Dec 1998 09:25:04 -0500 (EST) Date: Mon, 28 Dec 1998 09:24:20 -0500 From: Matt White To: freebsd-current@FreeBSD.ORG cc: Christian Kuhtz Subject: Re: PPTP and FreeBSD Message-ID: <9026692.914837060@DEIMOS.REM.CMU.EDU> In-Reply-To: <19981228071255.S1333@ns1.adsu.bellsouth.com> Originator-Info: login-id=; server=cyrus.andrew.cmu.edu X-Mailer: Mulberry (Win32) [1.4.0, s/n S-100002] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG *quenches flames* I guess I didn't read the drafts closely enough four months ago when I was last looking at this. Since you obviously think you know all about these protocols, perhaps you can set me straight. My impression from looking at the protocols and the products that have been built around them is that the following is the expected case: A client dials up to a remote access server at some ISP. There has been some arrangement made between the client's company and said ISP to have the client's traffic tunneled back to their site. The remote access server creates a tunnel back to a configured endpoint at the client's company's site on behalf of the client. The client needs no software to do this and may not even know that such tunneling is taking place on it's behalf. Obviously there are other similar situations where this is useful, such as an ISP that wants to manage all of its POPs from a single IP space, but does not want to set up physical circuits for each POP. I am sure you can list many other situations, but these are really the ones that most affect me on a day to day. Now, what we were talking about is having the client itself initiate the tunnel on its own behalf. This is what the MS VPN clients do. However, from looking at the protocol spec, it seems that quite a bit goes into making the above case work properly. It seems that a protocol that only did client tunneling could be made easier to implement. That is the source of the statement that we are not exactly considering L2TP/PPTP for what they were intended. Will they work? Of course. This has already been demonstrated. As to whether to implement PPTP or L2TP first, that largely remains dependant on the application. For a client, L2TP is obviously the way to go. However, I still want a PPTP server that authenticates to radius (or better yet, uses PAM). If said PPTP server also supported L2TP, that would make me just that much happier. So anyway, where did I go horribly wrong? -Matt ---------- Matt White Network Systems Designer Canegie Mellon Computing Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message