Date: Mon, 20 May 1996 18:48:15 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: alk@Think.COM (Tony Kimball) Cc: terry@lambert.org, bmah@cs.berkeley.edu, alk@Think.COM, questions@FreeBSD.ORG Subject: Re: ip masquerading Message-ID: <199605210148.SAA29397@phaeton.artisoft.com> In-Reply-To: <199605210010.TAA18525@compound.Think.COM> from "Tony Kimball" at May 20, 96 07:10:02 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> This is one of the *big* problems I see. The recovery mechanism to get
> around this requires an intelligent client (ie: not Windows 95) and
> the ability to recover state (ie: the client knows the state, too
> (ie: not Linux-style "masqueraing").
>
> 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?
> It would be nice to pull out the rewriting stuff into loadable
> rule sets.
It would be nicer to not need them.
> 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 I'm crippled by lack of understanding
> of the tunnel device. There is a box, G. It has a network interface,
> I(G), on the Internet. It has a network interface, P(G), on a private
> net. Hosts on network P route through P(G) to get out through I(G).
> G is implementing masquerade, then. I don't understand what you
> are saying about the structure of the implementation.
,----.
| |
| |
`----'
,----------.
| client |
`----------'
|
o-------+----+----------o local (reserved) net
|
,--.
|s |
|e |
|r |
,----. |v |
| | |e | modem
| | |r |____,-----.____ // ___ PPP provider
`----' `--' `-----' //
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
>
> > 4. It's not a general purpose solution (e.g. ICMP doesn't work...
>
> The is the second of the *big* problems.
>
> I don't understand why it is a big problem. It is a big problem if
> you are trying to put the private machines on the Internet, but
> I don't see that as being the goal. The goal is to get TCP
> applications (and secondarily UDP applications) to run transparently
> from a private network home through an Internet gateway.
In other words, to put them on the internet (by proxy). 8-).
> If the gateway violates host requirements, *that* is a problem.
Yes, a *big* one. 8-).
Terry Lambert
terry@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199605210148.SAA29397>