Date: Mon, 20 May 1996 22:24:28 -0500 (CDT) From: Tony Kimball <alk@Think.COM> To: terry@lambert.org Cc: bmah@cs.berkeley.edu, questions@FreeBSD.ORG Subject: Re: ip masquerading Message-ID: <199605210324.WAA19342@compound.Think.COM> In-Reply-To: <199605210148.SAA29397@phaeton.artisoft.com> (message from Terry Lambert on Mon, 20 May 1996 18:48:15 -0700 (MST))
next in thread | previous in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199605210324.WAA19342>