From owner-freebsd-questions  Mon May 20 20:25:02 1996
Return-Path: owner-questions
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.3/8.7.3) id UAA16849
          for questions-outgoing; Mon, 20 May 1996 20:25:02 -0700 (PDT)
Received: from mail.think.com (Mail1.Think.COM [131.239.33.245])
          by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id UAA16841
          for <questions@FreeBSD.ORG>; Mon, 20 May 1996 20:24:58 -0700 (PDT)
Received: from Early-Bird-1.Think.COM by mail.think.com; Mon, 20 May 96 23:23:33 -0400
Received: from compound.Think.COM by Early-Bird.Think.COM; Mon, 20 May 96 23:23:29 EDT
Received: (from alk@localhost) by compound.Think.COM (8.7.5/8.7.3) id WAA19342; Mon, 20 May 1996 22:24:28 -0500 (CDT)
Date: Mon, 20 May 1996 22:24:28 -0500 (CDT)
Message-Id: <199605210324.WAA19342@compound.Think.COM>
From: Tony Kimball <alk@Think.COM>
To: terry@lambert.org
Cc: bmah@cs.berkeley.edu, questions@FreeBSD.ORG
In-Reply-To: <199605210148.SAA29397@phaeton.artisoft.com> (message from Terry
	Lambert on Mon, 20 May 1996 18:48:15 -0700 (MST))
Subject: Re: ip masquerading
Sender: owner-questions@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

   From: Terry Lambert <terry@lambert.org>
   Date: Mon, 20 May 1996 18:48:15 -0700 (MST)

   > Couldn't state be inferred from the retry packets?

   I reboot.  A packet comes in on port 3096:

   1)	Is it for me?  If so, I've been dead.

   2)	Is it for the local net?  Which host?

   3)	Is it an FTP data packet?  Some other packet?  What packet
	   rewriting rules should I apply to it based on these
	   assumptions?

Host, protocol could be encoded in the port number.

   > 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?

   >    Socks really wants two additional tunnel-to-socks and socks-to-tunnel
   >    daemons written; using two private nets, this would let you run a
   >    private net of socks-unaware hosts that get their packets proxied
   >    by setting up a default route, a private net route to one tunnel on
   >    one private net, and a default route to the other tunnel on the
   >    private net with the dumb hosts.  Effectively, a gateway LLB in user
   >    space.
   > 
   > I'm trying to picture this, but ...

[admirable ASCII art omitted]

You did take me literally:-)  I don't have a problem with the physical
picture.

   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?

   In other words, to put them on the internet (by proxy).  8-).

It appears that way to the client, but in a correct masq
implementation, they are not visible Internet objects.
Only the gateway *exists*, and it incorporates the behaviour 
of the clients by aggregation in its life as an Internet host.

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.