From owner-freebsd-questions  Sat May 18 12:21:37 1996
Return-Path: owner-questions
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.3/8.7.3) id MAA15314
          for questions-outgoing; Sat, 18 May 1996 12:21:37 -0700 (PDT)
Received: from fyeung5.netific.com (netific.vip.best.com [205.149.182.145])
          by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id MAA15309
          for <questions@freebsd.org>; Sat, 18 May 1996 12:21:34 -0700 (PDT)
Received: (from fyeung@localhost) by fyeung5.netific.com (8.6.11/8.6.9) id MAA21394 for questions@freebsd.org; Sat, 18 May 1996 12:27:16 GMT
From: francis yeung <fyeung@fyeung5.netific.com>
Message-Id: <199605181227.MAA21394@fyeung5.netific.com>
Subject: Re: ip masquerading
To: questions@freebsd.org
Date: Sat, 18 May 1996 12:27:16 +0000 ()
X-Mailer: ELM [version 2.4 PL24]
Content-Type: text
Sender: owner-questions@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

> 
> 

Greetings,


> 
> On Fri, 17 May 1996, Terry Lambert wrote:
> 
> > Which is to say, you turn on IP forwarding by default (which is illegal)
> > and rewrite the packet source headers on the way in and out (which is
> > also illegal).
> 
> > Writing a socks client that hooks to a tunnel driver on the machine
> > that needs the masquerading is a better solution, and it doesn't
> > require kernel hacks to get there (or source hacks for statically
> > linked binaries, like normal socks does).  And it does it without
> > violating the world.
> > 
> > I guess you would need to write a tunnel client daemon (instead of
> > putting in about twice as much work to write IP masquerading, as
> > well as dragging the poor kernel into the mess).
> > 
> > Seems like that would provide the same capability for less effort
> > with fewer drabacks -- but would require an OS (like FreeBSD) with
> > tunnel drivers to make it work.
> 
> 
> 

	Actaully, I have been using (hacked) tcprelay/ftprelay and udprelay
	to do the similiar thing in FreeBSD.

	The following approaches may not be 100% identical but some of
	the objectives are similiar:

	o Socks

		- Socks 5 and earlier need sockified clients.
		- one step process

	o Fwtk 

		- owned by TIS and needed 2 steps processes

	o Applications Proxies

		e.g. Delegate, CERN etc.

		- good solutions but hard to find one to cover
		all applications, except Delegate which is very
		buggy.

	o tcprelay/udprelay

		- reasonable soluton.
		- Almost 1 step e.g. ftp tcprelay 8021
		where tcprelay is a gateway machine. 

	o NAT

		- 1 IP address if this is the objective.


	None of those mentioned above (except NAT) need kernal modification
	.

	One thing that I have not tried is IPIP which can do similiar things.

	Francis