From owner-freebsd-questions Mon May 20 17:11:54 1996 Return-Path: owner-questions Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id RAA01230 for questions-outgoing; Mon, 20 May 1996 17:11:54 -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 RAA01225 for ; Mon, 20 May 1996 17:11:51 -0700 (PDT) Received: from Early-Bird-1.Think.COM by mail.think.com; Mon, 20 May 96 20:09:10 -0400 Received: from compound.Think.COM by Early-Bird.Think.COM; Mon, 20 May 96 20:09:05 EDT Received: (from alk@localhost) by compound.Think.COM (8.7.5/8.7.3) id TAA18525; Mon, 20 May 1996 19:10:02 -0500 (CDT) Date: Mon, 20 May 1996 19:10:02 -0500 (CDT) Message-Id: <199605210010.TAA18525@compound.Think.COM> From: Tony Kimball To: terry@lambert.org Cc: bmah@cs.berkeley.edu Cc: alk@Think.COM, questions@FreeBSD.ORG In-Reply-To: <199605202245.PAA28777@phaeton.artisoft.com> (message from Terry Lambert on Mon, 20 May 1996 15:45:51 -0700 (MST)) Subject: Re: ip masquerading Sender: owner-questions@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk From: Terry Lambert Date: Mon, 20 May 1996 15:45:51 -0700 (MST) 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? The packet rewriting is a bit annoying; on the other hand, there are a finite number of protocols that really need to be supported this way, so it's bad, but it's not as bad as it could be. It would be nice to pull out the rewriting stuff into loadable rule sets. 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. > 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. If the gateway violates host requirements, *that* is a problem.