From owner-freebsd-questions Mon May 20 21:35:03 1996 Return-Path: owner-questions Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id VAA22494 for questions-outgoing; Mon, 20 May 1996 21:35:03 -0700 (PDT) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id VAA22486 for ; Mon, 20 May 1996 21:35:01 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id VAA29860; Mon, 20 May 1996 21:30:39 -0700 From: Terry Lambert Message-Id: <199605210430.VAA29860@phaeton.artisoft.com> Subject: Re: ip masquerading To: alk@Think.COM (Tony Kimball) Date: Mon, 20 May 1996 21:30:39 -0700 (MST) Cc: terry@lambert.org, bmah@cs.berkeley.edu, questions@FreeBSD.ORG In-Reply-To: <199605210324.WAA19342@compound.Think.COM> from "Tony Kimball" at May 20, 96 10:24:28 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-questions@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > Host, protocol could be encoded in the port number. You have *got* to be kidding! > > It would be nice to pull out the rewriting stuff into loadable > > rule sets. > > It would be nicer to not need them. > > Not an option, though, is it? It is for a real proxy. 8-). > client default route: server on local net > server default route: modem > internal local net route: depends on packet destination > (internal local net == net which only exists as a tunnel) > > client packet -> local net > local net -> server > server local packet -> gateway > gateway -> tunnel device internal local net > internal local net -> socks client (on server) > socks client (on server) -> socks server (on server) > socks server (on server) -> socks proxy socket on default route > > A bit redundant and baroque, but if the components are coming > off-the-shelf, it might be an economical implementation... > I think I understand the scheme now, and the tunnel device and > the general-purpose socks client seem to be the unimplemented > components, yes? The tunnel device is already there. The socks client can be hacked out of SLiRP or user mode PPP (there are two clients you'd like -- you'd prefer to have socks clients coming in normally). > Hmm... it would seem worthwhile to find out *how* Linux does > MTU discovery through a masquerade, or perhaps more appositely, > *in*what*sense* it does so. Yes, since this was my primary objection on the basis of RFC's; the other was classless routing. 8-). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.