From owner-freebsd-net Thu Jul 27 17: 0:20 2000 Delivered-To: freebsd-net@freebsd.org Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (Postfix) with ESMTP id 5CA5F37B5D2; Thu, 27 Jul 2000 17:00:15 -0700 (PDT) (envelope-from erik@whistle.com) Received: from whistle.com (erik.whistle.com [207.76.205.71]) by alpo.whistle.com (8.9.1a/8.9.1) with ESMTP id QAA13668; Thu, 27 Jul 2000 16:59:40 -0700 (PDT) Message-ID: <3980CCEC.379C5ACF@whistle.com> Date: Thu, 27 Jul 2000 16:59:40 -0700 From: Erik Salander X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 4.0-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: net@FreeBSD.ORG Cc: Ruslan Ermilov , Archie Cobbs , Julian Elischer , Brian Somers , Charles Mott , Eivind Eklund Subject: Re: Improved PPTP support for libalias(3) References: <20000417170542.A61926@relay.ucb.crimea.ua> <200004180014.RAA28144@bubba.whistle.com> <20000419115513.A42767@relay.ucb.crimea.ua> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org We've ran into a bit of a snag with 2 PPTP clients, behind the same address-translation entity, attempting to connect to the same PPTP server. Everything is fine in the address-translation: two mappings, each distinguishable from either direction. But at the PPTP server, PPTP maintains an IP address based association between the client and server. So a second connection (in the described manner) results in a collision of sorts. Yesterday, when we checked in the RTSP/RTP aliasing changes, we added a BUGS section to the libalias man page about this. This is a restriction for now. This is how the combinations work at this point: - 2 clients being address translated can successfully connect to different servers - 2 clients being address translated can not connect to the same server (restriction described by this post) - 1 server being address translated can successfully serve many clients - 2 servers being address translated is not yet supported. Erik Ruslan Ermilov wrote: > On Mon, Apr 17, 2000 at 05:14:25PM -0700, Archie Cobbs wrote: > > Ruslan Ermilov writes: > > > > does this mean that only one PC at a time behind a NAT wall, can access a > > > > particular machine? > > > > i.e. two visitors with their own laptops from the same place, > > > > cannot go back to the same host to read their mail..? > > > > This is not a BAD restriction, but it is a restriction.. > > > > > > > If you mean two PCs, each with their own tunnel to the same host, this > > > will not work. The problem here is that we need some "tag" to use with > > > source and destination IP addresses, to successfully de-alias packets > > > coming in. For TCP and UDP packets, there are port numbers. For ICMP > > > echo/timestamp packets, there is an ID field. But unfortunately, there > > > seems to be no such "tag" with PPTP protocols. > > > > Sure there is: the Call ID. > > > > We are probably going to implement the remaining bit of this here > > at Whistle in the next couple of weeks.. and will submit when done. > > > This patch should (hopefully) allow for concurrent PPTP tunnels from > multiple local PACs to the same remote PNS to work behind NAT (rfc2637 > terminology is being used). > > Could someone please test this patch, since I do not have enough test > environment here? > > Note please, that you DO NOT need PacketAliasRedirectPptp() for this > to work. Just running natd(8) with the default set of options should > be enough. > > If someone is going to test this, please mail me the output of `natd -v' > while trying PPTP to the same PNS from two or more local PACs. > > Thanks, > -- > Ruslan Ermilov Sysadmin and DBA of the > ru@ucb.crimea.ua United Commercial Bank, > ru@FreeBSD.org FreeBSD committer, > +380.652.247.647 Simferopol, Ukraine > > http://www.FreeBSD.org The Power To Serve > http://www.oracle.com Enabling The Information Age > > ------------------------------------------------------------------------ > > pName: p > Type: Plain Text (text/plain) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message