From owner-freebsd-hackers Thu Jan 30 12:55:18 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id MAA00630 for hackers-outgoing; Thu, 30 Jan 1997 12:55:18 -0800 (PST) Received: from nic.follonett.no (nic.follonett.no [194.198.43.10]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id MAA00625 for ; Thu, 30 Jan 1997 12:55:16 -0800 (PST) Received: (from uucp@localhost) by nic.follonett.no (8.8.5/8.8.3) with UUCP id VAA03910; Thu, 30 Jan 1997 21:52:37 +0100 (MET) Received: from oo7 (oo7.dimaga.com [192.0.0.65]) by dimaga.com (8.7.5/8.7.2) with SMTP id VAA15668; Thu, 30 Jan 1997 21:50:29 +0100 (MET) Message-Id: <3.0.32.19970130215029.00b2eba0@dimaga.com> X-Sender: eivind@dimaga.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Thu, 30 Jan 1997 21:50:30 +0100 To: =?iso-8859-1?Q?S=F8ren_?= Schmidt From: Eivind Eklund Subject: Re: ipdivert & masqd Cc: imp@village.org, hackers@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by freefall.freebsd.org id MAA00626 Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk 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/