Date: Fri, 31 Jan 1997 15:37:14 +1100 (EDT) From: Darren Reed <avalon@coombs.anu.edu.au> To: danny@panda.hilink.com.au (Daniel O'Callaghan) Cc: eivind@dimaga.com, imp@village.org, hackers@FreeBSD.ORG Subject: Re: Transparent proxies (was Re: ipdivert & masqd) Message-ID: <199701310437.UAA00532@freefall.freebsd.org> In-Reply-To: <Pine.BSF.3.91.970131084015.263G-100000@panda.hilink.com.au> from "Daniel O'Callaghan" at Jan 31, 97 08:55:35 am
next in thread | previous in thread | raw e-mail | index | archive | help
In some mail from Daniel O'Callaghan, sie said: > On Thu, 30 Jan 1997, Eivind Eklund wrote: > > At 08:04 AM 1/30/97 -0700, you 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. > > Here's a problem which requires transparent proxies for a data stream, > not packet-patching: Transparent capture of all HTTP requests on port 80 > and diversion to a www-proxy server. > > e.g. > > Client Sends "NAT" WWW-Proxy receives > 10.2.3.4 10.2.3.1 10.2.3.55 > > 10.2.3.4-> 5.6.7.8:80 ================> 10.2.3.1->10.2.3.55 > GET / HTTP/1.0 GET http://5.6.7.8:80/ HTTP/1.0 > > Darren Reed's ipfilter does this with the 'redirect' keyword and some > trickery in the receiving process. The example given is for the ftwk's > ftp-gw program (from ftp.tis.com). The userland process finds its true > destination by calling an IOCTL for the kernel NAT code. To give you some idea of "what happens": rule example: rdr ed0 any port ftp -> localhost port ftp (redirect all incoming packets going to port ftp, even if they're not for this host, to 127.0.0.1, port ftp) in inetd.conf of your freebsd gateway, you'd have: ftp stream nowait root ... /usr/local/bin/tpftpd tpftpd (tpftpd is a transparent proxy enabled ftpd). On a user's workstation, the route to X points through the freebsd gateway so they enter: % ftp X IPFilter sees the ftp packet, maps its destination to the localhost, thus inetd detects a connection, fires off tpftpd. The user doing "ftp X" sees "Connection Established". tpftpd starts up, does a lookup on the source of the connection, gets the real remote destination, initiates a connection to X. When the connection is established, it then acts like a tcp-relay, forwarding data backward and forward between the endpoints, having no trouble handling the "PORT" commands. The user doing "ftp X" has no idea of the "middle man" unless tpftpd sends its own messages when the connection is initiated. There are patches available for all the Firewall Toolkit proxies to enable this behaviour. ftp is usually the best example, using it with HTTP so that users don't need to manually configure web browsers for proxies is another. Darren
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199701310437.UAA00532>