Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 30 Jan 1997 21:50:30 +0100
From:      Eivind Eklund <eivind@dimaga.com>
To:        =?iso-8859-1?Q?S=F8ren_?= Schmidt <sos@ravenock.cybercity.dk>
Cc:        imp@village.org, hackers@freebsd.org
Subject:   Re: ipdivert & masqd
Message-ID:  <3.0.32.19970130215029.00b2eba0@dimaga.com>

next in thread | raw e-mail | index | archive | help
At 08:14 PM 1/30/97 +0100, Søren Schmidt wrote:
>In reply to Eivind Eklund who wrote:
>> I'm thinking about doing transparent proxying for the protocols, but I want
>> to see how well the packet-patching version run first.  As it is, it is
>> (hopefully) right in 99% of the cases, and it scales well.  If I get
>> reports of real-life problems I'll make it a priority to make proxies, but
>> not before.
>> (And the packet-patchers will still be an option - for most people, they
>> probably are a better or as good solution.)
>
>Hmm, I've done a NAT implementation, and my experience tells me that
>doing ftp, irc, realaudio etc in the NAT itself, (I like the name
>packet-patchers :) ) is the most efficient way of doing things, 
>and it saves the user for all that proxy fiddleing, they see the
>world as if they where on the net directly...

I was still thinking of doing 100% transparent proxies.  This would involve
snapping up all connection to proxied services, either re-assembling them
or throwing them at a local socket.  For this stream I would fork out and
run a proxy, which could interpret the data as a stream instead of a set of
disconnected packets.

It is a little less efficient than packet-patching, but works 100% and
still saves the user for 'all the proxy fiddleing'.  Working with normal
proxies (SOCKS, proxy-FTP) is a pain, and I will not write anything that
encourage admins to use them.



Eivind Eklund / perhaps@yes.no / http://maybe.yes.no/perhaps/



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3.0.32.19970130215029.00b2eba0>